S3 암호화 옵션: SSE-S3 vs SSE-KMS vs SSE-C, 언제 무엇을 선택할까?
AWS S3의 서버 측 암호화 옵션(SSE-S3, SSE-KMS, DSSE-KMS, SSE-C)과 클라이언트 측 암호화의 차이점을 비교하고, 상황별 선택 기준을 제시합니다.
관련 시험 도메인
- Domain 1: Design Secure Architectures
핵심 요약: S3 암호화 옵션 선택
결론부터 말하면: 대부분의 경우 SSE-S3(기본값)로 충분합니다. 키에 대한 세부 제어나 감사가 필요하면 SSE-KMS, AWS도 데이터를 볼 수 없어야 하면 클라이언트 측 암호화를 사용하세요.
한눈에 보는 비교
| 암호화 유형 | 키 관리자 | 추가 비용 | CloudTrail 감사 | 적합한 상황 |
|---|---|---|---|---|
| SSE-S3 | AWS S3 | 없음 | 제한적 | 기본 암호화, 최소 오버헤드 |
| SSE-KMS | AWS KMS | 있음 | 전체 지원 | 규정 준수, 키 제어 필요 |
| DSSE-KMS | AWS KMS | 있음 | 전체 지원 | 이중 암호화 규제 요건 |
| SSE-C | 고객 | 없음 | 제한적 | 자체 키 관리 시스템 |
| 클라이언트 측 | 고객 | 없음 | 해당 없음 | AWS도 데이터 접근 불가 |
시험 팁
시험 핵심: "최소 운영 오버헤드" → SSE-S3, "키 사용 감사" → SSE-KMS, "AWS도 데이터 볼 수 없음" → 클라이언트 측 암호화
S3 암호화는 언제 필요할까?
2023년 1월 5일부터 모든 S3 객체는 자동으로 SSE-S3로 암호화됩니다. 별도 설정 없이도 기본 암호화가 적용됩니다.
그러나 다음 상황에서는 암호화 유형을 변경해야 합니다:
SSE-KMS로 변경해야 하는 경우
- 누가, 언제 키를 사용했는지 **감사(audit)**해야 할 때
- 키에 대한 세부적인 접근 제어가 필요할 때
- 규정 준수(HIPAA, PCI-DSS 등) 요구사항이 있을 때
- 키 자동 교체 정책을 적용해야 할 때
클라이언트 측 암호화가 필요한 경우
- AWS 포함 어떤 제3자도 데이터를 볼 수 없어야 할 때
- 전송 중에도 암호화 상태를 유지해야 할 때
- 자체 키 관리 시스템(HSM 등)을 사용해야 할 때
서버 측 암호화 (Server-Side Encryption)
서버 측 암호화는 S3가 데이터를 디스크에 저장할 때 암호화하고, 다운로드할 때 자동 복호화합니다.
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Client │────▶│ Amazon │────▶│ Disk │
│ (평문 전송) │ │ S3 │ │ (암호화 저장)│
└─────────────┘ │ (암호화) │ └─────────────┘
└─────────────┘
SSE-S3: Amazon S3 관리형 키
가장 간단한 암호화 옵션으로, AWS가 키를 완전히 관리합니다.
객체 업로드
│
▼
┌─────────────────────────────────────────┐
│ Amazon S3 │
│ ┌───────────┐ ┌───────────┐ │
│ │ 데이터 │─────▶│ AES-256 │ │
│ │ (평문) │ │ 암호화 │ │
│ └───────────┘ └─────┬─────┘ │
│ │ │
│ ┌───────────┐ ┌─────▼─────┐ │
│ │ S3 루트 │─────▶│ 객체 키 │ │
│ │ 키 │ 암호화│ (고유) │ │
│ └───────────┘ └───────────┘ │
└─────────────────────────────────────────┘
| 특징 | 설명 |
|---|---|
| 암호화 알고리즘 | AES-256 (AES-GCM) |
| 키 관리 | S3가 완전 관리, 자동 교체 |
| 비용 | 추가 비용 없음 |
| 기본값 | 2023년 1월부터 모든 버킷의 기본값 |
적합한 경우:
- 기본적인 저장 데이터 암호화만 필요
- 키 관리에 대한 추가 요구사항 없음
- 최소 운영 오버헤드 원하는 경우
SSE-KMS: AWS KMS 관리형 키
더 강력한 제어와 감사가 필요할 때 사용합니다.
객체 업로드
│
▼
┌─────────────────────────────────────────┐
│ Amazon S3 │
│ │
│ ┌───────────────────────────────────┐ │
│ │ AWS KMS │ │
│ │ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ CMK (고객 │ │ 데이터 키 │ │ │
│ │ │ 관리형 키) │──▶│ 생성 │ │ │
│ │ └─────────────┘ └──────┬──────┘ │ │
│ │ │ │ │ │
│ │ CloudTrail │ │ │
│ │ 로깅 │ │ │
│ └──────────────────────────┼────────┘ │
│ │ │
│ ┌───────────┐ ┌─────▼─────┐ │
│ │ 데이터 │───────▶│ AES-256 │ │
│ │ (평문) │ │ 암호화 │ │
│ └───────────┘ └───────────┘ │
└─────────────────────────────────────────┘
| 특징 | 설명 |
|---|---|
| 키 유형 | AWS 관리형 키 또는 고객 관리형 키(CMK) |
| 감사 | CloudTrail에서 모든 키 사용 기록 |
| 접근 제어 | 키 정책으로 세부 권한 설정 |
| 키 교체 | 자동 교체 설정 가능 (1년 주기) |
| 비용 | KMS API 호출 비용 발생 |
적합한 경우:
- 키 사용에 대한 감사 로그 필요
- 규정 준수 요구사항 (HIPAA, PCI-DSS)
- 키에 대한 세부적인 접근 제어 필요
- 여러 AWS 서비스 간 키 공유
시험 팁
SSE-KMS 주의사항: KMS에는 **초당 요청 제한(quota)**이 있습니다. 대량의 객체를 처리할 때는 S3 버킷 키를 활성화하여 KMS 호출을 줄이세요.
DSSE-KMS: 이중 계층 암호화
두 개의 독립적인 암호화 계층을 적용합니다.
┌─────────────────────────────────────────┐
│ 이중 계층 암호화 (DSSE-KMS) │
│ │
│ ┌───────────────────────────────────┐ │
│ │ 1차 암호화: AWS KMS 데이터 키 │ │
│ │ ┌─────────────────────────┐ │ │
│ │ │ 2차 암호화: S3 관리형 키 │ │ │
│ │ │ ┌─────────────────┐ │ │ │
│ │ │ │ 원본 데이터 │ │ │ │
│ │ │ └─────────────────┘ │ │ │
│ │ └─────────────────────────┘ │ │
│ └───────────────────────────────────┘ │
└─────────────────────────────────────────┘
| 특징 | 설명 |
|---|---|
| 암호화 계층 | 2개 (KMS + S3 관리형) |
| 규정 준수 | NSA CNSSP 15, FIPS 준수 |
| 비용 | SSE-KMS보다 높음 |
적합한 경우:
- 금융, 정부, 국방 등 엄격한 규제 산업
- 다중 계층 암호화 필수 요구사항
- DAR CP(미사용 데이터 기능 패키지) 5.0 준수 필요
SSE-C: 고객 제공 키
고객이 직접 키를 관리하고 S3는 암호화/복호화만 수행합니다.
┌─────────────┐ ┌─────────────┐
│ Client │ │ Amazon S3 │
│ │ │ │
│ ┌───────┐ │ HTTPS + 키 │ ┌───────┐ │
│ │ 암호화 │──┼───────────────────▶│ │암호화 │ │
│ │ 키 │ │ │ │ 수행 │ │
│ └───────┘ │ │ └───────┘ │
│ │ │ │
│ 주의: 키 │ │ 키 저장 │
│ 분실 시 │ │ 하지 않음 │
│ 복구 불가 │ │ │
└─────────────┘ └─────────────┘
| 특징 | 설명 |
|---|---|
| 키 저장 | AWS에서 키 저장 안 함 |
| 요청 방식 | 매 요청마다 키 전송 필요 |
| 프로토콜 | HTTPS 필수 (키 전송 보안) |
| 비용 | 추가 비용 없음 |
적합한 경우:
- 자체 키 관리 시스템 보유
- 완전한 키 소유권 필요
- AWS에 키를 맡기고 싶지 않음
시험 팁
2026년 4월 변경 예정: SSE-C는 새 버킷에서 기본 비활성화됩니다. SSE-C가 필요하면 PutBucketEncryption API로 명시적 활성화가 필요합니다.
클라이언트 측 암호화 (Client-Side Encryption)
S3에 전송하기 전에 클라이언트에서 암호화합니다.
┌─────────────────┐ ┌─────────────┐ ┌─────────────┐
│ Client │ │ Amazon │ │ Disk │
│ ┌───────────┐ │ │ S3 │ │ │
│ │ 암호화 │ │────▶│ (암호문 │────▶│ (암호문 │
│ │ (로컬) │ │ │ 수신) │ │ 그대로) │
│ └───────────┘ │ │ │ │ │
└─────────────────┘ └─────────────┘ └─────────────┘
서버 측 vs 클라이언트 측 암호화
| 구분 | 서버 측 암호화 | 클라이언트 측 암호화 |
|---|---|---|
| 암호화 위치 | AWS S3 | 클라이언트(로컬) |
| 키 관리 | AWS 또는 고객 | 고객 |
| 전송 중 상태 | 평문 (TLS 보호) | 암호문 |
| AWS 데이터 접근 | 가능 | 불가능 |
| 구현 복잡도 | 낮음 | 높음 |
| 성능 영향 | 없음 | 클라이언트 CPU 사용 |
클라이언트 측 암호화 사용 사례
✅ AWS 포함 제3자의 데이터 접근 차단
✅ 전송 중에도 암호화 상태 유지 (TLS 외 추가 보호)
✅ 자체 HSM(Hardware Security Module) 사용
✅ 특수 암호화 알고리즘 요구사항
암호화 유형 선택 가이드
시나리오별 선택
| 시나리오 | 권장 암호화 | 이유 |
|---|---|---|
| 최소 운영 오버헤드 | SSE-S3 | 기본값, 추가 설정 불필요 |
| 키 사용 감사 필요 | SSE-KMS | CloudTrail 통합 |
| 규정 준수 (일반) | SSE-KMS | 키 정책, 감사 로그 |
| 이중 암호화 규제 | DSSE-KMS | 2계층 암호화 |
| 자체 키 관리 시스템 | SSE-C | 고객 키 사용 |
| AWS도 접근 불가 | 클라이언트 측 | 로컬 암호화 |
의사결정 플로우차트
키 사용 감사가 필요한가?
│
├── 예 ──▶ 이중 암호화 규제가 있는가?
│ │
│ ├── 예 ──▶ DSSE-KMS
│ │
│ └── 아니오 ──▶ SSE-KMS
│
└── 아니오 ──▶ AWS도 데이터를 볼 수 없어야 하는가?
│
├── 예 ──▶ 클라이언트 측 암호화
│
└── 아니오 ──▶ SSE-S3 (기본값)
비용을 줄이려면 어떻게 해야 할까?
SSE-KMS 비용 최적화
SSE-KMS는 KMS API 호출마다 비용이 발생합니다. 다음 방법으로 비용을 절감할 수 있습니다:
-
S3 버킷 키 활성화
- KMS 호출 횟수를 최대 99% 감소
- 버킷 수준에서 데이터 키 캐싱
-
대량 작업 최적화
- S3 Batch Operations 사용
- 단일 요청으로 대량 객체 처리
-
적절한 암호화 유형 선택
- 감사가 필요 없으면 SSE-S3 사용
- SSE-S3는 추가 비용 없음
비용 비교
| 암호화 유형 | 스토리지 비용 | 추가 비용 |
|---|---|---|
| SSE-S3 | 기본 S3 요금 | 없음 |
| SSE-KMS | 기본 S3 요금 | KMS API 호출 요금 |
| DSSE-KMS | 기본 S3 요금 | KMS API 호출 요금 (더 많음) |
| SSE-C | 기본 S3 요금 | 없음 |
SAA-C03 시험 출제 포인트
자주 나오는 문제 유형
-
최소 운영 오버헤드로 암호화
- 정답: SSE-S3
- "별도 설정 없이", "추가 비용 없이" 힌트
-
키 사용 감사 및 모니터링
- 정답: SSE-KMS
- "CloudTrail", "감사", "누가 언제 액세스" 힌트
-
AWS도 데이터 접근 불가
- 정답: 클라이언트 측 암호화
- "AWS 포함 제3자 접근 차단" 힌트
-
규정 준수 요구사항
- 정답: SSE-KMS 또는 DSSE-KMS
- "HIPAA", "PCI-DSS", "이중 암호화" 힌트
시험 팁
시험 문제 예시: "회사는 S3에 저장된 민감한 데이터에 대해 키 사용을 감사하고, 키에 대한 세부적인 접근 제어가 필요합니다. 가장 적합한 암호화 방법은?"
→ 정답: SSE-KMS (CloudTrail 감사 + 키 정책으로 접근 제어)
핵심 암기 포인트
| 키워드 | 연상 |
|---|---|
| 최소 오버헤드 | SSE-S3 |
| 감사, CloudTrail | SSE-KMS |
| 키 정책, 접근 제어 | SSE-KMS |
| 이중 암호화, FIPS | DSSE-KMS |
| 자체 키 관리 | SSE-C |
| AWS 접근 차단 | 클라이언트 측 |
| HTTPS 필수 | SSE-C |
FAQ
Q1: SSE-S3와 SSE-KMS 중 어떤 것을 선택해야 하나요?
A: 대부분의 경우 SSE-S3로 충분합니다. 다음 요구사항이 있을 때만 SSE-KMS를 선택하세요:
- 키 사용 감사(CloudTrail 로깅)
- 키에 대한 세부적인 접근 제어(키 정책)
- 규정 준수 요구사항(HIPAA, PCI-DSS 등)
Q2: SSE-KMS의 KMS 요청 제한은 어떻게 해결하나요?
A: S3 버킷 키를 활성화하세요. 버킷 수준에서 데이터 키를 캐싱하여 KMS API 호출을 최대 99% 줄일 수 있습니다.
Q3: 기존 객체의 암호화 유형을 변경할 수 있나요?
A: 네, S3 Batch Operations를 사용하여 기존 객체를 복사하면서 새로운 암호화 유형을 적용할 수 있습니다. S3 인벤토리와 함께 사용하면 수십억 개의 객체도 처리 가능합니다.
Q4: SSE-C에서 키를 분실하면 어떻게 되나요?
A: 데이터를 복구할 수 없습니다. AWS는 SSE-C 키를 저장하지 않으므로, 키 분실 시 해당 객체는 영구적으로 접근 불가능해집니다.
Q5: 서버 측 암호화와 클라이언트 측 암호화를 동시에 사용할 수 있나요?
A: 네, 가능합니다. 클라이언트에서 암호화한 후 업로드하면 S3가 추가로 서버 측 암호화를 적용합니다. 이중 보호가 필요한 경우 사용할 수 있습니다.
마무리
S3 암호화 옵션 선택의 핵심은 요구사항에 맞는 적절한 수준을 선택하는 것입니다:
- 기본 암호화: SSE-S3 (추가 비용 없음, 운영 오버헤드 최소)
- 감사/규정 준수: SSE-KMS (CloudTrail, 키 정책)
- 최고 수준 보안: 클라이언트 측 암호화 (AWS도 접근 불가)
SAA-C03 시험에서는 상황에 맞는 암호화 유형 선택이 자주 출제됩니다. 각 옵션의 특징과 사용 사례를 명확히 이해하세요.