本ブログは、Microsoft mitigated exposure of internal information in a storage account due to overly-permissive SAS tokenの抄訳版です。最新の情報は原文を参照してください。
概要
マイクロソフトは、Wiz.io からの最近の協調的な脆弱性の公開 (CVD) に基づいた報告の一環として、オープン ソース AI 学習モデルに貢献する際に、パブリック GitHub リポジトリ内の BLOB ストアの URL を共有した Microsoft 従業員に関するインシデントを調査し、修正しました。この URL には、内部ストレージ アカウントの制限が過度に許可されている共有アクセス署名 (SAS) トークンが含まれていました。その後、Wiz のセキュリティ研究者は、このトークンを使用してストレージ アカウントの情報にアクセスできました。このストレージ アカウントで公開されていたデータには、2 名の元従業員のワークステーション プロファイルのバックアップと、これらの 2 名の元従業員と同僚の内部 Microsoft Teams メッセージが含まれています。この問題によって、お客様のデータは公開されておらず、他の内部サービスが危険にさらされることもありませんでした。この問題に対応するために、お客様で実施する必要のある作業ありません。 マイクロソフトは、今回のインシデントをお客様に公表するとともに、今後、お客様が同様のインシデントを回避できるように、以下の学びとベスト プラクティスを共有します。
SAS トークンは、アクセスを制限し、特定のクライアントが指定された Azure Storage リソースに接続できるようにするメカニズムを提供します。この場合、マイクロソフトの研究者は、この SAS トークンを BLOB ストア URL に誤って含め、オープン ソース AI 学習モデルに貢献するため、パブリック GitHub リポジトリに URL を提供しました。Azure Storage または SAS トークン機能にセキュリティの問題や脆弱性はありません。他のシークレットと同様に、SAS トークンは適切に作成され管理される必要があります。また、SAS トークン機能をさらに強化するために継続的な改善を行い、セキュリティで保護された既定のセキュリティ能勢を改善するためにサービスの評価を続けています。
この露出を特定した後、Wiz は 2023 年 6 月 22 日に Microsoftセキュリティ レスポンス センター (MSRC) にこの問題を報告しました。MSRC は通知を受け、関連する調査およびエンジニアリング チームと協力して SAS トークンを失効させ、ストレージ アカウントへのすべての外部アクセスを防ぎ、2023 年 6 月 24 日にこの問題を緩和しました。その後、お客様やビジネスの継続性に対する潜在的な影響を理解するために追加の調査が行われました。マイクロソフトの調査は、今回の露出によるお客様へのリスクはないと結論づけられました。
今後のケースのために検出機能の向上
GitHub のシークレット スキャニング サービスは、資格情報やその他のシークレットがプレーンテキストで露出していないか、すべての公開されたオープン ソース コードの変更を監視します。このサービスは、VHD やプライベート暗号化キーなどの機密コンテンツを指す Azure Storage SAS URL にフラグを設定する、マイクロソフト提供の SAS 検出を実行します。マイクロソフトは、過度に許可された有効期限または特権を持つ可能性のある SAS トークンを含めるよう、この検出を拡張しました。
また、マイクロソフトは追加で、マイクロソフトが所有または関連する組織およびアカウントのすべてのパブリック リポジトリの完全な履歴再スキャンを実行します。このシステムは、‘robust-models-transfer’ リポジトリで Wiz によって識別された特定の SAS URL を検出しましたが、この検出は誤って誤検知とマークされました。この問題の根本原因は修正され、システムがオーバープロビジョニングされたすべての SAS トークンを検出して適切に報告することが確認されました。
SAS トークンの理解、ベスト プラクティス、不正利用の防止
Shared Access Signatures (SAS) は、ストレージ アカウント内のデータへのアクセスを委任する安全なメカニズムを提供します。ストレージ アカウント全体にフル アクセスできる Shared Key とは異なり、SAS はクライアントがデータにアクセスする方法を細かく制御します。 SAS を正しく使用すると、ストレージ アプリケーションのセキュリティとパフォーマンスの両方が向上します。
たとえば、SAS トークンを使用して次を制限できます。
- クライアントがアクセスできるリソース (特定のコンテナー、ディレクトリ、BLOB、または BLOB バージョン)
- クライアントが実行できる操作 (読み取り、書き込み、一覧表示、削除)
- クライアントがアクセスできるネットワーク (HTTPS、IP アドレス)
- クライアントがアクセス権を持つ期間 (開始時刻、終了時刻)
キーベースの認証メカニズムと同様に、親キーをローテーションすることで、SAS はいつでも失効させることができます。さらに、SAS は、ストレージ アカウント キーをローテーションすることなく、コンテナー レベルできめの細かい失効をサポートします。
他のシークレットと同様に、SAS トークンを適切に作成し処理する必要があります。
AZURE Storage は、SAS URL を操作する際に次のベスト プラクティスを推奨します。
- 最小限の特権の原則: SAS URL をクライアントに必要な最小のリソース セット (単一の BLOB など) に適用し、アクセス許可をアプリケーションが必要とするリソース (読み取り専用、書き込み専用など) のみに制限します。
- 存続期間の短い SAS の使用: SAS を作成するときは常に有効期限が近い時間を使用し、必要に応じてクライアントに新しい SAS URL を要求してもらいます。Azure Storage は、すべての SAS URL に対して 1 時間以下を推奨します。
- SAS トークンを慎重な処理: SAS URL はデータへのアクセス権を付与するため、アプリケーション シークレットとして扱う必要があります。ストレージ アカウントにアクセスする必要があるクライアントにのみ SAS URL を公開します。
- 失効計画を保持: SAS トークンをストアド アクセス ポリシーに関連付け、コンテナー内での SAS の詳細な失効を可能にします。SAS または共有キーがリークした場合は、ストアド アクセス ポリシーまたはローテーション ストレージ アカウント キーを削除する準備をしてください。
- アプリケーションの監視と監査: Azure Monitor と Azure Storage ログを有効にして、ストレージ アカウントへの要求が承認される方法を追跡します。SAS 有効期限ポリシーを使用して、存続期間の長い SAS URL を使用しているクライアントを検出します。
Azure Storage は、お客様がデータ資産を保護できるように取り組んでおり、ストレージ アカウントの既定の設定でこれらのベスト プラクティスをエンコードするための継続的な改善を引き続き行います。
詳細については、SAS トークンの使用に関するマイクロソフトのベスト プラクティスと BLOB ストレージのセキュリティに関する推奨事項を参照してください。
結論
繰り返しになりますが、公開された情報は、2 人のマイクロソフトの元従業員と、その元従業員のワークステーションに固有の情報で構成されていました。この問題によって、お客様のデータは公開されておらず、他の内部サービスが危険にさらされることもありませんでした。お客様は、セキュリティを維持するために追加の措置を講じる必要はありません。
他のシークレットと同様に、SAS トークンを適切に作成し処理する必要があります。通常と同様に、SAS トークンを使用する場合はベスト プラクティスに従い、意図しないアクセスや不正使用のリスクを最小限に抑えることをお勧めします。また、マイクロソフトは検出およびスキャニング ツールセットの継続的な改善を行い、このようなオーバープロビジョニングされた SAS URL のケースをプロアクティブに特定し、既定のセキュリティで保護された能勢の改善をしています。
Wiz.io から報告されたレポートを調査する機会に感謝します。マイクロソフトでは、すべてのリサーチャーが協調的な脆弱性の公開 (CVD) の下でベンダーと協力し、侵入テストのエンゲージメントルールに従い、セキュリティ研究を実施する際に顧客データに影響を与えないようにすることをお勧めします。マイクロソフト セキュリティ レスポンス センターにセキュリティの問題を報告するリサーチャーも、マイクロソフトのバグ バウンティ プログラムに参加する資格があります。
マイクロソフトは CVD に従っています。この CVD は、システム上および責任を持ってセキュリティの脆弱性の検出、報告、および改善策を管理します。CVD を使用すると、ユーザーのセキュリティとシステムの整合性を優先する方法で、研究者や広範なセキュリティ コミュニティと共同作業できます。協調的なアプローチに従うことで、研究者と協力し、潜在的な脆弱性が公表される前に解決されるようにし、悪用のリスクを低減することができます。