Microsoft Entra ID（旧 Azure AD）の PIM（特権 ID 管理）で、管理者ロールの有効期限が同時に切れ、しかも承認者が自分たちだけだった――という「完全に詰む」シナリオは、どの組織でも起こり得ます。本記事では、主アカウントとバックアップアカウントの PIM 割り当てが同時に失効し、承認者も自分たちしかいない状況から、どのように復旧し、再発を防止するかを、実務的な観点で整理します。
PIM（特権 ID 管理）のロール有効期限が同時に切れたら何が起こるか
まず、今回のようなトラブルの典型的な状況を整理してみます。
- 管理用の主アカウントとバックアップアカウントに PIM で特権ロールを割り当てていた
- 両方とも PIM ロールの有効期限がほぼ同時に切れた
- 両アカウントのメールボックスが停止・利用不可で、期限通知メールを受け取れていなかった
- PIM のロール更新要求には承認者が必要だが、その承認者に設定していたのが「自分たち（期限切れの 2 アカウント）」だけ
- 結果として、誰も承認できず、要求を出しても詰む状態になっている
この状態を別の言い方をすると、「承認できる人がテナント内に 1 人もいない」ということです。PIM で特権ロールを厳密に管理しているがゆえに、設計ミスがそのままロックアウト事故に直結してしまうパターンです。
| 項目 | 状態 | 主なリスク |
|---|---|---|
| PIM ロール割り当て | 主・バックアップともに期限切れ | 特権操作が一切できない |
| 承認者設定 | 自分たち 2 アカウントのみ | 承認ルートが完全に断絶 |
| 通知メール | メールボックス停止で不達 | 期限切れに気づけない |
| テナント管理 | 他の全体管理者などが不在 | テナント全体の運用停止に直結 |
結論：最短ルートは「別の権限保持者」か「Microsoft サポート」
この状況からの脱出ルートは、シンプルにまとめると次の 3 パターンです。
- 他の管理者アカウントでログインして、該当ロールを再割り当てする
- 緊急アクセス用（break‑glass）アカウントがあれば、それでサインインしてロールを再割り当てする
- 本当に誰もいない場合は、Microsoft 公式サポートに「管理者アクセスの回復」を依頼する
どれを選ぶかはテナントの現状次第ですが、基本的には上から順に可能性を潰していく形になります。
| パターン | 条件 | 実現性 | 主なアクション |
|---|---|---|---|
| 他の管理者を使う | 全体管理者 / 特権ロール管理者が他にいる | 最も現実的・即時性が高い | その管理者で PIM 設定を修正しロールを再割り当て |
| 緊急アクセスアカウントを使う | break‑glass アカウントを事前に用意している | セキュリティ設計が成熟している環境なら有力 | 緊急アカウントでログインし、ロール/承認者を復旧 |
| Microsoft サポートに依頼 | 本当に管理者が誰もいない | 時間はかかるが最終手段として有効 | テナント所有者確認を経て一時的な全体管理者を付与してもらう |
他の管理者または緊急アクセスアカウントでの復旧手順
他の全体管理者 / 特権ロール管理者がいる場合
まずは「本当に管理者が自分たち 2 人だけなのか？」を冷静に確認しましょう。大きめの組織では、監査目的や利用開始時の暫定対応として、別の管理者が登録されているケースも少なくありません。
- Azure ポータルにアクセスし、別の候補アカウントでサインインを試みる
- サインインできたら、Microsoft Entra 管理センターを開く
- 「ロールと管理者」または「特権 ID 管理（PIM）」に移動
- 問題となっている特権ロール（例：全体管理者、特権ロール管理者など）を開き、
- 主アカウント・バックアップアカウントに対してロール割り当て（Eligible または Active）を追加
- あわせて承認者を自分以外にも追加（グループを推奨）
承認者の見直しまで一気に行っておくと、同様の事故を再度起こす確率を大きく下げられます。
緊急アクセス（break‑glass）アカウントがある場合
セキュリティ設計が進んでいるテナントでは、PIM とは別に緊急アクセス用アカウント（break‑glass アカウント）を用意していることがあります。これらは通常、
- 条件付きアクセスの対象外（MFA などでロックアウトされない）
- メールボックスやライセンスを持たない、または最小限
- 常時、全体管理者ロールを保持しつつ、パスワードと使用状況を厳格に監査
もしこのようなアカウントを運用しているなら、以下の流れで復旧します。
- 緊急アクセスアカウントで Microsoft Entra にサインイン
- 特権 ID 管理（PIM）の対象ロールを開き、
- 主アカウントおよびバックアップアカウントをロールに再割り当て
- PIM 承認者として、自分たち以外のメンバーを含むグループを指定
- 作業完了後、緊急アクセスアカウントの利用ログを確認し、所定の運用ルールに沿って記録
緊急アクセスアカウントは「最後の砦」です。利用した事実と理由を必ず残し、「安易に使わないが、いざというときは確実に使える」状態にしておきましょう。
本当に誰も承認できない場合：Microsoft サポートによるテナント復旧
他に全体管理者や特権ロール管理者が見つからず、緊急アクセスアカウントも存在しない場合、残されたルートはMicrosoft 公式サポートによる管理者アクセス回復です。
概要は次のとおりです。
- Azure ポータルまたは Microsoft 365 管理センターから、サインインできる範囲でサポートにアクセス
- 「管理者アクセスの回復」「テナントの管理者権限の喪失」といった内容でサポートチケットを起票
- テナントの「所有者」であることを証明するため、次のような情報の確認が行われる
- サブスクリプションの課金情報（契約 ID、請求先情報など）
- 既知の連絡先情報（登録済みの電話番号・メールアドレス）
- 必要に応じて、DNS に一時的な TXT レコードを追加してドメイン所有を証明
- 本人確認プロセスを通過すると、Microsoft によって一時的な全体管理者アカウントの付与などの措置が取られる
- 付与された管理者権限を使って、PIM ロールや承認者設定を復旧する
このプロセスは時間がかかる可能性があるため、ビジネス影響が大きい場合は、チケット起票時にその点も明確に伝え、優先度を上げてもらうよう依頼するとよいでしょう。
復旧後に必ず見直したい PIM 設計と運用
テナントが復旧したら終わりではありません。同じ事故を繰り返さないために、PIM と緊急アクセスの設計を「攻めの姿勢」で見直す必要があります。
承認者を「個人」ではなく「グループ」で指定する
今回のボトルネックは、承認者が主アカウントとバックアップアカウントの 2 つだけだったことです。PIM の承認者に「個人アカウントだけ」を指定すると、その個人が使えなくなったときに承認ルートが断絶します。
| 承認者のパターン | メリット | デメリット / リスク |
|---|---|---|
| 個人アカウント 1 名 | 管理対象が少なくシンプル | その 1 名がロックアウトすると即詰み |
| 個人アカウント複数名 | ある程度の冗長性 | 人事異動や退職で知らぬ間に 1 名体制になりやすい |
| セキュリティグループ（Privileged Access Group） | メンバーの追加・削除で柔軟に冗長性を確保 | グループ自体の管理が必要 |
おすすめは、PIM の承認者をセキュリティグループで定義し、そのグループのメンバーを複数名にしておく運用です。さらに、Privileged Access Groups（特権アクセス グループ）を利用すると、グループメンバーシップ自体も PIM で管理でき、よりセキュアな運用が可能になります。
緊急アクセスアカウントは最低 2 つ用意する
緊急アクセスアカウントは、1 つだけだと「そのアカウントの認証情報が失効したときに終わる」という構造的な弱点があります。そのため、最低 2 アカウントは用意し、次のようなポリシーで運用するのがベストプラクティスです。
- クラウド専用アカウントとし、オンプレ AD とは連携しない
- 条件付きアクセスのポリシーから除外し、MFA 障害や IdP 障害の影響を受けないようにする
- メールボックスは必須ではない（通知の宛先として使わない設計にする）
- 強力なパスワード＋安全な保管方法（物理金庫など）で管理
- 定期的（例：月 1 回）にサインインテストを実施し、まだ利用可能か確認する
- 利用時は必ず監査ログを確認し、利用理由と作業内容を記録
ロールの有効期限と更新オペレーションをずらす
主アカウントとバックアップアカウントのロール有効期限が同時に切れると、今回のような事故のリスクが一気に高まります。そこで、有効期間と開始日を意図的にずらすことが重要です。
| 設定パターン | 例 | ポイント |
|---|---|---|
| 同時開始・同時終了 | 主・バックアップとも 2025/01/01～2025/03/31 | リマインダーを見逃すと同時に失効しやすい |
| 開始日をずらす | 主：2025/01/01～03/31、バックアップ：2025/01/15～04/15 | 片方の有効期限に気づけば、もう片方も見直すトリガーになる |
| 有効期間を短くし、更新頻度で安全性を確保 | 各 1～3 か月程度で見直し | 定期的な棚卸しと PIM 設定の健全性チェックがしやすい |
通知の冗長化：メールボックス停止に依存しないしくみ作り
今回のケースでは、「メールボックスが停止していたため、期限切れ通知を受け取れなかった」という要素も事故の一因です。通知経路の単一路は、特権 ID 運用においては大きなリスクです。
対策としては、次のような「通知の冗長化」が有効です。
- PIM の通知先を個人メールアドレスだけにしない
- 監視対象の配布リスト（例：[email protected]）を用意し、そこに期限切れ通知を送る
- 配布リストに、
- 複数の運用担当者
- サービスデスクのアドレス
- 必要に応じて、外部監視システムの取り込み用アドレス
- Microsoft Teams のチャンネルやチケットシステムと連携して、期限 〇日前に自動でチケットを起票する
- Exchange Online のメールボックス保持ポリシーや自動停止設定を見直し、運用アラート用メールボックスが勝手に停止しないようにする
特に「期限が近づいたら自動でチケットを切る」運用は、人に依存しないのでおすすめです。PIM の通知をトリガーにしつつ、タスク管理ツール側で「期限までに更新されない場合はエスカレーションする」ルールを組み込んでおくと、より安心です。
ロール失効時の“駆け込み手順”をランブックにする
どれだけ設計を工夫しても、システムや人のミスはゼロにはなりません。そこで重要なのが、「ロール失効で困ったときの駆け込み手順」を文書化しておくことです。いわゆるランブック（運用手順書）です。
ランブックには、最低限次のような項目を含めておくと実務で役立ちます。
- 切り分けフロー
- PIM ロールだけが切れているのか
- そもそもサインイン自体ができないのか
- 条件付きアクセスや MFA 側の問題ではないか
- 段階的な対応先
- まず確認すべき他の管理者アカウントの一覧
- 緊急アクセスアカウントの ID（ただしパスワードは別管理）
- それでも駄目な場合にエスカレーションする先（情報システム部長、CISO など）
- Microsoft サポートに依頼する際に必要な情報
- テナント ID、ドメイン名
- 契約情報を確認できる社内窓口
- DNS 変更を行える担当者（またはベンダー）の連絡先
- 復旧作業後に必ずやるべきチェックリスト
- PIM 承認者の冗長化ができているか
- 緊急アクセスアカウントのテストとログの確認
- 通知経路が単一になっていないか
ランブックは、紙・共有ドキュメント・社内 Wiki など、クラウド障害やアカウント障害の影響を受けにくい形で保管しておくことが重要です。
PIM と緊急アクセスアカウントの基礎をおさらい
ここで改めて、今回登場したキーワードを整理しておきます。用語の理解が揃っていると、運用メンバー間でのコミュニケーションロスが減ります。
| 用語 | 意味 | ポイント |
|---|---|---|
| PIM（Privileged Identity Management） | Microsoft Entra ID の特権 ID 管理機能。管理者ロールを「必要なときだけ」有効化する仕組み。 | 常時特権ではなく、JIT（Just-In-Time）でセキュリティを高める。 |
| Eligible（有効化可能な割り当て） | 平常時はロールが無効で、必要なときに要求（＋承認）して一定時間だけ有効化する形。 | 日常的に特権を持たせたくないロール（全体管理者など）に適している。 |
| Active（アクティブな割り当て） | 常にロールが有効になっている状態。 | 緊急アクセスアカウントなど、ごく一部に限定して利用する。 |
| 緊急アクセス（break‑glass）アカウント | ロックアウトや大規模障害の際に、最後の手段として使う特別な管理者アカウント。 | 通常は一切使わず、強力なパスワードと監査で厳重管理する。 |
具体的な設定イメージ：こう変えると事故が減る
最後に、今回のような事故を防ぐための「実際の設定イメージ」を示しておきます。
承認者設定の見直しイメージ
- 「特権ロール管理者」「全体管理者」など重要ロールごとに、“PIM 承認者用セキュリティグループ”を作成する
- 各グループに、少なくとも 3〜5 名程度の管理者を追加
- 主アカウント・バックアップアカウント
- 他部署の信頼できる管理者
- 外部 MSP（運用委託先）があれば、その代表アカウント など
- PIM のロール設定で、「要求の承認者」に上記グループを指定する
- グループメンバーの変更ログを監査し、不正な追加/削除がないかを定期確認
緊急アクセスアカウント運用のチェックポイント
- アカウントは 2 つ以上あるか
- どの条件付きアクセス ポリシーから除外されているか一覧化されているか
- 最終サインイン日時・パスワード変更日時を定期的に確認しているか
- “誰が、どの状況で使ってよいか”がドキュメント化されているか
- 利用記録のフォーマット（テンプレート）が用意されているか
まとめ：承認経路の単独化をやめ、緊急アクセスを二重化する
今回の事象は、一言でいえば「承認者が自分たちだけ」「通知が個人メールだけ」「緊急アクセスがない」という三重の設計ミスが同時に噴出したケースです。
再発防止のための要点を整理すると、次のようになります。
- 他の管理者または緊急アクセスアカウントでの復旧ルートを必ず用意する
- PIM の承認者はグループで定義し、複数名が承認可能な構成にする
- 主アカウントとバックアップアカウントのロール有効期限をずらし、同時失効を避ける
- 通知経路を個人メールに依存させず、配布リストやチケットシステムと連携する
- ロール失効時の駆け込み手順（ランブック）を作成し、定期的に見直す
特権 ID 管理は、「厳しすぎて誰も触れない」状態でも、「ゆるすぎて誰でも触れる」状態でも問題です。PIM と緊急アクセスアカウントを適切に組み合わせ、「通常は厳格だが、いざというときは安全に復旧できる」バランスを目指して設計・運用していきましょう。
コメント