【クラウド法務】NSGグループの設計を委託した場合、責任はどこに残るのか―「ベンダーが設計した」では守れない。事故・監査・取引先説明で“主語が割れない”ための責任分界と契約整理―

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

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

はじめに

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

NSG（Network Security Group）の設計を外部ベンダーに委託すると、構成が整い、設計書も出て、レビュー会も開かれます。現場としては「これで統制できる」「プロが設計したから大丈夫」と感じやすいはずです。しかし、いざ事故や監査が来たときに一番困るのは、技術ではなく“責任の主語”です。

・「この許可ルール、誰が決めたの？」・「0.0.0.0/0 を開けた判断は誰？承認は？」・「委託先が設計したなら委託先の責任では？」・「取引先にどう説明する？根拠は？」

結論を先に言うと、NSG設計を委託しても、外部（取引先・顧客・監査）に対する説明責任の多くは“利用者＝自社”に残ります。委託先に責任がゼロという意味ではありませんが、「責任の性質」が違います。

本記事では、NSG設計を委託した場合に・どこに責任が残るのか・どこまで委託先に負わせられるのか・契約と規程で何を固めるべきかを、情シスの実務でそのまま使える形で整理します。

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

1. 技術構成の“事実整理”：NSG設計で実際に決まっているもの────────────────────────────

まず、NSG設計で決まるのは「ルールの束」だけではありません。運用に直結する“統制の前提”が決まります。

典型構成（テキスト図）

【インターネット】　

↓

（Public IP / LB / App Gateway など）

【VNet】

├─ Subnet-Web ─ NSG-Web（80/443 等）

├─ Subnet-App ─ NSG-App（Web→App のみ 等）

├─ Subnet-DB ─ NSG-DB（App→DB のみ 等）

└─ 管理系Subnet ─ NSG-Mgmt（管理端末・踏み台のみ 等）

NSG設計の“成果物”は、表面的には「ルール表」ですが、本当に重要なのは次の4点です。

（1）境界の定義（どこが“外”でどこが“内”か）・Web/App/DB の分離、管理系の分離・サブネット単位かNIC単位か・Private Endpointや踏み台、Bastion等とどう整合するか

（2）許可の根拠（なぜその通信を通すのか）・業務要件、アプリ仕様、運用仕様・「一時的例外」の扱い（期限、戻し方）

（3）変更の扱い（誰が、どうやって変えるのか）・変更管理（チケット、承認、ロールバック）・緊急変更（事後追認の期限と記録）

（4）証跡（誰がいつ何を変えたか、説明できるか）・変更記録、設定スナップショット・監視ログとの突合（何が起きたか）

（ここまでは技術の話。ここからが法務・責任の話です。）

NSGは“セキュリティ機能”ですが、事故が起きたときに問われるのは「通信が通る／通らない」ではなく、**“誰がどの根拠でその境界を設計し、誰が承認し、誰が維持管理していたか”**です。

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

2. まず結論：委託しても「責任」は消えない。消えるのは“作業”だけ────────────────────────────

NSG設計を委託したときに混ざりやすい「責任」を、3種類に分けます。ここを分けると整理が一気に進みます。

（1）原因責任（技術的に何が原因か）・設計の誤り／実装の誤り／運用変更の誤り／例外の放置 など

（2）契約責任（委託先が何を義務として負うか）・成果物の品質、設計要件の充足、レビュー対応、納品物の内容・運用委託なら通知・提出・保全協力など

（3）説明責任（取引先・顧客・監査へ誰が説明するか）・影響範囲、原因、再発防止、統制状況の説明

このうち、（3）説明責任は原則として自社に残ります。委託先が設計者でも、取引先と契約しているのは自社であり、業務の主体は自社だからです。委託先は「協力者」にはなれますが、対外説明の主語は委託先になりにくい、というのが実務です。

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

3. NSG設計を委託したとき「自社に残る責任」────────────────────────────

委託しても自社に残る責任は、ざっくり言うと「決める責任」「監督する責任」「説明する責任」です。もう少し具体化します。

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

（A）セキュリティ要件を決める責任（＝設計の前提条件の責任）────────────────────────────

・どの資産を守るのか（重要度・データ分類）・公開してよい範囲（外部公開／社内限定／取引先限定）・例外を許容する条件（緊急時、期限、補償統制）・管理経路（RDP/SSH等）をどう扱うか（原則禁止、踏み台必須等）

