AWS Client VPN: qual CA deve emitir os certificados de cliente?

A pergunta sobre certificados no AWS Client VPN é feita como pergunta de produto, e na verdade é uma pergunta de operações. Qualquer uma das três configurações habituais manterá um túnel a funcionar: uma CA organizacional existente, um emissor próprio dedicado ou o AWS Private CA. Diferem em quem aprova um dispositivo, quem guarda a chave de assinatura e quem responde quando um portátil desaparece a uma hora inconveniente. Escolha a opção cujo responsável consegue nomear.

A AWS não exige Private CA para autenticação por certificado. Colocar um certificado de servidor no ACM é um passo de implementação, não um processo de inscrição.

As três condições que o decidem

Três condições separam claramente as opções: se já existe um processo aprovado de inscrição de dispositivos, se consegue operar uma chave de assinatura com cópias de segurança e um responsável nomeado, e como uma revogação chega ao endpoint. Cada uma está perto de um sim ou de um não, e o primeiro não costuma decidir a arquitetura.

Trate-as por ordem. Saltar diretamente para uma comparação de custos é como as equipas acabam com uma CA gerida e ninguém que saiba quem emite o próximo certificado de portátil.

Primeira condição: a inscrição já existe?

Se a sua organização já opera uma CA com um caminho aprovado de inscrição de dispositivos, emitir a partir dela os certificados de cliente do Client VPN é a rota mais curta. As aprovações, o processo e os registos de ativos já estão lá. Um emissor subordinado dedicado dentro dessa hierarquia costuma ser melhor do que a CA emissora de uso geral, porque dá à VPN a sua própria fronteira de confiança e a sua própria lista de revogação. Mantenha essa lista separada do resto da hierarquia para que um incidente de VPN não obrigue a uma alteração em todo o PKI.

Se tal processo não existir, a verdadeira questão é se quer construir um. Uma CA é fácil de começar e cara de possuir mal.

Segunda condição: consegue operar uma chave de assinatura?

Um emissor próprio funciona com o modelo de importação documentado, e o EasyRSA ou uma pequena ferramenta interna podem produzir o material. Executar o comando não é a parte difícil. A parte difícil são as cópias de segurança offline da chave de assinatura, um caminho de recuperação que alguém tenha testado a sério, um responsável que não esteja de férias e uma regra de que a chave nunca acaba num pacote de cliente nem numa exportação de configuração. Escreva isso como procedimento antes de emitir o primeiro certificado, não depois do primeiro incidente.

O AWS Private CA transfere essa custódia para um serviço gerido. Não transfere a política de inscrição, o passo de aprovação nem a entrega do certificado ao dispositivo.

Terceira condição: como chega a revogação?

O Client VPN consome uma lista de revogação de certificados de cliente que importa para o endpoint, como descrito no guia do ciclo de vida dos certificados. Publicar uma CRL noutro local do seu PKI não a empurra para o serviço. A importação é uma operação separada e agendada, e uma lista expirada para as ligações em vez de se degradar em silêncio. Coloque a renovação no mesmo calendário dos próprios certificados.

Isso faz da renovação um item de monitorização com responsável, não uma tarefa que termina no lançamento. Revogue um certificado de teste de ponta a ponta antes de precisar realmente do mecanismo.

O que nenhuma das opções elimina

Todas as opções continuam a precisar de um certificado de cliente e uma chave distintos por cada dispositivo gerido de forma independente. Um tutorial que distribui uma única identidade por todos é um atalho de tutorial, e também torna impossível a revogação seletiva.

Os certificados de servidor importados no ACM não têm renovação gerida, pelo que o responsável tem de obter o substituto, voltar a importá-lo e depois confirmar que o endpoint o adotou. Renovar o certificado de servidor não renova as credenciais de cliente que já estão nos portáteis. São ciclos de vida separados com calendários separados.

Verifique os tipos de chave e as extensões que o serviço aceita antes de emitir seja o que for. O facto de uma CA suportar um algoritmo não significa que o endpoint o aceite.

Antes do lançamento, execute uma renovação e uma remoção de cliente pelo fluxo de trabalho que escolheu, e anote que credencial mudou, que definição do endpoint mudou e o que aconteceu à sessão ativa. Se esse exercício terminar sem um responsável claro, a escolha do emissor não está concluída.