S3 버킷 퍼블릭 액세스 차단 설정 확인으로 데이터 유출 사고 예방하는 방법

S3 버킷 퍼블릭 액세스 차단 설정은 클라우드 스토리지에서 발생하는 데이터 유출 사고를 막는 가장 확실한 방어선입니다. 지난 몇 년 동안 국내외에서 고객 정보, 내부 문서, 백업 파일이 인터넷에 그대로 노출된 사고가 여러 차례 보도되었는데, 상당수는 해킹 기술이 아니라 저장소를 공개 상태로 잘못 설정한 단순한 실수에서 시작되었습니다. 이 설정 하나만 제대로 이해하고 관리해도 비슷한 사고를 크게 줄일 수 있습니다.

 

S3 버킷 퍼블릭 액세스 차단 설정 확인으로 데이터 유출 사고 예방하는 방법

저도 예전에는 이미지 파일 몇 개를 외부에서 보이게 하려고 버킷 전체의 퍼블릭 액세스 차단을 해제하는 방법을 따라 한 적이 있습니다. 당장은 파일이 잘 열려서 문제가 없어 보였지만, 나중에 같은 버킷에 다른 자료도 올리고 있었다는 것을 깨닫고 식은땀이 났습니다. 그 뒤로는 공개가 필요한 파일도 버킷을 열지 않고 제공하는 방법을 먼저 찾게 되었습니다.

 

오늘 제가 준비한 포스팅에서는 S3 버킷 퍼블릭 액세스 차단 설정을 중심으로 S3가 공개되는 경로, 퍼블릭 액세스 차단의 네 가지 세부 옵션, 계정 단위와 버킷 단위 설정의 차이, 현재 노출된 버킷을 찾는 방법, 그리고 파일을 안전하게 외부에 제공하는 대안까지 차근차근 정리해보겠습니다.

 

결론부터 말씀드리면 AWS는 2023년 4월부터 새로 만드는 S3 버킷에 퍼블릭 액세스 차단을 기본으로 켜고 ACL을 비활성화하도록 변경했습니다. 따라서 가장 중요한 것은 이 기본값을 함부로 끄지 않는 것, 그리고 계정 단위 차단까지 켜서 실수로 공개되는 일을 원천적으로 막는 것입니다.

 

S3 데이터가 외부에 공개되는 두 가지 경로

S3 객체가 인터넷에 공개되는 경로는 크게 두 가지입니다. 첫 번째는 ACL(Access Control List)입니다. ACL은 버킷이나 개별 객체에 모든 사용자 읽기 같은 권한을 부여하는 오래된 방식으로, 파일 하나하나에 공개 권한을 붙일 수 있어 관리가 어렵고 실수가 발생하기 쉬웠습니다.

 

두 번째는 버킷 정책(Bucket Policy)입니다. JSON 형식으로 작성하는 권한 정책에서 Principal을 모든 사용자를 뜻하는 별표로 지정하고 객체 읽기 권한을 허용하면, 버킷 안의 객체를 누구나 주소만 알면 내려받을 수 있게 됩니다. 정적 웹사이트 호스팅 튜토리얼에서 흔히 사용되는 설정입니다.

 

문제는 이런 설정이 한 번 들어가면 그 뒤에 버킷에 올리는 모든 파일에도 똑같이 적용된다는 점입니다. 처음에는 공개용 이미지만 있었던 버킷에 누군가 내부 자료를 올리는 순간 그 자료도 함께 공개됩니다. 공개 여부가 파일을 올리는 사람의 주의력에 달려 있게 되는 구조입니다.

 

S3 데이터는 ACL과 버킷 정책이라는 두 경로로 공개될 수 있으며, 한 번 공개 설정이 들어간 버킷은 이후 올리는 파일까지 모두 노출될 위험이 있습니다.

 

퍼블릭 액세스 차단의 네 가지 세부 옵션

S3 퍼블릭 액세스 차단(Block Public Access)은 앞에서 설명한 공개 경로를 막는 네 가지 옵션으로 구성되어 있습니다. 첫 번째 옵션은 새로운 ACL을 통한 퍼블릭 액세스 차단으로, 앞으로 공개 ACL을 설정하려는 요청을 거부합니다.

 

두 번째 옵션은 모든 ACL을 통한 퍼블릭 액세스 차단입니다. 이미 설정되어 있는 공개 ACL이 있더라도 S3가 이를 무시하도록 만듭니다. 오래전에 설정된 공개 ACL이 남아 있는 버킷을 한 번에 보호할 수 있는 옵션입니다.

 

세 번째 옵션은 새로운 퍼블릭 버킷 정책 차단으로, 공개 접근을 허용하는 버킷 정책을 새로 저장하려고 하면 거부합니다. 네 번째 옵션은 퍼블릭 정책이 있는 버킷에 대한 접근 제한으로, 이미 공개 정책이 들어 있더라도 AWS 서비스와 버킷 소유 계정의 권한 있는 사용자만 접근할 수 있게 제한합니다.

 

