Acces VPN pentru contul de serviciu: certificat sau autentificare partajată

Două modele acoperă aproape orice configurare VPN fără supraveghere: o autentificare umană partajată ținută într-un script sau un certificat de mașină legat de gazdă. Ele eșuează în locuri diferite, iar asta contează mai mult decât viteza de instalare. O parolă stocată se strică atunci când proprietarul o schimbă sau pleacă; un certificat se strică atunci când expiră sau când gazda este reconstruită fără cheie. Trei condiții decid ce cost poți duce, iar niciun model nu limitează nimic până când nu o face politica de autorizare.

Pornește de la sarcină, nu de la cont

Sarcina definește granița: ce destinații, ce servicii, în ce ore, cât de mult poate rula o sesiune. O rută de tunel este doar jumătate din acea graniță. Poarta decide dacă sesiunea este permisă; resursa din spatele ei decide ce poate face sesiunea. Scrie lista mai întâi, cu un proprietar numit, pentru că ambele modele de identitate trebuie să o îndeplinească.

Ține autentificarea și autorizarea separate în timp ce notezi. Autentificarea răspunde cine se conectează; autorizarea răspunde la ce poate ajunge sesiunea după aceea. RADIUS transportă a doua parte ca atribute precum Filter-Id, Framed-IP-Address, Session-Timeout și Class, iar poarta le atașează după ce autentificarea reușește. Un model care schimbă autentificarea și lasă autorizarea neatinsă nu a limitat nimic.

Autentificare umană partajată: parola devine granița

Refolosirea unui cont uman este calea cea mai rapidă și cea care îmbătrânește cel mai rău. Acreditarea este o parolă, așa că ajunge într-un script, într-un fișier de mediu și într-o configurație de planificator, iar fiecare copie are nevoie de rotație. Când proprietarul o schimbă într-o vineri, sarcina eșuează la următoarea rulare și nimeni nu se uită.

MFA este locul unde acest model se prăbușește de obicei. Un script nu poate răspunde la o cerere push, așa că contul este exclus din politică, exact contul pe care l-ar alege un atacator. Excluderile, ocolirile pentru locații de încredere și scutirile pe cont se înmulțesc, iar niciuna nu este vizibilă pentru următoarea persoană care citește setările chiriașului.

Atribuirea este celălalt cost. Fiecare sesiune din jurnalul porții poartă același nume de utilizator, așa că sincronizarea nocturnă nu poate fi deosebită de munca persoanei care a scris-o, iar revocarea sarcinii înseamnă revocarea acelei persoane.

Certificat de mașină: identitate legată de gazdă

Un certificat schimbă întrebarea din ce știe contul în ce este gazda. Cu EAP-TLS clientul prezintă un certificat și dovedește că deține cheia privată corespunzătoare; serverul de politici mapează subiectul sau contul de computer la un grup și aplică politica acelui grup. Fără prompt, fără secret partajat într-un fișier text.

Granița pe care o creează este mai îngustă decât se așteaptă lumea. Un certificat autentifică gazda, nu sarcina, iar oricine are drepturi de root sau de administrator local poate folosi acea cheie pe acea gazdă. Ține cheia acolo unde platforma o protejează: neexportabilă în magazinul de certificate Windows, susținută de TPM acolo unde profilul permite, sau un fișier 0600 deținut de root pe Linux. Compromiterea gazdei este compromiterea acreditării.

Expirarea este eșecul recurent. Un certificat care expiră într-o duminică oprește sarcina duminică, iar poarta raportează de obicei o eroare generică de autentificare în loc să numească data. Verifică datele de pe gazda sarcinii ca parte a runbook-ului:

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

Revocarea are nevoie de o cale pe care poarta o verifică. OpenVPN citește un CRL prin opțiunea crl-verify, iar strongSwan depinde de CRL sau OCSP în funcție de modul în care este construit profilul de conexiune. Dacă niciunul nu este conectat, eliminarea unei gazde înseamnă așteptarea expirării certificatului.

Trei condiții care decid între ele

Fă comparația cu platforma pe care o ai, nu cu un model de referință.

Prima condiție: poate poarta să autorizeze o identitate de mașină? Dacă mapează doar un nume de utilizator RADIUS la un utilizator din director, un certificat autentifică gazda și apoi se blochează la autorizare. A doua condiție: are sarcina nevoie de acces la resurse pe care numai un cont de utilizator le are, cum ar fi o partajare mapată sau o licență pe loc? Atunci o identitate de mașină nu poate înlocui, iar răspunsul cinstit este un cont de utilizator dedicat cu o politică delimitată. A treia condiție: cine poate roti acreditarea fără o persoană în buclă? Înregistrarea automată face certificatele ieftin de întreținut; o parolă știută de o singură persoană nu.

Citește tabelul ca o listă de costuri, nu ca un clasament. Coloana cu secret stocat câștigă la viteza de revocare și la compatibilitatea cu resursele care înțeleg doar conturi de utilizator; coloana certificatului câștigă la rotație și la faptul că nu slăbește MFA pentru ca un script să funcționeze.

Pune limita în politică, după autentificare

Orice identitate ai alege, limita de permisiuni aparține politicii care rulează după autentificare. În NPS, politicile de rețea sunt evaluate în ordine, iar prima politică ce corespunde tuturor condițiilor își aplică setările, așa că o politică largă plasată deasupra uneia înguste decide rezultatul, indiferent ce prezintă clientul. Microsoft documentează modelul de condiții și setări în prezentarea generală a politicilor NPS.

Dă sarcina propriul grup sau condiție de politică, bazată pe ceva ce poartă identitatea mașinii: un șablon de certificat, un identificator de stație apelantă sau o adresă dintr-un pool dedicat. Apoi mărginește sesiunea cu atribute: un Filter-Id pentru rolul căruia poarta îl mapează, un Session-Timeout scurt ca o sarcină blocată să se reautentifice în loc să țină o sesiune zile întregi, și un Framed-IP-Address dintr-un pool pe care îl filtrezi cu firewall pe partea cealaltă. Autorizarea aplicației rămâne separată: un tunel către un server de baze de date nu este permisiunea de a citi un tabel din el.

Verifică refuzurile, apoi planifică eliminarea

Accesul care funcționează nu dovedește nimic despre privilegiul minim. Testează refuzurile: conectează-te cu identitatea sarcinii și încearcă o destinație din afara listei, deschide o a doua sesiune concurentă dacă poarta ar trebui să permită doar una, și repetă autentificarea după revocarea acreditării.

Apoi confirmă aceeași sesiune în două locuri. Jurnalul porții arată identitatea care s-a autentificat; jurnalul serverului de politici arată ce politică s-a potrivit și ce atribute a returnat. Pe OpenVPN serverul înregistrează numele comun al certificatului, iar ipsec statusall pe strongSwan afișează tunelul stabilit cu identitatea folosită. Dacă cele două jurnale nu sunt de acord asupra identității, politica se potrivește cu altceva decât presupui.

Eliminarea aparține proiectării, nu unui sprint de curățenie. Notează tot ce trebuie șters (certificat sau cont, apartenență la grup, politică de rețea, intrare în pool, regulă de firewall pe țintă) și rulează-o o dată cât timp sarcina este ușor de reconstruit.

Dacă începi astăzi, lucrează în această ordine: scrie lista de resurse, alege identitatea cu cele trei condiții, pune limita în politică și exersează un refuz înainte ca sarcina să intre în producție.