【クラウド法務】ゼロトラストIAMは本当に安全か？ 技術と契約のズレに注意―「条件付きアクセス/PIM/SSO」を入れても、“事故対応と説明責任”は自動では付いてきません（ゼロトラスト IAM／責任分界／契約）―

※本記事は一般的な情報提供であり、個別案件の法的助言ではありません。

────────────────────────────

目次

1. ゼロトラストIAMの“技術的な全体像”（まず事実整理）

2. よくある「法務・契約の地雷」3選（技術はOK、契約はNG）

3. ゼロトラストIAMを“安全にする”整理フレーム（3つの軸）

4. ケーススタディ（匿名化）：製造業A社の場合

5. いま確認しておきたいチェックリスト

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

はじめに（共感パート）【300〜500文字】

ゼロトラストは「社内だから安全」ではなく、「常に検証する」考え方です。最近はID（認証）を中心に、SSO、MFA、条件付きアクセス、PIM（特権管理）などを組み合わせて“ゼロトラストIAM”を実装する企業が増えています。ただ、全国の情シス・IT部門の方から相談を受けていると、次の声をよく耳にします。

「技術的には整ってきたが、事故が起きたときの責任分界やログ提出が契約に落ちていない」「委託先や海外拠点が絡むと、例外運用が増えて統制が崩れる」「監査や取引先から“本当に安全と言える根拠は？”と聞かれ、説明資料が作れない」

本記事では、ゼロトラストIAMを“本当に安全な状態”にするために、技術より先に整理しておきたい「契約・責任」のポイントを解説します。

────────────────────────────

1. ゼロトラストIAMの“技術的な全体像”（まず事実整理）────────────────────────────

ゼロトラストの入口は「ネットワーク境界」ではなく「ID」です。ゼロトラストIAM（Identity and Access Management）は、ざっくり次の部品で構成されます。

（1）IdP（認証の中核）・ID基盤（例：Entra IDのようなクラウドID）・SSO（SAML/OIDC）でSaaSや社内アプリに連携

（2）強い認証・MFA（Authenticator、生体、FIDO2等）・パスワードだけに依存しない

（3）条件付きアクセス（アクセス判定のルール）・端末の準拠状態（管理端末か、暗号化されているか等）・場所（社内/海外/高リスク地域）・リスク（不審なサインイン）・アプリごとのルール

（4）特権アクセス管理（管理者を“必要時だけ強くする”）・PIM等で管理者権限を期限付き・承認付きで付与・常設管理者を減らす

（5）ログと監視（証跡）・サインインログ・監査ログ（管理操作、ポリシー変更、権限付与など）・必要に応じてSIEMへ集約し長期保管

（6）例外・緊急時の仕組み・Break-glass（緊急用）アカウント・障害時の回避策、復旧手順

多くの企業での構成イメージ（テキスト図）

【ユーザー】社員／委託先／海外拠点　↓（SSO/MFA）【ID基盤】SSO＋条件付きアクセス＋特権管理　↓【利用先】M365／各種SaaS／社内アプリ／クラウド管理画面　↓【ログ】サインイン・管理操作・ポリシー変更 → 監視基盤（必要ならSIEM）

ここまでは技術の話です。しかし、実際に事故・監査で問われるのは次の部分です。

「誰が、どこまで、いつまでに対応するのか」「どのログを、どの期間、どの形式で提出できるのか」「委託先・再委託先・海外拠点が絡むとき、契約上の整合は取れているのか」

つまり、ゼロトラストIAMは“技術で強くする”だけでは完結せず、契約と運用で「説明できる形」にしないと“安全と言い切れない”状態が残ります。

────────────────────────────

2. よくある「法務・契約の地雷」3選（技術はOK、契約はNG）────────────────────────────

ここからが「技術はOK／法務はNG」のギャップです。代表的な地雷は次の3つです。

────────────────────────────

地雷①：ゼロトラストにしたつもりでも、事故時の責任分界が“空白”のまま────────────────────────────

技術的にはOK・MFAも条件付きアクセスも入っている・PIMも入れて、管理者を減らした（ように見える）

