Day 1 - KMS, 키를 한 번도 보지 않고 키를 관리하는 법

암호화는 결국 키 관리 문제로 귀결된다. AES-256으로 데이터를 암호화하는 알고리즘은 1990년대에 이미 끝난 이야기고, 깨진 적도 없다. 사고는 알고리즘이 아니라 키에서 난다. 키를 코드에 하드코딩했다가 GitHub에 푸시하고, 키를 평문으로 S3에 올려두고, 키를 누가 언제 썼는지 추적하지 못하고, 떠난 직원의 노트북에 키 사본이 남아 있다. 보안 사고의 압도적 다수가 "키를 어디다 뒀는지"의 문제다.

KMS의 핵심 설계 철학은 단순하다. 사용자가 키 원본(key material)을 절대 보지 못하게 한다. 키를 만들 수도 있고, 회전시킬 수도 있고, 삭제 예약을 걸 수도 있지만, 평문 마스터 키 바이트를 다운로드하는 API는 존재하지 않는다. 이게 왜 그렇게 설계됐는지, HSM이라는 물리 장비가 어떻게 이걸 보장하는지, Envelope Encryption이 왜 필요한지, Key Policy가 왜 IAM보다 우선하는지 — 이 결정들의 이유를 따라가는 게 이 글이다.

키를 다운로드할 수 없는 시스템 — KMS가 등장한 이유

AWS 초기에 암호화는 전적으로 고객 책임이었다. S3에 데이터를 올리려면 클라이언트에서 직접 암호화하고, 키는 알아서 보관해야 했다. 문제는 키 보관이 암호화 자체보다 훨씬 어렵다는 것이다. 키를 어디 두지? 환경 변수? 그럼 그 변수를 읽을 수 있는 모든 프로세스가 키를 본다. 파일? 그럼 디스크 이미지를 뜨면 키가 같이 딸려 나간다. 키를 또 다른 키로 암호화? 그럼 그 키는 어디 두지? 이 무한 후퇴(turtles all the way down)가 키 관리의 본질적 난점이다.

KMS는 이 후퇴를 하드웨어에서 끊는다. 최상위 마스터 키는 FIPS 140-2 인증을 받은 HSM(Hardware Security Module) 안에서만 존재하고, HSM 밖으로 평문 상태로 나오는 일이 물리적으로 불가능하다. HSM은 키를 외부로 추출하려는 시도를 감지하면 키를 스스로 파괴하는 변조 방지(tamper-resistant) 회로를 갖고 있다. 사용자는 "이 데이터를 이 키로 암호화해줘"라고 요청만 보내고, 암호화된 결과만 받는다. 키 바이트 자체는 결코 네트워크를 타지 않는다.

이 모델의 이름은 "keys never leave the HSM unencrypted"다. 2014년 KMS가 출시되기 전까지 이 수준의 키 격리는 직접 HSM 장비를 사서 데이터센터에 설치해야만 가능했고, 장비 한 대가 수만 달러였다. KMS는 이걸 월 $1짜리 API 서비스로 만들었다. 시험에서 "왜 KMS를 쓰나, 직접 암호화하면 안 되나"의 답은 단지 편의가 아니라 — 키를 사람이 만질 수 없게 만드는 것 자체가 보안의 핵심이기 때문이다.

KMS의 신뢰 모델은 "신뢰할 수 있는 컴퓨팅 기반(Trusted Computing Base, TCB)을 최소화한다"는 보안 공학 원칙의 구현이다. TCB는 시스템 보안을 책임지는 부품의 집합인데, 이게 작을수록 검증·감사가 쉽고 공격 표면이 좁다. KMS는 TCB를 HSM 하드웨어 + 그 안의 펌웨어로 축소한다. 운영체제, 애플리케이션 코드, 네트워크 스택이 모두 침해당해도 마스터 키는 HSM 밖으로 나가지 않으므로 TCB가 깨지지 않는다. 1980년대 Orange Book(TCSEC)에서 정립된 이 개념이 현대 클라우드 KMS의 근간이다.

