パートナーのセキュリティ要件に関する一般的な質問

CSP プログラムのすべてのパートナー (直接請求、間接プロバイダー、間接リセラー)、アドバイザー、およびコントロール パネル ベンダーは、要件を満たしている必要があります。

1. すべてのユーザーに MFA を適用する

   CSP プログラムのパートナー、アドバイザー、およびコントロール パネル ベンダーはすべて、パートナー テナント内のすべてのユーザーに対して MFA を適用する必要があります。

   その他の考慮事項:

   • 間接プロバイダーは、間接リセラーと協力してパートナー センターにオンボードする必要があります (まだ行っていない場合)。
   • Microsoft Entra 多要素認証は、Microsoft Entra セキュリティの既定値を通じて、パートナー テナントのユーザーが無償で利用できます。この認証方法は、時間ベースのワンタイム パスワード (TOTP) をサポートする認証アプリケーションの唯一の検証方法です。
   • 電話やテキスト メッセージなどの他の方法が必要な場合は、 Microsoft Entra P1 または P2 SKU を介して他の検証方法を使用できます。
   • パートナーは、Microsoft の商用クラウド サービスにアクセスするときに、個々のアカウント単位でサード パーティの MFA ソリューションを使用することもできます。

2. セキュリティで保護されたアプリケーション モデル フレームワークを採用する

   任意の API (Azure Resource Manager、Microsoft Graph、パートナー センター API など) を使用してカスタム統合を開発したパートナー、または PowerShell などのツールを使用してカスタム自動化を実装したパートナーは、 Secure Application Model フレームワーク を採用して Microsoft クラウド サービスと統合する必要があります。 これを行わないと、MFA のデプロイによって中断が発生する可能性があります。

   次のリソースは、モデルを採用する方法の概要とガイダンスを提供します。

   • セキュリティで保護されたアプリケーション モデルの概要
   • パートナー センター: セキュリティで保護されたアプリケーション モデル ガイド
   • CSP プログラムでのパートナー: セキュリティで保護されたアプリケーション モデルを有効にするための .NET サンプル コード
   • パートナー センターの認証に関するドキュメント
   • パートナー センターの PowerShell 多要素認証 (MFA) ドキュメント

   セキュア アプリケーション モデル フレームワークの導入についてコントロール パネルを使用する場合は、ベンダーにお問い合わせください。

   コントロール パネル ベンダーは、コントロール パネル ベンダーとしてパートナー センターにし、すぐにこの要件の実装を開始する必要があります。 Partner Center: Secure Application Model framework を参照してください。

   コントロール パネル ベンダーは、資格情報ではなく CSP パートナーの同意を受け入れて管理し、既存のすべての CSP パートナーの資格情報を消去する必要があります。

MFA は、複数の必要なセキュリティと検証手順を使用して個人を認証するためのセキュリティ メカニズムです。 それは、次の認証方法のうち 2 つ以上を必須にすることで機能します。

• ユーザーが知っている情報 (一般にパスワード)
• ユーザーの所持品 (電話など、容易には複製できない、信頼済みのデバイス)
• ユーザー自身 (生体認証)

Microsoft は、Microsoft Entra セキュリティの既定値を実装することにより、MFA を無償で提供します。 このバージョンの MFA を使用して利用できる認証オプションは、認証アプリケーションだけです。

• 電話または SMS メッセージが必要な場合は、 Microsoft Entra P1 または P2 ライセンスを購入する必要があります。
• または、サード パーティのソリューションを利用して、パートナー テナント内の各ユーザーに MFA を提供することもできます。 その場合、MFA ソリューションが適用され、準拠していることを確認するのはユーザーの責任です。

パートナー テナントのユーザーは、Microsoft 商用クラウド サービスにアクセスするときに MFA を使用して認証する必要があります。 サードパーティのソリューションを使用して、これらの要件を満たすことができます。 Microsoft では、Microsoft Entra ID との互換性のための検証テストを独立 ID プロバイダーには現在提供していません。 製品の相互運用性をテストするには、 Microsoft Entra ID プロバイダーの互換性に関するドキュメントを参照してください。

