ZTNA puolustukseen: identiteettitietoinen proxy ja politiikkakone

Reuna-VPN on ollut puolustusverkkojen ensisijainen etäpääsyn hallinta kolme vuosikymmentä. Käyttäjä todentautuu VPN-yhdyskäytävässä, tunneli muodostuu ja käyttäjä saa laajan verkkotason pääsyn reunan sisäpuolen resursseihin. Tämä malli suunniteltiin maailmaan, jossa sovellukset oli majoitettu yhteen konesaliin ja käyttäjät yhdistivät organisaation hallinnoimilta toimipisteiltä. Modernissa puolustusympäristössä – jossa kuormat ulottuvat suvereeniin pilveen, taktiseen reunaan ja ilmaraossa toimiviin luokiteltuihin enklaaveihin ja jossa käyttäjät yhdistävät hallinnoituilla ja osittain hallinnoituilla laitteilla useista sijainneista – VPN-arkkitehtuuri tuo mukanaan riskin, jota sen suunnittelijat eivät koskaan ennakoneet. Nollaluottamuksen verkkopääsy (ZTNA) on arkkitehtuurinen korvaaja: sovellustason pääsy identiteettitietoisen proxyn välittämänä, ehdollistettuna jatkuvalla todennuksella siitä, kuka yhdistää ja mitä laitetta hän käyttää. Tämä artikkeli tarkastelee ZTNA:n insinöörimekaniikkaa puolustuksessa: miten identiteetti- ja laitesignaalit kerätään ja arvioidaan, miten politiikkakone tuottaa pääsypäätökset ja miten ZTNA otetaan käyttöön koko kirjossa luokittelemattomista verkoista ilmaraossa toimiviin luokiteltuihin enklaaveihin.

Miksi perinteinen VPN ei sovi puolustuksen nollaluottamukseen

VPN:n perusongelma nollaluottamuksen näkökulmasta ei ole salaus – VPN-tunnelit ovat kryptografisesti luotettavia. Ongelma on siinä, mitä VPN myöntää salauksen muodostuttua. Kun käyttäjä todentautuu VPN-yhdyskäytävään ja tunneli nousee, käyttäjän laite saa verkon osoitteen puolustusenklaavin sisällä ja voi tavoittaa minkä tahansa kyseisen aliverkon resurssin, jolla ei ole erillistä isäntäpohjaista palomuuria. VPN on suorittanut yhden todennustapahtuman tunnelin muodostuessa ja tehnyt epäsuoran, jatkuvan luottamuspäätöksen: tämä käyttäjä ja tämä laite saavat käyttää koko verkkosegmenttiä istunnon ajan.

Epäsuora luottamus todennuksen jälkeen. VPN-todennus on portti, eikä jatkuva arviointi. Kun portti on ohitettu, luottamusta ei arvioida uudelleen ennen istunnon päättymistä tai aikakatkaisua. Jos käyttäjän tili kompromittoituu istunnon keskellä, jos laite saastuu haittaohjelmalla istunnon aikana tai jos käyttäjä jättää laitteen valvomatta aktiivisen tunnelin kanssa, VPN jatkaa enklaavitason pääsyn myöntämistä, kunnes ylläpitäjä manuaalisesti lopettaa istunnon tai tunneli aikakatkeaa. Puolustusympäristössä, jossa istunnot usein jatkuvat koko työpäivän, tämä on pitkittynyt huomaamattoman riskin ikkuna.

Tasaisen verkon vaikutussäde. VPN sijoittaa käyttäjän verkkosegmentille. Tasainen itä-länsi-yhteys segmentin sisällä tarkoittaa, että kompromittoitunut VPN-istunto voi tavoittaa paitsi sovelluksen, jota käyttäjä aikoi käyttää, myös jokaisen palvelun, tietokannan ja hallintaliittymän aliverkossa. Hyökkääjä, joka varastaa VPN-tunnuksen, saa sillanpään, jonka verkkokantama on sama kuin laillisella käyttäjällä – tai laajempi, koska VPN-politiikka harvoin rajoittaa aliverkon sisäistä liikennettä. Tämä on vaikutussäde-ongelma: yhden tunnuksen kompromittoituminen altistaa koko tasaisen verkkosegmentin.

