ZTNA pentru apărare: proxy identity-aware și motor de politici

VPN-ul de perimetru a fost principalul control de acces la distanță pentru rețelele de apărare timp de trei decenii. Un utilizator se autentifică la gateway-ul VPN, se stabilește un tunel, iar utilizatorul obține acces larg, la nivel de rețea, la resursele din interiorul perimetrului. Acest model a fost proiectat pentru o lume în care aplicațiile erau găzduite într-un singur centru de date, iar utilizatorii se conectau din amplasamente controlate de organizație. Într-un mediu modern de apărare — în care sarcinile de lucru se întind pe cloud suveran, marginea tactică și enclave clasificate cu separare fizică, și în care utilizatorii se conectează de pe dispozitive gestionate și semigestionate din mai multe locații — arhitectura VPN introduce riscuri pe care proiectanții săi nu le-au anticipat niciodată. Accesul zero trust la rețea (ZTNA) este înlocuitorul arhitectural: acces la nivel de aplicație intermediat printr-un proxy identity-aware, condiționat de verificarea continuă a cine se conectează și ce dispozitiv folosește. Acest articol examinează mecanica inginerească a ZTNA pentru apărare: cum sunt colectate și evaluate semnalele de identitate și de dispozitiv, cum produce motorul de politici decizii de acces și cum se implementează ZTNA pe tot spectrul, de la rețele neclasificate până la enclave clasificate cu separare fizică.

De ce eșuează VPN-ul tradițional pentru zero trust în apărare

Problema fundamentală a VPN într-un context zero trust nu este criptarea — tunelurile VPN sunt criptografic solide. Problema este ceea ce acordă VPN-ul după ce criptarea este stabilită. Când un utilizator se autentifică la un gateway VPN și tunelul se stabilește, dispozitivul utilizatorului primește o adresă de rețea în interiorul enclavei de apărare și poate ajunge la orice resursă din acea subrețea care nu are un firewall separat la nivel de gazdă. VPN-ul a efectuat un singur eveniment de autentificare la stabilirea tunelului și a luat o decizie de încredere implicită și susținută: acest utilizator și acest dispozitiv pot accesa întregul segment de rețea pe durata sesiunii.

Încredere implicită după autentificare. Autentificarea VPN este o poartă, nu o evaluare continuă. Odată poarta trecută, încrederea nu este reevaluată până când sesiunea nu se încheie sau are loc un timeout. Dacă contul utilizatorului este compromis în timpul sesiunii, dacă dispozitivul este infectat cu malware în timpul sesiunii sau dacă utilizatorul lasă dispozitivul nesupravegheat cu un tunel activ, VPN-ul continuă să furnizeze acces la nivel de enclavă până când un administrator termină manual sesiunea sau tunelul expiră. Într-un mediu de apărare în care duratele sesiunilor se întind adesea pe o întreagă zi de lucru, aceasta reprezintă o fereastră extinsă de risc nedetectat.

Rază de impact în rețeaua plată. Un VPN plasează utilizatorul pe un segment de rețea. Conectivitatea plată est-vest din acel segment înseamnă că o sesiune VPN compromisă poate ajunge nu doar la aplicația pe care utilizatorul intenționa să o acceseze, ci la fiecare serviciu, bază de date și interfață de administrare din subrețea. Atacatorul care fură un identificator VPN obține un punct de sprijin cu aceeași deschidere în rețea ca utilizatorul legitim — sau mai largă, deoarece politica VPN restricționează rareori traficul intra-subrețea. Aceasta este problema razei de impact: compromiterea unui singur identificator expune întregul segment de rețea plat.

