【クラウド法務】Azure導入で「セキュリティ事故」が起きたとき、説明責任はどこにあるか― “Microsoftのクラウドだから”では済まない。事故後に詰まらない責任分界の整理 ―

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

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

はじめに

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

Azureを導入すると、セキュリティ機能も運用支援も選択肢が増え、「ちゃんとやっているつもり」になりやすい一方で、事故が起きた瞬間に一番困るのが“説明”です。社内では「Microsoft側の問題？自社の設定ミス？委託先の作業？」と責任が割れ、社外からは「漏えいは？影響範囲は？再発防止は？」と即答を求められる。このとき詰まるのは、技術的に原因が分からないからではなく、“説明責任の所在”が事前に決まっていないからです。

本記事では、Azure導入環境でセキュリティ事故が起きたとき、Microsoft／利用者（自社）／委託先のどこに“説明責任”があるのかを、実務で使える形に整理します。

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

1. まず整理：事故の「責任」は3種類ある（ここが混ざると必ず揉める）────────────────────────────

「責任」という言葉は、事故時に混ざります。混ざると説明が壊れます。最低限、次の3つに分けてください。

（1）原因責任（技術的に何が原因か）・設定ミス／権限ミス／資格情報漏えい／委託先操作／クラウド基盤障害 など

（2）契約責任（誰が何を“義務として”負うか）・通知義務、調査協力、ログ提出、補償（賠償・免責）、SLA、再委託の条件 など

（3）説明責任（対外的に誰が説明するか）・取引先、顧客、親会社、監査、当局（該当する場合）に　「影響範囲」「対応状況」「再発防止」を説明する責任

結論から言うと、Azure導入後のセキュリティ事故において説明責任の“主語”は、原則としてサービス提供主体＝利用者（自社）です。

Microsoftや委託先が原因に関与していても、自社が事業主体・対外窓口である限り、社外への説明を放棄できません。

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

2. なぜ説明責任は「自社」に残るのか（現場で一番重要な原則）────────────────────────────

説明責任が自社に残る理由は、実務上ほぼこの4点です。

理由①：顧客・取引先との関係は「自社」が持っている取引先が困るのは「Azureが落ちた」ではなく、「あなたの会社のサービスが止まった／情報が漏れた」だからです。

理由②：設計と運用の最終判断は「自社」がしている委託していても、採用した構成・委託範囲・ログ保持期間・権限設計を決めたのは自社です。委託先は“自社の作業の代行者”であって、対外責任の引受人ではありません。

理由③：説明に必要な材料（ログ・台帳・証跡）を揃える責任も自社事故時に求められるのは「原因」よりも先に、「いつから」「何が」「どれだけ」「誰に影響」「いま何をした」が出せるかです。この材料を“出せる状態にしておく”責任は、基本的に自社側に残ります。

理由④：Microsoftの説明（障害情報など）があっても、それを“自社の言葉”に翻訳する必要がある仮にMicrosoft側の基盤問題が原因だったとしても、取引先に必要なのは「あなたのサービスはどうなるのか」「データは安全か」です。Microsoftの公表情報を引用するだけでは、取引先の質問に答えられません。

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

3. ただし例外もある：説明責任が「分担」されるケース────────────────────────────

説明責任の“主語”は自社が基本ですが、事故の種類によっては説明責任が「分担」されます（ただし自社の説明責任が消えるわけではありません）。

（A）Microsoft基盤側の大規模障害・セキュリティ事象が主因・Microsoftから障害情報や説明が出る・しかし自社は「自社サービスへの影響」と「自社側の対策」を説明する必要がある

（B）委託先の作業ミス・不正が主因・委託先にも事実関係の説明や協力義務が必要（契約で担保）・しかし自社は取引先に対して「委託先がやりました」で終われない　（委託管理の責任が問われる）

