データストレージのセキュリティ

なぜストレージの公開設定が最優先事項なのか

オブジェクトストレージは、アプリケーションのログ、バックアップ、顧客データ、機密文書など「実データ」がそのまま置かれる場所です。IAMの権限昇格やネットワークの侵入経路がなくても、バケット/コンテナのアクセス制御設定が1つ誤っているだけで、インターネット上の誰もがデータを列挙・ダウンロードできてしまいます。攻撃者にとって、公開ストレージの探索はスキャンだけで成立する「最も低コストな攻撃」です。

典型的なストレージセキュリティアーキテクチャ

アプリケーションからストレージサービスへ書き込まれたデータは、鍵管理サービスによって保管時に暗号化され、アクセスポリシー/公開ブロック設定というゲートを通過した後にのみ、外部の利用者やインターネットへ到達すべきです。このゲートの評価が緩むと、暗号化されていても「誰でも読める」状態になり得ます。

「Access Policy Gate」がこのアーキテクチャのSecurity Gateです。ここでバケットポリシー・ACL・公開ブロック設定・presigned URLの有効期限が正しく評価されなければ、暗号化されたデータであっても不特定多数からアクセス可能になります。

主要概念とAWS/Azure/GCPの対応

よくある設定ミス

• 公開読み取り/リストACLまたはバケットポリシー High Risk

  バケットポリシーやACLに Principal: "*" を許可する記述が残り、誰でもオブジェクトを一覧・取得できる状態になる。

• ストレージアカウント単位での公開Blob許可 High Risk

  Azureの "Allow Blob Public Access" がストレージアカウントレベルで有効なままになっており、個々のコンテナで匿名アクセスが設定可能になっている。

• プロバイダ管理鍵のまま運用 Medium Risk

  コンプライアンス要件でカスタマー管理キー(CMK)が必要な機密データにもかかわらず、既定のプロバイダ管理暗号化のまま運用されている。

• アクセスログ未設定 Medium Risk

  バケット/コンテナへのアクセスログが有効化されておらず、不正アクセスの検知・事後調査ができない。

• 有効期限の長いpresigned URLの乱用 High Risk

  一時アクセス用のpresigned URL/SASトークンに数週間〜無期限に近い有効期限を設定し、URLが漏洩した際の被害期間を拡大させる。

攻撃シナリオ: 公開バケットの発見とデータ窃取

攻撃者が命名規則の推測やコード内に残された漏洩URLから、公開状態のS3バケットを発見した、という想定です。

1. 会社名やサービス名を含むバケット名を辞書的に推測、またはGitHub/Slackなどに残ったURLから対象を特定する。
2. 認証情報なしでバケットの中身を一覧できるかを確認する。
3. 機密性の高そうなファイルを特定し、ダウンロードする。
4. 取得したデータ(顧客情報、認証情報、内部文書など)を悪用・転売する。

# 1. 認証情報なしでバケットの中身を一覧
$ aws s3 ls s3://example-public-bucket --no-sign-request

# 2. 機密性の高そうなファイルを発見
2024-01-10 09:15:32     482913 customers.csv
2024-01-12 17:02:11      88210 backup-credentials.json

# 3. 認証情報なしでダウンロード
$ aws s3 cp s3://example-public-bucket/customers.csv . --no-sign-request

検知

バケット/コンテナの公開状態を定期的に棚卸しし、意図しない公開設定を早期に検出します。

• バケットポリシーが匿名アクセスを許可していないかを get-bucket-policy-status で確認する。
• 4つのBlock Public Access設定がすべて有効かを get-public-access-block で確認する。
• IAM Access Analyzer for S3が「パブリックにアクセス可能」と判定したバケットのファインディングを確認する。
• Azure Storageの "公開アクセスが検出されました" アラート、GCPのIAM Recommenderによるバケット公開の指摘を確認する。

aws s3api get-bucket-policy-status --bucket example-public-bucket

aws s3api get-public-access-block --bucket example-public-bucket

aws accessanalyzer list-findings \
  --analyzer-arn <analyzer-arn> \
  --filter '{"resourceType":{"eq":["AWS::S3::Bucket"]},"isPublic":{"eq":["true"]}}'

是正

公開状態を許可しているバケットポリシーのステートメントを削除し、Block Public Accessの4設定をすべて再有効化します。

# Block Public Accessの4設定をすべて有効化
$ aws s3api put-public-access-block \
    --bucket example-public-bucket \
    --public-access-block-configuration \
      BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

# 公開を許可していたバケットポリシーのステートメントを削除
$ aws s3api delete-bucket-policy --bucket example-public-bucket

# 是正後、再度公開状態でないことを確認
$ aws s3api get-public-access-block --bucket example-public-bucket

実際に手を動かす

このページで扱った「公開状態のオブジェクトストレージ」の検出と是正を、AWSとAzureそれぞれのシナリオで体験できます。Scenario → Architecture → CLI Commands → Misconfiguration → Detection → Remediation → Verification の流れで進めます。

実装チェックリスト

• すべてのバケット/ストレージアカウントでBlock Public Access(または同等の設定)が有効になっている
• 機密データを含むバケット/コンテナで保管時の暗号化が強制されている
• コンプライアンス要件のあるデータはカスタマー管理キー(CMK)で暗号化されている
• すべてのバケット/コンテナでアクセスログが有効化されている
• presigned URL / SASトークンの有効期限ポリシーが定義され、必要最小限の期間に制限されている
• データ分類(機密度)に応じてバケット/コンテナのアクセス制御レベルが分けられている
• Access Analyzer for S3 / Azure Storage公開アラート / GCP IAM Recommenderを定期的に確認している
• 通信は転送時暗号化(TLS)が強制され、平文アクセスが拒否される設定になっている