Donar d’alta un usuari de VPN: primer trobeu el propietari de la identitat

Algú demana accés a la VPN, i el primer instint és executar adduser al servidor. Aquest instint només és correcte en un conjunt estret de desplegaments. Abans de crear res, obriu la configuració del servidor i esbrineu quin producte hi funciona i on valida les credencials, perquè el compte pot viure en una base de dades del producte, en un proveïdor d’identitat o a la pila d’autenticació pròpia de l’amfitrió. Crear el tipus de compte equivocat deixa la persona amb una entrada de sessió que funciona i sense túnel.

Un perfil de client que diu OpenVPN descriu el protocol, no el sistema d’identitat que hi ha al darrere.

Comenceu pel servidor, no per adduser

Identifiqueu primer el producte. Community OpenVPN és el dimoni més qualsevol autenticació que hi hàgiu connectat, mentre que Access Server és un producte amb la seva pròpia capa d’usuaris. Demaneu la configuració, el nom de la unitat i la llista de paquets, i comproveu si existeix una interfície web per gestionar usuaris. Després mireu com el perfil desplegat espera que els clients demostrin qui són: un certificat, un nom d’usuari i una contrasenya, o tots dos. Aquesta resposta anomena el sistema que posseeix el compte.

Només després d’això la frase crear l’usuari significa alguna cosa. En un desplegament només amb certificats vol dir emetre una identitat de dispositiu mitjançant el procés aprovat, i una entrada de sessió d’Unix no canvia res. En un desplegament amb contrasenya vol dir el backend que valida realment la contrasenya.

Quatre backends, quatre llocs on crear el compte

L’autenticació local d’Access Server guarda els comptes a la seva pròpia base de dades, així que la interfície per crear-los pertany al producte i no a l’amfitrió. PAM delega la validació a la pila del sistema operatiu, i per això un compte Unix local pot formar part de l’alta quan aquesta pila és la que el servei ha triat. LDAP, RADIUS i SAML traslladen la validació a un servei extern, on viuen l’aprovisionament, la política de contrasenyes i l’MFA. Access Server encara pot tenir certificats i permisos per usuari en els quatre casos, i això és el que fa confusa la separació.

Comproveu el mètode efectiu per a aquest usuari concret i no el valor predeterminat global. Access Server 2.10 i posteriors poden aplicar mètodes d’autenticació diferents per grup o per usuari, així que un valor predeterminat local no demostra que el compte que teniu davant es validi localment.

El dret és una decisió a part

L’autenticació respon qui és la persona; el dret respon a què pot arribar. Manteniu-ho com dos passos, perquè una entrada de sessió correcta no és una concessió. Assigneu deliberadament les rutes previstes, els permisos de recursos i els drets administratius, i confirmeu que l’accés no relacionat continua denegat. On el desplegament admet identitats individuals, emeteu-ne una per persona en lloc de reenviar el perfil d’una altra, perquè un perfil compartit no es pot retirar per a una sola persona.

El material del client també importa. Un perfil d’inici automàtic i una entrada de sessió interactiva d’usuari representen relacions d’autenticació diferents, i intercanviar l’un per l’altre canvia què verifica realment el servidor.

Retirar l’accés forma part de l’alta

Anoteu tres propietaris mentre es crea l’usuari: qui valida el compte, qui autoritza l’accés a la VPN i quin dispositiu o perfil representa la connexió. Poden ser tres sistemes diferents, i un pla de revocació que només n’anomena un deixa un camí obert. Quan la persona marxa, traieu el dret del seu propietari i retireu cada credencial emesa sota el seu propietari. Esborrar un fitxer descarregat no és revocar, i tampoc no ho és esborrar una entrada local si una identitat externa encara s’autentica.

Després proveu l’alta com ho faria un atacant: connecteu-vos una vegada amb la identitat nova, confirmeu l’accés al recurs previst i confirmeu que un recurs no relacionat encara el rebutja. Una primera connexió que funciona més una prova negativa és una alta completada.

Guardeu el registre amb el perfil al qual pertany. El proper auditor preguntarà qui podia connectar-se durant un mes determinat, i la resposta viu en aquests tres propietaris.