Toimiston Wi-Fi-ssä ja silti kysytään VPN:ää? Tässä syy

Kannettava on yrityksen SSID:ssä, varmennekehote hyväksyttiin, ja verkkosovellus kysyy silti VPN:ää. Se näyttää tuplatyöltä, ja joskus se sitä on. Kaksi kirjautumista panevat yleensä täytäntöön eri päätöksiä, ja ainoa tapa tietää, ansaitseeko toinen paikkansa, on kysyä, mitä se muuttaa.

Verkkoon liittyminen on sisäänpääsypäätös

802.1X-käyttöönotto vastaa yhteen kysymykseen: saako tämä laite tai käyttäjä liittyä tähän verkkoon? Tukiasema välittää tunnistetiedot RADIUS-palvelimelle, ja vastaus voi kantaa attribuutteja, jotka sijoittavat istunnon tiettyyn VLANiin tai soveltavat suodatinta. Se on sisäänpääsyä ja segmentointia, ei valtuutus johonkin tiettyyn sovellukseen.

Kun istunto on hyväksytty, langaton linkki salataan asiakkaan ja tukiaseman välillä. Suojaus päättyy siihen, langallisen verkon reunalle.

Kaikki tuon pisteen takana on tavallista reititystä rakennuksen sisällä, sillä sisäisellä tavoitettavuudella, jonka segmentti sallii.

Mitä EAP-TTLS oikeastaan suojaa

EAP-TTLS rakentaa TLS-tunnelin todennuksen aikana ja ajaa sen sisällä sisäistä menetelmää. Sisäinen menetelmä on usein PAP, eikä sen esiintyminen suunnitelmassa tarkoita, että salasana kulkee ilman halki selkokielisenä, sillä TLS-tunneli kuljettaa sen. Asiakkaan on silti varmennettava palvelimen identiteetti ja luotettava oikeaan CA:han, eikä tuttu SSID ole se varmennus. Lue sisäisen menetelmän valinta tunnistetietojen muodoksi, ei lausunnoksi ulkoisesta salauksesta.

Tämä on todennusvaihto, ei datatunneli kannettavan myöhemmälle liikenteelle.

Kun todennus päättyy, TLS-tunneli on poissa ja asiakkaan paketit kulkevat hyväksytyn segmentin yli. Näiden kahden sekoittaminen on sen uskomuksen juuri, että Wi-Fi-salaus hoitaa jo VPN:n työn.

VPN on toinen, kapeampi päätös

VPN vastaa eri kysymykseen: mihin yksityisiin resursseihin tämä identiteetti saa päästä ja millä ehdoilla? Se päättyy yhdyskäytävään, jolla on oma käytäntönsä, omat identiteettitarkistuksensa ja usein omat laitevaatimuksensa. Tunnelin noustua tavoitettava joukko on yleensä pienempi kuin rakennuksen sisäverkko ja roolikohtainen.

Siksi ylläpitorooli voidaan ottaa Wi-Fiin kuin kuka tahansa muukin, ja silti se tarvitsee tunnelin päästäkseen hallintaverkkoon. Wi-Fi-päätös tehtiin tukiasemalla; tämä päätös tehdään yhdyskäytävällä.

Molemmat vaiheet voivat olla salattuja ja silti panna täytäntöön toisiinsa liittymättömiä käytäntöjä.

Missä sijaintiin perustuva luottamus murtuu

Toimistoverkon pitäminen implisiittisesti luotettavana epäonnistuu yksinkertaisesta syystä: verkkosijainti on yhteyden ominaisuus, ei henkilön. NIST:n nollaluottamuksen ohjeet sanovat sen suoraan, ja siksi resurssien käyttö päätetään pyyntöä kohden, ei rakennusta kohden. Kuka tahansa samaan SSID:hen liittyvä perii saman sijainnin. Siksi myös työntekijöiden verkossa kompromettoitu kannettava ansaitsee saman epäluulon kuin vierasverkossa oleva.

Käytännön seuraus on, että sovellusten valtuutus on silti oltava olemassa. VPN, joka myöntää kokonaisen aliverkon, plus sovellus, joka luottaa kaikkiin kyseisestä aliverkosta tuleviin pyyntöihin, on yhden tunnistetiedon päässä huonosta päivästä.

Kumpikaan kerros ei korvaa toista, koska ne vastaavat kysymyksiin eri laajuudessa.

Miten tietää, ansaitseeko toinen kirjautuminen paikkansa

Kysy verkon omistajalta kahta asiaa: mitä tulee tavoitettavaksi, kun VPN yhdistyy, ja mitä identiteetti- tai laiteehtoja tarkistetaan sen sallimiseksi? Tarkista sitten vastaukset testaamalla, mikä todella vastaa. Jos tunneli ei muuta kumpaakaan, tavoitettavuutta tai varmuutta, se voi olla toimintatapa eikä valvontakeino, ja se on omistajan päätös, ei jotain, mitä käyttäjän pitäisi kiertää.

Etsi myös tahattomia suoria polkuja, sillä ilman tunnelia tavoitettava resurssi tekee tunnelista koristeellisen.

Dokumentoi jokainen raja ja sen tarkoitus, niin seuraavan ei tarvitse arvailla, miksi kirjautumisia on kaksi.