セキュリティ & アイデンティティ

ストレージの保護: ダングリングバケットの乗っ取りを防ぐためのベストプラクティス

2025年8月29日

Raman Bansal

Senior Software Engineer

Maksim Shudrak

Information Security Engineer

Try Gemini 2.5

Our most intelligent model is now available on Vertex AI

Try now

※この投稿は米国時間 2025 年 8 月 8 日に、Google Cloud blog に投稿されたものの抄訳です。

ストレージバケットは、クラウド内のデータが保存される場所です。デジタルの不動産にたとえると、バケットはインターネット上の土地のようなものです。引っ越して特定のバケットが不要になった場合、古いアドレスがまだ一般公開されていれば、他の人がその「土地」を再利用できます。

これがダングリングバケット攻撃の根幹となる考え方です。ストレージバケットを削除しても、アプリケーションコード、モバイルアプリ、公開ドキュメントにそのバケットへの参照が残っている場合に発生します。攻撃者は、自分のプロジェクトで同じバケット名を簡単に要求できます。これにより、古いアドレスが事実上ハイジャックされ、公式には使用されなくなったバケットをまだ利用しているユーザーに、マルウェアを配信したり、データを盗んだりする可能性があります。

幸いなことに、次の 4 つのステップで、アプリケーションとユーザーをこの脅威から保護できます。

まず、安全な廃止計画を実装する

バケットを削除する際は、慎重に行ってください。慎重な廃止プロセスが重要です。gcloud storage rm を入力する前に、次の手順を行います。

ステップ 1: 監査と学習

削除する前に、バケットにアクセスしているユーザーとリソースを把握します。ログを使用して、最近のトラフィックを確認します。古いバージョンのアプリ、サードパーティサービス、ユーザーからのアクティブなトラフィックリクエストを確認したら、調査します。実行可能コード、ML モデル、動的ウェブコンテンツ（JavaScript など）、機密性の高い構成ファイルをプルしようとするリクエストには特に注意してください。

リクエスト元のユーザーエージェントを確認すると、ボット、データクローラ、スキャナからのリクエストが多数あることがわかります。これらのリクエストは基本的にバックグラウンドノイズであり、システムが正しく機能するためにバケットがアクティブに必要とされていることを示すものではありません。これらはアプリケーションやユーザーからの正規のトラフィックではないため、危険ではなく、無視してかまいません。

ステップ 2: 確信をもって削除

自動化されたプロセスやユーザーアクティビティの多くは毎日発生するわけではないため、バケットを削除する前に少なくとも 1 週間待つことが重要です。少なくとも 1 週間待つことで、以下を含むアクティビティの完全なサイクルを観察したという確信が高まります。

週次レポート: 週次スケジュールでレポートを生成し、データバックアップを実行するスクリプト。
バッチジョブ: 週末や特定の曜日にのみ実行される自動化されたタスク。
アクセス頻度が低いユーザー: バケットのデータに依存する機能を週に 1 回しか使用しないユーザー。

正当なトラフィックが 1 週間以上バケットにアクセスしていないことを確認し、すべてのレガシーコードを更新したら、バケットの削除に進むことができます。Google Cloud プロジェクトを削除すると、すべての Google Cloud Storage バケットを含む、そのプロジェクトに関連付けられたすべてのリソースが事実上削除されます。

ダングリングバケットを参照するコードを見つけて修正する

将来の問題を防ぐことも重要ですが、環境内にダングリングバケットへの参照がすでに存在する可能性があります。ここでは、それらを特定して修正する計画を立てます。

ステップ 3: 事前特定

ログの分析: これは最も強力なツールの一つです。ストレージ URL で「404 見つかりません」エラーが繰り返し発生していることを示すサーバーログとアプリケーションログについて、Cloud Logging データをクエリします。たとえば、存在しない同じバケット名に対するリクエストが大量に失敗している場合は、重大な危険信号です（これを修正するには、ステップ 3 に進み、ステップ 4 に進むことをおすすめします）。

コードベースとドキュメントをスキャンする: すべてのプライベートおよびオープンソースのコードリポジトリ（古いものやアーカイブされたものを含む）、構成、ドキュメントを包括的にスキャンして、使用されなくなった可能性のあるストレージバケット名の参照がないか確認します。それらを見つける方法の一つは、次のパターンを探すことです。

gs://{bucket-name}
storage.googleapis.com/{bucket-name}
{bucket-name}.storage.googleapis.com
commondatastorage.googleapis.com/{bucket_name}
{bucket_name}.commondatastorage.googleapis.com

バケットがまだ存在するかどうかは、https://storage.googleapis.com/{your-bucket-name} をクエリすることで確認できます。レスポンス NoSuchBucket が表示された場合は、ダングリングバケット参照を特定したことを意味します。

読み込んでいます...

