Azureやその他の管理ポータルにおける多要素認証の義務化の計画

Microsoft では、お客様に最高レベルのセキュリティを提供することに取り組んでいます。 利用できる最も効果的なセキュリティ対策の 1 つは、多要素認証 (MFA) です。 Microsoft の調査によると 、MFA は 99.2% を超えるアカウント侵害攻撃をブロックできます。

そのため、2024 年以降、Azure のすべてのサインイン試行に対する MFA の必須化を実施します。 この要件の詳細については、 ブログの投稿を参照してください。 このトピックでは、影響を受けるアプリケーションとアカウント、テナントへの強制のロール アウトの方法、その他の一般的な質問と回答について説明します。

組織が既に MFA を適用している場合や、パスワードレスやパスキー (FIDO2) などのより強力な方法でサインインしている場合は、ユーザーに変更はありません。 MFA が有効になっていることを確認するには、「 ユーザーが必須の MFA に対して設定されていることを確認する方法」を参照してください。

実施範囲

適用の範囲には、MFA を適用する予定のアプリケーション、対象外のアプリケーション、適用を実施する予定の時期、必須の MFA の要件を持つアカウントが含まれます。

アプリケーション

次の表に、影響を受ける Azure のアプリ、アプリ ID、URL を示します。

次の表に、影響を受ける Microsoft 365 のアプリと URL を示します。

アカウント

前に示した アプリケーション にサインインして、作成、読み取り、更新、または削除 (CRUD) 操作を実行するすべてのユーザーは、適用の開始時に MFA を完了する必要があります。 Azure でホストされている他のアプリケーション、Web サイト、またはサービスにアクセスする場合、ユーザーは MFA を使用する必要はありません。 前述の各アプリケーション、Web サイト、またはサービス所有者は、ユーザーの認証要件を制御します。

実施が開始されたら、非常時つまり緊急時のアクセス アカウントも MFA を使用してサインインする必要があります。 パスキー (FIDO2) を使用するようにこれらのアカウントを更新するか、MFA の証明書ベースの認証を構成することをお勧めします。 どちらの方法も MFA 要件を満たしています。

マネージド ID やサービス プリンシパルなどのワークロード ID は、この MFA 適用 のいずれかのフェーズ の影響を受けません。 自動化を実行するためにユーザー ID がサービス アカウントとしてログインするのに使用される場合 (スクリプトやその他の自動化タスクを含む)、実施が開始されたらそれらのユーザー ID は MFA でログインする必要があります。 自動化にはユーザー ID は推奨されません。 これらのユーザー ID を ワークロード ID に移行する必要があります。

クライアント ライブラリ

OAuth 2.0 リソース所有者パスワード認証 (ROPC) トークン付与フローは、MFA と互換性がありません。 Microsoft Entra テナントで MFA が有効になった後、アプリケーションで使用される ROPC ベースの API によって例外がスローされます。 Microsoft 認証ライブラリ (MSAL) で ROPC ベースの API から移行する方法の詳細については、「ROPC から移行する方法」を参照してください。 言語固有の MSAL ガイダンスについては、次のタブを参照してください。

Azure ID ライブラリにも、同じ一般的な MSAL ガイダンスが適用されます。 これらのライブラリで提供される UsernamePasswordCredential クラスは、MSAL ROPC ベースの API を使用します。 言語固有のガイダンスについては、次のタブを参照してください。

ユーザー ベースのサービス アカウントをワークロード ID に移行する

サービス アカウントとして使用されているユーザー アカウントを見つけてワークロード ID への移行を開始することをお勧めします。 多くの場合、移行では、ワークロード ID を使用するためにスクリプトと自動化プロセスを更新する必要があります。

ユーザーが必須の MFA を設定されていることを確認する方法を確認し、サービス アカウントとして使用されているユーザー アカウントを含む、アプリケーションにサインインするすべてのユーザー アカウントを特定します。

