こんにちは！インフラやセキュリティの世界へようこそ。
初めてクラウドを触るとき、「AWSのS3って便利だな、とりあえずファイルをポンと置いておこう！」とワクワクしますよね。でも、その便利さの裏側で、ちょっとした設定のミスが「世界中に会社の秘密を全公開しちゃった！」という大インシデントに繋がってしまうことをご存知でしょうか？
今回は、新人のIT担当者や、これからセキュリティをしっかり学んでいきたい開発者の皆さんに向けて、S3バケットの「パブリックアクセスブロック」と「暗号化の強制」について、身近な防犯に例えながら分かりやすく紐解いていきたいと思います。一歩ずつ、確実に安全な環境づくりのコツを掴んでいきましょう！
—
1. 家の鍵とS3バケット：なぜ「丸見え」になってしまうのか？
皆さんが住んでいる自宅を想像してみてください。玄関のドアには頑丈な鍵がついていますよね。でも、もし引っ越してきた初日に「誰でも自由に出入りできるように、鍵を開けっ放しにして、表札に『どうぞお入りください』と書いておこう」とする人はいませんよね？
しかし、クラウドの世界（AWS）では、この「鍵を開けっ放しにした状態」がうっかり起きてしまいがちなんです。
Amazon S3は、データを保存しておく「バケット」という箱のようなものを作ることができます。初期設定では「安全」に配慮されていますが、少し昔の知識や、ネット上の古いブログ記事を参考に設定していると、「誰でもこの箱の中身を見られる状態（パブリックアクセス）」にしてしまう穴が生まれてしまうのです。
泥棒（悪意あるボット）は、24時間365日、インターネット上の自動巡回ツールを使って「鍵の掛かっていないS3バケット」を探し回っています。見つかったが最後、顧客の個人情報や社外秘のソースコードがごっそり盗まれ、ニュースのトップを飾る……なんてことが、現実の現場では後を絶ちません。
だからこそ、「どんなミスをしても、絶対に外から中身が見えないようにする強力な鉄板ルール」を組織全体で敷く必要があるのです。それが今回お伝えする「S3バケットのパブリックアクセスブロック」です。
—
2. パブリックアクセスブロックで「絶対に開かない二重ロック」をかける
「うっかり公開設定にしてしまうかもしれない」というヒューマンエラーを防ぐために、AWSには「Amazon S3 パブリックアクセスブロック（アカウントレベル / バケットレベル）」という神様のような機能が用意されています。
これは、開発者がどんなに「公開設定」に変更しようとしても、AWS側が「いや、組織のルールとしてそれは絶対に許可しません！」と強制的にブロックしてくれる仕組みです。玄関の鍵の上から、さらに頑丈なチェーンロックをガチャンとかけるようなイメージですね。
設定すべき項目は、基本的に以下の4つすべてを「有効（ブロック）」にします。
- ブロック公的アクセス (パブリックアクセスのすべてをブロック)
- これを有効にすると、ACL（アクセスコントロールリスト）やバケットポリシーによる意図しない一般公開の道をすべて断ち切ることができます。
現場のインフラ担当者としては、個別のバケットごとに設定するのではなく、AWSアカウント全体（Organizationレベル）でこのブロックをデフォルト有効化しておくのが鉄則です。「誰も例外なく、パブリックなS3は作れない」という大前提を最初に作ってしまうのが、最も安全で泥臭くない防犯対策になります。
—
3. 中身を見られても安心？「暗号化の強制」という最後の砦
さて、パブリックアクセスを完全にブロックして「外から泥棒に入れないようにしたぞ！」と安心していませんか？
実は、セキュリティの世界はそれだけでは甘いのです。万が一、AWSの基盤自体や、保存されているストレージのハードディスクが物理的に抜き出されたり、内部の不正な権限を持つユーザーに不正アクセスされたりした場合を考えてみましょう。
鍵の掛かったロッカーの中に宝箱が入っていたとしても、その宝箱自体に鍵（暗号化）が掛かっていなかったら、箱を開けられた瞬間に中身が丸見えになってしまいますよね。
そこで登場するのが、「暗号化されていないアップロードを拒否する（暗号化の強制）」という設定です。
S3にファイルをアップロードする際、データをめちゃくちゃな暗号文に変換（暗号化）してから保存するようにバケットポリシーで強制します。鍵を持っていない人（＝正式な手順を踏んでいないリクエスト）がファイルを置こうとしても、S3側が「おいおい、暗号化されていないデータは受け取れないよ！」と門前払いしてくれる仕組みです。
実践！暗号化を強制するバケットポリシーの書き方
百聞は一見にしかず。実際の現場でよく使われる、暗号化されていないアップロードを完全に弾き返すバケットポリシーのサンプルを見てみましょう。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyUnencryptedObjectUploads",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::your-secure-bucket-name/*",
"Condition": {
"Null": {
"s3:x-amz-server-side-encryption": "true"
}
}
}
]
}この設定のポイント（優しく解説！）
"Effect": "Deny": 「問答無用で拒否する」という最強の拒絶アクションです。許可（Allow）よりも拒否（Deny）が優先されるのがAWSのルールなので、この設定が強力な盾になります。"Action": "s3:PutObject": これは「S3に新しいファイルをアップロードする（置く）」という操作を指しています。"Condition"（条件）: ここがキモです。「s3:x-amz-server-side-encryption（サーバー側暗号化の指定）がNull（つまり、何も指定されていない、暗号化されていない状態）」である場合、そのアップロードを拒否するという条件を指定しています。
これさえ設定しておけば、開発者がうっかり暗号化を忘れたプログラムやツールからファイルをアップロードしようとしても、AWSがピシャリとエラーを返してデータを守ってくれます。
—
4. まとめ：安全なクラウドライフは「基本の徹底」から
今回は、S3バケットの「パブリックアクセスブロック」と「暗号化の強制」について、家の防衛術に例えて解説しました。
1. パブリックアクセスブロックで、うっかり公開のミスを物理的・システム的に防ぐ。
2. バケットポリシーによる暗号化の強制で、万が一中身にアクセスされてもデータを読ませないようにする。
セキュリティの対策と聞くと、なんだか難解な数式や複雑なプログラムを想像しがちですが、本質はとてもシンプルで「自分たちの家を守るための当たり前の施錠」の延長線上にあります。
新人の皆さんも、これから新しいバケットを作る機会があれば、必ずこの2つの鉄則が守られているかを確認する癖をつけてみてくださいね。一歩ずつ、確実に安全なエンジニアへの階段を登っていきましょう！応援しています！
コメント