Incapacitatea de a aplica politici de acces granulare. Politica de acces VPN este grosieră: unui utilizator i se permite sau nu să se conecteze la un profil VPN. Profilul poate atribui un VLAN sau o subrețea, dar aplicarea politicilor per aplicație, per resursă sau per acțiune în interiorul tunelului nu este o capabilitate VPN. Controlul accesului în tunel este delegat mecanismului propriu de autentificare al fiecărei aplicații — care poate varia sălbatic în rigoare de-a lungul portofoliului de aplicații. ZTNA mută politica de acces într-un motor centralizat de politici, care aplică reguli consecvente pe fiecare aplicație, evaluate în punctul fiecărei cereri de acces, nu o singură dată la stabilirea sesiunii. Conceptul înrudit de microsegmentare zero trust pentru apărare abordează mișcarea laterală în rețea după decizia de acces, completând stratul ZTNA de la perimetru.

Arhitectura ZTNA: modele cu proxy vs agent pe terminal

Implementările ZTNA se împart în două tipare arhitecturale principale, după modul în care se realizează interceptarea traficului: modelul cu proxy invers (fără client) și modelul cu agent pe terminal. Ambele modele împărtășesc o structură logică comună — un punct de aplicare a politicilor, un broker de identitate, un serviciu de încredere în dispozitiv și un proxy de sesiune — dar diferă prin locul unde are loc interceptarea și prin nivelul de vizibilitate asupra dispozitivului pe care îl pot atinge.

ZTNA cu proxy invers (fără client)

În modelul cu proxy invers, niciun software nu este instalat pe terminal. Serviciul ZTNA publică un punct final de proxy — de obicei un URL în domeniul organizației — plasat în fața fiecărei aplicații protejate. Utilizatorul navighează la URL-ul proxy-ului într-un browser, se autentifică prin brokerul de identitate (prezentând credențialele CAC/PIV și finalizând MFA) și primește un token de sesiune de scurtă durată. Proxy-ul validează tokenul la fiecare cerere și transmite cererile autentificate și autorizate către backend-ul aplicației. Dispozitivul utilizatorului nu este niciodată plasat în rețeaua aplicației; doar proxy-ul are o cale de rețea către backend.

Principala limitare a modelului fără client este acoperirea protocoalelor: funcționează natural pentru aplicațiile HTTPS și poate gestiona RDP și SSH prin clienți bazați pe browser (gateway-uri RDP/SSH HTML5), dar nu suportă protocoale TCP/UDP arbitrare sau aplicații cu client greu care comunică prin protocoale proprietare. Vizibilitatea încrederii în dispozitiv este de asemenea mai limitată fără agent: proxy-ul poate inspecta certificatele de client TLS și șirurile user-agent ale browserului, dar nu poate verifica starea de sănătate EDR sau atestarea TPM fără asistența unui agent local.

ZTNA cu agent pe terminal

Modelul cu agent instalează un daemon ușor pe terminalul gestionat. Agentul rulează continuu, interceptează traficul destinat adreselor aplicațiilor protejate (printr-un adaptor virtual de rețea local sau un filtru de pachete la nivel de sistem de operare), efectuează local verificările de încredere în dispozitiv și stabilește un tunel criptat către marginea de servicii ZTNA. Traficul aplicațiilor protejate traversează acest tunel, nu internetul deschis sau un VPN. Backend-ul aplicației primește conexiuni de la proxy-ul ZTNA, nu direct de la terminal — adresa de rețea a backend-ului nu este niciodată expusă terminalului.

ZTNA bazat pe agent suportă orice protocol de aplicație, permite semnale bogate de încredere în dispozitiv (integrare EDR, atestare TPM, conformitate a patch-urilor) și permite rutarea split-tunnel, în care doar traficul aplicațiilor protejate traversează tunelul ZTNA, în timp ce traficul general de internet iese direct. Pentru terminalele gestionate de apărare, modelul cu agent este alegerea standard, deoarece cerințele de postură a dispozitivului pentru accesul la aplicații clasificate nu pot fi îndeplinite fără vizibilitate la nivel de agent local.

ZTNA livrat din cloud vs ZTNA on-premises

