DNS OverDoS: プライベート エンドポイントはプライベートすぎるのか？

エグゼクティブ サマリー

AzureのPrivate Endpointアーキテクチャに、Azureリソースがサービス拒否(DoS)攻撃にさらされる可能性があることが弊社の調査で明らかになりました。本記事では、意図的な行為と不注意な行為の両方が、Azureプライベート リンクの仕組みを通じて、Azureリソースへのアクセスを制限する結果になる可能性があることを探ります。この問題は、Azureのテスト環境における不規則な動作を調査している際に発見されたものです。

リスクは以下の3つのシナリオで存在します。

• 事故 - 内部: あるネットワーク管理者が、Azure環境内のネットワーク セキュリティを向上させるためにプライベート・エンドポイントを導入した。
• 事故 - ベンダー: サードパーティ ベンダーは、例えばセキュリティ製品によるリソースのスキャンを可能にするために、そのソリューションの一部としてプライベート エンドポイントを導入することがあります。
• 悪意 - 攻撃者: Azure 環境にアクセスした脅威アクターは、DoS 攻撃の一環として意図的にプライベートエンドポイントを展開します。

弊社の調査によると、現在Azureストレージ アカウントの5％以上が、このDoS問題の対象となる構成で運用されています。ほとんどの環境では、以下の各サービスの少なくとも1つのリソースが影響を受けやすいです。

• Key Vault
• CosmosDB
• Azure Container Registry (ACR)
• Function Apps(関数アプリ)
• OpenAIアカウント

この問題は、さまざまな形で組織に影響を与える可能性があります。たとえば、ストレージ アカウントへのサービス拒否は、FunctionApps内のAzure Functionsおよびこれらのアプリへのその後の更新を失敗させる可能性があります。別のシナリオでは、このリスクはKey VaultへのDoSにつながる可能性があり、その結果、Key Vault内のシークレットに依存するプロセスに波及します。

Microsoftは、プライベート エンドポイントに関連するこの問題およびその他の既知の問題を部分的に解決するインターネットへのフォールバックに関するアドバイスを提供しています。

弊社はこれらの問題を議論し、潜在的な解決策を提供するとともに、DoS攻撃を受けやすいリソースを防衛側が環境をスキャンする方法を提案しています。

パロアルトネットワークスのお客様は、以下の製品を通じて、本書で取り上げるツールに対する確実な保護を構築いただけます。

• Cortex Cloud

Unit 42 クラウド セキュリティ評価は、組織のクラウド インフラストラクチャを検証し、設定ミスやセキュリティ上の弱点を特定する戦略的評価サービスです。これにより、チームはクラウドベースの脅威に対する防御態勢を強化できます。

侵害を受けている可能性がある場合、または緊急を要する場合は、Unit 42インシデント レスポンス チームまでご連絡ください。

Azureプライベート リンク キーのコンポーネント、コンセプト、フロー

Azureのネットワーク サービスの一環として、MicrosoftはAzure Private Linkを開発しました。この仕組みは、Azureのバックボーン ネットワークを使用して、サポートされるAzureリソースやAzureがホストするカスタムサービスに接続するプライベートで安全な方法を提供するものです。

定義付け

本ソリューションと、それを使ったリソースのセキュアな接続プロセスの理解にむけて、まず主要なコンポーネントとコンセプトを定義します。

• サービス: 接続先となる宛先
• プライベートリンク: 接続を許可し、処理するAzureの実装
• プライベート エンドポイント: サービスとの接続を可能にする、顧客の仮想ネットワーク内のネットワーク インターフェース
• プライベートDNSゾーン: プライベート エンドポイントで使用されるデフォルトのドメイン ネーム システム(DNS)サービス
• 仮想ネットワークリンク: プライベートDNSゾーンと仮想ネットワークの間にデフォルトで作成されるリンク
• DNS Aレコード: ドメインまたはホスト名をIPアドレスにマッピングするDNSレコード
• ネットワークACL: ネットワーク アクセス制御リスト(ACL)は、プライベート リンク ソリューションとは別に、サービスへのトラフィックを許可または制限するルールを定義します。

Azureリソースはデフォルトでパブリック エンドポイントを公開します。これらのエンドポイントは、標準的なDNSインフラ(パブリックなAzure DNS、または顧客が管理するDNSリゾルバ)を通じて解決されます。クライアントがmystorageaccount.blob.core.windows[.]netなどのサービス名を照会すると、DNSリゾルバはMicrosoftが所有するパブリックIPアドレスを返します。IPアドレスは、適用されているネットワーク アクセス制御に応じて、パブリック インターネットまたはAzureサービスエンドポイント経由での接続を可能にします。

