Microsoft Partner Center の Security requirements dashboard for Partner Center は、CSPパートナーが「CSP承認を維持するために満たすべきセキュリティ要件」を確認するためのダッシュボードです。結論から言うと、管理者は 管理者MFA、セキュリティ連絡先、セキュリティアラート対応 を最優先で確認し、開発者は Partner Center APIのMFA要件により自動化処理が止まらないか を検証する必要があります。
特に、Partner Centerを使って顧客テナントを管理しているCSPパートナーは、単なるセキュリティ推奨ではなく、取引・顧客管理・API連携に影響する運用要件として扱うべきです。Microsoft Learnの英語版公式ページは2026年5月15日に更新されており、日本時間では2026年5月16日時点で確認すべき最新情報として整理できます。日本語版ページの更新表示が英語版より古い場合があるため、実務では英語版も併せて確認するのが安全です。(Microsoft Learn)
Partner Center セキュリティ要件ダッシュボードとは
Partner Center セキュリティ要件ダッシュボードは、CSPパートナーが自社テナントのセキュリティ状態を確認し、未対応の要件を実装するための管理画面です。Microsoftの公式説明では、直接請求パートナー、ディストリビューター、間接リセラーが、セキュリティスコア、必須要件、推奨要件、完了済み・未完了の状態を確認できる仕組みとして位置付けられています。(Microsoft Learn)
このダッシュボードの重要な点は、「セキュリティ状態を見える化するだけの画面」ではないことです。CSP承認の維持、管理者アカウント保護、顧客テナントへの安全なアクセス、API自動化の継続性に関わります。
ダッシュボードを確認できる主なロールは、公式情報では次のとおりです。(Microsoft Learn)
| 確認できるロール | 実務上の役割 |
|---|---|
| Admin Agent | Partner Centerの運用責任者。要件の対応状況を確認し、必要な設定変更を進める |
| Security Administrator | Microsoft Entra IDやMFA、条件付きアクセスなどのセキュリティ設定を確認・変更する |
| Security Reader | 状態確認や監査目的でダッシュボードを確認する |
権限が不足している場合、ダッシュボードを見られない、または必要なアクションを完了できないことがあります。CSP管理者だけで進めず、Entra ID管理者、セキュリティ運用担当、API連携を担当する開発者を早い段階で巻き込むことが重要です。
今回の更新で押さえるべき変更点
Microsoftは、2025年10月1日以降、直接請求パートナー、ディストリビューター、間接リセラーに対して、更新されたCSP承認資格要件を適用すると説明しています。既存のCSPパートナーについては、2026年1月以降、最初にCSPへオンボードされた月の記念月に毎年検証されます。(Microsoft Learn)
実務上は、次のように理解すると分かりやすいです。
| 変更・確認ポイント | 内容 | 影響を受ける担当 |
|---|---|---|
| CSP承認要件としてのセキュリティ対応 | MFA、セキュリティ連絡先、アラート対応などがCSP承認維持に関わる | Partner Center管理者、経営・事業責任者 |
| セキュリティスコアの可視化 | 要件の完了状況に応じて0〜100のスコアで表示 | セキュリティ管理者、監査担当 |
| 必須要件と推奨要件の区別 | 必須要件はCSP承認維持に関わる。推奨要件もセキュリティ強化とスコア改善に有効 | 管理者、運用担当 |
| 今後の要件の予告 | 将来適用予定の要件が表示され、未対応の場合は将来スコアに影響する可能性がある | 情報システム、セキュリティ責任者 |
| Partner Center APIのMFA影響 | 有効なMFA要求を含まないapp+user API呼び出しがブロックされる可能性がある | 開発者、SRE、運用自動化担当 |
特に見落としやすいのは、セキュリティ要件が「管理画面上のチェック項目」ではなく、顧客管理や課金、プロビジョニング、サポート業務の継続性に直結する点です。
セキュリティスコアの仕組み
Partner Centerのセキュリティスコアは、0〜100で表示されます。Microsoftの説明では、個々のセキュリティ要件のスコアをもとに全体スコアが計算され、現在の計算アルゴリズムでは、要件に準拠している場合は最大スコア、準拠していない場合は0点として扱われます。(Microsoft Learn)
つまり、「半分だけ対応しているから半分の点数が入る」とは限りません。たとえば、管理者MFAの要件では、対象管理者の一部だけがMFA登録済みでも、要件全体として未完了扱いになる可能性があります。
公式ページでは、全体スコアの計算式は次の考え方で示されています。(Microsoft Learn)
個々のセキュリティ要件スコアの合計
÷ 個々のセキュリティ要件の最大スコアの合計
× 100管理者が見るべきポイントは、スコアの数字そのものよりも、各要件の Status、Insights、Instructions、Action です。未完了項目がある場合は、ダッシュボードの手順リンクから具体的な対応ページへ進めます。
必須要件で確認すべき項目
Partner Center セキュリティ要件ダッシュボードで特に重要なのは、CSP承認維持に関わる必須要件です。公式情報では、すべてのパートナーが満たすべき必須要件として、管理者MFA、セキュリティ連絡先、セキュリティアラート対応が示されています。なお、24時間以内のアラート対応は間接リセラーパートナーには適用されないとされています。(Microsoft Learn)
CSPテナントのすべての管理者にMFAを有効化する
最優先で確認すべき項目です。CSPテナントの管理者アカウントは、顧客テナントや契約、課金、サポートに関わる高い権限を持つため、侵害された場合の影響が大きくなります。
Microsoftの公式ページでは、少なくとも次のような管理者ロールを保護対象として挙げています。(Microsoft Learn)
| 対象ロールの例 | 確認ポイント |
|---|---|
| グローバル管理者 | 常時使用する管理者を減らし、必要最小限にする |
| セキュリティ管理者 | MFA登録と緊急時の代替手段を確認する |
| 認証管理者、特権認証管理者 | 認証方式を変更できるため、特に厳格に管理する |
| 条件付きアクセス管理者 | MFAポリシー変更権限を持つため、監査対象にする |
| Exchange管理者、SharePoint管理者 | 顧客情報・社内情報への影響を考慮する |
| 課金管理者 | 不正購入や契約変更のリスクを考慮する |
| ヘルプデスク管理者、ユーザー管理者 | パスワードリセットやユーザー操作の悪用に注意する |
ここで重要なのは、「MFAポリシーを作成した」だけでは完了とは言えない点です。公式情報では、すべての管理者ユーザーがMFA要件の対象になっていることに加え、各管理者が追加の検証要素を設定し、MFAチャレンジを完了できる状態であることが求められます。緊急アクセスアカウントもこの要件に含まれます。(Microsoft Learn)
実務では、次の順で確認すると漏れを減らせます。
| 手順 | 作業内容 | 完了判断 |
|---|---|---|
| 管理者一覧を抽出 | Entra IDで特権ロールに割り当てられたユーザーを確認 | 退職者、共有アカウント、不要な管理者がない |
| MFA適用方式を確認 | セキュリティの既定値、条件付きアクセス、ユーザーごとのMFAのどれで適用しているか確認 | すべての対象管理者がカバーされている |
| MFA登録状況を確認 | 管理者本人が認証方法を登録済みか確認 | 未登録の管理者がいない |
| 緊急アクセスアカウントを確認 | 除外・運用ルール・監査手順を確認 | 緊急用でも要件上の扱いを理解している |
| 古い管理者を削除 | 不要な特権ロールを削除または再割り当て | 最小権限に近づいている |
Microsoft Entra ID Freeを使っている場合はセキュリティの既定値、Microsoft Entra ID P1またはP2を使っている場合は条件付きアクセスを使った設計が選択肢になります。ただし、セキュリティの既定値と条件付きアクセスは並行して使用できないため、既存環境で条件付きアクセスを使っている組織は、単純にセキュリティの既定値をオンにしないよう注意が必要です。(Microsoft Learn)
セキュリティ連絡先を設定する
セキュリティ連絡先は、MicrosoftがCSPパートナーテナントのセキュリティ問題について連絡するための窓口です。公式情報では、セキュリティ関連の問題に責任を持つ個人またはグループの名前、メールアドレス、電話番号を登録する必要があると説明されています。(Microsoft Learn)
実務では、個人メールアドレスだけを登録するより、次のような運用にした方が安全です。
| 推奨設定 | 理由 |
|---|---|
| セキュリティ担当グループの共有メールボックス | 担当者不在・退職時にも通知を受け取れる |
| チケットシステムに連携するメールアドレス | 受付、担当割当、SLA管理がしやすい |
| 電話番号を定期確認 | 緊急連絡時に古い番号へ送られるリスクを減らせる |
| 四半期ごとの棚卸し | 組織変更や委託先変更を反映できる |
よくある失敗は、「登録済み」だが誰も見ていないメールボックスになっているケースです。Partner Centerの要件上は入力されていても、実際のインシデント対応が遅れれば、顧客保護やアラート対応の面で問題になります。
セキュリティアラートに24時間以内で対応する
直接請求パートナーやディストリビューターでは、Partner Centerに表示されたセキュリティアラートに平均24時間以内で対応することが求められます。Microsoftの公式説明では、アラートが表示された時点から、パートナーユーザーが状態や理由コードを更新するなどアラートに変更を加えた時点までが応答時間として測定され、平均応答時間は過去30日間のアクティビティに基づいて計算されます。(Microsoft Learn)
ここでの実務上のポイントは、単に「24時間以内に見る」ではなく、トリアージして状態を更新できる運用を作ることです。
| 確認項目 | 実務上の対応 |
|---|---|
| 通知先 | セキュリティ連絡先のメールが監視対象になっているか |
| 一次対応 | 誰がアラートを確認し、重大度を判断するか |
| 理由コード | 各アラートに理由コードを付ける運用になっているか |
| 休日・夜間 | 24時間以内対応を満たせる当番体制があるか |
| 記録 | チケット番号、対応者、判断理由を残しているか |
社内SLAは24時間ではなく、まず1時間以内の一次確認を目標にするのが現実的です。公式情報でも、24時間以内の対応に加え、1時間以内の対応を目標とする旨が示されています。(Microsoft Learn)
推奨要件も後回しにしすぎない
推奨要件は、CSP承認の必須要件ではないものの、セキュリティスコア改善や顧客保護の観点で重要です。公式ページでは、顧客テナントの管理者ロールを持つユーザーがMFAを使用することが推奨要件として示されています。(Microsoft Learn)
CSPパートナーは、自社テナントだけを守れば十分ではありません。顧客テナント側の管理者がMFA未設定の場合、顧客環境の侵害リスクが高まり、結果としてサポート負荷や信頼低下につながります。
Customer MFA statisticsでは、顧客ごとのMFA状況として、MFAが有効な管理者数、MFAが有効な非管理者数、総ユーザー数などを確認できます。顧客ごとに状態を検索できるため、MFA未対応の顧客を優先順位付けして案内する際に役立ちます。(Microsoft Learn)
開発者が確認すべきPartner Center APIの影響
開発者や運用自動化担当が特に注意すべきなのは、Partner Center APIのMFA要件です。Microsoftの2026年5月のお知らせでは、すべてのPartner Center app+user APIにMFAを適用しており、完全適用後は有効なMFA要求を含まないAPI呼び出しがブロックされ、401応答とエラーコード900421が返ると説明されています。(Microsoft Learn)
影響を受けやすいのは、次のような処理です。
| 処理例 | リスク |
|---|---|
| 顧客テナントのプロビジョニング | 新規顧客作成やリソース準備が失敗する |
| 請求・契約管理の連携 | 請求処理、契約更新、レポート取得が止まる |
| サポート用の運用ツール | 顧客情報取得や管理操作ができなくなる |
| PowerShellスクリプト | ユーザー資格情報を使う自動化がMFA要件で失敗する |
| コントロールパネル連携 | 顧客向けポータルからの操作が失敗する |
開発者は、まずPartner Center APIを呼び出している処理を棚卸ししてください。公式のお知らせでも、app+user API統合のインベントリ、トークン取得フローの検証、有効なMFA要求がエンドツーエンドで含まれるかの確認、サンドボックスや本番相当環境でのテスト、401および900421の監視が推奨されています。(Microsoft Learn)
API連携で確認するチェックリスト
| 確認項目 | 見るべきポイント |
|---|---|
| API利用箇所の棚卸し | アプリ、バッチ、PowerShell、外部ツール、社内ポータルをすべて洗い出す |
| 認証方式 | app-onlyなのか、app+userなのかを区別する |
| トークン取得フロー | MFA要求が正しく含まれるか確認する |
| エラーハンドリング | 401と900421を検知し、原因をログに残せるか |
| テスト環境 | 本番に近い権限・条件付きアクセスで検証する |
| 運用手順 | 認証失敗時に誰が復旧するか決めておく |
「本番で動いているから問題ない」と考えるのは危険です。強制適用のフェーズが進むと、ある日突然、請求連携や顧客管理のバッチが失敗する可能性があります。セキュリティ対応であると同時に、業務継続性の確認として扱うべきです。
MFA展開で失敗しやすいポイント
MFAは有効化そのものより、展開前の棚卸しで差が出ます。Microsoftのパートナー向けセキュリティ要件では、MFAを適用する前に、MFAを実行できないアカウント、先進認証をサポートしないアプリケーションやデバイス、自動化や統合で使われているユーザー資格情報を確認することが推奨されています。(Microsoft Learn)
セキュリティの既定値と条件付きアクセスを混在させようとする
セキュリティの既定値は手軽ですが、条件付きアクセスと同時には使えません。既に条件付きアクセスで細かい制御をしている組織では、セキュリティの既定値を有効化するのではなく、既存ポリシーで管理者MFAを確実にカバーする方が自然です。(Microsoft Learn)
判断基準は次のとおりです。
| 環境 | 向いている対応 |
|---|---|
| 小規模で複雑なアクセス制御が不要 | セキュリティの既定値を検討 |
| Microsoft Entra ID P1/P2を利用中 | 条件付きアクセスで管理者MFAを設計 |
| 既に条件付きアクセス運用がある | 既存ポリシーの対象漏れを確認 |
| 例外や拠点条件が多い | 条件付きアクセスで慎重に設計 |
レガシ認証や古いOfficeクライアントを確認していない
MFAを適用すると、IMAP、POP3、SMTPなど、MFAに対応しないレガシ認証を使うアプリやデバイスに影響する場合があります。Microsoftの公式ページでも、Outlookなどの接続問題を避けるため、Officeのバージョンや先進認証の有効化を確認することが重要とされています。(Microsoft Learn)
CSPテナントで古いOutlook、複合機のSMTP送信、監視ツールのメール送信、古い業務アプリを使っている場合は、MFA有効化前に影響範囲を確認してください。
サービスアカウントを人間の管理者のように使っている
公式情報では、サービスプリンシパルアカウントは「CSPテナントのすべての管理者にMFAを有効化する」要件の計算対象には含まれない一方、人間ベースのサービスアカウントはManaged Identitiesへ移行することが推奨されています。(Microsoft Learn)
実務で問題になりやすいのは、次のようなアカウントです。
| アカウント例 | 問題点 | 対応方針 |
|---|---|---|
| 共有の管理者アカウント | 誰が使ったか追跡しにくい | 個人アカウント＋最小権限へ移行 |
| バッチ用のユーザーアカウント | MFA適用で自動処理が止まる | アプリ認証やManaged Identitiesを検討 |
| 退職者名義の管理者 | 監査・復旧時に問題になる | 無効化または権限削除 |
| 緊急アクセスアカウント | 除外しすぎるとリスクが高い | 用途、保管、監査、使用手順を明確化 |
「昔から動いている自動化」は、最も見落とされやすいリスクです。API、PowerShell、請求連携、顧客管理ツールを担当する開発者に、早い段階で確認を依頼してください。
サードパーティMFAのMFA要求を検証していない
Okta、Ping、Duoなどの外部認証方法を使う環境では、Microsoft Entra IDやPartner Center側で期待されるMFA要求が正しく発行されているかが重要です。Microsoftのパートナー向けセキュリティ要件では、Microsoft以外のMFAソリューションで想定される要求が発行されない場合、ベンダーと協力して対応する必要があると説明されています。(Microsoft Learn)
サードパーティMFAを使っている組織は、「MFA画面が出ている」だけで判断せず、Partner CenterやAPI呼び出しで要件を満たすMFA要求として認識されているかをテストしてください。
管理者が最初に実施すべき確認手順
Partner Center セキュリティ要件ダッシュボードへの対応は、いきなり設定変更から始めると失敗しやすくなります。まず現状を可視化し、未対応項目をチケット化し、影響の大きい順に処理するのが安全です。
| 優先度 | 作業 | 担当 |
|---|---|---|
| 高 | Security requirements dashboardを開き、未完了の必須要件を確認 | Partner Center管理者 |
| 高 | 管理者ロールとMFA登録状況を確認 | Entra ID管理者 |
| 高 | セキュリティ連絡先を共有メールボックスまたはチケット連携先に更新 | セキュリティ運用担当 |
| 高 | セキュリティアラートの一次対応手順を作成 | SOC、運用担当 |
| 高 | Partner Center APIのapp+user連携を棚卸し | 開発者、SRE |
| 中 | 顧客テナント管理者のMFA状況を確認 | カスタマーサクセス、サポート |
| 中 | 古い管理者、共有アカウント、不要な特権ロールを削除 | 情シス、監査担当 |
| 中 | 条件付きアクセスやセキュリティの既定値の設計を見直す | セキュリティ管理者 |
最初の1日でやるべきことは、完璧なセキュリティ設計ではありません。未完了要件、対象管理者、API影響、通知先の4点を把握することです。これだけで、後続作業の優先順位が明確になります。
展開時の実務ポイント
MFAや条件付きアクセスは、設定を間違えると管理者自身が締め出される可能性があります。展開時は、次の流れで進めると安全です。
| フェーズ | 実施内容 | 注意点 |
|---|---|---|
| 棚卸し | 管理者、API、古いアプリ、通知先を確認 | 共有アカウントや退職者アカウントを見逃さない |
| 設計 | MFA方式、条件付きアクセス、緊急アクセスを決める | セキュリティの既定値と条件付きアクセスを混在させない |
| テスト | 少人数の管理者と代表的なAPI連携で検証 | 本番に近い条件で401や900421を確認する |
| 展開 | 全対象管理者へMFA登録を完了させる | 登録完了まで追跡する |
| 運用 | アラート対応、理由コード、SLAをチケット化 | 24時間以内対応を個人任せにしない |
| 監査 | 月次または四半期でスコアと未完了項目を確認 | Future requirementsも確認する |
特に、条件付きアクセスの変更は業務時間外に実施すればよいとは限りません。問題発生時に復旧できる担当者がいる時間帯に実施し、緊急アクセス手順を事前に確認しておくことが大切です。
よくある疑問
Microsoft Secure Scoreとは同じですか
同じものとして扱わない方が安全です。Partner Center セキュリティ要件ダッシュボードのセキュリティスコアは、CSPパートナー向けのセキュリティ要件に基づくスコアです。Microsoft 365 DefenderやEntra IDなどで表示される一般的なSecure Scoreとは、目的や評価対象が異なります。
MFAを有効化したのに未完了になる理由はありますか
あります。要件を満たすには、対象の管理者がMFAポリシーでカバーされているだけでなく、本人が追加の検証要素を登録し、MFAチャレンジを完了できる必要があります。緊急アクセスアカウントも対象に含まれるため、除外設定や未登録アカウントを確認してください。(Microsoft Learn)
間接リセラーもすべて同じ対応が必要ですか
管理者MFAとセキュリティ連絡先は、すべてのパートナーが確認すべき必須要件です。一方、24時間以内のセキュリティアラート対応については、公式情報で間接リセラーパートナーには適用されないと説明されています。ただし、アラート対応の運用を整えておくこと自体は、顧客保護と信頼維持の面で有効です。(Microsoft Learn)
APIを使っていなければ開発者対応は不要ですか
Partner Center APIやPowerShell、自動化ツールを一切使っていないなら、API起因の障害リスクは限定的です。ただし、社内で「誰かが作った請求バッチ」「顧客管理用の外部ツール」「販売管理システムとの連携」が動いているケースは珍しくありません。開発者または運用担当に、app+user API連携の有無を確認してください。
まず取るべき次のアクション
Partner Center セキュリティ要件ダッシュボードへの対応は、次の3つから始めるのが最短です。
1つ目は、Partner CenterでSecurity requirements dashboardを開き、必須要件の未完了項目を確認することです。2つ目は、Entra IDで管理者ロールとMFA登録状況を照合し、未登録・不要・共有の管理者アカウントをなくすことです。3つ目は、APIやPowerShellなどの自動化処理を棚卸しし、MFA要件により401や900421で停止しないかを検証することです。
この対応は、セキュリティ部門だけの作業ではありません。Partner Center管理者、Entra ID管理者、開発者、運用担当、顧客対応部門が同じチェックリストを見て進めることで、CSP承認維持と顧客環境の保護を両立できます。
コメント