S3 버킷 정책 vs ACL: 무엇이 다른가?
1. 버킷 정책 (Bucket Policy) - "현대적인 중앙 통제"
형식: JSON 기반의 정책 문서입니다.
특징: 매우 정교합니다. 특정 IP 대역, 특정 시간대, MFA 인증 여부 등 복잡한 조건(Condition)을 걸 수 있습니다.
범위: 버킷 전체와 그 안의 모든 객체에 대해 일괄적으로 권한을 부여하거나 뺏을 때 사용합니다.
2. ACL (Access Control List) - "전통적인 개별 관리"
형식: XML 기반의 리스트입니다.
특징: 버킷뿐만 아니라 개별 객체(Object) 하나하나에 대해 읽기/쓰기 권한을 줄 수 있습니다.
범위: 주로 다른 AWS 계정에서 파일을 업로드할 때, 해당 파일의 소유권을 관리하기 위해 사용하던 방식입니다. (현재는 대부분 버킷 정책으로 대체 가능합니다.)
🚦 우선순위와 평가 로직 (Evaluation Logic)
S3 권한은 가장 엄격한 규칙이 승리한다는 대원칙을 따릅니다.
명시적 거부(Explicit Deny)가 있는가?
버킷 정책이나 IAM 정책 중 하나라도
Deny가 있다면, ACL에서 아무리 허용해도 무조건 차단됩니다. (Deny Wins!)
명시적 허용(Allow)이 하나라도 있는가?
Deny가 없는 상태에서, 버킷 정책, IAM 정책, ACL 중 어느 하나라도Allow를 하고 있다면 접근이 허용됩니다.
기본값 (Default):
아무런 설정이 없다면 기본적으로 거부(Deny)됩니다.
한눈에 비교하는 차이점
항목 | 버킷 정책 (Bucket Policy) | ACL (Access Control List) |
권장 여부 | 강력 권장 (Modern) | 레거시 (비활성화 권장) |
세밀함 (Granularity) | 매우 높음 (IP, 조건부 등) | 낮음 (Read/Write 수준) |
형식 | JSON | XML |
관리 지점 | 버킷 단위에서 중앙 관리 | 객체마다 따로 설정 가능 |
최대 크기 | 20 KB | 용량 제한 거의 없음 |
Tip
2026년의 보안 베스트 프랙티스는 'S3 Object Ownership' 설정을 통해 ACL을 완전히 끄는 것입니다. ACL이 켜져 있으면 파일마다 권한이 제각각이라 보안 구멍이 생기기 쉽습니다. 모든 권한은 버킷 정책 하나로 중앙 집중 관리하세요. 그게 훨씬 안전하고 정신 건강에도 이롭습니다
만약 다른 계정에서 내 버킷에 파일을 올렸는데 내가 읽을 수 없다면, 그건 ACL 때문일 확률이 99%입니다. 이때는 당황하지 말고 '버킷 소유자 강제(Bucket Owner Enforced)' 옵션을 켜보세요. ACL 설정이 무시되고 버킷 정책이 모든 권한을 가져오게 되어 문제가 깔끔하게 해결됩니다!
댓글
댓글 0개
이 문서에는 댓글을 달 수 없습니다.