【クラウド法務】Break-glass運用・規程でトラブルになりやすい3つのポイント— Entra ID / M365 の“緊急用アカウント”を作っただけで終わらせない：運用・監査・責任分界まで揃える（Break-glass 運用 規程）—

導入：平常時は問題ない。でも「いざという時」に限って詰むのがBreak-glass

Entra ID（旧 Azure AD）や M365 のゼロトラスト運用が進むと、条件付きアクセス（CA）や MFA、PIM によって、普段の管理はかなり堅くできます。一方で、その“堅さ”が原因で、障害や緊急時に 管理者が入れない／解除できない という事態も普通に起きます。

全国の情シス・IT部門の方から相談を受けていると、次のような声を非常によく耳にします。

• 「Break-glass（緊急用）アカウントは作ったが、運用ルール（規程）がない」

• 「監査で“そのアカウント、誰が使えて、いつ使うの？”と聞かれて、説明資料が出せない」

• 「ベンダー作業や障害対応で一度使ったが、利用後の証跡・パスワード変更・例外解除が曖昧 で不安が残った」

Break-glass は「作る」ことが目的ではなく、“緊急時に、確実に、統制された手順で使える状態を維持する” ことが目的です。

本記事では、「Break-glass 運用 規程 × クラウド法務」 という視点から、技術・責任分界・監査対応をセットにした整理方法をご紹介します。

1. Break-glass運用の“技術的な事実整理”｜現場で実際にどう構成されているか

まずは「技術として何が起きているか」を揃えます。多くの企業での典型構成は次の通りです。

1-1. ありがちな全体像（テキスト簡易アーキテクチャ）

• ID基盤：Entra ID（M365 への入口）

• ゼロトラスト制御：条件付きアクセス（MFA必須、準拠デバイス必須、国制限、リスク制御 等）

• 特権管理：PIM（管理者ロールの一時昇格）

• 監査・ログ：Sign-in log / Audit log（＋SIEM連携がある企業も）

• 運用体制：

  • 自社情シス（アカウント管理）

  • 運用ベンダー（監視・一次対応）

  • 構築ベンダー（設定変更の支援）

1-2. Break-glassが“必要になる”典型シーン（技術的に自然）

Break-glass の出番は、だいたい次のような場面です。

• 条件付きアクセスの設定ミスで 管理者が自分で締め出した

• MFA 連携・認証要素まわりの障害で 正規の管理者がログインできない

• 大規模障害で通常運用フローでは間に合わず、緊急で設定緩和・復旧 が必要

• 侵害疑い対応で、アカウント停止・強制サインアウト・アクセス遮断 などを即時実施したい

ここまでが技術の話です。

そして、ここからが法務です。

技術として「緊急用アカウントがある」だけでは足りません。“誰が・どの条件で・どの手順で・どの証跡を残して使うか” が決まっていないと、監査・親会社・取引先説明で詰みます。

2. 全国の案件で見えてきた「Break-glass 運用 規程」の落とし穴3選

① Break-glassが“存在するだけ”で、運用ルールも証跡もない

• 技術的にはOK緊急用の管理者アカウント自体は作ってある（パスワードも保管してある）。

• 法務・監査的にはNGになりやすい

  • 「誰が使えるか」「いつ使うか」「誰が承認するか」が文書化されていない

  • 利用記録（いつ、誰が、何の目的で）が残らず、後から説明できない

  • 結果として、事故が起きていなくても 統制不備（ガバナンス不備） と評価されやすい

② 一度使った後の“戻し”が曖昧で、例外が恒久化する

• 技術的にはOK緊急対応として設定を緩和し、サービス復旧に成功する。

• 法務・実務的にはNGになりやすい

  • 緊急対応で入れた例外（権限付与、例外グループ、設定緩和）が戻されず残る

  • パスワード・認証要素の再発行、管理者ロール棚卸しが実施されない

  • 「緊急の一回」がきっかけで、恒久的に統制が弱くなる（しかも誰も気づかない）

③ ベンダー・委託先・当番体制と責任分界がつながっていない

• 技術的にはOK夜間・休日の障害時、運用ベンダーが動ける体制になっている。

• 契約・責任分界的にはNGになりやすい

  • ベンダーが Break-glass を使う／使わないが曖昧

  • 使うなら「どの範囲まで」「誰の指示で」「どのログを提出するか」が契約にない

  • 使わないなら「自社の誰が夜間に開封・承認できるのか」が決まっていない→ つまり 緊急時に“動けるはずの人が動けない”設計 になりやすい

  • 
    

3. Break-glass運用・規程を整えるための「整理のフレーム」3つ

ここが記事の核です。技術構成を変える前に、最低限この3つを紙に落とすだけで、社内説明と監査対応が一気に楽になります。

① 例外ではなく“BCP手順”として定義する（発動条件・承認・記録）

Break-glass は「特別な裏口」ではなく、BCP／インシデント対応手順の一部として定義します。

• 発動条件（トリガー）例：

  • 管理者がログイン不能で、復旧までに一定時間以上かかる見込み

  • 侵害疑いで緊急遮断が必要

  • 監査・法令・契約上、即時対応が求められる重大インシデント

