Mai aveți nevoie de un VPN dacă folosiți un Identity-Aware Proxy?

Premisa este aceasta: de îndată ce un proxy care cunoaște identitatea se așază în fața aplicațiilor interne, VPN-ul este doar decor și clientul poate pleca. Acest lucru este valabil pentru un singur caz îngust, o aplicație HTTPS interactivă folosită de o persoană într-un browser, și eșuează în tăcere în toate celelalte locuri. Un proxy autorizează o cerere față de o resursă; un VPN admite un client într-un perimetru de rețea, iar cele două frontiere coincid rareori. Înainte de a retrage un tunel, comparați operațiile pe care oamenii tăi le fac într-adevăr, nu etichetele de produs de pe diagramă.

Cele două porți autorizează lucruri diferite

O poartă de aplicație decide dacă această cerere, de la această identitate, poate ajunge la această resursă protejată. Prezentarea generală a Identity-Aware Proxy de la Google descrie exact această formă: un strat central de autorizare în fața aplicațiilor HTTPS, condus de un rol IAM. Granița este resursa, iar unitatea de acces este cererea. Un VPN rutat face ceva mai grosier și mai larg: admite un client într-un perimetru de rețea definit, după care aplicația decide în continuare ce poate face acel client.

Niciunul dintre modele nu îl implică pe celălalt. Trecerea porții nu spune nimic despre citirea unei înregistrări anume, iar prezența în rețea nu spune nimic despre permisiunea de a acționa.

Ce nu acoperă proxy-ul și acoperă VPN-ul

Sesiunile SSH, clienții de baze de date, brokerii de mesaje și numele de gazdă interne pe care niciun browser nu le deschide nu devin accesibile doar pentru că există un proxy web. Fiecare vorbește propriul protocol și fiecare are nevoie fie de propria cale autentificată, fie de o rețea care să îl transporte. Aceasta este golul pe care oamenii îl descoperă în prima zi a unei migrări, de obicei de la un inginer de gardă cu un laptop care nu mai poate rezolva un nume de gazdă.

Golul invers este la fel de real. Un VPN care admite un client într-o subrețea nu autentifică persoana din interior, iar un dispozitiv compromis în acea subrețea moștenește ce permite rețeaua. Dacă cerința este autorizare pentru fiecare cerere cu o identitate auditabilă, rutarea singură nu o poate produce. Majoritatea organizațiilor ajung să ruleze ambele, iar întrebarea interesantă este căror resurse li se permite fiecăruia să stea în față.

Fluxul clientului decide mai mult decât diagrama de arhitectură

O autentificare în browser cu redirecționare și o provocare MFA ocazională este o experiență bună pentru o persoană care face clic pe un semn de carte. O sarcină cron, un CLI sau un agent de build nu are browser și nu poate răspunde la o solicitare interactivă, așa că are nevoie de o cale non-interactivă documentată sau de tunel. Descoperirea acelei cerințe se întâmplă de obicei după aprobarea designului.

Numărați clienții înainte de a număra aplicațiile. Un tablou de bord poate servi o sută de oameni; un port de bază de date poate bloca o echipă întreagă.

Postura dispozitivului nu este o proprietate a niciuneia dintre porți

Instalarea unui client VPN nu este o verificare de conformitate, iar un design bazat pe browser nu este automat incapabil să respecte politica pentru dispozitive administrate. Ambele se pot integra cu semnale de postură și ambele pot fi implementate fără ele. Întrebați ce aplicare există, cui î aparține politica și ce se întâmplă cu un dispozitiv care o încalcă, în loc să deduceți asta din forma produsului.

Aceeași prudență se aplică și la eliminarea accesului. Ștergerea unei apartenențe la un grup în proxy și revocarea unui certificat pentru tunel sunt operații diferite cu întârzieri diferite, iar una dintre ele este de obicei uitată la plecare.

Găsiți căile alternative înainte de a retrage ceva

O origine neprotejată din spatele proxy-ului, un al doilea nume de gazdă care îl ocolește sau o rută privată largă rămasă dintr-un design anterior vor decide care poartă este efectiv în vigoare. Testați o operație permisă și una refuzată prin clientul real, nu prin consolă, și testați-le de pe un dispozitiv care nu a fost niciodată înscris. Cazul refuzat este cel care vă spune dacă poarta face ceva.

Apoi scrieți predarea: înscriere, actualizări, eliminarea accesului și calea de recuperare pentru cineva blocat afară la 2 dimineața. Eliminarea unei solicitări sau a unei aplicații client mută responsabilitatea între echipe; nu șterge responsabilitatea.

Dacă decideți săptămâna aceasta, începeți cu o listă de operații în loc de o listă de produse, marcați pe care le poate executa un browser și lăsați restul să justifice accesul la rețea care supraviețuiește.