Firewallを通した“つもり”が、Service Endpointで横抜けしていた話

― Azure閉域設計における経路統制・監査証跡・説明責任の研究 ―

※本稿は一般的な情報提供であり、個別案件に対する法的助言・紛争代理を目的とするものではありません。行政書士業務の範囲で、クラウド構成、契約、規程、責任分界、説明資料、証跡整理の観点から論じます。

要旨

Azure環境において「全通信はFirewall経由」と設計書に記載されていても、実際のPaaS通信がAzure Firewallを通過していないことがある。その典型例が、Service Endpointを有効化したサブネットからAzure Storage、Key Vault、SQL Database等のPaaSへ到達する構成である。Service Endpointは、Azureサービスへの安全で直接的な接続を提供する機能であり、それ自体が悪いわけではない。問題は、「Firewallで検査・記録する」という統制目的と、「Service Endpointで直接到達させる」という技術仕様が、設計書・監査証跡・責任分界上で整合していないことである。

Microsoftの公式情報では、Service EndpointはAzureバックボーン経由の最適化された直接接続を提供し、Microsoftは安全なプライベートアクセスにはPrivate LinkおよびPrivate Endpointの利用を推奨している。また、Service Endpointを有効化すると、対象サブネットに VirtualNetworkServiceEndpoint のシステムルートが追加され、このルートはルートテーブルでは上書きできないと説明されている。したがって、「0.0.0.0/0をFirewallへ向けたから全通信がFirewallを通る」という理解は、Azure PaaS通信においては不十分である。

本稿は、匿名化した実務事例をもとに、Service Endpoint、Private Endpoint、DNS、NSG、ルートテーブル、Azure Firewallログの相互作用を整理し、クラウド法務の観点から「通る」だけでなく「どこを通したかを説明できる」設計の必要性を論じる。

キーワード： Azure、Service Endpoint、Private Endpoint、Azure Firewall、NSG、DNS、監査証跡、クラウド法務、説明責任、NIST CSF 2.0

1. 序論：閉域構成の事故は、通信断だけではない

クラウドのネットワーク事故というと、多くの人は「つながらない」「止まった」「外部公開された」といった事象を思い浮かべる。しかし、Azureの現場で本当に怖いのは、通信そのものは成功しているにもかかわらず、後から「その通信は、どの経路を通りましたか」と聞かれたときに説明できない状態である。

ある現場では、閉域構成は完成したと判断されていた。設計書にも、運用引継ぎ資料にも、「全通信はFirewall経由」と書かれていた。Azure Firewallにはアプリケーションルール、ネットワークルール、診断設定が整備され、Log Analyticsにもログが流れていた。経営層向けの説明資料にも、「外部通信はFirewallで制御・監査」と記載されていた。

ところが、実際にログを追うと、一部のPaaS通信がFirewallに出てこない。アプリケーションは正常に動いている。ストレージにも到達している。Key Vaultからシークレットも取得できている。しかし、Azure Firewallの該当ルールにはヒットがない。KQLで時間帯を絞っても、送信元IP、宛先FQDN、ポート、ルール名のどれにも該当ログがない。

このとき現場で起きる会話は、かなり生々しい。

ネットワーク担当者は「0.0.0.0/0はFirewallに向けています」と言う。アプリ担当者は「アプリは問題なく動いています」と言う。セキュリティ担当者は「Firewallログに出ていないなら、監査上どう説明するのか」と言う。ベンダーは「Service Endpointを有効化しているので仕様どおりです」と言う。経営層は「つまり、閉域なのか、閉域ではないのか」と聞く。

ここで問題になるのは、単なる設定ミスではない。設計思想、証跡、説明責任、契約上の責任分界がずれていることである。

2. 事例：Firewallを通した“つもり”の設計

本稿の事例は、複数の現場経験を抽象化したものである。

対象システムは、Azure上の業務アプリケーションであった。構成は、Hub-Spoke型に近い。Spoke VNetにアプリケーションサーバーがあり、Hub側にAzure Firewallが配置されていた。Spoke側のサブネットにはルートテーブルが関連付けられ、0.0.0.0/0 の次ホップはFirewallのプライベートIPに向けられていた。NSGでは不要なOutboundを制限し、Firewall側でPaaS宛通信を許可する設計とされていた。