法務・実務的にはNGになりやすい・障害や侵害が起きたときに、次が契約上あいまい　- 重大障害の一次通知（誰が何分/何時間以内に連絡するか）　- エスカレーション（誰が決断し、誰が復旧作業を実行するか）　- 調査協力（ログ提出、原因分析、再発防止報告）　- 取引先・監査への説明資料（誰が作るか）・IDaaS側は「補償は返金（サービスクレジット）」中心になりやすく、社内の“説明責任”は自社に残る

結果として・事故の初動で「ベンダーの問題」「設定の問題」「委託先の作業」など責任の押し付け合いになり、報告が遅れる・情シスだけが火消しする構図が起きやすい

────────────────────────────

地雷②：例外運用（委託先・海外・VIP・Break-glass）が恒久化し、“統制不備”で刺される────────────────────────────

技術的にはOK・例外が必要な場面（海外拠点、夜間対応、役員の端末、緊急復旧）は確実にある・現場は止めないために例外ルールを作る

法務・監査的にはNGになりやすい・例外が「期限なし」「承認根拠なし」「台帳なし」で増え続ける・Break-glassは“存在”するが、発動条件・使用記録・復旧後手順がない・委託先の管理者権限が常設化し、担当者交代や契約終了時の剥奪漏れが起きる・結果として「ゼロトラストなのに、実態は例外だらけ」と見なされやすい

結果として・監査で「統制が弱い」「例外管理が不十分」と指摘される・事故後に「なぜ例外を残していたのか」の説明ができない

────────────────────────────

地雷③：ログは“見られる”が、監査・取引先へ“提出できる”とは限らない────────────────────────────

技術的にはOK・サインインログも監査ログも画面上は見られる・SIEM連携も設定できる（はず）

法務・実務的にはNGになりやすい・保持期間が短く、監査・不正調査・取引先照会に必要な期間が残っていない・管理操作ログ（ポリシー変更、権限付与、特権の昇格など）の提出形式・提出期限が決まっていない・委託先SOC/海外SOCが絡むとログの所在が複雑化し、提出が遅れる・「保全（リーガルホールド相当）」の手順がなく、上書きや削除が止められない

結果として・“安全に運用している”ことの根拠を出せず、説明責任が崩れる・取引先・親会社の監査で「不十分」と判断され、余計な是正コストが発生する

────────────────────────────

3. ゼロトラストIAMを“安全にする”整理フレーム（3つの軸）────────────────────────────

ゼロトラストIAMを「本当に安全」と言える状態にするには、技術をいじる前に、最低限次の3つを紙に落とすのが近道です。

────────────────────────────

整理軸①：事故別の責任分界（RACI）を作る（誰が実行し、誰が最終判断するか）────────────────────────────

最低限、以下の事故タイプごとに責任を決めます。

・IDaaS障害（全社ログイン不可）・アカウント侵害（乗っ取り、管理者悪用）・設定事故（条件付きアクセスの誤設定、SSO切断）・ログ提出（監査・取引先照会）・委託先事故（再委託・国外含む）

ここで重要なのは、最終責任（A）は基本的に自社から逃げられない点です。だからこそ、ベンダー・委託先に「何を義務として約束させるか（通知・協力・提出）」を契約で固定します。

成果物（1枚でよい）・事故別RACI（実行/最終判断/相談/共有）

────────────────────────────

整理軸②：例外と特権を“運用と規程”で縛る（例外台帳＋期限＋復旧）────────────────────────────

ゼロトラストは、例外をゼロにできません。重要なのは「例外を増やさない」「例外を恒久化させない」ことです。

最低限決めること・例外の発動条件（誰が、どんな理由で）・承認者（情シスだけで決めない。必要ならCSIRT/法務/事業部）・期限（いつまでに戻すか）・補償統制（例外中の監視強化、アクセス範囲の限定など）・復旧後手順（例外解除、記録、再発防止）

Break-glassも同様です。・「存在」ではなく「発動条件・使用記録・復旧後手順」までがセット

成果物・例外台帳（理由、承認者、期限、補償統制、解消ToDo）・Break-glass運用手順（規程・記録・棚卸し）

────────────────────────────

整理軸③：監査で出す“証跡パック”を先に決め、保持・提出・保全を契約に落とす────────────────────────────

