【情シス向け】IDaaS比較表では分からない「事故が起きたときの責任の所在」― “誰のせいか”ではなく、“誰が何を約束しているか”を先に固定する ―

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

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

0. 先に結論：比較表で見えないのは「責任の階層」が違うから────────────────────────────

IDaaSの比較表（機能・対応プロトコル・UI・価格）で見えるのは「できること」です。でも事故時に揉めるのは「約束されたこと（契約）」と「誰が実務で担うか（運用）」です。

事故が起きたときの責任は、最低でも次の4層に分かれます。

（1）技術原因（どこが落ちた／何が破られた）（2）運用責任（誰が設定し、誰が監視し、誰が一次対応するか）（3）契約責任（SLA、通知義務、調査協力、ログ提出、賠償・免責）（4）説明責任（監査・取引先・親会社・当局への説明）

比較表は（1）に寄りがちで、（2）〜（4）が空欄のまま導入されます。その結果、事故後にこうなります。

「ベンダーの障害だ」 vs 「設定はお客様側」 vs 「運用委託先の作業」→ 最初に揉める → 報告が遅れる → 取引先説明で詰む

この記事では、比較表では見えない「事故時の責任の所在」を、情シスが社内で説明できる形に落とします。

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

1. まず「事故」を6種類に分ける（責任が割れやすい順）────────────────────────────

IDaaSの“事故”は、ざっくり次の6タイプに分類すると整理しやすいです。

A）可用性事故：IDaaSが落ちて全社ログイン不可（ロックアウト含む）B）侵害事故：アカウント乗っ取り、管理者権限の悪用、MFA回避C）設定事故：条件付きアクセス/SSO/プロビジョニングの誤設定で業務停止D）ログ事故：監査ログが残っていない・出せない・改ざん疑義が残るE）委託事故：運用委託先（MSP/MSSP）の操作が原因／再委託先が原因F）説明事故：取引先・監査・親会社に一貫した説明ができない（統制不備）

重要なのは、A〜Cは「止まった」「入れない」なので緊急性が高く、D〜Fは「後から効いてくる」ため、事故後に二次炎上しやすい点です。

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

2. “責任の所在”を決めるための基本フレーム（RACIを事故別に持つ）────────────────────────────

事故時の責任を曖昧にしない最短手段は、事故タイプごとにRACIを作ることです。RACIとは、誰がR：実行責任（実際に手を動かす）A：最終責任（最終判断・責任を負う）C：相談先（判断に関与）I：共有先（情報共有）かを決める枠組みです。

IDaaSで最低限必要な登場人物（例）・IDaaS提供事業者（ベンダー）・導入SI（構築ベンダー）・運用MSP/MSSP（委託先。SOC含む）・自社 情シス（ID運用担当）・自社 セキュリティ/CSIRT・自社 法務/コンプラ・自社 事業部（業務責任者）・人事（Joiner/Mover/Leaverの起点）・利用者（一般ユーザー）

以下は、比較表では埋まらない「事故別RACI」のたたき台です（そのまま社内資料化できます）。

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

3. 事故別：責任が割れやすいポイントと“勝ち筋”の決め方────────────────────────────

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

A）可用性事故：IDaaS障害で全社ログイン不可（ロックアウト含む）────────────────────────────

よくある揉め方・ベンダー：「サービス障害。復旧中。補償はクレジット」・自社：「取引先に説明が必要。いつ復旧？代替は？」・運用委託先：「設定はお客様。範囲外」・SI：「構築はした。運用は別」

比較表では分からない“責任の争点”1）一次通知の責任（誰が何分以内に連絡するか）2）復旧判断の責任（切り戻し・例外解除・MFA回避など）3）社内周知・取引先説明の責任（誰が文章を出すか）4）代替手段（Break-glassや限定アクセス）を誰が持つか

RACIの最低ライン（例）・復旧作業（R）：ベンダー＋自社/運用委託（設定側の切替が必要なら）・最終判断（A）：自社（事業影響の最終責任は自社から逃げられない）・相談（C）：CSIRT/法務/事業部・共有（I）：全社、取引先窓口

