✅ [개념정리] S3 암호화 방식 완전 정리 – SSE-S3, SSE-KMS, SSE-C, Client-Side

🎯 학습 목표

S3에 데이터를 저장할 때는 **기본적으로 서버 측 암호화(Server Side Encryption)**가 적용될 수 있다.
이번 정리에서는 AWS S3에서 제공하는 4가지 암호화 방식의 차이를 이해하고,
실제 아키텍처와 키 관리 주체, 사용 사례까지 정리한다.

---

🔐 암호화 방식 4종 비교

방식키 관리 주체특징

SSE-S3	AWS가 관리하는 키	자동 암호화, 설정만 하면 끝
SSE-KMS	사용자가 생성한 KMS 키	감사 로그 기록 가능, 세분화된 권한 제어
SSE-C	사용자가 직접 키 제공	AWS는 키 저장 안함, 보안 위험 존재
Client-Side	사용자가 직접 암호화	업로드 전 파일 암호화 → 서버는 암호화되지 않음

 

---

🔹 SSE-S3 (서버 측, AWS 키 사용)

• 기본 설정으로 가장 많이 사용됨
• AWS가 자체적으로 관리하는 키(AES-256)를 사용하여
  업로드된 객체를 암호화

json

복사편집

"x-amz-server-side-encryption": "AES256"

• 관리 편리하지만 키 관리는 전적으로 AWS에 맡김
• 비용 없음

---

🔹 SSE-KMS (서버 측, KMS 키 사용)

• AWS KMS(Key Management Service)를 통해 생성한 CMK 사용
• 사용자 지정 키(고객 관리형 CMK 또는 AWS 관리형 키)를 사용할 수 있음
• CloudTrail 로그를 통해 누가, 언제 키를 사용했는지 감사 가능

json

복사편집

"x-amz-server-side-encryption": "aws:kms" "x-amz-server-side-encryption-aws-kms-key-id": "키 ARN"

• 비용: KMS 요청당 과금, 키 저장비용 발생

---

🔹 SSE-C (서버 측, 고객 제공 키 사용)

• 객체를 저장할 때 클라이언트가 직접 키를 함께 전송
• AWS는 해당 키를 저장하지 않음

http

복사편집

x-amz-server-side-encryption-customer-algorithm: AES256 x-amz-server-side-encryption-customer-key: Base64로 인코딩된 키

• 사용 시 주의:
  • 키 유출 시 복호화 불가
  • HTTPS 필수
  • 권장되지 않음 (보안 책임이 전적으로 사용자에게 있음)

---

🔹 Client-Side Encryption (클라이언트 측 암호화)

• 사용자가 직접 파일을 암호화한 뒤 S3에 업로드
• AWS는 암호화된 데이터만 보관
• 복호화는 다운로드 후 사용자 측에서 수행

예: Python boto3, Java SDK에서 라이브러리로 암호화 후 업로드

---

✅ 요약 비교

항목SSE-S3SSE-KMSSSE-CClient-Side

키 저장	AWS	KMS (사용자)	없음	없음
설정 편의	쉬움	중간	복잡	사용자 책임
감사 기능	불가	가능 (CloudTrail)	불가	불가
비용	없음	KMS 비용 발생	없음	없음
실무 사용도	매우 높음	높음 (보안 민감 시)	낮음	특수 목적

 

---

🧠 실무 시사점

• 기본은 SSE-S3으로 충분하지만,
  금융/의료/공공 등 규제 대상 산업군은 SSE-KMS를 사용해야 하는 경우 많다.
• SSE-KMS는 IAM 권한과 KMS 권한이 모두 있어야 하기 때문에,
  정책 설계 시 kms:Encrypt, kms:Decrypt 등 별도로 부여해야 한다.
• CloudTrail을 통해 키 사용 내역 추적 가능하다는 점에서
  내부 데이터 접근 감사용으로도 유용하다.

---

💬 느낀 점

처음엔 "S3 암호화는 그냥 설정 한 번 하면 끝 아니야?"라고 생각했지만,
정리하면서 느낀 건 암호화 자체보다 ‘키 관리’가 더 중요하다는 점이었다.
실무에서는 "누가 키를 사용했는가", "권한은 제대로 설정됐는가",
"모든 객체가 암호화돼 있는가" 같은 부분이 보안에서 핵심이 된다.