ZTNA voor defensie: zero trust-netwerktoegang en beleidsengine

De perimeter-VPN is drie decennia lang de belangrijkste toegangscontrole op afstand geweest voor defensienetwerken. Een gebruiker authenticeert bij de VPN-gateway, er wordt een tunnel opgezet en de gebruiker krijgt brede toegang op netwerkniveau tot resources binnen de perimeter. Dit model was ontworpen voor een wereld waarin applicaties in één datacenter stonden en gebruikers verbinding maakten vanaf locaties die de organisatie beheerde. In een moderne defensieomgeving — waar workloads soevereine cloud, tactische edge en air-gapped geclassificeerde enclaves overspannen, en waar gebruikers vanaf beheerde en semi-beheerde apparaten vanaf meerdere locaties verbinding maken — introduceert de VPN-architectuur risico's die haar ontwerpers nooit voorzien hadden. Zero trust-netwerktoegang (ZTNA) is de architecturale vervanging: toegang op applicatieniveau, bemiddeld via een identity-aware proxy en voorwaardelijk gemaakt door continue verificatie van wie er verbindt en welk apparaat wordt gebruikt. Dit artikel onderzoekt de engineeringmechanica van ZTNA voor defensie: hoe identiteits- en apparaatsignalen worden verzameld en geëvalueerd, hoe de beleidsengine toegangsbeslissingen produceert en hoe ZTNA wordt ingezet over het hele spectrum, van ongeclassificeerde netwerken tot air-gapped geclassificeerde enclaves.

Waarom legacy VPN faalt voor zero trust bij defensie

Het fundamentele probleem met VPN in een zero trust-context is niet de versleuteling — VPN-tunnels zijn cryptografisch degelijk. Het probleem is wat de VPN verleent nadat de versleuteling tot stand is gebracht. Wanneer een gebruiker authenticeert bij een VPN-gateway en de tunnel opkomt, ontvangt het apparaat van de gebruiker een netwerkadres binnen de defensie-enclave en kan het elke resource op dat subnet bereiken die geen afzonderlijke op de host gebaseerde firewall heeft. De VPN heeft één authenticatie-gebeurtenis uitgevoerd bij het opzetten van de tunnel en heeft een impliciete, aanhoudende vertrouwensbeslissing genomen: deze gebruiker en dit apparaat mogen gedurende de sessie het volledige netwerksegment benaderen.

Impliciet vertrouwen na authenticatie. VPN-authenticatie is een poort, geen continue evaluatie. Zodra de poort is gepasseerd, wordt vertrouwen niet her-evalueerd tot de sessie eindigt of er een timeout optreedt. Als het account van de gebruiker halverwege de sessie wordt gecompromitteerd, als het apparaat tijdens de sessie met malware wordt besmet of als de gebruiker het apparaat onbeheerd laat met een actieve tunnel, blijft de VPN toegang op enclave-niveau leveren tot een beheerder de sessie handmatig beëindigt of de tunnel door een timeout verloopt. In een defensieomgeving waar sessieduren vaak een volledige werkdag beslaan, is dit een verlengd venster van onopgemerkt risico.

Explosie-radius van een vlak netwerk. Een VPN plaatst de gebruiker op een netwerksegment. Vlakke oost-west-connectiviteit binnen dat segment betekent dat een gecompromitteerde VPN-sessie niet alleen de applicatie kan bereiken die de gebruiker wilde benaderen, maar elke service, database en beheerinterface op het subnet. De aanvaller die een VPN-credential steelt, verkrijgt een bruggenhoofd met hetzelfde netwerkbereik als de legitieme gebruiker — of breder, omdat het VPN-beleid verkeer binnen het subnet zelden beperkt. Dit is het probleem van de explosie-radius: het compromitteren van één credential stelt het hele vlakke netwerksegment bloot.

