AWS S3 버킷 정책 설정 실수 피하는 방법

AWS S3 버킷 정책 설정 실수 피하는 방법

AWS S3(Simple Storage Service)는 데이터를 저장하고 공유할 수 있는 가장 보편적이고 강력한 스토리지 서비스입니다. 하지만 버킷 정책(Bucket Policy)을 잘못 설정할 경우, 개인정보 유출, 서비스 장애, 보안 취약점 노출 등 심각한 사고로 이어질 수 있습니다. 특히 공용 액세스(Public Access)를 허용하거나 권한을 과하게 부여하는 실수가 자주 발생합니다.

이번 포스팅에서는 AWS S3 버킷 정책 설정 실수 피하는 방법을 중심으로, 실무에서 안전하게 S3를 관리할 수 있는 핵심 팁들을 구체적으로 안내합니다.

이 글의 목차

✅ S3 버킷 정책이란?

S3 버킷 정책은 JSON 형식의 문서로, 특정 사용자 또는 서비스가 S3 버킷에 대해 어떤 행동을 할 수 있는지를 정의하는 리소스 기반 정책(Resource-Based Policy)입니다.

Allow 또는 Deny를 통해 접근 제어
Principal, Action, Resource, Condition 등의 필드로 구성
IAM 정책과 달리, S3 리소스에 직접 부착

✅ 자주 발생하는 설정 실수 TOP 5

❌ 1. 전체 공개(Public Read/Write) 설정

{
  "Effect": "Allow",
  "Principal": "*",
  "Action": "s3:*",
  "Resource": "arn:aws:s3:::mybucket/*"
}

누구나 S3의 모든 객체에 접근, 수정, 삭제가 가능해짐
2021년 Accenture S3 유출 사고도 이와 같은 실수로 발생

🔐 해결 방법:

"Principal": "*" 절대 사용 금지
반드시 aws:userid 또는 aws:PrincipalArn 조건으로 제한

❌ 2. 퍼블릭 차단 기능 해제 후 방치

AWS S3는 기본적으로 퍼블릭 액세스를 차단하는 보호 기능을 제공합니다. 이를 일시적으로 해제했다가 다시 활성화하지 않으면 버킷이 노출됩니다.

✅ 팁:

버킷 생성 후 반드시 “퍼블릭 액세스 차단” 옵션을 켜두세요
필요 시 특정 객체만 presigned URL로 제한 공유

❌ 3. Deny 정책이 빠져 예외 상황 발생

버킷 정책에서 Allow만 선언하고 Deny를 명시하지 않으면, 악의적 우회 요청을 차단하지 못할 수 있습니다.

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:*",
  "Resource": "arn:aws:s3:::mybucket/*",
  "Condition": {
    "Bool": {
      "aws:SecureTransport": "false"
    }
  }
}

HTTP 요청은 거부하고, HTTPS 요청만 허용

📌 항상 최소 권한 원칙을 지키고, 조건부 Deny도 병행하는 것이 안전합니다.

❌ 4. 특정 Prefix에만 제한했는데 전체 접근 허용됨

"Resource": "arn:aws:s3:::mybucket/*"

실제로는 arn:aws:s3:::mybucket 버킷 루트 자체에 대한 권한이 필요함
이를 빼면 일부 작업(예: 목록 조회)에서 AccessDenied 발생 가능

✅ 해결 방법:

"Resource": [
  "arn:aws:s3:::mybucket",
  "arn:aws:s3:::mybucket/*"
]

❌ 5. 테스트용 정책을 운영 환경에 그대로 반영

개발 환경에서 임시로 "Action": "s3:*" 또는 "Principal": "*" 설정 후, 이를 복붙하여 운영 버킷에 그대로 적용하는 경우가 많습니다.

🚨 실수 방지 방법:

운영 정책은 Git 또는 SSM Parameter Store에서 버전 관리
적용 전 콘솔에서 시뮬레이션 기능 사용 (Policy Simulator)

✅ 안전한 S3 버킷 정책 설정 가이드라인

항목	권장 설정
공개 접근	원칙적으로 차단 (Presigned URL 또는 CloudFront로 대체)
접근 제어	IAM Role 또는 서비스 계정 기반으로 세밀하게 제한
전송 보안	`aws:SecureTransport: false` 조건으로 HTTP 요청 차단
객체 삭제 방지	`Deny`로 `s3:DeleteObject` 제한 또는 버전 관리 활성화
활동 로깅	S3 버킷에 CloudTrail 및 액세스 로그 설정 필수

✅ 모범 예시: 특정 IAM Role만 읽기 허용

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowReadOnlyToSpecificRole",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/MyAppReadOnlyRole"
      },
      "Action": [
        "s3:GetObject"
      ],
      "Resource": "arn:aws:s3:::my-secure-bucket/*"
    }
  ]
}

해당 역할을 가진 사용자/서비스만 읽기 가능
쓰기 및 삭제는 기본적으로 차단됨

✅ Q&A

Q. S3 정책과 IAM 정책 중 어느 것이 우선인가요?
→ 둘 다 적용됩니다.

둘 중 하나라도 Deny이면 거부
둘 다 Allow일 때만 성공
S3 버킷 정책은 리소스 기준, IAM 정책은 사용자 기준 제어

Q. S3 버킷을 외부에서 안전하게 공유하려면?
→ Presigned URL을 사용하세요.

제한된 시간 동안만 유효한 URL
GetObject, PutObject 요청에 대해 생성 가능
AWS SDK 또는 CLI에서 쉽게 생성 가능

aws s3 presign s3://mybucket/image.jpg --expires-in 3600

Q. 버킷 정책이 적용되지 않을 때 원인은?

퍼블릭 액세스 차단이 활성화되어 있으면 정책과 관계없이 거부
Principal 설정 오류 (Role, User ARN 잘못 입력)
Resource ARN 누락 또는 오타
S3 콘솔에서 변경 후 버전 캐시가 남아있을 수 있으므로, 수 초 대기 후 테스트

✅ 요약 정리

체크리스트	확인 여부
❌ `Principal: *` 사용 여부	☐ 금지
✅ 퍼블릭 액세스 차단 설정	☐ 활성화
✅ HTTPS 전용 전송 조건 추가	☐ 적용
✅ 최소 권한 정책 작성	☐ 적용 완료
✅ IAM 사용자 또는 역할 기반 제어	☐ 사용 중
✅ 버전 관리 및 액세스 로그 설정	☐ 활성화 완료

결론

AWS S3 버킷 정책 설정 실수 피하는 방법을 숙지하면 보안 사고 가능성을 획기적으로 줄일 수 있습니다. 특히 실수로 인한 데이터 유출은 대부분 정책 한 줄로부터 시작되며, 사전 점검과 모범 정책을 통해 충분히 예방이 가능합니다. 신중하게, 반복적으로 검토하고, 보안은 “한 번 설정”이 아닌 지속적인 관리임을 꼭 기억하세요.