Behöver du fortfarande en VPN om du använder en Identity-Aware Proxy?

Antagandet låter så här: när väl en identitetsmedveten proxy står framför de interna applikationerna är VPN:en bara dekoration och klienten kan gå. Det gäller ett smalt fall, en interaktiv HTTPS-applikation som en person använder i en webbläsare, och det misslyckas tyst överallt annars. En proxy auktoriserar en förfrågan mot en resurs; en VPN släpper in en klient i ett nätverksområde, och de två gränserna sammanfaller sällan. Innan du avvecklar en tunnel, jämför de åtgärder som dina medarbetare faktiskt utför, inte produktetiketterna på diagrammet.

Två portar auktoriserar olika saker

En applikationsport avgör om den här förfrågan, från den här identiteten, kan nå den här skyddade resursen. Googles översikt över Identity-Aware Proxy beskriver just den formen: ett centralt auktoriseringslager framför HTTPS-applikationer, styrt av en IAM-roll. Gränsen är resursen, och enheten för åtkomst är förfrågan. En routad VPN gör något grövre och bredare: släpper in en klient i ett definierat nätverksområde, och därefter avgör applikationen fortfarande vad klienten får göra.

Ingen av modellerna förutsätter den andra. Att passera porten säger inget om att läsa en viss post, och att vara på nätverket säger inget om behörighet att agera.

Vad proxyn inte täcker, och vad VPN:en täcker

SSH-sessioner, databasklienter, meddelandebrokers och interna värdnamn som ingen webbläsare någonsin öppnar blir inte nåbara bara för att det finns en webbproxy. Var och en talar sitt eget protokoll, och var och en behöver antingen sin egen autentiserade väg eller ett nätverk som bär den. Det är gapet folk upptäcker första dagen av en migrering, vanligtvis från en jourhavande ingenjör med en bärbar dator som inte längre kan slå upp ett värdnamn.

Det omvända gapet är lika verkligt. En VPN som släpper in en klient i ett subnät autentiserar inte personen inuti det, och en komprometterad enhet i det subnätet ärver vad nätverket tillåter. Om kravet är auktorisering per förfrågan med en granskningsbar identitet kan routning ensam inte åstadkomma det. De flesta organisationer kör till slut båda, och den intressanta frågan är vilka resurser var och en får stå framför.

Klientens arbetsflöde avgör mer än arkitekturdiagrammet

En webbläsarinhoggning med omdirigering och en och annan MFA-utmaning är en bra upplevelse för en person som klickar på ett bokmärke. Ett cron-jobb, ett CLI eller en byggagent har ingen webbläsare och kan inte svara på en interaktiv prompt, så den behöver en dokumenterad icke-interaktiv väg eller tunneln. Upptäckten av det kravet sker vanligtvis efter att designen godkänts.

Räkna klienterna innan du räknar applikationerna. En instrumentpanel kan betjäna hundra personer; en databasport kan blockera ett helt team.

Enhetens tillstånd är inte en egenskap hos någon av portarna

Att installera en VPN-klient är inte en efterlevnadskontroll, och en webbläsarbaserad design är inte automatiskt oförmögen att följa policy för hanterade enheter. Båda kan integreras med tillståndssignaler, och båda kan rullas ut utan dem. Fråga vilken efterlevnad som finns, vem som äger policyn och vad som händer med en enhet som bryter mot den, i stället för att härleda det ur produktens form.

Samma försiktighet gäller borttagning av åtkomst. Att radera ett gruppmedlemskap i proxyn och återkalla ett certifikat för tunneln är olika åtgärder med olika fördröjning, och en av dem glöms vanligtvis vid avslut.

Hitta de alternativa vägarna innan du avvecklar något

Ett oskyddat ursprung bakom proxyn, ett andra värdnamn som kringgår den, eller en bred privat rutt kvar från en tidigare design avgör vilken port som faktiskt gäller. Testa en tillåten och en nekad åtgärd genom den riktiga klienten, inte genom konsolen, och testa dem från en enhet som aldrig registrerats. Det nekade fallet är det som säger om porten gör något alls.

Skriv sedan överlämningen: registrering, uppdateringar, borttagning av åtkomst och återställningsvägen för någon som är utelåst klockan 2 på natten. Att ta bort en prompt eller en klientapplikation flyttar ansvar mellan team; det raderar inte ansvaret.

Om du bestämmer dig den här veckan, börja med en lista över åtgärder i stället för en lista över produkter, markera vilka en webbläsare kan utföra, och låt resten motivera den nätverksåtkomst som överlever.