• 承認者（意思決定者）

  • 情シス責任者／セキュリティ責任者／当番管理者

  • 夜間・休日の承認ルート（代理・代替）

• 記録（証跡）

  • いつ、誰が、どの目的で、どんな操作をしたか

  • “使っていない月”も、点検記録があると強い（監査で刺さる）

ポイントは「Break-glassを使うこと」自体を悪者にしないこと。“使ってよい条件”と“説明できる形”があることが統制です。

② “保管・開封・使用・復旧後”までを運用プロセスとして固定する

規程（ルール）に落とすなら、少なくとも次の流れを固定します。

• 保管：パスワードや認証情報の保管方法（オフライン／金庫／二重管理 等）

• 開封：開封者・立会者（単独開封にしない設計が好まれやすい）

• 使用：

  • 使う作業端末・ネットワーク（社内端末限定など）

  • 実施できる操作の範囲（“復旧に必要な最小限”の原則）

• 復旧後（ここが超重要）：

  • 例外の解除（緩和した設定を元に戻す）

  • Break-glass の認証情報を再発行・再保管

  • 実施ログの保全・報告書化（監査提出を想定した形式）

この「復旧後」まで規程化していない企業が多く、ここが事故の温床になります。

③ 委託契約・運用SLA・責任分界表と接続する

Break-glass は、技術よりも「人と契約」が事故を生みます。ここを揃えます。

• 責任分界（誰が何を担保するか）

  • Microsoft（サービス提供範囲）

  • 構築ベンダー（設計・変更の支援範囲）

  • 運用ベンダー（監視・一次対応・エスカレーション範囲）

  • 自社（最終判断・承認・対外説明責任）

• 委託契約に入れたい論点（例）

  • 緊急時の連絡・承認フロー

  • ベンダーが操作する場合の範囲・ログ提出・再委託制限

  • インシデント後の報告期限・報告内容

  • 契約終了時のアクセス剥奪・棚卸し

“緊急時に誰が何をするか”が契約にないと、事故後に「ベンダーの責任か」「自社の責任か」が泥沼化しやすいです。

4. ケーススタディ：製造業A社（売上1,000億、拠点9カ国）の場合

実際に当事務所でご相談を受けた事例の一つをご紹介します（業種等は匿名化しています）。

• 業種：製造業

• 売上規模：約1,000億円

• 拠点：日本＋欧州＋アジア（9カ国）

• テーマ：M365/Entra ID ゼロトラスト運用下での Break-glass 運用規程整備

課題の整理

• 条件付きアクセスと PIM を導入し、平常時は統制できていた

• ただし、障害対応の訓練で

  • 「夜間に誰が開封できるのか」

  • 「使った後に誰が戻しを保証するのか」が曖昧で、BCPとして成立していないことが発覚

• 監査部門から「緊急用アカウントの運用規程」「証跡の残し方」「委託先の関与」を求められ、情シスが説明に詰まった

当事務所の支援内容（抜粋）

• Break-glass を “例外設定”ではなく“BCP手順” として整理（発動条件・承認者・記録様式）

• 責任分界マトリクス を作成（平常時／緊急時／復旧後で役割を分解）

• 委託先・運用ベンダーが関わる場合の 契約条項案 を整備（ログ提出、作業範囲、報告期限）

• 監査・親会社向けに「規程＋運用証跡＋ログ保全」のセットで説明できる資料を作成

結果として

• 「緊急時に動ける」だけでなく、緊急時に動いたことを説明できる 体制になり、監査対応が安定

• “属人的に知っている人だけが開ける”状態から脱却し、継続可能な運用規程へ移行

• ベンダーとの責任分界が明確になり、緊急時の判断遅延が減った…といった声をいただいています。

• 
  

5. Break-glass運用・規程のチェックリスト（今すぐ確認）

□ Break-glass の 発動条件（いつ使うか） が文章化されている□ 承認者・代理承認者（夜間休日含む） が決まっている□ 保管方法（誰がどこに、どう保管し、誰が立会うか）が決まっている□ 使用後の 戻し（例外解除）・認証情報再発行・再保管 が手順化されている□ 使用記録（日時・目的・実施操作・結果）が 監査に出せる形式 で残る□ 例外や特権操作のログが、保持期間・保全手順・提出責任まで整理されている□ ベンダーが関与する場合、作業範囲・ログ提出・再委託・報告期限が 契約で縛れている□ 「作っただけ」ではなく、定期点検・訓練の計画がある

「すべて自信を持ってYESと言える企業」は、全国的に見てもまだ多くありません。

6. 全国からのご相談について

山崎行政書士事務所では、Entra ID / M365 の技術構成と、運用規程・委託契約・責任分界・監査対応をセットで整理する『クラウド法務支援』 を行っています。

• Break-glass を作ったが、規程・承認・証跡が追いついていない

• 監査・親会社・取引先からの質問に、一貫したストーリーで答えられるようにしたい

• 委託先・運用ベンダーが絡むため、責任分界と契約条項を固めたい

といったお悩みがあれば、**オンライン（全国対応）**にて初回のご相談を承っております。

👉 ご相談フォームはこちら

👉 お問い合わせの際に、「Break-glass 運用 規程の記事を見た」 と書いていただけるとスムーズです。