Key Management Fundamentals
AWS KMS 문제를 풀면서 봉투 암호화 흐름은 익혔는데, 그 앞단에 있는 “키 관리 생명주기” 개념 자체를 별도로 정리한 적이 없어서 여기 채움
Key Lifecycle (키 생명주기)
생성(Generation) → 배포(Distribution) → 저장(Storage)
→ 사용(Usage) → 교체(Rotation) → 폐기(Revocation/Destruction)
각 단계마다 별도의 리스크가 있다는 게 핵심임 아무리 강력한 알고리즘을 써도 키 저장이 허술하면 전체가 무너짐
HSM(Hardware Security Module)이 존재하는 이유
Physical device that generates, stores, and manages cryptographic keys without ever exposing the raw key material outside its boundary (암호화 키를 생성·저장·관리하되, 원본 키 자료를 자신의 경계 밖으로 절대 노출시키지 않는 물리적 장치)
- 소프트웨어로만 키를 관리하면, 메모리 덤프나 서버 침해로 키가 그대로 유출될 위험이 있음
- HSM은 키가 “장치 밖으로 나가지 않는다”는 걸 물리적으로 보장 — AWS KMS의 마스터 키가 HSM 밖으로 안 나온다는 게 이 원리
키 교체(Rotation)가 필요한 이유
- 하나의 키를 오래 쓸수록, 그 키로 암호화된 데이터량이 누적되고 유출 시 피해 범위가 커짐
- 정기적으로 키를 바꾸면, 한 키가 뚫려도 피해가 “그 키가 쓰인 기간”으로 한정됨
- 다만 회전 시 이전 키로 암호화된 데이터를 여전히 복호화할 수 있어야 하므로, 옛 키를 완전히 폐기하지 않고 버전 관리하는 방식이 일반적
대칭키 배포 문제 → 비대칭키가 푸는 방식
대칭키는 양쪽이 같은 키를 가져야 하는데, 그 키를 처음에 안전하게 “나눠 갖는” 것 자체가 문제다(키 배포 문제) 비대칭키는 공개키를 그냥 공개해도 되므로, 이 문제를 근본적으로 우회한다 — TLS가 비대칭키로 세션을 열고 대칭키로 전환하는 이유이기도 함
더 생각해볼 것들
- 우리가 다루는 시스템 중 키 회전이 전혀 안 되고 있는 곳이 있다면 어디일까
- HSM 없이 소프트웨어만으로 키를 관리해야 하는 상황이라면 어떤 보완책을 둬야 할까
원본: summary