勝ち筋（契約と運用で先に固定すること）・「通知期限」「エスカレーション」「重大障害時の報告内容」を契約に落とす・Break-glass運用（発動条件・使用記録・復旧後手順）を社内規程化・「誰が例外解除を承認できるか」を決め、常設例外を禁止する

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

B）侵害事故：アカウント乗っ取り／管理者権限悪用／MFA回避────────────────────────────

よくある揉め方・自社：「不正ログインがあった。ベンダー側の責任？」・ベンダー：「認証は正常。資格情報の漏えいはお客様側」・運用委託先：「通知はした。対応は別契約」・監査：「管理者権限と例外運用が統制されていないのでは？」

比較表では分からない“責任の争点”1）侵害認知と通知の義務（疑い段階での通知含む）2）調査協力（ログ提出、原因分析、再発防止提案）が義務か努力か3）特権アクセス（管理者）の統制責任は誰か4）委託先や再委託先の操作が絡んだ場合、最終責任は誰が負うか

RACIの最低ライン（例）・初動（R）：運用委託先/SOC＋自社CSIRT・封じ込め判断（A）：自社CSIRT（または経営判断ライン）・ベンダー調査協力（R/C）：ベンダー（どこまで義務化されているかが肝）・社外説明（A）：自社（法務・広報・営業）

勝ち筋・管理者権限は「常設禁止」「期限付き」「承認付き」「個人アカウント」「操作ログ必須」を原則にする・インシデント時の「ログ保全」「提出期限」「調査協力」を契約で縛る・再委託（国外含む）があるなら、同等義務と監督責任をフロー・ダウンで貫通させる

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

C）設定事故：条件付きアクセス/SSO/SCIMの誤設定で業務停止────────────────────────────

これが一番“責任が割れやすい”事故です。なぜなら、原因が「人の設定」だからです。

典型例・条件付きアクセスを厳しくしすぎて、海外拠点や役員が入れなくなる・SSO設定変更で特定SaaSだけ止まる・SCIMで退職者を止めるつもりが現役を停止してしまう（誤停止）・IdP側の証明書更新漏れでSAMLが死ぬ

比較表では分からない“責任の争点”1）「誰が設定を変えたか」を追える証跡があるか2）承認フロー（変更管理）が契約や運用に入っているか3）委託先が作業する場合、作業範囲・責任・報告義務は明確か4）検証環境（ステージング）と本番の切替手順があるか

RACIの最低ライン（例）・変更作業（R）：自社情シス or 運用委託先（範囲明確化が必要）・変更承認（A）：自社（業務影響の最終責任）・レビュー（C）：CSIRT/法務（重大変更時）・周知（I）：関係部門

勝ち筋・「変更管理」を“ID運用の必須機能”として設計に組み込む・例外運用は台帳化し、期限と解消ToDoを必ず持つ・委託先が作業するなら、作業報告（チケット番号、実施者、実施時刻、変更内容、ロールバック）を義務化

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

D）ログ事故：監査で出せない／必要期間が残っていない／改ざん疑義が残る────────────────────────────

よくある誤解「ログは画面で見られる」＝「監査・取引先照会で提出できる」ではありません。

責任が割れるポイント・ログ保持期間は誰が決め、誰がコストを負担し、誰が設定するか・提出形式（CSV/JSON、タイムゾーン、項目、抽出者記録）が決まっているか・保全（リーガルホールド相当）：削除停止・上書き停止に協力する義務があるか・SIEM運用委託があると、ログが委託先側にあり“出ない”が起きる

勝ち筋・「証跡パック（監査で必ず出すもの）」を先に定義し、保持・提出・保全を契約化・委託先にはログ提出義務と期限、再委託先にも同等義務を課す・事故時の保全依頼テンプレ（いつ、どの期間、何のログを凍結）を用意する

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

E）委託事故：運用委託先・再委託先（国外）による操作が原因────────────────────────────

比較表で見えない最大の地雷がここです。「委託先がやった」＝「自社は責任ゼロ」にはなりません（対外説明は基本的に自社責任）。

責任が割れるポイント・再委託（国外含む）が事前承諾か、包括許可か・再委託先を国・法人・業務範囲まで特定できるか・同等義務（目的限定、学習利用禁止、ログ提出、保全、アクセス制御）が貫通しているか・一次請けが最終責任を負う条文があるか

