検証では動くのに、本番だけ繋がらない

― Azure Private Endpoint／Private DNS Zoneにおける「環境差分事故」とクラウド法務上の説明責任 ―

※本稿は、Azure構成・クラウド運用・契約文書・監査証跡の整理を目的とする一般的情報提供です。個別紛争、訴訟、代理交渉、個別法的判断は弁護士等の専門領域となる場合があります。山崎行政書士事務所のクラウド法務としては、行政書士業務の範囲を守りつつ、Azureの技術実態を契約・規程・説明資料・監査証跡へ落とし込む観点から論じます。

要旨

Azure PaaSの閉域化で、検証環境では正常に動作したPrivate Endpoint接続が、本番リリース直後にDB接続不可となる事故は珍しくない。典型原因は、NSGでもFirewallでもなく、DNSである。特に、Private DNS Zoneの本番VNetリンク漏れ、Aレコード不整合、カスタムDNS／DNS Private Resolver／オンプレDNSの転送差分は、「dev/stgでは動くのにprodだけ壊れる」事故を生む。

Microsoft Learnは、Private EndpointのDNS構成について、Private EndpointのIPアドレスを接続文字列のFQDNへ解決するようDNS設定を正しく構成することが重要であり、既存のAzureサービスのパブリックエンドポイントDNS構成をPrivate Endpoint利用時には上書きする必要があると説明している。また、Private Endpoint DNS統合は、仮想ネットワーク内のAzureサービスへの安全なプライベート接続に不可欠であり、サービスFQDNは既定でパブリックIPへ解決されるため、Private EndpointのプライベートIPへ解決するにはDNS構成変更が必要である。

本稿の結論は明確である。本番設計では、通信経路より先に名前解決経路を設計せよ。 Private Endpointは作成しただけでは閉域化にならない。Private DNS Zone、VNetリンク、FQDN解決、監視、IaC、責任分界、監査証跡が一致して初めて、「本番で壊れない閉域化」と「説明できるクラウド法務」が成立する。

キーワード： Azure、Private Endpoint、Private DNS Zone、VNetリンク、Azure SQL Database、DNS、IaC、Bicep、情シス、クラウド法務、監査証跡

1. 序論：本番だけ壊れる事故は、たいてい“差分”で起きる

クラウドの障害対応で最も嫌な言葉がある。

「検証では動いていました」

この一言が出た瞬間、現場の調査は難しくなる。開発環境では接続できる。ステージング環境でも接続できる。Private Endpointも作成済み。DB側のPrivate Endpoint Connectionも承認済み。NSGもAllow。FirewallにもDenyは出ていない。アプリケーションのコンテナやVMも起動している。

それでも本番だけDBに繋がらない。

このとき、現場ではまず通信制御を見る。NSGの優先度、Firewall Policy、ルートテーブル、PaaS側ファイアウォール、送信元IP、アプリの接続文字列、Key Vaultのシークレット。TeamsやSlackには、短いが重いメッセージが流れる。

「PEはApprovedです」「NSGはAllowです」「FirewallログにDenyありません」「アプリは起動しています」「でもDBに繋がりません」「なぜ本番だけですか」

数時間後に見つかった原因は、prod VNetだけPrivate DNS Zoneにリンクされていなかったことだった。さらに、本番だけDNS問い合わせ経路が違い、パブリックDNSへ素直にフォールバックする構成ではなかった。内部DNSがPrivate Link用の名前解決を握っているのに、対象VNetがゾーンへ到達できず、FQDN解決が失敗していた。

これは単なるDNSミスではない。これは、検証環境で動く設計を、本番で壊れない設計と取り違えた事故である。

2. 研究対象：Private Endpoint接続はdev/stg正常、prodだけDB接続不可

本稿で扱う事例は、複数のAzure現場で見られる構成事故を抽象化したものである。

対象は、Azure上の業務アプリケーションとAzure SQL Databaseである。dev/stg/prodの三環境があり、各環境にVNet、アプリケーション実行基盤、DB接続設定が存在する。DBはPrivate Endpoint化され、パブリックアクセスは制限または拒否する方針だった。Azure SQL DatabaseのPrivate Endpointでは、論理サーバーへのパブリックルーティングはPrivate Endpoint追加だけでは既定でブロックされず、パブリックネットワークアクセスを無効にするには明示的な設定が必要である。

