緊急用管理者アカウントの棚卸し ─ break glassを安全に運用する初動確認

冒頭要約

緊急用管理者アカウント、いわゆる break glass account は、IdP障害、条件付きアクセス設定ミス、MFA障害、管理者退職などで通常の管理者が使えなくなったときに、最低限の復旧操作を行うための非常用経路です。

一方で、非常用アカウントは強い権限を持ちやすく、常用・共有・監査不足になると、普段の管理者アカウントより危険な抜け道になります。Microsoftの公式ドキュメントでも、緊急アクセスアカウントは通常時に使うものではなく、保管、監視、定期検証、利用後レビューを含めて管理する前提で説明されています。

まず確認すべきことは、「非常時に本当に使えるか」と「平時に勝手に使われていないか」の両方です。作成数、保管場所、認証方式、条件付きアクセスの扱い、利用権限者、監査ログ通知、定期訓練、利用後の記録をセットで棚卸しします。

---

読者別の影響：誰が何を確認するか

緊急用管理者アカウントは、IdPチームだけの問題ではありません。Microsoft EntraやGoogle Workspaceの管理者、GitHub Organization owner、クラウド管理者、CSIRT、監査担当が同じ台帳を見られる状態にしておく必要があります。

読者・担当者	主な関心	まず確認すること
情シス・IdP管理者	ロックアウト時の復旧経路	緊急用アカウントの数、認証方式、保管場所、条件付きアクセス除外
SaaS管理者	Microsoft 365、Google Workspace、Slackなどの管理継続	Super Admin、Global Administrator、請求管理者、サービス管理者の過不足
開発者・DevOps	GitHub、CI/CD、クラウド管理の継続性	Organization owner、リポジトリ管理者、緊急時の権限移管
CSIRT・SOC	不審利用の検知と初動	サインインログ、監査ログ、通知、利用後レビュー、操作内容
監査・管理部門	説明責任と例外管理	利用条件、承認者、訓練記録、保管証跡、権限棚卸しの履歴

ここで重要なのは、「緊急用アカウントを作ること」と「管理者権限を増やすこと」を混同しないことです。通常時は PAM や JIT Access を使い、必要なときだけ一時的に権限を有効化するのが基本です。緊急用アカウントは、その仕組み自体が使えない場面に備える最後の復旧経路として扱います。

---

まず確認すること：緊急用管理者アカウントの10項目

棚卸しでは、アカウントが存在するかだけでなく、非常時に使えるか、平時に誤用されないか、使われたときに追跡できるかを確認します。

確認項目	見るポイント
1. 対象サービス	Microsoft Entra、Google Workspace、GitHub、クラウド、DNS、MDM、監視基盤など
2. アカウント数	単一障害点を避けるため、主要基盤ごとに継続管理できる人数・アカウントがあるか
3. 権限範囲	全体管理者か、限定管理者か、復旧に必要な最小範囲か
4. 認証方式	通常管理者と同じ認証依存に寄りすぎていないか、フィッシング耐性のある方法を使えるか
5. 条件付きアクセス	緊急時にブロックされない設計か、除外理由と範囲を説明できるか
6. 保管方法	認証器、回復情報、鍵、手順書が複数人で安全に取り出せる場所にあるか
7. 利用権限者	誰が、どの条件で、誰に連絡して使うのかが明確か
8. 監査ログ	サインイン、権限変更、設定変更、API利用、GitHub owner操作を追えるか
9. 通知	緊急用アカウント利用時に、管理者・CSIRTへ自動通知されるか
10. 定期訓練	少なくとも四半期などの周期でサインイン、通知、操作範囲、手順を検証しているか

Microsoft Entraの公式ドキュメントでは、緊急アクセスアカウントを2つ以上用意すること、通常の管理者アカウントと異なる強い認証方式を検討すること、条件付きアクセスでロックアウトされないようにすること、利用を監視し、定期的に検証することが説明されています。

---

初動対応：不明な緊急用アカウントや利用ログを見つけたとき

