[security] AWS KMS

One-Line Summary

KMS는 암호화 키를 만들고·보관하고·사용 권한과 감사(audit)를 관리하는 서비스로, S3·EBS·RDS·EFS 등 대부분의 AWS 서비스가 저장 데이터(at-rest) 암호화에 KMS를 쓴다. 시험에서는 저장 데이터 암호화 / 봉투 암호화(envelope) / 키 정책 vs IAM / 자동 회전 / 교차 계정·멀티리전 / CloudTrail 감사 / CloudHSM과의 차이 가 핵심이다.

뭔지 (What / Why)

데이터 암호화의 진짜 어려움은 암호화 자체가 아니라 키를 안전하게 보관하고, 누가 언제 쓰는지 통제·감사하는 것이다. 키가 유출되면 암호화는 무의미하다.

KMS는 키를 HSM(하드웨어 보안 모듈) 기반으로 보관하되 키 원문(plaintext)은 절대 KMS 밖으로 내보내지 않고, 요청자가 권한이 있으면 KMS 내부에서 암·복호화를 수행해준다. 모든 사용은 CloudTrail에 남는다.

S3/EBS/RDS 등 ──"이 데이터 KMS 키로 암호화"──▶ KMS(키는 내부에만)
                                                 └─ 사용 기록 → CloudTrail

봉투 암호화(Envelope Encryption) — 반드시 이해 (빈출)

KMS 키(마스터 키)로 큰 데이터를 직접 암호화하지 않는다. 대신 데이터 키를 발급받아 로컬에서 대용량 데이터를 빠르게 암호화하고, 데이터 키 자체만 KMS 키로 암호화해 데이터 옆에 저장한다.

1) GenerateDataKey 요청
   → KMS가 (평문 데이터 키 + 암호화된 데이터 키) 둘 다 반환
2) 평문 데이터 키로 실제 데이터 암호화 → 평문 키는 메모리에서 폐기
3) 저장: [암호화된 데이터] + [암호화된 데이터 키]
복호화: 암호화된 데이터 키를 KMS에 보내 복호화 → 그 키로 데이터 복호화

이점: 대용량도 효율적(대칭 로컬 암호화), 마스터 키는 KMS 밖으로 안 나감.
S3 SSE-KMS + Bucket Key(빈출): 객체마다 KMS를 호출하면 비용·스로틀이 커지므로, 버킷 수준의 키로 KMS 호출을 줄여 비용을 절감한다.

키 종류

키 유형	의미	회전
AWS managed key	서비스가 자동 관리(예: `aws/s3`)	자동
Customer managed key (CMK)	사용자가 생성·정책·회전 통제	연 1회 자동 회전 옵션
AWS owned key	AWS 소유, 사용자에게 안 보임	-

항목	내용
대칭/비대칭	대칭(기본, 암복호화), 비대칭(서명·공개키 배포)
키 저장소	기본 KMS / 커스텀 키 스토어 = CloudHSM 백엔드 / 외부 키 임포트
리전성	키는 리전 종속(다른 리전으로 안 나감) — 예외는 멀티리전 키
삭제	즉시 삭제 불가, 7~30일 대기(pending deletion), 그 전엔 disable 권장

권한: 키 정책 vs IAM vs Grant (자주 헷갈림)

KMS 키 접근은 세 경로로 통제되고, 이 조합을 이해해야 "왜 권한이 있는데 안 되지?"가 풀린다.

메커니즘	역할
키 정책(Key Policy)	키에 직접 붙는 정책. 모든 접근의 기준(이게 허용 안 하면 IAM 있어도 막힘)
IAM 정책	계정 내 주체에게 KMS 사용 권한 부여(키 정책이 위임했을 때)
Grant	일시적·세분화 위임(서비스가 잠깐 키를 쓰게 할 때)

기본 키 정책은 보통 "계정 루트에 위임" → 그 다음 IAM으로 세부 허용.
교차 계정 사용: 키 정책에서 상대 계정을 허용 + 상대 계정 IAM에서도 허용(양쪽 필요).

실무 활용 사례

사례 1. EBS/S3/RDS 저장 암호화

볼륨·버킷·DB 생성 시 KMS 키(주로 CMK) 지정 → 스냅샷·복제본까지 암호화 승계. 규정 준수(at-rest 암호화)의 기본.

사례 2. 교차 계정 공유 데이터

중앙 보안 계정의 CMK를 다른 계정이 쓰도록 키 정책 + IAM 양쪽 허용 → 여러 계정이 같은 키로 암호화된 데이터 공유(예: 공유 S3, 암호화된 AMI/스냅샷 공유).

사례 3. 멀티리전 키 (Multi-Region Keys)

같은 키 자료를 여러 리전에 복제 → 교차 리전 백업/복제, DynamoDB Global Tables, 리전 DR 시 다른 리전에서 복호화 가능.

사례 4. 감사·거버넌스

누가 어떤 키로 무엇을 복호화했는지 CloudTrail에 기록 → 규정 감사·이상 탐지.

KMS vs CloudHSM (자주 비교)

구분	KMS	CloudHSM
관리	완전관리형(멀티테넌트)	전용(single-tenant) HSM, 사용자 관리
규정	일반적 요구	FIPS 140-2 Level 3, 키를 내가 단독·완전 통제
통합	대부분 AWS 서비스와 네이티브	직접 통합(또는 KMS 커스텀 키 스토어로 연결)
선택	대부분의 경우 기본	엄격 규정·전용 하드웨어 요구 시

"전용 하드웨어 / FIPS L3 / 키를 내가 완전 단독 통제" = CloudHSM, 그 외 대부분 = KMS.

Common Wrong Directions

오답 방향	왜 부족한가
큰 데이터를 KMS 키로 직접 암호화한다고 이해	실제는 봉투 암호화(데이터 키)
교차 계정 접근을 IAM만으로	키 정책 + IAM 양쪽 허용 필요
권한 있는데 왜 막히지 → 키 정책 무시	키 정책이 최상위 기준
전용 HSM/FIPS L3 필요한데 KMS로만	CloudHSM
S3 대량 객체를 SSE-KMS 그대로(비용 폭증)	S3 Bucket Key로 호출 절감
키를 즉시 삭제 가정	7~30일 대기, 우선 disable
다른 리전에서 같은 CMK로 복호화 기대	키는 리전 종속 → 멀티리전 키 필요

Exam Triggers

문제에서 이런 표현이 나오면	떠올릴 것
"encrypt data at rest / manage encryption keys"	`KMS`
"control key permissions and yearly rotation"	`KMS` CMK
"audit who used the key"	`KMS` + `CloudTrail`
"share encrypted data across accounts"	키 정책 + IAM(양쪽)
"encrypt/replicate data across regions, DR"	멀티리전 키
"reduce KMS cost for many S3 objects"	S3 Bucket Key
"dedicated hardware / FIPS 140-2 Level 3 / single-tenant"	`CloudHSM`

Memory Sentence

KMS는 키를 밖으로 내보내지 않고 봉투 암호화(GenerateDataKey)로 대용량을 처리하며, 접근은 키 정책(최상위)+IAM+Grant로 통제하고 사용은 CloudTrail에 남는다. CMK는 연 1회 회전·삭제는 7~30일 대기, 교차 계정은 양쪽 허용, 교차 리전은 멀티리전 키, S3 대량은 Bucket Key. 전용 하드웨어·FIPS L3면 CloudHSM.