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 uski slučaj — interaktivnu HTTPS aplikaciju koju osoba koristi u pregledniku — i tiho pada svugdje drugdje. Proxy autorizira zahtjev prema resursu; VPN pušta klijenta u mrežni obuhvat, a te se dvije granice rijetko poklapaju. Prije nego umirovite tunel, usporedite operacije koje vaši ljudi doista 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 obuhvat, nakon čega aplikacija i dalje odlučuje što 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.

Što 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 staza ili mreža koja ga nosi. To je praznina koju ljudi otkriju prvog dana migracije, obično od dežurnog inženjera s prijenosnikom koji više ne može razriješiti ime hosta.

Obrnuta praznina jednako je 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.

Tijek 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 staza 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 što 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 putove prije nego bilo što 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 vrijedi. 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.

Povezani članci