[AWS 하드닝 05] 암호화된 버킷도 공개될 수 있습니다: S3 접근 경계

Об этом предложении

S3에 저장된 파일이 암호화됐다는 표시를 보고 외부 공개도 막혔다고 생각하기 쉽습니다. 하지만 정상 권한으로 파일을 읽는 요청에는 서비스가 내용을 제공할 수 있습니다. 이번에는 공개 접근, 객체 소유권, 전송 보호 를 각각 점검하겠습니다. 기존 AWS 시리즈 에서 서비스별 역할을 정리한 데 이어, 이번에는 정상 업무를 유지하면서 접근 범위를 줄이는 방법을 살펴봅니다. S3 버킷과 객체, IAM 정책을 알고 있으면 읽을 수 있습니다. 사내 보고서를 저장하는 가상 버킷이며 공개 웹사이트 용도는 아닙니다. 서로 다른 세 가지 질문 Block Public Access는 정책과 ACL 등을 통해 공개 접근이 허용되는 것을 제한합니다. 버킷 설정만 보지 않고 계정과 적용되는 조직 설정, 액세스 포인트도 함께 확인해야 합니다. 더 엄격한 조합이 적용될 수 있습니다. S3 공개 접근 차단 Object Ownership의 BucketOwnerEnforced 는 ACL을 비활성화하고 버킷 소유자가 객체를 소유하도록 하는 설정입니다. IAM과 버킷 정책이 필요 없어지는 기능이 아닙니다. 기존 업로드 클라이언트가 ACL을 보내는지 전환 전에 확인합니다. 객체 소유권과 ACL 전송 보호는 HTTPS를 사용하는 질문입니다. 저장 암호화 여부와 다른 경계입니다. 데이터가 저장될 때 보호돼도 네트워크 요청 자체를 HTTP로 허용해 둘 수 있습니다. 그림의 세 칸은 어느 하나만 통과하면 충분하다는 뜻이 아닙니다. 정상 역할이 필요한 파일만 읽는지까지 별도 확인합니다. 버킷 속성의 예 아래 JSON은 CloudFormation AWS::S3::Bucket 의 Properties 에 들어가는 속성 조각 입니다. 버킷 정책과 암호화 설정, 전체 템플릿은 포함하지 않았습니다. { "PublicAccessBlockConfiguration": { "BlockPublicAcls": true, "IgnorePublicAcls": true, "BlockPublicPolicy": true, "RestrictPublicBuckets": true }, "OwnershipControls": { "Rules": [{"ObjectOwnership": "BucketOwnerEnforced"}] } } 네 항목을 모두 참으로 적었습니다. 각각 같은 설정의 별명이 아니므로 하나만 켜고 같은 효과라고 생각하지 않습니다. 기존 ACL과 정책 내용이 정리됐다는 의미도 아닙니다. 구조와 용도는 PublicAccessBlockConfiguration , OwnershipControls 에서 확인할 수 있습니다. HTTPS 요구는 별도 정책입니다 아래는 가상 버킷 정책의 거부 Statement입니다. 권한을 부여하는 전체 정책은 아닙니다. AWS 서비스 간 호출에서는 요청 컨텍스트가 일부 가려질 수 있어 서비스 주체를 구분하는 조건도 넣었습니다. { "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": [ "arn:aws:s3:::amzn-s3-demo-hardening", "arn:aws:s3:::amzn-s3-demo-hardening/*" ], "Condition": {"Bool": { "aws:SecureTransport": "false", "aws:PrincipalIsAWSService": "false" }} } Principal: "*" 가 있지만 이 Statement는 Deny 입니다. 별표만 보고 공개 허용 정책이라고 판단하면 의미가 바뀝니다. 예제는 두 조건이 함께 맞는 비서비스 주체의 HTTP 요청을 거부하려는 것입니다. HTTPS 요청을 허용하는 권한은 별도로 있어야 합니다. S3 전송 암호화 권장 사항 , AWS 서비스 주체 조건 기존 서비스가 끊기지 않도록 버킷 정책, 액세스 포인트, 업로드 ACL, 공개 배포 여부를 목록으로 만듭니다. 테스트 버킷에서 정상 역할의 업로드·읽기가 되는지 확인합니다. 권한 없는 익명 읽기와 HTTP 요청은 서로 다른 시험으로 확인합니다. 공개 웹사이트 같은 예외 용도는 이 사내 보고서 예제와 분리해 설계합니다. 되돌릴 때는 실패한 클라이언트의 호출 조건을 먼저 확인하고 바꾼 항목만 복구합니다. 문제를 해결하려고 계정 전체의 공개 접근 차단을 무작정 끄면 다른 버킷까지 영향을 받을 수 있습니다. 기존 공개 접근이 필요한지는 소유자와 검토하고, 예외의 범위를 기록합니다. 미리 서명된 URL도 따로 생각해야 합니다. URL을 발급한 주체의 권한과 만료가 관련되며, URL을 공유하면 의도한 상대 외에도 사용될 수 있습니다. “공개 차단을 켰으니 URL 공유도 신경 쓰지 않아도 된다”는 결론으로 이어지지 않습니다. 로컬 검증: 두 JSON 조각을 파싱하고 공개 차단 네 항목, ACL 비활성화, TLS 거부 조건을 검사했습니다. 공개 차단 하나를 끈 반례와 Deny 를 Allow 로 바꾼 반례는 탈락했습니다. 실제 S3 접근 평가, 업로드 호환성, HTTPS 연결은 시험하지 않았습니다. 확인 문제 저장 암호화가 켜져 있으면 익명 읽기도 차단될까요? Deny 의 Principal: "*" 는 모두에게 권한을 주는 뜻일까요? 정상 업로드가 실패할 때 공개 차단 전체를 끄기 전에 무엇을 볼까요? 답과 해설 아닙니다. 저장 보호와 읽기 권한은 다릅니다. 아닙니다. 조건에 맞는 요청을 거부하는 범위를 나타냅니다. 업로드 ACL, 소유권 전환, 요청 프로토콜과 적용된 정책을 봅니다. 복습 오늘은 공개 차단·소유권·TLS가 답하는 질문을 하나씩 써 보세요. 내일은 HTTPS이지만 권한 없는 요청이 왜 여전히 거부돼야 하는지 설명해 보세요. 일주일 뒤에는 KMS 복호화 권한까지 포함해 읽기 경로를 그려 보세요. 확인일: 2026-10-04, 한국 시간 . S3와 CloudFormation 속성, IAM 전역 조건 키 기준입니다. 모든 버킷 이름은 가상입니다.