들어가며
Config 규칙 점검에서 퍼블릭 액세스 차단이 꺼진 버킷이 걸렸다. 켜면 되는 일인데, 막상 켜려고 하면 늘 같은 질문이 돌아온다. "그러면 지금 쓰는 게 안 되는 거 아니냐."
이 질문에 "괜찮을 겁니다"라고 답할 수는 없었다. 퍼블릭 차단이 정확히 어떤 요청을 막고 어떤 요청은 그대로 두는지 확인해야 켜자고 말할 수 있었다. 그래서 정리한 글이다.
퍼블릭 액세스란
S3 버킷이 인터넷에 공개되어 있어서, AWS 계정 외부의 누구나 파일을 읽거나 쓸 수 있는 상태다. 여기서 중요한 건 "인증 없이"다. 자격증명을 전혀 제시하지 않은 익명 요청이 통과하는 상태를 말한다.
퍼블릭 접근이 가능해지는 경로는 두 가지다.
- 버킷 정책(Bucket Policy)에
"Principal": "*"설정 - 버킷 ACL에 퍼블릭 읽기/쓰기 권한 부여
두 경로가 따로 있다는 점이 차단 옵션이 네 개인 이유다.
Block Public Access란
퍼블릭 접근을 원천 차단하는 안전장치다. 버킷 정책이나 ACL로 퍼블릭 접근을 허용하더라도 이 설정이 켜져 있으면 차단된다.
순서로 보면 이렇다.
요청 도착
│
▼
[Block Public Access] ← 여기서 먼저 걸린다
│ (퍼블릭으로 판정되는 요청이면 거부)
▼
[버킷 정책 / ACL / IAM 권한 평가]
│
▼
허용 또는 거부
정책보다 앞에 서 있기 때문에, 누군가 실수로 퍼블릭 정책을 붙여도 그 정책이 효력을 갖지 못한다. 정책을 잘 쓰는 것과는 별개로 켜두는 이유가 이것이다.
4가지 차단 옵션
| 옵션 | 막는 대상 | 시점 |
|---|---|---|
| BlockPublicAcls | 퍼블릭 ACL을 새로 붙이는 요청 | 설정 시도 시 |
| IgnorePublicAcls | 이미 붙어 있는 퍼블릭 ACL | 요청 평가 시 |
| BlockPublicPolicy | 퍼블릭 버킷 정책을 새로 붙이는 요청 | 설정 시도 시 |
| RestrictPublicBuckets | 퍼블릭 정책이 있는 버킷에 대한 퍼블릭 및 교차 계정 접근 | 요청 평가 시 |
두 개씩 짝을 이룬다. Block으로 시작하는 옵션은 앞으로 생길 설정을 막고, Ignore와 Restrict는 이미 있는 설정을 무력화한다. 그래서 네 개를 다 켜야 "지금도 안전하고 앞으로도 안전한" 상태가 된다. 두 개만 켜면 기존 설정은 살아 있거나, 새 설정을 막지 못하거나 둘 중 하나가 된다.
무엇이 막히고 무엇은 그대로인가
실제로 가장 많이 받은 질문이 여기에 있다. 퍼블릭 차단은 인증 없이 들어오는 요청만 막는다. 자격증명이나 서명이 붙은 요청은 대상이 아니다.
| 접근 방식 | 퍼블릭 차단의 영향 | 이유 |
|---|---|---|
| 브라우저에서 URL로 직접 열기 (익명) | 차단됨 | 자격증명 없는 요청 |
| ECS Task Role, EC2 Instance Role | 영향 없음 | IAM 인증 요청 |
| AWS CLI / SDK (자격증명 사용) | 영향 없음 | IAM 인증 요청 |
| Presigned URL | 영향 없음 | 발급자의 서명이 붙은 요청 |
| CloudFront OAC / OAI | 영향 없음 | CloudFront가 IAM 주체로 접근 |
정리하면 사람이 "이 주소 아무나 열 수 있게 해주세요"라고 만들어둔 경로만 끊긴다. 서비스가 쓰는 경로는 전부 인증을 거치기 때문에 그대로 동작한다. 이걸 표로 보여주고 나서야 논의가 빨라졌다.
상태별 위험도
| 퍼블릭 차단 | 버킷 정책 | 실제 상태 | 위험도 |
|---|---|---|---|
| 활성 | 정책 없음 | 안전 + 실수 방지 | 안전 |
| 활성 | 퍼블릭 정책 있음 | 차단됨 (정책 무시) | 안전 |
| 비활성 | 정책 없음 | 현재는 안전, 실수 방지 장치 없음 | 주의 |
| 비활성 | 퍼블릭 정책 있음 | 누구나 접근 가능 | 위험 |
"퍼블릭 차단 비활성 + 정책 없음" 상태를 눈여겨볼 만하다. 지금 당장 공개된 건 아니지만, 누군가 정책 한 줄을 붙이는 순간 공개된다. 사고의 조건이 이미 갖춰진 상태라서 Config 규칙이 이걸 잡아낸다.
확인 방법
퍼블릭 액세스 차단 확인
- S3에서 버킷을 열고 "권한(Permissions)" 탭으로 이동
- "퍼블릭 액세스 차단" 섹션 확인
- 4개 항목이 전부 "켜짐"이면 안전
버킷 정책 확인
같은 "권한" 탭의 "버킷 정책"에서 "Principal": "*" 또는 "Principal": {"AWS": "*"}가 있으면 퍼블릭이다. 목록에서 한눈에 보려면 버킷 목록 화면의 "액세스" 열을 보면 되는데, 여기에 "퍼블릭"이라고 표시된 버킷이 우선 확인 대상이다.
조치 방법
퍼블릭 접근이 필요 없는 버킷 (대부분)
- S3에서 버킷의 "권한" 탭으로 이동
- "퍼블릭 액세스 차단"에서 "편집" 클릭
- 4개 항목을 전부 체크하고 "변경 사항 저장"
- 확인 문구에
confirm입력 후 저장
기존 동작에는 영향이 없다. 앞의 표에서 본 대로 IAM 인증 접근, Presigned URL, CloudFront OAC는 모두 그대로다.
퍼블릭 접근이 의도적으로 필요한 버킷
정적 웹사이트 호스팅이나 외부 파일 공유처럼 공개가 목적인 버킷이라면, Config 규칙에서 예외 리소스로 등록해 미준수 집계에서 제외한다. 이때 왜 예외인지를 같이 적어두는 게 중요하다. 이유가 없는 예외는 다음 점검 때 다시 판단 대상이 되고, 매번 같은 논의를 반복하게 된다.
한 가지 더 확인할 것은, 정말 퍼블릭이어야 하는지다. 외부 공유가 목적이라면 Presigned URL로, 웹 배포가 목적이라면 CloudFront OAC로 대체할 수 있는 경우가 많다. 둘 다 버킷을 공개하지 않고도 같은 결과를 낸다.
주의사항
- 퍼블릭 액세스 차단은 버킷 레벨과 계정 레벨 두 곳에서 설정할 수 있다
- 계정 레벨에서 차단하면 모든 버킷에 일괄 적용된다. 공개가 필요한 버킷이 하나도 없는 계정이라면 계정 레벨이 더 확실하다
- 퍼블릭 차단을 켜도 CloudFront OAC/OAI를 통한 접근은 영향이 없다 (퍼블릭이 아닌 IAM 기반 접근)
- 퍼블릭 차단을 켜도 Presigned URL은 정상 동작한다 (서명된 요청이라 퍼블릭이 아님)
정리
- 퍼블릭 차단은 정책 평가보다 앞에 서는 안전장치다. 정책이 잘못돼도 효력을 막는다
- 4개 옵션은 "새로 생기는 설정"과 "이미 있는 설정"을 나눠 막는다. 전부 켜야 완성된다
- 인증 없는 요청만 차단된다. IAM 인증, Presigned URL, CloudFront OAC는 영향이 없다
- 켠 상태를 유지하는 일은 Config 규칙
s3-bucket-public-read/write-prohibited에 맡긴다
배운 점
보안 작업에서 필요한 자료는 위험의 크기가 아니라 영향 범위였다. 퍼블릭 차단을 켜자고 설득할 때 가장 효과가 있었던 건 유출 사례가 아니라, 무엇이 영향을 받지 않는지 적은 표였다. 막는 범위를 정확히 아는 사람만 막을 수 있다. 같은 순서를 EC2 IMDSv2 보안 강화에서도 밟았다. 거기서는 MetadataNoToken 메트릭으로 영향도를 먼저 세어봤다.
옵션이 넷으로 나뉜 데는 이유가 있었다. 처음엔 왜 하나가 아닌가 싶었는데, 앞으로 생길 설정을 막는 것과 이미 있는 설정을 무력화하는 건 다른 동작이었다. 설정 이름을 그대로 외우기보다 무엇을 언제 막는지로 묶어두니 기억에 남았다.
켜는 것보다 켜진 상태를 유지하는 게 어렵다. 한 번 켜도 새 버킷이 생기고 예외가 쌓인다. 그래서 이 작업의 마무리는 콘솔이 아니라 Config 규칙이었다. 전체 감시 구성은 AWS Config 기반 인프라 규정 준수 모니터링에 정리했다.
이어 읽기
- S3 Presigned URL 관련 자원 보안 점검: 실제 버킷들을 전수 점검한 기록
- S3 버킷 버전 관리 적용 가이드: 데이터 보호 설정의 판단 기준
- EC2 IMDSv2 보안 강화: SSRF 공격으로부터 IAM 자격증명 보호: 영향도를 먼저 재고 적용한 다른 보안 작업