키 관리·교차 계정·CMK 설계로 배우는 KMS와 봉투 암호화
_Category: Data Protection_
데이터를 암호화해도 암호화 키를 안전하게 관리하지 못하면 아무 소용이 없습니다. AWS KMS(Key Management Service)는 바로 그 문제를 해결합니다. SCS-C03에서 KMS는 S3·EBS·RDS·Secrets Manager 등과 얽혀 복합 시나리오로 자주 출제됩니다. 키의 종류, 권한 모델, 봉투 암호화 흐름을 이해하면 대부분의 KMS 문제는 패턴으로 풀 수 있습니다.
---
KMS가 풀어주는 문제: 직접 키 관리의 위험
암호화 키를 직접 관리한다는 것은 어떤 의미일까요? 금고 안에 귀중품을 보관했는데, 금고 열쇠를 책상 서랍에 테이프로 붙여놓은 것과 비슷합니다. 코드베이스에 AES-256 키를 하드코딩하거나, 환경 변수에 평문으로 넣어두거나, 서버 로컬 디스크에 저장하는 방식이 대표적인 안티패턴입니다.
AWS KMS는 이런 문제를 세 가지 방식으로 해결합니다. 첫째, 키 재료(key material)를 HSM(Hardware Security Module) 내부에 보관하여 AWS 서비스나 고객 모두 평문 마스터 키를 직접 꺼낼 수 없게 합니다. 둘째, 모든 암호화·복호화 작업이 KMS API 호출을 통해 이루어지므로 CloudTrail에 완전한 감사 로그가 남습니다. 셋째, IAM과 연동되는 세밀한 접근 제어를 키 단위로 적용할 수 있습니다.
시험에서 "감사 로그", "키 접근 추적", "중앙 집중식 키 관리"라는 키워드가 보이면 KMS가 정답 방향입니다. "직접 HSM 하드웨어 통제가 필요하다"면 CloudHSM으로 연결됩니다.
---
키의 종류: Customer Managed Key vs AWS Managed Key vs AWS Owned Key
KMS에는 세 가지 키 유형이 있습니다. 마치 자동차를 직접 구매해 운전하는지, 렌터카를 빌리는지, 택시를 타는지의 차이와 비슷합니다.
| 구분 | Customer Managed Key (CMK) | AWS Managed Key | AWS Owned Key | |------|--------------------------|-----------------|---------------| | 생성 주체 | 고객 | AWS (서비스별 자동 생성) | AWS | | Key Policy 편집 | 가능 | 불가 | 불가 | | 키 교체(Rotation) | 수동 또는 자동(연 1회) | 자동(연 1회) | AWS 관리 | | CloudTrail 로그 | 상세 기록 | 기록 | 미노출 | | 비용 | 키당 월 $1 + API 호출 비용 | 무료 | 무료 | | 사용 예 | 직접 만든 CMK로 S3·EBS 암호화 | S3 SSE-KMS 기본 키, RDS 기본 암호화 | S3 SSE-S3 내부 키 | | 교차 계정 공유 | 가능 (Key Policy로 제어) | 불가 | 불가 |
시험에서 "키 정책을 직접 제어하고 싶다", "교차 계정에서 키를 사용해야 한다", "키 접근을 즉시 비활성화해야 한다" 조건이 나오면 반드시 Customer Managed Key(CMK)를 선택해야 합니다. AWS Managed Key는 편리하지만 고객이 Key Policy를 편집할 수 없기 때문입니다.
키 교체와 관련해 자주 나오는 함정이 있습니다. Imported Key Material로 만든 CMK는 자동 교체를 지원하지 않습니다. 이 경우 새 CMK를 생성하고 KMS Alias를 교체하는 수동 로테이션이 공식 모범 사례입니다. Alias 재지정만으로 애플리케이션 코드 변경 없이 신규 키로 전환할 수 있습니다.
!KMS 키 3가지 유형
봉투 암호화의 동작 원리
봉투 암호화(Envelope Encryption)는 KMS의 핵심 개념입니다. 이름 그대로 "비밀번호가 적힌 종이를 금고 키로 잠근 봉투"를 상상하면 됩니다. 실제 데이터를 직접 KMS로 암호화하는 것이 아니라, 임시 데이터 키(Data Key, DEK)로 데이터를 암호화하고, 그 DEK를 KMS 마스터 키(CMK)로 다시 암호화하는 2단계 구조입니다.
암호화 흐름: GenerateDataKey API 호출 → KMS가 평문 DEK와 encrypted DEK 반환 → 평문 DEK로 로컬 암호화 → 평문 DEK 메모리에서 즉시 삭제 → 암호화된 데이터와 encrypted DEK 함께 저장.
복호화 흐름: encrypted DEK를 KMS Decrypt API로 평문 DEK 복원 → 데이터 복호화 → 평문 DEK 즉시 삭제.
이 구조의 장점은 두 가지입니다. 대용량 데이터도 로컬에서 빠르게 처리 가능하고(KMS는 4KB 이하만 직접 처리), CMK를 비활성화하면 모든 DEK가 쓸모없어져 데이터 접근을 일괄 차단할 수 있습니다.
시험 함정: 클라이언트 측 암호화(CSE)에서 kms:Encrypt+kms:Decrypt만으로는 부족합니다. DEK 생성을 위해 kms:GenerateDataKey가 추가로 필요합니다. S3 멀티파트 업로드에서도 소용량 파일은 kms:GenerateDataKey만으로 성공하지만, 대용량 파일의 CompleteMultipartUpload 단계에서는 kms:Decrypt도 필요합니다.
---
권한 모델: Key Policy, IAM Policy, Grant의 3겹 구조
KMS 권한은 세 가지 레이어가 겹쳐 작동합니다. 이를 건물 출입 시스템에 비유하면 이해하기 쉽습니다.
| 레이어 | 비유 | 특징 | 적용 시점 | |--------|------|------|----------| | Key Policy | 건물 출입 마스터 정책 | 키에 직접 부착된 리소스 기반 정책. 반드시 Key Policy에서 허용해야 IAM Policy가 효력 발휘 | 항상 상시 적용 | | IAM Policy | 직원 출입증 | 자격증명 기반 정책(역할·사용자에 부착). Key Policy가 계정 루트에 IAM 위임을 허용한 경우에만 유효 | 항상 상시 적용 | | Grant | 임시 위임장 | 특정 Principal에게 특정 작업만 일시적으로 위임. AWS 서비스(EBS, ECS 등)가 고객 CMK로 데이터 처리 시 주로 내부 사용 | 즉시 유효, 만료 또는 취소 가능 |
가장 중요한 원칙이 있습니다. Key Policy에 계정 루트() Principal이 없으면 해당 계정의 IAM 정책이 아무리 허용해도 키에 접근할 수 없습니다. 이 루트 위임 구문이 빠지면 키 복구 자체가 불가능해집니다. KMS 콘솔로 생성 시 자동 포함되지만, API나 IaC로 수동 생성할 때는 주의가 필요합니다.
kms:ViaService 조건은 특정 AWS 서비스를 통한 요청일 때만 키 사용을 허용합니다. 마치 "정문을 통해서만 유효한 출입증"과 같습니다. 을 Key Policy에 추가하면 S3 서비스가 그 리전에서 키를 사용할 때만 허용되고 직접 KMS API 호출은 차단됩니다.
kms:EncryptionContext 조건은 암호화 맥락(context) 검증에 사용됩니다. 으로 암호화한 데이터는 동일한 context 없이는 복호화가 거부됩니다. 프로덕션 데이터가 스테이징에서 복호화되는 사고를 방지하는 암호학적 바인딩입니다.
Grant는 Key Policy를 수정하지 않고 임시로 권한을 위임할 때 사용합니다. EBS 볼륨을 EC2에 연결할 때 AWS가 내부적으로 Grant를 발급합니다. 장기 접근 제어에는 Key Policy 또는 IAM Policy가 적합합니다.
---
Cross-Account Key 접근과 Multi-Region Key 패턴
교차 계정(Cross-Account) KMS 키 접근의 핵심은 양쪽 모두에서 허용해야 한다는 것입니다. 계정 A의 Key Policy에 계정 B의 Principal을 허용하고, 계정 B의 IAM Policy에서 해당 역할에 kms:Decrypt 등을 허용해야 합니다. Key Policy에서 계정 B를 허용했더라도 계정 B의 IAM Policy가 없으면 접근이 거부됩니다.
교차 계정 EBS 스냅샷 복사 시, 원본 계정의 CMK 의존성을 끊으려면 복사 시 백업 계정의 CMK로 재암호화해야 합니다. 이렇게 하면 원본 계정이 침해되더라도 백업 스냅샷은 백업 계정의 CMK로 독립적으로 관리됩니다.
aws:PrincipalOrgID 조건 키는 조직 ID 하나만으로 모든 멤버 계정의 접근을 허용할 수 있어, 신규 계정이 추가되어도 Key Policy 수정 없이 자동 적용됩니다.
Multi-Region Key는 하나의 기본 키(primary key)를 여러 리전에 복제하는 기능입니다. 복제된 키는 동일한 키 ID와 키 재료를 공유하므로, 리전 A에서 암호화한 데이터를 리전 B에서 동일 키로 복호화할 수 있습니다. Secrets Manager 멀티 리전 복제와 조합하면 리전마다 별도 키를 관리하는 오버헤드가 사라집니다.
Imported Key Material은 외부 HSM 등에서 생성한 키 재료를 KMS로 가져오는 방식입니다. 자동 교체가 지원되지 않으므로 연간 로테이션 규정을 충족하려면 새 CMK를 생성하고 Alias를 재지정하는 수동 방식으로 진행해야 합니다. Imported Key Material을 즉시 삭제하면 해당 키로 암호화된 모든 데이터가 즉각 복호화 불가능 상태가 되어 "24시간 이내 즉시 차단" 요건에 적합합니다.
---
KMS와 통합되는 핵심 서비스
KMS는 거의 모든 AWS 스토리지·데이터베이스·컴퓨트 서비스와 통합됩니다. S3 서버 측 암호화는 세 가지 방식이 있습니다. SSE-S3는 S3가 키 생성과 관리를 전부 자동 처리하며 객체마다 고유한 AES-256 키를 사용합니다. SSE-KMS는 고객이 지정한 CMK를 사용하고 CloudTrail 로그가 남아 감사 추적이 가능합니다. SSE-C는 고객이 요청마다 키를 직접 전달하는 방식으로, AWS는 키를 저장하지 않습니다.
EBS는 볼륨 생성 시 암호화를 활성화하면 KMS CMK로 투명하게 암호화됩니다. 이미 생성된 볼륨은 직접 암호화할 수 없고, 스냅샷을 생성한 뒤 복사 시 암호화 옵션을 적용해야 합니다. RDS는 인스턴스 생성 시점에만 암호화를 활성화할 수 있으며, 미암호화 인스턴스를 암호화하려면 스냅샷 생성 후 암호화 옵션으로 복원해야 합니다.
Secrets Manager는 KMS CMK로 시크릿을 암호화하며, CloudFormation 동적 참조()를 통해 템플릿에 평문 자격 증명을 노출하지 않고 배포 시 자동으로 값을 가져올 수 있습니다. Secrets Manager는 자동 교체(rotation), 교차 계정 접근, 리전 복제를 지원합니다. Parameter Store SecureString은 KMS CMK로 암호화되며 비용이 낮고 단순 설정 관리에 적합하지만, 교차 계정 접근과 자동 교체는 지원하지 않습니다.
| 서비스 | CMK 지정 가능 | 교차 계정 공유 | 자동 교체 | |--------|-------------|--------------|----------| | S3 SSE-KMS | 가능 | CMK에 한해 가능 | 불가(키 수동 관리) | | EBS | 가능 | 스냅샷 재암호화 | 불가 | | RDS | 가능 | 스냅샷 공유 후 재암호화 | 불가 | | Secrets Manager | 가능 | 리소스 정책으로 가능 | 가능 | | Parameter Store SecureString | 가능 | 불가 | 불가 |
---
시험에서 헷갈리는 KMS 시나리오
실제 시험에서 자주 나오는 KMS 시나리오 패턴을 정리합니다.
"즉시 차단" 요건: Imported Key Material로 생성된 CMK라면 키 재료를 직접 삭제하는 것이 가장 빠릅니다. Scheduled Deletion은 최소 7일 대기 기간이 있어 24시간 이내 요건을 충족할 수 없습니다. 단순히 특정 IAM 엔티티만 차단하고 싶다면 Key Policy Deny를 추가하는 방법이 있습니다.
"삭제된 KMS 키 복구": KMS는 삭제 예약 후 최소 7일(기본 30일)의 Pending Deletion 기간을 제공합니다. 이 기간 중 CancelKeyDeletion API를 호출하면 키가 완전히 복원됩니다. EC2 인스턴스가 EBS 볼륨에 정상 접근 중이라는 사실이 키가 아직 Pending Deletion 상태임을 의미합니다.
"S3 멀티파트 업로드 권한 부족": Lambda 실행 역할에 kms:GenerateDataKey만 있으면 소용량 파일 PUT은 성공하지만, 대용량 파일의 CompleteMultipartUpload 단계에서 kms:Decrypt도 필요합니다. 이 권한이 없으면 대용량 파일에서만 권한 오류가 발생합니다.
"KMS와 CloudHSM의 차이": KMS는 완전 관리형 서비스로 HSM 하드웨어를 AWS가 관리합니다. CloudHSM은 고객이 전용 HSM 하드웨어를 직접 관리하며, FIPS 140-2 Level 3 인증이 필요하거나 HSM에 대한 완전한 통제권이 요구될 때 선택합니다. KMS 커스텀 키스토어(Custom Key Store)를 통해 CloudHSM과 KMS를 연동할 수도 있습니다.
---
시험 핵심 정리
키워드가 보이는 순간 정답 방향을 연결할 수 있도록 핵심 패턴을 정리합니다.
키 종류 선택: "키 정책 직접 제어", "교차 계정 공유", "즉시 비활성화" → Customer Managed Key(CMK) "외부 HSM 키 재료 사용" → Imported Key Material CMK (자동 교체 불가, Alias 수동 교체)