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

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

そのため、2024 年以降、Azure のすべてのサインイン試行に対する MFA の必須化を実施します。 この要件の詳細については、 ブログ記事「Azure の必須多要素認証:フェーズ 2(2025 年 10 月以降 )、 および Azure サインインの必須多要素認証の発表」を参照してください。 このトピックでは、影響を受けるアプリケーションとアカウント、テナントへの強制のロール アウトの方法、その他の一般的な質問と回答について説明します。

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

実施範囲

適用のスコープには、適用が予定されている時期、MFA を適用するアプリケーション、スコープ外のアプリケーション、必須の MFA 要件を持つアカウントが含まれます。

実施フェーズ

アプリケーションに対する MFA の適用は、2 つのフェーズでロールアウトされます。

フェーズ 1 のアプリケーション

2024 年 10 月以降、Azure portal、Microsoft Entra 管理センター、Microsoft Intune 管理センターにサインインするアカウントが作成、読み取り、更新、または削除 (CRUD) 操作を実行するには、MFA が必要です。 適用は、世界中のすべてのテナントに徐々に実施されます。 2025 年 2 月以降、Microsoft 365 管理センターへのサインインでの MFA の適用が徐々に開始されます。 フェーズ 1 は、Azure CLI、Azure PowerShell、Azure モバイル アプリ、IaC ツールなどの他の Azure クライアントには影響しません。

フェーズ 2 のアプリケーション

2025 年 10 月 1 日以降、Azure CLI、Azure PowerShell、Azure モバイル アプリ、IaC ツール、REST API エンドポイントにサインインして、作成、更新、または削除操作を実行するアカウントに対して、MFA の適用が徐々に開始されます。 読み取り操作では MFA は必要ありません。

一部のお客様は、Microsoft Entra ID のユーザー アカウントをサービス アカウントとして使用できます。 これらのユーザー ベースのサービス アカウントを移行して、ワークロード ID を持つクラウドベースのサービス アカウントをセキュリティで保護することをお勧めします。

アプリケーション ID と URL

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

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

Accounts

アプリケーション セクションに記載されている操作を実行するためにサインインするすべてのアカウントは、適用の開始時に 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 に 条件付きアクセスを適用できます。

フェデレーション ID プロバイダーを外部認証方法に移行する

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

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

必須の MFA 適用の準備

MFA の適用を準備するには、ユーザーが MFA でサインインすることを要求する 条件付きアクセス ポリシー を構成します。 ポリシーで例外または除外を構成した場合は、適用されなくなります。 Azure を対象とするより制限の厳しい条件付きアクセス ポリシーがあり、フィッシングに強い MFA など、より強力な認証が必要な場合は、引き続き適用されます。

条件付きアクセスには、Microsoft Entra ID P1 または P2 ライセンスが必要です。 条件付きアクセスを使用できない場合は、 セキュリティの既定値を有効にします。

Azure Policy の組み込み定義を使用して、MFA を自己適用できます。 詳細を確認し、これらのポリシー割り当てを環境に適用する手順の概要に従う方法については、「 チュートリアル: Azure Policy を使用して MFA 自己強制を適用する」を参照してください。

最適な互換性エクスペリエンスを実現するには、テナント内のユーザーが Azure CLI バージョン 2.76 と Azure PowerShell バージョン 14.3 以降を使用していることを確認します。 それ以外の場合は、次のトピックで説明されているようにエラー メッセージが表示されます。

• Azure PowerShell での MFA エラーのトラブルシューティング
• Azure CLI での MFA エラーのトラブルシューティング

フェーズ 1 MFA の適用に備える時間を増やす

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

適用の開始日を延期するテナントごとに、グローバル管理者は https://aka.ms/managemfaforazure に移動して開始日を選択できます。

フェーズ 2 MFA の適用に備える時間を増やす

Microsoft では、複雑な環境や技術的な障壁を持つお客様が、テナントに対するフェーズ 2 の適用を 2026 年 7 月 1 日まで延期できます。 https://aka.ms/postponePhase2MFAでは、フェーズ 2 の MFA の適用に備える時間を増やすことができます。 別の開始日を選択し、[ 適用] をクリックします。

必須の MFA の適用を確認する

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

Microsoft Entra ID サインイン ログには 、MFA 要件のソースとして MFA を適用したアプリケーションが表示されます。

FAQs

質問: テナントがテストにのみ使用されている場合、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 を構成して展開する方法の詳細を参照してください。

• ユーザーが署名できないテナントの適用を延期する方法
• ユーザーが必須の MFA に設定されていることを確認する方法
• チュートリアル: Microsoft Entra 多要素認証を使用してユーザー サインイン イベントをセキュリティで保護する
• Microsoft Entra 多要素によるサインイン イベントのセキュリティ保護
• Microsoft Entra 多要素認証の展開を計画する
• フィッシングに強い MFA メソッド
• Microsoft Entra 多要素認証
• 認証方法