Porque é que as chaves do servidor e as credenciais de utilizador precisam de proprietários separados

A chave que prova que o seu gateway é ele mesmo e a credencial que diz que uma pessoa pode entrar são ambos segredos, e é aí que a semelhança termina. Um identifica um serviço perante cada cliente; o outro identifica um utilizador perante esse serviço. Misturá-los poupa um passo na configuração e custa uma tarde durante um incidente, porque a recuperação de cada um não é a mesma operação. A separação é aborrecida de preparar e memorável de omitir.

Dois segredos, dois proprietários diferentes

O gateway guarda uma chave privada ou um certificado cuja única tarefa é provar a sua identidade durante o aperto de mão. Os clientes precisam do material público correspondente para o verificar, e nunca precisam da metade privada. É essa assimetria que torna possível a autenticação do servidor sem dar a cada utilizador a capacidade de se fazer passar pelo servidor.

O material do utilizador vai na direção oposta. Uma chave privada de cliente, um certificado de cliente ou uma palavra-passe demonstram que a esta pessoa ou dispositivo específico foi concedido acesso. Espera-se que seja distribuído, copiado entre dispositivos e, por fim, revogado.

O WireGuard torna a separação óbvia porque cada participante tem um par de chaves: a chave privada do servidor fica no servidor, e um ficheiro de configuração que dá a um utilizador contém a sua própria chave privada mais a chave pública do servidor. Um perfil que contém a chave privada do servidor não é um atalho, é um comprometimento à espera de uma partilha de ficheiros.

Três perguntas que decidem a separação

Pergunte quem tem de conseguir ler o segredo, o que uma exposição permitiria a um atacante fazer e se a correção é uma revogação ou uma reconstrução do serviço.

Se um utilizador o pode ler e ele prova a identidade do gateway, a resposta à segunda pergunta é que o atacante pode fazer-se passar pelo seu servidor perante cada cliente — o pior resultado, porque os clientes são feitos para confiar nessa identidade. Se provar apenas um utilizador, a exposição concede a esse utilizador acesso a um par, e a revogação é uma operação de rotina. Se for uma chave de autoridade de certificação, a exposição é pior do que ambas, uma vez que o atacante pode criar identidades em que cada extremidade confia.

Essas três respostas produzem a regra de armazenamento: a chave de CA vive offline ou num cofre, a chave do gateway vive no gateway, e as chaves dos utilizadores vivem com os utilizadores. Qualquer disposição que ponha as três num único diretório por conveniência transformou uma decisão num acidente.

O que um cliente precisa realmente

Um cliente precisa do certificado público ou da chave pública do par, do material de CA ou da impressão digital em que deve confiar, da sua própria chave privada e dos detalhes do extremo. Essa lista não contém nada que pertença à identidade privada do gateway.

A documentação é onde isto fica exposto. Um guia que diz copie o diretório do servidor e apague o que não precisa já ensinou o modelo errado, porque o ficheiro que resta depois do passo de eliminação raramente é verificado por alguém.

Revogue um utilizador sem tocar no gateway

Como as identidades dos utilizadores são emitidas separadamente, podem ser retiradas separadamente. Uma implementação baseada em certificados revoga o certificado de cliente e publica uma lista de revogação atualizada; uma implementação de WireGuard remove a entrada do par da configuração do servidor. Nenhuma dessas operações altera a chave própria do gateway.

Guarde o registo de emissão, ou não saberá que identidade retirar. Uma folha de cálculo chega, desde que nomeie a pessoa, o dispositivo, o número de série ou a chave pública e a data, e desde que alguém a mantenha depois de a pessoa que a construiu sair.

Os comandos abaixo inspecionam um certificado de cliente e depois revogam-no através de uma autoridade ao estilo OpenSSL, que é o fluxo que o easy-rsa envolve:

openssl x509 -in client.crt -noout -subject -serial
openssl ca -config openssl.cnf -revoke client.crt
openssl ca -config openssl.cnf -gencrl -out crl.pem

Publique a nova lista onde os clientes a verificam, ou a revogação é uma nota num ficheiro que não muda nada. Se o seu gateway aceita certificados de cliente sem consultar uma lista de revogação, diga-o explicitamente em vez de sugerir que a revogação funciona.

Mantenha as cópias de segurança tão separadas como os segredos

Um arquivo de reconstrução contém legitimamente a chave do gateway e o material de CA, porque sem eles uma restauração não pode reproduzir o serviço. Um pacote de configuração de cliente não deve, e os dois não devem ser guardados juntos. Etiquete cada arquivo por quem o pode guardar, não pela data em que foi feito. É essa etiqueta que um administrador cansado lê às duas da manhã.

Essa distinção também determina quem pode recuperar cada um. Administrar o gateway, emitir identidades de utilizador e ler cópias de segurança são três poderes diferentes, e quem precisa de um não precisa automaticamente dos outros. Escreva essas permissões e depois confirme-as contra o que o seu armazenamento permite realmente, porque a herança de diretórios concede em silêncio mais do que a política pretende.