Zero Trust, VPN ja TLS-tarkastus tekevät eri tehtäviä

Hankinta-asiakirjat kohtelevat zero trustia, VPN:ää ja TLS-tarkastusta kuin ne olisivat sama hankinta, ja jokainen niistä vastaa kysymykseen, johon muut eivät pysty. Tunneli rakentaa suojatun reitin, tarkastusyhdyskäytävä lukee liikennettä, jonka se pystyy päättämään, ja käytäntö päättää, saako nimetty identiteetti suorittaa nimitetyn toiminnon nimetyllä resurssilla. Vain viimeinen niistä on valtuutuspäätös. Tuote voi tehdä kaksi ensimmäistä täydellisesti ja jättää silti varsinaisen kysymyksen avoimeksi.

Kolme mekanismia, kolme kysymystä

Tunneli vastaa, miten liikenne saavuttaa verkon. Tarkastusyhdyskäytävä vastaa, mitä välilaite voi nähdä ja tehdä siellä, missä sillä on valtuus päättää TLS. Käytäntömoottori vastaa, kuka saa tehdä mitä millekin resurssille, ja sitten se tarvitsee valvontapisteen, joka pystyy soveltamaan tätä vastausta. NISTin zero trust -arkkitehtuuri asettaa resurssin keskelle ja kieltäytyy päättelemästä luottamusta siitä, mistä paketti tuli.

Tätä kehystä on vaikeampi täyttää kuin tarraa, ja paljon vaikeampi väärentää katselmoinnissa. Se siirtää kysymyksen myös siitä, mitä tuotteita on käytössä, siihen, mitä päätöksiä pannaan täytäntöön ja millä.

Missä päätös tosiasiassa pannaan täytäntöön

Ota yksi pyyntö: tukiteknikko avaa palvelukonsolin, eikä samaan kytkimeen kytketty henkilökohtainen kone saa periä tätä lupaa pelkän läheisyyden vuoksi. Kirjoita muistiin sallittu toiminto, laitteen ehdot ja komponentti, joka ne panee täytäntöön. Sijoittelu ratkaisee kaiken: sovellusyhdyskäytävä, palveluvälityspalvelin, isäntäkontrolli tai muu raja, jota organisaatio tosiasiassa tukee. Mikä tahansa tuo komponentti onkin, sen on oltava sekä etä- että paikallisten yritysten reitillä.

Liikennettä, joka ei koskaan ylitä VPN-sisäänkäyntiä, ei ohjaa siellä tehtävä tarkistus, olipa se kuinka perusteellinen tahansa. Juuri tämä aukko selittää suurimman osan zero trust -kaavion ja toimivan käyttöönoton välisestä etäisyydestä. Piirrä pyynnön reitti ennen kuin piirrät arkkitehtuurin.

Salauksen purkaminen ei ole valtuutus

Sieppaus palvelee kapeita tarkastustavoitteita ja kantaa oman taakkansa: varmenteet, luotetut juuret, yksityisyyden tarkastelu ja sovellukset, jotka hajoavat sen alla. Mikään tästä ei ole zero trustin merkitys, eikä mikään tästä korvaa käytäntöpäätöstä. Henkilön todentaminen ja palvelun valtuuttaminen on täysin mahdollista purkamatta salausta yhdestäkään paketista. Purettu virta ei kerro mitään siitä, oliko käyttäjällä oikeus sen sisällä kuljetettuun toimintoon.

Käytäntö tarvitsee yhdenlaisen todisteen, eikä salauksen purkaminen ole sitä. Laitteen terveys on yksi syöte identiteetin, resurssin arkaluonteisuuden ja kontekstin joukossa, eikä sen läpäiseminen kerran anna tälle koneelle loppua verkkoa. Kahden sekoittaminen muuttaa valtuutuskysymyksen varmenneprojektiksi.

Kun yhdyskäytävä ei ole missään reitillä

Luettele, mikä kulkee koskettamatta etäyhdyskäytävää: yhteydet paikallisen segmentin koneiden välillä, kutsut työkuormalta toiselle ja päätepisteet, joihin päästään suoraan pilvitilin sisällä. Nimeä jokaiselle reitille valvontamenetelmä, joka voidaan tosiasiassa ottaa käyttöön tänään. Laitteisto, joka ei voi ylläpitää agenttia, tarvitsee silti jonkin muun nimenomaisesti tuetun kontrollin, eikä oletus agentin myöhemmästä saapumisesta sulje nyt mitään. Palvelusta palveluun -pääsy sopii yleensä paremmin työkuorman identiteettiin ja resurssia vasten kirjoitettuun tarkistukseen kuin vielä yhteen päällekkäisverkkoon.

Hyväksy suunnittelu käyttäytymisen eikä kaavioiden perusteella: mitkä toiminnot ovat sallittuja, mitkä kiellettyjä ja missä kukin vastaus pannaan täytäntöön. Hyväksy tietyt sallitut ja kielletyt toiminnot ja sisällytä yksi paikallinen reitti, joka ei koskaan saavuta yhdyskäytävää. Kirjaa, kuka omistaa käytännön, miten se muuttuu ja miten peruutus toimii.

Uudelleen nimetty tunneli on edelleen tunneli. Käytäntö päättää, ja jonkin on pantava se täytäntöön.