これらのアプリケーションで認証するために、ユーザーベースのサービス アカウントからワークロード ID に移行する方法の詳細については、次を参照してください。

• Azure CLI を使用してマネージド ID で Azure にサインインする
• Azure CLI を使用してサービス プリンシパルで Azure にサインインする
• 自動化シナリオ用に非対話形式で Azure PowerShell にサインイン する方法には、マネージド ID とサービス プリンシパルのユース ケースの両方に関するガイダンスが含まれています

一部のお客様は、ユーザー ベースのサービス アカウントに条件付きアクセス ポリシーを適用します。 ユーザー ベースのライセンスを再利用し、ワークロード ID ライセンスを追加して 、ワークロード ID に 条件付きアクセスを適用できます。

実装

サインイン時の MFA のこの要件は、管理ポータルやその他のアプリケーションに対 して実装されます。 Microsoft Entra ID サインイン ログには 、MFA 要件のソースとして表示されます。

必須の MFA は構成できません。 テナントで構成されているアクセス ポリシーとは別に実装されます。

たとえば、組織が Microsoft の セキュリティの既定値を保持することを選択し、現在セキュリティの既定値が有効になっている場合、Azure 管理には MFA が既に必要であるため、ユーザーに変更は表示されません。 テナントが Microsoft Entra で 条件付きアクセス ポリシーを使用していて、ユーザーが MFA を使用して Azure にサインインする条件付きアクセス ポリシーが既にある場合、ユーザーに変更は表示されません。 同様に、Azure を対象としてより強力な認証 (フィッシングに強い MFA など) を必要とする厳格な条件付きアクセス ポリシーも、引き続き実行されます。 ユーザーには変更は表示されません。

実施フェーズ

MFA の実施は、次の 2 つのフェーズで適用されます。

• フェーズ 1: 2024 年 10 月以降、Azure portal、Microsoft Entra 管理センター、および Microsoft Intune 管理センターにサインインするには MFA が必要です。 適用は、世界中のすべてのテナントに徐々に実施されます。 2025 年 2 月以降、Microsoft 365 管理センターへのサインインでの MFA の適用が徐々に開始されます。 このフェーズは、Azure CLI、Azure PowerShell、Azure mobile app、IaC ツールなどの他の Azure クライアントには影響しません。

• フェーズ 2: 2025 年 9 月 1 日から、Azure CLI、Azure PowerShell、Azure モバイル アプリ、IaC ツール、REST API エンドポイントに対する MFA の適用が徐々に開始されます。 一部のお客様は、Microsoft Entra ID のユーザー アカウントをサービス アカウントとして使用できます。 これらのユーザー ベースのサービス アカウントを移行して、ワークロード ID を持つクラウド ベースのサービス アカウントをセキュリティで保護することをお勧めします。

通知チャネル

Microsoft は、次のチャネルを介してすべての Microsoft Entra のグローバル管理者に通知します。

• メール: メール アドレスを構成したグローバル管理者には、今後の MFA の強制と準備に必要なアクションがメールで通知されます。

• サービス正常性通知: グローバル管理者は、Azure portal からサービス正常性通知を受信し、追跡 ID は 4V20-VX0 です。 この通知には、メールと同じ情報が含まれています。 グローバル管理者は、サービス正常性通知をメールで受信するように登録することもできます。

• ポータル通知: グローバル管理者がサインインすると、Azure portal、Microsoft Entra 管理センター、および Microsoft Intune 管理センターに通知が表示されます。 必須の MFA 実施の詳細については、ポータル通知がこのトピックにリンクします。

• Microsoft 365 メッセージ センター: Microsoft 365 メッセージ センターにメッセージ ID : MC862873が表示されます。 このメッセージには、メールおよびサービス正常性通知と同じ情報が記載されています。

適用後、 Azure portal にバナーが表示されます。

外部認証方法と ID プロバイダー

