설명
S3 버킷 정책에서 와일드카드 Principal은 넓은 범위의 주체를 대상으로 합니다. Allow 구문에 필요한 제한이 없으면 의도하지 않은 주체도 지정된 작업을 수행할 수 있습니다. 실제 권한은 작업, 리소스, 조건, 명시적 거부와 S3 공개 접근 차단(Block Public Access)에 따라 달라집니다.
고정된 조직이나 IP 범위 등의 조건으로 접근을 제한할 수 있으므로, 와일드카드만으로 모든 인터넷 요청이 허용된다고 판단해서는 안 됩니다. 제한 조건이 실제 요구 사항에 맞는지 확인하고, 공개 읽기가 필요하더라도 쓰기나 삭제까지 허용하지 마세요.
잠재적 영향
- 불필요한 읽기 권한은 허용된 작업과 리소스 범위에 따라 객체 내용이나 버킷 내 객체 목록을 노출할 수 있습니다.
- 쓰기·삭제 권한까지 허용되면 객체 변경, 데이터 손실 또는 서비스 중단으로 이어질 수 있습니다.
- 조건이나 공개 접근 차단을 완화하면 기존 정책의 접근 범위가 넓어질 수 있습니다.
해결 방법
- 필요한 주체, 작업과 버킷·객체 ARN으로 권한을 제한하세요. 와일드카드가 필요한 경우에는 유효하고 충분히 좁은 조건을 적용하세요.
- 정책 전체의 허용과 거부, ACL과 공개 접근 차단을 함께 점검하고 승인된 요청과 차단할 요청을 검증하세요.
- 공급자와 모듈 버전에 맞게 정책을 적용하고
terraform plan을 확인하세요.terraform-aws-modules/s3-bucket/aws3.7.0에서는 사용자 지정policy를 적용하려면attach_policy = true가 필요합니다.
예시
다음은 IP 조건이 있는 허용과 거부를 비교하는 부분 예시입니다. aws_s3_bucket.example을 별도로 정의하고, 문서용 IP 주소를 실제 필요한 출발지로 바꾸세요. 두 정책을 동시에 같은 버킷에 적용하지 마세요.
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 조건에 맞는 요청에만 명시적 거부를 적용합니다. 나머지 출발지의 접근을 차단하는 정책은 아니며, 정상 사용자의 요청도 거부할 수 있습니다. 필요한 권한을 고려해 정책 전체를 설계하세요.