Azureやその他の管理ポータルにおける多要素認証の義務化の計画
Microsoft では、お客様に最高レベルのセキュリティを提供することに取り組んでいます。 利用できる最も効果的なセキュリティ対策の 1 つは、多要素認証 (MFA) です。 Microsoft の調査 によると、MFA はアカウントを侵害する攻撃の 99.2% 以上をブロックできることが示されています。
そのため、2024 年からすべての Azure ログイン試行に対して必須の多要素認証 (MFA) を実施します。 この要件の詳しい背景については、「ブログ記事」をご覧ください。 このトピックでは、影響を受けるアプリケーションとアカウント、テナントへの強制の展開方法、その他の一般的な質問と回答について説明します。
組織が既に MFA を適用している場合や、パスワードレスやパスキー (FIDO2) などのより強力な方法でサインインしている場合は、ユーザーに変更はありません。 MFA が有効になっていることを確認するには、「 ユーザーが必須の MFA を設定していることを確認する方法を参照してください。
実施範囲
適用範囲には、MFA の実施が予定されるアプリケーション、実施が計画されるタイミング、必須の MFA 要件が対象となるアカウントが含まれます。
アプリケーション
| アプリケーション名 | アプリ ID | 実施フェース |
|---|---|---|
| Azure portal | c44b4083-3bb0-49c1-b47d-974e53cbdf3c | 2024 年後半 |
| Microsoft Entra 管理センター | c44b4083-3bb0-49c1-b47d-974e53cbdf3c | 2024 年後半 |
| Microsoft Intune 管理センター | c44b4083-3bb0-49c1-b47d-974e53cbdf3c | 2024 年後半 |
| Azure コマンド ライン インターフェイス (Azure CLI) | 04b07795-8ddb-461a-bbee-02f9e1bf7b46 | 2025 年初頭 |
| Azure PowerShell | 1950a258-227b-4e31-a9cf-717495945fc2 | 2025 年初頭 |
| Azure Mobile App | 0c1307d4-29d6-4389-a11c-5cbe7f65d7fa | 2025 年初頭 |
| コードとしてのインフラストラクチャ (IaC) ツール | Azure CLI または Azure PowerShell IDを使用する | 2025 年初頭 |
取引先企業
前に示した アプリケーション にサインインして作成、読み取り、更新、または削除 (CRUD) 操作を実行するすべてのユーザーは、適用の開始時に MFA を完了する必要があります。 Azure でホストされている他のアプリケーション、Web サイト、またはサービスにアクセスする場合、ユーザーは MFA を使用する必要はありません。 前述の各アプリケーション、Web サイト、またはサービス所有者は、ユーザーの認証要件を制御します。
実施が開始されたら、非常時アクセス アカウントまたは緊急用のアクセス アカウントも MFA でログインする必要があります。 これらのアカウントは、 passkey (FIDO2) を使用するように更新するか、MFA certificate ベースの認証 を構成することをお勧めします。 どちらの方法も MFA 要件を満たしています。
マネージド ID やサービス プリンシパルなどのワークロード ID は、この MFA 適用のフェーズ影響を受けません。 自動化を実行するためにユーザー ID がサービス アカウントとしてログインするのに使用される場合 (スクリプトやその他の自動化タスクを含む)、実施が開始されたらそれらのユーザー ID は MFA でログインする必要があります。 自動化にはユーザー ID は推奨されません。 それらのユーザー ID をワークロード ID に移行する必要があります。
ユーザー ベースのサービス アカウントをワークロード ID に移行する
サービス アカウントがワークロード ID への移行を開始する場合に使用されるユーザー アカウントを検出することをお勧めします。 多くの場合、移行では、ワークロード ID を使用するためにスクリプトと自動化プロセスを更新する必要があります。
サービス アカウントとして使用されているユーザー アカウントを含め、アプリケーションにサインインするすべてのユーザー アカウントを識別するために、必須の MFA が設定されていることを確認する方法を確認します。
これらのアプリケーションを使用した認証のために、ユーザー ベースのサービス アカウントからワークロード ID に移行する方法の詳細については、以下を参照してください。
- Azure CLI を使用してマネージド ID で Azure にサインインする
- Azure CLI を使用してサービス プリンシパルで Azure にサインインする
- 自動化シナリオのために対話形式で Azure PowerShell にサインインします マネージド ID とサービス プリンシパルのユース ケースの両方に関するガイダンスが含まれています
一部のお客様は、ユーザー ベースのサービス アカウントに条件付きアクセス ポリシーを適用します。 ユーザー ベースのライセンスを再利用し、 workload ID ライセンスを追加して、ワークロード ID に Conditional Access を適用できます。
実装
ログイン時の MFA におけるこの要件は、管理者ポータル用に実装されます。 Microsoft Entra ID のログイン ログは、MFA 要件のソースとして示されます。
管理ポータルの必須 MFA は構成できません。 テナントで構成したアクセス ポリシーとは別に実装されます。
たとえば、組織が Microsoft の セキュリティの既定値群を保持することを選択し、現在はセキュリティの既定値群が有効になっている場合、Azure 管理には MFA が既に必要であるため、ユーザーに変更は表示されません。 テナントが Microsoft Entra で 条件付きアクセス ポリシーを使用して、ユーザーが MFA を使用して Azure ログインするための条件付きアクセス ポリシーが既にある場合、ユーザーに変更は表示されません。 同様に、Azure を対象としてより強力な認証 (フィッシングに強い MFA など) を必要とする厳格な条件付きアクセス ポリシーも、引き続き実行されます。 ユーザーには変更は表示されません。
実施フェーズ
MFA の実施は、次の 2 つのフェーズで適用されます。
フェーズ 1: 2024 年の後半から、MFA は Azure Portal、Microsoft Entra 管理センター、Microsoft Intune 管理センターにログインするために必要になります。 適用は、世界中のすべてのテナントに徐々に実施されます。 このフェーズは、Azure CLI、Azure PowerShell、Azure mobile app、IaC ツールなどの他の Azure クライアントには影響しません。
フェーズ 2: 2025 年初めから、Azure CLI、Azure PowerShell、Azure mobile app、IaC ツールへのサインインに対する 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が表示されます。 このメッセージには、電子メールおよびサービス正常性通知と同じ情報があります。
適用後、Microsoft Entra 多要素認証にバナーが表示されます。
外部認証方法と ID プロバイダー
外部 MFA ソリューションのサポートは、外部認証方法とプレビュー段階であり、MFA 要件を満たすために使用できます。 従来の条件付きアクセス カスタム コントロール プレビューでは、MFA 要件を満たしていません。 外部の認証方法プレビューに移行し、Microsoft Entra ID で外部ソリューションを使用する必要があります。
Active Directory フェデレーション サービス (AD FS) などのフェデレーション ID プロバイダー (IdP) を使用していて、MFA プロバイダーがこのフェデレーション IdP と直接統合されている場合は、MFA 要求を送信するようにフェデレーション IdP を構成する必要があります。
適用の準備により多くの時間を要求する
一部のお客様は、この MFA 要件の準備により多くの時間が必要になる場合があることを理解しています。 Microsoft は、複雑な環境や技術的な障壁を持つお客様に対し、テナントへの実施を 2025 年 3 月 15 日までに延期することを許可しています。
2024 年 8 月 15 日から 2024 年 10 月 15 日までの間に、グローバル管理者は Azure Portal にアクセスし、テナントに対する実施開始日を 2025 年 3 月 15 日に延期できます。 グローバル管理者は、このページで MFA 実施の開始日を延期する前に、昇格したアクセス権を持っている必要があります。
グローバル管理者は、適用の開始日を延期するすべてのテナントに対してこのアクションを実行する必要があります。
Azure Portal など、Microsoft サービスにアクセスするアカウントは、脅威アクターにとって非常に価値が高いターゲットであるため、実施の開始日を延期することでさらなるリスクにさらされます。 すべてのテナントが今すぐ MFA を設定し、クラウド リソースをセキュリティで保護することをお勧めします。
よく寄せられる質問
質問: テナントがテストのみに使用されている場合、MFA は必要ですか?
回答: はい、すべての Azure テナントに MFA が必要になり、例外はありません。
質問: すべてのユーザーまたは管理者のみに MFA が必須ですか?
回答: 前に記載されたアプリケーションにログインするすべてのユーザーは、アクティブ化または資格のある管理者ロール、あるいは有効なユーザー除外とは関係なく、MFA を完了する必要があります。
質問: ログインしたままにするオプションを選択した場合、MFA を完了する必要がありますか?
回答: はい。 サインインを選択した場合でも、これらの アプリケーションにサインインする前に MFA を完了する必要があります。
質問: この実施内容は B2B ゲスト アカウントに適用されますか?
回答: はい。クロステナント アクセスを使用して MFA 要求をリソース テナントに送信するように適切に設定されている場合、MFA はパートナー リソース テナントまたはユーザーのホーム テナントのいずれかから準拠する必要があります。
質問: 別の ID プロバイダーまたは MFA ソリューションを使用して MFA を実施しても、Microsoft Entra MFA を使用して実施しない場合、どの方法で準拠できますか。
回答: 複数認証要求を Microsoft Entra ID に送信するには、ID プロバイダー ソリューションを適切に構成する必要があります。 詳細については、「Microsoft Entra 多要素認証の外部方法のプロバイダー リファレンス」を参照してください。
質問: 必須の MFA のフェーズ 1 またはフェーズ 2 は、Microsoft Entra Connect または Microsoft Entra Cloud Sync と同期する機能に影響しますか?
回答 : いいえ。 同期サービス アカウントは、必須の MFA 要件の影響を受けません。 前に示した アプリケーションのみ サインインに MFA が必要です。
質問: オプトアウトできますか?
オプトアウトする方法はありません。このセキュリティ モーションは、Azure プラットフォームのすべての安全性とセキュリティにとって重要であり、クラウド ベンダー間で繰り返されています。 たとえば、「設計でセキュリティ保護: 2024 年に AWS は MFA 要件を強化」を参照してください。
実施開始日を延期するオプションはお客様に提供されます。 2024 年 8 月 15 日から 2024 年 10 月 15 日までの間に、グローバル管理者は Azure Portal にアクセスし、テナントに対する実施開始日を 2025 年 3 月 15 日に延期できます。 グローバル管理者は、このページで 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 を構成して展開する方法の詳細を参照してください。