女性向けエンジニアスクール
3秒でわかる
S3バケットに直接付けるJSON形式のアクセス制御ルール。誰がどの操作を許されるかをバケット側でまとめて決められ、別アカウントへの許可も出せます。
もう少し詳しく
どういうものか
バケットポリシーは、Amazon S3 のバケットに直接付けるアクセス制御の設定です。JSONで記述し、Effect Principal Action Resource Condition の要素で「誰が」「何に」「何をできるか」を表します。リソース側に付ける権限なので、AWSアカウントの外にいる相手にも許可を出せる点が特徴です。
なぜ必要か
IAMポリシーは利用者や役割に付ける権限で、自分のアカウント内の相手にしか効きません。別のアカウントからの読み取りを許したい、CloudFront経由のときだけ配信を許したい、暗号化されていないアップロードを拒否したい、といった要件はバケット側で決める必要があります。オブジェクト1つずつにACLを付ける方法もありますが、数が増えると管理できません。バケットポリシーなら、バケット全体の方針を1か所にまとめられます。
具体例
特定のアカウントにだけ読み取りを許可する形です。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowPartnerRead",
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::111122223333:root" },
"Action": ["s3:GetObject"],
"Resource": "arn:aws:s3:::my-report-bucket/reports/*"
},
{
"Sid": "DenyInsecureTransport",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::my-report-bucket",
"arn:aws:s3:::my-report-bucket/*"
],
"Condition": { "Bool": { "aws:SecureTransport": "false" } }
}
]
}後半の記述はHTTPでのアクセスを拒否するもので、多くの構成で定型的に入ります。
つまずきやすいところ
Resource の書き分けを間違えると動きません。オブジェクトへの操作は arn:aws:s3:::bucket/*、ListBucket のようにバケット自体への操作は arn:aws:s3:::bucket を指定します。片方だけ書いてアクセス拒否になる相談が非常に多いところです。
評価順も重要で、明示的な Deny はどんな Allow よりも優先されます。組織のポリシーやパブリックアクセスブロックの設定に Deny があると、バケットポリシーで Allow を書いても通りません。
そして最大の事故は "Principal": "*" で s3:GetObject を全体に許してしまう公開設定です。静的サイト配信のつもりで付けた設定が、置いた覚えのある全ファイルを世界中から読める状態にします。配信はCloudFrontを前面に置き、バケットは非公開のままにする構成が現在の定石です。
似た用語との違い
| 仕組み | 付ける先 | 主な用途 |
|---|---|---|
| バケットポリシー | バケット | バケット全体の方針、アカウント外への許可 |
| IAMポリシー | 利用者や役割 | 自アカウント内の権限設計 |
| ACL | バケットやオブジェクト | 旧来の方式で、現在は無効化が推奨 |