ZTNA livrat din cloud rulează planul de control și proxy-ul de sesiune într-un serviciu cloud multi-tenant. Acest model se potrivește programelor neclasificate, în care aplicațiile sunt găzduite în medii cloud comerciale sau guvernamentale. Pentru programele clasificate — IL4, IL5 și IL6 cu separare fizică — planul de control ZTNA trebuie implementat în interiorul perimetrului acreditat. ZTNA on-premises plasează motorul de politici, brokerul de identitate și proxy-ul de sesiune în interiorul enclavei clasificate. Traficul aplicațiilor nu iese niciodată din perimetrul clasificat. Dependențele externe ale planului de control — validarea certificatelor, interogările de stare EDR, căutările la furnizorul de identitate — trebuie toate rezolvate în rețeaua acreditată, fără acces la internet.

Semnale de identitate: cine se conectează

Deciziile de acces ZTNA sunt condiționate de identitatea utilizatorului care se conectează. Pentru personalul de apărare, verificarea identității se ancorează în credențialul fizic emis de sistemul de personal al organizației — cardul inteligent CAC sau PIV — și este îmbogățită de atributele de rol și de grup provenite din director.

Verificarea certificatelor CAC/PIV

Cardul CAC (Common Access Card) și cardul PIV (Personal Identity Verification) poartă un certificat de identitate X.509 emis de PKI-ul aprobat al organizației. Verificarea certificatului ZTNA implică: prezentarea certificatului brokerului de identitate ZTNA prin autentificare de client TLS; validarea lanțului certificatului față de ancora de încredere aprobată (CA-urile rădăcină și intermediare din depozitul de încredere al organizației); verificarea certificatului față de lista de revocare a certificatelor (CRL) sau responderul OCSP, pentru a confirma că nu a fost revocat; și extragerea numelui distinctiv al subiectului sau a UPN din certificat, pentru a identifica principalul utilizator.

Disponibilitatea CRL și OCSP într-un mediu cu separare fizică este un punct frecvent de eșec operațional. Dacă punctul de distribuție CRL este accesibil doar din rețeaua neclasificată, iar implementarea ZTNA se află pe o rețea clasificată, verificările de revocare a certificatelor eșuează sau expiră. Implementările ZTNA cu separare fizică cer un proxy de cache CRL în interiorul perimetrului clasificat, care sincronizează periodic actualizările CRL prin mecanismul de transfer inter-domenii.

Autentificare multi-factor pentru accesul ZTNA

Introducerea PIN-ului CAC satisface cerința MFA „ceva ce aveți plus ceva ce știți” pentru majoritatea programelor. Totuși, aplicațiile desemnate ca de înaltă sensibilitate pot cere un factor suplimentar dincolo de CAC — un cod TOTP, o notificare push către o aplicație autentificator înregistrată sau o cheie hardware de securitate. Motorul de politici ZTNA poate impune cerințe de nivel MFA per aplicație: CAC-PIN standard pentru aplicațiile generale, CAC-PIN plus TOTP pentru aplicațiile sensibile de comandă și un flux de aprobare în afara bandei, limitat în timp, pentru accesul administrativ privilegiat. Această stratificare MFA per aplicație nu poate fi obținută cu o politică VPN plată.

Integrarea furnizorului de identitate: LDAP și Active Directory

Autentificarea prin certificat identifică principalul utilizator, dar nu poartă rolul curent sau apartenența la grupuri — acestea sunt gestionate în director și se pot schimba independent de emiterea certificatului. Motorul de politici ZTNA interoghează furnizorul de identitate — LDAP sau Active Directory — în momentul fiecărei cereri de acces, pentru a rezolva apartenențele curente la grupuri și atribuirile de roluri ale utilizatorului. Atributele rezolvate devin intrări pentru politici: un utilizator trebuie să fie membru al grupului Active Directory „analysts-secret” pentru a accesa aplicația clasificată de analiză, indiferent ce spune certificatul său. Dacă utilizatorul este scos din grup în Active Directory, următoarea sa cerere de acces la aplicația de analiză este refuzată de motorul de politici ZTNA, fără a fi necesară revocarea certificatului sau o schimbare a politicii VPN. Acest control al accesului bazat pe atribute, susținut de interogări în timp real ale directorului, este o capabilitate fundamentală a guvernanței identității pe care organizațiile de apărare o aplică pentru a strânge ciclul de viață al controlului accesului.