Kyvyttömyys pakkotuttaa hienojakoista pääsypolitiikkaa. VPN:n pääsypolitiikka on karkeaa: käyttäjällä on joko lupa yhdistää VPN-profiiliin tai ei. Profiili voi määrittää VLAN:n tai aliverkon, mutta sovellus-, resurssi- tai toimintakohtainen politiikan pakkotus tunnelin sisällä ei ole VPN:n kyky. Tunnelin sisäinen pääsynhallinta on delegoitu kunkin sovelluksen omalle todennusmekanismille – joka voi vaihdella ankaruudeltaan rajusti sovellussalkun sisällä. ZTNA siirtää pääsypolitiikan keskitetylle politiikkakoneelle, joka soveltaa yhtenäisiä sääntöjä kaikkiin sovelluksiin ja arvioi ne jokaisen pääsypyynnön kohdalla eikä vain kerran istuntoa muodostettaessa. Siihen liittyvä käsite nollaluottamuksen mikrosegmentointi puolustuksessa käsittelee sivuttaisliikkeen verkossa pääsypäätöksen jälkeen ja täydentää ZTNA-kerrosta reunalla.

ZTNA-arkkitehtuuri: proxy- ja päätepisteagenttimallit

ZTNA-toteutukset jakautuvat kahteen ensisijaiseen arkkitehtuurimalliin sen mukaan, miten liikenteen sieppaus saavutetaan: käänteisproxy- (asiakasohjelmoton) malli ja päätepisteagenttimalli. Molemmilla malleilla on yhteinen looginen rakenne – politiikan pakkotuspiste, identiteettivälittäjä, laiteluottamuspalvelu ja istuntoproxy – mutta ne eroavat siinä, missä sieppaus tapahtuu ja minkä tasoisen laitenäkyvyyden ne saavuttavat.

Käänteisproxy- (asiakasohjelmoton) ZTNA

Käänteisproxymallissa päätepisteeseen ei asenneta ohjelmistoa. ZTNA-palvelu julkaisee proxy-päätepisteen – tyypillisesti URL:n organisaation verkkotunnuksessa – kunkin suojatun sovelluksen eteen. Käyttäjä siirtyy selaimella proxy-URL:ään, todentautuu identiteettivälittäjän kautta (esittää CAC/PIV-tunnukset ja suorittaa monivaiheisen todennuksen) ja saa lyhytikäisen istuntotunnuksen. Proxy vahvistaa tunnuksen jokaisessa pyynnössä ja välittää todennetut, valtuutetut pyynnöt sovelluksen taustajärjestelmään. Käyttäjän laitetta ei koskaan sijoiteta sovellusverkkoon; vain proxyllä on verkkopolku taustajärjestelmään.

Asiakasohjelmottoman mallin ensisijainen rajoitus on protokollakattavuus: se toimii luonnostaan HTTPS-sovelluksille ja pystyy käsittelemään RDP:tä ja SSH:ta selainpohjaisilla asiakasohjelmilla (HTML5 RDP/SSH-yhdyskäytävät), mutta ei tue mielivaltaisia TCP/UDP-protokollia tai paksuja asiakasohjelmia, jotka viestivät ominaisprotokollilla. Laiteluottamuksen näkyvyys on myös rajoitetumpaa ilman agenttia: proxy voi tutkia TLS-asiakasvarmenteita ja selaimen user-agent-merkkijonoja, mutta ei voi varmentaa EDR-terveystilaa tai TPM-attestointia ilman paikallista agenttiapua.

Päätepisteagentti-ZTNA

Agenttimalli asentaa kevyen daemonin hallinnoitavaan päätepisteeseen. Agentti toimii jatkuvasti, sieppaa suojattuihin sovellusosoitteisiin menevän liikenteen (paikallisen virtuaaliverkkosovittimen tai käyttöjärjestelmätason pakettisuodattimen kautta), suorittaa laiteluottamustarkistukset paikallisesti ja muodostaa salatun tunnelin ZTNA-palvelureunalle. Suojattu sovellusliikenne kulkee tämän tunnelin kautta avoimen internetin tai VPN:n sijaan. Sovelluksen taustajärjestelmä vastaanottaa yhteydet ZTNA-proxyltä eikä suoraan päätepisteeltä – taustaverkon osoite ei koskaan paljastu päätepisteelle.

