Zero trust -vaihtoehdot VPN:lle puolustuksessa: ZTNA, ohjelmistomääritellyt perimeterit ja identiteettitietoiset välityspalvelimet

Vanhat VPN-ratkaisut suunniteltiin verkon perimeterille, jota ei enää ole olemassa. Kun jokainen sovellus sijaitsi konesalin sisällä ja jokainen käyttäjä istui hallitulla työasemalla tunnetussa aliverkossa, laajan tunnelipääsyn myöntäminen yritysverkkoon oli puolustettava asema. Nykyaikaiset puolustusarkkitehtuurit -- joissa kuormat ovat hajautettuina paikallisiin enklaaveihin, salaiseen pilveen, eteenpäin sijoitettuihin solmuihin ja liikkuviin komentopaikkoihin -- tekevät tästä mallista paitsi tehottoman myös aktiivisesti vaarallisen. VPN-keskittimestä tulee yksittäinen sivuttaisliikkeen riskipiste: yksi vaarantunut tunnistetieto tai väärin määritetty tunneli antaa vastustajalle saman implisiittisen verkkotason pääsyn, joka legitiimillä sisäpiiriläisellä on. Zero trust -arkkitehtuuri sotilasverkoille tarjoaa perustavanlaatuisesti erilaisen mallin, ja tämä artikkeli tarkastelee niitä erityisiä komponentteja, jotka korvaavat VPN:n käytännössä: Zero Trust Network Access, ohjelmistomääritellyt perimeterit ja identiteettitietoiset välityspalvelimet.

Miksi vanhat VPN-ratkaisut epäonnistuvat nykyaikaisissa puolustusarkkitehtuureissa

Vanhojen VPN-ratkaisujen arkkitehtuurinen epäonnistuminen puolustuskonteksteissa ei ole ensisijaisesti haavoittuvuus itse VPN-protokollassa -- IPsec- ja TLS-tunnelointi pysyvät kryptografisesti vakaina. Epäonnistuminen on pääsymallissa, jonka VPN pakottaa. Kun käyttäjä todentaa itsensä VPN-keskittimelle, tuloksena oleva tunneli antaa verkkotason tavoitettavuuden koko aliverkkoon tai VLAN:iin. VPN ei tiedä mihin tiettyyn sovellukseen käyttäjä aikoo päästä, ei arvioi yhdistävän laitteen tilaa eikä sovella istuntokohtaista käytäntöä pyydetyn resurssin arkaluonteisuuden perusteella. Jokainen istunto saa saman implisiittisen luottamuksen heti kun alkuperäinen tunnistetietotarkistus läpäisee.

Operatiivisissa puolustusympäristöissä tämä litteä luottamusmalli luo konkreettista riskiä. Vaarantuneet päätelaitteet -- vastustajien talteen ottamat kannettavat tietokoneet, vangituilta henkilöiltä uutetut tunnistetiedot -- kantavat samat VPN-pääsyoikeudet kuin hyvässä kunnossa olevat operatiiviset laitteet. Split-tunnel-määritykset, jotka otettiin käyttöön kaistankäytön vähentämiseksi eteenpäin sijoitetuilla tukikohdilla, luovat reititysasymmetrioita, joita turvallisuustiimit eivät pysty täysin auditoimaan. Ja kun VPN-keskittimissä itsessään on korjaamattomia haavoittuvuuksia, paljastunut hyökkäyspinta on portti koko suojattuun verkkosegmenttiin, ei yksittäiseen sovellukseen. Useat näkyvät tunkeutumiset puolustusalan toimittajien verkkoihin ovat noudattaneet täsmälleen tätä kaavaa: alkupääsy VPN-keskittimen haavoittuvuuden kautta, jota seuraa sivuttaisliike aliverkkojen välillä, joihin VPN-malli implisiittisesti luotti.