バケットが存在する場合（NoSuchBucket エラーが表示されない場合）、そのバケットが実際に組織に属していることを確認する必要があります。脅威アクターがすでにそのバケットを使用している可能性があるからです。

所有権を確認する最も簡単な方法は、バケットの Identity and Access Management（IAM）権限を読み取ってみることです。

gcloud storage buckets get-iam-policy gs://{bucket-name} のようなコマンドを実行して、Access Denied または 403 Forbidden エラーが表示された場合は、バケットが他のユーザーによって使用されていることを示しています。バケットが存在することは証明されますが、アカウントにはバケットを管理する権限がありません。これは、バケットが乗っ取られたことを示しています。この参照はリスクとして扱われ、削除されるべきです。

便宜上、指定されたファイル内の未解決の参照を検索できるスクリプトを以下に示します。

読み込んでいます...

import re
import sys
from typing import Optional, Set

import requests
from requests.exceptions import RequestException

def check_bucket(bucket_name: str) -> Optional[requests.Response]:
    try:
        with requests.Session() as session:
            response = session.head(f"https://storage.googleapis.com/{bucket_name}")
        return response
    except RequestException as e:
        print(f"An error occurred while checking bucket {bucket_name}: {e}")
        return None

def sanitize_bucket_name(bucket_name: str) -> Optional[str]:
    # 一般的な接頭辞と引用符を削除
    bucket_name = bucket_name.replace("gs://", "")
    bucket_name = bucket_name.replace("\"", "")
    bucket_name = bucket_name.replace("\'", "")
    bucket_name = bucket_name.split("/")[0]

# GCS の命名規則に従ってバケット名の形式を検証する
    if re.match("^[a-z0-9-._]+$", bucket_name) is None:
      return None
    return bucket_name

def extract_bucket_names(line: str) -> Set[str]:
    all_buckets: Set[str] = set()

pattern = re.compile(
        r'gs://([a-z0-9-._]+)|'
        r'([a-z0-9-._]+)\.storage\.googleapis\.com|'
        r'storage\.googleapis\.com/([a-z0-9-._]+)|'
        r'([a-z0-9-._]+)\.commondatastorage\.googleapis\.com|'
        r'commondatastorage\.googleapis\.com/([a-z0-9-._]+)',
        re.IGNORECASE
    )

for match in pattern.finditer(line):
        # 最初の空でないグループがバケット名
        if raw_bucket := next((g for g in match.groups() if g is not None), None):
            if sanitized_bucket := sanitize_bucket_name(raw_bucket):
                all_buckets.add(sanitized_bucket)

return all_buckets

def main(filename: str) -> None:
  with open(filename, 'r') as f:
      for i, line in enumerate(f, 1):
          bucket_names = extract_bucket_names(line)
          for bucket_name in bucket_names:
              response = check_bucket(bucket_name)
              if response.status_code == 404:
                  print(f"Dangling bucket found: {bucket_name} (line {i}), {line}")

if __name__ == "__main__":
    if len(sys.argv) != 2:
        print("Usage: python find_dangling_buckets.py <filename>")
        sys.exit(1)
    
    main(sys.argv[1])

このスクリプトと推奨事項で検出できるのはハードコードされた参照のみで、実行時に動的に生成された参照は検出できないのでご注意ください。また、コードベースにパターンに従っていないバケット名がハードコードされている場合もありますが、Google Cloud Storage クライアントで使用されています。

ステップ 4: 回収して保護する

自分やクライアントにセキュリティリスクをもたらす可能性のあるダングリングバケット名を見つけた場合は、迅速に対応してください。

所有していないダングリングバケットの場合:

前のステップで利用可能なすべてのデータを使用して、ダングリングバケットを見つけ、コードまたはドキュメント内のハードコードされた参照を削除します。修正をユーザーにデプロイして、問題を完全に解決します。

所有しているダングリングバケットの場合:

名前を再利用: 管理している安全なプロジェクトに、まったく同じ名前の新しいストレージバケットを作成します。これにより、攻撃者がそのドメインを使用することを防ぎます。
ロックダウン: 回収したバケットに制限の厳しい IAM ポリシーを適用します。allUsers と allAuthenticatedUsers のすべてのアクセスを拒否し、均一なバケットレベルのアクセスを有効にします。公開アクセスの防止コントロールを有効にして、バケットをプライベートな「シンクホール」にします。

これらのプラクティスを開発ライフサイクルと運用手順に組み込むことで、ダングリングバケットの乗っ取りを効果的に防ぐことができます。クラウド環境の保護は継続的なプロセスであり、これらの手順により、お客様とユーザーの保護が強力に強化されます。

ストレージバケットの管理について詳しくは、こちらのドキュメントをご覧ください。

-シニアソフトウェアエンジニア、Raman Bansal

-情報セキュリティエンジニア、Maksim Shudrak

投稿先