Semnale de încredere în dispozitiv: ce dispozitiv se conectează

Identitatea utilizatorului este o condiție necesară, dar nu suficientă, pentru acces într-un model ZTNA de apărare. Un utilizator legitim pe un dispozitiv compromis sau neconform prezintă un risc pe care identitatea utilizatorului singură nu îl poate atenua. Evaluarea încrederii în dispozitiv colectează și evaluează semnale despre dispozitivul care se conectează, independent de afirmația de identitate a utilizatorului.

Certificatul dispozitivului

Primul semnal de încredere în dispozitiv este certificatul de mașină: un certificat emis de PKI-ul de dispozitive al organizației către terminal în momentul înscrierii. Certificatul de mașină dovedește că dispozitivul a fost înscris de un sistem MDM autorizat sau de un sistem de gestionare a dispozitivelor și că era atunci un activ gestionat. Agentul ZTNA prezintă certificatul dispozitivului alături de certificatul utilizatorului la stabilirea sesiunii. Motorul de politici validează lanțul certificatului dispozitivului față de ancora de încredere a PKI-ului de dispozitive, verifică starea de revocare și confirmă că identificatorul dispozitivului din certificat corespunde identității dispozitivului înregistrate în inventarul MDM.

Starea de sănătate EDR

Agentul de detectare și răspuns la terminal (EDR) care rulează pe dispozitiv menține o evaluare în timp real a stării de amenințare a dispozitivului. Agentul ZTNA interoghează agentul EDR local sau API-ul platformei de gestionare EDR pentru o atestare de sănătate: rulează agentul EDR, este actualizată baza sa de informații despre amenințări și există amenințări active în carantină sau remediere? Un dispozitiv cu o bază de semnături EDR învechită este practic orb față de familiile recente de amenințări — politica ZTNA trebuie să trateze un astfel de dispozitiv ca neconform și fie să îi refuze accesul, fie să îl restrângă la un nivel de acces limitat până la actualizarea EDR. Un eveniment activ de carantină a unei amenințări în timpul unei sesiuni declanșează un eveniment de evaluare continuă care poate duce la suspendarea imediată a sesiunii.

Verificarea conformității patch-urilor

Nivelul de patch-uri al sistemului de operare și al aplicațiilor este interogat de la platforma MDM sau din inventarul local de patch-uri instalate al agentului ZTNA. Motorul de politici ZTNA compară starea patch-urilor dispozitivului cu un minim definit: de exemplu, toate CVE-urile critice și de severitate ridicată publicate în ultimele 30 de zile trebuie aplicate înainte de a permite accesul la aplicații clasificate. Dispozitivele rămase în urmă cu patch-urile sunt redirecționate către un aviz de remediere, nu către aplicația cerută. Verificarea conformității patch-urilor acoperă și aplicațiile terțe din inventarul de software gestionat al dispozitivului — un browser web sau un cititor PDF fără patch-uri, pe un dispozitiv gestionat, reprezintă un vector de exploatare chiar dacă sistemul de operare este complet actualizat.

Atestarea hardware prin TPM 2.0

Pentru terminalele gestionate de apărare echipate cu un modul TPM 2.0, agentul ZTNA poate cere o citire de atestare TPM — o măsurătoare semnată criptografic a lanțului de boot al dispozitivului, produsă de TPM și verificabilă față de un manifest de referință cunoscut ca bun. Atestarea dovedește că dispozitivul a pornit de la un firmware autorizat și o imagine de sistem de operare autorizată și că lanțul de boot nu a fost alterat de la ultima atestare. Acest control este relevant pentru detectarea malware-ului la nivel de boot — rootkit-uri și bootkit-uri care persistă sub sistemul de operare și nu ar fi detectate de un agent EDR la nivel de OS. Atestarea TPM cere ca planul de control ZTNA să dețină un manifest de referință pentru fiecare model de dispozitiv din parcul gestionat; manifestul este populat la înscrierea dispozitivului și actualizat când sunt implementate modificări autorizate de firmware.