はい。 CSP プログラムまたは Advisor プログラムに関連付けられている Microsoft Entra テナントごとに MFA を適用する必要があります。 Microsoft Entra ID P1 または P2 ライセンスを購入するには、各 Microsoft Entra テナントのユーザーの Microsoft Entra ID ライセンスを購入する必要があります。

はい。 各ユーザーには MFA が適用されている必要があります。 ただし、Microsoft Entra セキュリティの既定値を使用している場合は、その機能によってすべてのユーザー アカウントに MFA が適用されるため、他のアクションは必要ありません。 セキュリティの既定値を有効にすると、ユーザー アカウントが MFA に準拠し、MFA が適用されたときに影響を受けないように、無料で簡単に行うことができます。

直接請求クラウド ソリューション プロバイダー パートナーは、パートナー テナント内の各ユーザーに対して MFA を適用する必要があります。

はい。 すべての間接リセラーは、パートナー テナントの各ユーザーに対して MFA を適用する必要があります。 間接リセラーは MFA を有効にする必要があります。

はい。 このセキュリティ要件は、パートナー管理者ユーザーとパートナー テナントのエンド ユーザーを含むすべてのユーザーに対して行われます。

MFA ベンダーとソリューションを確認するときは、選択したソリューションが Microsoft Entra ID と互換性があることを確認する必要があります。

Microsoft では、Microsoft Entra ID との互換性のための検証テストを独立 ID プロバイダーには現在提供していません。 製品の相互運用性をテストする場合は、 Microsoft Entra ID プロバイダー互換性ドキュメントを参照してください。

詳細については、 Microsoft Entra フェデレーション互換性リストを参照してください。

Microsoft Entra セキュリティの既定値機能を有効にする必要があります。 または、フェデレーションを使用するサード パーティのソリューションを使用することもできます。

いいえ。 これらのセキュリティ要件を満たしても、顧客の管理方法には影響しません。 代理管理操作を実行する機能は中断されません。

いいえ。 顧客の Microsoft Entra テナントの各ユーザーに対して MFA を適用する必要はありません。 ただし、各顧客と協力して、ユーザーを保護する最善の方法を決定することをお勧めします。

いいえ。 パートナー テナント内のすべてのユーザー (サービス アカウントを含む) は、MFA を使用して認証する必要があります。

はい。 つまり、統合サンドボックス テナントのユーザーに適切な MFA ソリューションを実装する必要があります。 MFA を提供するには、Microsoft Entra セキュリティの既定値を実装することをお勧めします。

Microsoft Entra テナントから誤ってロックアウトされないように、1 つまたは 2 つの緊急アクセス アカウントを作成することをお勧めします。 パートナーのセキュリティ要件に関しては、各ユーザーが MFA を使用して認証を行う必要があります。 この要件は、緊急アクセス アカウントの定義を変更する必要があるということです。 MFA にサードパーティのソリューションを使用するアカウントである可能性があります。

いいえ。 サード パーティのソリューションを使用している場合は、Active Directory フェデレーション サービス (ADFS) を使用する必要はありません。 ソリューションのベンダーと協力して、ソリューションの要件を判断することをお勧めします。

いいえ。

はい。 条件付きアクセスを使用して、パートナー テナントでサービス アカウントを含む各ユーザーに MFA を適用できます。 ただし、パートナーであるという高い特権の性質を考えると、各ユーザーが 1 つの認証ごとに MFA チャレンジを受けられるようにする必要があります。 つまり、MFA の要件を回避する条件付きアクセスの機能を使用することはできません。

いいえ。 Microsoft Entra Connect によって使用されるサービス アカウントは、パートナーのセキュリティ要件の影響を受けることはありません。 MFA の適用の結果として Microsoft Entra Connect で問題が発生した場合は、Microsoft サポートにテクニカル サポートリクエストを開きます。

