Treba li vam još VPN ako koristite Identity-Aware Proxy?

Pretpostavka ide ovako: kad se ispred internih aplikacija postavi proxy koji poznaje identitet, VPN je samo ukras i klijent može otići. To vrijedi za jedan uzak slučaj — interaktivnu HTTPS aplikaciju koju osoba koristi u pregledniku — i tiho pada svuda drugdje. Proxy autorizira zahtjev prema resursu; VPN pušta klijenta u mrežni obim, a te dvije granice se rijetko poklapaju. Prije nego što umirovite tunel, uporedite operacije koje vaši ljudi zaista izvode, a ne oznake proizvoda na dijagramu.

Dva prolaza autoriziraju različite stvari

Prolaz aplikacije odlučuje smije li ovaj zahtjev, od ovog identiteta, doći do ovog zaštićenog resursa. Googleov pregled Identity-Aware Proxy opisuje upravo taj oblik: središnji sloj autorizacije ispred HTTPS aplikacija, kojim upravlja IAM uloga. Granica je resurs, a jedinica pristupa je zahtjev. Rutirani VPN radi nešto grublje i šire: pušta klijenta u definirani mrežni obim, nakon čega aplikacija i dalje odlučuje šta taj klijent smije.

Nijedan model ne podrazumijeva drugi. Prolazak kroz prolaz ne govori ništa o čitanju određenog zapisa, a boravak na mreži ne govori ništa o dopuštenju da se djeluje.

Šta proxy ne pokriva, a VPN pokriva

SSH sesije, klijenti baza podataka, brokeri poruka i interna imena hostova koja nijedan preglednik nikad ne otvori ne postaju dostupni samo zato što postoji web proxy. Svaki govori svoj protokol, i svakom treba ili vlastita autentificirana putanja ili mreža koja ga nosi. To je praznina koju ljudi otkriju prvog dana migracije, obično od dežurnog inženjera s laptopom koji više ne može razriješiti ime hosta.

Obrnuta praznina je jednako stvarna. VPN koji pušta klijenta u podmrežu ne autentificira osobu unutar nje, a kompromitirani uređaj na toj podmreži nasljeđuje sve što mreža dopušta. Ako je zahtjev autorizacija po svakom zahtjevu s revizijski provjerljivim identitetom, samo rutiranje to ne može proizvesti. Većina organizacija na kraju vodi oboje, a zanimljivo pitanje je kojim resursima je svakome dopušteno stajati na čelu.

Tok rada klijenta odlučuje više od arhitektonskog dijagrama

Prijava u pregledniku s preusmjeravanjem i povremenim MFA izazovom dobro je iskustvo za osobu koja klikne na zabilješku. Cron posao, CLI ili build agent nema preglednik i ne može odgovoriti na interaktivni upit, pa mu treba dokumentirana neinteraktivna putanja ili tunel. Otkriće tog zahtjeva obično se dogodi nakon što je dizajn odobren.

Prebrojite klijente prije nego prebrojite aplikacije. Jedna nadzorna ploča može služiti stotinu ljudi; jedan port baze podataka može blokirati cijeli tim.

Stanje uređaja nije svojstvo nijednog prolaza

Instalacija VPN klijenta nije provjera usklađenosti, a dizajn temeljen na pregledniku nije automatski nesposoban poštovati politiku upravljanih uređaja. Oba se mogu integrirati sa signalima stanja, i oba se mogu uvesti bez njih. Pitajte kakva prisila postoji, ko posjeduje politiku i šta se događa s uređajem koji je prekrši, umjesto da to zaključujete iz oblika proizvoda.

Isti oprez vrijedi i za uklanjanje pristupa. Brisanje članstva u grupi na proxyju i opoziv certifikata za tunel različite su operacije s različitim kašnjenjem, a jedna od njih se obično zaboravi pri offboardingu.

Pronađite alternativne putanje prije nego bilo šta umirovite

Nezaštićeni izvor iza proxyja, drugo ime hosta koje ga zaobilazi ili široka privatna ruta ostala iz ranijeg dizajna odredit će koji prolaz zapravo važi. Testirajte dopuštenu i odbijenu operaciju kroz stvarnog klijenta, ne kroz konzolu, i testirajte ih s uređaja koji nikad nije bio upisan. Odbijeni slučaj je onaj koji vam kaže radi li prolaz uopće ikakav posao.

Zatim napišite primopredaju: upis, ažuriranja, uklanjanje pristupa i put oporavka za nekoga zaključanog u 2 sata ujutro. Uklanjanje upita ili klijentske aplikacije premješta odgovornost među timovima; ono ne briše odgovornost.

Ako odlučujete ovog tjedna, počnite s popisom operacija, a ne proizvoda, označite koje preglednik može izvesti, a ostale neka opravdaju mrežni pristup koji preživi.