Onvermogen tot fijnmazige toegangscontrole. VPN-toegangsbeleid is grof: een gebruiker mag wel of niet met een VPN-profiel verbinden. Het profiel kan een VLAN of subnet toewijzen, maar beleidshandhaving per applicatie, per resource of per actie binnen de tunnel is geen VPN-mogelijkheid. Toegangscontrole binnen de tunnel is gedelegeerd aan de eigen authenticatiemechanismen van elke applicatie — die in strengheid sterk kunnen verschillen over de applicatieportefeuille. ZTNA verplaatst toegangsbeleid naar een gecentraliseerde beleidsengine die consistente regels toepast over elke applicatie, geëvalueerd op het punt van elk toegangsverzoek in plaats van eenmaal bij het opzetten van de sessie. Het verwante concept zero trust-microsegmentatie voor defensie adresseert laterale beweging binnen het netwerk na de toegangsbeslissing en vormt zo een aanvulling op de ZTNA-laag op de perimeter.

ZTNA-architectuur: proxy- versus endpoint-agentmodellen

ZTNA-implementaties verdelen zich in twee primaire architecturale patronen, gebaseerd op hoe verkeersonderschepping wordt bereikt: het reverse proxy-model (clientloos) en het endpoint-agentmodel. Beide modellen delen een gemeenschappelijke logische structuur — een handhavingspunt voor beleid, een identity broker, een device trust-service en een sessieproxy — maar verschillen in waar de onderschepping plaatsvindt en welk niveau van apparaatzicht zij kunnen bereiken.

Reverse proxy (clientloze) ZTNA

In het reverse proxy-model wordt geen software op het endpoint geïnstalleerd. De ZTNA-service publiceert een proxy-endpoint — doorgaans een URL in het domein van de organisatie — die vóór elke beschermde applicatie staat. De gebruiker navigeert in een browser naar de proxy-URL, authenticeert via de identity broker (met CAC/PIV-credentials en het afronden van MFA) en ontvangt een kort geldig sessietoken. De proxy valideert het token bij elk verzoek en stuurt geauthenticeerde, geautoriseerde verzoeken door naar de applicatie-backend. Het apparaat van de gebruiker komt nooit op het applicatienetwerk; alleen de proxy heeft een netwerkpad naar de backend.

De primaire beperking van het clientloze model is protocoldekking: het werkt van nature voor HTTPS-applicaties en kan RDP en SSH afhandelen via browsergebaseerde clients (HTML5 RDP/SSH-gateways), maar ondersteunt geen willekeurige TCP/UDP-protocollen of thick-client-applicaties die over propriëtaire protocollen communiceren. Ook is het zicht op device trust beperkter zonder agent: de proxy kan TLS-clientcertificaten en browser-User-Agent-strings inspecteren, maar kan de EDR-status of TPM-attestatie niet verifiëren zonder hulp van een lokale agent.

Endpoint-agent ZTNA

Het agentmodel installeert een lichtgewicht daemon op het beheerde endpoint. De agent draait continu, onderschept verkeer dat bestemd is voor beschermde applicatieadressen (via een lokale virtuele netwerkadapter of een packetfilter op OS-niveau), voert device trust-controles lokaal uit en zet een versleutelde tunnel op naar de ZTNA-service-edge. Verkeer van beschermde applicaties verloopt door deze tunnel in plaats van over het open internet of een VPN. De applicatie-backend ontvangt verbindingen van de ZTNA-proxy in plaats van rechtstreeks van het endpoint — het netwerkadres van de backend wordt nooit aan het endpoint blootgesteld.

Agent-gebaseerde ZTNA ondersteunt elk applicatieprotocol, maakt rijke device trust-signalen mogelijk (EDR-integratie, TPM-attestatie, patch-compliance) en staat split-tunnel-routing toe, waarbij alleen beschermd applicatieverkeer door de ZTNA-tunnel gaat en algemeen internetverkeer direct naar buiten loopt. Voor beheerde defensie-endpoints is het agentmodel de standaardkeuze, omdat aan de apparaatpostuureisen voor toegang tot geclassificeerde applicaties niet kan worden voldaan zonder zicht op agentniveau.

Cloud-geleverde versus on-premises ZTNA

