암호 키 관리와 HSM: 생성·보관·교체·폐기의 수명주기

1장 개념과 보호 목표#

암호키 관리는 안전한 키 생성부터 배포·사용·교체·보관·폐기까지의 수명주기를 통제하는 활동입니다. 알고리즘이 강해도 소스 코드나 로그에 키가 노출되면 보호 효과를 잃습니다.

2장 원리와 구분#

Cryptoperiod는 키를 정해진 용도로 사용하는 기간입니다. 데이터 민감도, 사용량, 노출 위험과 복구 조건에 따라 정하며 모든 키를 동일 주기로 교체할 이유는 없습니다. HSM은 보호 경계 안에서 키 저장·연산을 수행하도록 설계되지만 권한 있는 잘못된 요청을 자동으로 막지는 않습니다. 이중 통제는 여러 승인자의 협조를 요구하고, 비밀 분산은 정해진 수 이상의 조각을 모아 비밀을 복원하는 방식입니다.

3장 비교와 판단 기준#

단계	필요한 통제	확인할 증거
생성·주입	안전한 난수·권한 분리	생성 절차·설정
사용·보관	용도 제한·KMS/HSM·감사	정책·사용 기록
교체·복구	버전·과거 데이터 복원	회전·복원 시험
폐기	복구·보존 영향 확인	승인·삭제 검증

4장 키의 용도부터 분리한다#

저장 데이터 암호화, 통신 인증과 전자서명은 키의 목적이 다릅니다. 하나의 키를 여러 프로토콜과 서비스에서 재사용하면 유출 영향과 사용 조건이 얽힙니다. 키마다 소유자, 목적, 접근자와 수명주기를 정의합니다.

5장 생성은 예측 불가능성의 문제다#

암호 키는 적합한 암호학적 난수원으로 생성합니다. 날짜, 사용자 번호나 일반 난수 함수를 조합하는 방식은 충분한 엔트로피를 보장하지 않습니다. 장치 초기화와 가상 환경의 복제 조건도 확인합니다.

6장 HSM이 보호하는 경계#

HSM은 키를 보호하고 내부에서 암호 연산을 수행하도록 설계된 장치입니다. 개인키를 외부로 추출하지 않는 구조라도 허용된 API를 공격자가 사용할 수 있으면 부적절한 서명·복호화가 발생할 수 있습니다.

키 비노출과 사용 권한은 별도의 통제입니다. 호출 주체, 허용 연산과 요청 데이터 검증을 연결해야 합니다.

7장 DEK와 KEK를 나누는 이유#

데이터를 암호화하는 DEK와 DEK를 보호하는 KEK를 분리하면 키 관리 경계를 설계하기 쉽습니다. 그러나 애플리케이션이 복호화한 DEK와 원문이 메모리에 존재하는 구간은 여전히 보호해야 합니다.

flowchart LR
 D[데이터] --> E[DEK로 암호화]
 K[KEK·키 관리 서비스] --> W[DEK 보호]
 E --> S[암호문 저장]
 W --> S

8장 교체와 재암호화는 다르다#

새 키 버전으로 신규 데이터를 처리하는 교체와 기존 암호문을 새 키로 변환하는 재암호화는 다른 작업입니다. 기존 데이터와 백업에는 이전 키가 필요할 수 있습니다. 버전 식별자를 암호문과 연결하여 올바른 키를 찾게 합니다.

9장 암호 사용 기간은 조건에 따라 정한다#

키의 목적, 사용량, 알고리즘과 노출 위험을 고려해 사용 기간을 정합니다. 정해진 달력 주기만 맞추는 것이 전부는 아닙니다. 키 유출이 의심되면 정상 교체 주기와 별도의 사고 대응이 필요합니다.

10장 복구는 실제로 시험한다#

키를 안전하게 백업해도 복원 권한과 절차가 실패하면 암호문을 읽을 수 없습니다. 복구 자료의 보관 위치와 접근자, 복원 환경을 관리하고 실제 데이터로 복구 가능성을 확인합니다.

복구 과정에서 키를 평문 파일로 내보내는 예외가 생긴다면 그 경로가 새로운 취약점이 될 수 있습니다.

11장 이중 통제와 비밀 분산#

두 사람이 승인하는 이중 통제와 하나의 비밀을 여러 조각으로 나누어 복원하는 비밀 분산은 개념이 다릅니다. 운영 승인 절차와 암호학적 복원 조건을 각각 설계합니다. 이름만으로 같은 보안 효과를 가정하지 않습니다.

12장 폐기는 복사본까지 포함한다#

키 삭제는 운영 저장소의 항목만 지우는 일이 아닙니다. 백업, 캐시, 이전 장치와 복구 자료에 남은 복사본을 확인합니다. 암호학적 삭제도 다른 원문·키 복사본이 남아 있지 않아야 목적에 맞게 작동합니다.