KMS HSM은 마스터 키를 평문으로 디스크에 저장하지 않는다. 모든 마스터 키는 KMS가 운영하는 도메인 키(domain key)로 암호화돼 내구성 스토리지에 보관되고, 사용 시점에만 HSM 메모리에서 복호화된다. 도메인 키 자체는 여러 HSM에 분산된 quorum 방식으로만 접근 가능해서, HSM 한 대를 탈취해도 마스터 키를 복원할 수 없다. AWS는 이 설계를 공개 백서로 검증받았는데(KMS Cryptographic Details), 키가 만들어져서 폐기될 때까지 평문으로 HSM 경계를 넘는 순간이 단 한 번도 없음을 수학적으로 보인다.

Envelope Encryption — KMS가 4KB만 처리하는 이유

KMS로 직접 암호화할 수 있는 데이터는 최대 4KB다. 1GB 파일을 KMS에 보내 암호화하려 하면 에러가 난다. 처음엔 이게 제약처럼 보이지만, 사실 이건 의도된 설계이고 그 해법이 Envelope Encryption이다.

왜 4KB로 제한했나? 첫째, 큰 데이터를 KMS로 보내면 네트워크 왕복이 데이터 크기에 비례해 느려진다 — 1GB를 KMS API로 왕복시키는 건 말이 안 된다. 둘째, 그렇게 하면 모든 바이트가 HSM을 거쳐야 해서 HSM이 처리량 병목이 된다. 셋째, 가장 중요하게, 마스터 키로 대량의 데이터를 직접 암호화하면 같은 키가 너무 많은 암호문에 노출되어 암호 분석 공격(cryptanalysis)의 표면이 넓어진다.

Envelope Encryption은 이 문제를 두 단계로 푼다. 큰 데이터는 일회성 데이터 키(Data Encryption Key, DEK)로 로컬에서 빠르게 암호화하고, 그 짧은 DEK만 마스터 키로 암호화해서 데이터 옆에 같이 저장한다. 봉투(envelope) 안에 편지(데이터)를 넣고, 봉투를 마스터 키로 봉인하는 그림이다.

GenerateDataKey(KeyId) 호출
   → KMS가 DEK 한 개를 만들어 두 가지 형태로 반환:
       Plaintext DEK  (메모리에서만, 암호화에 사용 후 즉시 폐기)
       Encrypted DEK  (마스터 키로 암호화됨, 데이터와 함께 저장)

암호화: Plaintext DEK로 1GB 데이터를 로컬 AES-256 암호화 → 메모리의 DEK 파기
저장:   (암호화된 데이터, Encrypted DEK) 한 묶음으로 저장
복호화: Encrypted DEK를 KMS Decrypt에 보냄 → Plaintext DEK 회수 → 로컬 복호화

핵심은 Plaintext DEK를 사용 직후 메모리에서 지운다는 점이다. 디스크에 남는 건 암호화된 데이터와 암호화된 DEK뿐이고, 둘을 합쳐도 마스터 키 없이는 복호화할 수 없다. S3 SSE-KMS, EBS 암호화, RDS 암호화가 모두 내부적으로 이 패턴을 쓴다. EBS는 볼륨마다 별도 DEK를 만들고, 그 DEK를 지정된 KMS 키로 암호화해 볼륨 메타데이터에 붙여둔다.

Envelope Encryption은 새로운 발명이 아니라 PGP(Pretty Good Privacy, 1991)가 30년 전 정립한 하이브리드 암호화 패턴이다. PGP는 메시지를 빠른 대칭키(세션 키)로 암호화하고, 그 세션 키만 수신자의 느린 공개키(RSA)로 암호화해 함께 보낸다. 대칭키는 빠르지만 키 교환이 어렵고, 비대칭키는 키 교환이 쉽지만 느리다 — 둘의 장점만 취하는 게 하이브리드 암호화의 본질이다. KMS의 마스터 키는 비대칭은 아니지만 "느리고 안전한 상위 키 + 빠른 하위 데이터 키"라는 계층 구조는 동일하다. TLS의 세션 키 협상도 같은 원리다.