一方で、アプリケーションの安定稼働を優先した過程で、Azure StorageおよびKey Vaultに対するService Endpointが対象サブネットで有効化されていた。さらに、PaaS側のネットワーク制限では、当該VNetまたはサブネットからのアクセスを許可していた。

表面上は、すべてが正しく見えた。

通信は成功していた。PaaS側のネットワーク制限も有効だった。インターネットに直接出ているようにも見えなかった。設計書上はFirewall経由と記載されていた。

しかし、監査ログの観点では破綻していた。Firewallを通過していない通信は、Firewallログには残らない。Azure Firewallは、通過した通信については構造化ログや各種ログカテゴリで把握できるが、そもそもFirewallを経由していない通信を、Firewallログで証明することはできない。Azure Firewallの構造化ログは診断設定を通じてLog Analytics等に格納する設計であり、アプリケーションルール、DNS、Flow Trace等のログカテゴリも存在するが、それはFirewallを経由した通信を前提とした監査証跡である。

この事例の失敗は、「到達できるか」を確認しただけで、「どこを通って到達したか」を確認していなかった点にある。

3. 技術的分析：Service Endpointは何をしているのか

Service Endpointは、Azureサービスへの通信をAzureバックボーン上の最適化されたルートで直接到達させる仕組みである。Microsoft Learnでは、Azure仮想ネットワークService Endpointについて、Azureサービスへの安全で直接的な接続をAzureバックボーン経由で提供すると説明されている。また、Service Endpointを利用すると、仮想ネットワークからAzureサービスへのトラフィックは、Azureバックボーンネットワーク上のサービスに対して直接送られると説明されている。

重要なのは、Service Endpointを有効にした場合でも、AzureサービスのDNSエントリは変わらず、引き続きAzureサービスに割り当てられたパブリックIPアドレスに解決される点である。つまり、Private EndpointのようにFQDNがプライベートIPに解決されるわけではない。DNS上はパブリックIPに見えるが、経路上はService EndpointのシステムルートによってAzureバックボーン上で直接到達する。

さらに、Azureのルーティング仕様として、Service Endpointを有効化すると、対象サブネットに VirtualNetworkServiceEndpoint のルートが追加される。Azureのルート選択は最長プレフィックス一致を基本とし、同一プレフィックスの場合はユーザー定義ルート、BGPルート、システムルートの順に評価されるが、仮想ネットワーク、仮想ネットワークピアリング、Virtual Network Service Endpointに関連するトラフィックではシステムルートが優先され、VirtualNetworkServiceEndpoint のルートはルートテーブルでは上書きできないとされている。

ここに、「Firewallを通したつもり」の落とし穴がある。

0.0.0.0/0 → Azure Firewall というUDRを作っても、Service Endpointが有効化されたAzureサービス宛通信については、VirtualNetworkServiceEndpoint のシステムルートが効く。結果として、通信はAzure Firewallを通らずにPaaSへ到達する可能性がある。これはAzureの不具合ではない。むしろService Endpointの仕様どおりである。問題は、その仕様を前提に設計書と監査設計が作られていなかったことにある。

4. Private Endpointとの違い：閉域の意味を取り違えない

Service EndpointとPrivate Endpointは、どちらもAzure PaaSへの接続を安全にするための機能として語られる。しかし、設計上の意味は大きく異なる。

Private Endpointは、仮想ネットワーク内のプライベートIPアドレスを使用するネットワークインターフェイスであり、Azure Private Linkを利用するサービスに非公開で安全に接続するための機能である。Private LinkのFAQでは、Private LinkのトラフィックはMicrosoftバックボーンを使用してプライベートに送信され、インターネットを経由しないと説明されている。

ただし、Private Endpointを作成しただけで、PaaS側のパブリックエンドポイントが自動的に遮断されるわけではない。Azure StorageのPrivate Endpointに関するMicrosoft Learnでは、Private Linkを作成してもパブリックエンドポイントでの接続は自動的にはブロックされないため、必要に応じてストレージファイアウォールを構成する必要があると説明されている。

また、Private EndpointではDNS設計が極めて重要である。Microsoft Learnは、Private EndpointのIPアドレスを接続文字列のFQDNに解決するよう、DNS設定を正しく構成することが重要であり、既存のAzureサービスのパブリックエンドポイントDNS構成をPrivate Endpoint用に上書きする必要があると説明している。