Operatiivinen tempo lisää toisen kitkakerroksen. VPN-pääsyn provisiointi uudelle toimittajalle, sijoitetulle yksikölle tai koalitiokumppanille vaatii manuaalisia palomuurisääntömuutoksia ja VPN-ryhmämäärityksiä. Pääsyn peruuttaminen tehtävän päätyttyä vaatii päinvastaisen. Uhkaympäristössä, jossa pääsy tulisi myöntää tietyn tehtävän keston ajaksi ja peruuttaa välittömästi kun tehtävä päättyy, VPN-pääsynhallinnan karkea jaottelu luo sekä yli-oikeutettua pysyvää pääsyä että aikaa vievää hallinnollista taakkaa. Operatiivinen peruste VPN:n korvaamiselle koskee yhtä paljon pääsyn ketteryyttä kuin tietoturva-asentoa.

Zero Trust Network Access (ZTNA) -arkkitehtuuri: periaatteet ja komponentit

Zero Trust Network Access (ZTNA) on arkkitehtuurinen malli, joka korvaa VPN:n suoraan käyttäjä-sovellus-yhteyksissä. Perustavanlaatuinen periaate on, ettei mihinkään yhteyteen luoteta verkkosijainnin perusteella. Jokaisen istunnon -- olipa se peräisin konesalin sisällä olevalta työasemalta tai eteenpäin sijoitetulla tukikohdalla olevalta tabletilta -- on esitettävä varmennettu identiteetti, laitteen tilan vahvistus ja riittävä kontekstuaalinen peruste ennen kuin käytäntömoottori valtuuttaa pääsyn tiettyyn sovellukseen. VPN-tunneli korvataan istuntokohtaisella, sovellukseen rajatulla yhteydellä, jota välittää ZTNA-yhdyskäytävä, joka pakottaa käytäntöpäätöksen.

ZTNA-arkkitehtuurilla on neljä ydinkomponenttia. Identiteetintarjoaja (IdP) myöntää kryptografisen identiteettiväittämän, jonka käyttäjä kantaa istuntoon. Puolustuskäyttöönotoissa tämä on tyypillisesti PKI-pohjainen järjestelmä, joka käyttää älykortteja, laitteistotunnuksia tai FIDO2-avaimia -- ei pelkkiä salasanapohjaisia tunnistetietoja. Käytäntömoottori arvioi identiteettiväittämän, laitteen tilan signaalit ja pääsypyynnön attribuutit käytäntösääntöjoukkoa vasten tuottaakseen salli- tai estä-päätöksen. ZTNA-yhdyskäytävä pakottaa kyseisen päätöksen verkkokerroksessa välittäen vain valtuutettuja sovellusistuntoja ja pudottaen kaiken muun liikenteen. Päätelaitteella toimiva laitteen tila-agentti kerää ja vahvistaa terveyssignaalit, joita käytäntömoottori vaatii. Nämä neljä komponenttia ovat vuorovaikutuksessa sekvenssissä, joka tuottaa aikarajoitetun, sovellukseen rajatun pääsytunnuksen jokaiselle valtuutetulle istunnolle pysyvän verkkotunnelin sijaan.

Käytännön vaikutus on mikrosegmentointi ilman monimutkaisuutta, joka liittyy sovelluskohtaisten palomuurisääntöjen määrittämiseen jokaisella verkkosegmentillä. Sovellukset eivät ole suoraan tavoitettavissa miltään verkolta; kaikki liikenne kulkee ZTNA-yhdyskäytävän läpi, joka tuntee jokaisen välittämänsä istunnon identiteetin. Tämä arkkitehtuuri kuvataan yksityiskohtaisesti kontekstissa Corvus QUANTUM zero trust -arkkitehtuuri: suunnittelu ja komponentit, joka toteuttaa täyden ZTNA-pinon puolustuspilvi- ja paikallisille käyttöönotoille.

Ohjelmistomääritellyt perimeterit: yhden paketin valtuutus ja ohjaimen suunnittelu