外部 MFA ソリューションのサポートは、 外部認証方法を使用してプレビュー段階であり、MFA 要件を満たすために使用できます。 レガシの条件付きアクセス カスタム コントロール プレビューは、MFA 要件を満たしていません。 外部の認証方法プレビューに移行し、Microsoft Entra ID で外部ソリューションを使用する必要があります。

Active Directory フェデレーション サービス (AD FS) などのフェデレーション ID プロバイダー (IdP) を使用していて、MFA プロバイダーがこのフェデレーション IdP と直接統合されている場合は、MFA 要求を送信するようにフェデレーション IdP を構成する必要があります。 詳細については、Microsoft Entra MFA の予期される受信アサーションに関する記事を参照してください。

施行の準備にもっと時間を要求する

一部のお客様は、この MFA 要件の準備により多くの時間が必要になる場合があることを理解しています。 Microsoft は、複雑な環境や技術的障害があるお客様については、テナントでの適用を 2025 年 9 月 30 日まで延期することを許可しています。

グローバル管理者は、 https://aka.ms/managemfaforazure に移動して、フェーズ 1 で管理ポータルのテナントの適用開始日を選択できます。 フェーズ 1 の開始日を延期した場合、フェーズ 2 の適用は 、選択した開始日より前には開始されません。 グローバル管理者は、MFA 適用の開始日を延期する前に 、アクセス 権を昇格し、MFA を使用する必要があります。

グローバル管理者は、強制の開始日を延期するすべてのテナントに対してこのアクションを実行する必要があります。

Azure Portal など、Microsoft サービスにアクセスするアカウントは、脅威アクターにとって非常に価値が高いターゲットであるため、実施の開始日を延期することでさらなるリスクにさらされます。 すべてのテナントが今すぐ MFA を設定し、クラウド リソースをセキュリティで保護することをお勧めします。

よく寄せられる質問

質問: テナントがテストにのみ使用されている場合、MFA は必要ですか?

回答: はい。すべての Azure テナントで MFA が必要になりますが、テスト環境に対する例外はありません。

質問: この要件は Microsoft 365 管理センターにどのように影響しますか?

回答: 必須の MFA は、2025 年 2 月から Microsoft 365 管理センターにロールアウトされます。 Microsoft 365 管理センターの必須 MFA 要件の詳細については、Microsoft 365 管理センターの 必須多要素認証の発表に関するブログ記事を参照してください。

質問: すべてのユーザーまたは管理者にのみ MFA が必須ですか?

回答: 前に一覧表示されている アプリケーション のいずれかにサインインするすべてのユーザーは、アクティブ化または資格のある管理者ロール、または有効になっている ユーザーの除外 に関係なく、MFA を完了する必要があります。

質問: サインインしたままにするオプションを選択した場合、MFA を完了する必要がありますか?

回答: はい。[ サインインしたままにする] を選択した場合でも、これらのアプリケーションにサインインする前に MFA を完了する必要 があります。

質問: B2B ゲスト アカウントには適用されますか?

回答: はい。MFA は、パートナー リソース テナントから、またはユーザーのホーム テナント (クロステナント アクセスを使用してリソース テナントに MFA 要求を送信するように適切に設定されている場合) のいずれかに従う必要があります。

質問: 米国政府機関向けクラウドまたは Azure ソブリン クラウドの場合、この適用は Azure に適用されますか?

回答: Microsoft は、パブリック Azure クラウドでのみ必須の MFA を適用します。 現在、Microsoft では、米国政府または他の Azure ソブリン クラウドに対して Azure で MFA を適用していません。

質問: 別の ID プロバイダーまたは MFA ソリューションを使用して MFA を適用し、Microsoft Entra MFA を使用して適用しない場合、どのように準拠できますか。

回答: サード パーティの MFA は、Microsoft Entra ID と直接統合できます。 詳細については、「 Microsoft Entra 多要素認証の外部メソッド プロバイダー リファレンス」を参照してください。 Microsoft Entra ID は、必要に応じてフェデレーション ID プロバイダーで構成できます。 その場合は、複数認証要求を Microsoft Entra ID に送信するように ID プロバイダー ソリューションを適切に構成する必要があります。 詳細については、「 フェデレーション IdP からの MFA 要求を使用して Microsoft Entra ID 多要素認証 (MFA) コントロールを満たす」を参照してください。

