Har du stadig brug for en VPN, hvis du bruger en Identity-Aware Proxy?

Antagelsen lyder sådan: når først en identitetsbevidst proxy står foran de interne applikationer, er VPN'en kun dekoration, og klienten kan gå. Det holder for ét smalt tilfælde, en interaktiv HTTPS-applikation som en person bruger i en browser, og det fejler lydløst alle andre steder. En proxy autoriserer en anmodning mod en ressource; en VPN lukker en klient ind i et netværksomfang, og de to grænser flugter sjældent. Før du pensionerer en tunnel, skal du sammenligne de handlinger, dine folk faktisk udfører, ikke produktetiketterne på diagrammet.

De to gates autoriserer forskellige ting

En applikationsgate afgør, om denne anmodning fra denne identitet må nå denne beskyttede ressource. Googles oversigt over Identity-Aware Proxy beskriver netop den form: et centralt autorisationslag foran HTTPS-applikationer, styret af en IAM-rolle. Grænsen er ressourcen, og adgangsenheden er anmodningen. En rutet VPN gør noget grovere og bredere: den lukker en klient ind i et defineret netværksomfang, hvorefter applikationen stadig afgør, hvad den klient må.

Ingen af modellerne forudsætter den anden. At passere gaten siger intet om at læse en bestemt post, og at være på netværket siger intet om at have lov til at handle.

Hvad proxyen ikke dækker, og VPN'en gør

SSH-sessioner, databaseklienter, beskedmæglere og interne værtsnavne, som ingen browser nogensinde åbner, bliver ikke tilgængelige, bare fordi der findes en webproxy. Hver taler sin egen protokol, og hver kræver enten sin egen autentificerede vej eller et netværk, der bærer den. Det er det hul, folk opdager på første dag af en migrering, normalt fra en vagthavende ingeniør med en laptop, der ikke længere kan slå et værtsnavn op.

Det omvendte hul er lige så virkeligt. En VPN, der lukker en klient ind i et subnet, autentificerer ikke personen indeni, og en kompromitteret enhed på det subnet arver, hvad netværket tillader. Hvis kravet er autorisation for hver anmodning med en reviderbar identitet, kan routing alene ikke levere det. De fleste organisationer ender med at køre begge, og det interessante spørgsmål er, hvilke ressourcer hver af dem må stå foran.

Klientens arbejdsgang afgør mere end arkitekturdiagrammet

Et browser-login med en omdirigering og en lejlighedsvis MFA-udfordring er en fin oplevelse for en person, der klikker på et bogmærke. Et cron-job, en CLI eller en build-agent har ingen browser og kan ikke svare på en interaktiv prompt, så den har brug for en dokumenteret ikke-interaktiv vej eller tunnelen. Opdagelsen af det krav sker normalt, efter at designet er godkendt.

Tæl klienterne, før du tæller applikationerne. Ét dashboard kan betjene hundrede mennesker; én databaseport kan blokere et helt team.

Enhedens tilstand er ikke en egenskab ved nogen af gaterne

Installation af en VPN-klient er ikke en compliance-kontrol, og et browserbaseret design er ikke automatisk ude af stand til at efterleve politik for administrerede enheder. Begge kan integreres med tilstandssignaler, og begge kan udrulles uden dem. Spørg, hvilken håndhævelse der findes, hvem der ejer politikken, og hvad der sker med en enhed, der fejler den, i stedet for at udlede det af produktets form.

Den samme forsigtighed gælder fjernelse af adgang. At slette et gruppemedlemskab i proxyen og tilbagekalde et certifikat til tunnelen er forskellige handlinger med forskellig forsinkelse, og en af dem bliver normalt glemt ved offboarding.

Find de alternative veje, før du pensionerer noget

Et ubeskyttet origin bag proxyen, et andet værtsnavn, der omgår den, eller en bred privat rute tilbage fra et tidligere design vil afgøre, hvilken gate der reelt er i kraft. Test en tilladt handling og en afvist gennem den rigtige klient, ikke gennem konsollen, og test dem fra en enhed, der aldrig har været tilmeldt. Det afviste tilfælde er det, der fortæller dig, om gaten overhovedet gør noget.

Skriv derefter overdragelsen: tilmelding, opdateringer, fjernelse af adgang og gendannelsesvejen for en person, der er låst ude klokken 2 om natten. At fjerne en prompt eller en klientapplikation flytter ansvar mellem teams; det sletter ikke ansvaret.

Hvis du beslutter det i denne uge, så start med en liste over handlinger i stedet for en liste over produkter, markér hvilke en browser kan udføre, og lad resten begrunde den netværksadgang, der overlever.