Microsoft では、多要素認証を使用する クラウド ソリューション プロバイダー (CSP) パートナーと コントロール パネル ベンダー (CPV) を認証するための、セキュリティで保護されたスケーラブルなフレームワークを導入しました。 詳細については、セキュア アプリケーション モデル ガイドを参照してください。 任意の API (Azure Resource Manager、Microsoft Graph、パートナー センター API など) を使用してカスタム統合を開発した、または PowerShell などのツールを使用してカスタム自動化を実装したすべてのパートナーは、 Secure Application Model フレームワーク を採用して Microsoft クラウド サービスと統合する必要があります。

Microsoft では、多要素認証を使用するクラウド ソリューション プロバイダー (CSP) パートナーと コントロール パネル ベンダー (CPV) を認証するための、セキュリティで保護されたスケーラブルなフレームワークを導入しています。 詳細については、セキュア アプリケーション モデル ガイドを参照してください。

任意の API (Azure Resource Manager、Microsoft Graph、パートナー センター API など) を使用してカスタム統合を開発したパートナー、または PowerShell などのツールを使用してカスタム自動化を実装したすべてのパートナーは、Microsoft クラウド サービスと統合するために、 Secure Application Model フレームワーク を採用する必要があります。 これを行わないと、MFA のデプロイによって中断が発生する可能性があります。

次のリソースは、モデルの導入方法に関する概要とガイダンスを提供します。

• セキュリティで保護されたアプリケーション モデルの概要
• パートナー センター: セキュリティで保護されたアプリケーション モデル ガイド
• CSP プログラムでのパートナー: セキュリティで保護されたアプリケーション モデルを有効にするための .NET サンプル コード
• パートナー センターの認証に関するドキュメント
• パートナー センターの PowerShell 多要素認証 (MFA) ドキュメント

コントロール パネルを使用している場合は、セキュリティで保護されたアプリケーション モデル フレームワークの導入についてベンダーに相談する必要があります。

コントロール パネル ベンダーは、コントロール パネル ベンダーとしてパートナー センターにし、すぐにこの要件の実装を開始する必要があります。

Partner Center: Secure Application Model framework を参照してください。 コントロール パネル ベンダーは、資格情報ではなく CSP パートナーの同意を受け入れて管理し、既存のすべての CSP パートナーの資格情報を消去する必要があります。

すべてのユーザー アカウントに多要素認証を適用することで、非対話形式で実行することを意図した自動化または統合が影響を受けます。 パートナー のセキュリティ要件では、パートナー センター API のセキュリティで保護されたアプリケーション モデルを有効にする必要がありますが、自動化と統合による認証の 2 番目の要素の必要性に対処するために使用できます。

自動化が非対話形式で実行され、認証にユーザー資格情報に依存している場合は、セキュリティで保護されたアプリケーション モデルを実装する必要があります。 このフレームワークを実装する方法については、Partner Center PowerShell のセキュリティで保護されたアプリケーション モデルに関する記事をご覧ください。

最小限の特権のアクセス許可が割り当てられているサービス アカウントを使用することをお勧めします。 パートナー センター API に関しては、Sales エージェントまたは管理エージェントロールに割り当てられているアカウントを使用する必要があります。

そうするとリスクが軽減されるため、最小限の特権を持つ ID を使用することをお勧めします。 グローバル管理者特権を持つアカウントを使用することはお勧めしません。これは、必要以上のアクセス許可を提供するためです。

コントロール パネル ベンダー (CPV) ソリューションを使用して クラウド ソリューション プロバイダー (CSP) プログラムで取引を行うパートナーの場合は、CPV に相談する必要があります。

コントロール パネル ベンダーは、パートナー センター API と統合するために CSP パートナーが使用するアプリを開発する独立系ソフトウェア ベンダーです。 コントロール パネル ベンダーは、パートナー センターまたは API に直接アクセスできる CSP パートナーではありません。 詳細な説明については、 Partner Center: Secure Applications Model ガイドで確認できます。

コントロール パネル ベンダー (CPV) として登録するには、「CSP パートナー システムとパートナー センター API との統合を支援するためにコントロール パネル ベンダーとして登録する」のガイドラインに従う必要があります。

