Azure の Private Endpoint デプロイメントに深刻な脆弱性：クラウド・リソースへの DoS 攻撃の可能性

Azure Private Endpoint Deployments Expose Cloud Resources to DoS Attacks

2026/01/21 gbhackers — Azure の Private Endpoint デプロイメントにおける深刻なアーキテクチャ上の弱点により、クラウド・リソースに対する偶発的／意図的なサービス拒否 (DoS) 攻撃が可能になる。この脆弱性は、Azure の Private DNS ゾーン解決とハイブリッド・ネットワーク・コンフィグとの相互作用に起因し、Azure Storage Account の 5% 超と、複数の重要サービスに影響を及ぼす可能性がある。

中核となる脆弱性

この問題は、Azure Private Link の二元的な設計思想から発生する。Azure リソースである、Storage Account／Key Vault／CosmosDB インスタンスなどに対して Private Endpoint を作成すると、対応する Private DNS ゾーン (例：privatelink.blob.core.windows.net) が仮想ネットワークに自動的にリンクされる。

Azure の DNS 解決エンジンは、この Private DNS ゾーンを優先し、すべての該当する名前解決を、パブリック DNS インフラではなく Private DNS ゾーン経由に強制する。

特定の仮想ネットワーク (VNET2) に Private Endpoint が存在する状況で、他の仮想ネットワーク (VNET1) が同一リソースへパブリック・エンドポイント経由でのアクセスを必要とする場合に、この問題は顕在化する。

Private DNS ゾーンが、仮想ネットワーク間でリンクまたは共有されていると、Azure の解決ロジックにより、VNET1 のトラフィックも Private DNS ゾーン経由に強制される。

しかし、そのゾーン内には、該当 Storage Account の DNS A レコードが存在しないため、名前解決が失敗 (NXDOMAIN など) し、これまで正常に動作していたワークロードが事実上のサービス拒否状態に陥る。

攻撃ベクターとシナリオ

この脆弱性が成立する、デプロイメント・シナリオは以下の 3 つである。

• 偶発的 (内部)：ネットワーク管理者がセキュリティ強化のために Private Endpoint をデプロイし、共有インフラを通じて Private DNS ゾーンを、複数の仮想ネットワークに誤ってリンクする。
• 偶発的 (ベンダー)：サードパーティ・ベンダーがセキュリティ・ソリューションや監視ツールの一部として Private Endpoint をデプロイし、環境全体に DNS 解決問題が連鎖的に広がる。
• 悪意 (攻撃者)：Azure 環境へのアクセス権を持つ脅威アクターが、Key Vault や Function Apps などの高価値リソースを標的として、サービス可用性を妨害する目的で意図的に Private Endpoint をデプロイする。

この脆弱性により、Azure サービス全体に連鎖的な障害が引き起こされる。Storage Account への DoS は、Azure Functions や後続のアプリケーション・デプロイメントを阻害する。Key Vault を標的とした DoS では、対象となるプロセスが、暗号鍵やシークレットにアクセスできなくなる。

Palo Alto Networks によると、CosmosDB／Azure Container Registry／Function Apps／OpenAI アカウントも同様の影響を受けるという。同社による調査の結果では、多くの Azure 環境において、これらのサービスにまたがり、少なくとも 1 つの脆弱なリソースが存在することが示されており、組織全体に広範なリスクが生じていると分析されている。

検出と緩和の戦略

Azure Resource Graph クエリ：セキュリティ・チームは、事前に定義された Resource Graph Explorer クエリを使用して、脆弱なコンフィグを特定できる。

・対応するリソースを持たない Private DNS ゾーンにリンクされた仮想ネットワーク
・Private Endpoint 接続がない状態で、パブリック・エンドポイント・アクセスが有効化された Storage Account
・ネットワーク ACL 制限付きでパブリック・ネットワーク・アクセスを許可しているリソース

この問題が、既知の制限であることを Microsoft は認識している。

部分的な解決策は 2 つ存在する。1 つ目は、仮想ネットワーク・リンク作成時にインターネット DNS へのフォールバックを有効化する方法であるが、これは Private Link のセキュリティ目的と矛盾する。2 つ目は、影響を受けるリソースの DNS A レコードを Private DNS ゾーンに手動で追加する方法であるが、本番環境での運用負荷が高い。

ユーザー組織にとって必要なことは、Resource Graph クエリを用いて Azure 環境全体を包括的にスキャンし、Private Link コンフィグを可視化することである。

適切な場合には DNS フォールバック解決を実装し、重要リソースに対しては手動の DNS レコード管理と組み合わせて運用する。また、DNS 解決失敗を示すネットワーク ログを監視し、攻撃の兆候を検出する必要がある。

Azure のネットワーク機能 Private Link において、クラウド上の重要なリソースが突然使えなくなる、深刻な設計上の弱点が見つかりました。この問題の原因は、Azure の名前解決 DNS の仕組みが、パブリック設定よりもプライベート設定を無条件に優先してしまうことにあります。

具体的には、あるリソースに Private Endpoint を作成すると、Azure 内部では、今後において対象リソースをプライベート IP アドレスで呼び出すという、Private DNS ゾーンが自動的に作られます。問題は、複数のネットワークが、この Private DNS ゾーン共有している場合です。特定のネットワークでしか使用できないプライベート設定が、他のネットワークにも強制され、結果としてこれまでパブリック経由で通信できていた他のシステムが、リソースを見つけられずに通信不能 (DoS：サービス拒否) に陥ってしまいます。ご利用のチームは、文中の “検出と緩和の戦略” をご参照ください。