네 가지 옵션을 모두 켜면 ACL과 버킷 정책 어느 경로로도 익명 사용자가 접근할 수 없게 됩니다. 콘솔에서는 모든 퍼블릭 액세스 차단이라는 하나의 체크박스로 네 옵션을 한꺼번에 켤 수 있습니다.

 

옵션	막는 대상	적용 시점
새 ACL 차단	공개 ACL을 새로 설정하는 요청	앞으로의 설정
모든 ACL 차단	이미 설정된 공개 ACL의 효력	기존 설정 포함
새 퍼블릭 정책 차단	공개 버킷 정책 저장 요청	앞으로의 설정
퍼블릭 정책 접근 제한	이미 존재하는 공개 정책을 통한 익명 접근	기존 설정 포함

 

퍼블릭 액세스 차단의 네 옵션은 새로운 공개 설정과 기존 공개 설정을 ACL과 정책 경로 모두에서 막으므로, 특별한 이유가 없다면 네 가지 모두 켜두는 것이 원칙입니다.

 

계정 단위 차단과 버킷 단위 차단의 차이

퍼블릭 액세스 차단은 버킷 단위와 계정 단위 두 곳에서 설정할 수 있습니다. 버킷 단위 설정은 해당 버킷에만 적용되고, 계정 단위 설정은 그 계정에 있는 모든 버킷에 적용됩니다. 두 설정이 함께 있을 때는 더 제한적인 쪽이 적용됩니다.

 

즉 계정 단위에서 차단을 켜두면 누군가 개별 버킷에서 차단을 해제하더라도 공개가 되지 않습니다. 실수로 버킷을 공개하는 사고를 조직 차원에서 막는 가장 강력한 방법입니다. 콘솔의 S3 메뉴 왼쪽에 있는 이 계정에 대한 퍼블릭 액세스 차단 설정에서 확인할 수 있습니다.

 

여러 AWS 계정을 AWS Organizations로 관리한다면 서비스 제어 정책을 이용해 구성원 계정에서 퍼블릭 액세스 차단 설정을 해제하지 못하도록 막는 방법도 사용됩니다. 보안 담당자가 모든 계정을 일일이 확인하지 않아도 일관된 기준을 유지할 수 있습니다.

 

정말로 공개가 필요한 버킷이 있다면 그 버킷만 별도의 계정에 두고, 일반 업무 계정은 계정 단위 차단을 켜두는 식으로 분리하는 것도 좋은 방법입니다. 공개 데이터와 비공개 데이터가 같은 계정에 섞이지 않게 하는 것이 사고를 줄이는 구조적인 해결책입니다.

 

계정 단위 퍼블릭 액세스 차단은 개별 버킷 설정보다 우선 적용되므로, 공개가 필요 없는 계정이라면 반드시 켜두어 실수로 인한 공개를 원천 차단해야 합니다.

 

현재 공개되어 있는 버킷을 찾는 방법

이미 운영 중인 계정이라면 지금 공개된 버킷이 있는지부터 확인해야 합니다. S3 콘솔의 버킷 목록에는 액세스 열이 있어 공개, 객체를 퍼블릭으로 설정할 수 있음, 비공개 같은 상태가 표시됩니다. 공개라고 표시된 버킷이 있다면 의도한 설정인지 즉시 확인해야 합니다.

 

더 체계적으로 확인하려면 IAM Access Analyzer를 사용합니다. 계정 외부의 사용자나 익명 사용자에게 접근이 허용된 S3 버킷, IAM 역할, KMS 키 같은 리소스를 찾아 결과로 보여줍니다. S3 콘솔에서도 Access Analyzer for S3 화면을 통해 공개되거나 다른 계정과 공유된 버킷 목록을 확인할 수 있습니다.

 

버킷 안에 개인정보 같은 민감한 데이터가 들어 있는지 확인하고 싶다면 Amazon Macie를 활용할 수 있습니다. Macie는 S3 객체를 분석해 주민등록번호 형식, 신용카드 번호 같은 민감 정보 패턴을 찾아내고, 버킷의 공개 여부와 암호화 상태도 함께 보고합니다. 데이터 양에 따라 요금이 발생하므로 범위를 정해 사용하는 것이 좋습니다.

 

파일을 안전하게 외부에 제공하는 대안

버킷을 공개하는 가장 흔한 이유는 웹사이트 이미지나 다운로드 파일을 외부 사용자에게 보여주기 위해서입니다. 이 경우 버킷을 직접 공개하지 않고 Amazon CloudFront를 앞에 두는 방식이 권장됩니다. CloudFront의 원본 액세스 제어(OAC)를 설정하면 버킷은 비공개로 유지하면서 CloudFront를 통해서만 파일을 제공할 수 있습니다.

 

이 방식은 보안뿐 아니라 성능과 비용 측면에서도 장점이 있습니다. 전 세계 엣지 로케이션에 캐시된 파일이 제공되어 속도가 빨라지고, HTTPS 인증서 적용도 쉬우며, 트래픽이 많을 때 데이터 전송 비용을 줄이는 데 도움이 될 수 있습니다.

 

