いつ起きるか — 条件付きアクセスのロックアウト
Entra ID（旧Azure AD）の条件付きアクセスは強力な反面、設定ミスで管理者全員がEntra ID管理ポータルにサインインできない事故を引き起こします。典型例は次の3パターンです。
- 「Allコネクション」 ＋ 「すべてのクラウドアプリ」 ＋ 「コンプライアントデバイス必須」 を設定したが、管理者が使う端末がIntune登録されていなかった
- 「すべての場所」 ＋ 「ログインリスク中以上をブロック」 を有効化し、リスク判定でロックアウト
- VPNなしの拠点をすべてブロックするつもりが、自宅のIP範囲を含めてしまった
条件付きアクセスは 「除外（Exclude）」を必ずユーザー単位で設定するのが原則。除外されている専用アカウント＝Break Glassアカウントでログインし、ポリシーを無効化または修正します。Break Glassを用意していない場合は、Microsoftサポートへの緊急問い合わせとなり、復旧まで数時間〜半日を要します。
Break Glass（緊急アクセス）アカウントとは
Break Glassアカウントは、すべての条件付きアクセスポリシーから除外され、強力なパスワードとセキュリティキーで保護された専用の管理者アカウントです。MicrosoftはEntra IDテナントに2つ以上設置することを推奨しています。
設計要件
- クラウド専用アカウント（オンプレADから同期しない、独立した cloud-only ユーザー）
- UPNはテナント既定ドメイン（例：
onmicrosoft.com）で作成し、フェデレーション影響を受けない - 「グローバル管理者」または「Privileged Authentication Administrator」を恒久付与（PIMの対象外）
- FIDO2セキュリティキー（YubiKey等）を物理保管。パスワードは別保管庫
- ID／パスワードを金庫＋封筒＋取扱記録簿でアナログ運用
- サインインをMicrosoft Sentinel／Log Analyticsでアラート化（使用＝事故）
条件付きアクセスからの除外設定
すべての条件付きアクセスポリシーで「ユーザーとグループ → 除外」にBreak Glass用グループを指定します。グループにメンバーシップ追加するだけで除外が効くよう、専用Entraグループ（例：BG-Emergency-Access）を作るのが運用しやすい構成です。
「すべて」適用ポリシーを作るとき、Break Glass除外を忘れる事故が最多。ポリシー作成テンプレートを作り、除外グループを必須項目として組み込んでおくのが鉄則です。
ロックアウト発生時の復旧手順
Step 1：Break Glassでサインイン
InPrivate／シークレットウィンドウで https://entra.microsoft.com または https://portal.azure.com にアクセスし、Break Glassアカウントでサインイン。FIDO2を使う場合はキーを差し込みます。
Step 2：問題ポリシーを「無効」または「レポート専用」に
- Entra管理センター → 保護 → 条件付きアクセス → ポリシー
- 該当ポリシーを開く
- 「ポリシーを有効にする」を オフ、または レポート専用（Report-only）に変更して保存
レポート専用にすると、ポリシーは適用されないが評価結果はSign-inログに記録され、修正後の動作確認に役立ちます。
Step 3：ロックされたアカウントの解除確認
影響を受けたユーザーに再ログインを依頼。MFA要求が連続したケースでは、ユーザーの「サインインリスク」が高に固定されている可能性があるため、Identity Protection → リスクのあるユーザー → リスクの確認 → 修復済みに変更します。
Step 4：Sign-inログで原因特定
Entra管理センター → 監視 → サインインログ で、影響時間帯を絞り込み、ステータス「失敗」かつエラーコード 53003（条件付きアクセス） を抽出。詳細タブの「条件付きアクセス」を開くと、適用されたポリシーと「Grant Controls」のどの要件で阻まれたかが表示されます。
| エラーコード | 意味 | 典型対処 |
|---|---|---|
| 53003 | 条件付きアクセスポリシーでブロック | ポリシー詳細を確認、必要なら除外 |
| 50158 | 外部セキュリティチャレンジ未満たし | MFA未設定、デバイスコンプライアンス未達 |
| 50074 | 強い認証が必要 | MFA要求、登録誘導 |
| 53000 | デバイスがコンプライアント要件未達 | Intune同期、デバイス登録の確認 |
| 53001 | デバイスがドメイン参加でない | Hybrid Join／Entra Join確認 |
再発防止：本番投入前の3つの安全装置
1. レポート専用モードでの予行演習
新規ポリシーは必ず2週間以上「レポート専用」で動作確認します。Sign-inログのフィルタ「条件付きアクセス → レポート専用：失敗」で、運用ユーザーがブロックされる件数を観察。0件になったら本適用へ。
2. What If ツールでの事前検証
条件付きアクセス → What If でユーザー・場所・アプリ・デバイス状態を指定し、適用されるポリシーをシミュレーション。本番ユーザー数名で正常系・異常系の両方をテストするのが最低ライン。
3. パイロット段階展開
「全社員適用」は最終形。最初は情シスチーム → 30名のパイロット → 100名 → 全社と段階的に拡げる。初期段階で除外漏れを発見できれば、影響は最小化できます。
日常運用：Break Glassの健全性管理
- 四半期ごとのテストサインイン（実際にログインできるか）
- パスワードローテーションは原則しない（紛失リスクのほうが大きいため、長くて複雑な永続パスワード）
- Sentinel／Log Analyticsで「Break Glass使用 → 即Slack通知」のアラートルール
- FIDO2キーの物理保管場所と取り出し手順を災害対策BCPに含める
- 退職者が触れない場所、かつ2名以上が場所を知る運用（Two-person Integrity）
まとめ
Entra IDの条件付きアクセスでロックアウトを起こさない最大の予防策は、Break Glassアカウントの設計と本番投入前のレポート専用運用です。事故が起きた場合も、Break GlassとSign-inログがあれば30分で復旧可能です。逆に、Break Glassなしで「すべてのアプリ」「すべてのユーザー」「コンプライアント必須」を一気に有効化するのは、業務停止リスクが極めて高い禁忌操作。条件付きアクセスは強力な統制ツールだからこそ、本番投入時の運用設計を疎かにしないことが、ひとり情シスにとっての最大の保険となります。