（C）サードパーティ製品（Marketplace含む）の不具合・侵害が主因・サードパーティの説明が必要になる・しかし自社は「採用判断」「データ流通」「監督の合理性」を説明する必要がある

この“分担”を成立させるには、事故後ではなく導入前に「誰が何を説明する義務があるか」を契約で固める必要があります。

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

4. 事故タイプ別：「説明責任の所在」が割れやすいポイント────────────────────────────

ここからが実務です。事故はだいたい次の5種類に分類できます。

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

タイプ1：設定ミス（公開設定・権限・ネットワーク）で情報が外に出た────────────────────────────

例：ストレージ公開、アクセス権過剰、Key Vault権限ミス、Firewall穴、WAF未設定など

説明責任（対外）は誰か・原則：自社（利用者）・委託で設定していた場合：自社が説明主体＋委託先が協力（証跡・作業報告）

なぜ揉めるか・「Azureのせい」ではなく「構成・設定のせい」と捉えられやすい・誰が設定したか（委託先か自社か）と承認・レビューの有無が問われる

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

タイプ2：ID侵害（アカウント乗っ取り・特権悪用）────────────────────────────

例：MFA突破、条件付きアクセス例外、PIM運用不備、委託先アカウントの残留など

説明責任（対外）は誰か・原則：自社（利用者）・委託先アカウントが絡む場合：委託先の説明協力（いつ誰が何をしたか）を要求できる契約が必須

なぜ揉めるか・技術より「運用統制（例外・特権・棚卸し）」が問われる・「なぜその例外が残っていたのか」を説明できないと二次炎上する

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

タイプ3：委託先・再委託先（国外SOC含む）の運用事故────────────────────────────

例：誤操作、対応遅延、ログ提出不能、再委託先の関与が後から発覚

説明責任（対外）は誰か・原則：自社（利用者）・委託先の責任は「自社に対する契約責任」で追及できるが、対外説明の主語は自社から逃げにくい

なぜ揉めるか・再委託の範囲・国・法人・業務が説明できない・ログの所有や提出期限が契約で決まっていない

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

タイプ4：Microsoft側のサービス障害・脆弱性影響（基盤要因）────────────────────────────

例：広域障害、サービス側の不具合、プラットフォーム起因の影響

説明責任（対外）は誰か・Microsoft：基盤事象の説明は行われる（ことがある）・自社：自社サービスへの影響、復旧見込み、代替策、顧客影響を説明する

なぜ揉めるか・「いつ復旧するか」だけでなく「データは安全か」「取引先にどう説明するか」が残る

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

タイプ5：ログが出せない（保持不足・所在不明・保全不能）────────────────────────────

例：保持期間が短い、SIEM委託先にあり出ない、削除停止できない

説明責任（対外）は誰か・原則：自社（利用者）・委託先が関与：委託先に提出協力義務がなければ詰む

なぜ揉めるか・「安全に運用していた根拠」が出せず、説明が崩れる・原因が確定する前に“説明不能”で信用が落ちる

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

5. 説明責任で詰まらないための「最小3点セット」────────────────────────────

Azure導入で事故が起きても説明できる会社は、例外なく次を持っています。逆にこれがないと、ほぼ確実に“説明できない”状態になります。

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

（1）事故別RACI（誰が実行し、誰が最終判断し、誰が説明するか）────────────────────────────最低限、事故タイプ別に次を決めます。

・R（実行）：実際に手を動かす担当（自社／委託先）・A（最終責任）：最終判断（停止・切戻し・公表）をする担当（原則自社）・C（相談）：CSIRT、法務、経営、広報、事業部・I（共有）：顧客窓口、営業、親会社、監査対応窓口

ポイント：委託先がRでも、A（最終責任）と対外説明の主体は自社に残るケースが大半です。

────────────────────────────（2）証跡パック（事故・監査で“これを出す”）────────────────────────────「ログは見られる」ではなく「提出できる」が重要です。最低ラインの証跡パック例：