⚠️ 함정: GenerateDataKey는 Plaintext와 Encrypted DEK를 둘 다 주지만, GenerateDataKeyWithoutPlaintext는 Encrypted DEK만 준다. 후자는 "지금 당장 암호화할 건 아니고, 나중에 복호화할 때 쓸 DEK를 미리 만들어두는" 패턴(예: 일별 키 사전 생성)에 쓴다. 시험에서 "DEK를 만들되 평문은 받지 않는다"는 설명이 나오면 WithoutPlaintext 버전이다. 또 흔한 실수가 Plaintext DEK를 디스크에 저장해버리는 것 — 그 순간 Envelope Encryption의 모든 보안이 무너진다. Plaintext DEK는 메모리에서만 살아야 한다.

Key Policy가 IAM보다 우선하는 이유 — Lambda 봇 두 개의 교착

KMS에는 다른 AWS 서비스에 없는 독특한 권한 규칙이 있다. 모든 KMS 키에는 Key Policy가 반드시 있어야 하고, Key Policy가 명시적으로 허용하지 않으면 IAM 권한이 아무리 넓어도 그 키를 쓸 수 없다. S3 버킷은 버킷 정책이 없어도 IAM만으로 접근되지만, KMS는 다르다. 왜 이렇게 설계했나?

이유는 키 탈취 시 폭발 반경(blast radius)을 제한하기 위해서다. 만약 KMS도 IAM만으로 접근 가능했다면, 누군가 kms:* 권한을 가진 관리자 역할을 탈취하는 순간 계정의 모든 키를 쓸 수 있게 된다. Key Policy를 강제함으로써, 각 키는 자신을 쓸 수 있는 주체를 키 자체에 명시한다 — 키가 자기 방어선을 갖는 셈이다. 보안에 가장 민감한 자산(키)에는 자원 자체에 붙은 정책(resource-based policy)을 의무화해서, IAM 한 곳이 뚫려도 모든 키가 한꺼번에 노출되지 않게 한다.

기본 Key Policy의 한 줄이 이 구조를 만든다.

{
  "Sid": "Enable IAM User Permissions",
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::123456789012:root" },
  "Action": "kms:*",
  "Resource": "*"
}

root는 루트 사용자가 아니라 "이 계정 전체"를 의미한다. 이 한 줄이 있으면 "이 계정의 IAM 정책이 허용하면 키를 쓸 수 있다"가 되어, 평소처럼 IAM으로 권한을 관리할 수 있다. 이 줄을 빼버리면 IAM은 무력해지고 오직 Key Policy에 명시된 주체만 키를 쓰게 된다. 운영 사고 중 가장 무서운 게 이거다 — 실수로 기본 Key Policy의 root 줄을 지우고 자기 자신도 명시하지 않으면, 그 키는 아무도 못 쓰게 되고 되돌릴 방법은 AWS Support 티켓뿐이다. 키를 잠가버린 운영자가 그 키 자체에 대한 권한도 잃기 때문이다.

KMS 권한 평가는 Key Policy → IAM Policy → Grant → Encryption Context 순으로 누적 검토된다. 정확히는 "Key Policy가 IAM을 신뢰하도록 위임했는가"가 먼저 결정되고, 위임됐으면 IAM/Grant 중 하나라도 허용하면 통과한다. 단, 어느 단계든 명시적 Deny가 있으면 즉시 거부된다 — 이건 IAM 전체에 공통인 "explicit deny wins" 원칙이다. Grant는 Key Policy 수정 없이 임시 권한을 주는 장치라 자동화에 유용한데, AWS 서비스(EBS, RDS 등)가 사용자 대신 키를 쓸 때 내부적으로 Grant를 발급한다. 그래서 EBS 암호화 볼륨을 만들면 키에 자동으로 Grant가 붙는 것을 list-grants로 볼 수 있다.

가정해 보자. 한 SaaS 업체가 KMS 키 정책을 IaC(Terraform)로 관리하다가, 템플릿에서 root 위임 줄을 누락한 채 배포해 프로덕션 키를 잠가버렸다. 그 키로 암호화된 RDS와 S3 데이터에 접근할 수 없게 되고, AWS Support의 도움을 받아 키 정책을 복구해야 하는 상황이다. 이 가상의 사례가 주는 교훈은 두 가지다 — 첫째, Key Policy에는 항상 키를 관리할 주체(보통 보안팀 역할)를 root 위임과 별개로 명시할 것. 둘째, KMS 키 삭제·정책 변경은 IaC에서도 사람의 명시적 승인 단계를 둘 것. 재발을 막으려면 Key Policy 변경에 SCP(Service Control Policy)로 가드레일을 걸 수 있다.

