はじめに
AWSのバケットポリシーは、S3バケットとその中のオブジェクトへのアクセス権をJSONで定める仕組みです。誰が、どの操作（例：読み取り、書き込み、削除）を、どのリソースに対して行えるかを細かく設定できます。これにより、公開・非公開の管理や社内限定のアクセス制御が簡単になります。
なぜ重要か
- セキュリティの基本を作る：誤って公開するとデータが外部に出るため、アクセスを明確に制限します。
- 柔軟な共有：特定のユーザーやIPからのみアクセスを許可できます（例：社内ネットワークからのみ画像を取得可）。
- 最小権限の実現：必要な操作だけを許可してリスクを減らします。
短い具体例
- ウェブ公開用の画像バケットは「読み取りを全員に許可」することがあります。
- バックアップ用のバケットは「社内の管理者だけに読み書きを許可」することが一般的です。
本書では、バケットポリシーの役割、主要な要素、よくある利用パターン、注意点を順に分かりやすく解説します。
バケットポリシーの役割
バケットポリシーは、S3バケットへのアクセスを一か所で決めるための仕組みです。主にPrincipal（誰が）、Action（どの操作を）、Resource（どのバケットやオブジェクトに）、Condition（どんな条件で）の四つを組み合わせて許可や拒否を設定します。
Principal（誰が）
アクセス主体を指定します。IAMユーザーやロール、別アカウントのアカウントID、あるいは匿名（すべてのユーザー）を指定できます。例えば、社内の特定ロールだけ許可する、といった制御が可能です。
Action（どの操作を）
GetObjectやPutObjectのような具体的な操作を指定します。読み取りだけ許可したり、書き込みだけ拒否したりと細かく分けられます。
Resource（どのバケットやオブジェクトに）
ポリシーが適用されるバケット名やオブジェクトのパスを指定します。バケット全体や特定のプレフィックスにだけ適用することができます。
Condition（どんな条件で）
発効条件を追加します。例として、特定のIPアドレスからのアクセスのみ許可する、TLS（HTTPS）を必須にするなどがあります。条件を使うとセキュリティを高められます。
組み合わせでできること
バケットポリシーはIAMポリシーと併用します。IAMがユーザー単位での許可を管理し、バケットポリシーでバケット側の制約を課せます。別アカウントからの読み取り許可やIP制限、HTTPS強制など実務でよく使う設定を一元管理できます。したがって、運用ルールを明確にしやすくなります
主な構成要素
バケットポリシーは複数の「Statement」で成り立ち、それぞれが以下の要素で構成されます。簡単な例を交えながら説明します。
Effect（許可か拒否か）
操作を許可するか拒否するかを示します。値はAllowかDenyです。例：
"Effect": "Allow"
明示的なDenyは強い制約になります。
Principal（対象）
誰に対するルールかを指定します。ユーザー、ロール、アカウント、サービスなどが入ります。例：
"Principal": {"AWS": "arn:aws:iam::123456789012:role/ExampleRole"}
Action（操作）
許可・拒否する具体的な操作です。s3:GetObjectやs3:PutObjectなどを指定します。ワイルドカードでまとめることもできます（例：s3:*）。
Resource（対象リソース）
どのバケットやオブジェクトに適用するかをARNで指定します。例：
"Resource": "arn:aws:s3:::my-bucket/*"
バケット全体とオブジェクト単位で使い分けます。
Condition（追加条件）
IPアドレスや接続の安全性、時間帯などでさらに絞れます。例：IP制限
"Condition": {"IpAddress": {"aws:SourceIp": "203.0.113.0/24"}}
TLS必須は”Bool”:{“aws:SecureTransport”:”true”}のように指定します。
これらを組み合わせて1つのStatementを作り、複数並べてポリシーを構成します。
よくある利用パターン
1. 特定IPからのみアクセス許可
社内ネットワークのIPからだけバケットを見られるようにします。たとえば勤務先の固定IPだけ許可すると、外部からの閲覧を防げます。具体例：社内からの読み取りは可、外部は不可にする設定です。
2. 特定アカウント／ロールに限定した読み書き
開発チームや運用のロールだけ書き込みを許可し、他は読み取りのみ、あるいは完全にアクセス不可にします。たとえばログを送る専用アカウントだけ書き込みOKにする運用が多いです。
3. 削除禁止のポリシー
誤削除を防ぐため、オブジェクト削除を拒否するルールを入れます。バックアップや監査ログの保存先に有効です。必要な場合は特定の管理者だけ削除可能にします。
4. HTTPS以外のアクセス拒否
暗号化されていない接続を拒否して、安全性を高めます。ブラウザやアプリが常にHTTPSを使うように統制できます。
5. 複数アカウントからのログ集約バケット
複数のAWSアカウントやサービスからログを一つのバケットに集めるパターンです。各アカウントに書き込み権限だけ与えて、読み取りや削除は限定的にします。
それぞれ、目的に応じて細かく権限を分けると安全に運用できます。
注意点
バケットポリシーは便利ですが、小さな誤りで大きな障害につながります。ここでは実務で特に注意すべき点をわかりやすくまとめます。
ポリシーサイズの上限（20KB）
バケットポリシーは最大20KBまでしか保存できません。複雑な条件や多数のステートメントを入れると上限に達します。例として、個別のIPや細かい許可を大量に書くとすぐ超えます。対策としては、不要な記述を省く、共通の条件はIAMポリシー側へ移す、またはタグやプレフィックスでまとめて指定する方法があります。
明示的なDenyは常に優先される
ポリシー内の明示的なDenyは、他のAllowよりも優先されます。たとえば「すべてのユーザーを拒否する」ような広すぎるDenyを書いてしまうと、本来の管理者もアクセスできなくなります。したがって、Denyは必要最小限にとどめ、条件を明確に指定してください。
ルートユーザーやオーナーへの影響
バケットポリシーの設定ミスで、アカウントのルートユーザーやオーナーでもアクセスできなくなるケースがあります。実際にアクセスが止まると復旧が難しくなるため、重要操作はテスト環境で検証してから本番に適用してください。
設定ミスを防ぐ具体的対策
- 小さな変更を段階的に適用する。まずテストバケットで確認します。
- JSONの文法チェックとIAMポリシーシミュレータなどで事前に動作を検証する。
- ポリシーはコード管理（IaC）でバージョン管理し、ロールバック手順を用意する。
- 管理者用アカウントを別に用意し、バケットポリシーで誤って制限しないように注意する。
- アクセスログやCloudTrailを有効にして問題発生時に原因を追跡できるようにする。
最後に、Denyの影響範囲とサイズ制限を常に意識し、変更のたびに検証を行ってください。慎重に扱えば、安全に運用できます。
