本ブログは、Improved Guidance for Azure Network Service Tags の抄訳版です。最新の情報は原文を参照してください。
概要
Microsoft Security Response Center (MSRC) は、2024 年 1 月に業界パートナーである Tenable 社 から、サービス タグ機能を使用した Web リソースへのテナント間アクセスの可能性について通知を受けました。マイクロソフトは、Tenable 社がサービスタグの使用方法とその意図された目的を誤解されやすいことを強調することで、Azure コミュニティに貴重な貢献に感謝します。マイクロソフトは当初、この脆弱性を確認し、Tenable 社の貢献に対して報奨金を支払いましたが、Tenable 社のレポートをさらに調査した結果、サービスタグは設計どおりに機能し、Tenable 社とのフォローアップのやり取りで伝えたように、サービスドキュメントを通じてベストプラクティスを明確に伝える必要があることがわかりました。
テナント間アクセスは認証によって防止されるため、認証が使用されない場合のみ問題が生じます。ただし、このケースでは、受信ネットワーク トラフィックを検査するための 1 つのメカニズムとしてサービス タグを使用することに固有のリスクが浮き彫りになっています。 サービス タグはセキュリティ境界として扱われず、検証コントロールと組み合わせたルーティング メカニズムとしてのみ使用する必要があります。 サービスタグの悪用や乱用は、第三者によって報告されておらず、マイクロソフトの調査でも確認していません。
従来通り、ネットワーク トラフィックの監視や認証など、リソースに複数のセキュリティ レイヤを使用することを強く推奨します。Tenable 社のレポートを受けて、お客様にサービスタグの機能をお知らせするため、ドキュメントを更新しました。
このサービス タグ ドキュメント の更新の目的は、サービス タグとその機能に関するお客様の理解を深めることです。そのため、お客様によるアクションの必要はなく、Azure Portal でも追加のメッセージを提供しません。ただし、マイクロソフトでは、サービス タグの使用を積極的に見直し、サービス タグの信頼できるネットワーク トラフィックのみを認証するようにセキュリティ対策を検証することを強く推奨します。
技術的な詳細
サービス タグは、多くの Azure サービスの IP 空間のブロックを表す便利な方法です。リソースでは、例えば、特定のサービスからのトラフィックがリソースにアクセスすることを許可するなど、サービス タグを使用してファイアウォール規則で Azure サービスを参照できます。
これらのサービスの一部は、サービス タグを介した受信トラフィックを許可し、Web 要求の一部 (URL パス、宛先ホストなど) を制御できる機能を含んでいます。サービス タグからのトラフィックを許可するように構成され、それ以外の認証を行わない場合、テナント A の攻撃者は、Web 要求を使用してテナント B のリソースにアクセスする可能性があります。
このような場合、影響は次の要因によって部分的に決定されます。
- 攻撃を受けるサービス自身が認証をするか
- 攻撃者が制御できるリクエスト ボディの量
- 攻撃者が応答の内容を表示できるか
例: Azure Monitor 可用性テスト
たとえば、Azure Monitor 可用性テスト サービスには ApplicationInsightsAvailability サービス タグがあり、ユーザーはファイアウォール経由で Web テストを構成してサービス エンドポイントにアクセスし、総合的な監視を実行できます。これらの Web テストでは、共有インフラストラクチャ内の同じパブリック IP アドレスを使用してユーザーのサービス エンドポイントを呼び出すため、ユーザーは別の Azure Monitor 可用性テストサブスクリプションからサービス エンドポイントにアクセスするように Web 要求を構成できます。この動作により、悪意のあるアクターが別ユーザーのサービス エンドポイントに Web 要求を送信し、以下の場合にアプリケーションが意図しない Web 要求を処理する可能性があります。
- 悪意のあるアクターは、ApplicationInsightsAvailability サービス タグを有効にしたテナントにアクセスでき、かつ
- 対象のサービス エンドポイントが、独自の認証チェックを実行しない場合
お客様へのガイダンス
サービス タグは、特定の Azure サービスの IP アドレスの範囲を表し、ファイアウォール フィルター、ネットワーク セキュリティ グループ (NSG)、ユーザー定義ルート (UDR) などのネットワーク構成に使用されます。サービス タグのこの機能は、Azure サービスとユーザーのサービス エンドポイント間のネットワーク トラフィックを許可するために重要です。サービス タグの柔軟なユース ケースを考えると、お客様はテナント間のネットワーク トラフィックとサービスの特定のシナリオを考慮する必要があります。
サービス タグは、お客様の送信元へのトラフィックをセキュリティで保護するための完全な方法ではなく、Web 要求に関連する脆弱性を防ぐための入力検証に取って代わるものではありません。 入力検証は、トラフィックの送信元とトラフィックの送信者を保証するために使用されます。階層型ネットワークセキュリティアプローチのために、追加の認証および承認チェックを実装する必要があります。
Azure のお客様は、仮想ネットワーク サービス タグ の使用を確認し、Azure テナント間のネットワーク トラフィックをセキュリティで保護するために追加の対策を講じる必要があるかどうかを評価することを強く推奨します。お客様は、サービスタグの使用状況を確認した後、以下のアクションを実行できます。
- 新しい サービス タグに関するベスト プラクティスの記事を確認し、サービスによって特定のガイダンスが提供される場合、そのガイダンスに従います。
- Azure のセキュリティの基礎に関するドキュメント を確認し、Azure プラットフォームとインフラストラクチャが一般的かつセキュリティのベスト プラクティスを考慮し設定されていることを確認します。
- Azure Monitor のドキュメント を確認し、Azure プラットフォームとインフラストラクチャで、システム イベントの収集、分析、応答に適した監視コントロールが有効になっていることを確認します。
例: 認証チェックを使用した Azure Monitor 可用性テスト
Azure Monitor 可用性テストは、リソースのアップタイムを監視する手段を顧客に提供します。お客様は、リソースの監視戦略でこの点を考慮する必要があります。Azure Monitor 可用性テストを関連するサービス タグと共に使用すると、標準の監視戦略に確実に従うことができます。
ApplicationInsightsAvailability サービス タグがサービス エンドポイントに不要なネットワーク トラフィックを送信しないようにするには、トークンを作成し、可用性テストに HTTP ヘッダーとして追加します。その後、サービスは受信要求の HTTP ヘッダーを検証して、トラフィックの発信元が可用性テストからのものであることを認証できます。したがって、カスタム HTTP ヘッダーのない他のすべての要求は拒否され、破棄されます。Azure Monitor 可用性テストのこのアプリケーション層セキュリティ制御の詳細については、こちらを参照してください。
上記以外にも、お客様によっては次のようなシナリオが考えられます。A 社は、複数の業界パートナーに API を提供し、サービスやアプリケーションで使用できるようにしています。これらの各パートナーは、Azure Monitor 可用性テストを通じて A 社の API の稼働時間を監視したいと考えるかもしれません。そのため、A 社は、API のリソース監視戦略と、その戦略を業界パートナーに伝える方法を決定する必要があります。
セキュア・バイ・デザインの原則を追求すれば、A 社はHTTPヘッダーの検証チェックを実装できます。A社のリソース監視戦略は、カスタムヘッダーを持つ業界パートナーのみがアクセスでき、安全なコラボレーションが保証されます。または、別の方法として、A 社がカスタム ヘッダーを必要とせず、代わりに独自の認証方法を使用することで、だれでも Azure Monitor 可用性テストを使用して API を監視できるようにすることもできます。
マイクロソフトの対応と経緯
マイクロソフトは、本件が指摘された後、次の措置を講じました。
- マイクロソフトは、この問題の包括的な亜種調査、テレメトリ調査、およびエンジニアリングレビューを実行し、緩和策に影響を与えました。
- 受信サービスタグを持つ Azure サービスのドキュメントを更新し、サービス タグのユース ケースやネットワーク トラフィックを確認するためのガイダンスに関する情報を含むようドキュメントを更新しました。
- Azure にて、サービス タグに関するベスト プラクティスを一般的な記事で文書化しました。
この問題に関連する主なイベントのタイムラインを提供し、この問題を防ぐためにお客様が利用できるドキュメントを増やすためのアプローチを強調しました。
- 2024 年 1 月 24 日: Tenable 社は、MSRC 研究者ポータルを通じて潜在的なセキュリティ脆弱性を報告しました。
- 2024 年 1 月 31 日: MSRC は観測された脆弱性を確認し、Tenable 社に報奨金を授与しました。
- 2024 年 2 月 2 日: マイクロソフトはこの問題を確認し、軽減策を決定するために、この動作の包括的な亜種調査、テレメトリ調査、エンジニアリング レビューの実行を開始しました。
- 2024 年 2 月 26 日: マイクロソフトは、この問題に対処するために、お客様への情報開示戦略と、Azure サービスのサービス タグ ドキュメントを強化することを表明しました。
- 2024 年 3 月 6 日: マイクロソフトと Tenable 社は、この問題に関して協調的な開示に合意しました。
- 2024 年 3 月 31 日: マイクロソフトは、この問題に関する包括的な亜種調査、テレメトリ調査、エンジニアリング レビューを終了しました。
- 2024 年 4 月 3 日: マイクロソフトは、この問題が SSRF の脆弱性ではないことを Tenable 社に書面でフィードバックしました。
- 2024 年 5 月 3 日: マイクロソフトは、この問題がファイアウォール バイパスの脆弱性ではないことを Tenable 社に書面でフィードバックしました。
- 2024 年 5 月 10 日: マイクロソフトは、サービス タグのドキュメントの変更を Microsoft Learn で公開しました。
- 2024 年 6 月 3 日: マイクロソフトと Tenable 社はこの問題を一般に公開します。
謝辞
Tenable 社からの報告を調査する機会を与えていただいたことに感謝し、Microsoft バグ報奨金プログラムの条件に基づいて安全なセキュリティ調査を実施してくれたことに感謝します。すべての研究者は、協調的な脆弱性開示 (CVD) の下でベンダーと協力し、侵入テストのエンゲージメント ルールを遵守して、セキュリティ調査の実施中に顧客データに影響を与えないようにすることを推奨します。
マイクロソフトには、サードパーティの研究者やセキュリティ コミュニティの人々と協力してきた長い歴史があります。これは、Secure Future Initiative (SFI) に反映されており、セキュリティ研究者との協力方法や、製品やプラットフォームサービスに関連するリスクへの対応方法の透明性をさらに高めています。マイクロソフトは、研究者の主張を分析した結果を共有し、お客様やコミュニティに推奨事項を提供することをお約束します。
参照
- 質問がある場合は、aka.ms/azsupt で Azure Portal からサポート ケースを開いてください。
- Azure 仮想ネットワークサービスタグの詳細については、「Azure サービス タグの概要 |Microsoft Learn」を参照してください。
- Azure のセキュリティの基礎に関する詳細は、「Azure のセキュリティの基礎に関するドキュメント」を参照してください。
- Azure Monitor の詳細については、「Azure Monitor のドキュメント |Microsoft Learn」を参照してください。