프라이빗 CA 백업: 암호화 아카이브 대 HSM 키 백업

이것의 대부분을 결정하는 질문은 아카이브를 어떻게 암호화하는지가 아닙니다. CA 개인 키가 애초에 컨테이너를 떠날 수 있는지입니다. 키가 파일이라면 전체 CA 디렉터리를 하나의 암호화된 블롭에 복사하고 몇 분 만에 끝낼 수 있습니다. 키가 HSM이나 키를 추출 불가로 표시하는 토큰에 산다면 그 복사본은 존재하지 않으며, 계획은 공급업체의 래핑 및 복원 절차에 관한 계획이 됩니다. 두 모델 모두 작동하고, 서로 다르게 실패하며, 견딜 수 있는 쪽의 실패를 중심으로 설계할 가치가 있습니다.

두 백업 모델이 갈라지는 지점

모델 A는 디렉터리 복사입니다. OpenSSL 스타일 CA는 작업 디렉터리이며 단일 인증서가 아닙니다: ca.key 또는 cakey.pem, ca.crt, 발급 데이터베이스, serial 및 crlnumber 카운터, 그리고 openssl.cnf입니다. 그 디렉터리를 대칭 암호로 봉인하고 결과를 두 번째 매체로 옮기면, 복원은 풀기·검증·서명입니다. 발급자에게 필요한 모든 것이 함께 이동하며, 아무도 썼다고 기억하지 못하는 몇 주 분량의 폐기 이력도 포함됩니다.

모델 B는 키 격리입니다. 키는 PKCS#11 모듈 내부에서 생성되고 추출 불가로 표시되며, 모듈은 백업을 위해 키를 감쌀 수 있지만 어떤 프로세스도 원시 바이트를 읽지 않습니다. 그러면 백업은 올바른 순서로 복원해야 하는 두 가지 산출물입니다: 그 모듈 제품군만 풀 수 있는 감싼 키 블롭과, 데이터베이스·구성·인증서의 일반 사본입니다.

비교는 어느 모델이 추상적으로 더 강한가에 관한 것이 아닙니다. 실제로 깨어 있는 사람들과 함께 팀이 새벽 2시에 어느 것을 복원할 수 있는가에 관한 것입니다. 아무도 복호화할 수 없는 아카이브와 아무도 시험하지 않은 HSM 블롭은 똑같이 쓸모없습니다. 차이는 아카이브 실패는 비밀번호 관리자에 나타나고, HSM 실패는 지원 계약 속에 숨는다는 점입니다.

모든 CA 백업에 담아야 할 것

두 모델 모두 같은 레코드 집합이 필요합니다. OpenSSL CA에서는 index.txt가 발급된 인증서마다 한 행으로 상태·만료·serial·주체를 담고, 이어서 index.txt.attr, 다음 발급할 serial을 보관하는 serial, 다음 CRL 번호를 보관하는 crlnumber, 그리고 CA가 실제로 동작하는 dir·policy·default_days를 담은 openssl.cnf입니다. openssl-ca 설명서는 각 카운터가 무엇을 제어하는지 설명합니다. easy-rsa는 같은 데이터를 pki/ 아래에 두고, vars 파일이 인증서 필드를 결정합니다.

키와 인증서는 다시 만들 수 없는 부분입니다. 데이터베이스는 기억에서 재구성할 수 없는 부분입니다. index.txt를 건너뛰어도 새 인증서에 서명할 수 있으며, 바로 그것이 함정입니다: 고객이 인증서가 폐기되었는지 처음 물을 때 그 사실이 빠졌음을 알게 됩니다. CA 지문을 백업 밖에 기록해, 복원을 방금 복원한 파일이 아니라 신뢰하는 값과 비교하게 하십시오.

openssl x509 -in ca.crt -noout -fingerprint -sha256
tar czf ca-state.tar.gz ca.crt ca.key index.txt* serial* crlnumber* openssl.cnf
openssl enc -aes-256-cbc -pbkdf2 -iter 200000 -salt -in ca-state.tar.gz -out ca-state.tar.gz.enc
openssl ca -config openssl.cnf -gencrl -out crl.pem

발급자를 분기시키지 않는 복원 테스트