Ohjelmistomääritellyt perimeterit (SDP) laajentavat ZTNA-periaatteen verkon löytämiskerrokseen: infrastruktuuria ei pelkästään valvota pääsyltä vaan se tehdään täysin näkymättömäksi todentamattomille osapuolille. SDP-yhdyskäytävä ei vastaa TCP SYN -paketteihin, ei näy luottamattomille verkoille näkyvissä DNS-vastauksissa ja pudottaa kaiken liikenteen, jota ei ole edeltänyt kelvollinen yhden paketin valtuutuksen (SPA) koputus. Verkkoskannerin tai automaattisen hyväksikäyttökehyksen näkökulmasta infrastruktuuria ei yksinkertaisesti ole olemassa. Tämä "pimeän verkon" ominaisuus on määrittelevä piirre, joka erottaa SDP:n perinteisestä palomuuripakotetusta segmentoinnista, jossa infrastruktuuri on näkyvissä vaikka pääsy evätään.

Yhden paketin valtuutus toimii tarkasti määritellyn kättelyn kautta. SDP-asiakas kerää käyttäjän identiteettitunnuksen, pyydetyn palvelutunnisteen, aikaleiman ja kertaluonteisen arvon, allekirjoittaa yhdistetyn hyötykuorman laitteen laitteistoturvamoduulin tai TPM:n yksityisellä avaimella ja lähettää allekirjoitetun koputuksen yhtenä UDP-datagrammina SDP-ohjaimelle. Ohjain validoi koputuksen kryptografisen allekirjoituksen käyttäjän liitettyä julkista avainta vasten, tarkistaa aikaleiman toistosuojausta varten (tyypillisesti viiden sekunnin voimassaoloikkuna), arvioi pyydetyn palvelun pääsykäytännön ja, jos käytäntö sallii, ohjeistaa SDP-yhdyskäytävän avaamaan istuntokohtaisen palomuurisäännön kyseiselle asiakkaan IP:lle ja kohdeportille. Vasta sitten asiakas yrittää TCP-yhteyttä. Verkkoa tarkkaileva havainnoitsija näkee koputusdatagrammin -- joka on salattu ja jossa ei ole selväkielistä palvelutunnistetta -- mutta ei voi toistaa sitä, ei voi määrittää mitä palvelua pyydettiin eikä voi yhdistää ilman kelvollista identiteettitunnistetietoa.

Ohjaimen suunnittelu on arkkitehtuurinen päätös, joka vaikuttaa eniten SDP:n operatiiviseen sietokykyyn. Yksittäinen keskitetty ohjain on yksittäinen vikapiste koko pääsynvalvonnan ohjaustasolle. Puolustuskäyttöönotot käyttävät tyypillisesti hajautettua ohjainklusteria konsensusmekanismilla (Raft- tai Paxos-pohjaisella), joka kestää vähemmistön solmujen menetyksen. Eteenpäin sijoitetuille yksiköille, joiden on säilytettävä pääsykyky viestintähäiriön aikana, paikallinen SDP-ohjaininstanssi voidaan ottaa käyttöön yksikön verkon reunalla, synkronoituna keskusohjaimen kanssa kun yhteys on saatavilla ja toimien itsenäisesti paikallisesti välimuistitetulla käytäntötilannekuvalla kun yhteyttä ei ole.

Identiteettitietoiset välityspalvelimet: pääsykäytännön pakottaminen sovelluskerroksessa

Identiteettitietoiset välityspalvelimet (IAP) täydentävät ZTNA:ta ja SDP:tä siirtämällä pääsyn pakotuspisteen verkkokerroksesta sovelluskerrokseen. Kun ZTNA-yhdyskäytävä valvoo voiko istunto tavoittaa sovelluksen verkkopäätepisteen, IAP päättää istunnon, tarkastaa sovelluskerroksen protokollan, arvioi identiteetin ja käytännön ja uudelleenmuodostaa yhteyden taustajärjestelmään vain jos pyyntökohtainen valtuutus onnistuu. IAP ymmärtää HTTP-verbit, URL-polut, gRPC-palvelunimet ja SSH-alijärjestelmät -- se voi pakottaa pääsykäytäntöä yksittäisten API-päätepisteiden tai komentoluokkien tarkkuudella, ei pelkästään sovelluksen kokonaisuuden tasolla.