棚卸し中に所有者不明の管理者アカウント、用途不明のSuper Admin、GitHub owner、条件付きアクセス除外アカウントが見つかった場合は、すぐ削除だけで終わらせません。ロックアウト対策として必要な可能性があるため、止める順番と確認順序を分けます。

やること

• 対象サービス、アカウントID、権限、作成日、最終利用、所有者候補を記録する。
• 直近のサインインログ、権限変更、設定変更、監査ログ、GitHub Organization操作を確認する。
• 緊急復旧に必要なアカウントか、単に古い高権限アカウントかを分ける。
• 所有者不明でも高権限なら、追加利用を止めるための一時措置と代替復旧経路を同時に検討する。
• 説明できない利用があれば、漏えい疑い初動テンプレート に時刻、事実、推測、未確認事項を分けて記録する。
• 必要な緊急用アカウントは、保管、利用条件、通知、定期訓練、利用後レビューの運用へ載せ直す。

やらないこと

• 影響確認なしに唯一の管理者アカウントや唯一のOrganization ownerを削除しない。
• 緊急用アカウントの認証情報をチャットやチケット本文に貼り付けない。
• 「共有アカウントだから仕方ない」として日常運用に使わない。
• 説明できない利用ログを「訓練だったはず」と推測で処理しない。
• 条件付きアクセス除外を作ったまま、通知・ログ保管・再確認日を設定せず放置しない。

記録すること

記録項目	例
対象	サービス名、アカウントID、ロール、権限範囲、関連グループ
状態	有効、無効、緊急用、通常管理者、所有者不明、削除予定
認証	FIDO2/パスキー、証明書、MFA、回復情報、保管場所
例外	条件付きアクセス除外、MFA例外、端末条件、IP制限、承認者
ログ	サインイン、権限変更、監査ログ、GitHub owner操作、通知履歴
判断	維持、権限縮小、無効化、再設計、訓練実施、インシデント化

---

判断基準：どこまでエスカレーションするか

緊急用管理者アカウントの棚卸しでは、存在そのものよりも「説明できない強権限」と「使われた事実」を重く見ます。次の条件があれば、通常の棚卸しではなくセキュリティ初動として扱います。

優先度	条件	対応
高	緊急用アカウントのサインインが通知なしで発生した	ログ保全、操作内容確認、関係者確認、認証情報更新、CSIRT報告
高	唯一のGlobal Administrator、Super Admin、Organization ownerに依存している	代替管理者を整備し、ロックアウトリスクを優先是正
高	条件付きアクセス除外アカウントに所有者・保管記録・訓練履歴がない	一時停止可否を検討し、緊急経路を再設計
中	緊急用アカウントが通常作業に使われている	通常管理者ロールとPIM/JITへ移し、非常用の利用条件を再定義
中	GitHub ownerやSuper Adminが退職者・委託先・個人メールに残っている	所有者移管、権限縮小、退職者アカウント確認へ接続
低	用途、保管、通知、訓練が明確で、直近ログも想定内	台帳を更新し、次回訓練日と再確認日を設定

GitHubでは、Organization ownerが組織全体に強い管理権限を持ちます。公式ドキュメントでは、所有者が1人だけだとその人に連絡できない場合にプロジェクトへアクセスできなくなる可能性があるため、少なくとも2人のownerを推奨しています。一方で、ownerを増やしすぎると統制が弱くなります。継続性と最小権限を同時に満たす設計が必要です。

---

よくある誤解

「緊急用アカウントはMFAから除外するので弱くても仕方ない」

緊急時に通常のMFAや端末条件が使えない可能性を考えることは重要です。ただし、弱い認証でよいという意味ではありません。通常管理者と同じスマホや同じIdP依存に寄せすぎず、保管場所、利用者、通知、監査、定期訓練で補完します。

「PIMを使っているのでbreak glassは不要」

PIM（特権ID管理）や JIT Access は平時の恒久特権を減らす有効な仕組みです。しかし、承認者不在、IdP障害、条件付きアクセス設定ミス、MFA障害などでPIMの有効化自体ができない場合があります。break glassはPIMの代替ではなく、PIMを含む通常経路が使えない場面の最後の手段です。