13장 키 유출의 대응 사례#

외부에 노출된 키를 발견하면 사용을 제한하고 접근 기록과 영향 범위를 조사합니다. 새 키 발급, 인증서 폐지 또는 데이터 재암호화는 키의 용도에 따라 달라집니다. 이미 유출된 암호문과 이전 서명의 영향을 별도로 평가합니다.

14장 백업 복원 실패를 막는 키 버전 설계#

예를 들어 파일 X는 키 버전 1, 파일 Y는 버전 2로 암호화되어 있습니다. 운영 키를 버전 3으로 교체한 뒤 1·2를 삭제하면 현재 서비스의 신규 쓰기는 정상이어도 X·Y를 읽거나 과거 백업을 복원하지 못할 수 있습니다. 암호문에는 키를 직접 넣는 대신 키 식별자와 필요한 형식 정보를 연결합니다.

이전 키는 신규 암호화에 사용하지 않도록 제한하면서 허용된 복호화·복구에 필요한 기간 동안 보호할 수 있습니다. 폐기 시점은 데이터·백업·법적 보관과 업무 복원 요구를 확인하여 결정합니다. 키 보유와 키 사용 허용을 같은 상태로 관리하지 않는 것이 핵심입니다.

시험에서는 새 파일 작성, 이전 파일 읽기와 과거 백업 복원을 각각 수행합니다. 권한 없는 계정의 이전 키 사용은 거부되는지도 확인해야 합니다.

15장 적용 사례와 운영 방법#

키 회전 후에도 기존 백업을 읽어야 한다면 과거 키를 통제된 상태로 유지해야 합니다. 키 유출 시 신규 데이터 보호뿐 아니라 이전 암호문의 영향과 재암호화를 검토합니다. 소스에 들어간 키를 제거하는 것만으로 노출이 해소되지는 않으므로 회수·교체와 접근 기록 검토가 필요합니다.

16장 키 수명주기#

flowchart LR
 A["생성·주입"] --> B["용도별 사용"]
 B --> C["교체·버전 관리"]
 C --> D["과거 데이터용 통제 보관"]
 D --> E["복구 영향 확인 후 폐기"]

17장 키 목록에는 소유자와 복구 의존성을 함께 남긴다#

키의 ID·용도·알고리즘·버전·소유자·사용 상태·보호 위치·교체 조건·연결 데이터를 기록합니다. 서명 키와 데이터 암호화 키는 영향과 보존 요구가 다를 수 있습니다. 인증서 만료와 키 재료 폐기, 새 데이터용 키 전환과 기존 데이터 복호화 허용도 각각 구분해야 합니다.

HSM의 보호 경계는 장비 내부의 키 저장·연산과 관련됩니다. 정상 자격증명으로 잘못된 서명이나 복호화를 요청하는 행위는 API 인가·업무 승인·감사로 제한해야 합니다. 장비 검증의 대상 버전·구성과 실제 운영 환경이 일치하는지도 확인합니다.

18장 키 노출 사고에서 우선 조사할 것#

노출된 키가 어떤 데이터·기간·시스템에 사용되었는지 조사하고 새 사용을 제한합니다. 단순 파일 삭제로 끝내지 말고 회수·교체·관련 자격증명·과거 암호문 영향과 사용 로그를 검토합니다. 이전 데이터를 새 키로 재암호화해야 하는지와 복구 가능한 백업을 유지할지도 판단합니다.

이중 통제는 승인권자의 분리, 비밀 분산은 복원에 필요한 조각의 구조입니다. 조각을 같은 관리자·저장소에 몰아두면 기대한 분리가 약해집니다. 실제 복원 훈련, 담당자 부재, HSM 장애와 폐기 승인까지 검증해야 운영 가능한 키 관리가 됩니다.

19장 적용 전 확인할 사항#

용도·소유자·버전·사용 기간을 기록한다
키 사용과 관리 권한을 분리한다
폐기 전 백업 복구·보존 의무를 확인한다

20장 자주 묻는 질문#

HSM에 넣은 키는 절대 유출되거나 악용되지 않나요?#

장비의 보호·검증 범위와 운영 조건을 확인해야 합니다. 관리자 권한, API 인가, 백업과 사고 대응을 함께 통제해야 합니다.

키를 정기 교체하면 노출된 과거 데이터도 안전해지나요?#

기존 암호문과 노출 키의 관계는 남을 수 있습니다. 새 사용 중단과 과거 데이터 영향·재암호화·백업 처리 계획을 따로 검토해야 합니다.

키 백업을 없애면 더 안전한가요?#

노출 가능성은 줄 수 있지만 데이터 복구 불능 위험이 생깁니다. 보호된 백업과 접근 분리·복원 검증을 업무의 보존 요구에 맞춰 설계해야 합니다.