Substituir uma chave VPN comprometida: o que o servidor deve fazer

Um portátil que transportava uma chave de cliente perdeu-se, e a primeira ação costuma ser apagar a cópia local. Isso não muda nada no servidor, que ainda tem uma autorização que aceitará essa chave até alguém a remover. A substituição são duas operações, e só a segunda diz respeito à credencial antiga.

A cópia local não é a autoridade

Uma credencial VPN é aceite porque a configuração do lado do servidor o diz. Para certificados, isso significa que o certificado se encadeia num emissor de confiança e não aparece numa lista de revogação consultada pelo gateway. Para o WireGuard, significa que a chave pública do par aparece na configuração da interface. Apagar um ficheiro num cliente remove uma cópia de um segredo e deixa a regra de aceitação intacta.

É por isso que uma chave roubada continua a funcionar depois da limpeza óbvia, e por isso o incidente parece por resolver mesmo quando a nova configuração está instalada.

Comece pela regra do servidor e depois avance para fora, até ao cliente.

Certificados: o servidor detém a decisão

Emita a substituição através do processo do próprio emissor, para que a nova identidade fique registada, e depois retire a antiga com uma revogação assinada. O gateway tem de estar configurado para consultar essa fonte de revogação e tem de a recarregar, ou o ficheiro fica no disco enquanto o túnel continua a aceitar o número de série antigo. As sessões ativas também podem sobreviver até à renegociação, por isso planeie uma reconexão.

Confirme que a substituição funciona para a aplicação pretendida e depois confirme, através de um processo aprovado, que o certificado retirado já não estabelece acesso.

São dois testes diferentes e ambos são necessários. RFC 5280 define a semântica de certificados e revogação em que o gateway se baseia.

WireGuard: a chave do par é a identidade

O WireGuard não tem camada de certificados: a chave pública do par é a identidade, e a entrada allowed-ips do servidor é a autorização. Remover o par antigo da configuração da interface é a revogação, e aplica-se imediatamente aos novos handshakes.

As sessões existentes terminam quando o handshake seguinte falha, o que costuma acontecer dentro de alguns minutos e não de imediato.

Distribua a nova configuração por um canal em que confiaria uma palavra-passe, porque a chave privada é a credencial. Mantenha uma chave por dispositivo, para que um único dispositivo perdido não obrigue todos os dispositivos a mudar.

O que mais estava nesse pacote

Um pacote de cliente transporta frequentemente mais do que a chave privada: uma chave TLS estática, um nome de utilizador e palavra-passe, um segredo pré-partilhado ou um token de aprovisionamento. Limite o incidente ao que foi realmente exposto e rode também esses elementos. Rodar o certificado deixando uma chave estática partilhada no lugar fecha uma porta e deixa outra aberta.

Se o pacote foi partilhado entre dispositivos, todos os que o transportem herdam a exposição.

Anote o que foi rodado, porque a próxima auditoria vai perguntar.

Prove a recusa e depois registe a substituição

A substituição está completa quando se verificam dois factos: a nova identidade funciona para o serviço pretendido e a antiga é recusada. Verifique o segundo com a credencial retirada a partir de um ambiente de testes, ou com uma tentativa controlada que a organização aprove, e leia os registos do gateway para confirmar que a recusa veio da política e não de um erro de escrita. Depois registe o identificador antigo, o novo e a hora da alteração, porque são esses três valores que um auditor precisa para a reconstruir. Nada mais no ticket explicará a lacuna.

Mantenha as chaves privadas fora de tickets e conversas, e remova as exportações obsoletas do armazenamento e das cópias de segurança segundo a política.

Uma substituição sem teste de recusa é uma suposição, não uma correção.