키 회전 — backing key는 바뀌어도 Key ID는 그대로다

키 회전을 처음 접하면 직관에 반하는 부분이 있다. "키를 회전하면 옛날 데이터를 어떻게 복호화하지?" 매년 키를 바꾸는데 작년에 암호화한 데이터가 그대로 읽힌다. 비밀은 KMS 키가 사실 여러 개의 backing key(실제 암호 재료)를 품은 컨테이너라는 데 있다.

enable-key-rotation을 켜면 KMS는 매년(현재는 기본 365일, 설정으로 90~2560일 조정 가능) 새 backing key를 생성한다. 하지만 Key ID와 ARN, alias는 그대로 유지된다. 새로 암호화하는 데이터는 최신 backing key로 처리되고, 과거에 암호화된 데이터는 그 데이터에 기록된 backing key 식별자를 보고 해당 시점의 옛 backing key로 복호화한다. KMS가 모든 backing key를 영구 보관하므로 과거 데이터는 항상 읽힌다. 사용자 입장에선 키 하나가 그대로인데 안쪽 재료만 조용히 갱신된다.

이 설계의 장점은 애플리케이션이 회전을 전혀 신경 쓸 필요가 없다는 것이다. 코드는 alias/myapp을 부르기만 하면 되고, 안에서 backing key가 몇 개로 늘어나든 무관하다. 반면 수동 회전(새 키 만들고 alias 옮기기)은 alias를 옮기는 순간 옛 키로 암호화된 데이터를 복호화하려면 옛 키를 명시적으로 살려둬야 한다 — 관리 부담이 크다. 그래서 대칭키는 자동 회전이 표준이고, 수동 회전은 비대칭키나 imported key material처럼 자동 회전이 불가능한 경우에만 쓴다.

⚠️ 함정: 자동 회전은 암호화에 쓰이는 backing key만 바꾼다. 키의 권한(Key Policy)이 유출됐거나 키가 손상됐다고 의심되는 상황에서는 회전이 해결책이 아니다. 회전은 단지 암호 재료를 새것으로 갈 뿐, 옛 backing key를 폐기하지 않으므로 옛 데이터를 복호화할 수 있는 능력은 그대로다. 진짜 손상 시에는 키를 비활성화하고 데이터를 새 키로 재암호화(re-encrypt)해야 한다. 시험에서 "키가 유출된 것 같다, 회전하면 되나?"는 함정이다 — 회전은 사전 예방이지 사후 대응이 아니다.

Multi-Region Key — 리전 종속을 깨는 유일한 예외

일반 KMS 키는 철저히 리전에 종속된다. 서울 리전에서 만든 키로 암호화한 데이터는 도쿄 리전의 KMS로는 절대 복호화할 수 없다. 키 ARN에 리전이 박혀 있고, 그 키의 backing material이 그 리전의 HSM에만 존재하기 때문이다. 이건 의도적이다 — 리전 격리는 AWS의 가용성·규제 준수의 근간이고, 키가 리전을 넘나들면 그 격리가 깨진다.

그런데 Cross-Region 시나리오에서는 이 격리가 걸림돌이 된다. Global DynamoDB Table은 여러 리전에 데이터를 복제하는데, A 리전 키로 암호화된 데이터를 B 리전에서 읽으려면 B 리전에서도 같은 키가 필요하다. S3 Cross-Region Replication에서 SSE-KMS로 암호화된 객체를 다른 리전으로 복제하면 도착지 리전에서 복호화할 키가 있어야 한다.

Multi-Region Key가 이 예외를 만든다. Primary 키를 만들고 다른 리전에 replica를 만들면, 두 키는 같은 Key ID(정확히는 mrk-로 시작하는 공통 키 식별자)와 같은 backing material을 공유한다. 한 리전에서 암호화한 데이터를 다른 리전의 replica 키로 그대로 복호화할 수 있다. 단, 이건 어디까지나 예외적 도구다 — 키 재료가 리전을 넘어 복제되므로 격리가 약해지고, 한 리전에서 키가 손상되면 모든 replica가 영향받는다. 그래서 "정말 Cross-Region 복호화가 필요한 경우에만" 쓰라고 권장한다.

