Substituir una clau VPN filtrada: què ha de fer el servidor

Un portàtil que portava una clau de client es va perdre, i la primera acció sol ser esborrar la còpia local. Això no canvia res al servidor, que encara té una autorització que acceptarà aquesta clau fins que algú la retiri. La substitució són dues operacions, i només la segona afecta la credencial antiga.

La còpia local no és l’autoritat

Una credencial VPN s’accepta perquè la configuració del servidor ho diu. En els certificats, això vol dir que el certificat encadena cap a un emissor de confiança i no apareix en una llista de revocació que la passarel·la consulta. En WireGuard, vol dir que la clau pública de l’igual apareix a la configuració de la interfície. Esborrar un fitxer en un client elimina una còpia d’un secret i deixa la regla d’acceptació intacta.

És per això que una clau robada continua funcionant després de la neteja òbvia, i per això l’incident sembla no resolt fins i tot quan la configuració nova ja és instal·lada.

Comenceu per la regla del servidor, i després aneu cap al client.

Certificats: el servidor té la decisió

Emeteu la substitució pel procés propi de l’emissor perquè la identitat nova quedi registrada, i després retireu l’antiga amb una revocació signada. La passarel·la ha d’estar configurada per consultar aquesta font de revocació i ha de recarregar-la, o el fitxer queda al disc mentre el túnel continua acceptant el número de sèrie antic. Les sessions actives també poden sobreviure fins a la renegociació, així que planifiqueu una reconnexió.

Confirmeu que la substitució funciona per a l’aplicació prevista, i després confirmeu per un procés aprovat que el certificat retirat ja no estableix accés.

Són dues proves diferents i calen totes dues. RFC 5280 defineix la semàntica de certificat i revocació en què es basa la passarel·la.

WireGuard: la clau de l’igual és la identitat

WireGuard no té capa de certificats: la clau pública de l’igual és la identitat, i l’entrada allowed-ips del servidor és l’autorització. Retirar l’igual antic de la configuració de la interfície és la revocació, i s’aplica de seguida a les apretades de mans noves.

Les sessions existents s’acaben quan falla la propera apretada de mans, cosa que normalment passa en un parell de minuts i no a l’instant.

Distribuïu la configuració nova per un canal en què confiaríeu una contrasenya, perquè la clau privada és la credencial. Mantingueu una clau per dispositiu, perquè un sol dispositiu perdut no obligui tots els dispositius a canviar.

Què més hi havia en aquell paquet

Un paquet de client sovint porta més que la clau privada: una clau TLS estàtica, un nom d’usuari i una contrasenya, un secret compartit prèviament o un testimoni d’aprovisionament. Limiteu l’incident a allò que realment es va exposar i rotau també aquests elements. Rotar el certificat mentre una clau estàtica compartida queda al seu lloc tanca una porta i en deixa una altra oberta.

Si el paquet es compartia entre dispositius, cada dispositiu que el porta n’hereta l’exposició.

Anoteu què s’ha rotat, perquè la propera auditoria ho preguntarà.

Demostreu el rebuig i després registreu la substitució

La substitució està completa quan es compleixen dos fets: la identitat nova funciona per al servei previst i la vella és rebutjada. Verifiqueu el segon amb la credencial retirada des d’un entorn de proves, o amb un intent controlat que l’organització aprovi, i llegiu els registres de la passarel·la per confirmar que el rebuig ve de la política i no d’una errata. Després registreu l’identificador antic, el nou i l’hora del canvi, perquè aquests tres valors són el que un auditor necessita per reconstruir-ho. Res més al tiquet no explicarà el buit.

Mantingueu les claus privades fora dels tiquets i del xat, i retireu les exportacions obsoletes de l’emmagatzematge i de les còpies de seguretat segons la política.

Una substitució sense prova de rebuig és una suposició i no una correcció.