🔐 AWS KMS 키 로테이션, 제대로 알고 쓰고 있나요? — 자동 재암호화 서비스 총정리 + 침해사고 시 키 교체 실전 가이드
by gasbugs2026. 4. 15.
"키를 돌렸으니 보안은 끝났겠지?" 이 생각이 실제 침해사고 시 재앙의 시작이 될 수 있습니다.
🎯 이 글에서 다루는 것
AWS KMS 자동 키 로테이션이 실제로 하는 일과 하지 않는 일
로테이션 시 자동 재암호화가 되는 서비스 vs 직접 해야 하는 서비스 비교
침해사고(Security Incident) 발생 시 "키 교체"가 로테이션과 어떻게 다른지
침해사고 대응 시 서비스별 키 교체 절차 실전 정리
📌 도입 — "로테이션 켜놨으니 안전하다"는 착각
AWS 보안 가이드를 보면 늘 나오는 말이 있습니다. "KMS CMK 자동 로테이션을 활성화하라." 많은 분들이 이 설정 하나로 키 보안이 완결된다고 생각하시는데, 사실 이건 반만 맞는 말입니다.
키 로테이션이 켜져 있어도 이미 암호화된 데이터가 자동으로 새 키로 바뀌지 않는 서비스가 대부분입니다. 그리고 더 중요한 건, 실제 침해사고가 발생해서 키를 완전히 교체해야 하는 상황에서는 로테이션만으로 아무것도 해결되지 않습니다. 전혀 다른 절차가 필요하거든요.
지금부터 이 두 가지를 명확하게 정리해보겠습니다.
🔍 AWS KMS 키 로테이션이란? — 정확히 무슨 일이 일어나나
로테이션의 실체: 키 ID는 그대로, 속 재료만 교체
KMS에서 자동 키 로테이션(Automatic Key Rotation) 을 활성화하면 매년(또는 설정한 주기마다) 백킹 키 소재(Backing Key Material) 가 새로 생성됩니다. 중요한 건 이것입니다:
✅ KMS Key ID / ARN은 변하지 않습니다 → 기존 애플리케이션 설정 변경 불필요
✅ 이전 키 소재는 KMS 내부에 그대로 보관됩니다 → 과거에 암호화된 데이터도 계속 복호화 가능
✅ 새로 암호화하는 데이터는 새 키 소재로 암호화됩니다
❌ 기존 암호화 데이터를 자동으로 새 키 소재로 재암호화하지 않습니다
쉽게 비유하면, 아파트 호수(Key ID)는 그대로이고, 열쇠(Key Material)만 새로 만들어 주는데, 기존 자물쇠(암호화된 데이터)는 여전히 옛날 열쇠로 잠겨 있는 상태입니다. 다만 KMS가 옛날 열쇠 사본도 계속 가지고 있으니 문은 열립니다.
로테이션 방식 두 가지
자동 로테이션: KMS가 주기적으로 키 소재 자동 생성
→ Customer Managed Key (CMK)에서 설정 가능
→ AWS Managed Key는 자동으로 3년마다 로테이션
수동 로테이션: 사용자가 직접 새 KMS 키를 생성 후 서비스에 연결
→ 침해사고 시 필요한 방식
→ Key ID/ARN이 완전히 바뀜 → 재암호화 필수
📊 자동 로테이션 시 서비스별 재암호화 동작
✅ 로테이션 시 기존 데이터를 자동으로 재암호화해 주는 서비스
서비스
재암호화
동작 조건
AWS Secrets Manager
시크릿 값의 KMS 키를 변경하면 즉시 재암호화
update-secret --kms-key-id 실행 시
AWS Systems Manager Parameter Store
SecureString 파라미터 업데이트 시 재암호화
파라미터 값을 다시 put할 때
Amazon Redshift
클러스터 암호화 키 교체 기능 내장
rotate-encryption-key API 사용
이 서비스들의 공통점은 "키 교체 = 데이터 재암호화"가 하나의 단일 작업으로 설계되어 있다는 겁니다. 운영자가 별도로 데이터를 마이그레이션할 필요가 없습니다.
❌ 자동 재암호화가 안 되는 서비스 — 직접 해야 합니다
서비스
기존 데이터 상태
재암호화 방법
Amazon S3
기존 객체 그대로 유지
s3 cp 또는 S3 Batch Operations
Amazon EBS
기존 볼륨/스냅샷 그대로 유지
스냅샷 복사 + 새 볼륨 생성
Amazon RDS / Aurora
기존 DB 인스턴스 그대로 유지
스냅샷 복원 + 새 KMS 키 지정
Amazon DynamoDB
테이블의 KMS 키 변경 불가
내보내기 → 새 테이블 생성 → 가져오기
Amazon EFS
기존 파일 시스템 그대로 유지
새 EFS 생성 + 데이터 이전
AWS Lambda 환경 변수
기존 암호화 값 유지
함수 업데이트 시 자동 재암호화
💡 S3, EBS, RDS가 "재암호화 안 된다"고 해서 보안에 문제가 생기는 건 아닙니다. KMS가 이전 키 소재를 보관하고 있어서 복호화는 항상 가능합니다. 다만 오래된 데이터가 계속 구버전 키 소재로 암호화된 상태로 남는다는 의미입니다.
⚡ 침해사고 시 "키 교체" — 로테이션과 완전히 다른 이야기
로테이션 vs 키 교체, 무엇이 다른가
항목
자동 로테이션
침해사고 키 교체
Key ID/ARN
변하지 않음
완전히 새로운 키 생성
기존 키 소재
KMS 내부에 보존
폐기 대상 (공격자가 알고 있음)
목적
일반적인 보안 위생
노출된 키의 영향 차단
재암호화 필요 여부
선택 사항
필수
다운타임
없음
서비스에 따라 발생 가능
침해사고에서 "키 교체"가 필요한 이유는 단순합니다. 공격자가 키 소재(또는 키를 사용할 수 있는 IAM 자격증명)를 획득했다면, 로테이션으로 새 키 소재를 만들어도 공격자는 여전히 KMS API를 통해 복호화할 수 있습니다. 기존 키 소재가 KMS 안에 살아있고, 공격자의 권한이 아직 남아있다면 의미가 없습니다.
진짜 키 교체는 다음의 순서로 이루어져야 합니다.
🛠️ 침해사고 시 키 교체 절차
Step 1 — 격리: 기존 키와 권한 즉시 차단
# 기존 KMS 키 비활성화 (즉각 복호화 차단)
aws kms disable-key --key-id <compromised-key-id>
# 해당 키를 사용하던 IAM 역할/사용자 권한 즉시 회수
aws iam detach-role-policy --role-name <role> --policy-arn <policy-arn>
# CloudTrail로 최근 키 사용 기록 확인
aws cloudtrail lookup-events \
--lookup-attributes AttributeKey=ResourceName,AttributeValue=<key-id>
⚠️ 키를 비활성화하면 기존 암호화 데이터도 즉시 복호화 불가가 됩니다. 재암호화 계획을 먼저 세우고 진행하세요.
Step 2 — 새 KMS 키 생성
# 새 Customer Managed Key 생성
aws kms create-key \
--description "replacement-key-after-incident" \
--key-usage ENCRYPT_DECRYPT \
--key-spec SYMMETRIC_DEFAULT
# 별칭 설정
aws kms create-alias \
--alias-name alias/new-data-key \
--target-key-id <new-key-id>
# 자동 로테이션 활성화
aws kms enable-key-rotation --key-id <new-key-id>
Step 3 — 서비스별 재암호화
S3 — S3 Batch Operations 활용
# 방법 1: 단일 버킷 오브젝트 복사 (SSE-KMS 키 교체)
aws s3 cp s3://my-bucket/ s3://my-bucket/ \
--recursive \
--sse aws:kms \
--sse-kms-key-id <new-key-id> \
--metadata-directive REPLACE
# 방법 2: 대규모는 S3 Batch Operations Job 생성 권장
# (Manifest → Copy operation → New KMS Key 지정)
EBS — 스냅샷 복사 방식
# 1. 기존 볼륨 스냅샷 생성
aws ec2 create-snapshot \
--volume-id vol-xxxxxxxx \
--description "pre-key-rotation-snapshot"
# 2. 스냅샷을 새 KMS 키로 복사 (재암호화)
aws ec2 copy-snapshot \
--source-region ap-northeast-2 \
--source-snapshot-id snap-xxxxxxxx \
--encrypted \
--kms-key-id <new-key-id> \
--description "reencrypted-snapshot"
# 3. 새 스냅샷으로 볼륨 생성 → 기존 볼륨 교체
aws ec2 create-volume \
--snapshot-id <new-snap-id> \
--availability-zone ap-northeast-2a \
--volume-type gp3
RDS — 스냅샷 복원 방식
# 1. 수동 스냅샷 생성
aws rds create-db-snapshot \
--db-instance-identifier mydb \
--db-snapshot-identifier mydb-snapshot-for-rekey
# 2. 스냅샷 복사 (새 KMS 키로 재암호화)
aws rds copy-db-snapshot \
--source-db-snapshot-identifier mydb-snapshot-for-rekey \
--target-db-snapshot-identifier mydb-snapshot-reencrypted \
--kms-key-id <new-key-id>
# 3. 새 스냅샷으로 DB 인스턴스 복원
aws rds restore-db-instance-from-db-snapshot \
--db-instance-identifier mydb-new \
--db-snapshot-identifier mydb-snapshot-reencrypted
Secrets Manager — 가장 간단
# KMS 키 교체 + 즉시 재암호화 (단일 명령)
aws secretsmanager update-secret \
--secret-id my-secret \
--kms-key-id <new-key-id>
DynamoDB — 가장 복잡, 다운타임 발생
# 1. 기존 테이블 Point-in-Time Recovery 또는 Export to S3
aws dynamodb export-table-to-point-in-time \
--table-arn arn:aws:dynamodb:...:table/MyTable \
--s3-bucket my-export-bucket
# 2. 새 KMS 키로 새 테이블 생성
aws dynamodb create-table \
--table-name MyTable-New \
--sse-specification Enabled=true,SSEType=KMS,KMSMasterKeyId=<new-key-id> \
# ... 기타 테이블 설정
# 3. S3에서 데이터 임포트
aws dynamodb import-table \
--s3-bucket-source S3Bucket=my-export-bucket,S3KeyPrefix=... \
--input-format DYNAMODB_JSON \
--table-creation-parameters ...
⚠️ 주의사항 / 흔한 실수
🚨 실수 1 — 기존 키 너무 빨리 삭제
침해사고라고 해서 기존 키를 즉시 삭제하면
재암호화 전 데이터가 영구 손실됩니다.
올바른 순서: 비활성화 → 재암호화 완료 → 삭제 예약(최소 7일)
🚨 실수 2 — 로테이션만 하고 침해사고 대응 완료라 착각
공격자가 kms:Decrypt 권한을 가진 IAM 자격증명을 탈취했다면, 키를 로테이션해도 의미 없습니다. IAM 권한 회수 + 새 키 생성 + 재암호화가 세트입니다.
🚨 실수 3 — 모든 서비스 재암호화 후 기존 키 상태 방치
# 재암호화 완료 확인 후 반드시 삭제 예약
aws kms schedule-key-deletion \
--key-id <old-key-id> \
--pending-window-in-days 30
🚨 실수 4 — DynamoDB 키 교체 과소평가
DynamoDB는 기존 테이블의 KMS 키를 직접 변경하는 API가 없습니다. 내보내기 → 재생성 → 가져오기 과정에서 다운타임 또는 데이터 정합성 이슈가 발생할 수 있으므로 변경 관리 절차를 반드시 수립하세요.
✅ 정리 / 마무리
AWS KMS 키 관리의 핵심을 한 문장으로 정리하면 이렇습니다.
로테이션은 미래를 보호하고, 키 교체는 현재를 보호한다.
상황
올바른 대응
일반적인 보안 위생
자동 로테이션 활성화
자격증명 노출 의심
즉시 비활성화 + 새 키 생성 + 재암호화
재암호화 자동 지원
Secrets Manager, Parameter Store, Redshift
재암호화 수동 필요
S3, EBS, RDS, DynamoDB, EFS
다음 단계로는 AWS Config Rule로 CMK 로테이션 미설정 감지 자동화, CloudTrail + EventBridge로 키 사용 이상 징후 알림 구축을 함께 구성하면 KMS 기반 보안 체계를 완성할 수 있습니다.