devとstgでは、privatelink.database.windows.net のPrivate DNS Zoneが対象VNetにリンクされ、AレコードもPrivate Endpoint NICのIPと一致していた。ところがprodだけ、Private DNS ZoneのVNetリンクが漏れていた。Azure Private DNSでは、Private DNS Zoneを作成した後、そのゾーンを仮想ネットワークにリンクする必要があり、リンクされた仮想ネットワーク内のVM等がPrivate DNS Zoneのレコードへアクセスできるようになる。

ここで重要なのは、Private Endpointの存在と、名前解決の成立は別物だという点である。

Private Endpointはある。Private DNS Zoneもある。Aレコードもどこかにはある。しかし、prod VNetからそのZoneを参照できない。

この状態では、本番アプリケーションから見れば、Private Endpointは存在しないのと同じである。

3. 技術的本質：Private Endpointは“IP”ではなく“FQDN解決”で成立する

Azure SQL DatabaseのPrivate Endpoint接続で、現場がよく誤解する点がある。接続先をPrivate IPやprivatelink FQDNへ直接変えればよい、という誤解である。

Microsoft Learnは、Azure SQL Database接続時にはクライアントの接続文字列で <server>.database.windows.net を使用し、IPアドレスや <server>.privatelink.database.windows.net を使用して直接ログインしようとすると失敗すると説明している。これは、Private Endpointがリージョン内のSQL Gatewayへトラフィックをルーティングし、ログイン成功には正しいFQDNが必要であるためである。

つまり、Private Endpoint化したDB接続の基本は次である。

アプリケーションの接続先:  <server>.database.windows.net期待される名前解決:  <server>.database.windows.net      ↓  <server>.privatelink.database.windows.net      ↓  Private Endpoint のプライベートIP

この名前解決が成立していなければ、NSGがAllowでも、FirewallがAllowでも、アプリケーションは正しい入口へ向かえない。

Microsoft Learnは、サービスのFQDNは既定ではパブリックIPに自動解決され、Private EndpointのプライベートIPへ解決するにはDNS構成を変更する必要があると説明している。また、DNSはPrivate EndpointのIPアドレスを解決するため、アプリケーションが正常に動作するために重要であると明記している。

したがって、Private Endpointの本番受入テストで見るべき最初の値は、ポート開放ではない。FQDNがどのIPへ解決されているかである。

4. なぜ「本番だけ」壊れたのか

この事故が厄介なのは、原因が単純なのに、説明が難しい点である。

「prod VNetだけPrivate DNS Zoneリンクが漏れていました」

言葉にすると一行で終わる。しかし現場では数時間かかる。なぜなら、調査の初動が通信制御へ寄るからである。

NSGを見る。Firewallを見る。ルートを見る。DBファイアウォールを見る。接続文字列を見る。アプリの再起動をする。シークレットを取り直す。それでも直らない。

この順番が間違っている。PaaS閉域化では、まず名前解決を見るべきである。

特にHub-Spoke構成では、Private DNS Zoneのリンク漏れが起きやすい。Microsoft Learnは、ピアリングされた仮想ネットワークのワークロードでPrivate Endpointを使用する場合、Private DNS Zoneに新しい仮想ネットワークリンクを追加する必要があり、Hub-Spokeモデルでは名前解決を必要とするクライアントを含むすべてのHubおよびSpoke VNetに同じPrivate DNS Zoneをリンクする必要があると説明している。

つまり、VNetピアリングがあるからDNSも通る、ではない。ネットワーク的に到達可能でも、DNS的に解決可能とは限らない。

この区別が、現場ではしばしば崩れる。

5. 「パブリックにフォールバックせず失敗」の構造

今回の事故で特に生々しいのは、「Private DNS Zoneリンクが漏れていたなら、パブリックDNSへ戻るのではないか」という議論が起きる点である。

単純なAzure既定DNS構成であれば、Private DNS Zoneを参照できない場合にパブリック側の名前解決結果へ向かうケースはあり得る。しかし企業環境の本番では、そう単純ではない。本番だけカスタムDNSを使っている。オンプレDNSの条件付きフォワーダーがある。Azure DNS Private Resolverを経由している。HubのDNSフォワーダーがprivatelink系ゾーンを内部に向けている。結果として、内部DNSがPrivate Link用の名前を処理する前提になっているのに、prod VNetだけPrivate DNS Zoneへリンクされていない、または正しい転送経路に乗っていない、という状態が起きる。