・管理者（特権）一覧：常設／期限付き、付与理由、承認者・重要操作ログ：権限変更、ポリシー変更、ネットワーク変更、キー操作・重要リソースの構成証跡：公開設定、暗号化、バックアップ、DR・例外運用台帳（条件付きアクセス等）：理由、承認、期限、解除計画・保全手順：削除停止、隔離、抽出者記録（いつ誰が取ったか）

これがあるだけで、事故初動の説明速度が大きく変わります。

────────────────────────────（3）委託契約に入れる「事故対応の義務」────────────────────────────委託しているなら、次を条項または別紙で固定しないと説明不能になります。

・一次通知：検知から何分以内、どのチャネルで・調査協力：ログ提出、原因分析、再発防止情報・ログ提出義務：提出期限、形式、保持、保全協力・特権アクセス統制：個人アカウント、期限付き、承認、操作ログ・再委託（国外含む）：条件、範囲特定、監督責任・契約終了：アクセス剥奪、データ削除、削除証明、ログ引渡し

委託先に「善処します」しかないと、事故後に説明の材料が集まりません。

────────────────────────────6. ケーススタディ（匿名化）：なぜ“説明できない事故”になるのか────────────────────────────

ある企業でAzure導入が進み、監視は委託、ログもSIEMに集約していました。技術的には「運用できている」状態でしたが、ある不正アクセス疑いが出た際に詰まりました。

・委託先の作業範囲が“監視まで”で、ログ提出や保全が契約外・条件付きアクセスの例外が標準ポリシーの除外で増えており、台帳がなく説明できない・特権アクセスの棚卸しが弱く、誰がいつ権限を持っていたか即答できない・社外向け報告書の責任者（法務/広報/情シス/経営）が決まっていない

結果、原因の確定より先に「説明が遅い」「根拠が出ない」で信用が落ち、事後対応として規程・台帳・契約別紙の整備が追加で発生しました。これが“法務・責任分界が後回し”の典型的な二重コストです。

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

7. 今すぐ確認できるチェックリスト────────────────────────────

□ 事故タイプ別に、RACI（実行/最終責任/相談/共有）が決まっている

□ 対外説明の責任者（誰が承認して出すか）が決まっている

□ 証跡パック（監査・取引先照会で出すもの）が定義されている

□ ログの保持期間・提出期限・形式が決まっている（委託なら契約化）

□ 例外運用（条件付きアクセス等）は台帳で管理し、期限と解除計画がある

□ 特権アクセス（委託先含む）は期限付き・承認付き・操作ログ付きで統制できる

□ 重大障害/侵害時の一次通知、保全、報告書作成の手順がある

□ 再委託（国外含む）がある場合、範囲特定と監督責任が説明できる

□ 契約終了時の出口（削除・削除証明・ログ引渡し）が決まっている

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

8. まとめ：説明責任は“事故後”に決めない────────────────────────────

Azure導入でセキュリティ事故が起きたとき、原因がMicrosoft側にあっても、委託先にあっても、対外説明の主語は原則として自社です。

だからこそ、導入前・運用設計の段階で・事故別RACI・証跡パック・委託契約の事故対応義務を揃えておくことが、結果的に一番安いセキュリティ投資になります。

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

お問い合わせ

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

山崎行政書士事務所では、Azure（IaaS/PaaS混在、ID、ログ、運用委託、サードパーティ導入）を前提に、事故が起きたときに「誰が何を説明できるか」を契約・規程・監査対応まで含めて整理する支援を行っています。

・Microsoft／委託先／自社の責任分界を“事故対応まで”1枚にしたい・ログ保持・提出・保全（証跡パック）を監査に耐える形にしたい・委託契約に、ログ提出・特権アクセス・再委託の条項を入れたい・条件付きアクセスの例外運用を台帳と規程で回したい

といった課題があれば、オンライン（全国対応）でご相談を承っています。