つまり、Private Endpointを採用する場合も、「作ったから閉域」では足りない。

FQDNはプライベートIPに解決されているか。オンプレミスや別VNetからの名前解決は正しいか。Private DNS Zoneは対象VNetにリンクされているか。パブリックネットワークアクセスは無効化または制御されているか。Private Endpoint宛通信をFirewallで検査する設計なら、UDR、NSG、ネットワークポリシーの扱いは整理されているか。

Service EndpointもPrivate Endpointも、単体では「監査で説明できる閉域」を完成させない。閉域は、ルーティング、DNS、PaaS側アクセス制御、ログ、変更管理、設計書が一致して初めて説明可能になる。

5. NSGとFirewallログの限界：許可と経路証明は別物である

NSGは、Azure仮想ネットワーク内のAzureリソース間のネットワークトラフィックをフィルター処理するための機能であり、規則では送信元、宛先、ポート、プロトコル等を指定できる。NSGは重要な制御であるが、「その通信がFirewallを通ったこと」を直接証明するものではない。

Azure Firewallは、既定では許可ルールを手動で構成するまでトラフィックを拒否する設計であり、NAT、ネットワーク、アプリケーション規則を用いて制御する。これは強力な境界制御である。しかし、Firewallを経由しない経路が存在する場合、Firewall側にログが残らないことは当然である。

現場でありがちな誤解は、「Firewallに拒否ログがないから安全」「Firewallに許可ログがないが通信できているから問題ない」という判断である。実際には、Firewallログに存在しない通信は、次の三つの可能性を持つ。

第一に、通信が発生していない。第二に、Firewallを通ったがログ設定やKQL検索条件が不適切である。第三に、Firewallを通っていない。

本件は第三のケースである。そして第三のケースは、監査上もっとも説明が難しい。なぜなら、「ログがない」ことは「安全」の証明ではなく、「その証跡では説明できない」という意味だからである。

6. 現場で起きた“説明責任の事故”

この種の事故は、会議室で一気に露呈する。

監査担当が聞く。「外部サービスへの通信は、どこで制御していますか」

情シスが答える。「Azure Firewallです」

監査担当が続ける。「では、このStorageへのアクセスログとFirewallログを突合してください」

ここで詰まる。Storage側のログにはアクセスがある。アプリ側のログにも成功記録がある。しかしFirewallログには該当通信がない。担当者は最初、KQLの条件を疑う。次に時刻同期を疑う。次にFirewall Policyのルール名を疑う。最終的に、Service Endpointが有効化されていたことが判明する。

この瞬間、現場の空気が変わる。

「通信はAzureバックボーンだから危険ではないですよね」「PaaS側でVNet制限していますよね」「でも設計書にはFirewall経由と書いてありますよね」「取引先にはFirewallで監査していると回答していますよね」「では、この回答は正しいのですか」

この問いに答えられない状態が、説明責任の事故である。

クラウド法務の観点では、これは単にネットワーク構成の誤記ではない。契約、規程、情報セキュリティチェックシート、委託先管理、監査回答、インシデント時の初動説明に影響する。特に個人データを扱う業務システムでは、漏えい等のおそれがある事案が発生した場合、個人情報保護委員会への報告期限や報告対象事態の該当性判断が問題となる。個人情報保護委員会は、漏えい等報告について、速報は発覚後速やかに、目安として3〜5日以内、確報は原則30日以内、不正目的のおそれがある場合は60日以内と案内している。

その場で「どの経路を通ったかわかりません」となる構成は、事故対応の初動で致命的な遅れを生む。

7. NIST CSF 2.0の観点：これはGovernの問題である

NIST Cybersecurity Framework 2.0は、サイバーセキュリティリスクを理解、評価、優先順位付け、コミュニケーションするための高レベルな成果分類を提供する枠組みであり、特定の達成方法を処方するものではない。

本件をNIST CSF 2.0の観点で見ると、単なるProtectやDetectの問題にとどまらない。むしろ、Governの問題である。すなわち、組織としてどのリスクを受容し、どの通信をFirewallで検査し、どのPaaS通信をService Endpointで直接許可し、どのログを監査証跡として採用するのかを、経営・情シス・委託先・監査対応の言葉で合意していなかったことが原因である。

