サイバーセキュリティ研究者は、Microsoft Azure の Private Endpoint 実装における重大なアーキテクチャ上の脆弱性を発見しました。意図しない DNS 解決の挙動により、クラウドリソースがサービス拒否（DoS）攻撃にさらされる可能性があります。
この発見は Azure ストレージアカウントの 5% 以上に影響し、Key Vault、CosmosDB、Azure Container Registry、Function Apps、OpenAI アカウントなどの主要サービスにも及びます。
Azure Private Link は、パブリックインターネットではなく Microsoft のバックボーンネットワークを介して Azure リソースへ安全に接続できるようにします。
組織が Private Endpoint をデプロイすると、Azure は標準の DNS 解決を上書きする Private DNS ゾーンを作成します。
たとえば、ストレージアカウントのパブリックエンドポイント（mystorageaccount.blob.core.windows.net）は通常、Microsoft が所有するパブリック IP アドレスに解決されます。
Private Link では、Azure は Private DNS ゾーン（privatelink.blob.core.windows.net）を優先し、Private Endpoint 経由の解決を強制します。
このアーキテクチャは 3 つのデプロイモデル（パブリックのみのアクセス、プライベートのみのアクセス、一部のワークロードが Private Endpoint を使用し他はパブリックアクセスを維持するハイブリッド構成）をサポートします。脆弱性は特にハイブリッド環境に影響します。
DoS 状態は従来のネットワーク攻撃ではなく、Azure の DNS 解決ロジックから生じます。
サービス種別（例：Blob ストレージ）の Private DNS ゾーンが仮想ネットワークにリンクされると、個々のリソースに Private Endpoint が構成されているかどうかに関係なく、Azure はそのサービスに対するすべての解決を Private DNS ゾーン経由に強制します。
仮想ネットワーク A の Function App が、ネットワーク ACL により許可されたパブリックエンドポイント経由でストレージアカウントにアクセスしているケースを考えます。
管理者、ベンダー、または攻撃者が仮想ネットワーク B でそのストレージアカウントの Private Endpoint を作成すると、Azure は自動的に Private DNS ゾーンを生成します。
そのゾーンが仮想ネットワーク A に、直接またはネットワーク間共有を通じてリンクされると、DNS 解決経路が変わります。
元のストレージアカウントに対する A レコードが Private DNS ゾーン内に存在しないため、解決は完全に失敗します。
ストレージアカウントのパブリックエンドポイントが稼働しておりアクセス可能であっても、Function App は接続できません。
この脆弱性は 3 つの異なるシナリオで顕在化します。
偶発的な内部デプロイ：セキュリティ強化のためにネットワーク管理者が Private Endpoint をデプロイすると、対応する Private Endpoint を持たない他の仮想ネットワークにある依存関係を意図せず破壊してしまう可能性があります。
偶発的なベンダーデプロイ：リソーススキャンのために Private Endpoint をデプロイするサードパーティのセキュリティソリューションが、警告なしに顧客環境全体で広範な障害を引き起こす可能性があります。
悪意ある攻撃：Azure 環境へのアクセスを持つ脅威アクターは、Private Endpoint を戦略的にデプロイすることでこの挙動を武器化し、重要リソースに対して標的型の DoS 状態を作り出すことができます。
調査によれば、現在 5% 以上の Azure ストレージアカウントが脆弱なハイブリッド構成で運用されています。
波及効果は甚大になり得ます。ストレージアカウントへのアクセスが遮断されると、Azure Functions の実行が妨げられ、アプリケーション更新が中断され、Key Vault へのアクセスが失われ、依存するプロセス全体に障害が連鎖します。
Microsoft はドキュメント内でこの「二者択一の性質」という制約を認めており、部分的な緩和策を提示しています。
「インターネットへのフォールバック」オプションにより、Private DNS ゾーンに一致するレコードがない場合に DNS リゾルバがパブリック解決を使用できますが、これは Private Link の中核的なセキュリティ価値を損ないます。
手動でレコードを作成することも別の回避策ですが、大規模では維持不能な運用負荷を生みます。
セキュリティチームは Azure Resource Graph クエリを使用して脆弱な構成を特定できます。あるクエリは Blob ストレージの Private DNS ゾーンにリンクされた仮想ネットワークを特定し、別のクエリはパブリックアクセスが有効である一方で Private Endpoint 接続がないストレージアカウントを見つけます。これらのクエリは、Private Link がサポートする他のサービスにも適用できます。
防御側は、Private Endpoint をデプロイする前に、ネットワーク間の依存関係をマッピングする包括的なディスカバリプロセスを実装すべきです。
ネットワークログは、Azure リソース間の通信パターンの特定に役立ちます。本番環境では、組織は Private Link を二者択一の判断として扱うべきです。すなわち、プライベートのみのアクセスに完全にコミットするか、明確なパブリックのみのアーキテクチャを維持し、曖昧なハイブリッド状態を避けることです。
Palo Alto Networks の顧客は、Cortex Cloud のランタイムセキュリティエージェントおよび Unit 42 Cloud Security Assessment サービスにより追加の保護を得られます。これらは誤設定を特定し、この脆弱性を悪用し得る悪意ある構成変更を検知します。