På kontorets Wi-Fi og likevel bedt om VPN? Her er grunnen

Den bærbare datamaskinen er på bedriftens SSID, sertifikatforespørselen ble godtatt, og en nettapp ber fortsatt om VPN-en. Det ser ut som dobbeltarbeid, og noen ganger er det det. De to innloggingene håndhever vanligvis forskjellige beslutninger, og den eneste måten å vite om den andre fortjener plassen sin er å spørre hva den endrer.

Å bli med i et nettverk er en opptaksbeslutning

En 802.1X-utrulling svarer på ett spørsmål: får denne enheten eller brukeren koble seg til dette nettverket? Aksesspunktet sender legitimasjonen videre til en RADIUS-server, og svaret kan bære attributter som plasserer økten i et bestemt VLAN eller bruker et filter. Det er opptak og segmentering, ikke autorisasjon for en bestemt applikasjon.

Når økten er tatt opp, krypteres den trådløse forbindelsen mellom klienten og aksesspunktet. Beskyttelsen slutter der, ved kanten av det kablede nettverket.

Alt utover det punktet er vanlig ruting inne i bygningen, med den interne rekkevidden segmentet tillater.

Hva EAP-TTLS faktisk beskytter

EAP-TTLS bygger en TLS-tunnel under autentiseringen og kjører en indre metode inne i den. Den indre metoden er ofte PAP, og at den dukker opp i et design betyr ikke at passordet går gjennom luften som klartekst, fordi det er TLS-tunnelen som bærer det. Klienten må fortsatt verifisere serverens identitet og stole på riktig CA, og en kjent SSID er ikke den verifiseringen. Les valget av indre metode som et format for legitimasjon, ikke som en uttalelse om den ytre krypteringen.

Dette er en autentiseringsutveksling, ikke en datatunnel for den bærbare maskinens senere trafikk.

Når autentiseringen er ferdig, er TLS-tunnelen borte, og klientens pakker reiser over det godtatte segmentet. Å forveksle de to er roten til troen på at Wi-Fi-kryptering allerede gjør VPN-ens arbeid.

VPN-en er en andre, smalere beslutning

En VPN svarer på et annet spørsmål: hvilke private ressurser kan denne identiteten nå, og på hvilke vilkår? Den terminerer ved en gateway med egen policy, egne identitetssjekker og ofte egne krav til enhetens tilstand. Settet som kan nås etter at tunnelen er oppe, er vanligvis mindre enn bygningens interne nettverk og spesifikt for rollen.

Derfor kan en vedlikeholdsrolle tas opp på Wi-Fi som alle andre og fortsatt trenge en tunnel for å nå et administrasjonssubnett. Wi-Fi-beslutningen ble tatt i aksesspunktet; denne tas i gatewayen.

Begge trinnene kan være krypterte og fortsatt håndheve urelaterte policyer.

Hvor stedsbasert tillit bryter sammen

Å behandle kontornettverket som implisitt pålitelig feiler av en enkel grunn: nettverksplassering er en egenskap ved forbindelsen, ikke ved personen. NISTs nulltillitsveiledning sier det direkte, og derfor avgjøres tilgang til ressurser per forespørsel og ikke per bygning. Alle som blir med i samme SSID, arver samme plassering. Det er også derfor en kompromittert bærbar maskin på ansattnettet fortjener samme skepsis som en på gjestenettet.

Den praktiske konsekvensen er at applikasjonsautorisasjon fortsatt må finnes. En VPN som gir et helt subnett, pluss en applikasjon som stoler på enhver forespørsel fra det subnettet, er én legitimasjon unna en dårlig dag.

Ingen av lagene erstatter det andre, fordi de svarer på spørsmål i ulike omfang.

Slik avgjør du om den andre innloggingen fortjener plassen sin

Spør nettverkseieren om to ting: hva som blir tilgjengelig etter at VPN-en kobler til, og hvilke identitets- eller enhetsvilkår som kontrolleres for å tillate det? Verifiser deretter svarene ved å teste hva som faktisk svarer. Hvis tunnelen verken endrer rekkevidde eller trygghet, kan det være operasjonell vane snarere enn en kontroll, og det er en beslutning for eieren, ikke noe en bruker bør gå utenom.

Se også etter utilsiktede direkte veier, fordi en ressurs som kan nås uten tunnelen, gjør tunnelen dekorativ.

Dokumenter hver grense og formålet med den, så slipper neste person å gjette hvorfor det er to innlogginger.