パートナー テナントの多要素認証 (MFA) の管理
対象のロール: 管理エージェント | 販売エージェント | ヘルプデスク エージェント | 課金管理者 | グローバル管理者
セキュリティの強化と継続的なセキュリティとプライバシー保護は、Microsoft の最優先事項の 1 つであり、パートナーが顧客とテナントを保護できるように支援し続けています。
パートナーがビジネスや顧客を ID の盗難や不正アクセスから保護できるように、パートナー テナントのセキュリティ保護を強化しました。 これらのセーフガードでは、MFA が義務付けおよび検証されます。 MFA の管理は、パートナーが資格情報の侵害から顧客リソースへのアクセスをセキュリティで保護するのに役立ちます。
この記事では、パートナー センターでの多要素認証 (MFA) の管理に関する詳細な例とガイダンスを示します。
クラウド ソリューション プロバイダー (CSP) プログラム、コントロール パネル ベンダー (CPV)、アドバイザーに参加しているパートナーは、準拠を維持するためにパートナー セキュリティ要件を実装する必要があります。
パートナーは、パートナー テナント内のすべてのユーザー アカウント (ゲスト ユーザーを含む) に対して MFA を強制する必要があります。 ユーザーは、次の領域の MFA 検証を完了する必要があります。
パートナー センター
パートナー センターの一部のページでは、次のような MFA で保護されています。
- [顧客] タブのすべてのページ (つまり、URL で始まる
https://partner.microsoft.com/commerce/*すべてのページ) - [サポート>顧客の要求] タブのすべてのページ (たとえば、URL で始まる
https://partner.microsoft.com/dashboard/v2/support/customers/*すべてのページ) - [課金] タブのすべてのページ
パートナー センターのその他のページ ([概要] ページや [サービス正常性の状態] チェック ページなど) では、MFA は必要ありません。
次の表は、これらの MFA で保護されたページにアクセスする権限を持つユーザーの種類を示しています (この機能の影響を受けます)。
| MFA 保護対象のページ | 管理エージェント | 販売エージェント | ヘルプデスク エージェント | 全体管理者 | 課金管理者 |
|---|---|---|---|---|---|
| [顧客] タブのすべてのページ | x | 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 あり)
- 詳細な管理者リレーションシップ要求とアクセスの割り当て
パートナーは次のオプションを使用できます。
- MFA 要件を満たすには、Microsoft の組み込み認証方法を使用します。
- フェデレーション ID プロバイダーを使用している場合は、 フェデレーションがフェデレーション MFA を受け入れるように構成されていることを確認します。
- ADFS を使用して外部の第 2 要素を構成する場合は、AD FS で使用可能な MFA オファリングを持つサード パーティ プロバイダーの構成: AD FS の認証方法の構成に関するページを参照してください。
- MFA を実装する: セキュリティの既定値または条件付きアクセスを使用して、セキュリティの既定値のガイダンスに従って、すぐに MFA を有効にします。
検証の例
パートナー センターでの検証のしくみを説明するには、次の例を検討してください。
例 1: パートナーが Microsoft Entra 多要素認証を実装している
Alejandra は Contoso という CSP で動作します。 Contoso は、Microsoft Entra 多要素認証を使用して、Contoso パートナー テナントのすべてのユーザーに対して MFA を実装しました。
Alejandra は新しいブラウザー セッションを開始し、パートナー センターの概要ページ (MFA で保護されていません) に移動します。 パートナー センターは、サインインするために Alejandra を Microsoft Entra ID にリダイレクトします。
Contoso による既存の Microsoft Entra 多要素認証のセットアップにより、MFA 検証を完了するには Alejandra が必要です。 サインインと MFA の検証が成功すると、Alejandra はパートナー センターの概要ページにリダイレクトされます。
Alejandra は、パートナー センターで MFA で保護されたページのいずれかにアクセスしようとします。 Alejandra は以前にサインイン中に MFA 検証を完了しているため、Alejandra は MFA で保護されたページにアクセスできます。MFA 検証を再度実行する必要はありません。
例 2: パートナーが ID フェデレーションを使用して Microsoft 以外の MFA を実装している
Prashob は Wingtip という CSP に勤めています。 Wingtip は、Microsoft 以外の MFA を使用して Wingtip パートナー テナントのすべてのユーザーに対して MFA を実装しました。これは、ID フェデレーションを介して Microsoft Entra ID と統合されています。
Prashob は新しいブラウザー セッションを開始し、パートナー センターの概要ページ (MFA で保護されていません) に移動します。 パートナー センターは、サインインするために Prashob を Microsoft Entra ID にリダイレクトします。
Wingtip には ID フェデレーションが設定されているため、Microsoft Entra ID は Prashob をフェデレーション ID プロバイダーにリダイレクトして、サインインと MFA の検証を完了します。 サインインと MFA の検証が成功すると、Prashob は Microsoft Entra ID にリダイレクトされ、パートナー センターの概要ページにリダイレクトされます。
Prashob は、パートナー センターの MFA で保護されたページのいずれかにアクセスしようとします。 Prashob は以前のサインイン時に MFA 検証を既に完了しているため、MFA 検証を再度実行する必要なく、MFA で保護されたページにアクセスできます。
その後、Prashob はサービス管理ページに移動し、Contoso の Microsoft Entra ID にユーザーを追加します。 Prashob は強力な認証で Entra と互換性のある認証プロバイダーを使用しているため、問題なく顧客テナントにアクセスできます。
この例の Prashob の推奨事項は、Microsoft Entra 多要素認証ソリューションまたは Entra 互換認証プロバイダーを使用して、顧客のテナントを正常に管理できるようにすることです。
例 3: パートナーが MFA を実装していない
Fabrikam という CSP パートナーは、まだ MFA を実装していません。 Microsoft では、Microsoft Entra ID でサポートされる MFA ソリューションを実装することをお勧めします。
John は Fabrikam に勤めています。 Fabrikam は、Fabrikam パートナー テナントの下のユーザーに対して MFA を実装していません。
John は新しいブラウザー セッションを開始し、パートナー センターの概要ページに移動します (MFA で保護されていません)。 パートナー センターは、サインインするために John を Microsoft Entra ID にリダイレクトします。
サインインに成功すると、John は MFA 検証を完了していないため、パートナー センターの概要ページにリダイレクトされます。
John は、パートナー センターの MFA で保護されたページのいずれかにアクセスしようとします。 John は MFA 検証を完了していないため、パートナー センターは John を Microsoft Entra ID にリダイレクトして MFA 検証を完了します。 John が MFA を完了する必要があるのはこれが初めてであるため、John は MFA への登録も要求されます。 MFA 登録と MFA 検証が成功すると、John は MFA で保護されたページにアクセスできます。
別の日に、Fabrikam が任意のユーザーの MFA を実装する前に、John は新しいブラウザー セッションを開始し、パートナー センターの概要ページ (MFA で保護されていない) に移動します。 パートナー センターは、MFA プロンプトなしでサインインするために John を Microsoft Entra ID にリダイレクトします。
John は、パートナー センターの MFA で保護されたページのいずれかにアクセスしようとします。 John は MFA 検証を完了していないため、パートナー センターは John を Microsoft Entra ID にリダイレクトして MFA 検証を完了します。 John は MFA を登録しているため、今回は MFA 検証の完了のみを求められます。
例 4: パートナーが Microsoft Entra と互換性のない Microsoft 以外の MFA を実装している
Trent は Wingtip という CSP に勤めています。 Wingtip は、条件付きアクセスを使用するクラウド環境で Microsoft 以外の MFA を使用して、Wingtip パートナー テナントのすべてのユーザーに対して MFA を実装しました。
Trent は新しいブラウザー セッションを開始し、パートナー センターの概要ページ (MFA で保護されていません) に移動します。 パートナー センターは、サインインするために Trent を Microsoft Entra ID にリダイレクトします。
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 は、認証方法参照 (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": "23ec45a3-5127-4185-9eff-c8887839e6ab",
"appidacr": "0",
"family_name": "Adminagent",
"given_name": "CSP",
"ipaddr": "127.0.0.1",
"name": "Adminagent CSP",
"oid": "4988e250-5aee-482a-9136-6d269cb755c0",
"scp": "user_impersonation",
"tenant_region_scope": "NA",
"tid": "df845f1a-7b35-40a2-ba78-6481de91f8ae",
"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:03ce8ca8-8373-4021-8f25-d5dd45c7b12f 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 パートナーは、パートナー センター ポータルからサービス管理インターフェイスを使用して顧客を管理できます。 パートナーは顧客に移動し、[サービス管理] を選択して、顧客の特定のサービスを管理できます。 パートナーは、GDAP ロールの ガイダンス に従って、顧客を管理するための適切な最小限の特権 GDAP ロールを取得する必要があります。
パートナー委任管理特権 (管理-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 登録を完了するように求められます。
パートナー アカウントがフェデレーション 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 セキュリティの既定値を有効にしてから、パートナーの詳細な委任された管理istration Privileges (GDAP) を使用して顧客テナントにアクセスしてみてください。
Note
一部の Microsoft Online Service ポータルでは、GDAP を使用して顧客リソースにアクセスするときにパートナー アカウントが顧客テナントにサインインする必要はありません。 代わりに、パートナー アカウントのみがパートナー テナントにサインインする必要があります。 1 つの例は Exchange 管理センターです。 時間の経過と同時に、これらのポータルでは、GDAP を使用するときにパートナー アカウントが顧客テナントにサインインする必要があります。
MFA 登録エクスペリエンス
MFA 検証中に、パートナー アカウントが MFA に登録されていない場合、Microsoft Entra ID はユーザーに最初に MFA 登録を完了するように求めます。
Microsoft Authenticator メソッドの詳細を確認します。
ユーザーが [次へ] を選択すると、確認方法の一覧から選択するように求められます。
登録が成功した後、ユーザーは選択した検証方法を使用して MFA 検証を完了する必要があります。
一般的な問題
他のパートナーから報告された一般的な問題の一覧を確認して、要求が有効かどうかを確認します。
問題 1: パートナーエージェントに MFA を実装する時間がパートナーに増える必要がある
あるパートナーが、顧客リソースを管理するためにパートナー代理管理特権を使用した Microsoft Online Services ポータルへのアクセスを必要としているパートナー エージェントに対する MFA の実装をまだ開始していないか、またはその最中です。 このパートナーには、MFA 実装を完了するためのさらに多くの時間が必要です。 これは、技術的な例外の有効な理由ですか?
回答 : できません。 パートナーは、中断を回避するために、ユーザーに MFA を実装する計画を立てる必要があります。
Note
パートナーがパートナー エージェントの MFA を実装していない場合でも、パートナー エージェントは、顧客テナントへのサインイン時にプロンプトが表示されたときに MFA 登録と MFA 検証を完了できる場合、パートナー委任管理登録特権を使用して Microsoft Online Services ポータルにアクセスできます。 MFA 登録を完了しても、そのユーザーに対して MFA が自動的に有効になるわけではありません。
問題 2: パートナーは顧客を管理するためにアクセスする必要がないため、MFA を実装していません
パートナーには、パートナーの委任された管理移行特権を使用して顧客リソースを管理するために Microsoft Online Services ポータルにアクセスする必要がないユーザーがパートナー テナントにいます。 このパートナーは、これらのユーザーに対して MFA を実装している最中であり、完了にはさらに時間が必要です。 これは、技術的な例外の有効な理由ですか?
回答 : できません。 これらのユーザー アカウントは、顧客のリソースを管理するためにパートナー委任管理istration 特権を使用していないため、顧客テナントにサインインする必要はありません。 顧客テナントへのサインイン時に MFA 検証を必要とする Microsoft Entra ID の影響を受けることはありません。 顧客リソースを管理するには、すべてのユーザーがパートナー センターまたは顧客ワークロードにアクセスする MFA を持っている必要があります。
問題 3: パートナーがユーザー サービス アカウントに MFA を実装していない
あるパートナーのパートナー テナントに、サービス アカウントとしてデバイスに使用されているいくつかのユーザー アカウントが存在します。 これらの低い特権アカウントでは、パートナー委任された管理istration 特権を使用して顧客リソースを管理するために、パートナー センターや Microsoft Online Services ポータルにアクセスする必要はありません。 これは技術的な例外の正当な理由ですか?
回答 : できません。 これらのユーザー アカウントは、顧客リソースを管理するためにパートナー委任管理istration 特権を使用していないため、顧客テナントにサインインする必要はありません。 顧客テナントへのサインイン時に 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 ソリューションを使用して、より多くの検証方法を提供することもできます。 詳細については、サポートされている認証方法に関するページを参照してください。
問題 5: レガシ認証プロトコルの使用により、パートナーが MFA を実装できない
あるパートナーの一部のパートナー エージェントが、MFA と互換性のないレガシ認証プロトコルを引き続き使用しています。 たとえば、ユーザーが、レガシ認証プロトコルに基づく Outlook 2010 を引き続き使用しています。 これらのパートナー エージェントに対して MFA を有効にすると、レガシ認証プロトコルの使用が中断されます。 これは、技術的な例外の有効な理由ですか?
回答 : できません。 パートナーは、これらのプロトコルを MFA 検証で保護することはできないため、セキュリティへの影響が考えられるため、レガシ認証プロトコルの使用から離れ、資格情報の侵害の影響を受けやすくすることをお勧めします。 レガシ認証を非推奨にし、セキュリティの既定値または条件付きアクセスを使用することをお勧めします。 レガシ認証から移行する準備をするには、レガシ認証ブックを使用したサインインと、レガシ認証をブロックする方法に関するガイダンスを確認します。
Outlook のレガシ認証をサポートするための最新の計画を理解するには、基本認証と Exchange Online に関する投稿を読み、Exchange チームのブログに従って今後のニュースを入手してください。
問題 6: パートナーが Microsoft Entra ID で認識されない Microsoft 以外の MFA を実装しました
パートナーは、Microsoft 以外の MFA ソリューションを使用してユーザーに MFA を実装しました。 ただし、パートナーは、ユーザー認証中に MFA 検証が完了したことを Microsoft Entra ID にリレーするように Microsoft 以外の MFA ソリューションを正しく構成できません。 これは、技術的な例外の有効な理由ですか?
回答: いいえ。パートナーは、認証時に提供される実際の資格情報の種類を反映して、資格情報メソッド要求 ("AMR")、アクセス トークン要求参照 - Microsoft ID プラットフォームをサポートする Entra ID と互換性のある認証プロバイダーを使用する必要があります。
Microsoft Entra ID と互換性のある MFA をすぐに実装して、テナントのセキュリティ ベースラインを上げることを強くお勧めします。
次のステップ
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示