「鍵をかけたはずなのに泥棒に入られた？」AWS S3の守り方、基本の「キ」
こんにちは。セキュリティの世界で長く戦っていると、「完璧に設定したはずなのにデータが漏れた」という悲痛な相談をよく受けます。
実は、セキュリティの事故の多くは、暗号の解読といった映画のような話ではなく、「家の玄関の鍵を開けっ放しにしていた」「窓に少しだけ隙間があった」というような、ちょっとした設定ミスから始まります。
今回は、AWS S3という「クラウド上の巨大な金庫」を、泥棒から守るための最初の一歩を一緒に学んでいきましょう。
—
1. なぜS3は「設定ミス」で狙われるのか？
S3バケットは、インターネット上のどこからでもアクセスできる「公開設定」が簡単にできてしまう便利な仕組みです。しかし、これが最大の弱点でもあります。
例えるなら、「自分の家の玄関ドアに、誰でも開けられる暗証番号をメモして貼り付けている」ような状態です。攻撃者は、自動化されたツールを使って、世界中の「鍵の開いている金庫」を24時間体制で探し回っています。
2. まずは「パブリックアクセスブロック」で門前払い
AWSには、非常に優秀な「門番」がいます。それが「パブリックアクセスブロック」機能です。
これは、どんなに設定を間違えて「誰でも見れる」状態にしてしまっても、「いや、ここは私の管理下以外からのアクセスは全部遮断する！」と物理的にシャットアウトしてくれる強力な盾です。
- 設定方法： AWSコンソールのS3バケット設定から「ブロックパブリックアクセス」の項目へ飛び、すべてのチェックボックスをオン（有効化）にしてください。
これだけで、誤って外部に公開してしまうリスクを9割以上排除できます。まずはここを固めるのが、プロとしての第一歩です。
3. 「ACL」という古い鍵は捨てて、「バケットポリシー」という新しい契約書を使おう
少し専門的な話になりますが、S3には「ACL（アクセスコントロールリスト）」と「バケットポリシー」という2つの管理方法が混在しています。
- ACL： 昔ながらの「誰にどのファイルを見せるか」を個別に設定する方式。複雑になりやすく、ミスが起きやすい。
- バケットポリシー： 「誰が、どのバケットに対して、何ができるか」をJSON形式で細かく定義する方式。
今のAWSでは、「ACLを無効化（S3 Object Ownershipを『バケット所有者強制』に設定）」し、ポリシーベースで管理するのがセキュリティの鉄則です。
実際に使う「バケットポリシー」の例
「特定のIAMユーザーだけが読み書きできる」という安全な契約書（ポリシー）のサンプルです。これを適用することで、部外者の侵入を許さない「契約書ベースのセキュリティ」を実現します。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowSpecificUserOnly",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:user/YourUserName"
},
"Action": ["s3:GetObject", "s3:PutObject"],
"Resource": "arn:aws:s3:::your-bucket-name/*"
}
]
}※このコードを適用する際は、arn:aws:iam::123456789012:user/YourUserName の部分を、実際に使うユーザーのIDに書き換えてくださいね。
4. 暗号化は「金庫の中の金庫」
ここまでで「玄関」と「契約書」の話をしましたが、万が一データが持ち出されたとしても、中身が読めないようにするのが「暗号化」です。
S3では「AES-256」という強力な共通鍵暗号が標準で使えます。バケットの「デフォルト暗号化」を有効にするだけで、保存されるデータは自動的に暗号化されます。これは「金庫の中の書類を、解読不能な特殊なインクで書き換える」ようなイメージです。
最後に：セキュリティは「一度設定して終わり」ではない
最後に、私から伝えたい一番大切なことがあります。
セキュリティ対策は、一度設定して安心するものではありません。AWSには CloudTrail という「金庫の出入りをすべて記録する防犯カメラ」があります。時々、誰がいつ金庫にアクセスしたか、ログを覗いてみてください。
「完璧」を目指すのではなく、「もしミスをしても、被害を最小限に抑える仕組み（多重防御）」を作ること。これが、私たちエンジニアが信頼されるための近道です。
一歩ずつ、着実に。今日の設定が、あなたのサービスを救うことにつながります。頑張っていきましょう！
コメント