『ダメ!』と言うだけがセキュリティではない 〜Amazon S3 セキュリティの考え方〜

 こんにちは～　浮田です。  

■  TL;DR  

• S3のセキュリティは「公開設定に気をつける」だけじゃない。S3がデフォルトで守ってくれる範囲＋8つのベストプラクティスで積み増す、という構造で考えるとわかりやすい。
• 2026年4月からSSE-Cがデフォルト無効に(Codefingerランサムウェア対策)。実質、新規は全部SSE-S3で暗号化される。
• 2025年11月発表の新機能が熱い:組織レベルでBPA一括強制(宣言的ポリシー)、S3のABAC対応(タグでアクセス制御)。
• まず何をやる?は役割別で。開発者は手元(③⑥⑦)から、組織リーダーは組織全体のガードレールと監査(①③④⑤⑦)から。

AWS Summit Japan 2026のブレイクアウトセッション 「Amazon S3 セキュリティベストプラクティス」 を聴講してきました。予約は満席で当日参加枠での聴講でしたが、会場は 8〜9 割ほどの入り。

S3 を触る人なら誰でも持ち帰れる、実践的な内容でした。

■  目次  

1. AWS のセキュリティ原則
2. S3 がデフォルトで守ってくれていること
3. すぐにできる 8 つのベストプラクティス
4. 役割別の「次の一手」

■   1. はじめに：AWS のセキュリティ原則      

冒頭のメッセージは明快でした。AWS はセキュリティを最優先事項とし、それを「制約」ではなく「ビジネス価値の土台」として捉える、という考え方です。

• セキュリティ・耐久性・可用性・パフォーマンスの真の価値は、利用者がビジネス要件を達成できるようにすることにある
• セキュリティは全員の仕事である（設計者・運用者・利用者）
• 継続的・反復的な改善が不可欠である

■  2. Amazon S3 がデフォルトで守ってくれていること

（利用者の対応がいらない部分）

8 つのベストプラクティスに入る前に、まず S3 が標準で実施してくれている保護の整理がありました。ここは利用者が何もしなくても効いている部分です。

• Block Public Access がデフォルトで有効
• ACL がデフォルトで無効（Object Ownership の "Bucket owner enforced"）
• すべての新規オブジェクトが暗号化済み（SSE-S3 が自動で付く）
• チェックサムがデフォルトで有効
• SOAP インターフェースの廃止
• SSE-C がデフォルトで無効

最後の SSE-C のデフォルト無効は新しい変更です。背景には 2025 年 1 月に観測された Codefinger ランサムウェアがあります。

攻撃者が盗んだ認証情報で SSE-C（顧客提供キー）を使って S3 オブジェクトを暗号化し、復旧と引き換えに身代金を要求する手口でした。

これを受け、AWS は SSE-C を無効化できるようにし、2026 年 4 月から新規汎用バケット（および SSE-C 未使用アカウントの既存バケット）でデフォルト無効にしています。

つまり実質的に、新規はすべて SSE-S3 で暗号化され、SSE-C はレガシー（特別な要件がなければ使わない）扱いになりました。

SSE-C は鍵を毎回自分で渡す必要があり、AWS マネージドサービスと相性が悪いため、ほとんどのワークロードでは SSE-S3 / SSE-KMS で十分です。

参考: Security best practices for Amazon S3（S3 ユーザーガイド）

●  補足：S3 はもう「ただのオブジェクトストレージ」ではない  

 軽くおさらいしておくと、S3 には用途別のバケット・機能がいくつもあります。  

■    3. すぐにできる 8 つのベストプラクティス  

 ここが本編。S3 セキュリティを「① → ⑧」の順に積み上げていく構成です。  

●  ① データへのパブリックアクセスをブロックする（Block Public Access）  

• S3 汎用バケットではデフォルトで有効、S3 Access Points でも自動的に有効
• ディレクトリ／テーブル／ベクトルバケットには "Public" の概念自体がない
• ウェブホスティング用途はすべて Amazon CloudFront 経由にする（バケットを直接公開しない）

●  ② バケットキーを有効にする

• S3 汎用バケットで SSE-KMS を使うときのオプション
• AWS KMS のコストを最大 99% 削減できる
• S3 Tables では同様の仕組みが自動的に有効

「暗号化（SSE-KMS）はコストが気になって避けられがち」という課題に対し、Bucket Key がコスト面のハードルを大きく下げてくれる、という実践的なポイントでした。