Multi-Region Key의 backing material 복제는 평문으로 네트워크를 타지 않는다. Primary 리전의 HSM과 replica 리전의 HSM이 서로 인증된 보안 채널을 맺고, 키 재료를 암호화된 상태로 전송한 뒤 도착지 HSM 안에서만 복호화한다. 즉 "keys never leave the HSM unencrypted" 원칙이 리전 간 복제에서도 유지된다. replica 키는 만든 후 독립적으로 회전·정책 관리되지만 backing material 식별 체계는 공유한다. Primary를 다른 리전의 replica로 승격(promote)할 수도 있어 DR 시나리오에 쓰인다.

KMS vs CloudHSM — 멀티테넌트 HSM과 단독 HSM의 갈림길

KMS도 결국 HSM 위에서 돈다면, CloudHSM은 왜 따로 존재하나? 차이는 HSM을 다른 고객과 공유하느냐, 통째로 빌리느냐다. KMS의 HSM은 AWS가 운영하며 여러 고객의 키를 (논리적으로 격리된 채) 함께 담는 멀티테넌트 구조다. CloudHSM은 고객이 HSM 장비 자체를 단독으로 임대해, 그 안의 모든 것을 직접 통제한다.

이 차이가 인증 등급을 가른다. KMS는 FIPS 140-2 Level 3 검증을 받은 HSM을 쓰지만 서비스 전체로는 멀티테넌트 운영 모델 때문에 통상 Level 2 맥락으로 설명되고(HSM 모듈 자체는 Level 3), CloudHSM은 고객 단독 점유라 FIPS 140-2 Level 3을 온전히 충족한다. 일부 규제 산업(특정 금융·정부 계약)은 "키가 우리만 접근 가능한 단독 HSM에 있어야 한다"를 명문으로 요구하는데, 이때 KMS로는 컴플라이언스를 만족시킬 수 없고 CloudHSM이 유일한 답이다.

CloudHSM의 무서운 점은 AWS조차 키를 복구할 수 없다는 것이다. CloudHSM 클러스터의 관리자 자격증명을 분실하면 그 안의 키는 영구히 사라지고 AWS도 도와줄 수 없다. 완전한 통제의 대가는 완전한 책임이다. 두 세계를 잇는 다리가 KMS Custom Key Store인데, KMS API의 편의성을 그대로 쓰되 실제 backing key는 고객의 CloudHSM 클러스터에 두는 하이브리드 구성이다.

KMS와 CloudHSM의 선택은 클라우드 보안의 근본 트레이드오프인 "통제권 vs 운영 부담"의 전형이다. 공유 책임 모델(Shared Responsibility Model)에서 통제권을 고객이 더 많이 가져올수록(CloudHSM) 보안 사고의 책임도 고객에게 더 온다. KMS는 키 가용성·내구성·물리 보안을 AWS에 위임하는 대신 멀티테넌트를 수용하고, CloudHSM은 그 반대다. "더 안전한 게 무조건 좋다"가 아니라 "규제가 단독 HSM을 강제하는가, 아니면 운영 단순성이 더 가치 있는가"를 따져야 한다 — 대부분의 워크로드에는 KMS가 정답이고, CloudHSM은 규제가 강제할 때만 꺼내는 카드다.

키 삭제 대기 기간 — 되돌릴 수 없는 작업에 브레이크를 거는 설계

KMS 키는 즉시 삭제할 수 없다. schedule-key-deletion을 호출하면 7~30일(기본 30일)의 대기 기간이 설정되고, 그 기간이 지나야 실제로 삭제된다. 대기 중에는 키가 Pending Deletion 상태로 비활성화돼 어떤 암호화·복호화도 거부한다. 왜 이런 불편한 지연을 강제하나?