Agenttipohjainen ZTNA tukee mitä tahansa sovellusprotokollaa, mahdollistaa rikkaat laiteluottamussignaalit (EDR-integraatio, TPM-attestointi, paikkausten ajantasaisuus) ja sallii jaetun tunneloinnin, jossa vain suojattu sovellusliikenne kulkee ZTNA-tunnelin kautta ja yleinen internetliikenne poistuu suoraan. Puolustuksen hallinnoituille päätepisteille agenttimalli on vakiintunut valinta, koska luokiteltujen sovellusten pääsyn laitetilavaatimuksia ei voida täyttää ilman agenttitason paikallista näkyvyyttä.

Pilvestä toimitettu vs paikallinen ZTNA

Pilvestä toimitettu ZTNA ajaa hallintatason ja istuntoproxyn monivuokraajaisessa pilvipalvelussa. Tämä malli sopii luokittelemattomille ohjelmille, joissa sovellukset on majoitettu kaupallisiin tai julkishallinnon pilviympäristöihin. Luokitelluille ohjelmille – IL4, IL5 ja ilmaraossa toimiva IL6 – ZTNA-hallintataso on otettava käyttöön akkreditoidun rajan sisällä. Paikallinen ZTNA sijoittaa politiikkakoneen, identiteettivälittäjän ja istuntoproxyn luokitellun enklaavin sisälle. Sovellusliikenne ei koskaan poistu luokitellulta raja-alueelta. Hallintatason ulkoisten riippuvuuksien – varmennevalidoinnin, EDR-terveyskyselyt, identiteettipalveluhaut – on ratkaistava akkreditoidussa verkossa ilman internet-yhteyttä.

Identiteettisignaalit: kuka yhdistää

ZTNA-pääsypäätökset ehdollistetaan yhdistävän käyttäjän identiteettiin. Puolustushenkilöstölle identiteettitodennus ankkuroituu fyysiseen tunnukseen, jonka organisaation henkilöstöjärjestelmä on myöntänyt – CAC- tai PIV-älykorttiin – ja sitä täydennetään hakemistosta saatavilla rooli- ja ryhmäattribuuteilla.

CAC/PIV-varmennevahvistus

CAC (Common Access Card) ja PIV (Personal Identity Verification) -kortti sisältävät X.509-identiteettivarmenteen, jonka organisaation hyväksymä PKI on myöntänyt. ZTNA-varmennevahvistus sisältää: varmenteen esittämisen ZTNA-identiteettivälittäjälle TLS-asiakastodennuksella; varmenneketjun vahvistamisen hyväksyttyä luottamusankkuria vasten (juuri- ja välivarmentajat organisaation luottamusvarastossa); varmenteen tarkistamisen varmennemitätöintiluetteloa (CRL) tai OCSP-vastaajaa vastaan sen varmistamiseksi, ettei sitä ole mitätöity; ja käyttäjätunnuksen (subject distinguished name tai UPN) poimimisen varmenteesta käyttäjäprinsipaalin tunnistamiseksi.

CRL- ja OCSP-saavutettavuus ilmaraossa toimivassa ympäristössä on yleinen operointihäiriöpiste. Jos CRL-jakelupiste on tavoitettavissa vain luokittelemattomasta verkosta ja ZTNA-käyttöönotto on luokitellussa verkossa, varmennemitätöintitarkistukset epäonnistuvat tai aikakatkeavat. Ilmaraossa toimivat ZTNA-käyttöönotot vaativat CRL-välimuistiproxyn luokitellun rajan sisälle, joka synkronoi CRL-päivitykset säännöllisesti cross-domain-siirtomekanismin kautta.

Monivaiheinen todennus ZTNA-pääsyyn