Motorul de evaluare continuă a politicilor

Motorul de politici este nucleul decizional al arhitecturii ZTNA. Primește cereri de acces — de la proxy-ul de sesiune când un utilizator inițiază o conexiune și de la bucla de evaluare continuă pe durata unei sesiuni active — și returnează o decizie de acces: permisiune, refuz sau step-up (cere autentificare suplimentară înainte de permisiune).

Politica-ca-cod cu OPA și Rego

Implementările ZTNA de apărare beneficiază din exprimarea politicii de acces ca cod, nu ca reguli configurate în interfață grafică. Open Policy Agent (OPA) cu limbajul de politici Rego este cadrul dominant pentru acest tipar. O politică Rego pentru ZTNA codifică declarativ toate condițiile de acces: grupurile de utilizatori necesare, nivelul minim de conformitate a dispozitivului, orele de acces permise, nivelul MFA necesar și pragul scorului de risc. Politicile sunt ținute sub versionare într-un depozit sursă, revizuite prin același proces de control al schimbărilor ca codul de aplicație și implementate în motorul OPA printr-un pipeline CI/CD. Fiecare modificare de politică are un autor, o înregistrare de revizuire, un marcaj temporal de implementare și poate fi întoarsă la o versiune anterioară printr-o singură revenire în pipeline. Această auditabilitate este un avantaj important față de regulile de firewall per aplicație, care se acumulează fără versionare.

Decizii de acces conștiente de context

Deciziile de politică ZTNA pot încorpora semnale contextuale dincolo de identitate și încrederea în dispozitiv. Politica pe timpul accesului restricționează accesul la aplicațiile sensibile la ferestre definite de ore de lucru, reducând fereastra de expunere la utilizarea abuzivă a identificatorilor în afara orelor normale de lucru. Politica de geolocalizare sau de sursă de rețea — de unde se conectează utilizatorul — poate fi evaluată de motorul de politici: o aplicație clasificată poate permite accesul doar din punctele de ieșire din rețea gestionate de organizație sau din anumite locații de acces la distanță aprobate. Integrarea scorului de risc permite motorului de politici să consume un semnal numeric de risc produs de o platformă de analiză a comportamentului utilizatorilor și entităților (UEBA): dacă tiparul de acces al utilizatorului din ultimele 24 de ore a produs un scor de risc de anomalie ridicat, motorul de politici ridică pragul de acces, cerând MFA suplimentar de tip step-up înainte de a permite accesul la aplicațiile sensibile.

Reevaluarea riscului sesiunii

Controlul tradițional al accesului ia o decizie la începutul sesiunii și nu o mai revizuiește. Evaluarea continuă ZTNA reevaluează decizia de acces pe toată durata sesiunii, la un interval de sondaj configurabil. Bucla de evaluare interoghează furnizorul de identitate pentru schimbări ale stării contului (blocarea contului sau revocarea din grup de la începutul sesiunii), platforma EDR pentru evenimente noi de amenințare pe dispozitiv, serviciul de conformitate a dispozitivelor pentru schimbări ale stării patch-urilor și serviciul de scor de risc pentru schimbări ale scorului de anomalie. Când o schimbare traversează un prag de politică, motorul răspunde proporțional: o creștere moderată a riscului declanșează o provocare MFA step-up fără terminarea sesiunii; un eveniment critic — cont blocat, amenințare EDR activă, revocarea certificatului — declanșează terminarea imediată a sesiunii. Modelul de evaluare continuă înseamnă că un atacator care compromite un dispozitiv în timpul sesiunii se confruntă cu o fereastră de detecție limitată de intervalul de sondaj, nu de întreaga durată a sesiunii. Aceleași principii care guvernează programele de gestionare a accesului privilegiat în apărare — acces just-in-time, înregistrarea sesiunilor și reevaluarea riscului în timp real — se aplică direct proiectării evaluării continue ZTNA pentru sesiunile cu privilegii ridicate.