Azure Private Linkが導入されると、DNS解決の動作が変わります。プライベートDNSゾーン(例えば、privatelink.blob.core.windows[.]net)は、1つまたは複数の仮想ネットワークにリンクできます。仮想ネットワークが特定のサービスタイプのプライベートDNSゾーンへのリンクを持つ場合、AzureのDNS解決ロジックは、一致するサービス名を解決する際にそのゾーンを優先します。一致するレコードが存在する場合、名前はパブリック エンドポイントではなく、プライベート エンドポイントのプライベートIPアドレスに解決されます。

組織は一般的に、以下のいずれかのアーキテクチャを導入しています。

• 一般公開のみのアーキテクチャ: リソースには、パブリック エンドポイントと標準的なDNS解決を使ってアクセスします。ネットワークACL、ファイアウォール、またはサービス エンドポイントがアクセス コントロールを担います。
• プライベート専用アーキテクチャ: リソースへのアクセスはすべてプライベート エンドポイントを通じて行われます。パブリック ネットワーク アクセスは無効化され、DNS解決はプライベートDNSゾーンによって完全に制御されます。
• ハイブリッド アーキテクチャ(パブリック&プライベート): 仮想ネットワークやワークロードの中には、プライベート エンドポイントを介してリソースにアクセスするものもあれば、パブリック エンドポイントを使い続けるものもあります。このモデルは、移行、段階的なロールアウト、サードパーティとの統合、共有サービス環境などで頻繁に使用されます。

ストレージ アカウントを例に、Azureネットワーキングでプライベート エンドポイントがどのように使用されるかを説明します。ただし、プライベート リンクがサポートするサービスには、同じ概念が適用されます。デフォルトでは、ネットワーク管理者または適切なAzureロールベースアクセス制御(RBAC)権限を持つユーザーがリソースにリンクされたプライベート エンドポイントを作成すると、プライベート エンドポイントと同じ仮想ネットワークへの仮想ネットワークリンクを持つプライベートDNSゾーンが作成されます。

DNSゾーンの名前は、プライベート エンドポイントの宛先サービスに基づいて事前定義された構造を持ちます(例: Blobストレージの場合は

)。さらに、DNSゾーンにAレコードが作成され、宛先リソース名とプライベート エンドポイントのIPアドレスがリンクされます。

仮想マシンVMとストレージ アカウントをNetwork ACLで接続するには、2つの方法があります。

