【クラウド法務】条件付きアクセスの例外運用でトラブルになりやすい3つのポイント— Entra ID 条件付きアクセス “例外” を入れる前に整理したい契約・責任分界と監査の落とし穴（条件付きアクセス 例外運用 法務）—
- 山崎行政書士事務所
- 2025年12月12日
- 読了時間: 7分
導入：ゼロトラストは動いている。でも「例外」が増えた瞬間に統制が崩れる
条件付きアクセス（Conditional Access）は、M365／Entra ID のゼロトラスト運用でほぼ必須の機能です。MFA、準拠デバイス、サインインリスク、国・拠点制御など、技術情報は豊富で「設計して適用する」までは進めやすい一方、現場で必ず出てくるのが “例外運用” です。
全国の情シス・IT部門の方から相談を受けていると、こんな声を非常によく耳にします。
「海外出張／工場の共有端末／役員端末など、例外を入れないと業務が止まる」
「ベンダー作業のために例外を許したら、いつの間にか恒久化していた」
「監査や親会社に “その例外、誰が承認して、どのリスクを取ってるの？” と聞かれて詰まった」
条件付きアクセスは「堅いポリシーを作る」よりも、例外をどう統制するか で成否が決まります。本記事では、「条件付きアクセス 例外運用 法務」 の視点で、よくある落とし穴と、実務で使える整理の型をご紹介します。
1. 条件付きアクセスの“例外運用”で現場が実際に組む構成（技術の事実整理）
1-1. 典型構成（テキスト簡易アーキテクチャ）
ID基盤：Entra ID（旧 Azure AD）
端末管理：Intune（準拠デバイス条件）
アクセス制御：条件付きアクセス（CA）
対象：M365（Exchange/SharePoint/Teams）＋主要SaaS（Box, Salesforce, ServiceNow 等）
リスク連携：Identity Protection（サインインリスク／ユーザーリスク）
ログ：Sign-in log / Audit log（＋SIEM連携は企業により差）
1-2. “例外”が発生する典型パターン（技術的には自然）
条件付きアクセスの例外は、だいたい次のどれかで発生します。
海外出張・海外拠点：国制限・MFA・デバイス準拠条件に引っかかる
現場端末（工場・倉庫・店舗）：共有端末／古い端末／キオスク端末で準拠にできない
役員・VIP：MFA や端末制御の“強さ”に現実が追いつかない（しかし入口は守りたい）
委託先・ベンダー作業：一時的に管理画面アクセスが必要
緊急対応：障害時に CA が強すぎて管理者が入れない（Break-glass問題）
古い認証方式・例外アプリ：レガシー認証、例外的なアプリ制約がある
ここまでは技術の話として、どの企業でも起きる“あるある”です。
ただし――ここからが法務。
技術として例外を入れること自体は簡単でも、問題は次の点です。
その例外を 誰が承認 したのか
例外の 有効期限 と 見直し があるのか
例外によって発生する 追加リスク を、社内・監査・取引先に説明できるか
事故が起きたときに 責任分界（Microsoft／ベンダー／自社）が整理されているか
この「説明責任の設計」がないまま例外が増えると、統制が崩れます。
2. 全国の案件で見えてきた「例外運用の落とし穴」3選
代表的なものを3つに絞ると、次のパターンが多いです。
① 例外が“口頭・チャット承認”で増殖し、証跡が残らない
技術的にはOK：一時的に CA の除外ユーザー／除外グループを作って業務を回す
法務・監査的にはNG：
「誰が」「なぜ」「どのリスクを見て」「いつまで」例外を許したかが残らない
監査・親会社・取引先に説明できない
インシデント発生後に“統制不備”として扱われやすい（事故の有無に関係なく揉める）
② “期限なし例外”が恒久化して、ゼロトラストの前提が崩れる
技術的にはOK：海外出張対応、役員対応、ベンダー作業で例外を継続
法務・実務的にはNG：
例外ユーザーが増えるほど 「入口の統制は効いている」と言えなくなる
ベンダー契約終了後も例外が残る、退職者・異動者で棚卸し漏れが起きる
事故が起きたとき「例外が原因だったのでは？」が争点化しやすい（説明不能）
③ 例外運用が“委託先管理・責任分界”と接続されていない
技術的にはOK：委託先にゲスト招待／一時的除外で作業させる
法務・契約的にはNG：
委託先のアクセス権限、ログの閲覧範囲、再委託、作業時間帯、緊急時の対応が契約・運用に落ちていない
「設定を変えたのは誰か」「その変更は承認されていたか」が曖昧になり、責任が宙に浮く
取引先や監査対応で “統制の外部化” と見なされるリスクがある
3. 条件付きアクセスの例外運用を崩さないための「整理のフレーム」3つ
技術構成を大きく変える前に、最低限これだけを紙に落とすと、社内説明とベンダー調整が一気に楽になります。
① 例外の“承認モデル”を決める（誰が決めるか・いつまでか）
例外は「例外だからこそ」手続が必要です。最低限、次を決めます。
承認者：情シスだけでなく、必要に応じてセキュリティ責任者／事業責任者も巻き込む
理由の型：海外出張／現場端末／役員／委託先／障害対応など、カテゴリ化
有効期限：原則「期限付き」（例：7日／30日／四半期まで）
例外台帳：誰に、何の例外を、いつまで、どのリスクで許容したか（監査に出せる形）
例外を“設定”ではなく“意思決定”として扱うのがポイントです。
② 技術的な例外の入れ方を“統制しやすい形”に寄せる
例外の作り方も、後から説明しやすいパターンに寄せます。
除外グループを乱立させない（命名規則＋用途固定）
例外は「一時的付与」に寄せる
可能なら PIM／アクセスパッケージ／期限付きグループなどで「自動的に戻る」設計へ
Break-glass は別枠管理（通常例外と混ぜない）
例外の監視
例外グループのメンバー変更ログ
CA ポリシー変更ログ
“例外が増えた”こと自体をアラート対象にする
ここまでやると、技術的にも「事故りにくい例外運用」になります。
③ 契約・規程・監査ストーリーを“例外前提”で整合させる
例外がある現実を前提に、法務・ガバナンス側も揃えます。
委託契約：委託先のアクセス権限、作業範囲、ログ、再委託、緊急時対応、終了時の剥奪
社内規程：在宅勤務／BYOD／海外利用／共有端末の扱い（例外をどこまで許すか）
インシデント手順：例外中に事故が起きた場合の初動・ログ保全・説明責任の担当者
監査向け資料：
「例外ゼロ」を主張するのではなく
「例外はあるが、承認・期限・監視・棚卸しで統制している」を示す
4. ケーススタディ：製造業A社（売上900億、拠点6カ国）の場合
実際に当事務所でご相談を受けた事例の一つをご紹介します（業種等は匿名化しています）。
業種：製造業
売上規模：約900億円
拠点：日本＋欧州＋アジア（6カ国）
テーマ：M365 ゼロトラスト移行に伴う条件付きアクセスの例外運用整理
課題
海外出張・海外拠点・工場共有端末で例外が増え、CAの除外が恒久化
ベンダー作業のために例外を入れたが、契約と運用ルールが追いつかない
監査部門から「例外の承認・棚卸し・証跡」を求められ、情シスが説明に詰まる
当事務所の支援（抜粋）
CA ポリシー・除外グループ・権限の棚卸し（技術構成×運用実態の突合）
例外運用の承認フロー・期限・例外台帳の設計（監査に出せる形へ）
委託先アクセスを前提に、責任分界・契約条項・終了時剥奪の整理
例外の監視・ログ保全・インシデント初動の“誰が何をするか”を文章化
結果
「例外はあるが統制している」状態になり、監査・親会社への説明が一貫
ベンダー任せの例外設定から脱却し、情シスが“方針”として語れる状態へ
例外が自動的に戻る（期限切れで解除される）設計に寄せられ、属人運用が減少
5. 条件付きアクセスの例外運用で、今すぐ確認しておきたいチェックリスト
□ 例外（除外ユーザー／除外グループ／例外ポリシー）の一覧を1枚で出せる
□ 例外ごとに「理由」「承認者」「期限」「見直し頻度」が決まっている
□ 例外は原則“期限付き”で、期限切れで自動的に戻る設計に寄せている
□ Break-glass は通常例外と分離され、保管・利用・証跡が文書化されている
□ 委託先・ベンダーのアクセスは、契約と運用（終了時剥奪・ログ）までつながっている
□ CA ポリシー変更・例外グループ変更のログを、監査で提示できる形で保全できる
□ インシデント時に「誰が・どこまで・いつまでに」を文章化した初動手順がある
□ 「例外ゼロ」ではなく「例外があっても統制できる」社内説明資料がある
すべてにYESと言える企業は、全国的に見てもまだ多くありません。逆に言うと、ここが整理できると「うちはゼロトラストを運用できている」と胸を張りやすくなります。
6. 全国からのご相談について
山崎行政書士事務所では、Entra ID／条件付きアクセスの技術構成と、契約・規程・監査対応をセットで整理する「クラウド法務支援」 を行っています。
条件付きアクセスの例外が増えて、監査・上司への説明が苦しい
ベンダー作業・委託先アクセスの例外運用を、責任分界と契約で固めたい
例外台帳、承認フロー、ログ保全まで含めて、統制の型を作りたい
といったお悩みがあれば、オンライン（全国対応） にて初回のご相談を承っております。
👉 ご相談フォームはこちら
👉 お問い合わせの際に、「条件付きアクセス 例外運用 法務の記事を見た」 と書いていただけるとスムーズです。
コメント