はじめに
Microsoft Entra ID の 緊急アクセス用 管理アカウント (Break glass Account) について取り上げます。
私はこれまでパスキーを中心に、認証・アクセス制御に関する情報発信を行ってきました。
その中で、「強くする」だけでなく、「最後に戻れる手段」をどう設計するかも同じくらい重要だと感じています。
Break glass は単なる“緊急用アカウント”ではなく、
テナントをロックアウトから守るための最終防衛ラインです。
本記事では、その設計の考え方も含めつつ、
まずは気軽に取り組める「入口」としての構成から、その設計の考え方まで紹介していきます。
本記事の要点
本記事の結論を先にまとめます。
これだけ覚えておけば、重大な設計ミスは防げます。
- Break glass アカウントは必ず2つ以上用意する
- 認証方式は単一依存を避ける（推奨：併用）
- 条件付きアクセス除外だけでなく攻撃面を意識して設計する
公開情報：Microsoft Entra ID で緊急アクセス用アカウントを管理する
https://learn.microsoft.com/ja-jp/entra/identity/role-based-access-control/security-emergency-access?wt.mc_id=MVP_407731
YonaYona Azure 2026/6/30 登壇時の資料
記事の全体像
本記事のターゲット
本記事は、以下のような読者を対象としています。
はじめて Break glass に触れる方から、すでに運用している方まで、
それぞれの状況に応じて 「体験 → 構成 → 設計の見直し」 へと進めることを目的としています。
-
まだ Break glass のことを知らなかった
→ まずは基本を理解し、構成を体験してみよう
-
Break glass のことは知っていたけど、やっていなかった
→ この機会に構成し、ロックアウトなどのリスクに備えよう
-
Break glass として運用しているつもりだったが、既存の管理者を除外しているだけだった
→ 設計観点（依存関係・可用性・攻撃面）から構成を見直してみよう
本記事の後半では、Break glass の設計や運用をより深く理解するための参考記事も紹介しています。
Break glass に興味を持ち、「もっとしっかり設計したい」と感じた方は、
ぜひ本格的な運用設計にも取り組んでみてください。
Break glass アカウントの必要性
条件付きアクセスの誤設定や認証トラブルにより、管理者自身がサインインできなくなるケースは実際に発生しています。
以下は、その代表的な事例ですが、以下の Microsoft テクニカル サポートブログで紹介されています。
Support Blog : グローバル管理者ロールを持つユーザーでサインインできない！
https://jpazureid.github.io/blog/azure-active-directory/ga-is-locked-out/
（上記より抜粋）
- テナントを作成したユーザーが退職してしまい、グローバル管理者ロールを持つユーザーが分からない。
- ゲスト ユーザーがグローバル管理者ロールを保持しているが、そのゲスト ユーザーの大元のユーザーにアクセスできない。
- グローバル管理者ロールをもつユーザーがスマホをなくした、もしくは機種変更したので MFA を突破できない。
- 条件付きアクセスでグローバル管理者ロールを持つ全てのユーザーがブロックされ Azure ポータルに入れない。
- 1 人しかいないグローバル管理者のユーザーにリスクが検出されてしまいサインインできない。
上記以外にも、「認証方法」の設定で、パスキー (FIDO2) を一旦無効にしてしばらく経ったら、全パスキーでの認証ができなくなった・・・という事例もあります。
条件付きアクセスを編集した際に、以下のようなメッセージを見たことがありませんか？
このタイミングで 設定ミスを犯していると 上記で挙げられたような締め出しを食らってしまい 誰もテナントに入れないという事態に遭遇してしまいます。
上記のまま、現在のユーザー 〇〇 をこのポリシーから除外 をすると、そのユーザーは条件付きアクセスの制御を完全に受けなくなります。
その結果、MFAや認証強度が適用されない認証経路が残り、ポリシーによる制御を迂回できる状態（＝Attack Surfaceの露出）となります。
特に、普段利用している管理者アカウントを除外すると、日常的に使われるアカウントが無防備になるため、実質的にセキュリティホールとなり得ます。
一時的な検証には有効ですが、そのまま運用すべき設計ではありません。
また、ポリシーの影響を受けることを理解しました。続行します。 にした場合、計算を間違えると 管理者アカウントが全てポリシーで制御されてしまった結果、誰もテナントに入れない事態に遭遇してしまいます。
言い換えると、Break glass が無い状態とは、「単一の認証経路に依存した状態」であり、その経路が失われた瞬間に、テナント全体へアクセス不能になるリスクを抱えている状態です。
このような事態を防ぐためには、Break glass アカウントの事前準備が不可欠です。
公開情報：緊急アクセス用アカウントを使用する理由
https://learn.microsoft.com/ja-jp/entra/identity/role-based-access-control/security-emergency-access?wt.mc_id=MVP_407731#why-use-an-emergency-access-account
Break glass 構成パターンの比較と設計上の落とし穴
Break glass の構成パターンには明確な正解はなく、利用シナリオごとにトレードオフを踏まえて選択する必要があります。
構成の選び方（簡易ガイド）
- まず試したい → ① MFAのみ
- 個人・検証 → ② パスキーのみ
- 本番環境 → ③ 併用（＋必要に応じてネームドロケーション）
構成の選び方（詳細）
-
➀ MFA のみ
本記事を見て、手元に パスキーは無いけど、まずは Break glass を設定してみようと思った方向けです。
簡単に、Break glass を体験できますし、条件付きアクセスの設定ミス のカバーが可能になります。
後日、FIDO2 セキュリティキー を追加で導入して、➂ 併用案 へ切り替えてください。
-
➁ パスキーのみ
本記事の読者の中には、完全パスワードレス化を進めている方も多いと思います。
Break glass は、FIDO2 セキュリティキー のみで管理できるので、これが理想と思いがちです。初めは 私も この案を推そうと思っていました。
ですが、「認証方法」の設定で、パスキー (FIDO2) を、誤って 無効化 すると、誰も入れなくなるリスクがあります。
この構成は、パスワードや Authenticator の管理負荷を軽減できる一方で、
単一の認証方式に依存するリスクを伴います。
そのため、このリスクを許容できる環境に限って選択してください。
なお、検証用テナント・小規模テナントであれば、➂ よりも 運用が軽くなるので、この案でも良いと思います。
➁ で Break glass 対策ができたら、続けて ➂ へ移行することも検討してみてください。
-
➂ 併用（推奨）
この方法は、２つの認証方法 Microsoft Authenticator（通知）と、パスキー (FIDO2 セキュリティキー）を併用する方法です。この場合は、仮に 片方の認証方法が無効化されてしまっても、他方が生き残ります。
大規模組織であれば、このような設計を検討いただいた方が良いと思います。
３方式のメリデメ比較
以下の表は「どれが優れているか」ではなく、「どのリスクを許容するか」という観点で整理しています。
| # | ➀ MFA のみ |
➁ パスキーのみ | ➂ 併用 （推奨） |
|---|---|---|---|
| 誰向けの構成か？ | 初心者 初回検証 |
検証用 小規模 テナント |
中～大規模 テナント |
| 条件付きアクセスの設定ミスをカバー | 〇 可能 | 〇 可能 | 〇 可能 |
| FIDO2 セキュリティキーの手配、コスト | 〇 なし | △ あり | △ あり |
| 認証方式の独立性 （他方式障害の影響） |
✕ 依存あり |
〇 単一 |
◎ リスク分散 |
| 保管・運用難度 ※デバイス紛失・担当者依存（離脱）による運用リスク |
✕ 人依存 |
△ 物理管理 |
✕ 両方管理 |
| 完全ロックアウト耐性 ※認証手段の喪失によるリスク耐性 |
✕ 低 | △ 中 | 〇 高 |
| ハッキングリスク ※③ は MFA 側に依存 |
✕ 高 | 〇 低 ★注意 |
✕ 高 ※MFA側 |
ハッキングリスク（★注意）について
ここで重要なのは、「Break glass を CA から除外することで、認証経路が露出する」という点です。
つまり、通常は制御されている認証手段（パスワード・Intune 準拠外 など）が攻撃面として露出します。
通常の運用時は、認証強度を パスキーのみで絞っていて安全ですが、このポリシーから除外することで、パスワードのみの認証が露出してしまいます。攻撃者は パスワードのみで 登録キャンペーンによって MFA を登録して、以後 パスワード + MFA でサインインができてしまうのです。このようなリスクがあることを把握しておきましょう。
完全パスワードレス の運用の場合には、Break glass アカウントでは安易に Authenticator を許可しないようにしてください。
「〇 低」の評価は、あくまで 上記の対策を実施した状態に対しての評価であり、そこをケアしていない場合は、「✕ 高」どころか、それ以下の状態になっていることに注意してください。
このリスクは認証強度の問題ではなく、「どこから攻撃できるか」という問題です。
このリスクを低減させるには、後述する ネームドロケーション との併用を検討してください。
※重要
これは「認証が弱い」問題ではなく、
「制御されていない経路が存在している」こと自体が問題です。
ハッキングリスク に対する ネームドロケーション追加設定の提案
いずれの構成（➀～➂）であっても、Break glass にはハッキングリスクが存在します。
一方で、Break glass設計の基本は「絶対にロックアウトしないこと」です。
そのため一般的には、すべての条件付きアクセスから除外する設計が推奨されています。
しかし、最適と考えられる ➂ 併用構成であっても、パスワード＋MFA という弱い認証経路が攻撃面として残ります。
さらに Break glass を条件付きアクセスから除外することで、本来制御されていた認証経路が外部に露出するという問題が発生します。
このリスクは認証強度の問題ではなく、「制御されていた攻撃経路が開放されること」 によって生じます。
そこで本記事では、この攻撃経路を抑制する手段として、
あえて Break glass 専用の条件付きアクセスを適用し、アクセス元を制限する設計も選択肢として提示します。
これは「認証強度の強化」ではなく、
「攻撃面の削減（Attack Surface Reduction）」 によってリスクを低減するアプローチです。
これは Break glass 設計における「セオリーの補完」であり、否定ではありません。
⚠ 注意
この設計では、ネットワーク障害やネームドロケーションの設定不備が発生した場合、Break glass アカウントでもサインインできなくなる可能性があります。
そのため、事前の十分な検証と運用ルールの整備が不可欠です。
この「設定不備によるロックアウトリスク」と「ハッキングリスク」はトレードオフの関係にあるため、環境に応じた判断が必要です。本記事では、このトレードオフを前提としたうえで、ハッキングリスクの低減を優先する設計として、ネームドロケーション案を推奨しています。
Break glass を構成してみよう
ここまでの設計を踏まえて、Break glass を実際に構成していきます。
以下に基本的な構成ステップを整理します。
※パスキーの導入は強く推奨ですが、手配が難しい場合は後から追加することも可能です。
| # | 構成ステップ | ➀ MFA のみ | ➁ パスキーのみ | ➂ 併用 （推奨） |
|---|---|---|---|---|
| 1 | パスキー (FIDO2 セキュリティキー) を手配する | － | 〇 | 〇 |
| 2 | テナント内のパスワード 有効期限ポリシーの設定確認 | 〇 | 〇 | 〇 |
| 3 | 緊急用のアカウント (Break glass) を作成する | 〇 | 〇 | 〇 |
| 4 | 条件付きアクセスの影響を受けないようにする | 〇 | 〇 | 〇 |
| 5 | Microsoft Authenticator を有効化する | 〇 | － | 〇 |
| 6 | Microsoft Authenticator をセットアップする | 〇 | － | 〇 |
| 7 | パスキー (FIDO2) を有効化する | 〇 | 〇 | 〇 |
| 8 | Temporary Access Pass (TAP) を有効化する | － | 〇 | － |
| 9 | パスキー (FIDO2 セキュリティキー) を割り当てる | － | 〇 | 〇 |
| 10 | パスキー (Microsoft Authenticator のパスキー）を割り当てる | 〇 | 任意 | 任意 |
| 11 | Break glass 専用ポリシーを追加する（追加案） | 推奨 | 推奨 | 推奨 |
⚠ 事前に知っておいてほしいこと
本章の構成は、Break glass の「入口」となる構成です。
この状態を固定したまま、本番環境で運用し続けることは推奨しません。
Break glass は「作ること」ではなく、
「壊れない設計を維持し続けること」が本質です。
実際に、ベストプラクティスは固定ではなく変化し続けています。
セキュリティリスクの増加やパスキー認証の普及により、必要とされる構成は変化し、その結果として攻撃面が増加し、ネームドロケーションのような追加対策が必要になるケースが出てきました。
仕組みや技術仕様、セキュリティは常に変化するため、
運用においては継続的な見直しが必要になります。
本運用では、以下の観点を踏まえて、都度設計を見直すようにしてください。
- 認証方式の依存関係
- 紛失・障害時の可用性
- 侵害リスクに対する耐性
1. パスキー (FIDO2 セキュリティキー) を手配する
作業対象
➀ MFA のみ = 不要（実施しません）
➁ パスキーのみ = 実施します。
➂ 併用 = 実施します。
※推奨は、２本以上用意してください。
FIDO2 セキュリティキー を手配してください。
理由は、以下の Microsoft テクニカルサポートブログでも説明されています。
Support Blog：緊急アクセス用の管理アカウントを作成する
https://jpazureid.github.io/blog/azure-active-directory/ga-is-locked-out/#緊急アクセス用の管理アカウントを作成する
（上記より抜粋）
緊急アクセス用の管理アカウントの ID とパスワードを発行したら、多要素認証の方法として
FIDO2 セキュリティ キーを構成することをおすすめします。多要素認証の方法として電話を利用することはお勧めしません。
どのような FIDO2 セキュリティキー を手配すれば良いのかですが、基本的には FIDO2 に対応している 物理セキュリティキーであれば、どれでも OK です。Amazon などで手に入ります。
ですが、どれを選べば良いのか迷ってしまう場合には、Yubico 社 の Yubikey をお勧めしたいと思います。
以下の記事を参考に、製品を選んでみてください。
Yubikey まとめ（利用可否検証あり）
https://qiita.com/carol0226/items/1e28bdc3acc4c7814da2
2. テナント内のパスワード 有効期限ポリシーの設定確認
作業対象
➀ MFA のみ = 実施します。
➁ パスキーのみ = 実施します。
➂ 併用 = 実施します。
現在のテナントの パスワードの有効期限の設定を確認しておきます。
Microsoft 365 管理センター で確認できます。
https://admin.cloud.microsoft/
設定－組織設定－セキュリティとプライバシー－パスワードの有効期限ポリシー を開いて、
パスワードを無期限に設定する にチェックが入っていれば OK です。
無期限でも大丈夫なのか？
パスワードの無期限化は、推奨されています。
上記の緑下線部のリンクでも説明されています。
緑下線：Microsoft 365 パスワードに関するパスワード ポリシーの推奨事項
https://learn.microsoft.com/ja-jp/microsoft-365/admin/misc/password-policy-recommendations?view=o365-worldwide&wt.mc_id=MVP_407731#password-expiration-requirements-for-users
最近 手配したテナントの場合は、既定で ON になっていますが、古くから運用しているテナントの場合は、チェックが外れている可能性があります。その場合には、以下の私の説明を参考にしながら、対処を行ってください。
➀ 検証用のアカウント：利用者は限定的
この場合は、上記の画面で ON に変更し、パスワードの無期限化を進めてみましょう。
※当然、関係者には声をかけましょう。
合わせて、以下の私の記事を参考に、テナント内の認証を 完全パスワードレスな環境へ移行することも検討してみて下さい。
FIDO2 & Entra 完全パスワードレス のための 条件付きアクセス
https://qiita.com/carol0226/items/a3e914b3968cb7c38a63
➁ 通常運用：利用者が居るテナント
この場合は、深く考えずに パスワードポリシーの運用方針を変更してしまうのは さすがに 運用面でのリスクがあります。先々は テナント内のアカウントを パスキー などへ移行させることを考えつつ、状況を見て 無効化を検討していきましょう。以下の私の記事も参考にしてみてください。
Microsoft Entra の登録キャンペーンを理解する ～パスキー導入に向けた挙動と展開のポイント～
https://qiita.com/carol0226/items/4ad04ffe2141f43ad6a1
なお、今回作成した Break glass アカウントだけは、無期限に設定しておきます。
普段利用しないアカウントは、有効期間が経過してしまうと、パスワードが 失効 してしまうからです。
アカウント単体で、パスワードを無期限化する方法があります。以下の Qiita 記事が参考になります。
[Azure] Microsoft Entra IDのユーザーパスワードを無期限にする
https://qiita.com/chappy7121/items/8151f64aa8b4cfcbdc91
3. 緊急用のアカウント (Break glass) を作成する
作業対象
➀ MFA のみ = 実施します。
➁ パスキーのみ = 実施します。
➂ 併用 = 実施します。
※推奨は、２アカウント作ってください。
では、Break glass 用のユーザーアカウントを作成していきます。
1．Microsoft Entra 管理センター を開きます。
https://entra.microsoft.com
2．左ペインから ユーザー を選び ＋新しいユーザー を開いて 新しいユーザーの作成 を選択します。
3．基本 タブでは、以下のように入力します。
なお、ここでは、緑枠 の xxxx.onmicrosoft.com となっているドメインを選んでください。
次へ：プロパティ を押して進めます。
注意
カスタムドメインを構成していると、水色 (carol226.com) のように 普段使いのドメイン名が表示されています。
しかし、Break glass アカウントの位置づけとしては、なるべく 余計な構成を行っていないアカウントが推奨されるため、カスタムドメインは、選ばないようにします。
パスワードは、自動生成ではなく、とても長いパスワードを手動で設定して、設定してください。
16文字程度でも良いと思いますが、私は、128 文字 を設定しました。
パスワードは、パスワードの自動生成 のチェックボックスを外すと入力できます。
このパスワードは、紙に印刷、USB メモリ（セキュリティ対応が理想）に保存し金庫保管、または 電子的な保管庫や 他社製のパスワードマネージャー などに保存します。
4．プロパティ タブでは、特に設定すべき項目はありません。そのまま 次へ：割り当て を押して進めます。
5．割り当て タブでは、＋ロールの追加 を押して、グローバル管理者 ロールを割り当ててください。最後に 次へ：レビューと作成 のボタンを押します。
6．アカウントが作成されたら、さらに セキュリティグループ を作成して、メンバーとして追加します。
推奨は、２アカウント作る
同様の手順で２アカウントを作ってください。
セキュリティグループの考え方
私のテナントでは、セキュリティグループを１つ作って、２つの Break glass アカウントを追加して運用しています。
場合によっては、この１つのグループがシングルポイントだというご指摘もあるかもしれません。
そこが気になる場合は、グループ化せずに、１アカウントずつ、後述する 条件付きアクセス の処理で除外してください。
公開情報：緊急アクセス用アカウントを作成する
https://learn.microsoft.com/ja-jp/entra/identity/role-based-access-control/security-emergency-access?wt.mc_id=MVP_407731#create-emergency-access-accounts
4. 条件付きアクセスの影響を受けないようにする
作業対象
➀ MFA のみ = 実施します。
➁ パスキーのみ = 実施します。
➂ 併用 = 実施します。
現在 作成されている条件付きアクセスを １つずつ 開いていきます。
全てのポリシーに対して、対象外のユーザーとして Break glass 用に作成したセキュリティグループを割り当てます。
What IF を使って、作成した Break Glass が、どのポリシーにも適用されていないことを確認します。
緑枠のとおり ポリシーがありません と表示されていれば OK です。
すべての条件付きアクセスポリシーの除外設定に、Break glass アカウントが追加されれば、OK です。
今後も 新しく 条件付きアクセスポリシーを作成するたびに、Break glass アカウントを除外しましょう。
このようにすることで、設定ミスで 管理者が締め出されてしまった場合でも、 Break glass アカウントを使って対処することが可能になります。
公開情報：条件付きアクセスに関する考慮事項
https://learn.microsoft.com/ja-jp/entra/identity/role-based-access-control/security-emergency-access?wt.mc_id=MVP_407731#conditional-access-considerations
5. Microsoft Authenticator を有効化する
作業対象
➀ MFA のみ = 実施します。
➁ パスキーのみ = 実施しません（逆に 有効にする が、OFF である必要があります）
➂ 併用 = 実施します。
認証方法 から Microsoft Authenticator を開きます。
有効にする が ON になっていることを確認します。
ターゲットは すべてのユーザー になっていれば OK です。
または グループの選択 となっていた場合は、先ほど作成した セキュリティグループ (Break glass Group) を追加してください。
作成した Break glass アカウントが、Microsoft Authenticator で認証できる状態になっていれば OK です。
6. Microsoft Authenticator をセットアップする
➀ MFA のみ = 実施します。
➁ パスキーのみ = 実施しません。
➂ 併用 = 実施します。
※作成した Break glass アカウントごとに作業を行います。
作成した Break glass アカウントに対して、Microsoft Authenticator をセットアップします。
1．Microsoft Entra 管理センターにサインインします。
https://entra.microsoft.com
2．作成した Break glass アカウントでサインインします。
3．以下の画面が表示されます。
4．以下の画面が表示されたら 次へ を押します。
5．表示された QR コードを スマホ側 Authenticator の QR コードで読み取ります。
6．以下のように登録されれば OK です。
パスワード + Authenticator でサインインできるようになれば OK です。
公開情報：Microsoft Authenticator について
https://support.microsoft.com/ja-jp/authenticator/about-microsoft-authenticator
7. パスキー (FIDO2) を有効化する
➀ MFA のみ = 実施しません。
➁ パスキーのみ = 実施します。
➂ 併用 = 実施します。
※既に、パスキーが有効化されていれば、本章は SKIP して構いません。
1．Microsoft Entra 管理センター にサインインします。
※認証ポリシー管理者のロールが必要ですが、グローバル管理者であれば OK です。
https://entra.microsoft.com/
2．左ペインの 保護 を開き 認証方法 を選択し 認証方法｜ポリシー のページを開きます。
パスキー (FIDO2) の欄をクリックして開きます。
3．有効化およびターゲット タブで 有効化する を ON にします。
なお、下記の設定では テナント内の 全ユーザー に対して FIDO2 が有効化されます。
限られたユーザーに対してのみ FIDO2 を許可するためには、グループの選択をしてください。
4．続いて、構成 タブは、この時点では変更はしませんが、既定値を憶えておきましょう。
保存 をクリックすると、設定が有効化されます。
5．以下の通り、有効 になったことが確認できます。
6．上記の設定が完了すると、各ユーザーの マイアカウント の画面で セキュリティ キー が選択できるようになります。
公開情報：Microsoft Entra IDでFIDO2パスキーを有効にする方法
https://learn.microsoft.com/ja-jp/entra/identity/authentication/how-to-authentication-passkeys-fido2?wt.mc_id=MVP_407731
8. Temporary Access Pass (TAP) を有効化する
➀ MFA のみ = ✕：実施しません。
➁ パスキーのみ = 〇：実施します。
➂ 併用 = ✕：実施しません。
パスキーのみの構成の場合だけ、セキュリテイ情報 の画面にサインインして FIDO2 セキュリティキーを割り当てるためには、TAP（一時アクセスパス）を発行しておく必要があります。
※それ以外の方式では、Authenticator + 通知 を使ってサインイン可能です。
1．一時アクセスパス (TAP) の有効化
以下を参考に、テナント内での TAP が利用可能となるように有効化します。
一時アクセスパス (TAP) を使っている理由は、アカウントにパスキーを紐づけるためには、セキュリティ情報 (My Sign-ins) というサイトに 多要素認証 または TAP が必須です。
多要素認証 を行うためには、スマートフォンを使って Authenticator の設定＆登録が必要となりますが、今回は Break glass です。スマートフォンへの紐づけは行わないため、TAP を使って セキュリティ情報 (My Sign-ins) にサインインさせることを目的としています。
公開情報：一時アクセス パスを構成してパスワードレス認証方法を登録する
https://learn.microsoft.com/ja-jp/entra/identity/authentication/howto-authentication-temporary-access-pass?wt.mc_id=MVP_407731
2．続いて、Break glass アカウントに対して TAP を発行します。
※TAP は、一時使用 で発行します。
3．TAP が発行されたら表示された値をメモします。
・赤下線 (https://aka.ms/mysecurityinfo) がパスキーを登録するためのサイト
・一時アクセスパスが 緑枠 です。
公開情報：一時アクセス パスを作成する
https://learn.microsoft.com/ja-jp/entra/identity/authentication/howto-authentication-temporary-access-pass?wt.mc_id=MVP_407731#create-a-temporary-access-pass
9. パスキー (FIDO2 セキュリティキー) を割り当てる
➀ MFA のみ = 実施しません。
➁ パスキーのみ = 実施します。
➂ 併用 = 実施します。
※作成した Break glass アカウントごとに作業を行います。
作成した Break glass アカウントに対して、以下の記事の手順を参考に FIDO2 セキュリティキー を割り当ててください。
1．以下の URL にアクセスします。
https://aka.ms/mysecurityinfo
2．以下のサインイン画面に ユーザーアカウント を入力して Next を押します。
3．パスワード + MFA が要求されたら、認証してください。
以下のように、一時アクセスパス の入力を促されたら、前章で発行した TAP を入力します。
これ以降の作業は、以下の Yubikey についてのまとめ記事 で取り上げている内容と共通の部分が多いため、こちらの記事も参考にしてみてください。
Yubikey まとめ（利用可否検証あり）
https://qiita.com/carol0226/items/1e28bdc3acc4c7814da2
4．以下の画面に遷移するため ＋Add sign-in method を押します。
5．以下のウィンドウが開くため Security key を選択します。
6．以下の画面では、USB device を選択します。
7．以下の画面では Next を押します。
8．以下の画面では、セキュリティキー を選択して 次へ を押します。
9．以下の画面では OK を押します。
10．以下の画面では OK を押します。
11．この画面が表示されたら FIDO2 セキュリティキーを挿入します。
12．FIDO2 の認証を行うことで、以下の画面になります。
13．登録した FIDO2 セキュリティキー を識別できるように 名前を入力して Next を押します。
おススメ
ここで、名前を指定する際に、FIDO2 セキュリティキーのシリアル No. も入力するようにしておくと良いと思います。
14．名前を登録すると、以下のウィンドウが表示されます。
15．登録が完了すると、以下の画面が表示されます。
セキュリティ情報 (My Sign-ins) で FIDO2 セキュリティーキー を割り当てる作業は、サインインしてから 5 分以内に完了させてください。そうしないと、タイムアウトします。そうなったら、再度 TAP を発行するところからやり直してください。
16．Break glass アカウントを使って、Entra 管理センター へサインインします。
https://entra.microsoft.com
17．FIDO2 セキュリティキーを使って、サインイン することができれば OK です。
公開情報：パスキーの登録 (FIDO2)
https://learn.microsoft.com/ja-jp/entra/identity/authentication/how-to-register-passkey?wt.mc_id=MVP_407731
10. パスキー (Microsoft Authenticator のパスキー）を割り当てる
➀ MFA のみ = 実施します。
➁ パスキーのみ = 任意
➂ 併用 = 任意
※作成した Break glass アカウントごとに作業を行います。
任意 = セキュリティキーの登録があれば十分ですが、任意で追加登録することもできます。
物理キー紛失時の回避策になります。
Authenticator + 通知 の設定を行っている場合は、対象のアカウントを開くと パスキーの作成 というメニューがあるため、そこから 作成することができます。
公開情報：Android または iOS デバイスの Authenticator にパスキーを登録する
https://learn.microsoft.com/ja-jp/entra/identity/authentication/how-to-register-passkey-authenticator?wt.mc_id=MVP_407731
11. Break glass 専用ポリシーを追加する（追加案）
固定 IP や利用可能なアクセス拠点が確保できる環境でのみ推奨します。
なぜ、あえて セオリー外 の設計を採用するのか？
Break glass の ベストプラクティスなセオリー設定を実施した場合に、すべての条件付きアクセスから除外させることになるので、不安を感じたからです。
セキュリティ的に脆弱な設定を、世界中にさらしておくのは 不安を感じる場面もあるのではないでしょうか？
本記事を完成させるにあたって、セオリーな設定と、私の不安（心のもやもや）を数週間抱え続けた結果、セオリー無視での私のこだわり設定を披露し、これを起点に 皆さん自身での Break glass の在り方も考えてほしいと思ったからです。
私のこだわり設定は、設定ミスによる崩壊のリスクをとって、心のもやもやを解消できるセキュリティレベルに上げることです。これによって、私自身がスッキリして 眠れる状態になったので、良しとします。
Break glass 専用ポリシーの構成
1．条件付きアクセス のメニューから ネームドロケーション を選び ＋IP 範囲の場所 を押します。
任意の名前（Break glass Location）を付与して、自宅や職場 などで IP が固定されている場所を登録します。
注意
テナントが条件付きアクセスでロックアウトした際には、この場所へ移動して解除する必要がるので、注意してください。
2．任意の名前 (Break glass Policy) の条件付きアクセスポリシーを作成します。
割り当て：組み込まれた特定のユーザー = Break glass Group
ターゲットリソース：すべてのリソース
3．以下の通り、ネームドロケーションで設定した場所 (Break glass Location) を対象外の場所として設定します。
ネットワーク（対象）：任意のネットワークまたは場所
ネットワーク（対象外）：選択したネットワークと場所（Break glass Location)
Break glass に割り当てた FIDO2 セキュリティキーの管理
今回、Break glass に割り当てた FIDO2 セキュリティキー は、適切に管理する必要があります。
-
無くさないように保管する
管理者によって、無くさない場所 は、さまざまです。
一般論としては、金庫などに保管する形をとります。
公開情報：アカウントの資格情報を安全に保管する
https://learn.microsoft.com/ja-jp/entra/identity/role-based-access-control/security-emergency-access?wt.mc_id=MVP_407731#store-account-credentials-safely
-
普段使いはしない
Break glass アカウントは、最高権限を持ってます。
これを、普段使いしてしまっては、意味がありません。
なぜかというと、普段使いしている際に、設定ミスをしたらどうなりますか？
それを助けるための管理者アカウントがありません。それでは本末転送です。
普段使いの管理者アカウントを救うためのアカウントが Break glass ですので、普段使いはせずに保管しておきましょう。
-
棚卸をする
一定期間ごとに、棚卸を実施してください。
棚卸とは、実際に FIDO2 セキュリティキー を使って、サインインを実施することです。
棚卸間隔は、Microsoft としては、90 日ごとが推奨されています。180 日を推奨している人もいます。
ルールを決めて、必ず 棚卸は実施してください。
そこにあると思っていた場所に、FIDO2 セキュリティキー が無い場合に問題ですし、なんらかの影響で サインインできなくなっている場合も考えられます。いざという時に、使えるようになっている状態を維持することが目的です。
公開情報：アカウントを定期的に検証する
https://learn.microsoft.com/ja-jp/entra/identity/role-based-access-control/security-emergency-access?wt.mc_id=MVP_407731#validate-accounts-regularly
以上で、最小限度の Break glass アカウントを作成することができました。
つまらない設定ミスで テナントに２度と入れなくなるという問題を防ぐことができるようになりました。
追加検討（その１）：Break glass の監査
Break glass は“使われたら異常”という前提で監査設計する必要があります。
Break glass アカウントは「使われないことが前提」のアカウントです。
そのため、“いつ使われたか”を確実に把握できる状態にしておくことが極めて重要です。
通常の管理者アカウントであれば日常的な操作ログが蓄積されるため、ログの中から異常を検知する運用が可能ですが、
Break glass の場合は逆です。
サインインが発生した時点で、それ自体がインシデント候補になります。
■ 監査の基本方針
Break glass の監査は、次の3つの観点で設計します。
① リアルタイム検知（即時アラート）
Break glass アカウントでサインインが発生した瞬間に検知できるようにします。
- サインインログ（Sign-in logs）
- 監査ログ（Audit logs）
これらをベースに、以下のような通知設計を行います。
- Microsoft Sentinel / Log Analytics によるアラート
- 条件付きアクセスの異常サインイン検出との連携
- 情報システム部へのメール通知・Teams通知
理想は「人が気づく」ではなく「仕組みが検知する」状態です。
② 利用の正当性確認（承認プロセス）
Break glass は「緊急時のみ使用」されるべきものです。
そのため、利用時には必ず以下を記録・確認します。
- 利用理由（なぜ Break glass が必要だったか）
- 実施内容（何を変更したか）
- 実施者（誰が使用したか）
- 利用時間（いつからいつまで）
運用上は、以下のようなルールが有効です。
- 利用前 or 利用直後にチケット起票（ITSM連携）
- 利用後レビュー（ポストレビュー）
- 定期的な監査ログの棚卸
③ 不正利用の兆候検知
Break glass は条件付きアクセスから除外されることが多いため、
通常のアカウントよりも 攻撃者にとって魅力的 です。
そのため、単純なサインイン検知に加えて、以下の観点も確認します。
- 通常と異なる場所からのアクセス（国・IP）
- 業務時間外の利用
- 短時間での権限変更やポリシー変更
- MFA 登録や認証方法変更の発生
■ 設計のポイント
Break glass の監査は、「ログを残す」ことが目的ではなく、
“見逃さないこと”と“意味のある記録として残すこと”
が重要です。
そのためには、
- ログ収集（Log）
- 検知（Detect）
- 通知（Notify）
- 記録（Record）
この一連の流れを「運用として回る状態」にしておく必要があります。
⚠ 注意
Break glass の性質上、「使われないこと」が正常です。
そのため、ログの量ではなく「イベントの質」で判断する必要があります。
「ログが少ないから大丈夫」ではなく、
「発生した1件を確実に捕まえる」設計にすることが重要です。
公開情報：監査可能性とコンプライアンス
https://learn.microsoft.com/ja-jp/entra/identity/role-based-access-control/security-emergency-access?wt.mc_id=MVP_407731#auditability-and-compliance
追加検討（その２）：Entra PIM（特権管理者）の併用
Break glass が守るのは“可用性”、PIM が守るのは“安全性”です。
Break glass は「最後の手段」、
PIM（Privileged Identity Management）は「日常の安全運用」を支える仕組みです。
この2つは対立するものではなく、役割が明確に異なる補完関係にあります。
■ Break glass と PIM の役割の違い
| 役割 | Break glass | PIM |
|---|---|---|
| 目的 | ロックアウト回避 | 特権の最小化 |
| 利用頻度 | ほぼゼロ | 日常的 |
| 利用タイミング | 緊急時のみ | 必要なときだけ昇格 |
| セキュリティモデル | 制御からの除外 | 制御の強化 |
Break glass は「外側の保険」、PIM は「内側の統制」です。
■ なぜ PIM を併用するのか
Break glass が整備されている状態でも、
日常的に強い権限を持ったアカウントが存在していると、以下のリスクが残ります。
- 誤操作による構成変更
- 権限の過剰付与
- 攻撃時の影響範囲拡大
- 誰が何をしたか分からない（トレーサビリティ不足）
PIM を導入することで、これらを大きく改善できます。
■ PIM による具体的な改善ポイント
① Just-in-Time（必要なときだけ管理者）
通常時は一般ユーザーとして運用し、必要な時だけ昇格します。
- グローバル管理者 → 必要時のみアクティブ化
- 最小権限の原則の実現
② 承認フローの導入
管理者昇格に承認を必要とすることで、ガバナンスを強化できます。
- 上長承認
- セキュリティチーム承認
- 管理者同士の相互承認
③ 操作のトレーサビリティ確保
昇格の履歴、操作履歴が明確に残るため、
- 誰が
- いつ
- なぜ
- どの権限で
作業したのかを明確にできます。
④ セキュリティ制御の追加
昇格時に追加の条件を課すことも可能です。
- MFA 必須
- 承認時の理由入力
- 使用時間の制限（自動失効）
■ Break glass × PIM の設計バランス
ここで重要なのは、
「Break glass を PIM に入れない」という判断です。
理由はシンプルで、Break glass は「確実に入れること」が最優先だからです。
PIM を適用すると、
- 承認が必要
- 条件が増える
などにより、緊急時に使えないリスクが発生します。
■ 推奨アーキテクチャ
- 通常管理者：PIM で管理（JIT・承認・ログ）
- Break glass：PIM 非対象（即時利用可能）
この構成により、
- 平常時：安全な運用（PIM）
- 非常時：確実な復旧（Break glass）
という役割分担が成立します。
設計の考え方
Break glass と PIM は「どちらか」ではなく「どう組み合わせるか」です。
- PIM は「事故を起こさない仕組み」
- Break glass は「事故から復旧する仕組み」
この2つを分離して設計することで、初めて現実的なセキュリティ運用が成立します。
以下は、PIM についての私の Qiita 記事です。
まとめ
本記事では、Microsoft Entra ID における Break glass アカウントについて、
構成方法と設計の考え方を紹介しました。
まずは、実際に Break glass アカウントを構成することで、
「テナントから締め出されないための最低限の備え」を整えることができました。
これはあくまで最初の一歩です。
Break glass は「作って終わり」ではなく、
運用の中で見直し続けることが前提となる設計対象です。
特に重要なのは、以下の観点です。
- 認証方式の依存関係（単一依存になっていないか）
- 紛失・障害時の可用性（本当に復旧できる状態か）
- 侵害リスクに対する耐性（攻撃面が露出していないか）
構成パターンの比較でも触れたように、
Break glass 設計にはトレードオフがあり、絶対的な正解はありません。
重要なのは、
「どのリスクを許容するのか」を理解したうえで設計することです。
また、本記事で紹介したネームドロケーションのように、
セオリーを補完する設計も選択肢となります。
環境や要件に応じて、自身の組織にとって最適な形を検討してください。
最後に。
Break glass は「最後に入るためのアカウント」ではなく、
「最後まで壊れないように設計する仕組み」 です。
そしてその本質は、「例外を作ること」ではなく、
「制御されていない経路を、意図的に設計・管理すること」 にあります。
その本質を理解した上で、まずは構成してみること。
そして、運用しながら見直していくこと。
このサイクルを回していくことが、
テナントの安全性を高める第一歩になります。
関連情報
お勧め記事
Break glass の設計をより深く理解したい方向けに、特に参考になる記事を紹介します。
🌍 グローバルで評価の高い包括的解説
Break glass の設計を網羅的に理解したい場合におすすめです。
Break-Glass Accounts Done Right: Securing Emergency Access in Microsoft Entra
https://www.chanceofsecurity.com/post/break-glass-accounts-done-right-securing-emergency-access-in-microsoft-entra#viewer-c524y93399
⚖️ 設計思想・ガバナンス視点
技術的な実装ではなく、「なぜ Break glass が必要なのか」という考え方を整理できます。
その他の関連記事
Break glass の構成やベストプラクティスを様々な観点から補足する記事です。
実装例・考慮事項
実務向けベストプラクティス
MFA 観点からの設計
Microsoft Q&A（実運用の疑問ケース）
セキュリティ観点のまとめ