• プライベート エンドポイントなし(パブリック エンドポイントまたはサービス エンドポイントを使用）
• プライベート エンドポイントあり

接続フロー

図1は、プライベート リンク ソリューションを使用しないリソースへの接続方法を示したものです。

この場合の接続フローは以下のようになります。

1. ストレージ アカウントにアクセスしようとすると、VMはアカウント名をIPアドレスに解決しようとする。これは通常、外部のDNSリゾルバを介して発生し、トラフィックは公衆インターネットを横断します。
2. リゾルバがストレージアカウントのレコードを持っていれば、対応するIPアドレスを返します。
3. アドレスが取得されると、VMはストレージ アカウントへの接続を試みます。
4. その後、ストレージアカウントは仮想マシンのIPアドレスをネットワークACLに照らして評価します。接続が許可された場合、ストレージアカウントは要求された情報を応答します。

図2は、プライベート エンドポイントを使用した場合に、同じ接続がどのように行われるかを示したものです。

1. 最初に、VMはアカウント名をIPアドレスに解決しようとします。プライベート リンク サービスを指すプライベートDNSゾーンへの仮想ネットワークリンクが仮想ネットワーク(VNET)内に存在する場合、Azureのプライベート リンク機構はプライベートDNSゾーンを使用して強制的に解決します。これは、接続先が同じタイプのプライベート リンク サービス(ブロブ ストレージなど)である場合に発生します。
2. DNSリゾルバが一致するAレコードを特定すると、対応するIPアドレスがVMに提供されます。
3. その後、VMはプライベート エンドポイントに属するIPアドレスに接続します。
4. プライベート エンドポイントは、ストレージ アカウントのネットワーク インターフェイスとして機能し、トラフィックを評価し、ストレージ・アカウントに転送します。
5. ストレージ アカウントがリクエストを評価し、プライベート・リンク・ソリューションを通じてレスポンスを提供します。
6. 応答はVMに提示され、VMは基本的にAzureのバックボーン ネットワークを使ってストレージ アカウントにアクセスします。

プライベート リンクDNSの潜在的危険性

上記のように、プライベートDNSゾーンが設定された仮想ネットワークからプライベート リンク サービスを利用する場合、プライベートDNSゾーンを介した解決が強制されます。

VNET1のVM1が、パブリック エンドポイントを使用してストレージ アカウントへのアクセスに成功した環境を考えてみましょう。DNS解決はデフォルトのパブリックDNSインフラを通して行われ、アクセスはストレージ アカウントのネットワークACLによって許可されます。この段階では、ワークロードは正常に動作しています。

その後、VNET2のストレージ アカウントに対して、意図的、偶然、またはサードパーティのデプロイメントによって、プライベート エンドポイントが作成されます。このプロセスの一環として、ブロブストレージ用のプライベートDNSゾーン(privatelink.blob.core.windows[.]net)がVNET1にリンクされるか、仮想ネットワーク全体で共有されます。

このDNSゾーンがリンクされると、AzureのDNS解決ロジックは、VNET1内のすべてのブロブ ストレージの名前解決をプライベートDNSゾーン経由で強制します。しかし、VNET1のコンテキスト内のストレージアカウントのゾーンには「A」レコードが存在しないため、DNS解決は失敗します。VM1はストレージ アカウントのホスト名を解決できなくなり、接続できなくなります。パブリック エンドポイントはアクセス可能で変更されていないにもかかわらずです。

このコンフィギュレーション変更により、以前は正常に機能していたVNET1のワークロードに対して、実質的にサービス拒否状態が発生します。サービス停止は、ターゲット リソース自体に変更を加えることなく、Private Link構成によって導入されたDNS解決の副作用によってのみトリガーされます。

図3はこの例を示したものです。

上の図は、ストレージ アカウントに接続しようとするVM1を示したものです。このストレージ アカウントはVNET2にプライベート エンドポイントを持ち、VNET1にプライベート エンドポイントを持ちません。仮説として、VM1がストレージ アカウントのパブリック エンドポイントを使用して接続を試みる可能性があります。これは、VMの仮想ネットワークに同じリソースタイプに解決するプライベートDNSゾーンがない場合に機能します。しかし、この場合、プライベートDNSゾーンとサービスはプライベート リンクに登録されているため、プライベート リンクはプライベートDNSゾーンを介して強制的に解決を試みます。

図3に示すプロセスは次のように行われます。

1. プライベート リンクはVNET1のブロブ ストレージ プライベートDNSゾーンを認識し、ストレージ アカウントがプライベート リンクに登録されていることを識別します。プライベート リンクは、プライベートDNSゾーンを介してDNS解決を強制します。
2. 図3の構成では、VNET1にリンクされたプライベートDNSゾーンにストレージアカウントのレコードが作成されていません。そのため、仮想マシンはサービスを解決できません。
3. ステップ2のDNS解決の問題により、その後のステップ(VM1がストレージ アカウントにリクエストを送信し、そこからレスポンスを受信するステップ)は発生しません。

このシナリオでは、部分的なサービス拒否が発生します。ストレージ アカウントにアクセスしようとするVNET1のリソースはアクセスできません。

このリスクは、ローカルのDNSリゾルバを使用する場合にも、設定や追加されるレコードによっては存在する可能性があります。さらに、この例は特にBlobストレージに関連していますが、Azure Private Linkをサポートするあらゆるサービスが潜在的なリスクにさらされる可能性があります。

軽減策と推奨事項

Azure Private Linkはもともと、完全に有効にするか無効にするかのバイナリ ソリューションとして意図されていました。サービスが意図した通りに実装されている場合、ユーザーはPrivate Linkを使用するリソースに、それらのリソースのプライベート エンドポイントを通じてのみアクセスできます。このアプローチでは、プライベート、パブリック、サービスのエンドポイントを組み合わせて使用する必要はありません。ただし、Azureストレージ アカウントの5% 以上がこの問題の影響を受ける構成となっているため、これらの実装によって生じるリスクに対処するソリューションを提供する必要性を認識しています。

緩和策

Microsoftは、この解決策の二進法的な性質が既知の問題であることを認め、そのことを自社のドキュメントに記載しています。.Microsoftは部分的な解決策も提供しており、それは仮想ネットワークリンクを作成する際に、インターネットへのフォールバックオプションを有効にすることです。このフォールバック ソリューションを使用すると、DNSリゾルバが要求されたサービスに一致するレコードを見つけられない場合、パブリック インターネットにフォールバックされます。このソリューションは問題を解決しますが、パブリック インターネットではなくAzureのバックボーン ネットワークを横断するというAzure Private Linkの主要コンセプトとは必ずしも一致するものではありません。

2つ目の部分的な解決策は、必要なプライベートDNSゾーンに影響を受けるリソースのレコードを手動で追加することです。このオプションは、運用上のオーバーヘッドが増えるため、大規模な本番環境にはあまり適していません。

フォールバックも手動でのレコード追加も決定的な解決策ではありませんが、上記のアプローチと包括的なディスカバリを組み合わせることで、影響を受けるコンフィギュレーションのマッピング、発見、修復に役立てることができます。

包括的なディスカバリとスキャン

潜在的にリスクのあるリソースをスキャンして特定するには、2つの方法があります。

1. 各サービスで個別にリソースをスキャンする
2. Azure Resource Graph Explorerを使用する

2番目のスキャン方法はより効率的で、ほとんどのリソースタイプに適合するように簡単に変更することができます。弊社では、ブロブ ストレージのプライベートDNSゾーン(privatelink.blob.core.windows[.]net)にリンクされている環境内のすべての仮想ネットワークのリストを取得するグラフクエリを作成しています。これらの仮想ネットワークは、Private Linkに登録されたリソースと通信する際、プライベート エンドポイント経由でBlobストレージ リソースを解決する必要があります。

さらに、プライベート エンドポイント接続を持たないブロブ ストレージ リソースと相互作用する仮想ネットワークを特定することも重要です。そのために弊社は以下のクエリを作成しました。このクエリは、パブリック エンドポイントへのアクセスを許可し、プライベート エンドポイント接続を持たないストレージ アカウントを検索します。

このクエリは、許可された仮想ネットワークを特定し、特定のIPアドレスを許可するリソースも検索するものです。仮想ネットワークのDNSコンフィギュレーションの可視性が限られていて、コンフィギュレーションが影響を受けているかどうかを判断するのが難しい場合に有効です。

防御担当者は、ネットワークACLを持たないリソースであってもリスクにさらされる可能性があることに注意すべきです。しかし、そのようなリソースと通信しようとする仮想ネットワークがあったとしても、それを決定するためにコンフィギュレーションを使用する方法はありません。このリスクに対処するには、ネットワークログを使用して、Azureネットワーク範囲から影響を受けやすいリソースへの接続を特定します。

防御担当者は、上記のリソースクエリでリソースとプライベートDNSゾーンの詳細を変更して照合し、危険にさらされているプライベートリンク対応リソースを検出することができます。

結論

Azure Private Linkの制限を完全に理解することは、それに依存するネットワークを保護するうえで不可欠です。コンポーネントとアーキテクチャの特定の構成では、Azure Private Linkのバイナリの性質によって接続性が失われ、場合によってはDoS攻撃が可能になる可能性があります。

このリスクに対してプライベート・エンドポイントを保護するために考えられるソリューションには、以下の2つがあります。

• パブリックDNS解決へのフォールバックを有効にする
• 影響を受けるリソースのDNSレコードを手動で追加する

防御担当者は、リソースを照会し、包括的なネットワーク スキャンを実施してリスクのあるリソースを特定し、必要な保護を実施することで、これらのソリューションの有効性を高めることができます。

パロアルトネットワークスの保護と緩和策

パロアルトネットワークスのお客様は、以下の製品を通じて、本書で取り上げるツールに対する確実な保護を構築いただけます。

• Cortex Cloudの利用者は、Cortex Cloudの適切な配置によって、この記事で説明したAzureプライベートエンドポイントの悪用から保護されます。XDR エンドポイント エージェントと サーバーレス エージェントをクラウド環境内に適切に配置することで、この記事で説明したようなエクスプロイト保護されます。Cortex Cloudは、この種の脅威からクラウド体制とランタイム オペレーションを保護するように設計されている。この記事で取り上げた悪意のある操作や設定の変更、エクスプロイトの検出と防止に役立ります。

Unit 42 クラウド セキュリティ評価は、組織のクラウド インフラストラクチャを検証し、設定ミスやセキュリティ上の弱点を特定する戦略的評価サービスです。これにより、チームはクラウドベースの脅威に対する防御態勢を強化できます。

情報漏えいの可能性がある場合、または緊急の案件がある場合はUnit 42インシデント レスポンス チームまでご連絡ください。

• 北米: フリーダイヤル: +1 (866) 486-4842 (866.4.UNIT42)
• 英国: +44.20.3743.3660
• ヨーロッパおよび中東: +31.20.299.3130
• アジア: +65.6983.8730
• 日本: +81.50.1790.0200
• オーストラリア: +61.2.4062.7950
• インド: 000 800 050 45107

Palo Alto Networksは、本調査結果を Cyber Threat Alliance (CTA)のメンバーと共有しています。CTAの会員は、このインテリジェンス情報を利用して、その顧客に対して迅速に保護をデプロイし、悪意のあるサイバー アクターを組織的に阻止しています。サイバー脅威アライアンスについて詳細をご確認ください。

その他の資料

• Azureプライベート エンドポイントのプライベートDNSゾーン値 – Microsoftのドキュメント
• Azureプライベート リンクの可用性 - Microsoftのドキュメント
• Azure Resource Graph Explorer - Microsoftのドキュメント
• ​プライベート エンドポイントを持つ仮想ネットワークにおけるクライアントのストレージ アクセス制約 - Microsoftのドキュメント