안전하게 키를 보관하려면 무엇을 봐야 할까? KMS 서비스 선택 기준 정리
클라우드에서 암호키를 직접 파일이나 애플리케이션 설정값으로 관리하면 접근 통제, 회전, 감사 기록을 일관되게 유지하기가 어렵다. 그래서 많은 팀이 KMS(Key Management Service)를 사용한다. KMS를 고를 때는 단순히 "암호화가 된다"는 점보다 키가 어디에 저장되는지, 누가 접근할 수 있는지, 회전과 감사가 어떻게 되는지를 먼저 봐야 한다.
이 글은 2026년 5월 5일 기준 AWS KMS, Google Cloud KMS, Azure Key Vault 및 Managed HSM 공식 문서를 바탕으로, 안전하게 키를 보관하기 위해 확인해야 할 기준을 객관적으로 정리한 글이다.
KMS를 볼 때 가장 먼저 확인할 기준은 무엇인가?
실무에서는 아래 다섯 가지를 먼저 보면 서비스 성격이 빠르게 정리된다.
- 키가 소프트웨어 보호인지, HSM 기반인지
- 멀티테넌트인지, 싱글테넌트인지
- 접근 제어가 IAM, 키 정책, RBAC 등 어떤 방식인지
- 자동 회전과 수동 회전이 어디까지 지원되는지
- 감사 로그와 지역 고정 같은 운영 요구사항을 충족하는지
같은 "KMS"라는 이름을 써도 지원 범위는 다르다. 어떤 서비스는 키 관리에 집중하고, 어떤 서비스는 secrets나 certificates까지 함께 다룬다. 따라서 기능명을 그대로 비교하기보다 운영 모델을 비교하는 편이 정확하다.
AWS KMS는 어떤 경우에 적합한가?
AWS 문서에 따르면 AWS KMS에는 고객이 직접 생성하고 정책, 회전, 삭제 일정을 제어하는 customer managed key와, AWS 서비스가 계정 안에서 관리하는 AWS managed key, 그리고 AWS 서비스 계정이 소유하는 AWS owned key가 있다. 제어와 감사가 중요하면 customer managed key가 중심이 된다.
AWS KMS는 customer managed key에 대해 키 정책, IAM 정책, grants, alias, rotation, deletion scheduling을 제어할 수 있다고 설명한다. 또한 사용 내역은 AWS CloudTrail에서 감사할 수 있다. 반대로 AWS managed key는 볼 수는 있지만 속성 변경이나 정책 수정, 삭제 예약은 할 수 없고, 자동 회전 주기도 사용자가 바꿀 수 없다.
회전 정책도 확인해야 한다. AWS 문서 기준으로 자동 회전은 대칭 암호화용 customer managed key에서 지원되며, 기본 주기는 1년이고 사용자 정의 일수도 지정할 수 있다. 즉 "키를 AWS에 보관한다"는 사실만으로 충분하지 않고, 어떤 키 유형인지와 누가 수명주기를 관리하는지까지 봐야 한다.
Google Cloud KMS는 무엇이 다른가?
Google Cloud KMS 문서는 보호 수준을 명확하게 구분한다. 기본 소프트웨어 보호인 SOFTWARE, Google 소유 HSM에서 동작하는 HSM, 전용 파티션을 쓰는 HSM_SINGLE_TENANT, 외부 키 관리자와 연결하는 EXTERNAL, VPC 기반 외부 키 연결인 EXTERNAL_VPC가 대표적이다.
이 구조의 장점은 "보호 수준"을 먼저 결정하고 같은 API와 클라이언트 라이브러리 흐름 안에서 운영할 수 있다는 점이다. 공식 문서에는 모든 보호 수준에서 IAM 역할로 접근을 제어하고, 키 작업을 감사 로그로 남길 수 있다고 정리돼 있다. 또 Cloud HSM은 FIPS 140-2 Level 3 검증 HSM을 사용한다고 설명한다.
외부 키가 필요한 조직이라면 EXTERNAL과 EXTERNAL_VPC 차이도 중요하다. Google은 외부 인터넷 경유 방식보다 VPC 기반 방식이 가용성 측면에서 더 유리할 수 있다고 안내한다. 즉 Google Cloud에서는 같은 KMS 안에서도 소프트웨어, 멀티테넌트 HSM, 싱글테넌트 HSM, 외부 키를 단계적으로 선택할 수 있다.
Azure는 Key Vault와 Managed HSM을 어떻게 나눠 봐야 하나?
Azure 문서상 Key Vault는 keys, secrets, certificates를 함께 다루는 서비스다. 반면 Managed HSM은 키 전용 서비스로, secrets와 certificates는 지원하지 않는다. 이 차이부터 이해해야 설계가 깔끔해진다.
Azure Managed HSM 문서는 이 서비스를 fully managed, highly available, single-tenant HSM 서비스라고 설명하며, FIPS 140-3 Level 3 validated HSM을 사용한다고 밝힌다. 또 각 인스턴스는 고객별 보안 도메인으로 격리되고, 로컬 RBAC 모델과 Azure Monitor 기반 감사 기능을 제공한다고 설명한다.
정리하면 Azure에서 "키만 강하게 보호"가 목표라면 Managed HSM을, 키 외에 secrets와 certificates까지 함께 다뤄야 하면 Key Vault를 먼저 검토하는 구조다. 다만 Managed HSM은 소프트웨어 보호 키나 secrets 저장소의 대체재가 아니라는 점을 구분해야 한다.
안전한 키 보관 관점에서 어떤 선택이 합리적인가?
규제 요구가 크지 않고 클라우드 네이티브 서비스와 빠르게 연동하는 것이 우선이면 소프트웨어 보호 키나 기본 KMS 기능으로 시작하는 경우가 많다. 반대로 HSM 요구사항, 싱글테넌시, 외부 키 주권, 세밀한 감사 추적이 중요하면 HSM 또는 외부 키 관리 기능을 먼저 검토해야 한다.
다음처럼 나누면 판단이 쉬워진다.
- 운영 단순성이 우선이면: 클라우드 기본 KMS와 customer managed key 또는 기본 vault 모델
- 키 보호 수준 강화가 우선이면: HSM 기반 옵션
- 테넌트 분리가 중요하면: single-tenant HSM 계열
- 키를 클라우드 밖에서 통제해야 하면: external key management 계열
- 키 외에 secrets, certificates 관리도 필요하면: Azure Key Vault처럼 객체 범위가 넓은 서비스 검토
FAQ
Q. KMS만 쓰면 애플리케이션의 모든 비밀번호와 인증서를 한 곳에 보관할 수 있나?
서비스마다 다르다. Azure Key Vault는 keys, secrets, certificates를 지원하지만, Azure Managed HSM은 키만 지원한다. Google Cloud KMS 문서는 키 보호 수준과 키 작업에 초점이 있고, AWS KMS 문서도 키 관리 중심으로 설명한다. 따라서 "KMS"라는 이름만 보고 secrets 저장 기능까지 있다고 가정하면 안 된다.
Q. 자동 회전이 되면 기존 데이터를 다시 모두 암호화해야 하나?
AWS KMS 문서는 키 회전이 현재 키 재료를 바꾸는 것이지, 기존에 보호한 데이터를 다시 암호화하는 동작은 아니라고 설명한다. 회전 후에도 AWS KMS는 기존 암호문을 복호화할 때 맞는 키 재료를 자동으로 사용한다. 다른 클라우드도 회전 방식은 서비스별 문서를 따로 확인하는 편이 안전하다.
Q. HSM이면 무조건 더 좋은가?
보호 수준과 규제 대응 측면에서는 장점이 있지만, 비용과 운영 제약도 함께 본다. 공식 문서만 놓고 보면 HSM 계열은 대체로 더 높은 보호 수준과 격리 모델을 제공하지만, 모든 워크로드에 반드시 필요한 것은 아니다. 요구사항 없이 HSM을 선택하는 것보다 접근 통제, 회전, 감사 요구를 먼저 정리하는 편이 합리적이다.
정리
안전하게 키를 보관하려면 서비스 이름보다 운영 모델을 봐야 한다. AWS KMS는 고객 관리 키와 회전 정책 통제가 강점이고, Google Cloud KMS는 보호 수준 선택 폭이 넓으며, Azure는 Key Vault와 Managed HSM의 역할이 분명하게 나뉜다. 결국 핵심은 HSM 여부, 테넌시, 접근 제어, 회전, 감사 로그, 외부 키 요구사항을 기준으로 선택하는 것이다.
참고 자료
'프로그래밍 > 서버, DBMS' 카테고리의 다른 글
| Let's Encrypt rate limit은 어떻게 계산될까? 2026 기준 발급 제한과 재시도 방법 정리 (0) | 2026.05.08 |
|---|---|
| CSP nonce와 hash는 언제 써야 할까? strict-dynamic까지 한 번에 정리 (0) | 2026.05.06 |
| MySql - DB 저장 위치 변경 & 디스크 변경 (데이터 복사) (0) | 2022.04.08 |
| 리눅스 파일 전송 명령어 : SCP (0) | 2021.12.15 |
| 동일한 요청을 여러 서버에 Broadcasting 해주는 NginX mirror (0) | 2021.11.27 |