Microsoft Entra IDで管理者がサインインできなくなる事態を防ぐには、通常の管理者アカウントとは別に、緊急アクセス管理者アカウントを少なくとも2つ用意し、条件付きアクセス・MFA・監視・定期テストまで含めて運用設計する必要があります。今回の公式情報では、単に「ブレークグラスアカウントを作る」だけでなく、ブロック系の条件付きアクセスから除外すること、フィッシング耐性のある認証方法を使うこと、90日ごとに検証することがより実務的な確認ポイントになります。(Microsoft Learn)
特に影響が大きいのは、グローバル管理者、Privileged Role Administrator、Microsoft Entra ID PIM、条件付きアクセス、Azure MonitorやMicrosoft Sentinelで監視を行っている管理部門です。開発者も、管理用ユーザーを自動化やスクリプトに使っている場合は、MFA必須化やROPC系認証の制約により見直しが必要です。(Microsoft Learn)
Microsoft Entraの緊急アクセス管理者アカウントとは
Microsoft Entraの緊急アクセス管理者アカウントとは、通常の管理者アカウントでサインインできない場合に、テナントの管理権限を回復するための特別な管理者アカウントです。
一般的には「ブレークグラスアカウント」と呼ばれます。通常運用で使うアカウントではなく、次のような非常時に限定して使います。
- フェデレーション先のIdPやAD FSが停止し、通常の管理者がサインインできない
- 管理者のMFA端末が利用不能になった
- 最新のグローバル管理者権限を持つ担当者が退職・異動し、管理権限を回復できない
- 災害や通信障害で電話・SMS・Authenticatorアプリが使えない
- PIMのロール有効化に承認が必要だが、承認者がいない
重要なのは、緊急アクセス管理者アカウントを「強力な管理者アカウントの予備」として安易に扱わないことです。グローバル管理者権限を持つ場合、テナント全体に対して非常に強い権限を持つため、通常利用・共有利用・作業代行に使うべきではありません。(Microsoft Learn)
2026年更新で管理者が押さえるべき主な変更点
今回の公式情報で特に確認すべきなのは、条件付きアクセス、セキュリティガードレール、監査・コンプライアンスに関する整理です。GitHub上の変更履歴では、2026年5月6日に「Conditional Access considerations」「Security guardrails summary」「Auditability and compliance」などのセクション追加・復旧が確認できます。(GitHub)
また、Microsoft Learnのページ表示では最終更新日が2026年5月26日と表示されています。公開・反映タイミングや地域差により日付の見え方が異なる可能性があるため、社内文書に転記する場合は「2026年5月下旬時点の公式情報」として扱うのが安全です。(Microsoft Learn)
| 確認ポイント | 以前の運用で起きやすい問題 | 2026年更新後に重視すべき対応 |
|---|---|---|
| 条件付きアクセス | すべての管理者に同じポリシーを適用し、緊急時にもブロックされる | サインインをブロック・制限する条件付きアクセスから緊急アクセスアカウントを除外する |
| MFA | 「緊急用だからMFAなし」で放置する | FIDO2パスキーまたは証明書ベース認証など、フィッシング耐性のある方法を使う |
| PIM | 緊急時にロール有効化の承認ができない | グローバル管理者ロールはeligibleではなく、永続的なactive割り当てにする |
| 監視 | 使われても気づけない | サインインログ・監査ログを監視し、使用時に通知する |
| 定期確認 | 作成後に放置し、いざという時に使えない | 少なくとも90日ごとにサインインと管理作業を検証する |
影響範囲：誰が何を確認すべきか
緊急アクセス管理者アカウントの見直しは、Microsoft Entra管理者だけの作業ではありません。条件付きアクセス、監査ログ、MFA、PIM、運用手順、退職者対応まで関係するため、複数の担当者で確認する必要があります。
Microsoft Entra管理者が確認すべきこと
Microsoft Entra管理者は、まず緊急アクセス管理者アカウントが存在するかを確認します。公式情報では、2つ以上の緊急アクセスアカウントを作成することが推奨されています。これらのアカウントは、オンプレミス環境から同期されたアカウントではなく、*.onmicrosoft.com ドメインを使うクラウド専用アカウントにする必要があります。(Microsoft Learn)
確認すべき項目は次の通りです。
| 項目 | 推奨状態 | 確認方法の例 |
|---|---|---|
| アカウント数 | 2つ以上 | Microsoft Entra管理センターのユーザー一覧 |
| アカウント種別 | クラウド専用 | UPNが onmicrosoft.com、同期元がオンプレではないことを確認 |
| ロール | グローバル管理者 | ロール割り当てを確認 |
| PIM設定 | permanent active | PIMでeligibleになっていないか確認 |
| 認証方法 | FIDO2または証明書ベース認証 | 認証方法ポリシーと登録状態を確認 |
| 条件付きアクセス | ブロック系ポリシーから除外 | 条件付きアクセスポリシーの対象・除外設定を確認 |
| 監視 | サインイン時に通知 | Azure Monitor、Microsoft Sentinelなどでアラート確認 |
セキュリティ担当者が確認すべきこと
セキュリティ担当者は、「使えること」と「使われたら気づけること」の両方を確認します。
緊急アクセスアカウントは、攻撃者に悪用されると被害が大きいアカウントです。一方で、厳しく制限しすぎると本来の役割を果たせません。このバランスを取るために、次の設計が必要です。
- 通常の管理者アカウントとは異なる認証方法を使う
- 使用できる担当者を明文化する
- 資格情報やセキュリティキーを耐火金庫など安全な場所に保管する
- 保管場所を1か所に集中させない
- 使用時は必ずログを保存し、事後レビューを行う
- 退職・異動があったら金庫の暗証番号やアクセス手順を更新する
公式情報では、緊急アクセスアカウントの使用後に、計画された訓練だったのか、実際の緊急対応だったのか、不正利用だったのかをレビューすることも示されています。(Microsoft Learn)
開発者・自動化担当者が確認すべきこと
開発者や自動化担当者は、管理者アカウントをスクリプトや自動処理に使っていないかを確認する必要があります。
MicrosoftのMFA必須化に関する公式情報では、Azure CLI、Azure PowerShell、IaCツール、REST APIなどを使うAzureリソース管理操作にも段階的にMFAの影響が広がることが説明されています。また、ユーザーアカウントをサービスアカウントとして使う運用は推奨されず、マネージドIDやサービスプリンシパルなどのワークロードIDへの移行が推奨されています。(Microsoft Learn)
特に注意したいのは次のケースです。
| 使い方 | リスク | 推奨対応 |
|---|---|---|
| 管理者ユーザーのIDとパスワードをスクリプトに保存 | MFAで動かなくなる、不正利用時の被害が大きい | マネージドIDまたはサービスプリンシパルへ移行 |
| ROPCフローでトークンを取得 | MFAと相性が悪く、今後の制約を受けやすい | MSALの推奨フローへ移行 |
| 緊急アクセスアカウントを自動化に利用 | 本来の緊急用途から外れる | 絶対に避ける |
| Azure CLIやPowerShellを古いまま使う | MFA要求時にエラーや操作不能が起きる可能性 | クライアントツールを更新し、事前にテスト |
緊急アクセス管理者アカウントは「人間が非常時に管理権限を回復するためのもの」です。自動処理の資格情報として使う設計は、セキュリティ面でも運用面でも避けるべきです。
緊急アクセス管理者アカウントの推奨構成
公式情報を実務向けに整理すると、推奨構成は次のようになります。
| 設定項目 | 推奨構成 | 理由 |
|---|---|---|
| アカウント数 | 2つ以上 | 1つが使えない場合の冗長性を確保する |
| アカウント形式 | クラウド専用アカウント | オンプレミスAD、AD FS、同期障害の影響を避ける |
| ドメイン | *.onmicrosoft.com | フェデレーションやカスタムドメイン障害への依存を減らす |
| ロール | グローバル管理者 | テナント復旧に必要な権限を確保する |
| PIM | active permanent | 緊急時に承認待ちで詰まることを防ぐ |
| 認証方式 | FIDO2パスキー、証明書ベース認証 | フィッシング耐性があり、MFA要件も満たせる |
| 条件付きアクセス | ブロック・制限系ポリシーから除外 | 緊急時にサインイン不能になるのを防ぐ |
| 利用端末 | PAWなどの安全な端末 | 高権限操作のリスクを下げる |
| 保管 | 複数の安全な物理保管場所 | 災害・紛失・単一障害点を避ける |
| 監視 | サインイン時に即時通知 | 不正利用や誤使用に早く気づける |
| 検証頻度 | 少なくとも90日ごと | 設定変更や人事異動による不具合を発見する |
条件付きアクセス設定で失敗しやすいポイント
今回の更新で最も実務影響が大きいのは、条件付きアクセスの扱いです。
緊急アクセス管理者アカウントは、条件付きアクセスを完全に無視してよいという意味ではありません。重要なのは、サインインをブロックまたは制限する条件付きアクセスポリシーから除外することです。レポート専用ポリシーはアクセスをブロックしないため、除外は不要とされています。(GitHub)
避けるべき設定例
次のような設定は、緊急時にアカウントが使えなくなる原因になります。
- すべてのユーザーを対象に「準拠済みデバイス必須」を強制している
- すべてのグローバル管理者に「特定の場所からのみ許可」を適用している
- Authenticatorアプリ前提のMFAを緊急アクセスアカウントにも要求している
- 条件付きアクセスの除外対象を個別アカウントで管理し、追加漏れがある
- テスト用のReport-onlyポリシーとブロック系ポリシーを区別せずに除外している
実務では、緊急アクセスアカウント専用のセキュリティグループ、たとえば EmergencyAccess のようなグループを作成し、そのグループをブロック・制限系ポリシーの除外対象にする設計が分かりやすいです。公式情報でも、専用セキュリティグループの利用が推奨されています。(GitHub)
条件付きアクセス除外の確認手順
| 手順 | 確認内容 |
|---|---|
| 1 | Microsoft Entra管理センターで緊急アクセスアカウントを一覧化する |
| 2 | 専用セキュリティグループに緊急アクセスアカウントを登録する |
| 3 | すべての条件付きアクセスポリシーを確認する |
| 4 | 「ブロック」「MFA必須」「準拠済みデバイス必須」「場所制限」など、サインインを妨げる可能性があるポリシーを抽出する |
| 5 | 対象ポリシーの除外に専用グループを追加する |
| 6 | Report-onlyポリシーはブロックしないため、除外が本当に必要かを分けて判断する |
| 7 | テストサインインを行い、緊急アクセスアカウントが利用可能か確認する |
| 8 | サインイン時に監視アラートが発報されるか確認する |
条件付きアクセスの変更は、本番ユーザーへの影響も大きいため、変更前後のポリシーエクスポート、変更理由、承認者、テスト結果を残しておくと監査対応にも役立ちます。
MFAと認証方式：FIDO2または証明書ベース認証を優先する
緊急アクセス管理者アカウントでは、通常の管理者アカウントと同じ認証方法を使わないことが重要です。
たとえば、通常の管理者がMicrosoft Authenticatorアプリを使っている場合、緊急アクセスアカウントにも同じスマートフォン依存の方法を使うと、スマートフォン紛失・通信障害・Authenticator利用不能時に両方とも使えなくなる可能性があります。
公式情報では、緊急アクセスアカウントのパスワードレス認証方法として、Passkey（FIDO2）と証明書ベース認証が示されています。FIDO2は推奨、証明書ベース認証は組織にPKI環境がある場合の選択肢です。(Microsoft Learn)
| 認証方式 | 向いている組織 | 注意点 |
|---|---|---|
| FIDO2セキュリティキー | 多くの組織で導入しやすい | キーの物理保管、予備キー、対応端末の確認が必要 |
| 証明書ベース認証 | 既にPKIを運用している組織 | 証明書の有効期限、失効管理、端末依存を確認する |
| Authenticatorアプリ | 通常管理者には有効 | 緊急アクセス用としては個人端末依存になりやすい |
| SMS・音声通話 | 一時的な代替としては使える場合がある | 通信障害やSIM紛失に弱く、緊急時の信頼性は高くない |
MFA必須化の観点でも、緊急アクセスアカウントは例外ではありません。MicrosoftのMFA必須化に関する公式情報では、ブレークグラスまたは緊急アクセスアカウントもMFAが必要になり、FIDO2または証明書ベース認証が推奨されています。(Microsoft Learn)
PIM設定：eligibleではなくactive permanentを確認する
Microsoft Entra Privileged Identity Management（PIM）を使っている環境では、ロールを常時付与せず、必要な時だけ有効化する設計が一般的です。しかし、緊急アクセス管理者アカウントでは注意が必要です。
公式情報では、緊急アクセスアカウントのグローバル管理者ロールは、eligibleではなく、active permanentとして割り当てるべきとされています。(Microsoft Learn)
理由は単純です。緊急時にロール有効化の承認者がいない、承認プロセスが動かない、MFA端末が使えない、といった状況では、PIMの有効化自体ができない可能性があります。
確認すべきPIM設定
| 確認項目 | NG例 | 推奨 |
|---|---|---|
| ロール状態 | eligibleのみ | active permanent |
| 承認設定 | 承認者不在でも有効化が必要 | 緊急アクセスアカウントでは承認に依存しない |
| MFA要求 | 通常管理者と同じ端末依存 | FIDO2または証明書ベース認証 |
| アクセスレビュー | 一度も確認していない | 定期的に対象・利用者・保管者を確認 |
PIMを厳格に運用している組織ほど、緊急アクセスアカウントだけは別の設計思想が必要です。通常時の最小権限と、非常時の回復可能性を混同しないことが重要です。
監視とアラート：使われた瞬間に気づける状態にする
緊急アクセス管理者アカウントは、使われないことが理想です。だからこそ、使われた場合は即座に検知できる必要があります。
公式情報では、Microsoft Entraのサインインログと監査ログを監視し、緊急アクセスアカウントがサインインした際に管理者へ通知することが推奨されています。Azure Monitor、Microsoft Sentinel、その他の監視ツールを利用できます。(Microsoft Learn)
Azure Monitorで監視する場合の基本的な流れ
| 手順 | 内容 |
|---|---|
| 1 | Microsoft EntraのサインインログをAzure Monitorに送信する |
| 2 | 緊急アクセスアカウントのObject IDを取得する |
| 3 | Log Analyticsワークスペースでカスタムログ検索を作成する |
| 4 | SigninLogs を対象に該当Object IDのサインインを検出する |
| 5 | 検出件数が0を超えたらアラートを発報する |
| 6 | アクショングループでメール、SMS、Push、音声通知などを設定する |
| 7 | 重要度を高く設定し、検知後の確認フローを決める |
クエリの考え方はシンプルです。緊急アクセスアカウントの UserId または UserPrincipalName を条件に、サインインログを検索します。公式情報でも、Object IDまたはUPNを使った SigninLogs のサンプルが示されています。(GitHub)
SigninLogs
| project UserId, UserPrincipalName, CreatedDateTime, IPAddress, AppDisplayName
| where UserId == "緊急アクセスアカウントのObject ID"実務では、アラートが鳴った後の対応手順も決めておく必要があります。
- 誰が一次確認するのか
- 訓練利用か、実際の障害対応か、不正利用かをどう判定するのか
- 利用者にどう確認するのか
- 実行された操作をどのログで追跡するのか
- 不正利用の場合、どの順序で無効化・パスワード変更・証明書失効を行うのか
アラートを作るだけでは不十分です。通知を受けた後に、誰が、何分以内に、どのログを確認するかまで運用に落とし込む必要があります。
90日ごとの検証で確認すること
緊急アクセス管理者アカウントは、作成した時点では正しく動いていても、数か月後に使えなくなることがあります。条件付きアクセスの変更、MFAポリシーの変更、証明書期限、セキュリティキーの紛失、担当者の異動などが原因です。
公式情報では、少なくとも90日ごと、IT担当者の変更後、Microsoft Entraサブスクリプション変更後に検証を行うことが示されています。(GitHub)
定期検証チェックリスト
| 確認項目 | チェック内容 |
|---|---|
| サインイン | 緊急アクセスアカウントでサインインできるか |
| 管理作業 | 必要な管理タスクを実行できるか |
| 認証方法 | FIDO2キーや証明書が失効・破損していないか |
| 条件付きアクセス | 新しいポリシーでブロックされていないか |
| 監視 | サインイン時にアラートが通知されるか |
| 保管 | 資格情報やキーが所定の場所にあるか |
| 利用権限者 | 退職者・異動者が含まれていないか |
| 手順書 | 最新の画面・ポリシー・連絡先に更新されているか |
| 端末 | 指定の安全な端末から操作できるか |
| 事後レビュー | 訓練結果が記録され、改善点が反映されているか |
検証では、単にサインインできるかだけでなく、「本当に障害時に使えるか」を確認します。たとえば、社内ネットワークが使えない想定、通常の管理者端末が使えない想定、承認者に連絡できない想定など、現実的なシナリオで訓練することが重要です。
移行・展開時の注意点
既存環境に緊急アクセス管理者アカウントを導入または見直す場合は、いきなり本番ポリシーを変更するのではなく、段階的に進めます。
推奨する展開手順
| フェーズ | 作業内容 | 成果物 |
|---|---|---|
| 現状調査 | 管理者アカウント、PIM、条件付きアクセス、MFA方式を棚卸し | 現状一覧、リスク一覧 |
| 設計 | アカウント数、認証方式、保管方法、利用者、監視方法を決定 | 設計書、運用ルール |
| 作成 | クラウド専用アカウントを2つ以上作成 | 緊急アクセスアカウント |
| 権限設定 | グローバル管理者をactive permanentで付与 | ロール設定記録 |
| 認証設定 | FIDO2または証明書ベース認証を登録 | 認証方法登録記録 |
| CA確認 | ブロック・制限系条件付きアクセスから除外 | ポリシー変更記録 |
| 監視設定 | サインイン検知アラートを作成 | アラートルール |
| テスト | サインイン、管理操作、通知、事後レビューを実施 | テスト結果 |
| 運用化 | 90日ごとの点検、退職時対応、訓練計画を設定 | 運用手順書 |
既存の緊急アクセスアカウントを見直す場合
既にブレークグラスアカウントを作成済みでも、次のような状態なら見直しが必要です。
- 1アカウントしかない
- オンプレミスADから同期されている
- カスタムドメインのUPNを使っている
- パスワードだけでサインインできる
- 個人のスマートフォンにMFAが紐づいている
- 条件付きアクセスの除外が個別設定で管理されている
- PIMでeligibleになっている
- 監視アラートがない
- 最後にテストした日が分からない
- 退職者が保管場所や手順を知っている可能性がある
この場合は、既存アカウントをそのまま延命するより、公式情報に沿って新しい構成を作り、テスト後に旧手順を廃止するほうが安全です。
よくある疑問
緊急アクセスアカウントはMFAなしでもよい？
MFAなしで運用するのは避けるべきです。Microsoftの公式情報では、緊急アクセスアカウントにもMFA要件が適用され、FIDO2または証明書ベース認証が推奨されています。(Microsoft Learn)
ただし、通常管理者と同じスマートフォン依存のMFAにすると、同じ障害で両方使えなくなる可能性があります。そのため、フィッシング耐性があり、個人端末に依存しにくい方法を選ぶのが実務的です。
条件付きアクセスから完全に除外すべき？
公式情報の最新の表現では、緊急アクセスアカウントは「すべての条件付きアクセス」ではなく、サインインをブロックまたは制限する条件付きアクセスポリシーから除外する、という整理になっています。Report-onlyポリシーはアクセスをブロックしないため、除外は不要です。(GitHub)
つまり、除外対象を雑に広げるのではなく、「このポリシーは緊急時のサインインを妨げるか」という観点で判断します。
グローバル管理者を常時付与して大丈夫？
緊急アクセスアカウントでは、PIMのeligibleではなくactive permanentが推奨されています。ただし、これは通常利用してよいという意味ではありません。使われたら即検知し、使用理由と実行操作を必ずレビューする前提で設計します。(Microsoft Learn)
2つ以上必要なのはなぜ？
1つだけでは、資格情報の紛失、FIDO2キーの故障、証明書の問題、設定ミス、保管場所の被災などで使えない可能性があります。2つ以上用意することで、単一障害点を減らせます。(Microsoft Learn)
管理者が今すぐ確認すべき対応ポイント
Microsoft Entraの緊急アクセス管理者アカウントは、障害発生後に作るものではありません。正常にサインインできる今のうちに、設計・作成・除外・監視・訓練まで完了しておく必要があります。
まず確認すべきことは、次の5つです。
- 緊急アクセス管理者アカウントが2つ以上あるか
- クラウド専用の
*.onmicrosoft.comアカウントになっているか - FIDO2または証明書ベース認証を使っているか
- ブロック・制限系の条件付きアクセスから除外されているか
- サインイン時にアラートが発報され、90日ごとに検証されているか
この5つのうち1つでも未対応なら、緊急時にMicrosoft Entraテナントへ入れなくなるリスクがあります。特に、条件付きアクセスとPIMは「セキュリティを強化したつもりで、非常時の復旧経路を塞ぐ」典型的な失敗ポイントです。
最初の一歩として、現在のグローバル管理者、条件付きアクセスポリシー、PIM割り当て、MFA登録状況を棚卸しし、緊急アクセス管理者アカウント専用の設計書を作成してください。そのうえで、作成・監視・訓練までを1つの運用プロセスとして定着させることが、Microsoft Entraの管理ロックアウトを防ぐ最も現実的な対策です。
コメント