Puolustussovelluksille IAP:t tarjoavat kyvyn, jota puhtaat verkkotason valvonnat eivät pysty: hienojakoiset, auditoitavat valtuutuspäätökset, jotka kirjataan varmennetulla käyttäjäidentiteetillä, ei lähde-IP-osoitteella. Salaisen datapalvelun edessä istuva IAP voi pakottaa, että logistiikka-analyytikko saa kysellä lukupäätepisteitä mutta ei kirjoituspäätepisteitä, että koalitiokumppanin identiteetti saa käyttää luokittelemattomia dataobjekteja mutta sille evätään pääsy salaisia pyydettäessä, ja että mikä tahansa pääsy tiettyyn datakategoriaan laukaisee hälytyksen turvallisuusoperaatiotiimille. Nämä valvonnat ovat verkkotopologiasta riippumattomia -- taustasovellusta ei tarvitse muokata niiden pakottamiseksi, ja ne pysyvät tehokkaina vaikka päätelaitteen verkko-osoite muuttuu roamingin tai VPN:ttömän yhteyden vuoksi.

IAP ratkaisee myös jäljitysketjuongelman, joka vaivaa IP-pohjaisia pääsylokeja. Koska IAP todentaa jokaisen pyynnön ja lisää varmennettuja identiteettiotsikoita, jotka taustasovellus kirjaa, jäljitysketju yhdistää jokaisen dataan pääsyn tiettyyn käyttäjäidentiteettiin sen sijaan kuin IP-osoitteeseen, joka voi olla jaettu, NATin takana tai väärennetty. Salaisille ympäristöille, joita koskevat auditointivaatimukset, tämä identiteettiin kohdennettu pääsyloki on merkittävä operatiivinen parannus verrattuna istuntotason lokeihin, joita VPN-keskittimet tuottavat.

Laitteen tilan arviointi: päätelaitteen terveyden varmistaminen ennen pääsyn myöntämistä

Laitteen tilan arviointi on mekanismi, jolla ZTNA-järjestelmät varmistavat, että yhdistävä päätelaite on tunnetussa hyvässä tilassa ennen pääsytunnuksen myöntämistä. Tilan arviointi sulkee hyökkäysvektorin, jonka pelkkä verkkotunnistetietotarkistus jättää auki: kelvollinen tunnistetieto vaarantuneella laitteella. Tila-agentti, joka on asennettu hallittuun päätelaitekantaan, kerää signaaleja, jotka vahvistavat laitteen tietoturvatilan, ja lähettää ne käytäntömoottorille osana istunnon valtuutuspyyntöä. Signaalit sisältävät tyypillisesti käyttöjärjestelmän version ja korjaustason, päätelaitteen havaitsemis- ja vastausagentin (EDR) tilan ja viimeisen skannauksen aikaleiman, levyn salauksen tilan, organisaation PKI:n myöntämän liittymissertifikaatin läsnäolon ja kelvollisuuden sekä tunnettujen haitallisten prosessien puuttumisen.

Tilakäytännön suunnittelu vaatii tietoturvan tiukkuuden tasapainottamista operatiivisen jatkuvuuden kanssa. Käytäntö, joka vaatii ajantasaista EDR-allekirjoitustietokantaa, evää pääsyn päätelaitteilta, jotka ovat olleet offline-tilassa viestintäkielletyssä ympäristössä ja jotka eivät ole saaneet tuoreita päivityksiä -- skenaario, joka on rutiinia sijoitetuille puolustusyksiköille. Puolustuksen ZTNA-käyttöönotot määrittelevät tyypillisesti porrastetut tilatasot: täysin hallittu laite ajantasaisilla korjauksilla ja aktiivisella EDR:llä saa rajoittamattoman pääsyn kaikkiin valtuutettuihin sovelluksiin; hallittu laite vanhentuneilla EDR-allekirjoituksilla saa pääsyn vähennettyyn sovellusjoukkoon pois lukien arkaluonteisimmat resurssit; hallitsematon laite ilman liittymissertifikaattia ei saa pääsyä tai pääsyn, joka on rajoitettu vain-luku-tietoportaaliin manuaalista tarkistusta odottaen. Tämä porrastettu malli säilyttää operatiivisen pääsyn sijoitetulle henkilöstölle samalla kun se ylläpitää merkityksellistä tilan pakotusta.

