Sustituir una clave VPN filtrada: qué debe hacer el servidor

Se perdió un portátil que llevaba una clave de cliente, y la primera acción suele ser borrar la copia local. Eso no cambia nada en el servidor, que todavía guarda una autorización que aceptará esa clave hasta que alguien la retire. La sustitución son dos operaciones, y solo la segunda afecta a la credencial antigua.

La copia local no es la autoridad

Una credencial VPN se acepta porque la configuración del servidor lo dice. En los certificados, eso significa que el certificado encadena hacia un emisor de confianza y no aparece en una lista de revocación que la puerta de enlace consulta. En WireGuard, significa que la clave pública del par aparece en la configuración de la interfaz. Borrar un archivo en un cliente elimina una copia de un secreto y deja la regla de aceptación intacta.

Por eso una clave robada sigue funcionando después de la limpieza obvia, y por eso el incidente parece sin resolver incluso cuando la configuración nueva ya está instalada.

Empiece por la regla del servidor y luego avance hacia el cliente.

Certificados: el servidor tiene la decisión

Emita la sustitución mediante el proceso propio del emisor para que la identidad nueva quede registrada y después retire la antigua con una revocación firmada. La puerta de enlace debe estar configurada para consultar esa fuente de revocación y debe recargarla, o el archivo se queda en el disco mientras el túnel sigue aceptando el número de serie antiguo. Las sesiones activas también pueden sobrevivir hasta la renegociación, así que planifique una reconexión.

Confirme que la sustitución funciona para la aplicación prevista y después confirme, mediante un proceso aprobado, que el certificado retirado ya no establece acceso.

Son dos pruebas distintas y hacen falta las dos. RFC 5280 define la semántica de certificado y revocación en la que se apoya la puerta de enlace.

WireGuard: la clave del par es la identidad

WireGuard no tiene capa de certificados: la clave pública del par es la identidad, y la entrada allowed-ips del servidor es la autorización. Retirar el par antiguo de la configuración de la interfaz es la revocación, y se aplica de inmediato a los handshakes nuevos.

Las sesiones existentes terminan cuando falla el siguiente handshake, lo que suele ocurrir en un par de minutos y no al instante.

Distribuya la configuración nueva por un canal en el que confiaría una contraseña, porque la clave privada es la credencial. Mantenga una clave por dispositivo, para que un solo dispositivo perdido no obligue a cambiar todos los dispositivos.

Qué más había en ese paquete

Un paquete de cliente a menudo lleva más que la clave privada: una clave TLS estática, un nombre de usuario y una contraseña, un secreto compartido de antemano o un token de aprovisionamiento. Limite el incidente a lo que realmente se expuso y rote también esos elementos. Rotar el certificado mientras una clave estática compartida se queda en su sitio cierra una puerta y deja otra abierta.

Si el paquete se compartía entre dispositivos, cada dispositivo que lo lleva hereda la exposición.

Anote qué se rotó, porque la próxima auditoría lo preguntará.

Demuestre el rechazo y luego registre la sustitución

La sustitución está completa cuando se cumplen dos hechos: la identidad nueva funciona para el servicio previsto y la antigua es rechazada. Verifique el segundo con la credencial retirada desde un entorno de pruebas, o con un intento controlado que la organización apruebe, y lea los registros de la puerta de enlace para confirmar que el rechazo vino de la política y no de una errata. Después registre el identificador antiguo, el nuevo y la hora del cambio, porque esos tres valores son lo que un auditor necesita para reconstruirlo. Nada más en el tique explicará el hueco.

Mantenga las claves privadas fuera de los tiques y del chat, y retire las exportaciones obsoletas del almacenamiento y de las copias de seguridad según la política.

Una sustitución sin prueba de rechazo es una suposición y no una corrección.