같은 주체와 같은 키를 가진 두 개의 살아 있는 CA는 원본을 신뢰하는 모든 클라이언트에게 동일하게 보입니다. 같은 번호지만 내용이 다른 두 개의 CRL은 클라이언트가 당신이 폐기한 인증서를 조용히 받아들이는 방식입니다. 복원을 클라이언트로 가는 경로가 없는 호스트나 일회용 VM에서 실행하고, 테스트가 만들어 내는 CRL은 절대 게시하지 마십시오.

아카이브가 열린다는 것만 증명하는 테스트는 발급에 대해 아무것도 증명하지 않습니다. 중요한 순서는 이렇습니다: 복원된 ca.crt의 지문을 기록한 값과 비교하고, serial이 마지막으로 발급한 인증서가 함축하는 값과 일치하는지 확인하고, 일회용 CN용 인증서 하나를 발급해 index.txt에 행이 늘어나는 것을 보고, 그 인증서를 폐기한 뒤 CRL을 다시 생성합니다.

openssl verify -CAfile ca.crt -CRLfile crl.pem -crl_check client.crt
openssl crl -in crl.pem -noout -lastupdate -nextupdate

HSM에서는 같은 테스트를 모듈을 통해 수행합니다. 블롭을 교체 장치에 풀고, 모듈이 보고하는 CA 인증서가 기록한 지문과 일치하는지 확인한 다음에야 서명하게 하십시오. 모듈에 자체 객체 저장소가 있다면 래핑은 키 객체와 그 레이블을 포함해야 합니다, 다른 레이블로 키를 복원하면 그 키를 가리키는 구성이 깨지기 때문입니다.

선택을 결정하는 실패 모드

다섯 가지 실패가 실제 손실의 대부분을 설명합니다. 비밀의 독립 사본 없이 잊힌 아카이브 암호는 아카이브를 벽돌로 만듭니다. 한 디스크의 단일 사본은 그 디스크와 함께 죽고, 체크섬은 복호화가 아직 작동하는지 결코 알려 주지 않습니다. 백업 날짜 이후 폐기된 인증서는 복원 후 다시 유효해 보이므로, 백업 간격은 폐기의 사각지대이기도 합니다. 더 오래된 serial 카운터를 복원하면 serial 번호를 재사용하고 serial로 키가 지정된 캐시와 CRL 조회를 혼란스럽게 합니다. 감싼 블롭을 거부하는 교체 HSM은 하드웨어 교체를 전면 재발급으로 바꿉니다.

모델 A는 처음 네 가지를 나쁘게 다루지만 눈에 띄게 다룹니다. 모델 B는 모듈이나 공급업체 프로세스가 실패할 때까지 잘 다룹니다. 키가 내보내기 가능하고 팀이 작다면 암호화 아카이브가 정직한 선택이며, 두 개의 매체와 문서화된 암호 절차가 뒷받침합니다. 키를 추출할 수 없다면 선택의 여지가 전혀 없고, 작업은 필요해지는 날 이전에 공급업체의 복원 경로를 입증하는 쪽으로 옮겨 갑니다.

모델 선택과 일정 계획

세 가지 조건이 결정을 끝냅니다. 공급업체 프로세스 없이 키를 내보낼 수 있습니까? 복원이 아직 보유하지 않은 하드웨어에 이루어져야 합니까? 지원과 논쟁하는 동안 발급이 얼마나 멈출 수 있습니까? 이 셋에 답하면 모델이 정해지고, 그 뒤의 모든 것은 일정 계획입니다.

모든 서명 의식 후, 그리고 모든 구성 변경 전에 백업하십시오, 구성은 상태의 일부이기 때문입니다. 서로 다른 장소의 서로 다른 매체에 두 개의 사본을 두고, 하나는 오프라인으로 두며, 복호화 비밀은 사본과 다른 신뢰 도메인에 두십시오. 마지막 성공적 복원 날짜를 백업 기록에 적으십시오. 한 번도 복원되지 않은 백업은 가설이지 통제가 아닙니다.

티켓을 닫기 전에 다음 다섯 가지를 확인하십시오:

• ca.crt의 지문이 백업 밖 어딘가에 기록되어 있습니다.
• index.txt, serial, crlnumber, openssl.cnf가 모두 아카이브나 블롭 집합 안에 있습니다.
• 암호 또는 감싼 키의 보관이 문서화되어 있고 아카이브 소유자가 아닌 누군가가 보유합니다.
• 격리된 호스트에서 발급 한 번과 폐기 한 번으로 복원을 시험했습니다.
• 백업 간격이 함축하는 폐기 공백을 서면으로 수용했거나 단축했습니다.