Acesso do parceiro ao HSM por VPN: defina as operações de chave

Alguém no parceiro tem de assinar um documento com uma chave designada, e o pedido chega formulado como uma questão de rede: precisam de chegar ao HSM. Trate essa frase como sintoma de um contrato de serviço indefinido e não como um problema de encaminhamento, porque um túnel que chega ao equipamento não concede nada por si só. Atrás do pedido estão três portões: alcançabilidade, identidade do HSM e política de chaves, e cada um é administrado num local diferente por uma equipa diferente. Escreva-os um a um, ou acabará por conceder uma rota porque a conversa sobre o certificado era mais difícil.

Tenha presente o caso concreto: o parceiro submete um documento aprovado para assinatura com uma chave nomeada, e nada mais. Tudo o que se segue decorre dessa única frase.

Alcançabilidade, identidade e política de chaves são três portões

O concentrador VPN decide quem pode abrir um túnel e que endereços pode tocar. O HSM decide por si mesmo que registo de utilizador apresentado pode iniciar sessão. A política de chaves decide depois o que esse registo de utilizador pode fazer com uma chave específica. Passar o primeiro portão deixa os outros dois exatamente como estavam, e é por isso que um handshake bem-sucedido prova tão pouco e que um parceiro pode chegar ao equipamento e falhar em todas as operações.

Atribua um responsável a cada portão antes de escrever os requisitos. Quando ninguém é responsável pelo segundo, o resultado habitual é ser entregue uma identidade ampla de administrador do HSM, porque é a única credencial que funciona.

Primeiro portão: o caminho de rede dado ao parceiro

Nomeie o cliente ou serviço aprovado, o destino de que necessita, e o protocolo e a porta em que esse serviço escuta. Depois limite o acesso do lado da VPN a esse par em ambos os sentidos, incluindo o caminho de retorno, para que a política seja uma frase que possa ler de volta ao parceiro. A administração do gateway, as interfaces de gestão do HSM e os sistemas internos não relacionados devem ficar fora do acesso normal do parceiro, não apenas fora da rota predefinida.

Um segmento dedicado torna essas travessias visíveis, mas o nome de um segmento não impõe nada. O tráfego tem de passar pelo controlo que pensa que ele atravessa. Admitir uma ligação do parceiro também não é afirmar que todas as máquinas do parceiro são de confiança.

Segundo portão: o que realmente se autentica perante o HSM

Uma identidade VPN e uma identidade HSM são objetos separados, salvo se uma integração suportada as unir deliberadamente. Com um cliente PKCS#11, a aplicação faz um início de sessão num slot com uma credencial guardada algures no host do parceiro, e é esse início de sessão que o HSM avalia.

O AWS CloudHSM é uma referência útil porque a sua documentação mantém os dois separados: os utilizadores do HSM são distintos dos utilizadores IAM, e o tipo de utilizador determina o que a conta pode fazer. Um responsável de criptografia gere utilizadores e chaves mas não é a identidade que executa operações criptográficas, enquanto um utilizador de criptografia pode usar chaves sem conseguir geri-las. Essa separação é a forma que pretende mesmo no equipamento de outro fornecedor, onde os nomes das funções serão diferentes.

Seja qual for a identidade que emita, tem de poder ser removida e atribuída com a granularidade de que precisará mais tarde. Uma única credencial operacional partilhada por vários parceiros dificulta a contenção e a responsabilização exatamente no incidente em que ambas mais importam.

Terceiro portão: que chave e que operação

Assinatura, decifração, geração de chaves, empacotamento de chaves e administração de utilizadores são permissões separadas e têm de ser listadas em separado. Em termos de PKCS#11, atributos como CKA_SENSITIVE e CKA_EXTRACTABLE descrevem se o material da chave pode sair do módulo numa forma utilizável, e são definidos por chave e não por equipamento. Leia a política real na chave em vez de inferir a não exportabilidade da palavra hardware ou da presença de um túnel.

Depois encontre a aprovação de negócio. Se só documentos aprovados podem ser assinados, que componente estabelece essa aprovação antes de o pedido chegar ao HSM? Uma interface criptográfica que aceita um pedido autorizado não tem ideia de se o documento foi revisto, pelo que essa verificação pertence ao serviço à sua frente.

Um cliente permitido que seja comprometido também pode abusar das operações que a sua credencial autoriza legitimamente, sem nunca extrair uma chave privada. Proteger o material de chave armazenado e controlar o uso das chaves são, portanto, duas condições de aceitação, e não uma.

As recusas fazem parte do teste de aceitação

Aceite o pedido de assinatura permitido e aceite também as recusas: uma identidade não autorizada, uma chave não relacionada e uma operação de gestão a partir do caminho do parceiro. Registe o autor da chamada, a operação, o identificador da chave, a hora e o resultado, e mantenha o material de chave privada, as credenciais e o conteúdo dos documentos fora dos registos de diagnóstico gerais.

Atribua um responsável pela saída do parceiro, por uma suspeita de compromisso do lado do parceiro e pelas alterações de política e recuperação. Alterar uma rota não restaura a confiança num host que pode já estar comprometido, pelo que a revogação tem de chegar também à identidade do HSM.

Um handshake VPN concluído pertence a esse registo. Não pode substituir um único resultado específico do HSM.