Azure DNS Private Resolverは、Azure VNetとオンプレミス環境の間でセキュリティ保護されたDNS解決を可能にするフルマネージドサービスであり、仮想ネットワーク内のクライアントからのDNSクエリ、カスタムDNS設定、同一VNetにリンクされたPrivate DNS Zone、DNS転送ルールセットなどの順序で名前解決が処理される。

この仕組みを理解せずに「DNSはAzureが自動でやってくれる」と考えると、本番だけ壊れる。

本番は検証環境より複雑である。本番だけオンプレ連携がある。本番だけ監査要件でパブリックアクセス拒否が強い。本番だけHub経由のDNSを使っている。本番だけリソース名やゾーン名の命名が微妙に違う。本番だけ手動で直した過去のAレコードが残っている。

つまり、本番だけ壊れるのではない。本番だけ、設計していない差分が表面化するのである。

6. 監視の盲点：アプリは起動しているのに、業務は使えない

この事故では、監視も役に立たないことがある。

アプリケーションプロセスは起動している。コンテナはRunning。VMは正常。App Serviceも稼働。CPUもメモリも平常。FirewallにDenyもない。NSGにも明確な拒否がない。

しかし、DBへ繋がらないため業務は使えない。

Azure Network Watcherの接続モニターは、継続的なネットワーク接続監視を提供し、TCP、ICMP、HTTP pingに基づく接続チェックや、URL、FQDN、IPアドレスを宛先エンドポイントとする監視をサポートしている。したがって、本番のアプリ実行元からDBのFQDNを対象にした接続監視を設計する余地はある。

ただし、接続モニターやフローログだけに頼ってはいけない。Virtual Network Flow Logsは仮想ネットワークを通過するIPトラフィックに関する情報を記録する機能であり、フローはネットワーク分離やアクセス規則への準拠確認にも利用できるが、DNS解決に失敗して通信そのものが発生しない場合、DB宛IPフローとしては観測されない。

さらに、NSG Flow Logsは2027年9月30日に廃止予定であり、2025年6月30日以降は新規作成できず、MicrosoftはVirtual Network Flow Logsへの移行を推奨している。ログ設計も、過去のNSG Flow Logs前提から更新が必要である。

本番監視で必要なのは、単なる死活監視ではない。次の三段階である。

1. 名前解決監視

   <server>.database.windows.net がPrivate EndpointのIPへ解決されるか。

2. 接続監視

   解決後の宛先へTCP接続できるか。

3. 業務監視

   実際にDBログインまたは軽量クエリが成功するか。

「アプリが起動している」は、業務が使えることを意味しない。「ポートが開いている」は、Private Endpoint経由で正しくDBへログインできることを意味しない。「FirewallにDenyがない」は、DNSが正しいことを意味しない。

7. IaCで統一しない本番環境は、いつか壊れる

この事故の再発防止で最も重要なのは、Private DNS Zoneリンクを手動作業にしないことである。

Bicepは、Azureリソースを宣言型構文でデプロイするドメイン固有言語であり、開発ライフサイクル全体でインフラを繰り返しデプロイでき、リソースを一貫した方法で配置できるとMicrosoft Learnは説明している。

ARMテンプレートについても、インフラストラクチャをコードとして定義し、ソースリポジトリでバージョン管理し、同様の環境をデプロイできること、さらにテンプレートは冪等性を持ち、同じテンプレートを何度でもデプロイして同じリソースを同じ状態に配置できることが説明されている。

本番だけPrivate DNS Zoneリンクが漏れる事故は、まさにIaCで防ぐべき事故である。

dev/stg/prodで個別にポータル作業をする。担当者が違う。作業日が違う。チェックリストが違う。本番だけ例外対応をする。リリース直前に手動で直す。

この運用は、クラウドでは危険である。

Private Endpoint、Private DNS Zone、Aレコード、Private DNS Zone Group、VNetリンク、DNS Private Resolverのルールセット、PaaS側のPublic network access、監視、アラートまでを、環境パラメータを変えながら同じコードで展開する。これが「動く検証環境」から「壊れない本番設計」への第一歩である。

8. Azure Policyによるガードレール

