Trenger du fortsatt en VPN hvis du bruker en Identity-Aware Proxy?

Antakelsen lyder slik: når først en identitetsbevisst proxy står foran de interne applikasjonene, er VPN-en bare dekorasjon og klienten kan gå. Det holder for ett smalt tilfelle, en interaktiv HTTPS-applikasjon som en person bruker i en nettleser, og det feiler lydløst alle andre steder. En proxy autoriserer en forespørsel mot en ressurs; en VPN slipper en klient inn i et nettverksområde, og de to grensene er sjelden sammenfallende. Før du pensjonerer en tunnel, sammenlign operasjonene folkene dine faktisk utfører, ikke produktetikettene på diagrammet.

To porter autoriserer ulike ting

En applikasjonsport avgjør om denne forespørselen, fra denne identiteten, kan nå denne beskyttede ressursen. Googles oversikt over Identity-Aware Proxy beskriver nettopp denne formen: et sentralt autorisasjonslag foran HTTPS-applikasjoner, styrt av en IAM-rolle. Grensen er ressursen, og enheten for tilgang er forespørselen. En rutet VPN gjør noe grovere og bredere: den slipper en klient inn i et definert nettverksområde, og deretter avgjør applikasjonen fortsatt hva klienten kan gjøre.

Ingen av modellene forutsetter den andre. Å passere porten sier ingenting om å lese en bestemt post, og å være på nettverket sier ingenting om tillatelse til å handle.

Hva proxyen ikke dekker, og VPN-en dekker

SSH-økter, databaseklienter, meldingsmeglere og interne vertsnavn som ingen nettleser noen gang åpner, blir ikke tilgjengelige bare fordi det finnes en webproxy. Hver snakker sin egen protokoll, og hver trenger enten sin egen autentiserte vei eller et nettverk som bærer den. Det er gapet folk oppdager første dag av en migrering, vanligvis fra en vaktingeniør med en bærbar PC som ikke lenger kan slå opp et vertsnavn.

Det motsatte gapet er like reelt. En VPN som slipper en klient inn i et subnett, autentiserer ikke personen inni det, og en kompromittert enhet på det subnettet arver det nettverket tillater. Hvis kravet er autorisasjon per forespørsel med en reviderbar identitet, kan ruting alene ikke produsere det. De fleste organisasjoner ender med å kjøre begge, og det interessante spørsmålet er hvilke ressurser hver av dem får stå foran.

Klientens arbeidsflyt avgjør mer enn arkitekturdiagrammet

En nettleserinnlogging med omdirigering og en og annen MFA-utfordring er en god opplevelse for en person som klikker på et bokmerke. En cron-jobb, en CLI eller en byggeagent har ingen nettleser og kan ikke svare på en interaktiv forespørsel, så den trenger en dokumentert ikke-interaktiv vei eller tunnelen. Oppdagelsen av det kravet skjer vanligvis etter at designet er godkjent.

Tell klientene før du teller applikasjonene. Ett dashbord kan betjene hundre mennesker; én databaseport kan blokkere et helt team.

Enhetens tilstand er ikke en egenskap ved noen av portene

Installasjon av en VPN-klient er ikke en samsvarskontroll, og et nettleserbasert design er ikke automatisk ute av stand til å etterleve policy for administrerte enheter. Begge kan integreres med tilstandssignaler, og begge kan rulles ut uten dem. Spør hvilken håndheving som finnes, hvem som eier policyen og hva som skjer med en enhet som feiler den, i stedet for å utlede det fra produktets form.

Samme forsiktighet gjelder fjerning av tilgang. Å slette et gruppemedlemskap i proxyen og tilbakekalle et sertifikat for tunnelen er forskjellige operasjoner med forskjellig forsinkelse, og én av dem blir vanligvis glemt ved offboarding.

Finn de alternative veiene før du pensjonerer noe

Et ubeskyttet opphav bak proxyen, et annet vertsnavn som omgår den, eller en bred privat rute til overs fra et tidligere design vil avgjøre hvilken port som faktisk gjelder. Test en tillatt og en avvist operasjon gjennom den ekte klienten, ikke gjennom konsollen, og test dem fra en enhet som aldri har vært registrert. Det avviste tilfellet er det som forteller deg om porten gjør noe i det hele tatt.

Skriv deretter overleveringen: registrering, oppdateringer, fjerning av tilgang og gjenopprettingsveien for noen som er låst ute klokken 2 om natten. Å fjerne en forespørsel eller en klientapplikasjon flytter ansvar mellom team; det sletter ikke ansvaret.

Hvis du bestemmer deg denne uken, start med en liste over operasjoner i stedet for en liste over produkter, merk hvilke en nettleser kan utføre, og la resten begrunne den nettverkstilgangen som overlever.