次の方法で共有


パートナー テナントに多要素認証 (MFA) を義務付ける

適切なロール: 管理エージェント |販売エージェント |ヘルプデスク エージェント |課金管理者 |セキュリティ管理者

セキュリティの強化と継続的なセキュリティとプライバシー保護は、Microsoft の最優先事項の 1 つであり、パートナーが顧客とテナントを保護できるように支援し続けています。

パートナーがビジネスや顧客を ID の盗難や不正アクセスから保護できるように、パートナー テナントのセキュリティ保護を強化しました。 これらのセーフガードでは、MFA が義務付けおよび検証されます。 MFA の管理は、パートナーが資格情報の侵害から顧客リソースへのアクセスをセキュリティで保護するのに役立ちます。


この記事では、パートナー センターでの多要素認証 (MFA) の管理に関する詳細な例とガイダンスを示します。

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

パートナーは、パートナー テナント内のすべてのユーザー アカウント (ゲスト ユーザーを含む) に対して MFA を強制する必要があります。 ユーザーは、次の領域の MFA 検証を完了する必要があります。

パートナー センター

パートナー センターの一部のページは MFA で保護されています。次に例を示します。

  • Customers タブのすべてのページ (つまり、https://partner.microsoft.com/commerce/*で始まる URL を持つすべてのページ)
  • Support>Customer 要求 タブのすべてのページ (たとえば、https://partner.microsoft.com/dashboard/v2/support/customers/*で始まる URL でアクセスされたすべてのページ)
  • [ビリング]タブのすべてのページ

Overview ページや Service Health Status チェック ページなど、パートナー センターのその他のページでは MFA は必要ありません。


次の表は、これらの MFA で保護されたページにアクセスする権限を持つユーザーの種類を示しています (この機能の影響を受けます)。

MFA 保護対象のページ 管理エージェント 販売エージェント ヘルプデスク エージェント セキュリティ管理者 課金管理者
Customers タブのすべてのページ x x x
Support > Customer requests タブのすべてのページ x x
課金 ページ x x x
セキュリティ ワークスペース x x

これらのページにアクセスするには、まず MFA 検証を完了する必要があります。

サポートされている MFA オプション

  • Microsoft を使用するパートナーは、Microsoft Entra 多要素認証をサポートしました。 詳細については、「 Microsoft Entra 多要素認証を有効にする複数の方法 (MFA がサポートされています) を参照してください。
  • 統合 MFA フェデレーション認証を実装したパートナー。 これらのパートナー ユーザーは、パートナー センターにアクセスし、GDAP を使用して顧客を管理できます。 AD FS で使用可能な MFA オファリングを備えた統合 MFA プロバイダー: AD FS の 構成方法を参照してください。

重要

パートナーは、Microsoft Entra ID の統合 MFA 要求と互換性のある認証プロバイダーを使用する必要があります。 統合要求は、認証時に提供される実際の資格情報の種類を示します。 パートナーは、GDAP を使用して顧客テナントを管理するために、統合 MFA を使用する必要があります。

パートナー センターおよび API

次のパートナー センター API では、App+User アクセスと Microsoft Entra ID サポート MFA が必要です。

  • 検出 (価格、カタログ、プロモーション)
  • トランザクションと管理
  • 請求と調整
  • 委任されたアクセスまたは AOBO を使って顧客を管理する
  • ユーザーとライセンスの割り当て (DAP のみ)
  • ユーザーとライセンスの割り当て (GDAP あり)
  • 詳細な管理者リレーションシップ要求とアクセスの割り当て

パートナーは次のオプションを使用できます。

検証の例

パートナー センターでの検証のしくみを説明するには、次の例を検討してください。

例 1: パートナーが Microsoft Entra 多要素認証を実装している

  1. Alejandra は Contoso という CSP で動作します。 Contoso は、Microsoft Entra 多要素認証を使用して、Contoso パートナー テナントのすべてのユーザーに対して MFA を実装しました。

  2. Alejandra は新しいブラウザー セッションを開始し、パートナー センターの概要ページ (MFA で保護されていません) に移動します。 パートナー センターは、サインインするために Alejandra を Microsoft Entra ID にリダイレクトします。

  3. Contoso による既存の Microsoft Entra 多要素認証のセットアップにより、MFA 検証を完了するには Alejandra が必要です。 サインインと MFA の検証が成功すると、Alejandra はパートナー センターの概要ページにリダイレクトされます。

  4. Alejandra は、パートナー センターで MFA で保護されたページのいずれかにアクセスしようとします。 以前にサインイン中に Alejandra が MFA 検証を完了したため、Alejandra は MFA で保護されたページにアクセスできます。MFA 検証を再度実行する必要はありません。

例 2: パートナーが ID フェデレーションを使用して Microsoft 以外の MFA を実装している

  1. Prashob は Wingtip という CSP に勤めています。 Wingtip は、Microsoft 以外の MFA を使用して Wingtip パートナー テナントのすべてのユーザーに対して MFA を実装しました。これは、ID フェデレーションを介して Microsoft Entra ID と統合されています。

  2. Prashob は新しいブラウザー セッションを開始し、パートナー センターの概要ページ (MFA で保護されていません) に移動します。 パートナー センターは、サインインするために Prashob を Microsoft Entra ID にリダイレクトします。

  3. Wingtip には ID フェデレーションが設定されているため、Microsoft Entra ID は Prashob をフェデレーション ID プロバイダーにリダイレクトして、サインインと MFA の検証を完了します。 サインインと MFA の検証が成功すると、Prashob は Microsoft Entra ID にリダイレクトされ、パートナー センターの概要ページにリダイレクトされます。

  4. Prashob は、パートナー センターの MFA で保護されたページのいずれかにアクセスしようとします。 Prashob は以前のサインイン時に MFA 検証を既に完了しているため、MFA 検証を再度実行する必要なく、MFA で保護されたページにアクセスできます。

  5. その後、Prashob はサービス管理ページに移動し、Contoso の Microsoft Entra ID にユーザーを追加します。 Prashob は強力な認証で Entra と互換性のある認証プロバイダーを使用しているため、問題なく顧客テナントにアクセスできます。

この例の Prashob の推奨事項は、Microsoft Entra 多要素認証ソリューションまたは Entra 互換認証プロバイダーを使用して、顧客のテナントを正常に管理できるようにすることです。

例 3: パートナーが MFA を実装していない

  1. Fabrikam という CSP パートナーは、まだ MFA を実装していません。 Microsoft では、Microsoft Entra ID でサポートされる MFA ソリューションを実装することをお勧めします。

  2. John は Fabrikam に勤めています。 Fabrikam は、Fabrikam パートナー テナントの下のユーザーに対して MFA を実装していません。

  3. John は新しいブラウザー セッションを開始し、パートナー センターの概要ページに移動します (MFA で保護されていません)。 パートナー センターは、サインインするために John を Microsoft Entra ID にリダイレクトします。

  4. サインインに成功すると、John は MFA 検証を完了していないため、パートナー センターの概要ページにリダイレクトされます。

  5. John は、パートナー センターの MFA で保護されたページのいずれかにアクセスしようとします。 John は MFA 検証を完了していないため、パートナー センターは John を Microsoft Entra ID にリダイレクトして MFA 検証を完了します。 John が MFA を完了する必要があるのはこれが初めてであるため、John は MFA の登録 要求されます。 MFA 登録と MFA 検証が成功すると、John は MFA で保護されたページにアクセスできます。

  6. 別の日に、Fabrikam が任意のユーザーの MFA を実装する前に、John は新しいブラウザー セッションを開始し、パートナー センターの概要ページ (MFA で保護されていない) に移動します。 パートナー センターは、MFA プロンプトなしでサインインするために John を Microsoft Entra ID にリダイレクトします。

  7. John は、パートナー センターの MFA で保護されたページのいずれかにアクセスしようとします。 John は MFA 検証を完了していないため、パートナー センターは John を Microsoft Entra ID にリダイレクトして MFA 検証を完了します。 John は MFA を登録しているため、今回は MFA 検証の完了のみを求められます。

例 4: パートナーが Microsoft Entra と互換性のない Microsoft 以外の MFA を実装している

  1. Trent は Wingtip という CSP に勤めています。 Wingtip は、条件付きアクセスを使用するクラウド環境で Microsoft 以外の MFA を使用して、Wingtip パートナー テナントのすべてのユーザーに対して MFA を実装しました。

  2. Trent は新しいブラウザー セッションを開始し、パートナー センターの概要ページ (MFA で保護されていません) に移動します。 パートナー センターは、サインインするために Trent を Microsoft Entra ID にリダイレクトします。

  3. Wingtip では、Microsoft Entra ID と互換性のない、強力な認証を持たない Microsoft 以外の MFA 統合が使用されているため、Trent はパートナー センター内のすべての MFA で保護されたページと API へのアクセスをブロックされます。

Trent は MFA で保護されたページにアクセスするため、MFA で保護されたページにアクセスするには、強力な認証を MFA に提示する必要があります。

パートナーは、認証時に提供される実際の資格情報の種類を反映して、アクセス トークン要求参照の資格情報メソッド要求 ("amr 要求" - Microsoft ID プラットフォーム) をサポートする Microsoft Entra ID と互換性のある認証プロバイダーを使用する必要があります。

MICROSOFT Entra ID と互換性のある MFA をすぐに実装して、テナントのセキュリティ ベースラインを上げることを CSP パートナーに強くお勧めします。

パートナー センター API

パートナー センター API では、アプリのみの認証とアプリケーションとユーザー (アプリ + ユーザー) 認証の両方がサポートされます。

アプリ + ユーザー認証を使用する場合、パートナー センターでは MFA 検証が必要です。 具体的には、パートナー アプリケーションがパートナー センターに API 要求を送信するときに、要求の承認ヘッダーにアクセス トークンを含める必要があります。

Note

セキュア アプリケーション モデル フレームワークは、パートナー センター API を呼び出す際に Microsoft Azure MFA アーキテクチャを介して CSP パートナーおよび CPV を認証するためのスケーラブルなフレームワークです。 サービス自動化で MFA を使用する場合は、このフレームワークを実装する必要があります。

パートナー センターが App+User 認証を使用して取得したアクセス トークンを含む API 要求を受信すると、パートナー センター API は、Authentication Method Reference (AMR)要求に MFA 値が存在するか確認します。 JWT デコーダーを使用すると、アクセス トークンに、予測される認証方法参照 (AMR) 値が含まれているかどうかを検証できます。

{
  "aud": "https://api.partnercenter.microsoft.com",
  "iss": "https://sts.windows.net/df845f1a-7b35-40a2-ba78-6481de91f8ae/",
  "iat": 1549088552,
  "nbf": 1549088552,
  "exp": 1549092452,
  "acr": "1",
  "amr": [
    "pwd",
    "mfa"
  ],
  "appid": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "appidacr": "0",
  "family_name": "Adminagent",
  "given_name": "CSP",
  "ipaddr": "127.0.0.1",
  "name": "Adminagent CSP",
  "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  "scp": "user_impersonation",
  "tenant_region_scope": "NA",
  "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee",
  "unique_name": "Adminagent.csp@testtestpartner.onmicrosoft.com",
  "upn": "Adminagent.csp@testtestpartner.onmicrosoft.com",
  "ver": "1.0"
}
  • この値が存在する場合、パートナー センターは MFA 検証が完了していると判断し、API 要求を処理します。

  • 値が存在しない場合、パートナー センター API は次の応答で要求を拒否します。

    HTTP/1.1 401 Unauthorized - MFA required
    Transfer-Encoding: chunked
    Request-Context: appId=cid-v1:11112222-bbbb-3333-cccc-4444dddd5555
    WWW-Authenticate: Bearer error="invalid_token"
    Date: Thu, 14 Feb 2019 21:54:58 GMT
    

パートナー センター API を呼び出す場合、アプリ専用アクセス トークンは、顧客テナントでの GDAP ロールの割り当てを必要としない操作でのみサポートされます。

ベスト プラクティスの詳細については、「 API の認証と承認 - 概要」を参照してください。

パートナー代理管理

パートナー テナントは、きめ細かい委任された管理者特権 (GDAP) を使用して、Microsoft Online Services ポータル (portal.azure.com または admin.microsoft.com)、コマンド ライン インターフェイス (CLI)、API (App+ User 認証を使用) を使用して顧客リソースを管理する必要があります。 詳細については、 サポートされている MFA オプションを参照してください。

サービス ポータルの使用

CSP パートナーは、 Partner Center ポータルから サービス管理インターフェイスを使用して顧客を管理できます。 パートナーは顧客に移動し、[サービス管理] を選択して、顧客の特定のサービスを管理できます。 パートナーは、 GDAP ロール ガイダンスに従って 顧客を管理するための適切な最小特権 GDAP ロールを取得する必要があります。

パートナー委任管理者特権 (Admin-On-Behalf-Of) を使用して Microsoft Online Services ポータルにアクセスして顧客リソースを管理する場合、これらのポータルの多くは、顧客の Microsoft Entra テナントを認証コンテキストとして設定して、パートナー アカウントを対話形式で認証する必要があります。 顧客テナントにサインインするには、パートナー アカウントが必要です。

Microsoft Entra ID 認証では、MFA を必要とするポリシーがある場合、ユーザーは MFA 検証を完了する必要があります。 パートナー アカウントがマネージド ID またはフェデレーション ID のどちらであるかに応じて、次の 2 つのユーザー エクスペリエンスが考えられます。

  • パートナー アカウントが 管理 ID の場合、Microsoft Entra ID はユーザーに MFA 検証の完了を直接求めます。 パートナー アカウントが以前に Microsoft Entra ID で MFA に登録されていない場合、ユーザーは最初に MFA 登録 完了するように求められます

  • パートナー アカウントが federated ID の場合、エクスペリエンスは、パートナー管理者が Microsoft Entra ID でフェデレーションを構成した方法によって異なります。 Microsoft Entra ID でフェデレーションを設定する場合、パートナー管理者は、フェデレーション ID プロバイダーが MFA をサポートしているかどうかを Microsoft Entra ID に指定できます。

    • その場合、Microsoft Entra ID はユーザーをフェデレーション ID プロバイダーにリダイレクトして MFA 検証を完了します。
    • そうでない場合、Microsoft Entra ID はユーザーに MFA 検証の完了を直接求めます。 パートナー アカウントが以前に Microsoft Entra ID で MFA に登録されていない場合、ユーザーは最初に MFA 登録 完了するように求められます

全体的なエクスペリエンスは、エンド カスタマー テナントが管理者に MFA を実装したシナリオに似ています。 たとえば、顧客テナントで Microsoft Entra セキュリティの既定値が有効になっている場合、管理者エージェントやヘルプデスク エージェントなど、MFA 検証を使用して顧客テナントにサインインするには管理者権限を持つすべてのアカウントが必要です。

テスト目的で、パートナーは顧客テナントで Microsoft Entra セキュリティの既定値 を有効にしてから、パートナーの詳細な委任された管理特権 (GDAP) を使用して顧客テナントにアクセスしてみてください。

Note

一部の Microsoft Online Service ポータルでは、GDAP を使用して顧客リソースにアクセスするときにパートナー アカウントが顧客テナントにサインインする必要はありません。 代わりに、パートナー アカウントのみがパートナー テナントにサインインする必要があります。 1 つの例は Exchange 管理センターです。 時間の経過と同時に、これらのポータルでは、GDAP を使用するときにパートナー アカウントが顧客テナントにサインインする必要があります。

MFA 登録エクスペリエンス

MFA 検証中に、パートナー アカウントが MFA に登録されていない場合、Microsoft Entra ID はユーザーに最初に MFA 登録を完了するように求めます。

Microsoft Authenticator メソッドの詳細を確認します。

MFA 登録の最初の手順のスクリーンショット。

ユーザーが Next を選択すると、確認方法の一覧から選択するように求められます。

MFA 登録の 2 番目の手順のスクリーンショット。

登録が成功した後、ユーザーは選択した検証方法を使用して MFA 検証を完了する必要があります。

一般的な問題

要求が有効かどうかを理解するには、他のパートナーによって報告された一般的な問題の一覧を確認します。

問題 1: パートナーエージェントに MFA を実装する時間がパートナーに増える必要がある

あるパートナーが、顧客リソースを管理するためにパートナー代理管理特権を使用した Microsoft Online Services ポータルへのアクセスを必要としているパートナー エージェントに対する MFA の実装をまだ開始していないか、またはその最中です。 このパートナーには、MFA 実装を完了するためのさらに多くの時間が必要です。 これは、技術的な例外の有効な理由ですか?

回答 : いいえ。 パートナーは、中断を回避するために、ユーザーに MFA を実装する計画を立てる必要があります。

Note

パートナーがパートナー エージェントの MFA を実装していない場合でも、パートナー エージェントは、顧客テナントへのサインイン時にプロンプトが表示されたときに MFA 登録と MFA 検証を完了できる場合、パートナー代理管理特権を使用して Microsoft Online Services ポータルに引き続きアクセスできます。 MFA 登録を完了しても、そのユーザーに対して MFA が自動的に有効になるわけではありません。

問題 2: パートナーは顧客を管理するためにアクセスする必要がないため、MFA を実装していません

パートナーには、パートナー代理管理特権を使用して顧客リソースを管理するために Microsoft Online Services ポータルにアクセスする必要がないユーザーがパートナー テナントにいます。 このパートナーは、これらのユーザーに対して MFA を実装している最中であり、完了にはさらに時間が必要です。 これは、技術的な例外の有効な理由ですか?

回答 : いいえ。 これらのユーザー アカウントは、顧客リソースを管理するためにパートナー委任管理特権を使用していないため、顧客テナントにサインインする必要はありません。 顧客テナントへのサインイン時に MFA 検証を必要とする Microsoft Entra ID の影響を受けることはありません。 顧客リソースを管理するには、すべてのユーザーがパートナー センターまたは顧客ワークロードにアクセスする MFA を持っている必要があります。

問題 3: パートナーがユーザー サービス アカウントに MFA を実装していない

あるパートナーのパートナー テナントに、サービス アカウントとしてデバイスに使用されているいくつかのユーザー アカウントが存在します。 これらの低い特権アカウントでは、パートナー代理管理特権を使用して顧客リソースを管理するために、パートナー センターや Microsoft Online Services ポータルにアクセスする必要はありません。 これは技術的な例外の正当な理由ですか?

回答 : いいえ。 これらのユーザー アカウントは、顧客リソースを管理するためにパートナー委任管理特権を使用していないため、顧客テナントにサインインする必要はありません。 顧客テナントへのサインイン時に MFA 検証を必要とする Microsoft Entra ID の影響を受けることはありません。 API またはポータルでアプリとユーザーの認証が必要な場合、すべてのユーザーが認証に MFA を使用する必要があります。

問題 4: パートナーが Microsoft Authenticator アプリを使用して MFA を実装できない

パートナーには "クリーン デスク" ポリシーがあり、従業員が個人のモバイル デバイスを職場に持ち込むことは許可されていません。 個人のモバイル デバイスにアクセスしないと、従業員は Microsoft Authenticator アプリをインストールできません。これは、Microsoft Entra セキュリティの既定値でサポートされている唯一の MFA 検証です。 これは、技術的な例外の有効な理由ですか?

回答 : いいえ。 パートナー センターにアクセスするときに従業員が MFA 検証を完了できるように、パートナーは次の代替手段を検討する必要があります。

  • パートナーは、Microsoft Entra ID P1 または P2 にサインアップすることも、Microsoft Entra ID と互換性のある Microsoft 以外の MFA ソリューションを使用して、より多くの検証方法を提供することもできます。 詳細については、 Authentication メソッドのサポートを参照してください。

問題 5: レガシ認証プロトコルの使用により、パートナーが MFA を実装できない

あるパートナーの一部のパートナー エージェントが、MFA と互換性のないレガシ認証プロトコルを引き続き使用しています。 たとえば、ユーザーが、レガシ認証プロトコルに基づく Outlook 2010 を引き続き使用しています。 これらのパートナー エージェントに対して MFA を有効にすると、レガシ認証プロトコルの使用が中断されます。 これは、技術的な例外の有効な理由ですか?

回答 : いいえ。 パートナーは、これらのプロトコルを MFA 検証で保護することはできないため、セキュリティへの影響が考えられるため、レガシ認証プロトコルの使用から離れ、資格情報の侵害の影響を受けやすくすることをお勧めします。 レガシ認証を非推奨にし、セキュリティの既定値または条件付きアクセスを使用することをお勧めします。 レガシ認証から移行する準備をするには、レガシ認証ブックを使用して サインインを確認し レガシ認証をブロックする方法 ガイダンスを確認

Outlook のレガシ認証をサポートするための最新の計画を理解するには、Basic 認証と Exchange Online に関する投稿を読みExchange チームのブログに従って今後のニュースを入手してください。

問題 6: パートナーが Microsoft Entra ID で認識されない Microsoft 以外の MFA を実装しました

パートナーは、Microsoft 以外の MFA ソリューションを使用してユーザーに MFA を実装しました。 ただし、パートナーは、ユーザー認証中に MFA 検証が完了したことを Microsoft Entra ID にリレーするように Microsoft 以外の MFA ソリューションを正しく構成できません。 これは、技術的な例外の有効な理由ですか?

回答: いいえ。パートナーは、認証時に提供される実際の資格情報の種類を反映して、資格情報メソッド要求 ("AMR")、Access トークン要求参照 ( Microsoft ID プラットフォーム) をサポートする Microsoft Entra ID と互換性のある認証プロバイダーを使用する必要があります。

Microsoft Entra ID と互換性のある MFA をすぐに実装して、テナントのセキュリティ ベースラインを上げることを強くお勧めします。