ログは「取っている」だけでは弱いです。「必要なときに、必要な期間を、必要な形式で、期限内に提出できる」状態が強いです。

証跡パックの例（最低ライン）・管理者一覧（常設/期限付き、付与理由、承認者）・直近◯ヶ月の管理操作ログ（ポリシー変更、権限付与、特権昇格）・直近◯ヶ月のサインインログ（重要アカウント中心）・例外台帳（例外の期限と解消ToDo）・インシデント時の保全手順（削除停止・上書き停止、凍結依頼のテンプレ）

これを実現する契約要件（押さえどころ）・ログ保持期間（標準/延長の可否と費用）・提出期限（監査・取引先照会で何営業日以内に出せるか）・提出形式（CSV/JSON、タイムゾーン、項目）・保全協力（リーガルホールド相当）・委託先/再委託先にも同等義務を貫通させる（提出・保全・目的外利用禁止）

成果物・証跡パック定義書（“これを出す”を決める）・保持・提出・保全の要件書（契約・運用に落とす）

────────────────────────────

4. ケーススタディ（匿名化）：製造業A社（売上○○億、拠点○○カ国）の場合────────────────────────────

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

・業種：製造業・売上規模：○○億円・拠点：日本＋欧州＋アジア・テーマ：ゼロトラストIAM（SSO/MFA/条件付きアクセス/PIM）を全社導入。運用は一部委託。

課題の整理・技術的にはMFAと条件付きアクセスを導入し、セキュリティは強化された・一方で、委託先・海外拠点・VIP対応の例外が増え、ルールが複雑化・監査で「管理者権限の統制」「例外の管理」「ログの提出」が問われたが、契約・運用の資料が整っていなかった・事故時の一次通知、ログ保全、取引先説明の責任分界が曖昧だった

支援内容（抜粋）・事故タイプ別RACIの作成（障害/侵害/設定事故/ログ提出）・例外台帳と期限付き運用の設計（恒久例外の棚卸し→解消計画）・Break-glass運用の手順化（発動条件、記録、復旧後手順）・証跡パックの定義と、保持・提出・保全を契約条項に落とす整理（委託先にも同等義務）

結果として・監査・親会社・取引先からの質問に「技術＋運用＋契約」で一貫して回答できるようになり、情シスだけが抱える不安が減った・例外が台帳化され、恒久化が止まり、統制が“見える化”できた…といった声をいただいています。

────────────────────────────

5. いま確認しておきたいチェックリスト────────────────────────────

□ ゼロトラストIAMの事故タイプ別に、RACI（実行/最終判断/相談/共有）が決まっている□ 重大障害時の一次通知・復旧・社内周知・取引先説明の手順がある□ 例外運用が台帳化され、期限と解消ToDoが必ず付いている□ Break-glassが「作っただけ」ではなく、発動条件・使用記録・復旧後手順がある□ 管理者権限は常設ではなく、期限付き・承認付き（可能ならJIT）で統制している□ 管理操作ログ（ポリシー変更/権限付与/特権昇格）を監査に提出できる□ ログ保持期間が、監査・取引先要件と整合している□ 提出期限と提出形式（エクスポート）を説明できる□ 委託先・再委託先（国外含む）が絡む場合、同等義務と監督責任が契約で縛れている□ 契約終了時の出口（アクセス剥奪、ログ移管、削除、削除証明）が決まっている

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

────────────────────────────

6. 全国からのご相談について（CTA）────────────────────────────

山崎行政書士事務所では、ゼロトラストIAM（SSO/MFA/条件付きアクセス/PIM等）の技術構成と、契約・規程・監査対応をセットで整理する「クラウド法務支援」を行っています。

・ゼロトラストIAMを導入したが、事故時の責任分界と説明資料が追いついていない・例外運用（委託先・海外・VIP・Break-glass）が恒久化しており整理したい・ログ保持・提出・保全（リーガルホールド相当）まで含めて監査に耐える形にしたい・IDaaS契約と運用委託契約のズレ（SLA、通知、調査協力、提出義務）を潰したい

といったお悩みがあれば、オンライン（全国対応）にて初回のご相談を承っております。お問い合わせの際に「ゼロトラストIAMの記事を見た」と書いていただけるとスムーズです。

────────────────────────────