CAC-koodin syöttäminen täyttää useimpien ohjelmien ”jokin mukana oleva plus jokin tiedossa oleva” -monivaiheisen todennuksen vaatimuksen. Korkean arkaluontoisuuden sovellukset voivat kuitenkin vaatia lisätekijän CAC:n lisäksi – TOTP-koodin, push-ilmoituksen rekisteröityyn todennussovellukseen tai laitteistoturvavaimen. ZTNA-politiikkakone voi pakkotuttaa sovelluskohtaisia monivaiheisen todennuksen tasoja: tavallinen CAC-koodi yleisille sovelluksille, CAC-koodi plus TOTP arkaluontoisille komentosovelluksille ja aikarajoitettu sidonnainen ulkoinen hyväksyntätyönkulku etuoikeutetulle hallintapääsylle. Tämä sovelluskohtainen tasoitus ei ole saavutettavissa tasaisella VPN-politiikalla.

Identiteettipalveluintegraatio: LDAP ja Active Directory

Sertifikaattitodennus tunnistaa käyttäjän mutta ei sisällä nykyistä roolia tai ryhmäjäsenyyttä — ne hallitaan hakemistossa ja voivat muuttua itsenäisesti sertifikaatin myöntämisestä. ZTNA-käytäntömoottori kysyy identiteetin tarjoajalta — LDAP:ltä tai Active Directorylta — jokaisen käyttöoikeuspyynnön yhteydessä käyttäjän nykyiset ryhmäjäsenyydet ja roolitehtävät. Selvitetystä tiedosta tulee käytäntösyötteitä: käyttäjän on kuuluttava Active Directoryn ryhmään 'analysts-secret', jotta hän pääsee luokiteltuun analytiikkasovellukseen — sertifikaatin sisällöstä riippumatta. Jos käyttäjä poistetaan ryhmästä Active Directorysta, ZTNA-käytäntömoottori hylkää hänen seuraavan käyttöoikeuspyyntönsä analytiikkasovellukseen ilman sertifikaatin peruuttamista tai VPN-käytännön muuttamista. Tämä attribuuttien varaan rakentuva käyttöoikeuksien hallinta ja siihen kuuluva reaaliaikainen hakemistokysely ovat olennainen osa identiteettihallintaa puolustusorganisaatioissa — juuri sitä ne käyttävät kiristämään käyttöoikeuksien elinkaarhallintaa.

Laitteen luottamussignaalit: mikä laite yhdistää

Käyttäjän identiteetti on välttämätön mutta riittämätön ehto käyttöoikeudelle puolustuksen ZTNA-mallissa. Laillinen käyttäjä murtuneella tai vaatimusten vastaisella laitteella aiheuttaa riskin, jota pelkkä käyttäjän identiteetti ei lievennä. Laitteen luottamuksen arviointi kerää ja arvioi signaaleja yhdistävästä laitteesta käyttäjän identiteettiväitteestä riippumatta.

Laitesertifikaatti

Ensimmäinen laitteen luottamussignaali on koneen sertifikaatti: organisaation laite-PKI:n rekisteröinnin yhteydessä päätelaitteelle myöntämä sertifikaatti. Koneen sertifikaatti osoittaa, että laite rekisteröitiin valtuutetussa MDM- tai laitehallintajärjestelmässä ja että se oli tuolloin hallittu kohde. ZTNA-agentti esittää laitesertifikaatin käyttäjäsertifikaatin rinnalla istuntoa perustettaessa. Käytäntömoottori validoi laitesertifikaatin ketjun laite-PKI:n luottamusankkurista, tarkistaa peruutustilan ja vahvistaa, että sertifikaatin laitetunniste vastaa MDM-inventaarissa kirjattua laitteen identiteettiä.

EDR-terveystila

Laitteessa toimiva päätepisteiden havainnointi- ja reagointiagentti (EDR) ylläpitää reaaliaikaista arviota laitteen uhkatilanteesta. ZTNA-agentti kysyy paikalliselta EDR-agentilta tai EDR-hallinta-alustan API:ltä terveysvahvistuksen: toimiiko EDR-agentti, onko sen uhkatiedotietokanta ajantasainen ja onko karanteenissa tai korjauksessa aktiivisia uhkia? Laite, jonka EDR-signatuuritietokanta on vanhentunut, on käytännössä sokea viimeaikaisille uhkaperheille — ZTNA-käytäntönä olisi kohdella sellaista laitetta vaatimusten vastaisena ja joko evätä käyttöoikeus tai rajoittaa se rajattuun käyttöoikeustasoon EDR-päivityksen ajaksi. Aktiivinen uhkakaranteenitapahtuma istunnon aikana laukeaa jatkuvaan arviointitapahtumaan, mikä voi johtaa istunnon välittömään keskeyttämiseen.