質問: 必須の MFA は、Microsoft Entra Connect または Microsoft Entra Cloud Sync と同期する機能に影響しますか?

回答: いいえ。 同期サービス アカウントは、必須の MFA 要件の影響を受けません。 サインイン に MFA が 必要なのは、前述のアプリケーションのみです。

質問: オプトアウトできますか?

回答: オプトアウトする方法はありません。このセキュリティモーションは、Azure プラットフォームのすべての安全性とセキュリティにとって重要であり、クラウド ベンダー間で繰り返されています。 たとえば、 2024 年の MFA 要件の強化については、「設計によるセキュリティ保護: AWS」を参照してください。

実施開始日を延期するオプションはお客様に提供されます。 グローバル管理者は 、Azure portal にアクセスして、テナントの適用開始日を延期できます。 グローバル管理者は、このページで MFA 適用の開始日を延期する前に、 昇格されたアクセス権 を持っている必要があります。 延期が必要なテナントごとに、このアクションを実行する必要があります。

質問: Azure がポリシーを適用して何も中断しないようにする前に MFA をテストできますか?

回答: はい。MFA の手動セットアップ プロセスを使用して、 MFA をテスト できます。 これを設定してテストすることをお勧めします。 条件付きアクセスを使用して MFA を実施する場合、条件付きアクセス テンプレートを使用してポリシーをテストできます。 詳細については、「 Microsoft 管理ポータルにアクセスする管理者に多要素認証を要求する」を参照してください。 Microsoft Entra ID の無料版を実行する場合は、 セキュリティの既定値を有効にすることができます。

質問: MFA が既に有効になっている場合、次はどうなりますか?

回答: 前述のアプリケーションにアクセスするユーザーに対して既に MFA を必要とするお客様には、変更はありません。 ユーザーのサブセットにのみ MFA が必要な場合、MFA をまだ使用していないユーザーは、アプリケーションにログインするときに MFA の使用が必要になりました。

質問: Microsoft Entra ID で MFA アクティビティを確認するにはどうすればよいですか?

回答: ユーザーが MFA を使用してサインインするように求められるタイミングの詳細を確認するには、Microsoft Entra サインイン ログを使用します。 詳細については、 Microsoft Entra 多要素認証のサインイン イベントの詳細を参照してください。

質問: "非常用" シナリオがある場合は?

回答: これらのアカウントを更新して 、パスキー (FIDO2) を使用するか、MFA の 証明書ベースの認証 を構成することをお勧めします。 どちらの方法も MFA 要件を満たしています。

質問: MFA が適用される前に MFA の有効化に関する電子メールを受信せず、ロックアウトされた場合はどうすればよいですか。解決方法を教えてください。

回答: ユーザーはロックアウトしないでくださいが、テナントの適用が開始されると、MFA を有効にするように求めるメッセージが表示されることがあります。 ユーザーがロックアウトされた場合、他の問題が発生している場合があります。 詳細については、「 アカウントがロックされている」を参照してください。

関連するコンテンツ

次のトピックを参照し、MFA を構成して展開する方法の詳細を参照してください。

• Azure portal、Microsoft Entra 管理センター、または Microsoft Intune 管理センターの必須多要素認証 (MFA) 要件のロールアウト後にユーザーがサインインできないテナントの適用を延期する方法
• ユーザーが必須の MFA に設定されていることを確認する方法
• チュートリアル: Microsoft Entra 多要素認証を使用してユーザー サインイン イベントをセキュリティで保護する
• Microsoft Entra 多要素によるサインイン イベントのセキュリティ保護
• Microsoft Entra 多要素認証の展開を計画する
• フィッシングに強い MFA メソッド
• Microsoft Entra 多要素認証
• 認証方法