技術的には、Service Endpointを使う設計もあり得る。Private Endpointを使う設計もあり得る。FirewallでPaaS宛通信を集約監査する設計もあり得る。問題は、どれを採用したのかが、設計書、運用手順、ログ、契約、監査回答で一致していないことである。

「セキュリティ対策をしたか」ではなく、「その対策が何を守り、何を記録し、何を説明するためのものか」を定義する必要がある。

8. 設計原則：“通る”ではなく“どこを通したか”を設計する

本件から導かれる設計原則は、次の一文に集約される。

通信は、到達性ではなく、経路・制御点・証跡・責任分界で設計する。

実務上は、最低でも次の六つを一体で確認する必要がある。

観点	確認すべき事項	よくある事故
ルートテーブル	UDR、システムルート、有効なルート、Next Hop	0.0.0.0/0だけを見て全通信Firewall経由と誤認する
NSG	有効なセキュリティ規則、既定許可、Outbound制御	許可・拒否と経路証明を混同する
Service Endpoint	有効化サブネット、対象サービス、PaaS側VNet ACL	Firewallを通らない例外経路を設計書に書いていない
Private Endpoint	Private DNS Zone、FQDN解決、Public network access	Private Endpointを作っただけで閉域と判断する
DNS	パブリックIP解決か、プライベートIP解決か、オンプレDNS連携	名前解決だけが現場ごとに違い、通信経路が分裂する
Firewallログ	診断設定、構造化ログ、KQL、保持期間	通っていない通信をFirewallログで説明しようとする

Azure Network Watcherでは、Next Hopにより特定の宛先IPアドレスに対する次ホップの種類、IPアドレス、ルートテーブルIDを確認でき、IP Flow VerifyではNSG規則等に基づきパケットが許可または拒否されるかを確認できる。また、有効なルートを表示することで、既定ルート、カスタムルート、BGPで伝達されたルートの組み合わせを確認できる。

ただし、これらの診断ツールも、監査証跡として自動的に十分になるわけではない。監査で必要なのは、「調査時に見られる画面」だけではなく、「設計時に何を意図し、変更時に誰が承認し、運用時にどのログを保持し、事故時にどの資料を提出するか」である。

9. 2026年時点のログ設計：NSG Flow Logs依存からの脱却

ログ設計にも最新情報を反映する必要がある。Microsoftは、NSG Flow Logsについて、2027年9月30日に廃止され、2025年6月30日以降は新規作成できなくなり、Virtual Network Flow Logsへの移行を推奨している。

Virtual Network Flow Logsは、仮想ネットワークのトラフィックを記録するためのNetwork Watcher機能であり、NSG規則による許可・拒否だけでなく、Azure Virtual Network Managerのセキュリティ管理者ルールによる許可・拒否や、仮想ネットワーク暗号化を使用しているシナリオでの暗号化状態評価もサポートすると説明されている。

したがって、今後の監査設計では、「NSG Flow Logsを有効にしています」という回答だけでは不十分になっていく。Firewallログ、PaaSリソースログ、Virtual Network Flow Logs、Activity Log、変更管理ログを、どの目的で、どの期間、誰が確認し、どの監査質問に対応するのかを整理する必要がある。

10. 是正策：三つの設計モデルを明確に選ぶ

この問題の是正策は、単に「Service Endpointを消す」ではない。事業要件、性能、コスト、監査、委託先運用、データ保護要件に応じて、設計モデルを明確に選ぶことである。

10.1 Firewall監査型

すべてのPaaS宛通信をFirewallで検査・記録したい場合、Service Endpointを安易に有効化してはならない。なぜなら、Service Endpointの VirtualNetworkServiceEndpoint ルートはルートテーブルで上書きできないためである。Firewall監査型を採用するなら、対象PaaSへの通信をFirewallへ向けるUDR、Azure Firewallのアプリケーションルールまたはネットワークルール、PaaS側のアクセス制御、ログ保存設計を一体で作る必要がある。

10.2 Private Endpoint閉域型