「作成して金庫に入れたので完了」

保管だけでは不十分です。実際にサインインできるか、通知が飛ぶか、ログが残るか、担当者が手順を理解しているかを定期的に確認します。訓練で使った場合も、本番利用と区別できる記録を残します。

「非常用なので誰が使ったか分からなくてもよい」

非常用だからこそ、利用後レビューが必要です。いつ、誰が、どの理由で、何を操作し、どのログを確認したかを残さないと、正当な復旧と不正利用を区別できません。

---

関連用語・関連ページ

緊急用管理者アカウントは、ID管理、最小権限、監査ログ、退職者対応、SaaS棚卸しをつなぐテーマです。次のページを合わせて確認すると、実務へ落とし込みやすくなります。

目的	内部リンク
用語を理解する	Break Glass Account、Conditional Access、PAM、JIT Access
権限判断を整理する	最小権限の原則、認証と認可の違い
実務チェックへ進む	SaaS権限棚卸しチェックリスト、条件付きアクセス例外の棚卸し、退職者アカウント確認チェックリスト
ログ確認へ進む	セキュリティログの読み方、Audit Log、Log Retention
初動記録を残す	漏えい疑い初動テンプレート
初心者向けに練習する	認証と認可のミニCTF、ログイン失敗ログの読み取りミニCTF、用語クイズ

---

まとめ：break glassは「例外」ではなく管理された復旧経路にする

緊急用管理者アカウントは、作って終わりではありません。IdP障害、MFA障害、条件付きアクセス設定ミス、管理者退職、GitHub owner不在のような事態に備えつつ、平時には使われないように監査する必要があります。

まずは、主要IdP、Google Workspace、GitHub、クラウド、DNS、MDM、監視基盤に対して、緊急用アカウントまたは継続管理者が存在するかを確認します。次に、権限範囲、認証方式、保管場所、利用権限者、条件付きアクセス例外、監査ログ、通知、定期訓練を台帳化します。

通常運用では PAM、JIT Access、Zero Standing Privilege を使って恒久的な特権を減らし、非常用アカウントは最後の復旧経路として守ります。次の作業として、SaaS権限棚卸しチェックリスト に「緊急用管理者アカウント」「条件付きアクセス除外」「利用通知」「訓練日」を追加し、四半期レビューで繰り返し確認してください。MFA除外や場所例外を広く見直す場合は、条件付きアクセス例外の棚卸し で、除外ユーザー、named location、端末条件、report-only確認を分けて確認できます。

公式情報・参考情報

• Microsoft Learn: Manage emergency access accounts in Microsoft Entra ID Microsoft Entraの緊急アクセスアカウントの目的、2つ以上の用意、条件付きアクセス除外、監視、定期検証の考え方を確認できる。
• Microsoft Learn: What is Microsoft Entra Privileged Identity Management? PIMによるJIT権限、期限付きアクセス、承認、監査履歴、最小権限の考え方を確認できる。
• Microsoft Learn: Least privileged roles by task in Microsoft Entra ID Global Administratorに寄せすぎず、作業ごとの最小権限ロールへ分ける考え方を確認できる。
• Google Workspace Admin Help: Prebuilt administrator roles Google WorkspaceのSuper Admin、複数Super Admin推奨、管理者ロールの違いを確認できる。
• Google Workspace Admin Help: Recovering administrator access to your account Google Workspaceで管理者アクセスを回復するための公式導線と、関連する管理者ロール・復旧情報を確認できる。
• GitHub Docs: Roles in an organization GitHub Organization owner、member、security manager、outside collaboratorなどの権限境界を確認できる。
• GitHub Docs: Maintaining ownership continuity for your organization GitHub Organizationで少なくとも2人のownerを推奨する継続性の考え方を確認できる。
• NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations アクセス制御、監査、インシデント対応などの管理策ファミリーを確認できる。