Accés VPN amb compte de servei: certificat o inici de sessió compartit

Dos dissenys cobreixen gairebé qualsevol configuració de VPN sense supervisió: un inici de sessió humà compartit desat en un script, o un certificat de màquina lligat a l’amfitrió. Fallen en llocs diferents, cosa que importa més que la velocitat de configuració. Una contrasenya desada es trenca quan el seu propietari la canvia o marxa; un certificat es trenca quan caduca o quan l’amfitrió es reconstrueix sense la clau. Tres condicions decideixen quin cost podeu suportar, i cap dels dos dissenys limita res fins que ho fa la política d’autorització.

Partiu de la tasca, no del compte

La tasca defineix el límit: quins destins, quins serveis, quines hores, quant pot durar una sessió. Una ruta de túnel és només la meitat d’aquest límit. La passarel·la decideix si la sessió està permesa; el recurs que hi ha darrere decideix què pot fer la sessió. Escriviu primer la llista, amb un propietari nomenat, perquè tots dos dissenys d’identitat l’han de satisfer.

Manteniu l’autenticació i l’autorització separades mentre ho escriviu. L’autenticació respon qui es connecta; l’autorització respon a què pot arribar la sessió després. RADIUS porta la segona part com a atributs com Filter-Id, Framed-IP-Address, Session-Timeout i Class, i la passarel·la els adjunta quan l’inici de sessió té èxit. Un disseny que canvia l’inici de sessió i deixa l’autorització intacta no ha limitat res.

Inici de sessió humà compartit: la contrasenya es converteix en el límit

Reutilitzar un compte humà és el camí més ràpid i el que envellieix pitjor. La credencial és una contrasenya, així que acaba en un script, un fitxer d’entorn i una configuració del planificador, i cada còpia necessita rotació. Quan el propietari la canvia un divendres, la tasca falla a l’execució següent i ningú no ho mira.

L’MFA és on aquest disseny sol enfonsar-se. Un script no pot respondre a una sol·licitud push, així que el compte queda exclòs de la política, que és exactament el compte que triaria un atacant. Les exclusions, els desviaments de ubicació de confiança i les exempcions per compte es multipliquen, i cap no és visible per a la propera persona que llegeixi la configuració del tenant.

L’atribució és l’altre cost. Cada sessió del registre de la passarel·la porta el mateix nom d’usuari, així que la sincronització nocturna no es pot distingir de la feina de la persona que la va escriure, i revocar la tasca significa revocar aquesta persona.

Certificat de màquina: identitat lligada a l’amfitrió

Un certificat canvia la pregunta de què sap el compte a què és l’amfitrió. Amb EAP-TLS el client presenta un certificat i demostra la possessió de la clau privada corresponent; el servidor de polítiques assigna el subjecte o el compte d’equip a un grup i aplica la política d’aquell grup. Cap sol·licitud, cap secret compartit en un fitxer de text.

El límit que crea és més estret del que la gent espera. Un certificat autentica l’amfitrió, no la tasca, i qualsevol amb drets de root o d’administrador local pot fer servir aquesta clau en aquest amfitrió. Manteniu la clau on la plataforma la protegeix: no exportable al magatzem de certificats de Windows, amb suport de TPM on el perfil ho permet, o un fitxer 0600 propietat de root a Linux. Comprometre l’amfitrió és comprometre la credencial.

La caducitat és la fallada recurrent. Un certificat que caduca un diumenge atura la tasca diumenge, i la passarel·la sol informar d’una fallada d’autenticació genèrica en lloc de dir la data. Comproveu les dates des de l’amfitrió de la tasca com a part del runbook:

openssl x509 -in client.pem -noout -subject -issuer -dates
ipsec listcerts

La revocació necessita un camí que la passarel·la comprovi. OpenVPN llegeix una CRL mitjançant l’opció crl-verify, i strongSwan depèn de CRL o OCSP segons com es construeixi el perfil de connexió. Si no n’hi ha cap de connectat, treure un amfitrió vol dir esperar que el certificat caduqui.

Tres condicions que decideixen entre ells

Feu la comparació contra la plataforma que teniu, no contra un disseny de referència.

Primera condició: pot la passarel·la autoritzar una identitat de màquina? Si només assigna un nom d’usuari RADIUS a un usuari del directori, un certificat autentica l’amfitrió i després s’encalla a l’autorització. Segona condició: la tasca necessita accés a un recurs que només porta un compte d’usuari, com un recurs compartit muntat o una llicència per seient? Llavors una identitat de màquina no pot substituir-lo, i la resposta honesta és un compte d’usuari dedicat amb una política acotada. Tercera condició: qui pot rotar la credencial sense una persona al circuit? L’enregistrament automàtic fa que els certificats siguin barats de mantenir; una contrasenya que coneix una sola persona, no.

Llegiu la taula com una llista de costos, no com un rànquing. La columna del secret desat guanya en velocitat de revocació i en compatibilitat amb recursos que només entenen comptes d’usuari; la columna del certificat guanya en rotació i en no debilitar l’MFA per fer funcionar un script.

Poseu el límit a la política, després de l’autenticació

Sigui quina sigui la identitat que trieu, el límit de permisos pertany a la política que s’executa després de l’autenticació. A NPS, les polítiques de xarxa s’avaluen en ordre i la primera política que coincideix amb cada condició aplica la seva configuració, així que una política àmplia col·locada damunt d’una de concreta decideix el resultat independentment del que presenti el client. Microsoft documenta el model de condicions i configuració al seu resum de polítiques NPS.

Dóna a la tasca el seu propi grup o condició de política, basat en alguna cosa que porti la identitat de màquina: una plantilla de certificat, un identificador d’estació de trucada o una adreça d’un pool dedicat. Després limita la sessió amb atributs: un Filter-Id per al rol al qual la vostra passarel·la l’assigna, un Session-Timeout curt perquè una tasca encallada es reautentiqui en lloc de mantenir una sessió durant dies, i un Framed-IP-Address d’un pool que filtríssiu a l’altre costat. L’autorització d’aplicacions queda separada: un túnel cap a un servidor de bases de dades no és permís per llegir una taula dins seu.

Verifiqueu les denegacions, després planifiqueu la retirada

L’accés que funciona no demostra res sobre el mínim privilegi. Prova les denegacions en lloc d’això: connecta’t amb la identitat de la tasca i intenta arribar a un destí fora de la llista, obre una segona sessió simultània si la passarel·la ha de permetre només una, i repeteix l’inici de sessió després de revocar la credencial.

Després confirma la mateixa sessió en dos llocs. El registre de la passarel·la mostra la identitat que s’ha autenticat; el registre del servidor de polítiques mostra quina política ha coincidit i quins atributs ha retornat. A OpenVPN el servidor enregistra el nom comú del certificat, i ipsec statusall a strongSwan imprimeix el túnel establert amb la identitat en ús. Si els dos registres no coincideixen sobre la identitat, la política està coincidint amb una cosa diferent de la que assumeixes.

La retirada forma part del disseny, no d’un sprint de neteja. Escriviu tot el que cal esborrar (certificat o compte, pertinença a grup, política de xarxa, entrada de pool, regla de tallafocs a l’objectiu) i executeu-ho una vegada mentre la tasca sigui fàcil de reconstruir.

Si comenceu avui, treballeu en aquest ordre: escriviu la llista de recursos, trieu la identitat amb les tres condicions, poseu el límit a la política i exerciseu una denegació abans que la tasca entri en servei.