AWS S3 퍼블릭 액세스 차단: 버킷을 공개하기 전에 확인할 경계

파일을 웹에서 보여 줘야 한다는 이유만으로 S3 버킷 전체를 공개하면 업로드 파일과 백업까지 노출될 수 있다. 공개 접근은 버킷·객체·정책·배포 경로의 조합으로 결정되므로, 먼저 어느 파일을 누가 읽어야 하는지 정한다.

기본은 공개 차단과 최소 권한이다

새 버킷은 공개 접근을 막은 상태로 시작하고, 애플리케이션 역할이나 특정 배포 서비스에 필요한 읽기·쓰기를 부여한다. 객체 ACL과 버킷 정책을 여러 방식으로 섞으면 실제 허용 결과를 추적하기 어려우므로 팀의 권한 모델을 단순하게 유지하는 편이 좋다.

예를 들어 logo.png는 방문자에게 보여야 하지만 report.csv는 내부에서만 읽어야 한다면, 두 파일을 같은 공개 정책으로 처리하지 않는다. 먼저 버킷·계정 수준의 공개 차단 설정을 확인하고, 비공개 파일 접근은 필요한 역할만 허용한다. 공개 차단을 껐다는 사실만으로 파일이 공개되는 것도 아니고, 버킷 정책 한 줄만 봐서 최종 접근을 단정할 수도 없다.

이 세 요청을 따로 시험해야 ‘이미지가 보인다’는 사실을 버킷 전체가 안전하다는 증거로 오해하지 않는다.

공개 정적 자산은 전용 전달 경로를 고려한다

사용자에게 공개할 이미지·CSS·다운로드 파일은 전용 버킷과 CDN 같은 전달 계층으로 분리할 수 있다. 이때도 업로드 원본, 로그, 비공개 자료가 같은 경로에 섞이지 않게 하고, 캐시와 접근 정책을 목적에 맞게 설정한다.

검증할 때는 권한이 없는 사용자의 요청은 거부되고, 서비스 역할의 필요한 읽기만 성공하는지 각각 확인한다. 객체 URL이 403이면 무작정 공개 정책을 넓히지 말고 요청 주체와 경로, 계정·버킷의 공개 차단, 버킷 정책, 객체 소유권 설정을 차례로 대조한다. 업로드 담당 역할에는 읽기 권한과 별도로 필요한 쓰기 범위만 부여한다.

핵심 요약

S3는 기본적으로 공개 차단과 최소 권한으로 시작한다. 공개가 필요한 파일은 비공개 자료와 분리하고, 버킷 정책·객체 권한·전달 경로를 함께 검토하자. '웹에서 보여야 한다'는 요구는 '버킷 전체 공개'를 뜻하지 않는다.