●  ③ 統制を分離してスケールする  

 組織が大きくなると、1 つのバケットポリシーで全部を制御するのは限界が来ます。そこで 「統制の分離」＝アーキテクチャのモジュール化＋組織のモジュール化、という考え方が示されました。分離する場合の選択肢は次の 4 つです。  

S3 Access Points

ユースケースごとに独自のポリシーを持つバケットエンドポイントを提供します。

利用例として、営業部門とデータ分析チームでアクセスポイントを分け、SCP で VPC 利用を強制し、バケットポリシーで「VPC からのアクセスのみ許可（＝インターネットからのアクセスを禁止）」する構成が紹介されました。

Before: バケットポリシーだけで頑張る

After: アクセスポイントごとにコントロールする

S3 Access Grants

特定の AWS プリンシパル、またはフェデレーテッドプリンシパルに対して、バケットやプレフィックスへのアクセス権を動的・プログラムで付与します。AWS IAM Identity Center と連携し、個人にもグループにも権限を割り当てられるのが特徴です。

トークン自動販売機の考え方

任意の認可ロジックに基づき、最小スコープの一時認証情報をオンデマンドで発行するパターン。カスタム認証・認可を挟みたいケースで有効です。

ABAC（属性ベースアクセス制御）

タグ付けでアクセスを制御する仕組みが S3 にも来ました。

• S3 独自の PutBucketTagging ではなく、AWS 横断の標準 TagResource API に寄せる
• 汎用バケットはオプトインで ABAC をサポート（有効化すると PutBucketTagging は無効になる）
• S3 Tables・S3 Vectors も ABAC をサポート

ユーザー／ロール／バケットのタグをマッチさせて権限を自動付与できるため、組織がスケールしても IAM ポリシーを更新し続ける必要がなくなります（2025 年 11 月発表）。

参考: Introducing attribute-based access control for Amazon S3 general purpose buckets

●  ④ セキュリティ変更をモデル上でテストする  

ポリシー変更は事故のもと。テストの 3 原則が示されました。

• IaC ツールでテストスタックを構築する
• 正常系と異常系の両方をテストする（「アクセスできること」だけでなく「拒否されること」も検証）
• 変更のたびにテストを再実行する

●  ⑤ AWS Organizations でセキュリティを簡素化する  

組織レベルのガードレールの話。組織・OU・アカウントそれぞれに RCP / SCP を効かせる構成が示されました。

• Resource Control Policies (RCP) を組織レベルのガードレールとして使う
• 組織管理者のみがガードレールを変更できることを保証する
• ガードレールは新規・既存すべての AWS リソースに適用され、開発者は安全を保ちながら自由に開発できる
• RCP の例：Organizations 全体で S3 への非 TLS アクセスを拒否 Condition: aws:SecureTransport = false → Deny

Amazon S3 の Organizations ポリシー（宣言的ポリシー）

1 回の API コールで、組織または OU 内のすべてのアカウントのすべての S3 リソースに Block Public Access を強制できるようになりました。ルートや OU にポリシーを付ければ配下の全アカウントに伝播し、新規メンバーアカウントも自動継承します。これまで BPA 強制のために複雑な SCP を組んでいた運用が不要になります（2025 年 11 月発表）。

参考: Amazon S3 Block Public Access now supports organization-level enforcement

アクセス拒否メッセージの強化

同一アカウント／同一 Organization 内のリクエストに対する 403（Access Denied）エラーに、アクセスを拒否したポリシーの種類・拒否理由・リクエストした IAM ユーザー/ロールの情報といった追加コンテキストが含まれるようになり、権限のトラブルシューティングが格段に楽になりました。

＜補足：アクセス拒否時(403)の課金ルール（混同しやすいので整理）＞

このメッセージ強化とは別に、403 には課金ルールがあります。向きを間違えやすいので明記しておきます。

• 組織の"外部"からの 403 → 課金されない（攻撃者がバケット名を推測して叩くようなケース。2024 年の「空バケットで請求爆発」問題への対応）
• 同一アカウント／同一 Organization "内"からの 403 → 通常どおり課金対象（＝自分たちの設定ミスで弾かれているケース）

セッションでは、外部 403 を無料にする理由として 「もし課金されるなら、攻撃者はバケット名さえ知っていれば、ひたすら拒否されるリクエストを投げつけて被害者の請求額を無限に膨らませられてしまう」 という点が挙げられていました。