Paikkauksen vaatimustenmukaisuustarkistus

Käyttöjärjestelmän ja sovellusten paikkataso kysytään MDM-alustalta tai ZTNA-agentin paikallisesta asennettujen paikkojen inventaarista. ZTNA-käytäntömoottori vertaa laitteen paikkaustilaa määriteltyyn vähimmäistasoon: esimerkiksi kaikki viimeisen 30 päivän aikana julkaistut kriittiset ja korkean vakavuuden CVE-haavoittuvuudet on paikattava, ennen kuin käyttöoikeus luokiteltuihin sovelluksiin sallitaan. Paikkaamisessa jäljessä olevat laitteet ohjataan korjausilmoitukseen pyydetyn sovelluksen sijaan. Paikkauksen vaatimustenmukaisuustarkistus kattaa myös laitteen hallitun ohjelmistoinventaarin kolmannen osapuolen sovellukset — päivittämätön selain tai PDF-lukija hallitulla laitteella on hyökkäyskanava, vaikka käyttöjärjestelmä olisi täysin päivitetty.

Laitteiston vahvistus TPM 2.0:lla

Puolustuksen hallituille päätelaitteille, joissa on TPM 2.0 -moduuli, ZTNA-agentti voi pyytää TPM-vahvistuslauseketta — kryptografisesti allekirjoitettua mittausta laitteen käynnistysketjusta, jonka TPM tuottaa ja joka voidaan todentaa tunnettua vertailuarvoa vastaavaa luetteloa vasten. Vahvistus osoittaa, että laite käynnistyi valtuutetusta laiteohjelmistosta ja käyttöjärjestelmän kuvasta ja että käynnistysketjua ei ole muutettu viimeisimmän vahvistuksen jälkeen. Tämä hallintakeino on olennainen käynnistystason haittaohjelmien — rootkit- ja bootkit-ohjelmien — havaitsemiseksi; ne ovat käyttöjärjestelmän alapuolella eivätkä näy käyttöjärjestelmän tasolla toimivalle EDR-agentille. TPM-vahvistus edellyttää, että ZTNA-ohjaustaso ylläpitää vertailuarvoluetteloa jokaisesta hallitun kaluston laitemallista; luettelo täytetään laitteen rekisteröinnin yhteydessä ja päivitetään, kun valtuutettuja laiteohjelmistomuutoksia otetaan käyttöön.

Jatkuva käytäntöjen arviointimoottori

Käytäntömoottori on ZTNA-arkkitehtuurin päätöksentekoydin. Se vastaanottaa käyttöoikeuspyyntöjä — istuntovälityspalvelimelta, kun käyttäjä aloittaa yhteyden, ja jatkuvan arviointisilmukasta aktiivisen istunnon ajan — ja palauttaa käyttöoikeuspäätöksen: salli, evää tai vaadi vahvistettua todennusta (lisätodennusta ennen sallimista).

Käytännöt koodina OPA:n ja Regon avulla

Puolustuksen ZTNA-käyttöönotot hyötyvät siitä, että käyttöoikeuskäytäntö kirjoitetaan koodina eikä käyttöliittymässä määriteltynä sääntönä. Open Policy Agent (OPA) ja Rego-käytäntökieli ovat tämän mallin vallitseva kehys. ZTNA:n Rego-käytäntö koodaa kaikki käyttöoikeusehdot deklaratiivisesti: vaaditut käyttäjäryhmät, laitteen vähimmäisvaatimustenmukaisuustaso, sallitut käyttöajat, vaadittu MFA-taso ja riskipistemäärän kynnysarvot. Käytäntöjen versiohallinta on lähdevarastossa, ne tarkastetaan samalla muutoksenhallintaprosessilla kuin sovelluskoodi ja ne otetaan käyttöön OPA-moottoriin CI/CD-putken kautta. Jokaisessa käytäntömuutoksessa on tekijä, tarkastuskirjaus ja käyttöönoton aikaleima, ja se voidaan palauttaa aikaisempaan versioon yhdellä putken peruutuksella. Tämä seurattavuus on merkittävä etu sovelluskohtaisiin palomuurisääntöihin verrattuna, jotka kasaantuvat ilman versiohallintaa.