ZTNA pentru rețele clasificate: implementare IL4/IL5

Serviciile ZTNA comerciale livrate din cloud operează în infrastructură partajată multi-tenant, neautorizată pentru sarcini de lucru clasificate. Programele de apărare care operează la nivelurile de impact IL4 (Controlled Unclassified Information) și IL5 (National Security Systems) cer un model de implementare ZTNA care păstrează operațiunile planului de control și traficul aplicațiilor în interiorul perimetrului acreditat.

ZTNA on-premises pentru medii clasificate cu separare fizică

O implementare ZTNA on-premises pentru o rețea clasificată replică componentele funcționale ale unui serviciu ZTNA din cloud în interiorul enclavei clasificate. Motorul de politici, brokerul de identitate, proxy-ul de sesiune și serviciul de încredere în dispozitiv sunt toate implementate ca sarcini de calcul on-premises — fie pe hardware dedicat, fie în cadrul clusterului Kubernetes clasificat. Toate dependențele planului de control se rezolvă în interiorul enclavei: furnizorul de identitate este instanța Active Directory clasificată, consola de gestionare EDR este implementată on-premises, autoritatea de certificare și serviciul CRL operează în interiorul separării fizice, iar niciun apel de evaluare a politicilor nu părăsește perimetrul rețelei clasificate.

Provocarea operațională unică a ZTNA cu separare fizică este distribuția actualizărilor de politici. Într-un serviciu ZTNA din cloud, modificările de politică sunt implementate centralizat și se propagă în câteva secunde. Într-un mediu cu separare fizică, actualizările de politici trebuie livrate prin mecanismul autorizat de transfer de software — de obicei un proces de transfer pe suporturi prin perimetrul de acreditare. Aceasta înseamnă că modificările de politici ZTNA cer planificare din timp și nu pot fi aplicate cu latența sub un minut disponibilă în implementările din cloud. Procesul de control al schimbărilor pentru politica ZTNA cu separare fizică trebuie să țină cont de acest timp de anticipație, iar modificările de politică de urgență (de exemplu, revocarea imediată a accesului unui utilizator compromis) trebuie să aibă o cale accelerată prin procesul de control al schimbărilor definit în planul de securitate al programului.

Proiectarea proxy-ului ZTNA inter-domenii

Unele cazuri de utilizare din apărare cer ca utilizatorii dintr-o rețea cu clasificare inferioară să acceseze o vizualizare specifică și filtrată a datelor produse de un sistem cu clasificare superioară — o imagine operațională sanitizată, un rezumat de informații declasificate sau un flux de date doar pentru citire. Un proxy ZTNA inter-domenii rezolvă acest lucru combinând controlul accesului ZTNA cu inspecția de conținut inter-domenii la granița de clasificare. Proxy-ul primește cererea de acces a utilizatorului din rețeaua neclasificată, verifică identitatea și încrederea în dispozitiv față de motorul de politici ZTNA neclasificat, apoi interoghează aplicația clasificată în numele utilizatorului prin soluția inter-domenii. Componenta CDS inspectează conținutul răspunsului aplicației, aplică regulile de lansare pentru clasificarea datelor și filtrează sau redactează elementele neautorizate pentru lansare către solicitantul neclasificat. Doar răspunsul filtrat este returnat sesiunii utilizatorului din rețeaua neclasificată. Proxy-ul trebuie acreditat ca parte a ambelor ATO-uri de rețea și a autorizației inter-domenii, arhitectura ZTNA + CDS fiind descrisă explicit ca un control combinat.

Migrarea de la VPN-ul tradițional la ZTNA

