Potrebujete ešte VPN, ak používate Identity-Aware Proxy?

Predpoklad znie takto: akonáhle pred internými aplikáciami stojí proxy, ktorá pozná identitu, VPN je len dekorácia a klient môže odísť. Platí to na jeden úzky prípad, interaktívnu HTTPS aplikáciu, ktorú človek používa v prehliadači, a potichu zlyháva všade inde. Proxy autorizuje požiadavku voči zdroju; VPN púšťa klienta do sieťového rozsahu, a tieto dve hranice sa zriedka prekrývajú. Než tunel vyradíte, porovnajte operácie, ktoré vaši ĺudia skutočne vykonávajú, nie produktové štítky na diagrame.

Dve brány autorizujú rôzne veci

Brána aplikácie rozhoduje, či táto požiadavka od tejto identity môže dosiahnuť tento chránený zdroj. Prehľad Identity-Aware Proxy od Google opisuje presne tento tvar: centrálnu autorizačnú vrstvu pred HTTPS aplikáciami, riadenú rolou IAM. Hranicou je zdroj a jednotkou prístupu je požiadavka. Smerovaný VPN robí niečo hrubšie a širšie: púšťa klienta do definovaného sieťového rozsahu, po čom aplikácia stále rozhoduje, čo tento klient smie robiť.

Ani jeden model nepredpokladá ten druhý. Prechod bránou nič nehovorí o čítaní konkrétneho záznamu a pobyt v sieti nič nehovorí o povolení konať.

Čo proxy nepokrýva a VPN pokrýva

SSH relácie, klienti databáz, sprostredkovatelia správ a interné názvy hostiteľov, ktoré žiaden prehliadač nikdy neotvorí, sa nestanú dostupnými len preto, že existuje webová proxy. Každý hovorí vlastným protokolom a každý potrebuje buď vlastnú autentifikovanú cestu, alebo sieť, ktorá ho prenáša. To je medzera, ktorú ĺudia objavia prvý deň migrácie, zvyčajne od pohotovostného inžiniera s notebookom, ktorý už nevie vyriešiť názov hostiteľa.

Opačná medzera je rovnako reálna. VPN, ktorý púšťa klienta do podsiete, neautentifikuje človeka v nej, a prelomené zariadenie v tejto podsieti dedí čo sieť dovoľuje. Ak je požiadavkou autorizácia na každú požiadavku s auditovateľnou identitou, samotné smerovanie to nedokáže. Väčšina organizácií napokon prevádzkuje obe a zaujímavá otázka je, ktorým zdrojom smie ktorá stáť pred nimi.

Pracovný postup klienta rozhoduje viac ako architektonický diagram

Prihlásenie v prehliadači s presmerovaním a občasnou výzvou MFA je dobrý zážitok pre človeka, ktorý klikne na záložku. Úloha cron, CLI alebo agent zostavenia nemá prehliadač a nemôže odpovedať na interaktívnu výzvu, preto potrebuje zdokumentovanú neinteraktívnu cestu alebo tunel. Objavenie tejto požiadavky zvyčajne prichádza po schválení dizajnu.

Počítajte klientov skôr, než spočítate aplikácie. Jeden panel môže obslúžiť sto ĺudí; jeden databázový port môže zablokovať celý tím.

Stav zariadenia nie je vlastnosťou žiadnej z brán

Inštalácia klienta VPN nie je kontrola zhody a dizajn založený na prehliadači nie je automaticky neschopný dodržiavať politiku spravovaných zariadení. Obe sa môžu integrovať so signálmi stavu a obe sa dajú nasadiť bez nich. Pýtajte sa, aké presadzovanie existuje, komu patrí politika a čo sa stane so zariadením, ktoré ju poruší, namiesto odvodzovania z tvaru produktu.

Rovnaká opatrnosť platí pri odoberaní prístupu. Odstránenie členstva v skupine v proxy a odvolanie certifikátu pre tunel sú rôzne operácie s rôznym oneskorením a jedna z nich sa pri odchode zvyčajne zabudne.

Nájdite alternatívne cesty, než niečo vyradíte

Nechránený pôvod za proxy, druhý názov hostiteľa, ktorý ju obchádza, alebo široká súkromná trasa zostavená z predchádzajúceho dizajnu rozhodnú, ktorá brána je skutočne v platnosti. Otestujte povolenú a odmietnutú operáciu cez skutočného klienta, nie cez konzolu, a otestujte ich zo zariadenia, ktoré nikdy nebolo zaregistrované. Práve odmietnutý prípad vám povie, či brána vôbec niečo robí.

Potom napíšte odovzdanie: registrácia, aktualizácie, odobratie prístupu a cesta obnovy pre niekoho, kto je o 2 hodine ráno zamknutý vonku. Odstránenie výzvy alebo klientskej aplikácie presúva zodpovednosť medzi týmami; nezmaže ju.

Ak sa rozhodujete tento týždeň, začnite zoznamom operácií namiesto zoznamu produktov, označte, ktoré zvládne prehliadač, a ostatné nech zdôvodnia ten sieťový prístup, ktorý pretrvá.