Jatkuva tilan uudelleenarviointi aktiivisten istuntojen aikana käsittelee skenaarion, jossa laite läpäisee alkuperäisen tilatarkistuksen ja sitten heikkenee -- koska EDR-agentti tapetaan, koska käyttäjä asentaa luvatonta ohjelmistoa tai koska uusi korkean vakavuuden haavoittuvuus julkaistaan laitteen komponenttia vastaan. Tila-agentti raportoi terveysmuutokset käytäntömoottorille määritettävällä väliajalla. Kun käytäntömoottori vastaanottaa tilasignaalin, joka pudottaa laitteen alle nykyisen istuntonsa vaaditun vähimmäistason, se peruuttaa pääsytunnuksen ja pakottaa uudelleentodennuksen. Istunnon päättyminen kirjataan sen tietyn tilasignaalin kanssa, joka laukaisi sen, antaen turvallisuusoperaatioille tarkan tiedon siitä, milloin ja miksi pääsy peruutettiin.

ZTNA:n käyttöönotto air-gapped- ja salaisissa ympäristöissä: rajoitteet ja sovitukset

Internet-yhteydellisille yritysympäristöille suunnitellut ZTNA-toteutukset olettavat, että identiteetintarjoaja, käytäntömoottori ja uhkatiedustelusyötteet, joihin tilan arviointi tukeutuu, ovat tavoitettavissa julkisen internetin tai pilviselkärangan kautta. Air-gapped- ja salaiset verkot asettavat erilaisen rajoitejoukon: ei internet-yhteyttä, tiukat datadiodi- tai cross-domain-ratkaisun (CDS) vaatimukset millä tahansa ulkoisella rajalla ja akkreditointiprosessit, jotka säätelevät mitkä ohjelmistokomponentit saavat toimia luokittelurajojen sisällä. Nämä rajoitteet vaativat arkkitehtuurisovituksia, jotka säilyttävät zero trust -pääsymallin samalla kun ne eliminoivat jokaisen riippuvuuden ulkoisesta yhteydestä.

Ensisijainen sovitus on kaikkien ZTNA-ohjaustasokomponenttien isännöinti luokittelurajojen sisällä. Identiteetintarjoaja, sertifikaattiviranomainen joka myöntää laitteiden liittymissertifikaatit, käytäntömoottori, SDP-ohjainklusteri ja IAP-käyttöönotto toimivat kaikki paikallisina kuormina enklaavin sisällä. Koska ulkoista PKI-yhteyttä ei ole, sertifikaattien peruutus on hoidettava sisäisesti isännöidyllä OCSP-vastaajalla tai säännöllisesti jaetulla sertifikaattien peruutuslistalla (CRL), joka päivitetään enklaavin muutoksenhallintaprosessin kautta. Uhkatiedustelusyötteet, jotka informoivat tilakäytäntöä -- kuten vasta julkaistut CVE:t käyttöjärjestelmäkomponentteja vastaan -- otetaan sisään valvotun siirtoprosessin kautta määritellyllä päivitystahdilla reaaliajan sijaan.