Kontekstuaaliset käyttöoikeuspäätökset

ZTNA-käytäntöpäätökset voivat sisältää kontekstisignaaleja identiteetin ja laitteen luottamuksen lisäksi. Käyttöajankohdan käytäntö rajoittaa arkaluonteisten sovellusten käytön määrittyihin työaikoihin ja pienentää altistumisikkunaa tunnusten väärinkäytölle normaalin työajan ulkopuolella. Maantieteellistä sijaintia tai verkkolähdettä — mistä käyttäjä yhdistää — voi käytäntömoottori arvioida: luokiteltu sovellus voi sallia käytön vain organisaation hallitsemista verkon ulosmenokohdista tai tietyistä hyväksytyistä etäkäyttöpaikoista. Riskipistemäärän integrointi antaa käytäntömoottorille käyttöönsä numeerisen riskisignaalin, jonka tuottaa käyttäjän ja entiteettien käyttäytymisanalytiikka (UEBA): jos käyttäjän käyttötapa viimeisen 24 tunnin aikana on tuottanut korkean poikkeamariskipistemäärän, käytäntömoottori nostaa käyttöoikeuden kynnystä ja vaatii lisätodennuksen ennen kuin käyttöoikeus arkaluonteisiin sovelluksiin sallitaan.

Istunnon riskin uudelleenarviointi

Perinteinen käyttöoikeuksien hallinta tekee päätöksen istunnon alussa eikä palaa siihen. ZTNA:n jatkuva arviointi arvioi käyttöoikeuspäätöksen uudelleen koko istunnon ajan määritettävissä olevalla kyselyvälillä. Arviointisilmukka kysyy identiteetin tarjoajalta tilamuutoksia (tilin lukitus tai ryhmän peruutus istunnon aloituksen jälkeen), EDR-alustalta uusia uhkatapahtumia laitteessa, laitteen vaatimustenmukaisuuspalvelulta paikkaustilan muutoksia ja riskipistemääröpalvelulta poikkeamapistemäärien muutoksia. Kun muutos ylittää käytännön kynnysarvon, moottori reagoi suhteellisesti: kohtalainen riskin kasvu laukeaa lisätodennushaasteeseen istuntoa keskeyttämättä; kriittinen tapahtuma — tilin lukitus, EDR:n aktiivinen uhka, sertifikaatin peruutus — laukeaa istunnon välittömään päättämiseen. Jatkuva arviointimalli tarkoittaa, että hyökkääjä, joka kompromisoi laitteen istunnon aikana, kohtaa havaintoikkunan, jonka rajaa kyselyväli eikä koko istunnon elinkaari. Samat periaatteet, jotka ohjaavat erioikeuksien hallintaa puolustusorganisaatioissa — oikea-aikainen käyttöoikeus, istunnon tallennus ja reaaliaikainen riskin uudelleenarviointi — pätevät suoraan ZTNA:n jatkuvaan arviointiin korkean etuoikeustason istunnoissa.

ZTNA luokiteltuihin verkkoihin: IL4/IL5-käyttöönotto

Kaupalliset pilvestä tarjottavat ZTNA-palvelut toimivat monivuokralaisessa jaetussa infrastruktuurissa, jota ei ole valtuutettu luokiteltuihin työkuormiin. IL4- (Controlled Unclassified Information) ja IL5-tasojen (National Security Systems) vaikutustasoilla toimivat puolustusohjelmat vaativat ZTNA-käyttöönotomallin, joka pitää ohjaustason toiminnot ja sovellusliikenteen akkreditoidun rajan sisällä.

Paikallinen ZTNA ilmasta eristettyihin luokiteltuihin ympäristöihin

