S3バケットはなぜ「穴」になるのか？— 誤認を招く権限階層とIAMの境界防衛
S3バケットの公開設定による情報漏洩は、もはや古典的な「人為的ミス」として語られることが多い。しかし、現場でインシデント対応に当たっていると、それが単なる「設定忘れ」ではなく、AWSの権限評価ロジックと、開発者が抱く「直感的なアクセス制御」との間に横たわる深い溝に起因していることがわかる。
今回は、表面的なチェックリストではなく、IAMポリシーとバケットポリシーが複雑に絡み合う「権限の重畳」をどう制御し、防衛のガードレイルを構築すべきかについて、アーキテクチャの核心を突いていく。
—
1. 権限評価の「負の連鎖」を理解する
多くのエンジニアが陥る罠は、IAMポリシーとバケットポリシーを単独で評価してしまうことだ。AWSの権限評価は「明示的な拒否（Deny）」が「許可（Allow）」に優先する。そして、S3へのアクセスは以下の評価プロセスを経る。
1. Block Public Access (BPA): バケット単位、あるいはアカウント単位での絶対的な防衛線。ここが有効であれば、ポリシーが何であれパブリックアクセスは遮断される。
2. SCP (Service Control Policies): 組織単位のガードレイル。これこそが、個別のバケット設定を無効化する最終防衛層だ。
3. IAM Policy & Bucket Policy: ここで「誰が」「何を」できるかが評価される。
特に危険なのは、「IAMで許可しているから大丈夫」という思い込みだ。S3のバケットポリシーに`Principal: “”`が含まれている場合、BPAが無効であれば、IAMポリシー側でいくら厳密な制御をしていても、バケットそのものがインターネットに対して「門戸を開いてしまっている」状態になる。
2. 「最小権限」を強制するIAMポリシーの実装パターン
単に「S3の全権限」を渡すのではなく、特定の条件下でのみアクセスを許可する「条件付きアイデンティティ」を構築しなければならない。以下は、特定のVPC内からのみアクセスを許可し、かつ暗号化されていないアップロードを拒否するIAMポリシーのプロトタイプだ。
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Sid”: “RestrictToVPCAndEncryption”,
“Effect”: “Allow”,
“Action”: [“s3:PutObject”, “s3:GetObject”],
“Resource”: “arn:aws:s3:::my-secure-bucket/”,
“Condition”: {
“StringEquals”: {
“aws:SourceVpc”: “vpc-0123456789abcdef0”
},
“StringLike”: {
“s3:x-amz-server-side-encryption”: [“aws:kms”, “AES256”]
}
}
}
]
}
このポリシーの肝は、`s3:x-amz-server-side-encryption` を強制している点にある。これはデータが平文で保存されるリスクをインフラ層で弾くためのガードレイルだ。
3. 自動化された監査と防御のアーキテクチャ
ホワイトハッカーの視点で言えば、人間はミスをする。だからこそ、「設定」ではなく「状態」を監視する必要がある。
推奨するのは、AWS ConfigとEventBridgeを組み合わせた「オートレメディエーション」だ。S3のBPAがオフになった瞬間にトリガーを引く構成を組む。
- トリガー: `s3-bucket-public-write-prohibited` などのAWS Configルール。
- アクション: EventBridgeで検知し、Lambdaを起動して即座に `PutBucketPublicAccessBlock` APIを叩き、設定を強制的に `True` に書き戻す。
このフローにより、開発者が「一時的な検証のために」設定を緩めたとしても、数秒以内にシステムがそれを強制的に閉鎖する。これが、クラウドネイティブな防御アーキテクチャの基本形だ。
4. 生成AI時代の新たな脅威：プロンプトインジェクションとデータ流出
最後に、今のトレンドである生成AIとの関連に触れておく。最近のインシデントで増えているのは、LLMのRAG（検索拡張生成）に利用するS3バケットが、過度な権限設定によって「プロンプトインジェクション」の標的になるケースだ。
攻撃者は、LLMの応答を操作して、S3の機密情報を参照させようとする。もしS3のバケットポリシーが広範であれば、LLMを経由して内部の機密ドキュメントが外部へ漏洩する。
防御策としてのガードレイル:
- IAMロールのセッションポリシー: LLMが利用するIAMロールには、特定のプレフィックス（例: `/public-docs/`）以外へのアクセスを `Deny` するセッションポリシーを動的に適用する。
- データ保護: S3 Object Lockを併用し、AIによる書き込みや削除を物理的に防ぐ設計にする。
結びに代えて：セキュリティは「設定」ではなく「哲学」
結局のところ、S3のセキュリティは「バケットポリシーをどう書くか」といった枝葉の話ではない。「データがどこへ流れるべきか」というデータフローを定義し、それをIAMの評価ロジックで強制するという、一貫したアーキテクチャの哲学があるかどうかが分かれ道となる。
「便利だから」「一旦公開にしておこう」という妥協が、数ヶ月後の大規模なデータ侵害に繋がる。我々エンジニアに求められているのは、ツールを使いこなす知識以上に、最悪の事態を想定して「許可の範囲」を極限まで絞り込む、その冷徹なまでの疑心暗鬼である。
明日、貴方の環境の `Block Public Access` が全て `True` であることを確認してほしい。それが全ての出発点だ。
コメント