Kontori Wi-Fis ja ikka küsitakse VPN-i? Siin on põhjus

Sülearvuti on ettevõtte SSID-s, sertifikaadi küsimus on vastu võetud, ja veebirakendus küsib ikka VPN-i. See näib kahekordse tööna, ja mõnikord ongi. Kaks sisselogimist rakendavad tavaliselt erinevaid otsuseid, ja ainus viis teada saada, kas teine oma koha ära teenib, on küsida, mida see muudab.

Võrku liitumine on vastuvõtuotsus

802.1X juurutamine vastab ühele küsimusele: kas see seade või kasutaja tohib selle võrguga liituda? Pääsupunkt annab mandaadid RADIUS-serverile edasi, ja vastus võib kanda atribuute, mis panevad sessiooni kindlasse VLAN-i või rakendavad filtrit. See on vastuvõtt ja segmenteerimine, mitte autoriseerimine ühegi konkreetse rakenduse jaoks.

Kui sessioon on vastu võetud, krüpteeritakse juhtmevaba ühendus kliendi ja pääsupunkti vahel. Kaitse lõpeb seal, juhtmega võrgu servas.

Kõik sellest punktist kaugemal on tavaline marsruutimine hoone sees, selle sisemise kättesaadavusega, mida segment lubab.

Mida EAP-TTLS tegelikult kaitseb

EAP-TTLS ehitab autentimise ajal TLS-tunneli ja käivitab selle sees sisemise meetodi. Sisemine meetod on sageli PAP, ja selle ilmumine kavandisse ei tähenda, et parool läbib õhu selge tekstina, sest seda kannab just TLS-tunnel. Klient peab ikkagi kontrollima serveri identiteeti ja usaldama õiget CA-d, ja tuttav SSID ei ole see kontroll. Lugege sisemise meetodi valikut mandaadi vorminguna, mitte väitena välise krüpteerimise kohta.

See on autentimisvahetus, mitte andmetunnel sülearvuti hilisema liikluse jaoks.

Kui autentimine lõpeb, on TLS-tunnel kadunud ja kliendi paketid liiguvad vastuvõetud segmendi kaudu. Nende kahe segiajamine on juur uskumuses, et Wi-Fi krüpteerimine teeb juba VPN-i tööd.

VPN on teine, kitsam otsus

VPN vastab teisele küsimusele: millistele privaatsetele ressurssidele see identiteet pääseb, ja millistel tingimustel? See lõpeb lüüsil, millel on oma poliitika, oma identiteedikontrollid ja sageli oma nõuded seadme seisundile. Tunneli püstitamise järel kättesaadav hulk on tavaliselt väiksem kui hoone sisevõrk ja rollipõhine.

Seetõttu võidakse hooldusrolli lubada Wi-Fi-sse nagu kõiki teisi, ja ikkagi on tal vaja tunnelit haldusalavõrgu juurde pääsemiseks. Wi-Fi otsus tehti pääsupunktis; see otsus tehakse lüüsil.

Mõlemad etapid võivad olla krüpteeritud ja ikkagi rakendada omavahel sidumata poliitikaid.

Kus asukohapõhine usaldus murtakse

Kontorivõrgu pidamine vaikimisi usaldusväärseks ebaõnnestub lihtsal põhjusel: võrgu asukoht on ühenduse omadus, mitte inimese oma. NIST-i nullusalduse juhised ütlevad seda otseselt, ja seetõttu otsustatakse ressurssidele juurdepääs iga päringu, mitte hoone kaupa. Igaüks, kes liitub sama SSID-ga, pärib sama asukoha. Seetõttu väärib kompromiteeritud sülearvuti töötajate võrgus sama skeptilisust kui külalisvõrgus olev.

Praktiline tagajärg on see, et rakenduste autoriseerimine peab ikkagi olema. VPN, mis annab terve alavõrgu, pluss rakendus, mis usaldab iga sealt alavõrgust tulevat päringut, on ühe mandaadi kaugusel halvast päevast.

Kumbki kiht ei asenda teist, sest nad vastavad küsimustele erinevas ulatuses.

Kuidas teada, kas teine sisselogimine oma koha ära teenib

Küsige võrgu omanikult kahte asja: mis muutub kättesaadavaks pärast VPN-i ühendamist, ja milliseid identiteedi või seadme tingimusi kontrollitakse selle lubamiseks? Seejärel kontrollige vastuseid, testides, mis tegelikult vastab. Kui tunnel ei muuda ei kättesaadavust ega tagatist, võib see olla pigem töövõte kui kontroll, ja see on omaniku otsus, mitte midagi, millest kasutaja peaks mööda minema.

Otsige ka soovimatuid otseteid, sest ilma tunnelita kättesaadav ressurss muudab tunneli dekoratiivseks.

Dokumenteerige iga piir ja selle eesmärk, ja järgmisel inimesel ei tule enam arvata, miks on kaks sisselogimist.