Gestionarea Accesului Privilegiat (PAM) într-o rețea de apărare nu este aceeași problemă pe care PAM o rezolvă într-o întreprindere comercială. O bancă care greșește PAM pierde date ale clienților; o organizație de apărare care greșește PAM pierde rețeaua — și operațiunile care rulează pe ea. Autoritatea de acreditare știe acest lucru, iar lanțul de audit îl reflectă. Acest articol parcurge deciziile de inginerie care separă un rollout PAM de grad de apărare de unul comercial, bazându-se pe modelele pe care le-am văzut reușite (și eșuate) în interiorul enclavelor clasificate, fluxurilor de lucru rezidente SCIF și domeniilor OT. Pentru imaginea mai largă, consultați ghidul complet de cybersecuritate a apărării.
1. De ce PAM în apărare este diferit
Trei proprietăți fac PAM-ul de apărare structural diferit de PAM-ul comercial. În primul rând, utilizatorii sunt multi-clasificare: același operator uman poate deține conturi pe un LAN administrativ neclasificat, o rețea de misiune SECRET și o enclavă de informații TOP SECRET, iar platforma PAM nu trebuie niciodată să medieze o credențiala prin acea graniță. În al doilea rând, fluxurile de lucru de cea mai mare valoare sunt rezidente SCIF — utilizatorul, stația de lucru, gazda de salt și vault-ul sunt toate în interiorul aceleiași camere acreditate, iar orice componentă care trăiește în afara SCIF este, prin definiție, arhitectura greșită. În al treilea rând, așteptarea lanțului de audit este mult mai strictă decât cea comercială: autoritatea de acreditare nu acceptă „avem log-uri" — se așteaptă la o înregistrare rezistentă la manipulare, reproductibilă, limitată de retenție a fiecărei acțiuni privilegiate, mapată înapoi la o persoană autorizată și supraviețuind când rețeaua este offline timp de săptămâni.
Consecința practică este că „implementați CyberArk și ați terminat" — răspunsul care funcționează în majoritatea implementărilor comerciale — nu este răspunsul în apărare. Alegerea platformei contează mai puțin decât topologia enclavei, modelul de broker și pipeline-ul de audit. Am văzut organizații care cumpără produsul potrivit și totuși eșuează acreditarea deoarece au colapsat două niveluri de clasificare într-un singur vault.
2. CyberArk / HashiCorp Vault / BeyondTrust / Delinea
CyberArk rămâne titularul pentru implementările clasificate la organizațiile de apărare membre NATO. Managerul de Sesiuni Privilegiate (PSM) este matur, validat FIPS 140-2, iar Enterprise Password Vault are certificare Common Criteria EAL4+ — ambele articole pe care acreditorul le va verifica primul. Costul este ridicat, iar modelul de licențiere presupune conectivitate la infrastructura de actualizare CyberArk, ceea ce forțează un flux de actualizare offline în interiorul enclavelor cu decalaj aerian.
HashiCorp Vault (Enterprise) este alegerea când încărcătura de lucru este condusă de API, efemeră și adiacentă Kubernetes. Motoarele sale de secrete dinamice și PKI sunt excelente pentru emiterea X.509 cu viață scurtă, ceea ce este din ce în ce mai mult modul în care se autentifică sarcinile de lucru moderne de apărare. Vault Enterprise suportă modul FIPS 140-2 și integrarea HSM via PKCS#11. Punctul său slab în contextul apărării este brokering-ul de sesiuni — Vault este un motor de secrete, nu un proxy de sesiune, deci un flux de lucru de administrator interactiv are nevoie de o componentă separată (Boundary sau un bastion terț) stratificată deasupra.
BeyondTrust (Password Safe + Privileged Remote Access) are cea mai puternică poveste OT/ICS dintre cele patru. Modelul său de gazdă de salt a fost proiectat pentru accesul la distanță gestionat de furnizori în instalații industriale, care se mapează curat pe fluxurile de lucru de întreținere la depozit și suport OEM pe care le rulează efectiv organizațiile logistice de apărare. Validat FIPS 140-2; pipeline-ul de înregistrare a sesiunilor este cel mai matur din orice produs din această categorie.
Delinea (fostul Thycotic + Centrify) este opțiunea mai ușoară, adesea aleasă pentru sub-enclave unde amprenta completă CyberArk este excesivă. Secret Server este validat FIPS 140-2; Server Suite acoperă bridging-ul AD pentru Linux/Unix de care mai depind încă domeniile mai vechi de apărare.
Prin toate cele patru, tranziția FIPS 140-3 este în curs — validările 140-2 rămân acceptate în cadrul regulilor tranzitorii prin ciclul de acreditare 2026 în cele mai multe contexte NATO, dar noile implementări ar trebui să specifice 140-3 acolo unde furnizorul îl oferă. Acoperirea Common Criteria este inegală; CyberArk și BeyondTrust au cele mai adânci schedule.
3. Brokering de sesiuni conștient de clasificare
Decizia arhitecturală cea mai importantă în PAM-ul de apărare este dacă platforma mediază sesiunile prin granițele de clasificare — și răspunsul corect este întotdeauna „nu". Fiecare enclavă primește propriul vault, propriul manager de sesiuni și propriul spațiu de audit. Credențiala pentru contul de administrator SECRET nu există niciodată în vault-ul neclasificat, nici criptată, nici „pentru urgență". Dacă acreditarea găsește o singură înregistrare a unei credențiale de clasificare superioară într-o componentă de clasificare inferioară, întreaga implementare revine la punctul de plecare.
Escaladarea sesiunilor între enclave — fluxul de lucru în care un operator pe partea neclasificată trebuie să ajungă la o gazdă SECRET — este rezolvată la granița soluției cross-domain (CDS), nu în interiorul platformei PAM. Operatorul se autentifică în interiorul enclavei de clasificare superioară; CDS nu transmite credențiale. Platforma PAM pe fiecare parte nu este conștientă de cealaltă. Aceasta se mapează curat pe modelul rețelelor militare zero-trust unde fiecare enclavă este propriul domeniu de încredere.
Pentru fluxurile de lucru rezidente SCIF, vault-ul, managerul de sesiuni și colectorul de audit trăiesc toți în interiorul SCIF. Tentația de a găzdui planul de management în afara SCIF „pentru ușurința administrării" este cea mai frecventă greșeală arhitecturală pe care o vedem, și este nerecuperabilă — acreditorul nu va aproba un canal de management la distanță către un spațiu de credențiale rezident SCIF, indiferent de modul în care este criptat.
4. Elevare just-in-time (JIT)
Elevarea JIT este disciplina de a acorda acces privilegiat numai în momentul în care este necesar, pentru durata în care este necesar, și de a-l revoca automat ulterior. În rețelele de apărare înlocuiește modelul de lungă durată „echipa de întreținere are Domain Admin permanent deoarece uneori are nevoie de el la 3 dimineața" — care este exact modelul pe care îl exploatează un adversar cu acces persistent.
Arhitectura are trei componente. În primul rând, un flux de lucru de cerere — de obicei integrat cu sistemul de ticketing — unde operatorul solicită elevarea, cu un motiv declarat și o durată declarată. În al doilea rând, o cale de aprobare: pentru întreținere de rutină, aceasta poate fi automatizată de politică; pentru urgențe în sistemele OT sau material cheie criptografic, necesită aprobarea unui al doilea operator autorizat (principiul celor patru ochi). În al treilea rând, un mecanism de emitere: platforma PAM bate o credențiala limitată în timp — un certificat SSH efemer (de obicei 1–4 ore), un cert de client X.509 cu viață scurtă pentru acces API, sau o calitate de membre a grupului AD temporar care expiră pe un timer programat.
Certificatele SSH efemere sunt cel mai curat model pentru administrarea Linux/Unix: cererea operatorului declanșează Vault (sau echivalentul CyberArk) să bată un certificat semnat de SSH CA, cu scopul pentru gazde specifice, cu o valabilitate de 4 ore. Nicio cheie publică cu viață lungă nu stă vreodată pe gazda țintă, iar revocarea este automată când certificatul expiră. Pentru administrarea Windows, certificatele de client X.509 cu viață scurtă combinate cu cititoare de card inteligent ating aceeași proprietate, valorificând rădăcina de încredere hardware deja prezentă pe cele mai multe stații de lucru de apărare.
5. Conturi de serviciu și secrete
Cadenele de rotație recomandate de furnizori — 30 de zile pentru conturile de serviciu, 90 de zile pentru secretele aplicațiilor, anual pentru cheile root CA — sunt partea ușoară. Partea dificilă este rotația sub decalaj aerian. O întreprindere conectată rotează o parolă de cont de serviciu și noua credențiala se propagă prin Active Directory, spațiul de secrete, aplicația consumatoare și sistemul de monitorizare în câteva secunde. Înăuntrul unei enclave cu decalaj aerian, fiecare dintre acești pași este manual, programat și purtător de risc — iar fereastra de întreținere se măsoară în ore cu cifre simple, adesea noaptea, adesea cu un operator de rezervă în așteptare.
Răspunsul operațional realist este cadențele stratificate: credențialele de înaltă valoare (Domain Admin, CA-uri rădăcină, chei de deblocare KMS) se rotesc în programe accelerate cu disciplina completă de control al schimbărilor; credențialele de valoare medie (conturi de serviciu baze de date, principali de aplicații) se rotesc prin fluxuri de lucru PAM automatizate în ferestrele de întreținere programate; credențialele de valoare scăzută, dar cu viață lungă (conturi de aplicații legacy, parole de dispozitive încorporate) se inventariază, se păstrează în vault și se rotesc la cea mai lentă cadență pe care registrul de risc o va accepta.
Realitatea credențialelor cu viață lungă este cea pe care auditul o prinde întotdeauna. Fiecare domeniu de apărare de orice dimensiune are o coadă lungă de conturi de serviciu create în 2014 pentru un sistem pe care nimeni nu îl mai deține, cu parola într-o pagină wiki care a fost migrată de patru ori. Rollout-ul PAM descoperă acestea, iar descoperirea în sine este valoarea — chiar dacă rotația durează încă un an.
6. PAM pentru OT / instalații industriale
Tehnologia Operațională — sistemele de control industrial care rulează utilajele depozitului, infrastructura de alimentare cu energie a bazei, depozitarea combustibilului și din ce în ce mai mult liniile de producție care alimentează lanțul de aprovizionare al apărării — este cel mai dificil mediu PAM din orice organizație de apărare. Trei modele domină.
În primul rând, arhitectura gazdei de salt: fiecare conexiune administrativă la rețeaua OT se termină la un bastion întărit care mediază protocolul (RDP, VNC, serial-over-IP), impune înregistrarea sesiunilor și izolează stația de lucru a operatorului de rețeaua de control. Produsul Privileged Remote Access al BeyondTrust este implementarea de referință aici; PSM pentru SSH al CyberArk și modelul Apache Guacamole open-source acoperă același teren la puncte de cost diferite.
În al doilea rând, problema parolei neschimbate în 15 ani. PLC-urile, HMI-urile și serverele istorice au fost livrate de OEM cu credențiale implicite sau rar rotite, iar rotirea lor riscă să cărămidizeze dispozitivul sau să rupă un contract de suport al furnizorului. Răspunsul pragmatic este să stochezi credențiala în vault (astfel cel puțin calea de acces este auditată și textul clar este eliminat din memoria operatorului și notele post-it), să amâni rotația până la următoarea fereastră de întrerupere programată și să documentezi riscul rezidual în pachetul de acreditare.
În al treilea rând, accesul la distanță gestionat de furnizor. Tehnicienii OEM trebuie să ajungă la echipament pentru suportul de garanție. Platforma PAM mediază aceasta ca o sesiune complet înregistrată, limitată în timp, mediată prin gazda de salt — niciodată un tunel VPN permanent în rețeaua OT. Contul furnizorului este emis JIT, sesiunea este înregistrată de la capăt la capăt, iar operatorul autorizat din partea apărării aprobă și observă.
Perspectivă cheie: Platforma PAM nu este controlul de securitate. Lanțul de audit acreditabil este. Un vault perfect cu un pipeline de audit rupt eșuează acreditarea; un vault modest cu un lanț de audit neîntrerupt, disciplinat în retenție, trece. Proiectează pentru audit mai întâi; fluxurile de lucru ale credențialelor decurg din aceasta.
7. Lanțul de audit și înregistrarea sesiunilor
Lanțul de audit este artefactul de care se preocupă cel mai mult autoritatea de acreditare, și este cel pe care rollout-urile PAM de apărare îl construiesc cel mai des insuficient. Trei straturi contează. Logarea tastaturii captează comenzile literale pe care operatorul le-a tastat într-o sesiune privilegiată — neprețuită pentru criminalistică, costisitoare în stocare și supusă disciplinei de retenție. Înregistrarea video a sesiunilor captează cadrele RDP/VNC randate — non-negociabilă pentru sesiunile SCADA/HMI unde interacțiunea operatorului este grafică, nu textuală. Auditul la nivel de comandă captează evenimentul structurat („utilizatorul X elevat la rolul Y pe gazda Z la timpul T pentru tichetul #N") — stratul pe care SOC îl consumă efectiv în corelarea SIEM și verificarea zero-trust.
Disciplina de retenție lungă este locul unde playbook-urile PAM comerciale sunt deficitare. Orizonturile de retenție a apărării ajung în mod obișnuit la 7–10 ani, uneori mai lungi pentru contextele adiacente nucleare sau ale sistemelor strategice. Nivelul de stocare trebuie să fie imuabil (clasă WORM sau stocare de obiecte cu scriere unică cu blocuri de retenție), integritatea trebuie să fie criptografic ancorată (manifeste semnate, log-uri înlănțuite hash) și calea de recuperare trebuie să funcționeze în 2034 cu oamenii și instrumentele disponibili atunci — nu oamenii disponibili astăzi.
Alinierea GDPR și NIS2 contează în contextele de apărare UE. Înregistrarea sesiunilor captează date cu caracter personal (tastele operatorului, uneori fața pe o sesiune activată cu webcam). Baza legală conform GDPR este de obicei „obligație legală" plus „interes legitim", cu limite de retenție documentate și controale de acces. NIS2 consolidează aceasta cu cerințe explicite de răspuns la incidente și disponibilitate a auditului pe care logarea PAM le servește direct.
8. Migrare și coexistență
Calendarul realist pentru a aduce un domeniu de apărare numai AD în PAM modern este de doi până la patru ani. Primul an este descoperirea și vault-uirea: fiecare credențiala privilegiată este inventariată, stocată în vault și adusă sub fluxul de lucru de check-out/check-in, fără a schimba încă modul în care operatorii lucrează. Al doilea an este brokering-ul de sesiuni: sesiunile interactive de admin se mută în spatele proxy-ului PAM, înregistrarea începe și lanțul de audit intră online. Al treilea an este elevarea și rotația JIT: privilegiile permanente sunt convertite la timp limitat, iar cadenele de rotație sunt impuse. Al patrulea an, dacă este necesar, este curățarea conturilor de serviciu cu coadă lungă și a credențialelor OT.
Coexistența cu modelele legacy numai AD este norma, nu excepția, pentru cea mai mare parte a acestui calendar. Platforma PAM mediază accesul la gazdele AD-joined, vault-uiește credențialele AD și înlocuiește treptat calitatea de membre permanentă Domain Admin cu elevarea JIT prin grupuri umbră. Încercarea de a trece întregul domeniu într-un singur weekend a eșuat de fiecare dată când am văzut-o tentată.
Lecția câștigată cu greu: rollback-ul PAM este mai rău decât rollout-ul lent. Odată ce o populație de operatori a fost mutată pe fluxuri de lucru mediate de vault, elevate JIT, complet auditate, revenirea la vechiul model „Domain Admin permanent" este operațional și cultural aproape imposibilă — decalajul de audit este vizibil, SOC a ajuns să depindă de telemetrie, iar pachetul de acreditare a fost actualizat. Un rollout parțial care rezistă este mai bun decât un rollout complet care trebuie inversat. Planificați fazele astfel încât fiecare fază să fie stabil independentă, și tratați cadența multi-anuală ca o caracteristică, nu ca un bug.