Microsoft Azureのプライベート エンドポイント実装における微妙な設計上の制約が、セキュアな接続のためにPrivate Linkに大きく依存するクラウド環境に、予期しないサービス拒否（DoS）リスクを生み出しています。
複数の仮想ネットワーク（VNET）にまたがるプライベート エンドポイントとプライベートDNSゾーンに関するAzureのDNS挙動は、名前解決を破綻させ、サービスとそのパブリック エンドポイントが依然として機能している場合でも停止を引き起こす可能性があります。
この欠陥は「…Azureリソースをサービス拒否（DoS）攻撃にさらす可能性がある」と、Palo Alto NetworksのUnit 42の研究者が述べています。
Azureプライベート エンドポイントのDNS問題の内側
この問題の核心は、プライベートDNSゾーンが仮想ネットワークにリンクされると、AzureがDNS解決をどのように優先するかにあります。
プライベート エンドポイントは、AzureサービスにプライベートIPを割り当て、Azureのバックボーン経由でアクセスをルーティングすることで、トラフィックをパブリック インターネットに出さないように設計されています。
それをシームレスに機能させるために、Azureは privatelink[.]blob[.]core[.]windows[.]net のようなプライベートDNSゾーンを利用して、サービスのホスト名を正しいプライベート アドレスに変換します。
標準的なデプロイでは、そのDNSゾーンに必要なレコード（通常はAレコード）が含まれており、接続されたネットワーク内のワークロードは、サービス名をパブリック エンドポイントではなくプライベート エンドポイントのIPに解決します。
問題は、同じプライベートDNSゾーンが複数のVNETに拡張されたときに始まります。特に、すべてのネットワークが同一のプライベート エンドポイントのカバレッジを持つわけではない、ハブ＆スポークやセグメント化された環境で顕著です。
一般的な失敗パターンは次のとおりです。
- VNET2にプライベート エンドポイントが作成され、Azureがそのエンドポイントに紐づくプライベートDNSゾーンを生成または使用します。
- その後、ネットワーク間で名前解決を有効にするために、プライベートDNSゾーンがVNET1にリンクされます。
- しかしVNET1には、対象のストレージ アカウント（または他のサービス）に対応するDNS Aレコードがありません。
このリンクが設定されると、VNET1のAzure DNSは、そのホスト名の解決にプライベートDNSゾーンを優先するようになります。
レコードが存在しない場合、ルックアップはNXDOMAINのような応答で失敗し、名前をまったく解決できないことを意味します。
その結果、VNET1内のワークロードが突然アクセスを失うというサービス拒否（DoS）状態になります。基盤となるAzureリソースは健全で、パブリック エンドポイントも変わっておらず、ファイアウォール ルールにも手が加えられていないにもかかわらずです。
この問題が特に破壊的なのは、停止の原因がリソースを攻撃者がダウンさせたり、サービス自体の本番設定を変更したりすることではなく、完全にDNSの挙動に起因している点です。
VNETリンクやゾーンの関係を少し変更するだけで、環境全体の接続性が数秒で崩れる可能性があります。
研究者は、この弱点が典型的に次の3つの実環境シナリオで現れることを見いだしました。
- 偶発的な内部の誤設定: チームが時間をかけてプライベート エンドポイントのカバレッジを拡大する過程で、複数ネットワーク間でゾーンをリンクする際に意図せずDNSの競合を持ち込んでしまう。
- サードパーティのデプロイ: セキュリティ ベンダーやマネージド サービスが、スキャン、監視、統合目的でプライベート エンドポイントを展開し、意図せずDNS挙動を変えて本番トラフィック フローを妨げてしまう。
- 悪意ある内部者または侵害された管理者の活動: 十分なAzure権限を持つ攻撃者が、プライベート エンドポイントとDNSゾーンのリンクを武器化して意図的にアクセスを遮断し、トラフィックを氾濫させたり対象リソースを直接悪用したりせずにDoS事象を作り出せる。
影響は単一の停止にとどまらず連鎖する可能性があります。Azure Storageは、Azure Functions、CI/CDパイプライン、そして構成や状態のためにBlobに依存するアプリケーションなど、多くのサービスの基盤となっているためです。
DNS障害がストレージへのアクセスを遮断すると、停止は連鎖します。関数が失敗し、デプロイが停滞し、Key Vaultのシークレットやコンテナ成果物に依存するシステムが壊れる可能性があります。
Azureプライベート エンドポイントのDNS障害を緩和する
組織は、このPrivate LinkのDNSリスクを避けられないものとして受け入れる必要はありません。
DNSガバナンス、アクセス制御、監視を適切に組み合わせることで、解決失敗が停止に発展する可能性を低減できます。
- プライベートDNSゾーンのVNETリンクで「インターネットへのフォールバック」（NxDomainRedirect）を有効化し、NXDOMAIN障害が解決を破綻させるのを防ぎつつ、パブリック エンドポイントへのフォールバックを許容することによるセキュリティ上のトレードオフを評価する。
- リンクされたネットワーク全体で、Private Link有効化リソース向けのプライベートDNS Aレコードを完全かつ正確に維持し、停止を引き起こし得る解決ギャップを回避する。
- Azure Private Resolverまたは条件付きフォワーディングを備えたカスタムDNSサーバーを用いて、プライベート エンドポイントの名前解決を集中管理・標準化し、マルチVNETおよびハイブリッド環境における privatelink.* ゾーンを扱う。
- 最小権限のRBACを用いて、プライベート エンドポイントの作成やプライベートDNSゾーンおよびVNETリンクの変更ができる人物を制限し、DNSとPrivate Link構成更新に変更管理を追加する。
- プライベートDNSゾーンのリンクを必要なVNETのみに限定し、適切に環境やワークロードごとにDNSゾーンを分離して、影響範囲（ブラスト半径）を縮小する。
- Azure Policy、リソース グラフ クエリ、危険なリンク変更やNXDOMAIN急増に対するアラートを用いて、プライベート エンドポイントとプライベートDNSの変更を継続的に監査し、監視する。
これらの統制を総合的に実施することで、組織はPrivate Linkのデプロイを安全に保ちながら、DNS起因の停止リスクを低減できます。
Private LinkはDoSのような障害を引き起こし得る
この問題は、クラウドのセキュリティ制御が、規律あるDNS設計とガバナンスと組み合わされていない場合、可用性リスクを持ち込み得ることを思い起こさせます。
Azure Private Linkはパブリック露出を減らしますが、「オール・オア・ナッシング」のDNS挙動により、レコードの欠落や広範なゾーンリンクがDoSのような停止を引き起こす可能性があります。
より強い分離と運用レジリエンスのバランスが重要であるため、組織はネットワーク層の前提だけに依存せずにアクセスを保護するゼロトラスト ソリューションへと目を向けています。