パートナー センターに登録してアプリケーションを登録すると、パートナー センター API にアクセスできるようになります。 新しい CPV の場合は、パートナー センターの通知でサンドボックス情報を受け取ります。 Microsoft CPV としての登録を完了し、CPV 契約に同意すると、次のことができます。

• マルチテナント アプリケーションを管理する (Azure portal にアプリケーションを追加し、パートナー センターでアプリケーションを登録および登録解除する)。

  Note

  CPV は、Partner Center API の承認を取得するには、パートナー センターでアプリケーションを登録する必要があります。 Azure portal にアプリケーションを追加するだけでは、CPV アプリケーションはパートナー センター API に対して承認されません。

• CPV プロファイルを表示および管理する。

• CPV 機能にアクセスする必要があるユーザーを表示および管理する。 CPV には、グローバル管理者のみがロールを持つことができます。

いいえ。 セキュア アプリケーション モデル ガイドのガイドラインに従う必要があります。

はい。 更新トークンは、MFA が適用されていないアカウントを使用して生成できます。 ただし、これは行わないようにしてください。 MFA が有効になっていないアカウントを使用して生成されたトークンは、MFA の要件により、リソースにアクセスできません。

セキュリティ モデル ガイドに従って、新しいセキュリティ要件に準拠しながらその方法について詳しく説明します。 .NET のサンプル コードは、パートナー センターの DotNet サンプル - セキュア アプリケーション モデルに関するページ、Java のサンプル コードは、パートナー センターの Java のサンプルに関するページを参照してください。

CPV は、CPV としての登録に関連付けられているテナントに Microsoft Entra アプリケーションを作成する必要があります。

ユーザー資格情報はアクセス トークンの要求に使用されないため、アプリ専用認証は影響を受けません。 ユーザーの資格情報が共有されている場合は、コントロール パネル ベンダー (CPV) はセキュリティで保護されたアプリケーション モデル フレームワークを採用し、所有している既存のパートナー資格情報を消去する必要があります。

いいえ。 コントロール パネルベンダー パートナーは、アプリのみの認証スタイルを利用して、パートナーに代わってアクセス トークンを要求することはできません。 アプリとユーザー認証のスタイルが利用される、セキュリティで保護されたアプリケーション モデルを実装する必要があります。

クラウド ソリューション プロバイダー (CSP) プログラムに参加するすべてのパートナー、コントロール パネル ベンダー (CPV)、アドバイザーは、準拠を維持し、パートナーのセキュリティ要件を実装する必要があります。

より多くの保護を提供するために、Microsoft は、パートナーが多要素認証 (MFA) 検証を管理して未承認のアクセスを防ぐことで、テナントとその顧客を保護するのに役立つセキュリティ保護のアクティブ化を開始しました。

すべてのパートナーテナントに対するパートナーの代理管理 (AOBO) 機能のアクティブ化は既に完了しています。 パートナーと顧客をさらに保護するために、CSP でパートナー センター トランザクションのアクティブ化を開始し、パートナーが ID 盗難関連のインシデントからビジネスと顧客を保護できるようにします。

詳細については、「 パートナー テナントの多要素認証 (MFA) の管理 」ページを参照してください。

リソースにアクセスするアカウントが多要素認証でチャレンジされたことを検証するために、 認証方法のリファレンス 要求を確認して、MFA が一覧表示されているかどうかを確認します。 サードパーティ ソリューションによっては、この要求が発行されないか、MFA 値が含まれていない場合があります。 要求が見つからない場合、または MFA 値が一覧にない場合は、認証されたアカウントが多要素認証でチャレンジされたかどうかを判断する方法はありません。 サード パーティソリューションのベンダーと協力して、ソリューションが認証方法参照要求を発行するために実行するアクションを決定する必要があります。

サード パーティのソリューションが予想される要求を発行しているかどうかがわからない場合は、「 パートナー セキュリティ要件のテストを参照してください。