Cloud-geleverde ZTNA draait de control plane en sessieproxy in een multi-tenant cloudservice. Dit model past bij ongeclassificeerde programma's waar applicaties in commerciële of overheidscloudomgevingen worden gehost. Voor geclassificeerde programma's — IL4, IL5 en air-gapped IL6 — moet de ZTNA-control plane binnen de geaccrediteerde grens worden ingezet. On-premises ZTNA plaatst de beleidsengine, identity broker en sessieproxy binnen de geclassificeerde enclave. Applicatieverkeer verlaat de geclassificeerde grens nooit. De externe afhankelijkheden van de control plane — certificaatvalidatie, EDR-statusbevragingen, identity provider-lookups — moeten allemaal binnen het geaccrediteerde netwerk worden opgelost zonder internettoegang.

Identiteitssignalen: wie er verbindt

ZTNA-toegangsbeslissingen zijn voorwaardelijk gemaakt aan de identiteit van de verbindende gebruiker. Voor defensiepersoneel verankert identiteitsverificatie in de fysieke credential die door het personeelssysteem van de organisatie is uitgegeven — de CAC- of PIV-smartcard — en wordt deze verrijkt met rol- en groepsattributen uit de directory.

CAC/PIV-certificaatverificatie

De CAC (Common Access Card) en de PIV-kaart (Personal Identity Verification) dragen een X.509-identiteitscertificaat dat door de goedgekeurde PKI van de organisatie is uitgegeven. ZTNA-certificaatverificatie omvat: het presenteren van het certificaat aan de ZTNA-identity broker via TLS-clientauthenticatie; het valideren van de certificaatketen tegen de goedgekeurde trust anchor (de root- en intermediate-Ca's in de trust store van de organisatie); het controleren van het certificaat tegen de certificaatintrekkingslijst (CRL) of OCSP-responder om te bevestigen dat het niet is ingetrokken; en het extraheren van de subject distinguished name of UPN uit het certificaat om de gebruikersprincipal te identificeren.

De beschikbaarheid van CRL en OCSP binnen een air-gapped omgeving is een veelvoorkomend operationeel faalpunt. Als het CRL-distributiepunt alleen vanaf het ongeclassificeerde netwerk bereikbaar is en de ZTNA-implementatie op een geclassificeerd netwerk staat, falen certificaatintrekkingscontroles of lopen ze op een timeout. Air-gapped ZTNA-implementaties vereisen een caching-proxy voor CRL's binnen de geclassificeerde grens, die periodiek CRL-updates synchroniseert via het cross-domain overdrachtsmechanisme.

Multi-factor authenticatie voor ZTNA-toegang

Het intoetsen van de CAC-PIN voldoet voor de meeste programma's aan de MFA-eis “iets dat u hebt plus iets dat u weet”. Applicaties die als hooggevoelig zijn aangemerkt, kunnen echter een extra factor naast de CAC vereisen — een TOTP-code, een pushmelding naar een geregistreerde authenticator-app of een hardware security key. De ZTNA-beleidsengine kan MFA-niveau-eisen per applicatie afdwingen: standaard CAC-PIN voor algemene applicaties, CAC-PIN plus TOTP voor gevoelige commandoapplicaties en een tijdgebonden out-of-band goedkeuringsworkflow voor bevoorrechte administratieve toegang. Deze MFA-niveaulaag per applicatie is met een vlak VPN-beleid niet te bereiken.

Identity provider-integratie: LDAP en Active Directory

Certificaatauthenticatie identificeert de gebruikersprincipal, maar draagt geen actueel rol- of groepslidmaatschap — die worden in de directory beheerd en kunnen onafhankelijk van certificaatuitgifte veranderen. De ZTNA-beleidsengine bevraagt de identity provider — LDAP of Active Directory — op het moment van elk toegangsverzoek om de actuele groepslidmaatschappen en roltoewijzingen van de gebruiker op te lossen. De opgeloste attributen worden beleidsinvoer: een gebruiker moet lid zijn van de Active Directory-groep 'analysts-secret' om de geclassificeerde analyseapplicatie te benaderen, ongeacht wat zijn certificaat zegt. Als de gebruiker uit de groep in Active Directory wordt verwijderd, wordt zijn volgende toegangsverzoek tot de analyseapplicatie geweigerd door de ZTNA-beleidsengine, zonder dat certificaatintrekking of een VPN-beleidswijziging nodig is. Deze attribuutgebaseerde toegangscontrole, gedragen door realtime directorybevragingen, is een fundamentele capaciteit van identiteitsgovernance die defensieorganisaties toepassen om de levenscyclus van toegangscontrole aan te scherpen.

Device trust-signalen: welk apparaat er verbindt

Gebruikersidentiteit is een noodzakelijke maar niet voldoende voorwaarde voor toegang in een ZTNA-model voor defensie. Een legitieme gebruiker op een gecomprometteerd of niet-conform apparaat brengt risico met zich mee dat gebruikersidentiteit alleen niet kan mitigeren. De evaluatie van device trust verzamelt en beoordeelt signalen over het verbindende apparaat, onafhankelijk van de identiteitsbewering van de gebruiker.

Apparaatcertificaat

Het eerste device trust-signaal is het machinecertificaat: een certificaat dat door de apparaat-PKI van de organisatie aan het endpoint wordt uitgegeven op het moment van inschrijving. Het machinecertificaat bewijst dat het apparaat is ingeschreven door een geautoriseerd MDM- of apparaatbeheersysteem en toen een beheerd asset was. De ZTNA-agent presenteert het apparaatcertificaat naast het gebruikerscertificaat bij het opzetten van de sessie. De beleidsengine valideert de certificaatketen van het apparaat tegen de trust anchor van de apparaat-PKI, controleert de intrekkingsstatus en bevestigt dat de apparaat-id in het certificaat overeenkomt met de apparaatidentiteit die in de MDM-inventaris is vastgelegd.

EDR-status

De EDR-agent (endpoint detection and response) die op het apparaat draait, handhaaft een realtime beoordeling van de dreigingsstatus van het apparaat. De ZTNA-agent bevraagt de lokale EDR-agent of de API van het EDR-beheerplatform voor een statusattestatie: draait de EDR-agent, is de database met dreigingsinformatie actueel en zijn er actieve dreigingen in quarantaine of remediatie? Een apparaat met een verouderde EDR-signaturedatabase is feitelijk blind voor recente dreigingsfamilies — het ZTNA-beleid moet zo'n apparaat als niet-conform behandelen en de toegang weigeren of beperken tot een beperkt toegangsniveau in afwachting van een EDR-update. Een actieve quarantainegebeurtenis van een dreiging tijdens een sessie triggert een continue-evaluatiegebeurtenis die tot onmiddellijke schorsing van de sessie kan leiden.

Patch-compliancecontrole

Het patchniveau van besturingssysteem en applicaties wordt opgevraagd bij het MDM-platform of uit de lokale inventaris van geïnstalleerde patches van de ZTNA-agent. De ZTNA-beleidsengine vergelijkt de patchstatus van het apparaat met een gedefinieerd minimum: bijvoorbeeld alle kritieke en hoog-risico CVE's die in de laatste 30 dagen zijn gepubliceerd moeten gepatcht zijn voordat toegang tot geclassificeerde applicaties is toegestaan. Apparaten die achterlopen op patchen worden doorgestuurd naar een remediation-melding in plaats van naar de gevraagde applicatie. De patch-compliancecontrole bestrijkt ook externe applicaties in de beheerde software-inventaris van het apparaat — een ongepatchte webbrowser of pdf-lezer op een beheerd apparaat is een exploitatievector, ook als het OS volledig is gepatcht.

Hardware-attestatie via TPM 2.0

Voor beheerde defensie-endpoints met een TPM 2.0-module kan de ZTNA-agent een TPM-attestation quote aanvragen — een cryptografisch ondertekende meting van de opstartketen van het apparaat, geproduceerd door de TPM en verifieerbaar tegen een bekend-goed referentiemanifest. De attestatie bewijst dat het apparaat startte vanaf een geautoriseerde firmware- en OS-image en dat de opstartketen sinds de laatste attestatie niet is gemanipuleerd. Deze controle is relevant voor het detecteren van malware op opstartniveau — rootkits en bootkits die onder het OS voortbestaan en niet door een EDR-agent op OS-niveau worden gedetecteerd. TPM-attestatie vereist dat de ZTNA-control plane een referentiemanifest heeft voor elk apparaatmodel in het beheerde wagenpark; het manifest wordt gevuld tijdens apparaatinschrijving en bijgewerkt wanneer geautoriseerde firmwarewijzigingen worden uitgerold.

Engine voor continue beleidsevaluatie

De beleidsengine is de beslissende kern van de ZTNA-architectuur. Zij ontvangt toegangsverzoeken — van de sessieproxy wanneer een gebruiker een verbinding initieert, en van de continue-evaluatielus gedurende een actieve sessie — en retourneert een toegangsbeslissing: toestaan, weigeren of step-up (extra authenticatie vereisen voordat wordt toegestaan).

Policy-as-code met OPA en Rego

ZTNA-implementaties bij defensie profiteren ervan toegangsbeleid als code uit te drukken in plaats van via de GUI geconfigureerde regels. Open Policy Agent (OPA) met de beleidstaal Rego is het dominante framework voor dit patroon. Een Rego-beleid voor ZTNA codeert declaratief alle toegangscondities: de vereiste gebruikersgroepen, het minimale apparaat-complianceniveau, de toegestane toegangstijden, het vereiste MFA-niveau en de drempelwaarde van de risicoscore. Beleidsregels zijn versiebeheerd in een bronrepository, worden door hetzelfde wijzigingscontroleproces als applicatiecode gereviewd en via een CI/CD-pipeline naar de OPA-engine uitgerold. Elke beleidswijziging heeft een auteur, een reviewrecord en een deployment-tijdstempel, en kan met één pipeline-revert naar een eerdere versie worden teruggedraaid. Deze auditbaarheid is een materieel voordeel boven firewallregels per applicatie die zich zonder versiebeheer opstapelen.

Contextbewuste toegangsbeslissingen

ZTNA-beleidsbeslissingen kunnen contextuele signalen opnemen die verder gaan dan identiteit en device trust. Tijdsbeleid beperkt toegang tot gevoelige applicaties tot gedefinieerde vensters van werktijden, waarmee het blootstellingsvenster voor credentialmisbruik buiten normale werktijden afneemt. Geolocatie- of netwerkbronbeleid — vanwaar de gebruiker verbindt — kan door de beleidsengine worden geëvalueerd: een geclassificeerde applicatie kan toegang alleen toestaan vanaf door de organisatie beheerde netwerk-egresspunten of vanaf specifieke goedgekeurde locaties voor toegang op afstand. Risicoscore-integratie laat de beleidsengine een numeriek risicosignaal consumeren dat door een UEBA-platform (user and entity behavior analytics) wordt geproduceerd: als het toegangspatroon van de gebruiker in de laatste 24 uur een hoge anomalierisicoscore heeft opgeleverd, verhoogt de beleidsengine de toegangsdrempel en vereist step-up MFA voordat toegang tot gevoelige applicaties wordt verleend.

Her-evaluatie van sessierisico

Traditionele toegangscontrole neemt een beslissing bij het begin van de sessie en herziet die niet. Continue evaluatie bij ZTNA herbeoordeelt de toegangsbeslissing gedurende de sessie op een configureerbaar pollinginterval. De evaluatielus bevraagt de identity provider voor accountstatuswijzigingen (accountvergrendeling of groepsintrekking sinds het begin van de sessie), het EDR-platform voor nieuwe dreigingsgebeurtenissen op het apparaat, de compliance-service voor patchstatuswijzigingen en de risicoscore-service voor wijzigingen in de anomaliescore. Wanneer een wijziging een beleidsdrempel overschrijdt, reageert de engine evenredig: een matige risicoverhoging triggert een step-up MFA-uitdaging zonder de sessie te beëindigen; een kritieke gebeurtenis — accountvergrendeling, actieve EDR-dreiging, certificaatintrekking — triggert onmiddellijke beëindiging van de sessie. Het continue-evaluatiemodel betekent dat een aanvaller die een apparaat halverwege de sessie compromitteert een detectievenster krijgt dat wordt begrensd door het pollinginterval in plaats van door de volledige sessielevensduur. Dezelfde principes die programma's voor beheer van bevoorrechte toegang bij defensie sturen — just-in-time-toegang, sessieopname en realtime risicoher-evaluatie — zijn rechtstreeks van toepassing op het ontwerp van de continue evaluatie van ZTNA voor sessies met hoge bevoegdheden.

ZTNA voor geclassificeerde netwerken: IL4/IL5-implementatie

Commerciële cloud-geleverde ZTNA-diensten opereren in multi-tenant gedeelde infrastructuur die niet is geautoriseerd voor geclassificeerde workloads. Defensieprogramma's die opereren op impactniveau IL4 (Controlled Unclassified Information) en IL5 (National Security Systems) vereisen een ZTNA-implementatiemodel dat de bewerkingen van de control plane en het applicatieverkeer binnen de geaccrediteerde grens houdt.

On-premises ZTNA voor air-gapped geclassificeerde omgevingen

Een on-premises ZTNA-implementatie voor een geclassificeerd netwerk repliceert de functionele componenten van een cloud-ZTNA-dienst binnen de geclassificeerde enclave. De beleidsengine, identity broker, sessieproxy en device trust-service worden allemaal ingezet als on-premises compute-workloads — op dedicated hardware of binnen het geclassificeerde Kubernetes-cluster. Alle afhankelijkheden van de control plane lossen binnen de enclave op: de identity provider is de geclassificeerde Active Directory-instantie, de EDR-beheerconsole is on-premises ingezet, de certificaatautoriteit en CRL-dienst opereren binnen de air gap en geen enkele beleidsevaluatie-aanroep verlaat de grens van het geclassificeerde netwerk.

De operationele uitdaging die uniek is voor air-gapped ZTNA is de distributie van beleidsupdates. In een cloud-ZTNA-dienst worden beleidswijzigingen centraal uitgerold en planten zich binnen seconden voort. In een air-gapped omgeving moeten beleidsupdates worden aangeleverd via het geautoriseerde software-overdrachtsmechanisme — doorgaans een media-overdrachtsproces door de accreditatiegrens. Dit betekent dat ZTNA-beleidswijzigingen vooruitplanning vereisen en niet kunnen worden toegepast met de sub-minuutlatentie die cloud-implementaties bieden. Het wijzigingscontroleproces voor air-gapped ZTNA-beleid moet deze doorlooptijd meenemen, en noodbeleidswijzigingen (bijvoorbeeld onmiddellijke intrekking van de toegang van een gecompromitteerde gebruiker) moeten een versneld traject hebben door het wijzigingscontroleproces dat in het beveiligingsplan van het programma is gedefinieerd.

Ontwerp van een cross-domain ZTNA-proxy

Sommige defensie-gebruiksscenario's vereisen dat gebruikers op een netwerk met lagere classificatie een specifieke, gefilterde weergave benaderen van gegevens die door een systeem met hogere classificatie worden geproduceerd — een gezuiverd operationeel beeld, een gedeclassificeerde inlichtingensamenvatting of een alleen-lezen datafeed. Een cross-domain ZTNA-proxy lost dit op door ZTNA-toegangscontrole te combineren met cross-domain inhoudsinspectie op de classificatiegrens. De proxy ontvangt het toegangsverzoek van de gebruiker vanaf het ongeclassificeerde netwerk, verifieert identiteit en device trust tegen de ongeclassificeerde ZTNA-beleidsengine, en bevraagt daarna de geclassificeerde applicatie namens de gebruiker via de cross-domain solution. Het CDS-onderdeel inspecteert de inhoud van het applicatie-antwoord, past de release-regels voor de classificatie van de gegevens toe en filtert of redigeert elementen die niet voor vrijgave aan de ongeclassificeerde verzoeker zijn geautoriseerd. Alleen het gefilterde antwoord keert terug naar de gebruikssessie op het ongeclassificeerde netwerk. De proxy moet als onderdeel van beide netwerk-ATO's en de cross-domain autorisatie zijn geaccrediteerd, met de ZTNA + CDS-architectuur expliciet beschreven als één gecombineerde controle.

Migratie van legacy VPN naar ZTNA

VPN-naar-ZTNA-migratie in een defensieprogramma is een operationele overgang die toegangscontinuïteit voor missiekritieke applicaties moet bewaren terwijl de toegangscontrole stap voor stap wordt aangescherpt. Een gefaseerde migratiestrategie die VPN en ZTNA gedurende de overgangsperiode parallel laat draaien, is de standaardaanpak.

Gefaseerde migratiestrategie

De migratie verloopt in drie fasen. In de eerste fase wordt de ZTNA-infrastructuur ingezet en gevalideerd voor identiteits- en device trust-integratie, maar wordt nog geen applicatie overgezet en benaderen gebruikers alle applicaties nog via VPN. Een pilotgebruikersgroep — doorgaans het IT- en beveiligingsteam — test ZTNA-toegang tot een applicatie met lage criticaliteit om de end-to-endstroom te valideren voordat missiegebruikers betrokken worden. In de tweede fase worden applicaties in volgorde van prioriteit aan ZTNA toegevoegd. Gedurende deze fase blijft de VPN beschikbaar als fallback voor applicaties die nog niet zijn overgezet. Gebruikers worden getraind op het ZTNA-toegangsportaal en de agent voordat hun primaire applicaties naar ZTNA verhuizen. In de derde fase wordt, zodra alle applicaties binnen de scope zijn overgezet en de pilotpopulatie de toegang heeft gevalideerd, de VPN-toegang ingetrokken voor de gemigreerde gebruikerspopulatie. De VPN-gateway blijft in de laatste fase alleen beschikbaar voor applicaties die buiten de ZTNA-scope vallen (indien aanwezig), en wordt ontmanteld zodra de resterende applicaties de overgang afronden.

Overzetvolgorde voor applicaties

Applicaties worden in een volgorde aan ZTNA toegevoegd die is ontworpen om risico te minimaliseren en van vroege overzettingen te leren voordat complexe gevallen worden aangepakt. Begin met interne webportalen en dashboards — HTTPS-applicaties met browsergebaseerde frontends die van nature werken met reverse proxy-ZTNA en brede gebruikerspopulaties hebben die snel feedback kunnen geven. Ga daarna naar productiviteitsapplicaties: webinterfaces voor e-mail, documentbeheerportalen, interne wiki's. Pak daarna de applicatiecategorieën aan die het agentmodel vereisen: via RDP benaderde Windows-servers, via SSH benaderde Linux-systemen, thick-client C2- of missieapplicaties. Bewaar voor het laatst de complexste integraties: applicaties met niet-standaard authenticatiemechanismen, hoogkritieke realtime systemen en elke applicatie die momenteel afhankelijk is van op VPN-IP gebaseerde toegangscontrole in plaats van authenticatie op applicatielaag.

Gebruikerstraining voor ZTNA-toegangspatronen

De ZTNA-gebruikerservaring verschilt wezenlijk van VPN. Gebruikers die aan VPN gewend zijn, verbinden één keer aan het begin van de dag en benaderen de rest van de dag transparant alle applicaties. Met ZTNA benadert de gebruiker applicaties via het ZTNA-portaal of via agent-onderschepte verbindingen en kan hij gedurende de dag step-up MFA-uitdagingen tegenkomen wanneer continue evaluatie een risicowijziging detecteert. Training moet drie gedragsveranderingen adresseren. Ten eerste het toegangsportaal: waarheen navigeren om applicaties te vinden en hoe authenticeren via CAC. Ten tweede de agent: hoe de ZTNA-agent in het systeemvak verschijnt, wat zijn statusindicatoren betekenen en hoe problemen te melden. Ten derde step-up-authenticatie: hoe een MFA-uitdaging midden in een sessie eruitziet (zodat gebruikers een legitieme step-up-prompt niet voor een phishingpoging aanzien) en hoe deze af te ronden. Programma's die in gebruikerstraining investeren voordat de eerste missiegebruiker wordt overgezet, zien significant lagere volumes aan helpdesktickets en snellere adoptie dan programma's die ZTNA uitrollen zonder trainingsprogramma.