S3バケットは「鍵をかける」だけでは足りない――エンジニアが陥る「公開設定」の罠と防衛術
やあ。現場の最前線でコードを書き、夜中にアラートに飛び起きる諸君、お疲れ様。
AWS S3のセキュリティ事故が後を絶たない。ニュースで「またか」と思うようなS3の設定ミスによる個人情報流出だが、これらは決して「技術的に難しいこと」ではない。むしろ、「デフォルトの安心感」と「利便性の誘惑」に負けたヒューマンエラーが大半だ。
今日は、教科書的な「S3を公開するな」という警告の一歩先、「IAMとバケットポリシーを組み合わせた多層防御の実装」について、泥臭い現実を交えて解説する。
—
1. なぜ「パブリックアクセスブロック」だけでは不十分なのか
まず基本だ。AWSの「S3 パブリックアクセスブロック」は最強の盾だ。これを有効にしていれば、バケットポリシーでどれだけヘマをしても、外部からのアクセスは遮断される。まずはこれを全バケットで有効にしろ。
しかし、実務では「特定のCloudFrontからのみ許可したい」「社内VPN経由でのみアクセスを許可したい」といった複雑な要件が出てくる。ここで多くのエンジニアは、焦ってバケットポリシーを広げすぎる。
攻撃者が狙う「設定の盲点」
攻撃者は`s3-bucket-scanner`のようなツールを使い、片っ端から公開されているバケットを探している。特に狙われるのは以下の設定ミスだ。
- `Principal: “”` を使用し、Condition句でリファラー制限のみを行っている: リファラーは偽造可能だ。これだけで安全だと思っているなら、今すぐ考えを改めるべきだ。
- IAMユーザーの権限が広すぎる: 特定のバケットにのみアクセスさせたいのに、`s3:` を許可している。万が一そのIAMキーが流出したら、バケット内の全データが人質になる。
—
2. 最小権限の原則：IAMポリシーによる「二重の壁」
バケットポリシー（リソースベース）とIAMポリシー（アイデンティティベース）を組み合わせるのが鉄則だ。
「バケットポリシーで許可範囲を定義し、IAMポリシーで操作権限を絞る」。この二段構えが、設定ミスによる被害を最小限に抑える。
セキュアなIAMポリシーの実装例（Python/Boto3で操作するサーバー用）
サーバーから特定のバケットのみを操作させたい場合のポリシー設定だ。`Resource`にバケット名とパスを指定して、広範囲な操作を禁止する。
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Sid”: “AllowSpecificBucketAccess”,
“Effect”: “Allow”,
“Action”: [
“s3:PutObject”,
“s3:GetObject”
],
“Resource”: [
“arn:aws:s3:::my-secure-app-bucket/”
// バケット全体ではなく、オブジェクトに対してのみ許可する
]
}
]
}
—
3. 実践：CloudFront経由のみを許可する堅牢なバケットポリシー
WebアプリケーションでS3上の画像やJSファイルを配信する場合、S3を直接公開してはいけない。 必ずCloudFrontを挟み、S3側は「OAC (Origin Access Control)」を使用してCloudFrontからのアクセスのみを通す設定にする。
以下は、CloudFrontからのアクセスのみを許可するバケットポリシーのサンプルだ。
{
“Version”: “2012-10-17”,
“Statement”: {
“Sid”: “AllowCloudFrontServicePrincipal”,
“Effect”: “Allow”,
“Principal”: {
“Service”: “cloudfront.amazonaws.com”
},
“Action”: “s3:GetObject”,
“Resource”: “arn:aws:s3:::your-bucket-name/”,
“Condition”: {
“StringEquals”: {
“AWS:SourceArn”: “arn:aws:cloudfront::123456789012:distribution/EDVBD632BHOS5”
// 特定のCloudFrontディストリビューションからのみ許可する（なりすまし防止）
}
}
}
}
—
4. エンジニアへのアドバイス：インシデントを未然に防ぐ「守りの姿勢」
最後に、現場で戦う諸君に伝えたいことがある。
1. Infrastructure as Code (IaC) を徹底せよ: 手動でコンソールからポチポチ設定してはいけない。TerraformやCDKでコード化し、`checkov` や `tflint` といった静的解析ツールをCI/CDパイプラインに組み込め。設定ミスを「コードのレビュー」で弾くのが最もコストが低い。
2. ログの監視: CloudTrailでS3へのアクセスログを有効にしろ。普段と違うIPからの大量の`GetObject`は、攻撃の予兆だ。
3. 「怖い」と思える感覚を忘れるな: 「まあ、社内用だし」「開発環境だし」という甘い考えが、最大の脆弱性になる。
セキュリティは「完成したら終わり」ではない。常に攻撃者の視点を持ち、自分たちの設定を疑い続けることだ。もし設定に迷ったら、一番厳しい設定をデフォルトとし、そこから必要最小限の例外を許可する形をとれ。
君たちの書くコードとインフラが、強固な防壁になることを期待している。健闘を祈る。
コメント