KMS vs CloudHSM vs Secrets Manager
01-summary에서 KMS 봉투 암호화와 Custom Key Store(CloudHSM 연동)는 다뤘는데, Secrets Manager까지 셋을 한 번에 비교해본 적이 없어서 정리함 세 서비스 모두 “민감한 값을 안전하게 다룬다”는 목적은 같아서 오히려 헷갈리기 쉬움
세 서비스의 근본적 목적 차이
| 서비스 | 무엇을 다루는가 | 핵심 기능 |
|---|---|---|
| KMS | 암호화 키 | 데이터를 암호화/복호화하기 위한 키 관리 |
| CloudHSM | 암호화 키 (단독 전용) | 멀티테넌트 없이 내 전용 HSM 클러스터에서 키 관리 |
| Secrets Manager | 애플리케이션 시크릿(DB 비밀번호, API 키 등) | 시크릿 저장 + 자동 순환(rotation) + 애플리케이션 조회 |
헷갈리는 이유
KMS도 “키를 관리”하고 Secrets Manager도 “민감한 값을 저장”하다 보니 같은 서비스처럼 느껴지지만, KMS는 암호화 연산에 쓰는 “키” 자체가 대상이고 Secrets Manager는 애플리케이션이 실제로 꺼내 쓰는 “값”(예: DB 비밀번호 문자열)이 대상임 실제로 Secrets Manager는 내부적으로 저장된 시크릿을 암호화할 때 KMS를 사용한다 — 즉 Secrets Manager가 KMS 위에 얹혀 있는 구조
KMS vs CloudHSM 선택 기준
- KMS(기본): AWS가 관리하는 멀티테넌트 HSM. 대부분의 경우 충분하고 관리 부담이 적음
- CloudHSM: FIPS 140-2 Level 3 같은 컴플라이언스 요건, 또는 “내 키 자료가 다른 테넌트와 물리적으로도 절대 안 섞여야 한다”는 요건이 있을 때 관리 부담(패치, 클러스터 운영)이 늘어나는 대신 통제권이 커짐
Secrets Manager vs Parameter Store (자주 나오는 비교)
| 구분 | Secrets Manager | Systems Manager Parameter Store |
|---|---|---|
| 자동 순환 | 지원 (Lambda 연동) | 미지원(직접 구현 필요) |
| 비용 | 시크릿당 과금 | 표준 티어는 무료 |
| 주 용도 | DB 자격증명처럼 주기적으로 순환해야 하는 시크릿 | 설정값, 덜 민감한 파라미터 |
“자동 순환이 필요하다”는 표현이 나오면 Secrets Manager, “그냥 설정값 저장”이면 Parameter Store로 갈리는 경우가 많다는 감각을 기억해두려 함
더 생각해볼 것들
- DB 비밀번호를 Secrets Manager로 옮기고 자동 순환을 켰을 때, 애플리케이션 쪽 연결 로직은 어떻게 대응해야 끊김이 없을까
- CloudHSM을 실제로 써야 하는 컴플라이언스 요건(FIPS, PCI-DSS 등)을 좀 더 구체적으로 찾아보고 싶음
원본: summary