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