【入門編】AWS S3バケットのパブリックアクセスブロック設定とACLの無効化 – アプリケーションセキュリティ & 安全な開発防御ガイド

S3バケットを「不用意に公開」させない!新人エンジニアのための守りの鉄則

こんにちは。現場で泥臭いインシデント対応を繰り返していると、どうしても「なぜ、あんなに堅牢なクラウドサービスが簡単に破られてしまったのか?」という問いにぶつかります。

実は、AWS S3のバケットが公開されてしまう事件の多くは、高度なハッキング技術が使われているわけではありません。例えるなら、「高級な金庫を買ったのに、ダイヤルを『0000』のままにして、さらに鍵をかけ忘れて玄関に放置していた」ような状態なのです。

今日は、S3の「パブリックアクセスブロック」と「ACLの無効化」について、セキュリティの基本を一緒に紐解いていきましょう。

1. S3バケットは「家の玄関」と同じです

AWS S3は、インターネットという巨大な街に建つ「貸し倉庫」のようなものです。

  • バケット: 倉庫そのもの。
  • オブジェクト: 倉庫の中にある荷物。
  • バケットポリシー/ACL: 倉庫の扉に誰が入れるか決める「鍵」や「入館証」。

攻撃者は、この街を24時間歩き回り、鍵がかかっていない倉庫がないか探しています。最近の攻撃ツールは非常に優秀で、世界中のS3バケットを片っ端から叩き、「お、ここなら中身が見られるぞ!」と瞬時に特定してしまいます。

「ACL」は古い時代の遺物

かつて、S3には「ACL(アクセスコントロールリスト)」という古い鍵の仕組みがありました。これは個別の荷物ごとに鍵をかけるようなもので、管理が非常に複雑になりがちでした。

「あれ?さっきのファイルは鍵をかけたっけ?」と混乱した末に、誰でも中身が見られる状態(パブリック公開)にしてしまうミスが多発したのです。

2. 最強の防御:「パブリックアクセスブロック」という「鉄の扉」

今のAWSには、ミスを防ぐための素晴らしい機能があります。それが「パブリックアクセスブロック(Block Public Access)」です。

これは、倉庫の扉に「どんなことがあっても、絶対に外部からの入室を許可しない」という物理的な封印シールを貼るようなものです。たとえあなたがうっかり「誰でも入れる」という設定をしてしまっても、AWS側が「いや、今はダメですよ」と強制的にブロックしてくれます。

設定のやり方はこれだけ!

AWSマネジメントコンソールでバケットを開き、「アクセス許可」タブを確認してください。「パブリックアクセスをブロック」という項目があれば、以下の4つすべてにチェックが入っている状態が正解です。

すべてチェックを入れて「変更を保存」を押すだけ!
[x] 新しいパブリックバケットポリシーまたはアクセスポイントポリシーを介したバケットとオブジェクトへのパブリックアクセスをブロックする
[x] 任意のパブリックバケットポリシーまたはアクセスポイントポリシーを介したバケットとオブジェクトへのパブリックアクセスをブロックする
[x] 新しいパブリック ACL を介したバケットとオブジェクトへのパブリックアクセスをブロックする
[x] 任意のパブリック ACL を介したパブリック ACL を介したバケットとオブジェクトへのパブリックアクセスをブロックする

3. 「ACL無効化」で一元管理する

次に大切なのが「ACLの無効化」です。先ほど触れた古い鍵(ACL)を完全に無効にし、IAM(AWSの権限管理システム)だけでアクセスを制御する設定です。

「IAM?何それ?」という方も安心してください。IAMは、その倉庫に「誰が・何をできるか」を一元管理する名簿のようなものです。ACLという別の管理台帳を廃止することで、「管理台帳が二つあることによる混乱(設定ミス)」を根本から排除します。

設定方法:バケット所有者の強制

バケットの「アクセス許可」タブの「オブジェクト所有者」セクションを確認し、「ACL 無効 (推奨)」になっているか確認してください。

/
もしTerraformなどのコードで管理しているなら、
設定はシンプルに記述できます。
/
resource “aws_s3_bucket_ownership_controls” “example” {
bucket = aws_s3_bucket.example.id
rule {
object_ownership = “BucketOwnerEnforced” # これでACLを無効化し、バケット所有者に権限を統一
}
}

4. 最後に:セキュリティは「性悪説」で考える

セキュリティのプロとして皆さんに一つだけアドバイスがあります。それは、「自分は間違える」という前提でシステムを組むことです。

  • 手動で設定するのではなく、TerraformやAWS CDKなどの「コード」でインフラを管理する。
  • 開発環境のバケットであっても、本番環境と同じ「パブリックアクセスブロック」を適用する。
  • AWS Configを使って、パブリック設定が変更されたら即座にアラートを飛ばす。

「自分だけは大丈夫」と思っている時ほど、攻撃者はあなたの隙を突いてきます。まずは今すぐ、皆さんが管理しているバケットの「パブリックアクセスブロック」が有効になっているか、確認してみてください。

もし設定が漏れていたら、それは「ミス」ではありません。「改善のチャンス」です。一歩ずつ、強固な防御を築いていきましょう!

コメント

タイトルとURLをコピーしました