【Azureクラウド法務】NSGの暫定開放が“恒久化”してしまう組織の特徴― 「一時的に開けただけ」が、監査・事故・取引先説明で“言い訳できない穴”になる ―

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

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

はじめに

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

Azure運用でよくあるのが、NSG（Network Security Group）の「暫定開放」です。

「切り分けのために一旦ポートを開けたい」

「ベンダーの作業が今夜だけ入るので許可したい」

「移行の締切が迫っていて、まず通す必要がある」

この判断自体は、現場では避けられないこともあります。

しかし怖いのは、“暫定”だったはずのNSGルールが、そのまま残り続けて恒久化することです。

数ヶ月後、監査・親会社統制・取引先のセキュリティチェックで

「この開放は誰が承認しましたか？期限は？補償統制は？」

と聞かれた瞬間に、説明が止まります。

本記事では、NSGの暫定開放が恒久化してしまう組織に共通する特徴と、恒久化を止めるための“仕組みの作り方”を、技術→法務→運用の順で整理します。

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

技術構成の“事実整理”：NSGの暫定開放は、こうやって生まれる

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

まず技術的に、現場で「暫定開放」が発生しやすい典型パターンを整理します。

よくある構成（テキスト図）

【インターネット／拠点】

　↓

【Azure VNet】

・サブネット（Web／App／DB／管理用）

・NSG（サブネット or NICに適用）

・必要に応じてLB／App Gateway／Firewall／Bastion 等

　↓

【VM／PaaS／管理系】

・運用端末からRDP/SSH

・ベンダー作業用の踏み台

・監視・バックアップ・構成管理

暫定開放が生まれる典型

・「疎通しない」→ 22/3389/443などを広めに許可して切り分け

・「ベンダーが作業する」→ 特定IPが分からず“とりあえず”許可

・「本番直前」→ WAF/Firewall/NSGの設計が未完成で、暫定で穴を開ける

・「運用保守」→ 運用端末のIPが変動、VPN設計が間に合わず暫定対応

・「例外の例外」→ 例外が積み上がって“何が正しい状態か”分からなくなる

ここまでは技術の話。

ここからが法務・説明責任の話です。

NSGの暫定開放は「技術トラブルの解決策」になり得ますが、恒久化すると「統制不備」になります。

つまり、問題の本質は“開けたこと”ではなく、“開けっぱなしになったプロセス”です。

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

2. NSGの暫定開放が“恒久化”してしまう組織の特徴（7つ）

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

恒久化してしまう組織には、かなり共通した特徴があります。技術力の問題というより、意思決定と運用の仕組みの問題です。

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

特徴①：暫定措置に「期限」が存在しない（or 期限が管理されない）

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

暫定開放の最大の敵は、期限のない例外です。

期限がないと、例外は必ず“通常運用”に吸収されます。

よくある状態

・「今週だけ」のつもりが、誰も閉じるタイミングを持っていない

・閉じるときの影響が怖くて、先送りが続く

・担当者が異動し、背景が消える

恒久化の本質

期限がない例外は、「意思決定の放置」です。

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

特徴②：「誰が決めたのか」が消える（承認者・根拠・リスク受容が残らない）

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

監査や取引先が聞くのは、NSGのルールそのものより

「誰がそのリスクを受けたのか」です。

よくある状態

・チャットで「開けていい？」→「OK」だけ

・チケットはあるが、承認者・根拠・代替案が書かれていない

・“必要だった”は言えるが、“会社として受容した”証拠がない

恒久化の本質

例外が「現場判断の作業」になっており、「会社の意思決定」になっていない。

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

特徴③：例外を“台帳”で管理していない（例外が検索できない）

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

例外の台帳がない組織では、例外が増えるほど見えなくなります。

よくある状態

・NSGルールが増え、命名規則もバラバラ

・「このルール何？」と聞かれて、当時の担当しか分からない

・削除が怖いので放置が最適解になる

恒久化の本質

管理できないものは、減らせません。台帳がない＝減らす仕組みがない。

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

