버킷 정책·SSE·Macie·Object Lock으로 지키는 S3 데이터 보호
_Category: Data Protection_
S3는 AWS에서 가장 많이 쓰이는 스토리지 서비스인 동시에 잘못 설정하면 가장 먼저 보안 사고가 나는 서비스입니다. SCS-C03 시험에서 S3 데이터 보호는 접근 제어 평가 순서, 변경 방지 메커니즘, 민감 데이터 탐지, 감사 로그 설계까지 다층적으로 출제됩니다. 접근 제어→암호화→변경 방지→분류→감사의 다섯 계층 구조로 실무 함정과 함께 정리합니다.
---
S3 데이터 보호의 다층 모델 (접근·암호화·변경 방지·분류·감사)
S3 데이터 보호는 단일 기능이 아닌 '계층형 방어(Defense in Depth)' 모델로 접근해야 합니다. 금고를 보호하는 것과 같습니다 — 건물 출입 통제(접근 제어), 금고 자물쇠(암호화), 금고 안의 봉인(변경 방지), 내용물 분류 라벨(데이터 분류), 출입 기록부(감사 로그) — 각 계층이 서로를 보완합니다.
1계층(접근 제어): Bucket Policy, ACL, IAM Policy, Block Public Access, S3 Access Points, VPC Endpoint Policy. 2계층(암호화): SSE-S3·SSE-KMS·SSE-C·DSSE-KMS + TLS 강제. 3계층(변경 방지): Versioning, MFA Delete, Object Lock(Governance / Compliance / Legal Hold). 4계층(분류): Amazon Macie가 PII·금융정보·자격증명을 자동 탐지. 5계층(감사): Server Access Logging, CloudTrail Data Events, S3 Inventory.
---
Bucket Policy, ACL, IAM Policy: 누가 우선이고 왜 (평가 순서)
S3 요청이 들어오면 AWS는 정책을 특정 순서로 평가합니다. 이 순서를 모르면 접근 거부 원인을 찾기조차 어렵습니다.
평가 순서: 명시적 Deny → Block Public Access → Bucket Policy Allow → IAM Policy Allow → ACL Allow. Deny는 어디서든 발견되면 즉시 차단이며, Block Public Access는 Bucket Policy의 public Allow도 덮어씁니다.
| 정책 유형 | 적용 대상 | 주요 특징 | 시험 함정 | |----------|----------|----------|----------| | IAM Policy | IAM 주체(사용자/역할) | 자격증명 기반, VPC 조건 미지원 | 같은 역할이 다른 VPC에도 있으면 VPC 격리 불가 | | Bucket Policy | 버킷·객체 리소스 | aws:sourceVpc, aws:PrincipalOrgID 등 조건 지원 | Cross-account 시 IAM과 Bucket Policy 모두 Allow 필요 | | ACL | 객체·버킷 | 레거시, 계정 단위 | Bucket Owner Enforced 활성화 시 ACL 전체 비활성화 |
Cross-account 접근의 핵심: 버킷 소유 계정의 Bucket Policy Allow + 접근하는 계정의 IAM Policy Allow 양쪽이 모두 있어야 합니다. 한쪽만 있으면 거부됩니다. 로 Bucket Owner Enforced를 설정하면 ACL이 비활성화되고 버킷 정책·IAM Policy만으로 제어됩니다 — '건물 주인이 모든 출입권을 회수한 것'과 같습니다.
VPC 기반 제한 시 Bucket Policy에 조건을 사용합니다. 단, S3 VPC Endpoint(Gateway 또는 Interface)가 반드시 먼저 설정되어야 조건이 작동합니다. S3 Gateway Endpoint는 무료, Interface Endpoint는 시간당 과금입니다.
---
Block Public Access와 가장 흔한 노출 사고
Block Public Access는 '실수로 퍼블릭 허용'이라는 가장 흔한 S3 노출 원인을 막는 안전장치입니다. 계정 레벨과 버킷 레벨 두 곳에 설정할 수 있으며, 계정 레벨이 더 강력합니다.
BlockPublicAcls는 퍼블릭 ACL 추가를 차단하고, IgnorePublicAcls는 기존 퍼블릭 ACL을 무시합니다. BlockPublicPolicy는 퍼블릭 Bucket Policy 적용을 막고, RestrictPublicBuckets는 기존 퍼블릭 정책을 무력화하여 S3 서비스 주체와 버킷 소유 계정 IAM 사용자만 허용합니다.
자주 발생하는 실수 세 가지가 있습니다. 첫째, 계정 레벨 Block Public Access를 끄고 특정 버킷만 퍼블릭 설정 후 다른 버킷도 노출되는 경우입니다. 둘째, CloudFront가 OAC(Origin Access Control)를 사용하면 Block Public Access를 유지한 채 S3를 제공할 수 있는데 이를 모르고 설정을 끄는 경우입니다. 셋째, + 조건 조합을 RestrictPublicBuckets가 퍼블릭 정책으로 오판해 차단하는 경우 — 이때는 Principal을 특정 계정/역할로 좁혀야 합니다. 조직 전체 강제는 SCP로 Deny를 추가하거나, AWS Config 규칙 로 자동 교정합니다.
---
서버 측 암호화의 4가지 옵션 (SSE-S3 / SSE-KMS / SSE-C / DSSE-KMS) — 비교표
2023년부터 모든 S3 버킷에 SSE-S3가 기본 적용되었지만, 규정 준수·키 관리 요건에 따라 다른 옵션을 선택해야 하는 경우가 많습니다.
| 옵션 | 키 관리 | KMS 연동 | 비용 | 주요 사용 사례 | |------|--------|---------|------|-------------| | SSE-S3 | AWS 완전 관리(AES-256) | 없음 | 무료 | 기본 암호화, 비용 최소화 | | SSE-KMS | KMS CMK, 고객 제어 | 있음(감사 로그) | KMS API 호출당 과금 | 키 감사·교체·교차계정 제어 | | SSE-C | 고객이 키 직접 제공 | 없음 | 없음(키 관리 부담) | AWS에 키 재료 미위탁 | | DSSE-KMS | KMS CMK, 이중 암호화 | 있음 | SSE-KMS의 약 2배 | FIPS 140-3 이중 암호화 규정 |
SSE-KMS의 가장 큰 함정은 비용 폭증입니다. 모든 PUT/GET 요청마다 KMS API를 호출하기 때문에 대용량 버킷에서는 예상을 초과하는 요금이 발생합니다. 해결책은 S3 Bucket Keys입니다. 버킷 레벨 DEK를 사용해 KMS API 호출을 최대 99%까지 줄이므로, SSE-KMS를 사용한다면 Bucket Keys는 반드시 활성화해야 합니다.
SSE-C는 고객이 키를 직접 제공하고 AWS는 저장하지 않습니다. HTTPS 필수, 키 분실 시 복구 불가, CRR 불가 — 세 가지 제약을 기억하세요. DSSE-KMS는 두 개의 독립 KMS 키로 이중 암호화하며 FIPS 140-3 규정 환경에서 선택합니다.
암호화 강제: SSE-KMS는 조건 없는 PUT Deny. TLS 강제는 Deny입니다.
!S3 서버 측 암호화 옵션 4가지
Object Lock과 Versioning: 변경·삭제로부터 보호
S3 Object Lock은 객체를 일정 기간 삭제하거나 덮어쓸 수 없도록 잠그는 기능입니다. Object Lock은 버킷 생성 시에만 활성화할 수 있고 이후 비활성화가 불가하며, Versioning이 반드시 활성화되어 있어야 합니다.
Governance Mode는 특별 권한()을 가진 관리자가 잠금을 해제하거나 보존 기간을 변경할 수 있습니다. 실수 교정이 가능한 유연한 모드입니다.
Compliance Mode는 '법적으로 봉인된 금고 — 본사 사장도 못 연다'는 표현이 딱 맞는 모드입니다. 보존 기간 중에는 AWS root 사용자를 포함해 어떤 사용자도 객체를 삭제하거나 보존 기간을 단축할 수 없습니다. FINRA, SEC Rule 17a-4, HIPAA 등 법적 의무 준수에 필수입니다.
| 항목 | Governance Mode | Compliance Mode | |------|----------------|----------------| | 잠금 해제 | 특별 권한 보유자 가능 | 불가 (기간 만료 전) | | 보존 기간 단축 | 특별 권한으로 가능 | 불가 | | AWS root 계정 | 해제 가능 | 해제 불가 | | 적합 사례 | 테스트, 유연한 규정 준수 | FINRA, SEC, HIPAA 법적 의무 |
Legal Hold는 보존 기간 없이 객체를 잠그며, 권한 보유자만 활성화·해제할 수 있습니다. 소송 중 증거 보전에 사용됩니다.
Versioning이 활성화된 버킷에서 객체를 삭제하면 '삭제 마커(Delete Marker)'가 생성되고 원본 버전은 보존됩니다. MFA Delete는 버전 삭제 시 MFA 인증을 추가 요구해 자격증명 탈취 상황의 대량 삭제를 방지합니다(root 계정으로 CLI에서만 활성화). Lifecycle 정책과 충돌 시 Object Lock이 항상 우선하므로, 보존 기간 중인 객체는 Lifecycle으로도 삭제할 수 없습니다.
---
Macie로 민감 데이터 자동 분류와 모니터링
Amazon Macie는 머신러닝을 사용해 S3 버킷에서 민감 데이터를 자동으로 탐지·분류하는 보안 서비스입니다. 수천 개의 버킷을 수동 검사하는 대신, Macie가 PII(개인식별정보), 금융 데이터, 자격증명, 의료 정보 등을 자동으로 찾아냅니다.
Macie는 버킷 보안 평가(공개 접근·암호화·공유 여부 자동 평가)와 민감 데이터 탐지(예약·온디맨드 스캔으로 신용카드 번호, 주민번호, AWS 자격증명 등 탐지)를 제공합니다. 탐지 결과는 EventBridge를 통해 Security Hub, SNS, Lambda로 전달됩니다. 'S3에 PII 업로드 시 자동 알림·격리' 시나리오에서 Macie + EventBridge + Lambda 조합이 정답 패턴입니다.
Macie vs GuardDuty 구분이 자주 출제됩니다. Macie는 데이터 내용(민감 정보) 분류, GuardDuty는 S3 API 이상 행동(대량 다운로드, 비정상 리전 접근) 탐지로 역할이 다릅니다. 조직 전체 Macie는 AWS Organizations Delegated Administrator로 중앙 관리합니다.
---
시험에서 헷갈리는 S3 데이터 보호 시나리오
시험 문제에서 자주 출제되는 판단 포인트를 정리합니다.
특정 VPC에서만 S3 접근 허용: IAM 정책만으로는 같은 역할이 다른 VPC에도 부여될 수 있어 격리가 불완전합니다. Bucket Policy + 조건 + S3 VPC Gateway Endpoint(무료) 조합이 정답입니다.
전용 HSM + AWS가 키 재료에 접근 불가: 일반 SSE-KMS(AWS 관리 HSM)로는 불가합니다. CloudHSM Custom Key Store + SSE-KMS 조합이 정답입니다. FIPS 140-2 Level 3 인증 전용 HSM에서 키를 생성·저장하며, AWS는 접근 불가입니다. KMS API 완전 통합으로 기존 S3 앱 변경이 불필요합니다. '전용 HSM + AWS 키 접근 불가' → CloudHSM Custom Key Store, '여러 리전 동일 KMS 키 ID' → KMS multi-Region key로 구분하세요.
RDS 데이터 보호 3축: 인스턴스 생성 시 KMS CMK 암호화(이후 활성화 불가, Snapshot 자동 암호화) + RDS 파라미터 그룹 + AWS Secrets Manager(RDS 네이티브 통합, 기본 30일 자동 회전). Secrets Manager vs SSM Parameter Store: 자동 회전이 필요하면 Secrets Manager입니다.
SSE-KMS 객체 CRR: SSE-S3는 기본 지원, SSE-KMS는 대상 리전 KMS 키 지정 + IAM 역할에 소스 ·대상 권한 필요, SSE-C는 CRR 불가.
S3 감사 로그: Server Access Logging은 무료이지만 best-effort(일부 누락 가능). CloudTrail Data Events는 유료이지만 누락 없는 완전한 API 기록. 규정 준수 감사·법적 증거에는 CloudTrail Data Events가 필수입니다.
---
시험 핵심 정리
접근 제어: '특정 VPC에서만 S3' → Bucket Policy + + S3 VPC Endpoint (Gateway: 무료) 'Cross-account S3' → 버킷 소유 Bucket Policy Allow + 접근 계정 IAM Policy Allow 양쪽 필수 'ACL 비활성화' → Bucket Owner Enforced / '조직 전체 퍼블릭 차단' → SCP 또는 AWS Config
암호화: '전용 HSM + AWS 키 접근 불가' → CloudHSM Custom Key Store + SSE-KMS '다중 리전 동일 KMS 키' → KMS multi-Region key 'SSE-KMS 비용 절감' → S3 Bucket Keys 활성화 (KMS 호출 최대 99% 감소) 'FIPS 이중 암호화' → DSSE-KMS 'S3 암호화 강제' → Bucket Policy Deny 'TLS 강제' → Bucket Policy Deny
변경 방지: 'root도 삭제 불가, 법적 보존 기간' → Object Lock Compliance Mode (기간 중 AWS root도 해제 불가) '관리자는 해제 가능한 보존' → Object Lock Governance Mode '소송 증거 보전, 기간 없는 잠금' → Legal Hold 'MFA 없이 버전 삭제 불가' → MFA Delete (root 계정 CLI 전용) Object Lock은 Lifecycle보다 항상 우선, 버킷 생성 시에만 활성화 가능
분류·감사: 'S3 PII 자동 탐지·분류' → Amazon Macie / 'S3 API 이상 행동 탐지' → GuardDuty '누락 없는 감사 로그' → CloudTrail Data Events (유료) / '저비용 접근 로그' → Server Access Logging (무료, 일부 누락) '버킷 암호화 상태 일괄 보고' → S3 Inventory