勝ち筋・再委託は「事前承諾＋別紙特定」を基本にする・一次請けの監督責任（自己の行為と同一の責任）を条文化・委託先の特権アクセスは「期限付き・承認付き・個人アカウント・操作ログ必須」

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

F）説明事故：監査・取引先・親会社への説明が割れる（統制不備）────────────────────────────

事故後に最終的に効くのは「一貫した説明ができるか」です。ここが崩れると、技術復旧が済んでも信用回復が長引きます。

責任が割れるポイント・社外向け報告書の作成責任（誰がドラフトし、誰が最終承認するか）・ベンダーの報告が「調査中」で止まる場合の暫定説明・ログ提出が遅れたときの代替説明・原因が複合（ベンダー障害＋自社設定＋委託先操作）の場合の整理

勝ち筋・事故対応の「成果物」を先に決める（一次報告、詳細報告、再発防止、証跡提出）・社内の承認ライン（情シス→CSIRT→法務→経営）を手順化・契約で「調査協力」「報告内容」「期限」を可能な範囲で縛る

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

4. 比較表に追加すべき“事故時責任”のチェック項目（そのまま貼れる版）────────────────────────────

IDaaSの比較表に、最低限これだけは追加してください（YES/NO/要交渉で埋める）。

【通知・連絡】

□ 重大障害の一次通知期限（何分/何時間以内）

□ 通知チャネル（メールだけか、電話/専用窓口/ステータス連携はあるか）

□ 重大度（P1/P2等）の定義がある

【復旧・エスカレーション】

□ 復旧までのエスカレーション手順（優先度、対応時間）

□ 取引先説明に使える“報告書”の提供有無（内容と期限）

□ 補償がサービスクレジットのみか（調査協力まで含むか）

【調査協力・証跡】

□ 取得可能なログの範囲（管理操作、ポリシー変更、特権利用）

□ 保持期間（標準/延長）

□ 提出形式と提出期限（監査・取引先照会を含む）

□ 保全（リーガルホールド相当）協力の有無

【委託・再委託】

□ 委託先／再委託先（国外含む）の有無と特定（国・法人・業務範囲）

□ 再委託先にも同等義務が貫通するか

□ 一次請けが最終責任を負う条文があるか

【特権アクセス】

□ 管理者権限は期限付き・承認付きで運用できるか

□ ベンダー/委託先が入る場合の条件（目的限定、最小権限、操作ログ）

□ Break-glassの運用（発動条件、使用記録、復旧後手順）

【出口（契約終了時）】

□ 設定・ログ・レポートの返却/移管

□ データ削除・削除証明□ 移行支援（並行運用、期限、費用）

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

5. 社内で一発で通る「責任の所在」の言い方（上司向けテンプレ）────────────────────────────

事故後に上司が聞きたいのは、細かいプロトコルではなく「誰が責任を負うのか」です。説明テンプレを用意しておくと強いです。

（例）・今回の原因は「ベンダー障害／自社設定／委託先操作」のどれか（暫定でも分類）・復旧作業の実行は（R）：誰がやる・最終判断の責任は（A）：誰が負う（基本は自社）・取引先・監査への説明責任は（A）：誰が負う（基本は自社）・ベンダー・委託先の協力義務は契約上ここまで（提出・期限・範囲）・再発防止として、契約と運用のどこを直す（バックログ化）

これを“型”として社内共有すると、「情シスだけが抱える事故」になりにくくなります。

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

6. まとめ：責任の所在は「事故後」に決めない。決めておくべき3枚────────────────────────────

IDaaS比較表では分からない“事故時の責任の所在”を、導入前に決める最短ルートはこれです。

（1）事故別RACI（誰が実行し、誰が最終判断するか）

（2）ログ/データフロー図（どこにあり、誰が触れ、どれだけ残るか）

（3）インシデント成果物定義（一次報告、証跡提出、詳細報告、再発防止）

この3枚が揃うと、「事故が起きたときに揉めない」だけでなく、「監査・取引先に説明できる」IDaaS運用になります。

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