Toinen rajoite on laitteen liittymisprosessi. Yrityksen ZTNA-käyttöönotoissa laitteet liitetään käyttäjän vieraillessa IdP-isännöidyllä liittymisportaalilla internetin yli. Air-gapped-ympäristöissä liittymisen on tapahduttava in-band-prosessin kautta: laite yhdistetään erilliseen liittymisverkkosegmenttiin, PKI-agentti asennetaan ja liittymissertifikaatti myönnetään, ja laite yhdistetään sitten uudelleen operatiiviseen verkkoon. Tämä prosessi on dokumentoitava ja pakotettava akkreditointipaketissa, ja liittymisverkkosegmentti on eristettävä operatiivisesta liikenteestä, jotta sertifikaatin myöntämistä ei käytetä hyökkäysvektorina. Kovennusmallit puolustuksen Kubernetes-kuormille, jotka isännöivät ZTNA-ohjaustasokomponentteja, soveltavat samaa eristyksen ja minimaalisen altistuksen periaatetta klusterin hallintarajapintoihin.

Migraatiopolku: siirtyminen vanhasta VPN:stä ZTNA:han ilman palvelukatkoja

Migraatio vanhasta VPN:stä ZTNA:han on puolustusympäristöissä harvoin yksittäinen kertaluonteinen vaihto. Sovellusten monimuotoisuus, päätelaitekannan heterogeenisyys ja jatkuvan pääsyn operatiivinen kriittisyys tekevät vaiheittaisesta, rinnakkaiskäyttöisestä lähestymistavasta ainoan realistisen migraatiopolun. Migraatio etenee viidessä vaiheessa, jotka asteittain siirtävät sovellusryhmiä VPN-välitetystä pääsystä ZTNA-pakotettuun pääsyyn samalla kun ne ylläpitävät jatkuvaa operatiivista saatavuutta.

Ensimmäinen vaihe on kattava inventaario nykyisestä VPN-käytöstä: mitkä käyttäjät käyttävät mitäkin sovelluksia, millä protokollilla, miltä laitetyypeiltä ja minä operatiivisina ajanjaksoina. Tämä inventaario paljastaa riippuvuuksia, jotka eivät ole ilmeisiä verkkokaavioista -- sovellukset, jotka käyttävät VPN-tunnelia palvelujen väliseen todennukseen, vanhat järjestelmät, jotka sitovat pääsynvalvonnan lähde-IP-osoitteisiin, ja automaattiset prosessit, jotka käyttävät VPN-tunnistetietoja ajoitettuihin tehtäviin. Näistä piiloriippuvuuksista tulee migraation esteet, jotka on ratkaistava ennen kuin vastaava sovellus voidaan siirtää ZTNA-yhdyskäytävän taakse. Varjotilakäyttö -- ZTNA-käytäntömoottorin ajaminen vain-loki-tilassa samalla kun VPN pysyy aktiivisena -- tuo nämä riippuvuudet esiin häiritsemättä toimintaa, vaatien tyypillisesti kahdesta neljään viikkoa havainnointia sovellusryhmää kohti ennen kuin käytäntö on riittävän täydellinen luotettavaksi.

Asteittainen vaihto etenee matalimman kriittisyyden sovellusryhmistä korkeimman kriittisyyden ryhmiin. Kukin ryhmä vaihdetaan huoltoikkunassa: kyseisen sovelluksen aliverkkojen VPN split-tunnel -reitit poistetaan, ZTNA-yhdyskäytävästä tulee ainoa pääsypolku, ja sitä seuraa tehostettu valvontajakso pyytääkseen kiinni mahdolliset pääsyhäiriöt, jotka varjotilahavainnointi jätti huomaamatta. Viimeistä vaihetta -- VPN-keskittimien käytöstäpoistoa -- tulisi edeltää täysi pääsytarkistus, joka vahvistaa ettei mikään sovellus jää tavoitettavaksi jäljellä olevan VPN-tunnelipääsyn kautta ja että kaikki istunnon pääsylokit kantavat nyt käyttäjäidentiteetin ensisijaisena pääsytunnisteena tunnelin IP:n sijaan. Operatiivinen tulos on verkko, jossa jokainen sovellusistunto on kohdennettavissa varmennettuun identiteettiin, jokaisen päätelaitteen terveystila on jatkuvasti vahvistettu ja sivuttaisliikkeen reittejä, jotka vanha VPN-topologia loi, ei enää ole olemassa.