Azureおよびその他の管理ポータルの必須多要素認証の計画

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

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

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

実施範囲

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

実施フェーズ

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

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

2024 年 10 月以降、作成、読み取り、更新、または削除 (CRUD) 操作を実行するには、Azure portal、Microsoft Entra 管理センター、Microsoft Intune管理センターにサインインするアカウントに MFA が必要です。 適用は、世界中のすべてのテナントに徐々に実施されます。 2025 年 2 月から、MICROSOFT 365 ADMIN CENTER へのサインインに対する 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

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

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

Accounts

アプリケーション セクションに記載されている操作を実行するためにサインインするすべてのアカウントは、適用の開始時に MFA を完了する必要があります。 Azureでホストされている他のアプリケーション、Web サイト、またはサービスaccess場合、ユーザーは 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 ガイダンスについては、次のタブを参照してください。

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

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

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

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

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

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

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

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

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

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

必須の MFA 実施に向けた準備

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

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

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

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

• Azure PowerShell
• Azure CLI

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

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

適用の開始日を延期するテナントごとに、Global Administratorは https://aka.ms/managemfaforazure に移動して開始日を選択できます。

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

Microsoft では、複雑な環境や技術的な障壁を持つお客様が、テナントに対するフェーズ 2 の適用を 2026 年 7 月 1 日まで延期できます。 https://aka.ms/postponePhase2MFAでは、フェーズ 2 の MFA の適用に備える時間を増やすことができます。 別の開始日を選択し、[ 適用] をクリックします。 フェーズ 2 の適用が開始されたら、Microsoft のヘルプとサポートに要求を送信して、強制を一時的に解除できます。 要求は、セキュリティへの影響により、Global Administratorによって行われる必要があります。

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

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

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

FAQs

質問: フェーズ 2 の MFA 適用の影響を受けるアカウントはどれですか?

Answer: Azure フェーズ 2 の適用は、PowerShell、CLI、SDK、REST API など、Azure クライアントを介してAzureリソース管理アクションを実行するすべてのユーザー アカウントに適用されます。 この強制はAzure Resource Manager サーバー側で行われるので、https://management.azure.com を対象とする要求は適用の対象となります。 Automation アカウントは、マネージド ID またはサービス プリンシパルを使用している限り、スコープ内にありません。 ユーザー ID として設定されたすべてのオートメーション アカウントには強制的な措置が講じられます。

Question: 条件付きAccessなしで MFA 強制の影響を理解するにはどうすればよいですか?

Answer: Microsoft Entra ID ライセンスに条件付きAccessが含まれていない場合は、Azure Policyを使用して、MFA の適用がテナントに与える影響を理解できます。 システムの適用中に、Microsoft はテナントに Azure Policy を展開します。 これらの手順に従って、いつでも同じAzure policyを自分でデプロイできます。 ポリシーを監査モードで展開し、強制モードに変換できます。 強制モードの間に、テナントでこのポリシーを適用する日付を選択できます。 その後、Microsoft が MFA を適用しても、テナントにそれ以上の影響はありません。

質問: 特定のアカウントに例外はありますか?

Answer: システムの適用は、学生アカウント、緊急用アカウント、アクティブまたは資格のあるロールを持つ管理者アカウント、または有効になっているユーザー除外に関係なく、すべてのユーザーアカウントに適用されます。 これらのアカウントの種類はそれぞれ、Azureでリソース管理アクションを実行でき、侵害された場合は同じセキュリティ リスクが発生します。

Question: Microsoft Graph API はフェーズ 2 の適用対象ですか?

Answer: 一般に、Microsoft Graph API はAZURE MFA の適用の対象になりません。 https://management.azure.com/ に送信された要求のみが適用の対象となります。

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

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

Question: この要件はMicrosoft 365 admin centerにどのように影響しますか?

Answer: 必須の MFA は、2025 年 2 月からMicrosoft 365 admin centerにロールアウトされます。 Microsoft 365 admin centerの必須 MFA 要件の詳細については、ブログ記事「Microsoft 365 admin centerを参照してください。

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

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

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

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

質問: Azureの米国政府向けクラウドやソブリンクラウドにも適用されますか?

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

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

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

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

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

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

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

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

Question: 問題が発生しないことを確認するために、Azure がポリシーを強制する前に MFA をテストできますか?

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

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

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

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

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

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

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

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

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

関連コンテンツ

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

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