Sostituire una chiave VPN compromessa: cosa deve fare il server

Un portatile con una chiave client è andato perso, e la prima azione è di solito eliminare la copia locale. Questo non cambia nulla sul server, che conserva ancora un'autorizzazione che accetterà quella chiave finché qualcuno non la rimuove. La sostituzione è due operazioni, e solo la seconda riguarda la vecchia credenziale.

La copia locale non è l'autorità

Una credenziale VPN viene accettata perché la configurazione lato server lo dice. Per i certificati questo significa che il certificato si concatena a un emittente fidato e non compare in un elenco di revoca consultato dal gateway. Per WireGuard significa che la chiave pubblica del peer compare nella configurazione dell'interfaccia. Eliminare un file su un client rimuove una copia di un segreto e lascia intatta la regola di accettazione.

Ecco perché una chiave rubata continua a funzionare dopo la pulizia ovvia, e perché l'incidente sembra irrisolto anche quando la nuova configurazione è installata.

Parti dalla regola del server, poi lavora verso l'esterno fino al client.

Certificati: il server detiene la decisione

Emetti la sostituzione tramite il processo dell'emittente stesso, così che la nuova identità venga registrata, poi revoca la vecchia con una revoca firmata. Il gateway deve essere configurato per consultare quella fonte di revoca e deve ricaricarla, altrimenti il file resta sul disco mentre il tunnel continua ad accettare il vecchio seriale. Anche le sessioni attive possono sopravvivere fino alla rinegoziazione, quindi pianifica una riconnessione.

Verifica che la sostituzione funzioni per l'applicazione prevista, poi verifica tramite una procedura approvata che il certificato ritirato non stabilisca più l'accesso.

Sono due test diversi ed entrambi sono necessari. RFC 5280 definisce la semantica di certificato e revoca su cui il gateway si basa.

WireGuard: la chiave del peer è l'identità

WireGuard non ha uno strato di certificati: la chiave pubblica del peer è l'identità, e la voce allowed-ips del server è l'autorizzazione. Rimuovere il vecchio peer dalla configurazione dell'interfaccia è la revoca, e si applica immediatamente ai nuovi handshake.

Le sessioni esistenti terminano quando il successivo handshake fallisce, cosa che di solito avviene entro un paio di minuti anziché immediatamente.

Distribuisci la nuova configurazione attraverso un canale a cui affideresti una password, perché la chiave privata è la credenziale. Mantieni una chiave per dispositivo, così un singolo dispositivo perso non costringe ogni dispositivo a cambiare.

Cos'altro c'era in quel pacchetto

Un pacchetto client spesso porta più della chiave privata: una chiave TLS statica, un nome utente e una password, un segreto precondiviso o un token di provisioning. Limita l'incidente a ciò che è stato realmente esposto e ruota anche quegli elementi. Ruotare il certificato lasciando al suo posto una chiave statica condivisa chiude una porta e ne lascia aperta un'altra.

Se il pacchetto è stato condiviso tra dispositivi, ogni dispositivo che lo porta eredita l'esposizione.

Annota ciò che è stato ruotato, perché il prossimo audit lo chiederà.

Dimostra il rifiuto, poi registra la sostituzione

La sostituzione è completa quando valgono due fatti: la nuova identità funziona per il servizio previsto e la vecchia viene rifiutata. Verifica il secondo con la credenziale ritirata da un ambiente di test, o con un tentativo controllato che l'organizzazione approva, e leggi i log del gateway per confermare che il rifiuto è venuto dalla policy e non da un errore di battitura. Poi registra il vecchio identificatore, quello nuovo e l'ora della modifica, perché quei tre valori sono ciò che serve a un revisore per ricostruirla. Nient'altro nel ticket spiegherà il divario.

Tieni le chiavi private fuori da ticket e chat, e rimuovi le esportazioni obsolete da archiviazione e backup secondo la policy.

Una sostituzione senza test di rifiuto è un'assunzione, non una correzione.