特徴④：暫定開放の“代替手段”が整っていない（閉じると作業が止まる）

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

暫定開放が残る理由は、だいたいシンプルです。

「閉じたら業務が回らないから」。

よくある状態

・踏み台／Bastion／VPN／Private接続などの正規ルートが間に合っていない

・運用端末の固定化ができず、送信元が絞れない

・ベンダーアクセスの設計が曖昧（誰がいつどこから入るか決まっていない）

恒久化の本質

技術的には閉じたいが、閉じると止まる。止められない例外は残ります。

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

特徴⑤：委託（SIer/MSP）が絡むほど“監督”が抜ける（責任分界がレイヤー止まり）

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

よくある誤解が

「運用は委託している＝委託先が閉じる」

「NWはベンダー領域＝ベンダー責任」

という思い込みです。

現実は

・委託先は実行（作業）はできても、最終判断（承認）はしない／できない

・委託契約（特にSOW）に「例外の期限管理」「棚卸し」「是正」が義務として入っていない

・結果、誰も“閉じる責任”を持たない

恒久化の本質

作業者がいても、責任者がいない。これが一番残ります。

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

特徴⑥：監査・取引先質問に備えた「説明の型」がない

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

取引先や監査が聞くのは、だいたい決まっています。

・なぜ例外が必要だったのか

・承認者は誰か

・期限と解除計画はあるか

・例外中の補償統制（監視強化、送信元限定等）は何か

・棚卸し頻度は？誰が責任者か？

ここに答えるテンプレがないと、例外は“説明不能な穴”になります。

恒久化の本質

説明の型がない組織は、例外を“語れない”ので“閉じられない”。

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

特徴⑦：優先順位が「機能追加＞統制改善」になっている（詰まりが放置される）

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

恒久化する組織は、例外を“負債”として認識しながらも、後回しにします。

なぜなら、例外を閉じても新機能が増えるわけではないからです。

でも、例外は事故・監査・取引先審査で一気にコスト化します。

「見つかったときが締切」になっている組織ほど、恒久化が進みます。

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

3. 恒久化を止める「整理のフレーム」：例外運用を“制度化”する

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

ここからが解決策です。

NSGの暫定開放はゼロにはできません。だからこそ、恒久化させない制度が必要です。

ポイントは「禁止」ではなく「例外の扱いを固定する」ことです。

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

整理軸①：例外台帳（レジスター）を作る

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

最低限、次の項目があれば“説明できる例外”になります。

例外台帳に入れる項目（例）

・例外ID（チケット番号等）

・対象（サブスク／VNet／サブネット／NSG名／ルール名）

・内容（許可ポート、方向、送信元/宛先）

・理由（業務要件／切り分け／ベンダー作業等）

・承認者（役割名でOK）

・期限（必須）

・解除条件（何が終われば閉じるか）

・補償統制（監視強化、送信元限定、時間制限、JIT等）

・棚卸し日／棚卸し結果（継続・是正・終了）

ポイント

「例外は台帳に載っていないと存在できない」状態にします。

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

整理軸②：期限は“自動で閉じる”方向に寄せる（人の善意に依存しない）

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

恒久化の最大要因は「閉じる人がいない」ことです。

対策は、期限を“仕組み”に寄せることです。

運用でよく効く考え方

・例外は最大〇日（例：7日/14日/30日）まで

・延長は再承認（理由更新＋補償統制の再確認）

・期限到来前に通知（担当・承認者にアラート）

・可能なら「時間帯限定」「送信元限定」「作業ウィンドウ限定」にする

ここは技術だけでなく、規程（運用ルール）として固定すると強いです。

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

整理軸③：責任分界は“レイヤー”ではなく「例外タスク」でRACIを作る

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

NSG例外で事故が起きると必ず聞かれるのは、レイヤーではなくタスクです。

例外タスクのRACI（最低限）

・例外の起案（R）

・リスク評価（C）

・承認（A）

・実装（R）

・期限管理（R/Aを必ず置く）

・棚卸し（R）

・解除（R）