Luokitellun verkon paikallinen ZTNA-käyttöönotto toistaa pilvi-ZTNA-palvelun toiminnalliset komponentit salatussa erillisverkossa. Käytäntömoottori, identiteetin välityspalvelu, istuntovälityspalvelin ja laitteen luottamuspalvelu otetaan käyttöön paikallisina laskentakuormina — joko omistetussa laitteistossa tai luokitellussa Kubernetes-klusterissa. Kaikki ohjaustason riippuvuudet ratkeavat erillisverkon sisällä: identiteetin tarjoaja on luokiteltu Active Directory -instanssi, EDR-hallintakonsoli on käytössä paikallisesti, varmennuspalvelu ja CRL-palvelu toimivat ilmasta eristetyn sisällä eikä yksikään käytäntöarviointikutsu poistu luokitellun verkon rajasta.

Ilmasta eristetyn ZTNA:n toiminnallinen haaste on käytäntöpäivitysten jakelu. Pilvi-ZTNA-palvelussa käytäntömuutokset otetaan käyttöön keskitetysti ja leviävät sekunneissa. Ilmasta eristetyssä ympäristössä käytäntöpäivitykset on toimitettava valtuutetulla ohjelmistonsiirtomekanismilla — tyypillisesti mediansiirtoprosessilla akkreditointirajan yli. Tämä tarkoittaa, että ZTNA-käytäntömuutokset vaativat ennakkosuunnittelua eikä niitä voi ottaa käyttöön pilvikäyttöönnotoissa saatavilla olevalla alle minuutin viiveellä. Ilmasta eristetyn ZTNA-käytännön muutoksenhallintaprosessin on huomioitava tämä toimitusaika, ja kiireellisille käytäntömuutoksille (esimerkiksi murtuneen käyttäjän käyttöoikeuden välitön peruutus) on oltava nopeutettu reitti ohjelman turvallisuussuunnitelmassa määritellyn muutoksenhallintaprosessin läpi.

Luokitusten välisen ZTNA-välityspalvelimen suunnittelu

Jotkut puolustuksen käyttötapaukset edellyttävät, että alemman luokituksen verkossa olevat käyttäjät näkevät tietyn, suodatetun näkymän korkeamman luokituksen järjestelmän tuottamasta datasta — puhdistetun toimintakuvan, luokituksesta vapautetun tiedustelutiivisteen tai vain luku -muotoisen data-syötteen. Luokitusten välinen ZTNA-välityspalvelin toteuttaa tämän yhdistämällä ZTNA:n käyttöoikeuksien hallinnan luokitusten väliseen sisällön tarkasteluun luokitusrajan kohdalla. Välityspalvelin vastaanottaa käyttäjän käyttöoikeuspyynnön luokittelemattomasta verkosta, todentaa identiteetin ja laitteen luottamuksen luokittelemattoman ZTNA-käytäntömoottorin avulla ja hakee sitten luokitellun sovelluksen käyttäjän puolesta luokitusten välisen ratkaisun kautta. CDS-komponentti tarkastelee sovelluksen vastauksen sisältöä, soveltaa datan luokitukseen liittyviä julkaisusääntöjä ja suodattaa tai poistaa osat, joita ei ole valtuutettu julkaisemaan luokittelemattoman verkon pyytäjälle. Vain suodatettu vastaus palautetaan käyttäjän istuntoon luokittelemattomassa verkossa. Välityspalvelimen on oltava akkreditointi sekä molempien verkkojen ATO-hyväksynnän että luokitusten välisen valtuutuksen osana, ja ZTNA + CDS -arkkitehtuuri on kuvattava nimenomaisesti yhdistettynä hallintakeinona.

Siirtyminen vanhasta VPN:stä ZTNA:han

Siirtymä VPN:stä ZTNA:han puolustusohjelmassa on operatiivinen siirtymä, jonka on säilytettävä käyttöoikeuksien jatkuvuus tehtävän kannalta kriittisille sovelluksille ja samalla kiristettävä käyttöoikeuksien hallintaa vaiheittain. Vaiheittainen siirtymästrategia, jossa VPN ja ZTNA toimivat rinnakkain siirtymäkauden ajan, on vakiintunut lähestymistapa.

Vaiheittainen siirtymästrategia

