2025年に入り、Microsoft Entra ID（旧 Azure AD）を対象とした「必須 MFA（多要素認証）」の段階的な強制が本格化しています。特に Entra Free かつ「セキュリティの既定（Security Defaults）」を利用している小規模テナントでは、「ブレークグラス管理者や Enabled のユーザーをどう扱えばよいのか？」という疑問が急増しています。本記事では、具体的な 4 アカウント構成のケースを題材に、Phase 2 の MFA 強制に向けた現実的な対応方法を詳しく解説します。
Phase 2 の MFA 強制とは何か（ざっくり整理）
まず前提として、Microsoft は 2024 年以降、Azure や Microsoft 365 の管理系ポータルに対して段階的に「必須 MFA」を導入しています。これは 既存の MFA 設定（ユーザー単位 MFA／条件付きアクセス）に関わらず、対象アプリ側が「サインイン前に MFA 済みであること」を直接チェックする仕組みです。
| フェーズ | 開始時期（目安） | 主な対象 | ポイント |
|---|---|---|---|
| Phase 1 | 2024 年 10 月～段階的展開 | Azure ポータル、Microsoft Entra 管理センター、Intune 管理センター、Microsoft 365 管理センター | 管理ポータルへのサインイン時に MFA が必須 |
| Phase 2 | 2025 年 10 月 1 日 以降段階的展開 | Azure CLI / PowerShell / Azure モバイル アプリ / IaC ツール / Azure 管理系 REST API など | リソース管理操作（Create / Update / Delete）前に MFA が必須 |
重要なのは、次の 3 点です。
- Azure 管理操作（ポータル／CLI／IaC など）を行う「すべてのユーザー」が対象（管理者ロールの有無に依存しない）
- ブレークグラス（緊急用）アカウントも必ず MFA でサインインする必要がある
- テナント単位で「完全に除外」する方法は存在せず、猶予（延期）申請のみ
つまり、これまで一部で採用されていた「MFA 無効のブレークグラス管理者で最後の逃げ道を確保する」という設計は、Phase 2 以降は通用しなくなります。
Microsoft Entra Free ＋ セキュリティの既定テナントの前提
セキュリティの既定（Security Defaults）の役割
Entra Free テナントで最も多い構成が、「条件付きアクセスは未使用」「代わりにセキュリティの既定（Security Defaults）を有効」というパターンです。セキュリティの既定は、次のようなプリセット ポリシーの集合です。
- すべてのユーザーに MFA 登録を要求
- 管理者ロールを持つユーザーには毎回 MFA を要求
- 必要に応じて一般ユーザーにも MFA を要求
- レガシー認証（IMAP/POP/SMTP 基本認証など）のブロック
- Azure ポータル／Entra 管理センター／Azure PowerShell／Azure CLI の保護
セキュリティの既定はライセンス不要で利用でき、Entra Free テナント向けの「基本防御セット」として公式に案内されています。
ユーザー単位 MFA（Enabled / Enforced）の位置づけ
一方で、古くから存在する「ユーザー単位 MFA」には、次の 3 状態があります。
| 状態 | 意味 | 特徴 |
|---|---|---|
| Disabled | ユーザー単位 MFA の対象外 | デフォルト状態。MFA 要求は Security Defaults や CA 側が決める |
| Enabled | MFA 対象に登録済みだが、登録未完了の可能性あり | 次回サインイン時に登録を促される（登録後 Enforced へ自動移行） |
| Enforced | MFA 登録完了かつ常に MFA を要求 | ブラウザ サインイン・一部レガシーアプリ利用で MFA が必須 |
しかし Microsoft は、Security Defaults や条件付きアクセスを使う場合は「ユーザー単位 MFA を触らない」ことを推奨しています。 セキュリティの既定が有効なテナントでは、たとえユーザー単位 MFA の画面に Enabled / Enforced が表示されていても、実際の MFA 要求は Security Defaults と「必須 MFA（Phase 1 / Phase 2）」の側で決まるイメージです。
今回のサンプル テナント構成
本記事で扱う前提は次のとおりです。
- Microsoft Entra テナント：Entra ID Free
- セキュリティの既定：有効
- ユーザー構成（4 名）
- A さん：管理者アカウント（MFA Enforced）
- B さん：管理者アカウント（MFA Enforced）
- C さん：管理者アカウント（MFA Enabled）
- D さん：ブレークグラス管理者（緊急用）、ユーザー単位 MFA は Disabled
- これら 4 アカウントは「アプリのログイン用サービス アカウントとしては使用していない」
| ユーザー | ロール | ユーザー単位 MFA 状態 | 用途 |
|---|---|---|---|
| A | グローバル管理者 | Enforced | 日常の管理作業 |
| B | グローバル管理者 | Enforced | 日常の管理作業 |
| C | 管理者（何らかのロール） | Enabled | 管理作業も実施予定 |
| D | グローバル管理者（ブレークグラス） | Disabled | 緊急時のみ使用 |
この構成で「Phase 2 の MFA 強制に向けて、C さん（Enabled）と D さん（ブレークグラス）をどうすべきか？」が今回のテーマです。
結論：管理作業に使うアカウントは「すべて」MFA 登録必須（ブレークグラスも例外なし）
先に結論を書きます。
- Azure / Entra / Intune / Microsoft 365 管理ポータル、CLI、PowerShell などで管理操作を行うアカウントは、必ず MFA 登録済みでなければならない
- ブレークグラス（緊急用）管理者も例外ではなく、最低 1 つ以上の MFA 方法（できれば複数）を登録する必要がある
- ユーザー単位 MFA の Enabled / Enforced の違いで Phase 2 を回避することはできない（アプリ側の強制なので）
つまり、C さん（Enabled のままの管理者）も D さん（ブレークグラス管理者）も、「MFA をしない管理アカウント」として残しておくことはできません。 そのうえで、どのように設計を見直せばよいかを具体的に解説していきます。
ブレークグラス管理者アカウントの具体対応
ステップ 1：ブレークグラスにも必ず MFA を登録する
Phase 2 では、Microsoft 自身が「ブレークグラス（緊急用）アカウントも MFA が必須」と明言しています。 したがって、現在ユーザー単位 MFA が Disabled の D さんにも、次のような MFA 方法を必ず登録してください。
- 第一候補：FIDO2 セキュリティキー（パスキー）
- ブレークグラス用アカウントに最適な「パスワードレス＋物理トークン」
- キーを複数本用意し、別々の金庫に保管しておくと盤石
- 第二候補：Microsoft Authenticator（プッシュ通知 or TOTP）
- ブレークグラス運用では、特定の個人スマホではなく「専用端末」に入れて物理的に保管する運用が望ましい
- 補助候補：電話／SMS 認証
- 番号変更や SMS 遅延のリスクがあるため、単独ではなくあくまで補助要素として利用
ポイントは、通常の管理者が使う MFA 方法と「依存先をずらす」ことです。例えば、普段の管理者が Authenticator アプリを自分のスマホに入れているなら、ブレークグラスは FIDO2 キーを中心に構成し、「同じスマホが壊れたら両方ダメになる」という事態を避けます。
ステップ 2：ブレークグラス設計を Phase 2 前提にアップデートする
Microsoft の推奨は、クラウド専用の緊急アクセスアカウントを最低 2 つ以上作成することです。 Entra Free テナントでも同じ考え方で設計できます。
| 項目 | 推奨方針 | 理由 |
|---|---|---|
| アカウント数 | 2 アカウント以上 | どちらか 1 つが使えなくなっても、もう 1 つで復旧可能にする |
| ドメイン | [email protected] のクラウド専用 | フェデレーション／ADFS 障害の影響を受けないようにする |
| ロール | グローバル管理者（必要なら PIM で恒久アクティブ） | 「完全にロックアウトしたときに最後に触れる」ためのフル権限 |
| MFA 方法 | FIDO2 セキュリティキー ＋ 予備方法（Authenticator など） | 必須 MFA とフィッシング耐性の両方を満たし、端末依存も減らす |
| 利用頻度 | 通常時はログイン禁止（テスト時のみ使用） | 不必要な利用はリスク増加のため、原則封印 |
| 保管 | ID / パスワード / キーを印刷 or 封筒に入れ、金庫で保管 | 人的な漏えい・紛失リスクを下げるため |
今回の D さんは、上記のうち 1 アカウント目として位置づけられます。可能であれば、別の管理者が保有する 2 つ目のブレークグラス アカウントも新規に用意しましょう。
ステップ 3：四半期ごとのテストとサインイン監査
ブレークグラスは「使う日が来ないことが一番良い」アカウントですが、いざというときに使えなければ意味がありません。Microsoft も、少なくとも 90 日ごとの定期検証を推奨しています。
- 周知
- セキュリティ担当・監視担当に「ブレークグラス動作確認テスト」を実施することを事前に伝える
- テスト サインイン
- ブレークグラス アカウントで Azure ポータルへサインイン
- 実際に MFA が要求され、登録した方法で正しく認証できるかを確認
- 簡単な管理操作を実行
- ユーザー属性の閲覧や一時的なロール付与など、「いざという時にやりたい操作」を 1～2 個試す
- サインインログの確認
- Entra 管理センター → 監視 & トラブルシューティング → サインイン で、ブレークグラスのサインイン記録を確認
- アラート（Log Analytics / Sentinel 等）を設定している場合は、通知が正しく飛ぶかも確認
このテスト結果は、運用手順書と一緒に保管しておくと、監査対応や引き継ぎ時にも役立ちます。
Entra Free で「MFA 無効ブレークグラス」は事実上無理
「ブレークグラスだけは MFA を完全免除したい」という相談もよくありますが、Entra Free ＋ セキュリティの既定の組み合わせではほぼ不可能です。
- Security Defaults では、管理者に対する MFA は強制であり、個別除外はできない
- ブレークグラスの除外を行いたい場合は、条件付きアクセス（Entra ID P1 以上）が前提であり、Free では利用できない
- さらに、必須 MFA（Phase 1 / Phase 2）はアプリ側のチェックであるため、ポリシー側で免除してもアプリが MFA を要求してしまうケースがある
したがって、今後の設計思想としては、
- 「MFA 無しでログインできるアカウント」を残す発想を捨てる
- 「通常とは依存の異なる MFA で守られた安全なブレークグラス」へとシフトする
これが、Phase 2 時代のブレークグラス設計のゴールです。
「MFA 有効（Enabled）」ユーザーの扱い方
次に、C さん（ユーザー単位 MFA が Enabled で止まっている管理アカウント）をどうすべきかを整理します。
ステップ 1：まずは MFA 登録を完了させる
Enabled のままということは、「MFA 対象にはしているが、登録が完了していない／状態が Enforced に遷移していない」可能性が高い状態です。 Phase 2 までの間に、次の手順で登録を完了させましょう。
- C さん本人で、通常どおりサインイン（ポータルや
https://myprofile.microsoft.comなど） - 画面の指示に従い、Microsoft Authenticator を登録
- 可能なら、このタイミングで FIDO2 セキュリティキーも同時に登録
- 別ブラウザー（InPrivate ウィンドウなど）で再度サインインし、「MFA が必ず要求される」ことを確認
登録が完了すると、しばらくしてユーザー単位 MFA の状態が Enforced に変わります（自動で変わらない場合は管理者が手動変更も可）。
ステップ 2：運用方針を決める – per-user MFA 継続か、Security Defaults 一本化か
Entra Free ＋ Security Defaults テナントでは、次の 2 パターンが考えられます。
| パターン | 概要 | メリット | デメリット |
|---|---|---|---|
| A. ユーザー単位 MFA を継続 | 管理者だけ per-user MFA Enforced のまま運用 | 「管理者は毎回 MFA」という挙動がわかりやすい | Security Defaults と挙動が重複し、どちらが効いているのか分かりにくい |
| B. Security Defaults に一本化（推奨） | 全ユーザーのユーザー単位 MFA を Disabled に揃え、MFA 要求は Security Defaults に任せる | 設定箇所が 1 箇所になり、トラブルシュートが容易。Microsoft の最新推奨に沿う | 「ユーザー単位 MFA の画面だけ見ても、Enabled/Enforced ではない」ので戸惑う人がいる |
Microsoft の公式ドキュメントは、Security Defaults または条件付きアクセスを利用している場合、ユーザー単位 MFA は触らないことを推奨しています。 そのため、長期的には パターン B（Security Defaults に一本化）に寄せるのがおすすめです。
現実的な進め方は次のようになります。
- 全管理者（A さん、B さん、C さん、D さん）が少なくとも 1 つ以上の MFA 方法を登録済みであることを確認
- メンテナンス時間帯を確保し、ユーザー単位 MFA の管理画面で、該当管理者の状態を Disabled に揃える
- InPrivate ブラウザーから管理ポータルにサインインし、セキュリティの既定によって MFA が要求されることを検証
- 問題なければ、他のユーザーも順次 Disabled に揃えていく（必要であれば）
画面パスの一例（確認と登録）
操作手順の一例をまとめます。
- 管理権限の確認
- Entra 管理センター → 「ID」→「ロールと管理者」 から、管理ロールが付与されているユーザーを確認
- MFA 登録状況の確認
- Entra 管理センター → 「保護」→「認証方法」→「登録の詳細」 で、ユーザーごとの登録済み MFA 方法を確認
- ユーザー単位 MFA 状態の確認／変更
- Entra 管理センター → 「ユーザー」→「すべてのユーザー」→「Per-user MFA」
- 対象ユーザーを選択し、ユーザー MFA 設定から Enabled / Enforced / Disabled を確認・変更
- ユーザー側で MFA 方法を追加
- ユーザー本人が 「マイ サインイン」ページ（
https://mysignins.microsoft.com） へアクセス - 「セキュリティ情報」から Microsoft Authenticator や FIDO2 キーを追加
- ユーザー本人が 「マイ サインイン」ページ（
Phase 2 に向けた全体チェックリスト（最小合格ライン）
ここまでの内容を踏まえ、Phase 2 前に最低限クリアしておきたいチェック項目を一覧にします。
| チェック項目 | 具体的にやること |
|---|---|
| 管理者アカウントの洗い出し | Entra 管理センターで管理ロール（特にグローバル管理者）をすべて列挙 |
| MFA 登録の有無 | 「認証方法 → 登録の詳細」で各管理者に少なくとも 1 つ以上の MFA が登録されているか確認 |
| MFA 方法の多重化 | 各管理者に対して、Authenticator ＋ FIDO2 キーなど2 種類以上の方法を登録 |
| ブレークグラス設計 | クラウド専用ブレークグラスを 2 アカウント以上用意し、FIDO2 キーで保護。資格情報とキーを金庫で保管 |
| 四半期ごとのテスト | 少なくとも 90 日に一度、全ブレークグラスでサインイン＋簡単な管理操作を実施し、ログを確認 |
| サービスアカウントの棚卸し | ユーザー アカウントが Azure CLI / PowerShell / スクリプトに使われていないか確認。使われている場合はマネージド ID / サービスプリンシパルへの移行計画を作る |
| Security Defaults の状態確認 | 「Entra ID → プロパティ → セキュリティの既定の管理」で Enabled になっていることを確認 |
| ユーザー単位 MFA 整理 | 運用方針（per-user 継続 or Security Defaults 一本化）に応じて、Enabled / Enforced のユーザーを整理 |
| ドキュメント整備 | 連絡フロー、金庫の場所、キーの本数、テスト手順をまとめた運用ドキュメントを作成・保管 |
よくある疑問と回答（FAQ）
Q1. セキュリティの既定を有効にしていれば、Phase 2 の必須 MFA 条件は満たせますか？
A. 基本的には YES ですが、「必ずユーザーが MFA 登録を済ませていること」が前提です。
- Security Defaults 自体が、Azure ポータル／Entra 管理センター／Azure CLI などのアクセスに MFA を要求するプリセットになっています。
- 必須 MFA（Phase 1 / Phase 2）は「アプリ側の最終チェック」なので、Security Defaults による MFA 要求と相性が良い（むしろ事前に満たしておくための仕組み）です。
逆に言うと、Security Defaults が有効なだけで、ユーザーが MFA 登録を一切していない状態では、強制開始後に大量のサインイン失敗が発生するリスクがあります。今のうちに登録を終わらせておきましょう。
Q2. 管理者ではないユーザーも対象になりますか？
A. 「Azure リソースを管理する操作を行うかどうか」で決まります。
- 必須 MFA は、「Azure ポータルや CLI でサブスクリプション／リソースを操作するすべてのアカウント」が対象です。
- ロールが閲覧専用であっても、対象アプリにサインインする以上は MFA が必要になります。
そのため、開発者や運用担当者が Azure CLI や PowerShell を使っているなら、管理者とほぼ同じレベルで MFA 登録・テストを行う必要があります。
Q3. テスト用テナントなら MFA は不要では？
A. 残念ながら、テスト用テナントも例外ではありません。 Microsoft は「すべての Azure テナントに必須 MFA を適用する」と明言しており、テスト用途だからといって免除されることはありません。
Q4. サードパーティ IdP や外部 MFA を使っている場合は？
A. その場合でも、Azure 側が「MFA 済みである」というクレーム（multipleauthn など）を受け取れるように構成する必要があります。 詳細は Microsoft の「外部認証方法」ドキュメントで整理されていますが、Entra Free かつ Security Defaults 前提の小規模テナントでは、まずは Microsoft Entra MFA（Authenticator / FIDO2）で標準構成に寄せるのが現実的です。
まとめ：Phase 2 時代の「管理アカウントとブレークグラス」のあるべき姿
最後に、本記事のポイントを短くまとめます。
- Phase 2 の必須 MFA は、既存の MFA 設定に関係なく、Azure 管理操作を行うすべてのユーザーに MFA を強制する
- ブレークグラス管理者も例外ではなく、FIDO2 キーなどで MFA 登録を完了させておく必要がある
- Entra Free ＋ Security Defaults では「MFA 無効ブレークグラス」を維持するのは現実的でなく、「通常とは異なる MFA による緊急アカウント」へ設計を変えることが重要
- C さんのように「MFA Enabled のまま」の管理アカウントは、早急に MFA 登録を完了させ、Phase 2 前には Enforced または Security Defaults ベースの運用に統一しておく
- サービスアカウント用途でユーザー アカウントを使っている場合は、Phase 2 で動かなくなる可能性が高いため、マネージド ID やサービスプリンシパルへの移行を急ぐ
- すべての管理者アカウントについて、複数の MFA 方法・定期テスト・ログ監査・文書化をセットで実施することが、Free テナントでも実践できる現実的なセキュリティ対策になる
「Enabled / Enforced / Disabled」というラベルに振り回されるのではなく、 「このアカウントは、本当に今すぐ MFA 付きでサインインできるのか？」 という一点を軸に、Phase 2 時代に耐えられるアカウント設計へアップデートしていきましょう。
コメント