이유는 키 삭제가 데이터 영구 손실로 직결되는 비가역적 작업이기 때문이다. 키로 암호화된 데이터는 그 키 없이는 영원히 복호화할 수 없다. 키 하나를 잘못 지우면 그 키로 암호화된 수 테라바이트의 S3·RDS·EBS 데이터가 한순간에 디지털 쓰레기가 된다. 백업조차 같은 키로 암호화돼 있다면 백업도 무용지물이다. 이건 휴지통에서 파일을 지우는 것과는 차원이 다른 사고다.

대기 기간은 이 비가역적 작업에 강제로 브레이크를 거는 안전장치다. 7~30일 동안 누구든 cancel-key-deletion으로 되돌릴 수 있고, 그 사이 CloudWatch로 "Pending Deletion 키에 대한 복호화 시도"를 모니터링하면 "아, 이 키 아직 쓰이고 있었네" 하고 삭제를 취소할 수 있다. 운영 모범 사례는 키 삭제 전에 먼저 키를 비활성화(disable)해서 며칠~몇 주 운영해보고, 아무 문제 없으면 그때 삭제를 예약하는 것이다 — 비활성화는 즉시 되돌릴 수 있으므로 사실상 무료 리허설이다.

KMS의 7~30일 대기 기간은 "되돌릴 수 없는 삭제" 사고를 막으려는 안전장치다. 데이터베이스나 스토리지 서비스에서 "즉시 영구 삭제"가 가능했던 시절, 운영자의 오타 한 줄(DELETE 대상 잘못 지정, 스크립트 변수 미설정 등)로 프로덕션 데이터가 순식간에 증발한 사고가 반복됐다. 2017년 한 코드 호스팅 업체가 운영 DB를 실수로 드롭하고 백업까지 깨져 있던 사건은 "비가역 작업에는 반드시 지연·확인 단계를 둬야 한다"는 교훈을 업계에 남겼다. KMS는 이 교훈을 키 삭제에 못 박았다 — 가장 비싼 실수가 일어날 수 있는 지점에 가장 긴 안전 지연을 둔 것이다.

Encryption Context도 같이 외워둬야 한다. 암호화 시 --encryption-context "Project=Web"처럼 키-값 쌍을 주면, 복호화 시 정확히 같은 context를 제시해야만 복호화된다. 이건 추가 인증 데이터(AAD, Additional Authenticated Data)로 작동해서, 암호문이 의도한 맥락에서만 풀리도록 묶는다. 예를 들어 S3 SSE-KMS는 객체 ARN을 context로 자동 사용해서, 한 객체의 암호문을 다른 위치로 옮겨 복호화하려는 시도를 막는다. 시험에서 "복호화가 실패하는데 권한은 다 맞다"는 시나리오의 숨은 원인이 종종 Encryption Context 불일치다.

정리

KMS의 모든 설계 결정은 "사람이 키를 만지지 않게 한다"는 한 가지 원칙에서 파생된다. 키를 다운로드하는 API가 없는 건 HSM 안에서만 키가 존재하기 때문이고, 4KB 제한이 있는 건 큰 데이터를 마스터 키에 직접 노출시키지 않으려는 Envelope Encryption 강제이고, Key Policy가 IAM보다 우선하는 건 키 하나가 뚫려도 전체가 노출되지 않게 하려는 폭발 반경 제한이고, 삭제에 7~30일이 걸리는 건 비가역적 데이터 손실에 브레이크를 거는 안전장치다.

운영자가 기억할 다섯 가지는 이렇다. ① Envelope Encryption — 큰 데이터는 DEK로 로컬 암호화, KMS는 DEK만 봉인. ② Key Policy 우선 — 기본 정책의 root 위임 줄을 절대 함부로 지우지 말 것. ③ 자동 회전은 backing key만 갈고 Key ID는 불변, 손상 대응책은 아님. ④ Cross-Region 복호화는 Multi-Region Key가 유일한 길. ⑤ 키 삭제는 7~30일 대기, 그전에 비활성화로 리허설. 이 다섯이 KMS 문제의 대부분을 커버한다.

다음 글에선 KMS가 암호화하는 대상 중 가장 까다로운 것 — 자동으로 바뀌어야 하는 비밀(시크릿)을 다룬다. Secrets Manager가 비밀번호를 무중단으로 회전시키는 4단계 춤과, 멀티 리전에서 같은 비밀을 공유하는 법이다.