ここが曖昧だと、委託先は“とりあえず動く”方向に寄ります。そして事故後に「なぜこの前提で許可したのか」を説明できなくなります。

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

（B）承認とリスク受容の責任（＝“開ける”最終判断）────────────────────────────

NSGは、ルール1本で公開範囲が変わります。「誰の承認で開けたか」は、事故の時に必ず問われます。

・0.0.0.0/0 の許可、Any/Any、管理ポート開放・例外の延長、恒久化・セグメント分離を崩す変更

これらを許容する“最終判断”は、委託先ではなく自社側の責任として残すのが基本です。（委託先に最終判断まで渡すなら、逆に契約・規程を相当強くする必要があります）

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

（C）委託先を監督する責任（＝「任せた」のではなく「管理した」）────────────────────────────委託した瞬間に統制が弱くなる典型は、ここです。

・委託先の権限が強すぎる（常設管理者、共有IDなど）・変更がチケットに紐付かない（後から追えない）・緊急変更が恒久化する（戻し忘れ）・再委託（下請け）が混ざり、誰が触ったか不明

外部から見ると「委託先のミス」ではなく、「委託管理（監督）が弱い会社」と評価されやすい点が重要です。

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

（D）ログ・証跡を“提出できる状態”にする責任────────────────────────────監査・取引先照会で問われるのは「ログがあるか」より、次です。

・何を、どこに、どれだけ保持しているか・誰が、何営業日以内に提出できるか・事故時に保全（削除停止・隔離・抽出者記録）ができるか

委託先がログ基盤を見ている場合でも、提出期限を守れないと困るのは自社です。なので“提出できる状態”を作る責任は自社側に残ります。

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

（E）対外説明（取引先・顧客・監査）を統一する責任────────────────────────────事故後の二次炎上は、技術より「説明の不一致」で起きます。

・技術担当は「NSGの例外ですぐ戻しました」・委託先は「仕様上こうなります」・法務は「漏えいは確認できない」・営業は「問題ありません」と言ってしまう

これを止めるのは、事前の責任分界と手順です。対外説明の主語が自社である以上、説明を統一する責任は自社に残ります。

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

4. では委託先に「何の責任」を持たせられるのか（契約で決まる）────────────────────────────

委託先に持たせられる責任は、基本的に「契約で定義した義務」の範囲です。NSG設計を委託する場合、最低限次を契約・別紙（SOW）・成果物定義で固めると、事故後に揉めにくくなります。

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

（1）成果物責任：設計の内容と根拠を“納品物”にする────────────────────────────例：納品物に入れておきたい最低ライン・セグメント設計（Web/App/DB/管理系）・NSGルール表（許可理由、送信元/宛先、ポート、優先度、適用箇所）・例外運用ルール（例外が出る前提なら、期限・承認・補償統制）・設計前提（想定する公開範囲、管理経路、監視前提）・テスト観点（疎通確認だけでなく、禁止通信の確認）

“動いた”だけでは不十分で、なぜその許可が必要かが残る設計書が重要です。

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

（2）実装責任：設計どおりに作る／差分は承認を取る────────────────────────────設計委託＋構築実装まで任せるなら、次を明文化します。・IaC（Terraform等）での実装可否・設計差分が出たときの承認ルール（委託先判断で変えない）・ロールバックの考え方（戻し方と責任）

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

（3）変更管理責任：変更はチケットに紐づき、証跡が残る────────────────────────────運用委託まで含むなら、ここが必須です。・変更は必ずチケット番号に紐付け・承認者、実施者、実施日時、変更内容、影響、ロールバックを記録・緊急変更の事後追認期限（例：翌営業日まで）・月次棚卸し（例外の残存、広い許可の残存）

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

（4）提出・保全協力責任：事故時にログが出せる／保全できる────────────────────────────事故のときに一番揉めるのはここです。契約で最低限、次を“義務”として落とします。

・一次通知（検知から何分以内、どのチャネル）・ログ提出（提出期限・形式・対象範囲）・保全協力（削除停止、隔離、抽出者記録への協力）・原因分析協力（再発防止に必要な技術情報提供）

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

（5）特権アクセス責任：強権限の統制（個人特定・期限・剥奪）────────────────────────────委託先がNSG変更に触れるなら、ここが“統制の芯”です。・個人アカウント原則（共有アカウント禁止）・期限付き権限／承認付き（常設を避ける）・操作ログ（誰がいつ何をしたか）提出・担当交代／契約終了時のアクセス剥奪証明・再委託がある場合の条件と同等義務の貫通