パートナーのセキュリティ要件に対する技術的な適用は、認証されたアカウントが多要素認証に対してチャレンジされているかどうかを確認します。 アカウントがチェックされていない場合は、サインイン ページにリダイレクトされ、再認証を求められます。

エクスペリエンスとガイダンスの詳細については、「 パートナー テナントの多要素認証 (MFA) の管理を参照してください。

ドメインがフェデレーションされていないシナリオでは、認証に成功すると、多要素認証を設定するように求められます。 それが完了すると、AOBO を使用して顧客を管理できるようになります。 ドメインがフェデレーションされているシナリオでは、アカウントが多要素認証でチャレンジされていることを確認する必要があります。

Microsoft Entra ID "ベースライン" ポリシーは削除され、置き換えられます "セキュリティの既定値" は、ユーザーと顧客にとってより包括的な保護ポリシーセットです。 セキュリティの既定値 を使用すると、組織を個人情報盗難関連のセキュリティ攻撃から保護する上で役立ちます。

ベースライン ポリシーからセキュリティの既定値ポリシーに移行していない場合、または他の MFA 実装オプション 移行していない場合は、ベースライン ポリシーの廃止により、多要素認証 (MFA) の実装が削除されます。 MFA で保護された操作を実行するパートナー テナントのユーザーは、MFA の検証を完了するように要求されます。 詳細なガイダンスについては、「 パートナー テナントの多要素認証の管理を参照してください。

準拠を維持し、中断を最小限に抑えるには、次の手順を使用します。

• セキュリティの既定値への移行
  • セキュリティの既定ポリシーは、パートナーが MFA を実装する上で選択可能なオプションの1つです。 基本レベルのセキュリティが追加料金なしで有効になります。
  • Microsoft Entra ID を使用して組織の MFA を有効にする方法と、 セキュリティの既定の主な考慮事項を確認。
  • ビジネス ニーズを満たす場合は、セキュリティの既定ポリシーを有効にします。
• 条件付きアクセスへの移行
  • セキュリティの既定ポリシーでニーズに対応できない場合は、条件付きアクセスを有効にします。 詳細については、Microsoft Entra の条件付きアクセスに関するドキュメントを参照してください。

• Partner のセキュリティ要件を確認する: ステップ バイ ステップ ガイド。
• 質問とフィードバックを Partner Center セキュリティ ガイダンス グループに送信します。
• 今後予定されているパートナーの業務時間とウェビナーに参加してください。 詳細なスケジュールとリソースは、 Partner Community ページで確認。

• セキュリティで保護されたアプリケーション モデルの概要
• パートナー センター: セキュリティで保護されたアプリケーション モデル ガイド
• CSP プログラムでのパートナー: セキュリティで保護されたアプリケーション モデルを有効にするための .NET サンプル コード
• パートナー センターの認証に関するドキュメント
• パートナー センターの PowerShell 多要素認証 (MFA) ドキュメント

セキュリティ要件を満たすサポート リソースの場合:

• パートナー向けの高度なサポート (ASfP) がある場合は、サービス アカウント マネージャーにお問い合わせください。
• Premier Support for Partners 契約 (PSfP) については、サービス アカウント マネージャーとテクニカル アカウント マネージャーにお問い合わせください。

Microsoft Entra ID のテクニカル 製品サポート オプションは、Microsoft AI クラウド パートナー プログラムの特典を通じて利用できます。 アクティブな ASfP または PSfP サブスクリプションにアクセスできるパートナーは、関連するアカウント マネージャー (SAM/TAM) と連携して、使用可能な最適なオプションを理解できます。

MFA の問題が原因でアクセスできなくなった場合は、テナントのセキュリティ管理者に問い合わせてください。 内部 IT 部門は、セキュリティ管理者が誰であるかを通知できます。

パスワードを忘れた場合は、「 サインインできない 」を参照してください。

一般的な技術的問題に関する情報については、「パートナー センターまたはパートナー センター API を使用するパートナー向けの、パートナーのセキュリティ要件」を参照してください