AWS S3の「公開」という名の地雷原：ACLとバケットポリシーの複雑怪奇な力学
AWS S3は、クラウドインフラストラクチャにおける「データレイク」の代名詞だ。しかし、多くのアーキテクトが陥る罠がある。それは、S3の権限管理モデルが、歴史的経緯と利便性追求の結果、あまりにも多層的かつ複雑になってしまったことだ。
かつては「ACL（アクセスコントロールリスト）」が主流だったが、現在は「IAMポリシー」と「バケットポリシー」が主役だ。しかし、この両者が混在し、さらに「ブロックパブリックアクセス（BPA）」という強力なガードレイルが導入されたことで、現場では「なぜかアクセスできない」「なぜか漏洩している」という矛盾が日常的に発生している。
今日は、攻撃者の視点から、この「権限の多重構造」がどのようなロジックで突破され、我々防衛側がどうそれを「物理的に」封じ込めるべきかについて、深掘りしていく。
—
攻撃者が狙う「盲点」：ACLとポリシーステートの不整合
攻撃者はまず、s3-buckets-public-read-accessのような自動スキャンツールを走らせるだけではない。真のプロは、APIの挙動と認証の不整合を突く。
例えば、BPAが有効であっても、バケットポリシーで特定のIAM ARNに対して明示的に許可を出している場合、そのARNが乗っ取られていれば突破される。また、もっと致命的なのは「Object ACL」だ。バケット単位ではプライベートに見えても、特定オブジェクトにpublic-readが付与されていれば、そのファイルはインターネットから直リンクでダウンロード可能だ。
攻撃ロジックの解析
攻撃者がターゲットを特定する際、彼らは以下のプロトコル上の挙動を監視している。
1. 推論と列挙: LIST操作が拒否されても、GET操作でファイル名を推測（wordlistによるブルートフォース）する。
2. ACLの深掘り: GET Object ACLを実行し、GranteeがAllUsersまたはAuthenticatedUsersになっている個別のオブジェクトを抽出する。
3. 署名付きURLの乱用: 開発者がデバッグ目的で発行した「有効期限が極端に長い署名付きURL」が、Gitリポジトリにコミットされていないか監視する。
—
最小権限の原則：アーキテクチャによる「強制」
我々が取るべき防御策は、単なる設定変更ではない。「設定ミスを許容しないアーキテクチャ」への移行だ。
1. BPA（ブロックパブリックアクセス）のハードニング
まずは、アカウントレベルでBPAを「強制」する。Terraform等でIaC化し、手動変更を検知したら即座にロールバックするCI/CDパイプラインを構築する。
# Terraformによるバケット保護の強制
resource "aws_s3_account_public_access_block" "enforce_block_public" {
account_id = var.aws_account_id
# 全てのパブリックアクセスを問答無用でブロック
block_public_acls = true
block_public_policy = true
ignore_public_acls = true
restrict_public_buckets = true
}2. IAMポリシーとバケットポリシーの分離
バケットポリシーで「誰に許可するか」を決めるのではなく、「IAMロールがどのバケットにアクセスできるか」というIAM側の管理に統一する。バケットポリシーは、「特定のVPCエンドポイント以外からのアクセスを拒否する」というガードレイルとしてのみ使用する。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "RestrictToVPCEndpoint",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": ["arn:aws:s3:::my-secure-bucket/*"],
"Condition": {
"StringNotEquals": {
"aws:sourceVpce": "vpce-1a2b3c4d"
}
}
}
]
}—
次世代の防衛：AIによる異常検知とガードレイル
今、我々が直面しているのは人間による設定ミスだけではない。生成AIによる自動生成されたコードが、セキュリティコンテキストを理解せずに「とりあえず動く権限設定」を実装するリスクだ。
これに対しては、GuardDutyによるS3ログの監視に加え、IAM Access Analyzerを常時稼働させ、外部公開されているバケットをリアルタイムで検知し、未承認の変更を自動破棄する「自己修復インフラ」が必要となる。
セキュリティアーキテクトへの提言
1. 暗号化のレイヤ: SSE-S3からSSE-KMS（顧客管理鍵）への完全移行を行う。たとえバケットが公開されても、KMS鍵の権限がなければデータはただのバイナリゴミである。
2. 通信の可視化: S3アクセスログをAthenaで解析し、「意図しないIP範囲からのアクセス」を閾値ベースでアラートする（403 Forbiddenの急増は、攻撃者によるスキャンのサインだ）。
3. 耐量子暗号への備え: 現在のTLS通信は近い将来に脅威に晒される。S3へのアクセスにはTLS 1.2以上を強制し、将来的なハイブリッド暗号化への準備を進めておくべきだ。
セキュリティとは、境界線を引くことではなく、「境界線が破られた後の被害をいかに極小化するか」という冷徹な計算である。S3の設定一つとっても、それは単なるチェックボックスのオンオフではなく、企業の生存をかけたリスク管理そのものだということを忘れてはならない。
諸君、まずは今すぐ自身の環境で aws s3api get-public-access-block を叩くことから始めてほしい。そこに表示される True の数だけが、君たちの夜の安眠を保証する数値なのだから。
コメント