Identità VPN individuali per un piccolo team, senza directory

Sei persone condividono un accesso VPN, una se ne va, e l’unico modo per rimuovere il suo accesso è cambiare il segreto che usano tutti gli altri. Questo è il problema reale, e non serve Active Directory per risolverlo. Un piccolo ufficio può tenere identità separate nell’archivio locale che il suo gateway supporta e trattare comunque le uscite come routine. Il lavoro sta nello scegliere l’archivio e nello scrivere i passaggi di rimozione prima di averne bisogno.

Partite dalla credenziale che ciascuno possiede

Elencate con cosa si collega ciascuno prima di scegliere un backend. Un portatile, un telefono, magari un desktop di casa, e ognuno di questi è una credenziale separata o un certificato di dispositivo separato. Se non riuscite a nominare la credenziale che una persona possiede, non potrete rimuoverla in seguito.

Due persone che condividono un profilo è il caso che rende più difficile ogni passaggio successivo. Risolvete quello per primo, perché nessuna directory risolve un segreto condiviso.

Scegliete l’archivio che il gateway supporta davvero

Scegliete l’archivio delle identità che il gateway già supporta, non quello che vorreste gestire. Un gateway con un database locale degli utenti può tenere account individuali con criteri per utente. Una distribuzione IKEv2 può associare un’identità EAP a un segreto specifico, purché il metodo del client e il verificatore coincidano. Le configurazioni basate su certificati possono emettere un certificato per dispositivo da un’autorità comune, il che mantiene condivisa l’ancora di fiducia mentre le credenziali restano separate.

La posizione dell’archivio conta meno delle sue operazioni: registrazione, backup, rinnovo e revoca. Se una di queste non ha risposta, la scelta non è finita.

Se il gateway offre sia account locali sia certificati, preferite quello che il vostro team può gestire alle due di notte senza il fornitore al telefono. Quella preferenza riguarda i tempi di ripristino, non quale opzione sia tecnicamente più solida.

Separate la persona dai dispositivi

Decidete che cosa rappresenta una credenziale: una persona, un dispositivo o entrambi. Un portatile e un telefono di un solo dipendente sono due dispositivi e una persona, e perdere il telefono non dovrebbe necessariamente disattivare il portatile. Scrivete quel modello, perché determina che cosa significa rimuovere.

Registrate il proprietario, il dispositivo, la data di emissione e il percorso di revoca per ogni credenziale. Tenete quel registro in un posto dove l’ufficio possa leggerlo senza la persona che l’ha impostato. Una tabella con quelle quattro colonne basta per sei persone e continua a scalare fino a sessanta.

Rendete la rimozione un’operazione ordinaria

Scrivete la procedura di uscita prima della prima uscita. Disattivate l’identità, terminate ogni sessione attiva e confermate che il tunnel cade davvero invece di aspettare un timer di riautenticazione. Poi verificate che la vecchia credenziale fallisca da una macchina fuori dalla rete dell’ufficio. L’intera sequenza dovrebbe richiedere minuti e non esigere una nuova emissione per nessun altro.

sudo swanctl --terminate --ike alice-laptop

Mantenete un percorso di recupero da amministratore che non dipenda dall’account disattivato e riconciliate gli account locali che in seguito passeranno a una directory. L’obiettivo è semplice: rimuovere una persona è un compito di routine, non un progetto che tocca il profilo di tutti gli altri. L’autenticazione locale di Access Server è un esempio documentato di un archivio che si adatta a questa forma.