På kontorets Wi-Fi och ändå ombedd att använda VPN? Här är varför

Den bärbara datorn är på företagets SSID, certifikatfrågan godkändes, och en webbapp frågar fortfarande efter VPN:en. Det ser ut som dubbelarbete, och ibland är det det. De två inloggningarna genomdriver oftast olika beslut, och det enda sättet att veta om den andra förtjänar sin plats är att fråga vad den ändrar.

Att ansluta till ett nätverk är ett antagningsbeslut

En 802.1X-driftsättning svarar på en fråga: får den här enheten eller användaren ansluta till det här nätverket? Åtkomstpunkten skickar vidare uppgifterna till en RADIUS-server, och svaret kan bära attribut som placerar sessionen i ett visst VLAN eller tillämpar ett filter. Det är antagning och segmentering, inte auktorisering för en viss applikation.

När sessionen har antagits krypteras den trådlösa länken mellan klienten och åtkomstpunkten. Skyddet slutar där, vid kanten av det kabelbundna nätverket.

Allt bortom den punkten är vanlig routning inne i byggnaden, med den interna nåbarhet som segmentet tillåter.

Vad EAP-TTLS faktiskt skyddar

EAP-TTLS bygger en TLS-tunnel under autentiseringen och kör en inre metod inuti den. Den inre metoden är ofta PAP, och att den förekommer i en design betyder inte att lösenordet går genom luften som klartext, eftersom det är TLS-tunneln som bär det. Klienten måste fortfarande verifiera serverns identitet och lita på rätt CA, och ett bekant SSID är inte den verifieringen. Läs valet av inre metod som ett format för autentiseringsuppgifter, inte som ett påstående om den yttre krypteringen.

Det här är ett autentiseringsutbyte, inte en datatunnel för den bärbara datorns senare trafik.

När autentiseringen är klar är TLS-tunneln borta och klientens paket färdas över det antagna segmentet. Att blanda ihop de två är roten till tron att Wi-Fi-kryptering redan gör VPN:ens arbete.

VPN:en är ett andra, snävare beslut

En VPN svarar på en annan fråga: vilka privata resurser får den här identiteten nå, och under vilka villkor? Den terminerar vid en gateway med egen policy, egna identitetskontroller och ofta egna krav på enhetens tillstånd. Den nåbara mängden efter att tunneln rest sig är vanligtvis mindre än byggnadens interna nätverk och specifik för rollen.

Därför kan en underhållsroll antas till Wi-Fi som alla andra och ändå behöva en tunnel för att nå ett administrationssubnät. Wi-Fi-beslutet fattades vid åtkomstpunkten; det här fattas vid gatewayen.

Båda stegen kan vara krypterade och ändå genomdriva orelaterade policyer.

Där platsbaserat förtroende brister

Att behandla kontorets nätverk som implicit pålitligt misslyckas av en enkel anledning: nätverksplats är en egenskap hos anslutningen, inte hos personen. NIST:s riktlinjer för nolltillit säger det direkt, och därför avgörs resursåtkomst per begäran och inte per byggnad. Den som ansluter till samma SSID ärver samma plats. Det är också därför en komprometterad bärbar dator på personalnätet förtjänar samma skepsis som en på gästnätet.

Den praktiska konsekvensen är att applikationsauktorisering fortfarande måste finnas. En VPN som ger ett helt subnät, plus en applikation som litar på varje begäran från det subnätet, är en autentiseringsuppgift från en dålig dag.

Inget av lagren ersätter det andra, eftersom de svarar på frågor i olika omfattningar.

Hur du avgör om den andra inloggningen förtjänar sin plats

Fråga nätverksägaren om två saker: vad som blir nåbart efter att VPN:en ansluter, och vilka identitets- eller enhetsvillkor som kontrolleras för att tillåta det? Verifiera sedan svaren genom att testa vad som faktiskt svarar. Om tunneln varken ändrar nåbarhet eller trygghet kan det vara operativ vana snarare än en kontroll, och det är ett beslut för ägaren, inte något en användare bör gå runt.

Leta också efter oavsiktliga direkta vägar, eftersom en resurs som är nåbar utan tunneln gör tunneln dekorativ.

Dokumentera varje gräns och dess syfte, och nästa person behöver inte gissa varför det finns två inloggningar.