IaCだけでなく、Azure Policyによる検知・補正も検討すべきである。Microsoftの組み込みポリシーには、Private Endpointに対してPrivate DNS Zoneを構成するDeployIfNotExists系の定義が複数のAzureサービス向けに用意されており、たとえばAutomation、Databricks、Cosmos DB、Key Vault、Service Bus、SynapseなどでPrivate DNS Zoneを使う構成が列挙されている。

ただし、Azure Policyは万能ではない。ポリシーを割り当てたから本番で名前解決できる、ではない。どのスコープに割り当てるか。どのパラメータを使うか。既存リソースへRemediationをかけるか。Hub-SpokeのどのVNetへリンクさせるか。複数サブスクリプションをどう扱うか。例外を誰が承認するか。

ここを設計しないPolicyは、監査資料上の「導入済み」に過ぎない。

Policyは、統制を実装する道具である。統制そのものではない。

9. 受入テスト：本番リリース前に必ず見るべき項目

PaaS閉域化の受入テストでは、次を証跡として残すべきである。

観点	確認内容	証跡例
FQDN解決	<server>.database.windows.net がPrivate Endpoint IPへ解決されるか	Resolve-DnsName / nslookup 実行結果
実行元	prodの実アプリ実行元から確認しているか	VM名、サブネット、VNet ID、実行時刻
VNetリンク	prod VNetがPrivate DNS Zoneへリンク済みか	Private DNS ZoneのVNetリンク一覧
Aレコード	AレコードIPとPrivate Endpoint NIC IPが一致するか	DNSレコード、NIC IP、Private Endpoint ID
接続文字列	IP直書きやprivatelink FQDN直書きになっていないか	アプリ設定、Key Vault参照
Public access	PaaS側のパブリックネットワークアクセスが方針どおりか	PaaSネットワーク設定
DNS経路	Azure既定DNS、カスタムDNS、Private Resolver、オンプレDNSの経路が明確か	DNS経路図、転送ルール
監視	FQDN解決、TCP接続、DBログインを監視しているか	接続モニター、スクリプト、アラート
IaC	dev/stg/prodのDNS構成が同一コードで管理されているか	Bicep/Terraform、パラメータ差分
変更管理	VNet追加・Private Endpoint再作成時のDNS更新手順があるか	変更管理票、運用手順書

この表を見れば分かるとおり、受入テストは「接続できました」で終わらない。接続できた理由を証明することが、受入テストである。

10. 現場で使う初動コマンド

障害時には、まず本番アプリと同じ名前解決経路を使う場所から確認する。

Resolve-DnsName <server>.database.windows.net

次に、返ってきたIPがPrivate Endpoint NICのIPと一致するかを確認する。

Test-NetConnection <server>.database.windows.net -Port 1433

Azure SQLの場合、接続文字列には通常FQDNを使う。Private IPやprivatelink FQDNを直接指定してログイン検証をしない。ここを誤ると、テストは通ったように見えても、本番アプリの実際の接続経路を検証できない。

そして、dev/stg/prodで同じコマンドを打つ。差分が出たら、そこが事故の入口である。

11. クラウド法務上の論点：これはDNS事故であり、説明責任の事故である

本件は、単なるインフラ障害ではない。クラウド法務上は、次の説明が問われる。

「なぜ検証では動いて、本番では動かなかったのか」「本番の閉域化は、リリース前に何をもって確認したのか」「Private Endpoint化済みという監査回答の根拠は何か」「本番VNetがPrivate DNS Zoneにリンクされている証跡はあるか」「DNS監視が対象外だった理由は何か」「委託先、SIer、自社情シスの誰がDNSリンクを確認する責任を負っていたのか」「再発防止策は、手順書なのか、IaCなのか、Policyなのか」

ここで「担当者が確認漏れしました」で終わらせると、再発する。

NIST CSF 2.0は、サイバーセキュリティリスクの管理と低減を支援する枠組みとして、従来のIdentify、Protect、Detect、Respond、Recoverに加え、Governを新たに中核機能として位置付けている。NISTは、Governを通じてサイバーセキュリティが財務や評判と同様に企業リスクとして扱われるべきであると説明している。

この観点から見ると、本件はProtectだけの失敗ではない。Governの失敗である。

誰がDNS設計を承認するのか。誰が本番VNetリンクを確認するのか。誰が監視対象にFQDN解決を入れるのか。誰が取引先に「閉域化済み」と説明するのか。誰が証跡を保管するのか。

これを決めないままPrivate Endpointを作ると、クラウド法務としては不十分である。