いわゆる "Denial of Wallet"（財布への DoS） で、防ぎようのない他人由来のリクエストで課金される状態を解消するのが狙いです。

つまり「自分が悪くない外部由来の 403 は無料、自分の設定ミス由来の内部 403 は課金」という、責任の所在で扱いを分ける設計です。そして内部の 403 だからこそ詳細なエラーメッセージを返してトラブルシュートを助ける、という一貫した思想になっています。

参考: Billing for Amazon S3 error responses / Troubleshoot access denied (403 Forbidden) errors in Amazon S3

●  ⑥ S3 のデータ保護をアプリケーションにも広げる  

S3 内だけでなく、アプリで生成した瞬間から S3 に届くまで途切れなく保護するという考え方です。

• チェックサムを作成時から付与し、データライフサイクル全体で維持する
• すべての永続ストレージを暗号化する（キーローテーションと監査付き）
• データ転送中も常に暗号化する（TLS とプライベート VPC を使用）

S3 がデフォルトでチェックサム値を付ける

ChecksumAlgorithm を指定しない場合、デフォルトで CRC64-NVME が付与されます。クライアント／API／ストレージの各段でチェックサムを検証し、エンドツーエンドの完全性を担保します。

チェックサムとは？ データから計算した短い検証値のこと。受け取った側が同じ計算をして照合し、転送中・保存中にデータが壊れていないか（完全性）を確認する仕組みです。改ざん防止というより「破損検知」が主目的で、暗号的な用途には SHA-256 等を使い分けます。

●  ⑦ ログを有効にして、検知と対応を実装する  

 ログの選択肢として 2 つが比較されました。  

そして 「検知と対応はログ記録だけではない」として、次のステップが示されました。

• フォレンジック監査
• 異常検知とドリフト検出
• 自動即時修復（例：パブリックなバケットを自動スキャンして BPA を適用する）

ドリフト検出の文脈では AWS Config などのサービスが挙げられていました。設定があるべき状態から逸脱していないかを継続的に評価し、検知から修復まで自動でつなげていく、という流れです。

●  ⑧ 耐久性とリカバリを事前に計画する  

最後はデータ保護・復旧の打ち手。タイムライン形式で次の機能が紹介されました。

• S3 Conditional Writes（上書き事故の防止）
• S3 Object Versioning（誤削除・上書きからの復旧）
• S3 Object Lock（WORM、改ざん・削除の防止）
• S3 Replication（別バケット／別アカウント／別リージョンへの複製）
• AWS Backup（AWS Backup support for Amazon S3）

ランサムウェア対策の観点でも、バージョニング＋Object Lock＋別アカウントへのレプリケーション／バックアップの組み合わせが効いてきます。

■   4. 役割別のまとめ：やれることからやってみよう  

セッションの締めは、立場ごとの「次の一手」でした。8 個すべてを一度にやろうとすると重いので、自分の立場でやれることから始めるのが現実的です。セッションの役割別スライドをもとに整理すると、こうなります。

●  開発者・現場の方は → ③・⑥・⑦ から

• ③ 新しいタグ付け API（TagResource）に移行し、ABAC に備える
• ⑥ アプリケーションにエンドツーエンドのチェックサムを組み込む
• ⑦ 重要なバケットでログを有効にする
• ①＋⑤ AWS Organizations レベルで BPA を強制する（宣言的ポリシーで一括、RCP でガードレール）
• ③ 必要に応じて、チームを ABAC の採用に向けて推進する
• ④ テストスタックにリソースを割り当てる
• ⑦ 監査（ログ＝監査証跡）にリソースを割り当てる

いずれも**自分の手元（アプリ・バケット単位）**で完結し、組織全体の権限設計に手を入れずに始められるのがポイントです。

●  組織リーダーの方は → ①・③・④・⑤・⑦（監査目的）から

開発者＝手元から今日すぐに／組織リーダー＝組織全体のガードレールと監査基盤から、という住み分けで考えると着手しやすいです。完璧を目指さず、できるところから 1 つずつ積み上げていきましょう。

■   5. 所感

「S3 のセキュリティ＝公開設定に気をつける」くらいの認識だったのですが、このセッションでいい意味で覆されました。

一番印象に残ったのは「『ダメ!』と言うだけがセキュリティではない」という視点です。

S3 がデフォルトで守ってくれる範囲はどんどん広がっていて、残りを 8 つのベストプラクティスで積み増していく、という構造で語られたことでわかりやすかったです。

セキュリティは大事なので、この考え方を意識していきたいです。