【入門編】 S3バケットのパブリックアクセス設定とACLの誤設定による情報漏洩 – オフェンシブセキュリティ & リバースエンジニアリング防御ガイド

こんにちは！クラウドでのシステム開発、日々お疲れ様です。
最近はAWSなどのクラウドサービスを使うのがすっかり当たり前になりましたよね。「サーバーを自分で組み立てなくていいから、すごく便利！」と感じている開発者の方も多いはずです。

さて、そんな便利なクラウド生活の中で、初心者のエンジニアやインフラ担当者が一番やらかしやすい（そして攻撃者から一番狙われやすい）のが、Amazon S3（Simple Storage Service）の公開設定ミスなんです。

今回は、なぜS3の誤設定がこれほど危険なのか、攻撃者はどうやってそこに入り込むのか、そしてどうやってそれを防げばいいのかを、身近な「お家の防犯」に例えながら、一歩ずつ優しく紐解いていきたいと思います。一緒にしっかり学んでいきましょう！

—

1. 身近な防犯で考える「S3のパブリックアクセス」

まず、S3バケットというのは、インターネット上にある「巨大な貸し倉庫」のようなものだと思ってください。画像やPDF、バックアップデータなど、あらゆるファイルをポンと置いておくことができます。

この倉庫には、当然「鍵」をかけることができますよね。

プライベート設定（安全な状態）: 倉庫の鍵はあなた（またはあなたのシステム）だけが持っていて、合鍵を持っている人しか中に入れません。
パブリックアクセス設定（危険な状態）: 倉庫のシャッターが開きっぱなしになっていて、通りすがりの誰でも中に入り、勝手に荷物を見たり持ち出したりできるようになっています。

「えっ、シャッターを開けっ放しにする人なんているの？」と思われるかもしれませんが、これが意外と多いんです。
例えば、Webサイトの画像を表示するために一時的に設定を緩めたまま忘れてしまったり、設定画面の英語が難しくて「とりあえず全部OK」にしてしまったり……。

攻撃者は、この「シャッターを開けっぱなしにした倉庫」を、インターネットの海で24時間休まず探し回っています。見つかれば、社内の機密情報やお客様の個人情報が、一瞬で世界中にばら撒かれてしまうことになるのです。

—

2. なぜ設定ミスが起きるのか？（ACLとバケットポリシーの罠）

S3で情報漏洩が起きる原因の多くは、AWSの権限管理の仕組みが少し複雑なことにあります。

S3へのアクセス権をコントロールする方法には、主に「ACL（アクセスコントロールリスト）」と「バケットポリシー」の2つがあります。

1. ACL: ファイル単位やバケット単位で、昔ながらの「誰に読ませるか」を設定する古い仕組みです。ここを「全員（Everyone）」に許可してしまうと、その中のデータが世界中に公開されてしまいます。
2. バケットポリシー: 倉庫全体のルールをJSONという書き方でガチッと決める、現代の主流の仕組みです。

「うっかりACLで全員に読めるようにしてしまった」あるいは「バケットポリシーで公開範囲を広げすぎてしまった」というミスが重なると、AWS側が用意している最強の盾である「ブロックパブリックアクセス（Block Public Access）」機能を有効にしていない限り、データは丸見えになってしまいます。

—

3. 攻撃者はどうやってその「開いた倉庫」を見つけるのか？

私たちがペネトレーションテスト（侵入テスト）を行う際、公開されたS3バケットを探すのは驚くほど簡単です。攻撃者も全く同じ手法を使っています。

① 勘やツールによるバケット名の推測

S3のバケット名は、インターネット上で「世界に一つだけ」の名前である必要があります。そのため、攻撃者は次のような名前を自動ツールで大量に生成し、存在を確認します。

company-name-backup
sample-app-images-dev
prod-customer-data

② URLへの直接アクセス

バケット名が分かれば、ブラウザから https://[バケット名].s3.amazonaws.com/ や https://s3.amazonaws.com/[バケット名]/ にアクセスするだけで、設定がミスっていれば中のファイルの一覧がズラリと表示されてしまいます。

特別なハッキング技術すら不要で、ただ「ドアノブをガチャガチャと回して、鍵がかかっていなかったら入る」というレベルの侵入行為なのです。

—

4. 最小限の権限で守る！安全な設定手順

「じゃあ、どうやって守ればいいの？」という話ですよね。
基本方針はシンプルです。「最初からすべてを禁止し、必要な最小限だけを許可する（最小権限の原則）」を徹底することです。

ここからは、実務でそのまま使える安全な設定手順を見ていきましょう。

手順1：大元の元栓をしめる「ブロックパブリックアクセス」の有効化

まずは、AWSアカウント全体、またはバケット単位で「いかなる理由があっても、パブリック公開は絶対にさせない」という最強の盾を有効にします。これをしておけば、万が一ACLやポリシーを間違えても、AWSが強制的にシャッターを下ろしてくれます。

AWSマネジメントコンソールから対象のS3バケットを開き、「アクセス許可」タブの「パブリックアクセスをブロック (バケットの設定)」で、以下のすべてにチェックが入っていることを確認してください。

パブリックアクセスをブロックする (すべての設定): オン

これだけで、外部からの不正アクセスの9割は防げます。

手順2：安全なバケットポリシーの書き方

どうしても特定のファイルを一般公開したい場合（例えば、Webサイトのアイコン画像など）は、バケットポリシーを使って慎重に許可を与えます。

以下は、「特定のバケット内にある画像ファイルだけを、世界中の誰でも読み取り可能にする」ための安全なバケットポリシーのサンプルです。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PublicReadForSpecificFolderOnly",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::your-bucket-name/images/*"
    }
  ]
}

【コードのポイント解説】

"Sid": このルールの名前（識別子）です。後から見た時に何のルールかわかるように日本語などでメモを残すのもおすすめです。
"Effect": "Allow": アクセスを許可します。
"Principal": "*": すべてのユーザー（インターネット上の全員）を対象にします。
"Action": "s3:GetObject": ファイルの「読み取り（ダウンロード・表示）」だけを許可します（ファイルを書き換えたり削除したりする権限は絶対に与えません）。
"Resource": "arn:aws:s3:::your-bucket-name/images/*": ここが一番重要です！ バケット全体ではなく、images/ という特定のフォルダの中身だけに絞って許可をしています。これなら、他の大切なデータがさらされる心配はありません。

—

5. まとめ：安全なクラウドライフを送るために

S3の設定ミスによる情報漏洩は、技術的な難易度が高いサイバー攻撃というよりも、いわば「鍵の締め忘れ」のようなヒューマンエラーに近いものです。だからこそ、誰でも起こり得るミスだと言えます。

大切なポイントをもう一度おさらいしておきましょう！

1. まずはブロックパブリックアクセスを有効にする！（迷ったら全部オン）
2. ACLではなく、バケットポリシーで細かく管理する！
3. 公開範囲はバケット全体ではなく、必要なファイルやフォルダだけに絞る！

セキュリティの対策は、一度覚えてしまえば次からは当たり前にできるようになります。
「一歩ずつ安全な設定を覚えて、自信を持って開発を楽しんでいきましょう！」

あなたのクラウド環境が、今日も安全で頑丈に守られますように。次の解説もお楽しみに！