・例外中の監視強化（R）

・対外説明の承認（A）

委託（MSP/SIer）があるなら、

「MSPが実装する（R）」でも「最終責任（A）は自社」になりがちです。

ここを最初から紙で固定しておくと、事故時に主語が割れません。

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

整理軸④：委託契約（SOW）に「例外管理」を義務として落とす

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

委託先が関与するなら、SOW（作業範囲・品質の定義）に以下を入れると安定します。

・例外ルールの追加は、チケットと承認が前提

・例外ルールには必ず期限を設定

・期限管理（通知・棚卸し）を委託範囲に含める

・例外の解除（閉鎖）までを作業範囲に含める

・例外台帳の更新責任（誰が更新するか）

・月次で例外一覧を提出（棚卸し材料）

「運用は委託しているのに例外が減らない」会社は、ここが契約上空白なことが多いです。

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

4. ケーススタディ（匿名化）：暫定開放が積み上がって監査で止まったA社

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

（実務でよくある構図を匿名化しています）

背景

・Azureで複数サブネット運用（Web/App/管理）

・移行期にベンダー作業が続き、NSGに例外ルールが増加

・運用はMSP、監視はSOC

発生した問題

・取引先のセキュリティ審査で「インターネットからの許可ルール一覧と根拠」を要求

・「暫定」のはずのルールが複数残っており、承認者と期限が不明

・“誰が決めたか”が説明できず、回答が遅延

立て直しでやったこと

・例外台帳を作成し、既存例外を棚卸し（所有者・理由・期限を付与）

・例外は期限必須＋延長は再承認の運用へ

・例外中の補償統制（監視強化、送信元限定、時間制限）をセット化

・委託契約SOWに「例外台帳更新・月次棚卸し・解除」を明記

・最終的に“閉じられない例外”は、正規ルート（踏み台／VPN等）の整備計画に乗せて解消

結果

・「開けている」こと自体ではなく、「例外を統制している」ことを説明できるようになり、審査回答が安定した

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

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

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

□ NSGの例外ルールに、期限が入っている（入れない例外は原則ない）

□ 例外の承認者（役割）が分かる形で残っている

□ 例外台帳があり、例外を検索できる（NSG名／ルール名で追える）

□ 例外の解除条件（終わり方）が書かれている

□ 例外中の補償統制（監視強化、送信元限定、時間制限等）が定義されている

□ 月次/四半期で例外棚卸しを回している（記録が残る）

□ 委託先が実装しても、期限管理・解除の責任者が決まっている

□ 委託契約（SOW）に、例外管理（台帳更新・棚卸し・解除）が義務として入っている

□ 「そのルールは誰が決めたのか」に即答できる

□ 監査・取引先に説明する“例外説明テンプレ”がある

YESが揃わない場合、暫定開放は高確率で恒久化します。

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

6. まとめ：暫定開放が恒久化するのは“現場の怠慢”ではなく“制度の欠落”

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

NSGの暫定開放が恒久化してしまう組織の特徴は、技術の未熟さというより

・期限がない

・承認と根拠が残らない

・台帳がない

・閉じる代替ルートがない

・委託の監督が契約に落ちていない

という、運用制度の欠落です。

例外はゼロにできません。

でも、例外を“説明できる形”にして、期限で潰すことはできます。

それができる組織は、監査にも事故にも強くなります。

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

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

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

山崎行政書士事務所では、Azure運用におけるNSG設計・例外運用について、技術構成と契約・規程・監査対応をセットで整理し、暫定開放が恒久化しない「例外台帳＋期限管理＋責任分界（RACI）＋委託契約（SOW）」の整備支援を行っています。

・NSG例外が増え、監査や取引先に説明できない

・例外台帳と規程を作り、期限管理で恒久化を止めたい

・MSP/SIer委託を含め、例外管理をSOWに落としたい

・「誰が決めたのか」に詰まらない責任分界を1枚にしたい

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

お問い合わせの際に「NSG暫定開放の記事を見た」と書いていただけるとスムーズです。