특정 사용자에게만 일정 시간 동안 파일을 공유해야 한다면 미리 서명된 URL(Presigned URL)을 사용합니다. 권한이 있는 사용자가 유효 기간을 정해 URL을 생성하면, 그 URL을 받은 사람은 기간 안에만 파일을 내려받을 수 있습니다. 기간이 지나면 URL은 더 이상 작동하지 않습니다.

 

외부에 파일을 보여줘야 할 때도 버킷을 공개하지 말고 CloudFront 원본 액세스 제어나 유효 기간이 있는 미리 서명된 URL을 사용하는 것이 안전합니다.

 

퍼블릭 액세스 차단과 함께 점검할 S3 보안 설정

첫 번째는 객체 소유권 설정입니다. 버킷 소유자 적용(Bucket owner enforced) 설정을 사용하면 ACL이 비활성화되고 권한은 버킷 정책과 IAM 정책으로만 관리됩니다. 새 버킷의 기본값이며, 오래된 버킷이라면 이 설정으로 전환하는 것을 검토해보세요.

 

두 번째는 암호화입니다. S3는 2023년 1월부터 새로 업로드되는 객체에 S3 관리형 키를 이용한 서버 측 암호화를 기본으로 적용하고 있습니다. 더 엄격한 키 관리가 필요하다면 AWS KMS 키를 사용한 암호화로 설정할 수 있습니다.

 

세 번째는 버전 관리와 로깅입니다. 버전 관리를 켜두면 실수로 삭제하거나 덮어쓴 파일을 복구할 수 있고, CloudTrail 데이터 이벤트나 서버 액세스 로그를 활성화하면 누가 언제 어떤 객체에 접근했는지 추적할 수 있습니다. 사고가 발생했을 때 피해 범위를 확인하는 데 꼭 필요한 기록입니다.

 

S3 버킷 퍼블릭 액세스 차단 설정 총정리

S3 데이터는 ACL과 버킷 정책을 통해 공개될 수 있으며, 퍼블릭 액세스 차단의 네 가지 옵션은 두 경로의 새로운 설정과 기존 설정을 모두 막아줍니다. 계정 단위 차단은 개별 버킷 설정보다 우선 적용되므로 공개가 필요 없는 계정에서는 반드시 켜두어야 합니다. 외부 제공이 필요하면 CloudFront 원본 액세스 제어나 미리 서명된 URL을 사용하고, Access Analyzer로 공개된 버킷을 정기적으로 점검하는 것이 좋습니다.

 

질문 QnA

정적 웹사이트 호스팅을 쓰려면 퍼블릭 액세스 차단을 꺼야 하나요?

S3 웹사이트 엔드포인트를 직접 사용하려면 공개 설정이 필요하지만, CloudFront를 앞에 두고 원본 액세스 제어를 사용하면 버킷을 비공개로 유지한 채 웹사이트를 제공할 수 있습니다.

계정 단위 차단을 켜면 기존에 공개된 서비스가 멈추나요?

공개 버킷 정책이나 ACL에 의존하던 접근은 차단되므로 해당 서비스가 영향을 받을 수 있습니다. 적용 전에 Access Analyzer로 공개된 버킷과 용도를 확인하는 것이 좋습니다.

미리 서명된 URL의 유효 기간은 얼마나 설정할 수 있나요?

생성 방식과 사용하는 자격 증명에 따라 최대 유효 기간이 달라집니다. 임시 자격 증명으로 만든 URL은 자격 증명이 만료되면 함께 사용할 수 없게 되므로 공식 문서의 조건을 확인하세요.

버킷 이름만 알려져도 위험한가요?

퍼블릭 액세스 차단이 켜져 있고 권한이 제대로 설정되어 있다면 이름만으로 데이터에 접근할 수는 없습니다. 다만 버킷 이름에 회사 내부 정보가 드러나지 않도록 짓는 것이 좋습니다.

 

S3 데이터 유출 사고는 대부분 누군가의 한 번의 편의가 오랫동안 방치되면서 발생합니다. 기본값으로 켜져 있는 퍼블릭 액세스 차단을 유지하고, 계정 단위 차단으로 이중 잠금을 걸어두는 것만으로도 이런 사고의 대부분을 예방할 수 있습니다.

 

지금 S3 콘솔 왼쪽 메뉴에서 이 계정에 대한 퍼블릭 액세스 차단 설정을 열어 네 가지 옵션이 모두 켜져 있는지 확인해보세요. 그리고 버킷 목록의 액세스 열에서 공개로 표시된 버킷이 있다면 CloudFront나 미리 서명된 URL로 전환할 수 있는지 검토해보시길 권해드립니다.

 

※ 본 글은 2026년 9월 기준 Amazon S3 퍼블릭 액세스 차단, 객체 소유권, IAM Access Analyzer, Amazon CloudFront 원본 액세스 제어 공식 문서를 참고해 작성했으며, 기본 설정과 기능은 변경될 수 있으니 최신 내용은 AWS 공식 페이지에서 확인해 주세요.