────────────────────────────5. “責任分界”を崩さないための整理フレーム（最小3枚）────────────────────────────

NSG設計を委託したとき、社内説明と事故対応が崩れない企業は、だいたい次の3枚を持っています。

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

（1）タスク別RACI（自社／委託先／Microsoft）────────────────────────────例：NSGに関する最低タスク（例）

・要件定義（公開範囲、管理経路、例外条件）・設計（セグメント、ルール）・実装（作成・適用）・変更（追加・削除・例外）・棚卸し（広すぎる許可、期限切れ例外）・ログ提出（監査・取引先照会）・事故対応（一次通知、封じ込め、保全、報告書）

ポイントはここです。委託先が「実行（R）」でも、自社が「最終責任（A）」になるタスクを明確にする。この1枚があると、事故の初動が早くなります。

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

（2）例外台帳（暫定開放を恒久化させない）────────────────────────────最低限入れる項目・例外ルール（どのNSG／どの許可）・理由・承認者・期限・補償統制（監視強化、送信元限定等）・解除計画と解除証跡

NSG事故の多くは、例外の放置が原因です。台帳で止められます。

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

（3）証跡パック（監査・取引先に“これを出す”）────────────────────────────最低ライン例・NSGルール現状一覧・変更記録（チケット・承認・実施者・日時・内容）・例外台帳・ログの保持・提出ルール（期限・担当・形式）・事故時保全手順（抽出者記録）

“ログは取れる”より、“期限までに出せる”が重要です。

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

6. ケーススタディ（匿名化）：設計委託したのに自社が説明で詰まった例────────────────────────────

背景・Azure上で業務システムをIaaS中心に構築・NSG設計をベンダーに委託し、設計書も納品・運用も一部委託（監視＋変更代行）

起きたこと（典型）・切替対応で一時的な例外（広い許可）が入り、その後戻し忘れ・外部からのスキャンが検知され、取引先から照会・社内で「委託先が設計したのだから委託先の責任では？」という空気が出る・しかし、承認・期限・解除の証跡が揃っておらず、対外説明が遅れる・委託先側も「その運用は契約外」「ログ提出は別」となり、材料が集まらない

改善で効いたこと・RACIで「最終承認は自社」「例外は台帳必須」を固定・委託契約別紙に、変更管理・提出義務・保全協力・特権アクセス統制を明記・例外台帳と月次棚卸しで“戻し忘れ”を制度的に潰す・証跡パックを定義し、提出期限に耐える運用へ

結果「委託しているのに説明できない」状態から、「委託していても主語が割れない」状態に近づいた、という流れです。

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

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

□ NSG設計の前提（公開範囲／管理経路／例外条件）が社内で決まっている

□ “最終承認者”が明確（委託先が設計しても、開ける判断は誰か）

□ 委託範囲が明文化されている（設計のみ／実装まで／運用変更まで）

□ 変更管理が回っている（チケット、承認、緊急変更の事後追認期限）

□ 例外運用が台帳化され、期限・解除計画・補償統制がある

□ 委託先の特権アクセスが統制されている（個人アカウント、期限、剥奪証明）

□ “誰がいつ何を変えたか”の証跡を提出できる

□ ログ提出の期限・形式・担当が決まっている（委託先が絡むなら契約義務）

□ 事故時の保全（削除停止・隔離・抽出者記録）ができる

□ 再委託がある場合、範囲特定と同等義務の貫通が説明できる

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

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

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

山崎行政書士事務所では、Azure（IaaS中心、運用委託、監査対応）を前提に、NSGを含むネットワーク統制を「技術構成＋契約＋規程＋証跡」でセット整理するクラウド法務支援を行っています。

・NSG設計を委託したが、責任分界（自社／委託先／Microsoft）を1枚にしたい・委託契約別紙（SOW）に、変更管理・ログ提出・保全協力・特権アクセス統制を入れたい・NSGの例外運用を台帳化し、恒久化を止めたい・監査・取引先照会に耐える“証跡パック”を作りたい

といった課題があれば、オンライン（全国対応）でご相談を承っています。お問い合わせ時に「NSG委託責任の記事を見た」と書いていただけるとスムーズです。

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

※本記事は一般的な情報提供です。実際の責任分界は、委託範囲（設計のみ／運用まで）、権限設計、監視・ログ基盤、取引先要件により変わります。────────────────────────────