12. 契約・規程・監査資料への落とし込み

山崎行政書士事務所のクラウド法務・Azure技術支援では、Azureの実装、ログ、責任分界、監査、インシデント対応を契約・規程・説明資料・運用手順へ一貫した言葉で翻訳することが重要であると整理している。特に、契約・規程・監査資料は技術実態と同じ粒度で作る必要があり、設計・構成・運用設計・ドキュメント整備をまとめて支援する考え方が示されている。

本件で整備すべき文書は、少なくとも次である。

第一に、DNS解決経路図。dev/stg/prodごとに、アプリ実行元からDB FQDNを引いたとき、どのDNSサーバー、どのPrivate DNS Zone、どの転送ルールを通り、最終的にどのPrivate IPを返すのかを図示する。

第二に、Private DNS Zoneリンク一覧。各Private DNS Zoneについて、リンク済みVNet、用途、対象PaaS、管理方式、IaC管理有無を一覧化する。

第三に、PaaS閉域化受入基準。Private Endpoint作成、Private DNS Zoneリンク、FQDN解決、Public network access、監視、ログ、変更管理を完了条件として定義する。

第四に、責任分界表。DNS、Private Endpoint、PaaSネットワーク設定、Firewall、アプリ接続文字列、Key Vault、監視の担当者を明確化する。

第五に、障害初動手順。「PaaS閉域接続障害では、NSG・Firewall確認より先に、接続元からFQDNの名前解決結果を取得する」と明記する。

第六に、取引先・監査向け説明資料。「Private Endpointを使っています」ではなく、「どのFQDNが、どのPrivate DNS Zoneを通じて、どのPrivate IPに解決され、その証跡をどこに保管しているか」を説明する。

これらは、法律論だけでも、技術論だけでも作れない。Azure現場の粒度を理解し、行政書士として文書化・責任分界・証跡整備へ落とし込む必要がある。

13. 考察：検証環境は“証明”にならない

検証環境で動いたことは、本番で壊れないことの証明ではない。

devはAzure既定DNS。stgはHub DNS経由。prodはオンプレDNS経由。devはPublic access許可。prodはPublic access拒否。devは手動レコード。prodはDNS Zone Group。stgはVNetリンク済み。prodはリンク漏れ。

このような差分があるなら、検証環境の成功は本番成功の証明にならない。

本番設計とは、検証環境をコピーすることではない。本番の制約、監査、閉域、DNS、監視、委託先運用を含めて、壊れない状態を設計することである。

14. 結論：動く検証環境ではなく、壊れない本番設計へ

本件の結論は、次の一文に尽きる。

PaaS閉域化は、Private Endpointを作ることではない。FQDNが本番の実行元からPrivate IPへ解決され続ける状態を、設計・監視・証跡・責任分界で保証することである。

NSGがAllowでも、DNSが壊れていれば繋がらない。FirewallにDenyがなくても、名前解決できなければ通信は始まらない。Private EndpointがApprovedでも、prod VNetがPrivate DNS Zoneにリンクされていなければ本番アプリは使えない。dev/stgで動いても、prodのDNS経路が違えば本番保証にはならない。監視がCPUとプロセスしか見ていなければ、アプリは起動しているのに業務は停止する。

閉域化PaaSで見るべき問いは、次である。

• DNS解決経路は環境ごとに一致しているか

• prod VNetはPrivate DNS Zoneにリンク済みか

• FQDNはPrivate EndpointのIPへ解決されるか

• Public network accessは方針どおり制御されているか

• 名前解決まで含めて監視しているか

• VNetリンクはIaCで統一されているか

• 変更時にDNS証跡を残しているか

• 監査時に「なぜ閉域と言えるか」を説明できるか

山崎行政書士事務所のクラウド法務・Azure技術支援は、この「技術的に動く」と「本番で壊れない」と「監査で説明できる」の隙間を埋める支援である。

Private Endpointを作るだけでは足りない。Private DNS Zoneを作るだけでも足りない。本番VNetで、正しいFQDNが、正しいPrivate IPに解決され、その状態が監視され、IaCで再現され、契約・規程・責任分界・監査資料で説明できる。

そこまで整えて初めて、PaaS閉域化は本番設計になる。

動く検証環境ではなく、壊れない本番設計へ。通信制御だけでは足りない。名前解決まで設計せよ。