Migrarea de la VPN la ZTNA într-un program de apărare este o tranziție operațională care trebuie să păstreze continuitatea accesului pentru aplicațiile critice pentru misiune, în timp ce strânge progresiv controlul accesului. O strategie de migrare etapizată, care rulează VPN și ZTNA în paralel pe durata perioadei de tranziție, este abordarea standard.

Strategie de migrare etapizată

Migrarea decurge în trei faze. În prima fază, infrastructura ZTNA este implementată și validată pentru integrarea identității și a încrederii în dispozitiv, dar nicio aplicație nu este integrată, iar utilizatorii continuă să acceseze toate aplicațiile prin VPN. Un grup-pilot de utilizatori — de obicei echipa IT și de securitate — testează accesul ZTNA la o aplicație de criticitate scăzută, pentru a valida fluxul cap-coadă înainte de implicarea utilizatorilor de misiune. În a doua fază, aplicațiile sunt integrate în ZTNA în ordinea priorității. În această fază, VPN-ul rămâne disponibil ca rezervă pentru aplicațiile încă neintegrate. Utilizatorii sunt instruți în portalul de acces ZTNA și în agent înainte ca aplicațiile lor principale să treacă pe ZTNA. În a treia fază, după ce toate aplicațiile din perimetru sunt integrate și populația-pilot a validat accesul, accesul VPN este revocat pentru populația de utilizatori migrată. Gateway-ul VPN rămâne disponibil doar pentru aplicațiile excluse din perimetrul ZTNA (dacă există) pe durata fazei finale, apoi este retras când aplicațiile rămase își finalizează integrarea.

Secvența de integrare a aplicațiilor

Aplicațiile sunt integrate în ZTNA într-o secvență proiectată să minimizeze riscul și să învețe din integrările timpurii înainte de cazurile complexe. Începeți cu portalurile web interne și tablourile de bord — aplicații HTTPS cu interfețe bazate pe browser, care funcționează natural cu ZTNA prin proxy invers și au populații largi de utilizatori care pot oferi feedback rapid. Treceți apoi la aplicațiile de productivitate: interfețele web de e-mail, portalurile de gestionare a documentelor, wiki-urile interne. Abordați apoi categoriile de aplicații care cer modelul cu agent: servere Windows accesate prin RDP, sisteme Linux accesate prin SSH, aplicații C2 sau de misiune cu client greu. Rezervați pentru final integrările cele mai complexe: aplicațiile cu mecanisme de autentificare nestandard, sistemele în timp real de criticitate ridicată și orice aplicație care se bazează în prezent pe control al accesului bazat pe IP prin VPN, în loc de autentificare la nivel de aplicație.

Instruirea utilizatorilor pentru tiparele de acces ZTNA

Experiența utilizatorului ZTNA diferă în mod substanțial de VPN. Utilizatorii obișnuiți cu VPN se conectează o dată la începutul zilei și accesează toate aplicațiile transparent pentru restul zilei. Cu ZTNA, utilizatorul accesează aplicațiile prin portalul ZTNA sau prin conexiuni interceptate de agent și poate întâlni provocări MFA step-up în timpul zilei, dacă evaluarea continuă detectează o schimbare a riscului. Instruirea trebuie să abordeze trei schimbări de comportament. În primul rând, portalul de acces: unde să navigheze pentru a găsi aplicațiile și cum să se autentifice prin CAC. În al doilea rând, agentul: cum apare agentul ZTNA în tava sistemului, ce înseamnă indicatorii săi de stare și cum să raporteze probleme. În al treilea rând, autentificarea step-up: cum arată o provocare MFA în mijlocul sesiunii (pentru ca utilizatorii să nu confunde o solicitare legitimă de step-up cu o încercare de phishing) și cum să o finalizeze. Programele care investesc în instruirea utilizatorilor înainte de integrarea primului utilizator de misiune înregistrează volume semnificativ mai mici de tichete la helpdesk și o adoptare mai rapidă decât programele care implementează ZTNA fără un program de instruire.