Backup de uma CA privada: arquivo criptografado versus backup de chave HSM

A pergunta que decide a maior parte disto não é como você criptografa o arquivo. É se sua chave privada da CA pode sair do seu contêiner. Se a chave é um arquivo, você pode copiar todo o diretório da CA para um único blob criptografado e terminar em minutos. Se ela mora em um HSM ou em um token que marca a chave como não extraível, essa cópia não existe, e seu plano vira um plano sobre o procedimento de envolvimento e restauração do fornecedor. Os dois modelos funcionam, falham de formas diferentes, e a falha que você consegue sobreviver é a que vale a pena projetar.

Onde os dois modelos de backup se separam

O modelo A é cópia de diretório. Uma CA no estilo OpenSSL é um diretório de trabalho, não um único certificado: ca.key ou cakey.pem, ca.crt, o banco de dados de emissão, os contadores serial e crlnumber, e openssl.cnf. Sele esse diretório com uma cifra simétrica, mova o resultado para um segundo meio, e restaurar significa descompactar, verificar, assinar. Tudo o que o emissor precisa viaja junto, incluindo semanas de histórico de revogação que ninguém lembra ter escrito.

O modelo B é contenção da chave. A chave é gerada dentro de um módulo PKCS#11 e marcada como não extraível; o módulo pode envolvê-la para backup, mas nenhum processo lê os bytes brutos. Seu backup é então dois artefatos que devem ser restaurados na ordem correta: um blob de chave envolvida que só aquela família de módulos consegue abrir, mais uma cópia simples do banco de dados, da configuração e dos certificados.

A comparação nunca é sobre qual modelo é mais forte no abstrato. É sobre qual a sua equipe consegue restaurar às 2 da manhã com as pessoas que estão realmente acordadas. Um arquivo que ninguém consegue descriptografar e um blob de HSM que ninguém testou são igualmente inúteis. A diferença é que a falha do arquivo aparece num gerenciador de senhas, e a falha do HSM se esconde num contrato de suporte.

O que todo backup de CA deve conter

Os dois modelos precisam do mesmo conjunto de registros. Numa CA OpenSSL esses arquivos são index.txt com uma linha por certificado emitido cobrindo status, validade, serial e sujeito, depois index.txt.attr, serial que guarda o próximo serial a emitir, crlnumber que guarda o próximo número de CRL, e openssl.cnf com o dir, a policy e os default_days com que sua CA realmente roda. O manual do openssl-ca explica o que cada um desses contadores controla. O easy-rsa guarda os mesmos dados sob pki/, com um arquivo vars decidindo os campos do certificado.

A chave e o certificado são as partes que você não consegue reconstruir. O banco de dados é a parte que você não consegue reconstruir de memória. Pular o index.txt ainda deixa você assinar novos certificados, e essa é exatamente a armadilha: você descobre que ele falta na primeira vez que um cliente pergunta se um certificado foi revogado. Registre a impressão digital da CA fora do backup, para que uma restauração seja comparada com um valor em que você confia e não com o arquivo que você acabou de restaurar.

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

Testes de restauração que não bifurcam o emissor

Duas CAs ativas com o mesmo sujeito e a mesma chave parecem idênticas a todo cliente que confia na original. Duas CRLs com o mesmo número mas conteúdo diferente é como os clientes aceitam em silêncio um certificado que você revogou. Execute a restauração num host sem rota para os seus clientes, ou numa VM descartável, e nunca publique a CRL que o teste produz.

Um teste que só prova que o arquivo abre não prova nada sobre a emissão. A sequência que conta: compare a impressão digital do ca.crt restaurado com o valor que você registrou, confirme que o serial corresponde ao que o seu último certificado emitido implica, emita um certificado para um CN descartável e observe o index.txt ganhar uma linha, depois revogue esse certificado e regenere a CRL.

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

Com um HSM o mesmo teste passa pelo módulo. Desenvolva o blob no dispositivo de substituição, confirme que o certificado de CA que o módulo reporta corresponde à sua impressão digital registrada, e só então deixe-o assinar. Se o módulo tiver seu próprio armazenamento de objetos, o envolvimento deve cobrir o objeto de chave e o rótulo dele, porque restaurar a chave sob outro rótulo quebra a configuração que aponta para ela.

Modos de falha que decidem a escolha

Cinco falhas explicam a maioria das perdas reais. Uma frase secreta de arquivo esquecida sem cópia independente do segredo transforma o arquivo num tijolo. Uma única cópia num disco morre com esse disco, e um checksum nunca diz se a descriptografia ainda funciona. Certificados revogados depois da data do backup parecem válidos de novo após uma restauração, então o intervalo do seu backup é também o seu ponto cego de revogação. Restaurar um contador de serial antigo reutiliza números de série e confunde caches e buscas de CRL indexadas por serial. Um HSM de substituição que recusa o blob envolvido transforma uma troca de hardware numa reemissão completa.

O modelo A lida mal com os quatro primeiros, mas de forma visível. O modelo B lida bem com eles até o módulo ou o processo do fornecedor falhar. Se suas chaves são exportáveis e a equipe é pequena, o arquivo criptografado é a escolha honesta, apoiada por dois meios e um procedimento escrito de frase secreta. Se a chave não é extraível não há escolha alguma, e o trabalho passa a provar o caminho de restauração do fornecedor antes do dia em que você precisar dele.

Escolher o modelo e programá-lo

Três condições resolvem a decisão. A chave pode ser exportada sem um processo do fornecedor? Uma restauração precisa cair em hardware que você ainda não possui? Quanto tempo a emissão pode parar enquanto você discute com o suporte? Responda essas três e o modelo está decidido; todo o resto é programação.

Faça um backup depois de cada cerimônia de assinatura e antes de qualquer mudança de configuração, porque a configuração faz parte do estado. Mantenha duas cópias em meios diferentes em lugares diferentes, uma delas offline, e guarde o segredo de descriptografia num domínio de confiança diferente do das cópias. Escreva a data da última restauração bem-sucedida no registro do backup. Um backup que nunca foi restaurado é uma hipótese, não um controle.

Antes de fechar o ticket, confirme estes cinco pontos:

• A impressão digital do ca.crt está registrada em algum lugar fora do backup.
• index.txt, serial, crlnumber e openssl.cnf estão todos dentro do arquivo ou do conjunto de blobs.
• A custódia da frase secreta ou da chave envolvida está documentada e pertence a alguém diferente do dono do arquivo.
• Uma restauração foi testada num host isolado com uma emissão e uma revogação.
• A lacuna de revogação implicada pelo intervalo do seu backup é aceita por escrito ou encurtada.