Siirtymä etenee kolmessa vaiheessa. Ensimmäisessä vaiheessa ZTNA-infrastruktuuri otetaan käyttöön ja validoidaan identiteetti- ja laitteen luottamusintegraatiota varten, mutta yhtäkään sovellusta ei oteta mukaan ja käyttäjät käyttävät kaikkia sovelluksia edelleen VPN:n kautta. Kokeilukäyttäjäryhmä — tyypillisesti IT- ja turvallisuustiimi — testaa ZTNA-käyttöoikeuden matalan kriittisyyden sovellukseen ja validoi koko ketjun ennen tehtäväkäyttäjien mukaan ottamista. Toisessa vaiheessa sovellukset otetaan ZTNA:han tärkeysjärjestyksessä. Tässä vaiheessa VPN pysyy saatavilla varapolkkana sovelluksille, joita ei vielä ole otettu mukaan. Käyttäjät koulutetaan ZTNA-käyttöportaaliin ja agenttiin ennen kuin heidän ensisijaiset sovelluksensa siirtyvät ZTNA:han. Kolmannessa vaiheessa, kun kaikki laajuuteen kuuluvat sovellukset on otettu mukaan ja kokeilukäyttäjäkanta on validoinut käyttöoikeudet, VPN-käyttöoikeus peruutetaan siirretylle käyttäjäkannalle. VPN-yhdyskäytävä pysyy käytettävissä vain ZTNA-laajuudesta pois jätetyille sovelluksille (jos niitä on) viimeisen vaiheen ajan, ja se poistetaan käytöstä, kun loput sovellukset saadaan otettua mukaan.

Sovellusten käyttöönottamisjärjestys

Sovellukset otetaan ZTNA:han järjestyksessä, joka minimoi riskin ja hyödyntää varhaisten käyttöönottojen opit ennen monimutkaisten tapausten käsittelyä. Aloita sisäisistä verkkoportaaleista ja kojelaudoista — HTTPS-sovelluksista, joiden selainpohjaiset käyttöliittymät toimivat luontevasti käänteisen välityspalvelimen ZTNA:n kanssa ja joilla on laajat käyttäjäkunnat, jotka antavat palautetta nopeasti. Siirry seuraavaksi tuottavuussovelluksiin: sähköpostin verkkokäyttöliittymät, dokumenttien hallintaportaalit, sisäiset wikit. Ota sitten käsittelyyn sovellusluokat, jotka edellyttävät agenttimallia: RDP-yhteydellä käytettävät Windows-palvelimet, SSH-yhteydellä käytettävät Linux-järjestelmät, paksut C2- ja tehtäväsovellukset. Jätä viimeisiksi monimutkaisimmat integraatiot: sovellukset, joissa on epästandardit todennusmekanismit, korkean kriittisyyden reaaliaikajärjestelmät ja kaikki sovellukset, jotka nojaavat tällä hetkellä VPN:n IP-pohjaiseen käyttöoikeuksien hallintaan sovellustason todennuksen sijaan.

Käyttäjien koulutus ZTNA-käyttömalleihin

ZTNA-käyttökokemus eroaa VPN:stä olennaisesti. VPN:ään tottuneet käyttäjät yhdistävät kerran päivän alussa ja käyttävät kaikkia sovelluksia läpinäkyvästi loppupäivän ajan. ZTNA:ssa käyttäjä käyttää sovelluksia ZTNA-portaalin kautta tai agentin sieppaamien yhteyksien kautta, ja hän voi kohdata päivän aikana lisätodennushaasteita, jos jatkuva arviointi havaitsee riskin muutoksen. Koulutuksen on käsiteltävä kolme käyttäytymismuutosta. Ensinnä käyttöportaali: minne navigoidaan sovellusten löytämiseksi ja miten todennus CAC-kortilla tehdään. Toiseksi agentti: miten ZTNA-agentti näkyy ilmoitusalueella, mitä sen tilaindikaattorit tarkoittavat ja miten ongelmista raportoidaan. Kolmanneksi lisätodennus: miltä istunnon keskellä esiintyvä MFA-haaste näyttää (jotta käyttäjät eivät pidä laillista lisätodennuskehotetta tietojenkalasteluyrityksenä) ja miten se suoritetaan loppuun. Ohjelmat, jotka panostavat käyttäjien koulutukseen ennen ensimmäisen tehtäväkäyttäjän mukaan ottamista, näkevät selvästi pienemmän tukipyyntömäärän ja nopeamman omaksumisen kuin ohjelmat, jotka ottavat ZTNA:n käyttöön ilman koulutusohjelmaa.