はじめに
Microsoft 365 環境の運用には MFA を強制しない「緊急アクセス用アカウント」と呼ばれるアカウントを作成することが推奨されることをご存じの方も多いと思います。
一方で、最近 Azure や Entra などのポータルへのアクセスでは MFA が推奨され、さらには強制されるようになってきています。
これらの推奨は一見矛盾するため、考え方を整理してみたのでブログにまとめておきます。
緊急アクセス用アカウント
緊急アクセス用アカウントは、ブレーク グラス アカウント（Break Glass Account）とも呼ばれ、他のすべての管理者アカウントがロックアウトしてしまった際などの緊急時に使用することが想定されたアカウントのことです。
エレベーター内や消防設備などで非常時に押すボタンがガラス（実際にはプラスチックかもしれませんが）で覆われているのを見たことがあると思いますが、ガラスを壊す＝緊急時に使用するので「ブレーク グラス」と名付けられています。
緊急アクセス用アカウントには下記のような運用が推奨されています。（一例）
- グローバル管理者ロール（永続）を割り当てる
- ユーザー ID にはカスタム ドメインを使用せず *.onmicrosoft.com を使用する
- 条件付きアクセス ポリシーを適用しない
- サインイン アクティビティを監視する
管理者としてサインインしたり、別のユーザーのアカウントをアクティブ化できなくなるため、Microsoft Entra 組織から誤ってロックアウトされないようにすることが重要です。 複数の "緊急アクセス用アカウント" を組織に作成することにより、誤って管理アクセスが不可能になることによる影響を軽減できます。
Azure の MFA 強制
私たちネクストリードではお客様の Microsoft 365 や Azure 環境のセキュリティ監視を行っていますので、普段からどれだけ多くの攻撃が試行されるのかを理解しており、Micrsoft 365 や Azure に対する MFA 必須化については歓迎しています。
下記の URL にはこれまでと今後、どのようなスケジュールで Azure やその他のアプリケーションに MFA を強制していくかのロードマップが記載されていますのでぜひご覧ください。
Microsoft では、お客様に最高レベルのセキュリティを提供することに取り組んでいます。 利用できる最も効果的なセキュリティ対策の 1 つは、多要素認証 (MFA) です。 Microsoft の調査 によると、MFA はアカウントを侵害する攻撃の 99.2% 以上をブロックできることが示されています。
また、2025 年 9 月に MFA を適用できない基本認証（レガシー認証）が完全に廃止されることも発表されており、今後の大きな流れとしては Entra ID のすべての認証に MFA が必須になっていくものと思われます。
Exchange Onlineは 2025 年 9 月にクライアント申請 (SMTP AUTH) による基本認証のサポートを完全に削除すると発表しました。 お客様には、できるだけ早く SMTP AUTH で基本認証を使用しないようにすることを強くお勧めします。
緊急アクセス用アカウントの MFA をどうするか問題
緊急アクセス用アカウントは「全ての管理者アカウントが使えなくなった場合にテナント管理がロックアウトされる」リスクに対応するもので、MFA 強制は「アカウントが乗っ取られる」リスクに対応するものです。
当初、後者のリスク対応を優先して前者のリスク対応を犠牲にするようなもの、と考えていました。
しかし、ドキュメントをよく読んでいくうちに「MFA」という言葉の捉え方をより厳密にすることで両立できることに気づきました。
実際には「MFA を適用するな」ではなく、「電話ベースの MFA を適用するな」「他の管理者アカウントと同じ MFA を適用するな」という意味合いになります。
電話ベースの MFA を適用するな
前述のドキュメントには、緊急用アクセス アカウントを使用する理由として下記のように記載があるので、FIDO2 セキュリティ キーも使用すべきではないと考えていました。（セキュリティ キーも破損したり紛失したりして利用できなくなるリスクがあるので）
管理者が Microsoft Entra 多要素認証によって登録されていて、すべての個別デバイスを利用できないか、サービスを利用できない場合
しかし、ドキュメントに例示されているシナリオなどを見ると、どうやら電話網で障害が発生した場合に備えて電話ベースの MFA を適用すべきではない、という意味合いで書かれているようです。
他の管理者アカウントと同じ MFA を適用するな
また、同じドキュメントには下記のようにも記載があります。
他の管理者アカウントと同じ認証方法は決して使用しないでください。 たとえば、通常の管理者アカウントで、強力な認証に Microsoft Authenticator アプリを使用している場合、緊急用アカウントには FIDO2 セキュリティ キーを使用します
これは、他の管理者が使用する MFA の方法がロックアウトされてしまった場合に備えて、別の MFA の方法を使用できるようにしておく、ということです。
下記のドキュメントには ID の回復性を高めるための戦略について記載があります。
上図を見ていただくと、First Factor の Password in Entra ID は依存性が一つ（Entra ID Authentication Service）であることが示されており、Second Factor の Push Notification は依存性が 4 つであることが示されていて、このシナリオ（パスワードで認証した後にプッシュ通知で MFA する）では全体で 4 つのサービスに依存している（このうち 1 つでもサービス停止するとサインインできなくなる）ことが分かります。
上記を参考にしながら、緊急アクセス用アカウントには、他のユーザーや管理者と異なる依存性の認証方法を採用しましょうということです。
なお、下記のようにパスワードレス MFA の FIDO2 セキュリティ キー（パスキー）や Windows Hello for Business は Entra ID 認証サービスのみに依存しており MFA サービスに依存していないため、回復性に優れた認証方法と言えるようです。
前述の Azure MFA 必須化のドキュメントの後半に FAQ があり、FIDO2 セキュリティ キーについて下記のように「MFA 要件を満たす」という表現で書かれていますが、（MFA サービスを使っていないという観点で）セキュリティ キーは狭義の MFA ではないということにすると、「緊急アクセス用アカウントには MFA を強制しない」という原則が維持されているとも言えなくもないかなと思いました。
質問: "非常時" シナリオがある場合はどうすればいいですか?
回答: これらのアカウントを更新してパスキー (FIDO2) を使用するか、MFA の証明書ベースの認証を構成することをお勧めします。 どちらの方法も MFA 要件を満たしています。
まとめ
色々書いてきましたが、結論としては緊急アクセス用アカウントには 少なくとも FIDO2 セキュリティ キーを登録しておく！ というのがよさそうかなと思いました。
緊急アクセス用アカウントには条件付きアクセス ポリシーも適用しないため、紛失したり不用意に利用したりされないように、金庫などの物理的に安全な場所に保存しておくと良いと思います。（でもいざという時に開けられない可能性がある場合、「金庫を開ける」という依存性が増えますね・・）
そもそも緊急アクセス用アカウントを作っていないという組織もあると思いますし、既にあるけど正しく運用されていないという組織もたくさんあると思います。
このブログををきっかけに、リンクしているドキュメントにもよく目を通していただき、いざという時のための管理者アカウントの運用を考えていただけると幸いです。