PaaS閉域化で「NSGは許可なのに繋がらない」事故
- 山崎行政書士事務所
- 5月2日
- 読了時間: 18分
― Private Endpoint時代のAzure DNS設計とクラウド法務上の説明責任 ―
※本稿は、Azure構成・クラウド運用・契約文書・監査証跡の整理を目的とする一般的情報提供です。個別紛争、訴訟、法律判断、弁護士法その他専門士業の独占業務に属する事項は、必要に応じて弁護士等と連携する領域です。
要旨
Azure PaaSをPrivate Endpointで閉域化したにもかかわらず、「NSGもFirewallもAllowなのに本番だけDBへ接続できない」という事故は、現場で非常に多い。原因は、通信制御ではなくDNSであることが少なくない。
Private Endpointは、Azure PaaSを仮想ネットワーク内のプライベートIPアドレスで利用するための重要な仕組みである。Microsoft Learnでも、Private EndpointはVNet内のプライベートIPアドレスを使用するネットワークインターフェイスであり、Private Link対応サービスに非公開で安全に接続するためのものと説明されている。さらに、Private Linkでは仮想ネットワークとサービス間のトラフィックがMicrosoftバックボーンネットワークを通り、パブリックインターネットへサービスを公開する必要がないとされている。
しかし、Private Endpointの本質は「IPをプライベート化すること」だけではない。利用者やアプリケーションが接続するFQDNを、正しくPrivate EndpointのIPへ名前解決させることが中核である。Microsoft Learnは、Private EndpointのDNS統合が、仮想ネットワーク内のAzureサービスへの安全なプライベート接続に不可欠であると説明している。
本稿では、ある現場で起きた「本番だけDB接続不可」の事例をもとに、Private DNS Zone、VNetリンク、Aレコード、カスタムDNS、Azure DNS Private Resolver、NSG、Firewall、監査証跡、契約実務の関係を整理する。結論は明確である。閉域化PaaSは、疎通より先に名前解決を見る。通信制御だけでは足りない。名前解決まで設計せよ。
キーワード： Azure、Private Endpoint、Private DNS Zone、Azure SQL Database、Azure Storage、DNS、NSG、Firewall、クラウド法務、情シス、監査証跡
1. 序論：Azure閉域化の失敗は、ポートではなく名前で起きる
AzureのPaaS閉域化では、情シス・SIer・アプリベンダーがまずNSG、Firewall、ルートテーブル、Private Endpointの作成状態を確認する。これは当然である。だが現場で本当に時間を溶かすのは、ネットワーク経路そのものではなく、DNSの見落としである。
ある現場で、開発環境とステージング環境は問題なく動いていた。本番リリース前の最終確認でも、Private Endpointは作成済み、NSGはAllow、Firewall PolicyもAllow、DB側のパブリックアクセスは制限済み。構成図上は、きれいな閉域PaaS構成だった。
ところが本番切替の直後、アプリケーションだけがDBへ接続できない。
インフラ担当は言う。「NSGは開いています」
ネットワーク担当は言う。「FirewallにもDenyは出ていません」
アプリ担当は言う。「接続文字列はステージングと同じ形式です」
DB担当は言う。「Private Endpoint Connectionは承認済みです」
それでも繋がらない。
数時間後に見つかった原因は、Private DNS ZoneのVNetリンク漏れと、古いAレコードの残存だった。本番VNetが privatelink.database.windows.net のPrivate DNS Zoneにリンクされていなかった。さらに、手動で入れたAレコードが過去のPrivate Endpoint IPを向いていた。結果として、FQDNが期待するPrivate Endpoint IPに解決されず、アプリケーションは「存在しない入口」または「許可されていない経路」へ向かっていた。
この事故の本質は、単なるDNS設定ミスではない。「閉域化した」と説明していたのに、閉域化の成立条件を証明できていなかった点にある。
2. 事例：NSGもFirewallもAllow、しかし本番だけDBへ接続不能
本事例は、複数のAzure現場で見られる典型的な失敗を抽象化したものである。
対象は、Azure上の業務アプリケーションとAzure SQL Databaseである。アプリケーションはApp Serviceまたは仮想マシンからDBへ接続する構成で、本番ではAzure SQL DatabaseをPrivate Endpoint化していた。Azure SQL DatabaseのPrivate Linkに関するMicrosoft Learnでは、Private Endpointは特定のVNetおよびサブネット内のプライベートIPアドレスであると説明されている。
構成上は、次のように見えていた。
Private Endpointは作成済み
Private Endpoint Connectionは承認済み
NSGはアプリサブネットからDB向け通信を許可
Azure Firewallも該当通信を許可
DB側のパブリックアクセスは制限
開発環境・ステージング環境では接続成功
この状態で本番だけ接続できないと、現場はほぼ確実に通信制御へ向かう。NSGの優先度、Firewall Policy、ルートテーブル、DBファイアウォール、アプリ側のOutbound制限を見始める。
しかし、ここで最初に見るべきだったのはDNSだった。
Azure SQL Databaseでは、クライアントの接続文字列には通常のサーバーFQDN、すなわち <server>.database.windows.net を使う必要があり、Private Link FQDNやPrivate IPへ直接ログインしようとすると失敗するとMicrosoft Learnは説明している。これは、Private EndpointがSQL Gatewayへトラフィックをルーティングするため、正しいFQDNが必要だからである。
つまり、Azure SQLのPrivate Endpoint接続では、次の確認が不可欠である。
接続先FQDN:<server>.database.windows.net期待する名前解決:<server>.database.windows.net → CNAME等を経由 → <server>.privatelink.database.windows.net → Private Endpoint のプライベートIPこの名前解決が崩れていれば、NSGがAllowでも、FirewallがAllowでも、アプリケーションは正しいPrivate Endpointへ向かわない。
3. 技術的分析：NSGのAllowは「名前解決の成功」を意味しない
NSGは、Azure仮想ネットワーク内のリソース間のトラフィックをフィルター処理するための機能である。Microsoft Learnでは、NSGは送受信ネットワークトラフィックを許可または拒否するセキュリティ規則を含み、送信元、宛先、ポート、プロトコル等を用いて制御すると説明されている。
ここで重要なのは、NSGは基本的に「解決済みの通信」を見るという点である。アプリケーションが myserver.database.windows.net に接続しようとした場合、まずDNSでIPアドレスを得る。その後、そのIPに対してTCP接続が試行される。NSGやFirewallの多くの通信制御は、この後段で評価される。
したがって、次のような状況では、NSG Allowは問題解決にならない。
第一に、FQDNがNXDOMAINになっている。この場合、そもそも接続先IPが得られない。
第二に、FQDNがパブリックIPに解決されている。DB側でパブリックネットワークアクセスを拒否していれば、通信は失敗する。
第三に、FQDNが古いPrivate Endpoint IPに解決されている。Private Endpoint再作成や環境差分によって、Aレコードが実体とずれていると、疎通は成立しない。
第四に、開発・ステージング・本番でPrivate DNS Zoneのリンク先VNetが違う。dev/stgでは成功し、prodだけ失敗する典型パターンである。
NSGのAllowは、「そのIP・ポートの通信が許可されている」という意味であって、「アプリケーションが正しいPaaSリソースへ名前解決できている」という意味ではない。
4. Private DNS ZoneのVNetリンクが閉域化の生命線である
Azure Private DNSでは、仮想ネットワークからPrivate DNS Zone内のレコードを解決するために、VNetをゾーンにリンクする必要がある。Microsoft Learnも、リンクされた仮想ネットワークはプライベートゾーンに公開されているDNSレコードを解決できると説明している。
Private EndpointのDNS構成では、Private DNS ZoneをVNetにリンクし、対象FQDNをPrivate EndpointのIPへ解決させる。Microsoft Learnは、Private DNS Zoneを使用してPrivate EndpointのDNS解決をオーバーライドでき、Private DNS ZoneをVNetにリンクして特定ドメインを解決できると説明している。
ここで事故が起きる。
開発環境では、Private DNS Zoneがdev VNetにリンクされている。ステージング環境では、stg VNetにもリンクされている。本番環境では、prod VNetへのリンクだけが漏れている。
この場合、ポータル上ではPrivate EndpointもPrivate DNS Zoneも存在する。構成図にも「Private Endpointあり」と書けてしまう。しかし、本番アプリが存在するVNetからそのPrivate DNS Zoneを参照できなければ、閉域化は成立しない。
さらにHub-Spoke構成では、誤解が増える。HubにPrivate DNS Zoneを作成したからといって、すべてのSpokeが自動的に正しく名前解決できるわけではない。Microsoft Learnは、ピアリングされたVNetのワークロードについて、同じPrivate DNS Zoneを、名前解決を必要とするクライアントを含むすべてのHubおよびSpoke VNetにリンクする必要があると説明している。
閉域化PaaSでは、VNetピアリングとPrivate DNS Zoneリンクを混同してはならない。通信経路がつながっていても、名前解決は別問題である。
5. Azure SQL Databaseで特に危険な誤解
Azure SQL DatabaseのPrivate Endpointで、現場がよく誤るのは次の三つである。
5.1 Private IPへ直接接続しようとする
Azure SQLでは、接続文字列にPrivate EndpointのIPアドレスを直接書くべきではない。Microsoft Learnは、すべてのクライアントドライバーとツールの接続文字列には常にサーバーFQDNを使用し、Private IPやPrivate Link FQDNで直接ログインしようとすると失敗すると説明している。
現場では、疎通確認のために telnet 10.x.x.x 1433 や Test-NetConnection 10.x.x.x -Port 1433 を行い、「ポートは開いている」と判断することがある。しかし、それはAzure SQLへのログイン成功を意味しない。SQL Gatewayの仕様上、FQDNを含めた接続経路として成立しているかを見る必要がある。
5.2 privatelink FQDNを接続文字列に書く
これも危険である。Private Endpoint化したからといって、アプリケーションの接続先を <server>.privatelink.database.windows.net に変えるのではない。通常は <server>.database.windows.net を使い、DNS側でPrivate Endpoint IPへ解決させる。
この考え方はAzure Storageでも同様である。Microsoft Learnは、Private Endpointを使う場合でも同じ接続文字列を使用し、privatelink サブドメインURLを使ってストレージアカウントへ接続しないよう説明している。
5.3 Private Endpointを作ればパブリックアクセスが自動で遮断されると思い込む
Azure SQL Databaseでは、Private Endpoint接続を追加しても論理サーバーへのパブリックルーティングは既定ではブロックされず、パブリックネットワークアクセスを無効にするには拒否設定が必要とされている。
Azure Storageでも同様に、Private Linkを作成してもパブリックエンドポイントでの接続は自動的にはブロックされず、必要に応じてストレージファイアウォールを手動で構成する必要がある。
つまり、Private Endpoint化とは、単なる「Private Endpoint作成」ではない。
Private Endpointを作成する
Private Endpoint Connectionを承認する
Private DNS Zoneを正しく作成する
対象VNetへリンクする
FQDNがPrivate IPへ解決されることを確認する
パブリックネットワークアクセスを制御する
開発・検証・本番で差分がないことを確認する
ログと設計書で説明できる状態にする
ここまで揃って初めて、閉域化PaaSは実務上説明できる。
6. Azure Storageでも同じ事故が起きる
本稿の主題はDB接続であるが、同じ問題はAzure Storageでも起きる。Microsoft Learnは、Private Endpointを使用するVNet上のクライアントは、パブリックエンドポイントに接続する場合と同じ接続文字列を使用し、Private Link経由でストレージへ自動的にルーティングするにはDNS解決に依存すると説明している。
さらに、ストレージのPrivate Endpointでは、VNet外からストレージエンドポイントURLを解決するとパブリックエンドポイントに解決され、Private EndpointをホストするVNet内から解決するとPrivate EndpointのIPに解決されると説明されている。
これは、監査上きわめて重要である。同じFQDNでも、どのネットワークから名前解決するかによって、返るIPが変わる。
そのため、監査証跡としては、単に「Private Endpointがあります」では足りない。次のような証跡が必要になる。
Resolve-DnsName <storageaccount>.blob.core.windows.netResolve-DnsName <server>.database.windows.netTest-NetConnection <server>.database.windows.net -Port 1433そして、その実行元がどのVNet、どのサブネット、どのDNS設定を使うマシンなのかを記録しなければならない。
7. カスタムDNS・オンプレDNSが入ると難易度は一段上がる
企業環境では、Azure標準DNSだけでなく、オンプレミスDNS、Windows DNS、Infoblox、BIND、Azure Firewall DNS Proxy、Azure DNS Private Resolverなどが組み合わされることが多い。
Microsoft Learnは、オンプレミスのDNSソリューションからPrivate EndpointのFQDNを解決するには、DNSフォワーダーやAzure DNS Private Resolverを用いる構成を示している。オンプレミスDNSは条件付きフォワーダーを通じてAzure側へDNSトラフィックを転送し、解決はVNetにリンクされたPrivate DNS Zoneによって行われる構成である。
Azure DNS Private Resolverは、Azure VNetとオンプレミス環境の間で安全かつシームレスなDNS解決を可能にするフルマネージドサービスであり、カスタムDNSサーバーのデプロイやパッチ適用を不要にできるとMicrosoft Learnは説明している。
現場では、ここで次のような事故が起きる。
オンプレDNSの条件付きフォワーダーが privatelink.database.windows.net ではなく誤ったゾーンに向いている
Azure側のPrivate DNS Zoneは正しいが、問い合わせ元VNetから到達できるDNSフォワーダーがない
開発環境だけAzure既定DNS、本番だけカスタムDNSになっている
DNSキャッシュが古く、Private Endpoint再作成後も旧IPを返している
手動Aレコードを入れたため、DNS Zone Groupによる自動更新と競合している
特に本番だけ失敗する案件では、「本番だけDNS経路が違う」ことが多い。通信経路図にはHub-Spokeが描かれているが、DNSの問い合わせ経路図がない。これが事故の温床である。
8. DNS Zone Groupと手動Aレコードの管理不全
Private EndpointのDNS設計では、Private DNS Zone Groupの扱いも重要である。Microsoft Learnは、Private EndpointをPrivate DNS Zoneと統合することを選択した場合、Private DNS Zone Groupも作成され、Private Endpointに更新がある場合のPrivate DNS Zoneレコード管理に役立つと説明している。
ところが現場では、初回構築時にDNS Zone Groupを作らず、手動でAレコードを登録していることがある。あるいは、Private Endpointを一度削除・再作成したのに、古いAレコードが残っている。Private EndpointのNIC IPが変わったのに、DNSは旧IPを返し続ける。
この状態でNSGやFirewallを見ても、原因は見つからない。通信制御ではなく、名前が間違っているからである。
設計上は、次の方針を明確にすべきである。
Private DNS Zone Groupで自動管理するのか
手動Aレコードで管理するのか
手動管理の場合、変更時の承認者・更新者・確認者は誰か
Private Endpoint再作成時にDNSレコードをどう更新するか
dev/stg/prodで同じ管理方式か
IaCで再現可能か
監査時に、現在の名前解決結果を証跡として出せるか
DNSは裏方ではない。閉域化PaaSにおいては、DNSが入口制御そのものである。
9. 監査・証跡設計：ログだけではDNS事故を説明できない
この種の事故では、FirewallログやNSGフローログを見ても、原因が見えないことがある。理由は単純で、名前解決に失敗していれば、そもそも通信が発生しないからである。また、名前解決が誤ったIPを返していれば、想定したPrivate Endpoint宛のログには出てこない。
さらに、Private Endpoint宛のトラフィックについても、Microsoft Learnは、NSGフローログではPrivate EndpointへのトラフィックをソースVM側でのみキャプチャでき、Private Endpoint自体ではプラットフォーム制限により記録できないと説明している。
加えて、NSGフローログは2027年9月30日に廃止予定であり、2025年6月30日以降は新規作成できず、MicrosoftはVirtual Network Flow Logsへの移行を推奨している。
Virtual Network Flow Logsでは、NSG規則による許可・拒否だけでなく、Azure Virtual Network Managerのセキュリティ管理者ルールによる許可・拒否、仮想ネットワーク暗号化の状態評価などもサポートされると説明されている。
ただし、どれだけフローログを整備しても、DNSの事前確認を代替することはできない。監査証跡としては、次の三層を分ける必要がある。
第一層：DNS証跡FQDNがPrivate Endpoint IPへ解決されていることを示す Resolve-DnsName、nslookup、dig結果。
第二層：通信証跡解決されたPrivate IPに対して、TCP接続が成立することを示す Test-NetConnection、アプリケーションログ、DB接続ログ。
第三層：統制証跡Private DNS Zoneリンク、Private Endpoint Connection、PaaS側パブリックアクセス制御、変更承認、IaC、運用手順書。
この三層が揃わないと、「閉域化しています」と言っても、監査・取引先説明・委託先管理では弱い。
10. クラウド法務上の問題：これは技術事故であり、説明責任の事故である
この事故を、単なる「DNS設定ミス」と見てはいけない。クラウド法務の観点では、次の文書が実態とずれる可能性がある。
セキュリティ設計書
ネットワーク構成図
運用手順書
委託先との責任分界表
取引先向けセキュリティチェックシート
ISMS・Pマーク・内部監査資料
インシデント対応手順
SOW・運用保守契約
クラウド利用規程
データフロー図
「PaaSはPrivate Endpointで閉域化済み」と記載しているのに、実際には本番VNetからPrivate DNS Zoneを参照できない。この場合、構成図の表現は不正確である。さらに、取引先へ「DBは閉域接続のみ」と回答していた場合、その回答根拠が揺らぐ。
NIST CSF 2.0は、サイバーセキュリティリスクを理解、評価、優先順位付け、コミュニケーションするための高レベルな成果分類を提供し、特定の実現方法を処方するものではないと説明されている。
この観点から見れば、DNS事故は単なるProtectの問題ではない。Govern、Identify、Detect、Respondにまたがる問題である。
Govern：誰がDNS設計を承認し、例外を管理するのか
Identify：どのPaaSが、どのPrivate DNS Zoneに依存するのか
Protect：FQDNをPrivate IPへ解決させ、パブリック経路を制御しているか
Detect：名前解決の異常を検知できるか
Respond：本番障害時に、DNS確認を初動手順に含めているか
Recover：Private Endpoint再作成後にDNSレコードを復旧できるか
山崎行政書士事務所が掲げるクラウド法務×Azure現場伴走は、要件定義から運用、KQL・スクリプトレビュー、契約・文書整備までを一つの流れで支える点に特徴があるとされている。これは、まさに本件のような「技術はあるが、説明できない」事故に対して有効である。
11. 現場で使うべき初動確認手順
PaaS閉域化で「NSGは許可なのに繋がらない」と言われたら、私はまず次の順番で見る。
11.1 まずFQDNを確認する
Resolve-DnsName <server>.database.windows.netまたは、
nslookup <server>.database.windows.net見るべきは、接続先FQDNがPrivate EndpointのプライベートIPに解決されているかである。Azure SQLなら、接続文字列のFQDNは通常 <server>.database.windows.net であり、Private IPやPrivate Link FQDNを直接使わない。
11.2 実行元を変えて確認する
同じFQDNを、次の場所から確認する。
アプリケーション実行環境
同じサブネット内の踏み台VM
Hub VNet
Spoke VNet
オンプレミス端末
dev/stg/prodそれぞれ
DNSは、実行元によって答えが変わる。StorageのPrivate Endpointでも、VNet外から解決するとパブリックエンドポイント、Private EndpointをホストするVNet内から解決するとPrivate Endpoint IPになるとMicrosoft Learnは説明している。
11.3 Private DNS Zoneリンクを見る
確認項目は次である。
本番VNetにリンクされているか
Hub/Spokeの必要なVNetすべてにリンクされているか
自動登録の有無を誤解していないか
dev/stg/prodでリンク差分がないか
Private DNS ZoneにVNetリンクがない場合、そのVNetのリソースはPrivate DNS Zone内のレコードを解決できない。
11.4 AレコードとPrivate Endpoint NIC IPを突合する
確認項目は次である。
AレコードのIP
Private EndpointのNIC IP
Private Endpoint Connectionの承認状態
Private DNS Zone Groupの有無
手動レコードの残骸
TTLとキャッシュ
特に、Private Endpointを削除・再作成した環境では、Aレコードの不整合が起きやすい。
11.5 最後に通信制御を見る
DNSが正しいことを確認してから、NSG、Firewall、ルート、DB側アクセス制御を見る。順番を逆にすると、数時間を失う。
12. 受入テストに入れるべき項目
Private Endpoint化の受入テストは、「接続できた」だけでは足りない。少なくとも次を成果物として残すべきである。
項目 | 確認内容 | 証跡 |
FQDN解決 | 接続先FQDNがPrivate IPへ解決される | Resolve-DnsName 結果 |
VNetリンク | Private DNS Zoneが対象VNetにリンク済み | Azure Resource Graph / ポータル画面 / IaC |
Aレコード | AレコードIPとPrivate Endpoint NIC IPが一致 | DNSレコード一覧・NIC情報 |
接続文字列 | 通常FQDNを使用し、Private IPやprivatelink FQDNを直書きしていない | アプリ設定レビュー |
パブリックアクセス制御 | PaaS側のPublic network accessが方針通り | PaaSネットワーク設定 |
環境差分 | dev/stg/prodのDNS構成差分が説明済み | 差分表 |
ハイブリッドDNS | オンプレDNSやPrivate Resolverの転送が正しい | 条件付きフォワーダー設定 |
ログ | フローログ・PaaSログ・変更履歴が保存される | Log Analytics / Storage / Activity Log |
変更管理 | Private Endpoint再作成時のDNS更新手順がある | 運用手順書 |
責任分界 | DNS・PaaS・Firewall・アプリ設定の担当が明確 | RACI / SOW / 契約別紙 |
これを受入基準にしないと、構築完了後に「本番だけ繋がらない」が再発する。
13. 契約・運用文書に落とすべき条項
クラウド法務としては、技術チェックで終わらせてはならない。次のような文書化が必要である。
13.1 SOW・運用保守契約
Private Endpoint、Private DNS Zone、VNetリンク、DNSフォワーダー、Azure DNS Private Resolver、PaaS側パブリックアクセス制御について、誰が設計し、誰が実装し、誰が変更し、誰が障害時に初動確認するかを明記する。
13.2 責任分界表
DNSは、アプリ、ネットワーク、クラウド基盤、オンプレ基盤、セキュリティ運用の境界に落ちやすい。責任分界表では、「名前解決の責任者」を明示する必要がある。
13.3 変更管理規程
Private Endpoint再作成、Private DNS Zone変更、VNet追加、Hub-Spoke変更、オンプレDNS条件付きフォワーダー変更は、すべて接続障害に直結する。変更管理票には、変更前後の名前解決結果を添付するべきである。
13.4 監査対応資料
「閉域化しています」という説明では足りない。どのFQDNが、どのPrivate DNS Zoneで、どのPrivate IPに解決され、どのVNetから利用されるのかを一覧化する。
13.5 障害対応手順
障害時の初動に、次の一文を入れる。
PaaS閉域接続障害では、NSG・Firewall確認より先に、接続元からFQDNの名前解決結果を取得する。
この一文があるだけで、初動時間は大きく変わる。
14. 山崎行政書士事務所が提供すべき価値
山崎行政書士事務所のクラウド法務の価値は、契約書だけを見ることではない。Azureの構成、DNS、Private Endpoint、ログ、責任分界、監査回答を、同じ粒度でつなぐことにある。
事務所サイトでも、Azure / Microsoft 365 / Entra IDを前提に、アーキテクチャ、運用、証跡、責任分界、越境データを同じ地図で整理する方針が示されている。
この「同じ地図で整理する」という考え方は、DNS事故にそのまま当てはまる。
構成図ではPrivate Endpointがある。設計書では閉域化と書いてある。契約書ではセキュアな接続と書いてある。監査回答ではパブリックアクセスを制限していると書いてある。
しかし、実際の本番アプリから名前解決するとパブリックIPに向いている。または、NXDOMAINになる。または、古いPrivate Endpoint IPを返す。
このとき、文書は実態を説明できない。
山崎行政書士事務所が支援すべきなのは、単なる設定代行ではなく、次の成果物化である。
PaaS閉域化設計書
DNS名前解決経路図
Private Endpoint一覧
Private DNS Zoneリンク一覧
dev/stg/prod差分表
取引先説明用の閉域化説明資料
委託先・SIer向け責任分界表
障害時DNS初動手順
監査証跡チェックリスト
Azure構成と契約条項の整合レビュー
これは行政書士の文書作成・事実証明・契約関連支援の領域と、Azure現場SEとしての実装理解をつなぐ仕事である。ここに、クラウド法務の実務価値がある。
15. 結論：閉域化PaaSは、疎通より先に名前解決を見る
本件の結論は、非常にシンプルである。
NSGがAllowでも、FirewallがAllowでも、FQDNがPrivate IPに解決されなければ、Private Endpoint閉域化は成立しない。
Private Endpointは作れば終わりではない。Private DNS Zoneは作れば終わりではない。VNetリンクは環境ごとに確認しなければならない。AレコードはPrivate Endpointの実体と突合しなければならない。オンプレDNSやカスタムDNSが入れば、条件付きフォワーダーやAzure DNS Private Resolverまで見る必要がある。監査では、通信ログだけでなく、名前解決の証跡まで必要になる。
クラウド閉域化の現場で本当に問われるのは、次の問いである。
そのFQDNは、どこから引くと、どのIPを返すのか
そのIPは、本当にPrivate EndpointのNIC IPなのか
そのPrivate DNS Zoneは、本番VNetにリンクされているのか
dev/stg/prodでDNS構成差分はないのか
パブリックアクセスは設計方針どおり制御されているのか
障害時に、誰がDNSを確認するのか
監査時に、名前解決結果を証跡として出せるのか
通信制御だけでは足りない。名前解決まで設計せよ。
山崎行政書士事務所のクラウド法務・Azure技術支援は、この「技術的に繋がる」と「法務・監査で説明できる」の隙間を埋めるための支援である。PaaS閉域化を、単なるPrivate Endpoint作成ではなく、DNS、ログ、責任分界、契約、監査証跡まで含めた説明可能な統制へ変える。そこに、技術と法務を架橋する専門性がある。
コメント