PaaSをVNet内のプライベートIPで扱いたい場合は、Private Endpointを採用する。ただし、Private Endpoint作成、Private DNS Zone、VNetリンク、オンプレミスDNS転送、Public network access制御、PaaS側ファイアウォール、ログ設計をセットで実装する必要がある。Private Endpointは強力だが、DNSが崩れると、利用者の場所によってパブリック側へ名前解決されることがある。

10.3 Service Endpoint許容型

Service Endpointを使うこと自体は誤りではない。むしろ、対象サービスと要件によっては合理的である。ただし、その場合は「当該PaaS通信はFirewallを通らない例外経路である」と設計書に明記しなければならない。PaaS側のVNet ACL、リソースログ、Virtual Network Flow Logs、Next Hop確認結果、変更履歴をもって説明する設計に切り替えるべきである。

最悪なのは、Service Endpointを使っているにもかかわらず、対外説明では「全通信Firewall経由」と書き続けることである。これは、技術的にも、監査的にも、契約実務上も危険である。

11. クラウド法務として整備すべき文書

この種の問題に対して、山崎行政書士事務所が重視すべき支援領域は、単なる設定レビューではない。クラウド構成図と契約・規程を接続し、技術と法務の間を説明可能にすることである。山崎行政書士事務所のクラウド法務ページでも、Azure、M365、EntraとGDPR、NIS2、SCC等をつなぎ、クラウド環境を説明可能な状態へ整えること、構成図と契約・規程をセットでレビューすることが掲げられている。

実務上、整備すべき文書は少なくとも次のとおりである。

第一に、通信経路設計書。各サブネットから、各PaaS、インターネット、オンプレミス、管理系サービスへ向かう通信について、Next Hop、DNS解決結果、Firewall通過有無、ログ取得先を記載する。

第二に、PaaS接続方式一覧。Storage、Key Vault、SQL、Cosmos DB等について、Service Endpoint、Private Endpoint、Public Endpoint制御のどれを採用しているかを明記する。

第三に、ログ・証跡対応表。「Firewallログで説明する通信」「PaaSリソースログで説明する通信」「Virtual Network Flow Logsで補完する通信」「Activity Logで変更証跡を説明する操作」を分ける。

第四に、責任分界表。自社情シス、SIer、MSP、SOC、クラウド運用担当、アプリベンダーの間で、Service Endpoint有効化、Private Endpoint作成、DNS変更、Firewall Policy変更、PaaS側ネットワーク制限変更を誰が承認し、誰が記録し、誰が監査時に説明するかを定義する。

第五に、契約・運用条項。委託先契約や運用SLAに、構成変更時の事前承認、ログ提出協力、KQLまたはログ検索条件の共有、障害・侵害時の初動報告、再委託先の操作証跡、設計書更新義務を盛り込む。

これらは、紛争代理のためではなく、日常運用で説明可能性を確保するための文書整備である。ここに、Azure現場を理解する行政書士によるクラウド法務支援の価値がある。

12. 結論：通信はできていた。しかし、説明できなかった。

本件の本質は、Azureの機能選択ミスではない。

Service Endpointは悪ではない。Private Endpointも万能ではない。Azure Firewallも、通らない通信までは記録できない。NSGも、経路そのものを証明するものではない。DNSも、設計しなければ現場ごとに別の答えを返す。

問題は、「通信ができる」という技術的成功を、「統制できている」「監査できる」「契約上説明できる」という組織的成功と取り違えたことである。

クラウド時代の閉域設計は、ネットワーク図だけでは完成しない。ルートテーブル、NSG、Service Endpoint、Private Endpoint、DNS、Firewallログ、PaaS側ログ、変更管理、責任分界、契約条項が一致して初めて、閉域は説明可能になる。

“通る”だけでは足りない。“止める”だけでも足りない。“ログがある”だけでも足りない。

どこを通したか。なぜそこを通したか。誰が承認したか。どのログで証明するか。事故時に誰が説明するか。

ここまで設計して初めて、Azureのネットワークはクラウド法務に耐える。

山崎行政書士事務所のクラウド法務・Azure技術支援は、この「技術構成」と「説明責任」の隙間を埋めるための支援である。Firewallを通した“つもり”の設計を、監査・契約・経営説明に耐える設計へ変える。そこに、技術と法務をつなぐ実務の価値がある。