Registrare un utente VPN: prima trovate il proprietario dell’identità

Qualcuno chiede l’accesso alla VPN, e il primo istinto è eseguire adduser sul server. Quell’istinto è corretto solo in un insieme ristretto di implementazioni. Prima di creare qualsiasi cosa, aprite la configurazione del server e scoprite quale prodotto vi gira e dove convalida le credenziali, perché l’account può vivere in un database del prodotto, presso un provider di identità o nello stack di autenticazione dell’host stesso. Creare il tipo di account sbagliato lascia la persona con un accesso funzionante e senza tunnel.

Un profilo client che dice OpenVPN descrive il protocollo, non il sistema di identità che gli sta dietro.

Partite dal server, non da adduser

Identificate prima il prodotto. Community OpenVPN è il demone più qualsiasi autenticazione vi abbiate collegato, mentre Access Server è un prodotto con il proprio livello utenti. Chiedete la configurazione, il nome dell’unità e l’elenco dei pacchetti, e verificate se esiste un’interfaccia web per la gestione degli utenti. Poi guardate come il profilo distribuito si aspetta che i client dimostrino chi sono: un certificato, un nome utente e una password, o entrambi. Quella risposta nomina il sistema che possiede l’account.

Solo dopo, la frase creare l’utente significa qualcosa. In una distribuzione solo con certificati significa emettere un’identità del dispositivo tramite il processo approvato, e un accesso Unix non cambia nulla. In una distribuzione con password significa il backend che convalida davvero la password.

Quattro backend, quattro luoghi dove creare l’account

L’autenticazione locale di Access Server tiene gli account nel proprio database, quindi l’interfaccia per crearli appartiene al prodotto e non all’host. PAM delega la convalida allo stack del sistema operativo, ed è per questo che un account Unix locale può far parte della registrazione quando il servizio ha scelto proprio quello stack. LDAP, RADIUS e SAML spostano la convalida su un servizio esterno, dove vivono il provisioning, la politica delle password e l’MFA. Access Server può comunque conservare certificati e permessi per utente in tutti e quattro i casi, ed è questo che rende confusa la separazione.

Verificate il metodo effettivo per questo specifico utente invece del valore predefinito globale. Access Server 2.10 e successivi possono applicare metodi di autenticazione diversi per gruppo o per utente, quindi un valore predefinito locale non dimostra che l’account davanti a voi venga convalidato localmente.

Il diritto è una decisione separata

L’autenticazione risponde a chi è la persona; il diritto risponde a cosa può raggiungere. Teneteli come due passaggi, perché un accesso riuscito non è una concessione. Assegnate deliberatamente le rotte previste, i permessi sulle risorse e i diritti amministrativi, e confermate che l’accesso non correlato resta negato. Dove la distribuzione supporta identità individuali, emettetene una per persona invece di inoltrare il profilo di qualcun altro, perché un profilo condiviso non può essere ritirato per una sola persona.

Anche il materiale del client conta. Un profilo con accesso automatico e un accesso utente interattivo rappresentano relazioni di autenticazione diverse, e scambiare l’uno con l’altro cambia ciò che il server verifica davvero.

Ritirare l’accesso fa parte della registrazione

Annotate tre proprietari mentre l’utente viene creato: chi convalida l’account, chi autorizza l’accesso VPN e quale dispositivo o profilo rappresenta la connessione. Possono essere tre sistemi diversi, e un piano di revoca che ne nomina solo uno lascia una via aperta. Quando la persona se ne va, rimuovete il diritto dal suo proprietario e revocate ogni credenziale emessa presso il suo proprietario. Eliminare un file scaricato non è una revoca, e non lo è nemmeno eliminare una voce locale se un’identità esterna si autentica ancora.

Poi testate la registrazione come farebbe un attaccante: collegatevi una volta con la nuova identità, confermate l’accesso alla risorsa prevista e confermate che una risorsa non correlata rifiuta ancora. Una prima connessione che funziona più un test negativo è una registrazione completata.

Conservate il registro con il profilo a cui appartiene. Il prossimo revisore chiederà chi poteva collegarsi durante un dato mese, e la risposta vive in quei tre proprietari.