説明
S3 バケットポリシーでワイルドカードの Principal を使うと、広い範囲のプリンシパルが対象になります。Allow ステートメントに適切な制限がなければ、想定外のプリンシパルも指定された操作を実行できる場合があります。実際の権限は、操作、リソース、条件、明示的な拒否、S3 のパブリックアクセスブロックに左右されます。
固定した組織や IP 範囲などの条件でアクセスを制限できるため、ワイルドカードだけでインターネット上のすべてのリクエストが許可されるとは限りません。条件が実際の要件に合っているかを確認してください。公開読み取りが必要でも、書き込みや削除まで公開する必要はありません。
想定される影響
- 不要な読み取り権限により、許可された操作とリソースの範囲でオブジェクトの内容やバケット内のオブジェクト一覧が公開される可能性があります。
- 書き込みや削除も許可すると、オブジェクトの変更、データ損失、サービス停止につながるおそれがあります。
- 条件やパブリックアクセスブロックを緩めると、既存ポリシーによるアクセス範囲が広がる場合があります。
対処方法
- 権限を必要なプリンシパル、操作、バケットまたはオブジェクトの ARN に限定してください。ワイルドカードが必要な場合は、有効な条件で範囲を十分に絞ってください。
- ポリシー全体の許可と拒否、ACL、パブリックアクセスブロックを併せて確認し、許可するリクエストと拒否すべきリクエストを検証してください。
- プロバイダーとモジュールのバージョンに合った方法でポリシーを適用し、
terraform planを確認してください。terraform-aws-modules/s3-bucket/aws3.7.0 でカスタムpolicyを適用するには、attach_policy = trueが必要です。
例
以下は IP 条件付きの許可と拒否を比較する部分的な例です。aws_s3_bucket.example は別途定義し、文書用の IP アドレスは必要な接続元のアドレスに置き換えてください。2 つのポリシーを同じバケットへ同時に適用しないでください。
IP 条件付きの許可
hcl
resource "aws_s3_bucket_policy" "public_policy" {
bucket = aws_s3_bucket.example.id
policy = <<POLICY
{
"Version": "2012-10-17",
"Id": "MYBUCKETPOLICY",
"Statement": [
{
"Sid": "IPAllow",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "s3:*",
"Resource": "${aws_s3_bucket.example.arn}/*",
"Condition": {
"IpAddress": {"aws:SourceIp": "203.0.113.10/32"}
}
}
]
}
POLICY
}
aws:SourceIp 条件に合うリクエストについて、オブジェクトリソースに適用される広範な S3 操作を許可します。すべての接続元への無条件の許可ではありませんが、その接続元で必要なプリンシパルと操作に権限を絞る必要があります。
IP 条件付きの明示的な拒否
hcl
resource "aws_s3_bucket_policy" "restricted_policy" {
bucket = aws_s3_bucket.example.id
policy = <<POLICY
{
"Version": "2012-10-17",
"Id": "MYBUCKETPOLICY",
"Statement": [
{
"Sid": "IPDeny",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": "${aws_s3_bucket.example.arn}/*",
"Condition": {
"IpAddress": {"aws:SourceIp": "203.0.113.10/32"}
}
}
]
}
POLICY
}
同じ IP 条件に合うリクエストだけを明示的に拒否します。ほかの接続元を遮断するポリシーではなく、正当な利用者のリクエストも拒否する場合があります。必要な権限を踏まえてポリシー全体を設計してください。