PAM și conturile break-glass pentru ISO 27001 în 2026
La 02:14, într-o dimineață de duminică, comandantul incidentului primește mesajul de care se teme orice CISO: „Autentificarea în producție eșuează. Consola de administrare nu poate fi accesată. Failover-ul bazei de date este blocat.”
Inginerul cloud de gardă vede problema, dar nu o poate remedia. Rolul său privilegiat normal depinde de același furnizor de identitate care este acum degradat. Responsabilul de operațiuni solicită acreditarea administratorului de urgență. Managerul de conformitate întreabă dacă acel cont break-glass a fost vreodată testat. DPO întreabă dacă accesarea bazei de date de producție poate expune date cu caracter personal. CISO pune întrebarea care decide dacă situația devine o recuperare controlată sau un coșmar de audit:
„Putem dovedi cine a utilizat accesul de urgență, de ce, ce a făcut și că acel cont a fost resetat ulterior?”
O altă organizație poate întâmpina aceeași problemă într-un context mai puțin tensionat. CISO al unei companii FinTech se află în fața auditorilor externi după o configurare greșită a unei baze de date cloud. Incidentul a fost remediat rapid, dar cauza principală nu a fost liniștitoare. Un dezvoltator terț avea privilegii administrative permanente. Când administratorul principal nu a fost disponibil, dezvoltatorul a utilizat un cont break-glass bazat pe o parolă partajată, stocată într-o notă „securizată” disponibilă echipei DevOps.
Auditorii nu s-au concentrat doar pe configurarea greșită. Au întrebat dacă accesul a fost limitat în timp, dacă a existat responsabilitate individuală, dacă au fost jurnalizate comenzile, dacă datele cu caracter personal au fost protejate conform GDPR Article 32, dacă obligațiile DORA privind riscurile TIC au fost îndeplinite și dacă așteptările NIS2 privind igiena cibernetică puteau fi demonstrate.
Acesta este punctul real de presiune pentru managementul accesului privilegiat și conturile break-glass în 2026. PAM nu mai este un proiect de nișă privind securitatea identității. Este punctul în care converg ransomware-ul, compromiterea mediilor cloud, riscul asociat furnizorilor, protecția datelor, reziliența operațională și dovezile de audit.
Accesul privilegiat este zona în care atacatorii încearcă să câștige. Accesul break-glass este zona în care apărătorii încearcă să recupereze. Ambele se bazează pe aceeași capabilitate periculoasă: privilegii ridicate care pot ocoli controale, modifica configurații, citi date sensibile, roti chei, dezactiva jurnalizarea, restaura backup-uri, implementa cod sau distruge dovezi.
Poziția practică a Clarysec este simplă: accesul de urgență este necesar, dar accesul de urgență neguvernat înseamnă risc neguvernat. Răspunsul corect nu este „fără conturi break-glass”. Răspunsul corect este un model guvernat de management al accesului privilegiat, cu inventar, aprobare, limite de timp, autentificare puternică, jurnalizarea sesiunilor, revizuire după utilizare, resetarea acreditărilor și dovezi de audit.
De ce accesul privilegiat este o problemă de conformitate la nivelul consiliului de administrație
În medii cu maturitate redusă, accesul privilegiat este adesea tratat ca o sarcină de administrare IT. Cineva are nevoie de drepturi de administrator, se deschide un tichet, se acordă un rol, iar activitatea organizației continuă. Acest model nu rezistă în fața ransomware-ului modern, a infrastructurii cloud-native, a răspunderii NIS2, a rezilienței operaționale DORA sau a analizei încălcărilor de securitate a datelor din perspectiva GDPR.
Directiva NIS2 aduce guvernanța securității cibernetice în sala consiliului de administrație. Article 20 impune organelor de conducere ale entităților esențiale și importante să aprobe măsurile de management al riscurilor de securitate cibernetică, să supravegheze implementarea și să urmeze instruire în domeniul securității cibernetice. Article 21 impune măsuri tehnice, operaționale și organizatorice adecvate și proporționale, inclusiv analiza riscurilor, gestionarea incidentelor, continuitatea activității, securitatea lanțului de aprovizionare, eficacitatea controalelor, igiena cibernetică, securitatea resurselor umane, controlul accesului, managementul activelor și autentificarea multifactor sau autentificarea continuă, după caz.
Pentru furnizori SaaS, furnizori de servicii administrate, furnizori de servicii de securitate administrate, servicii cloud, centre de date și alte organizații de infrastructură digitală, aplicabilitatea NIS2 depinde de sector, dimensiune, rol, impact transfrontalier și stabilirea în UE. Lecția operațională este directă: controlul accesului nu mai este îngropat într-o anexă tehnică. Face parte din baza de igienă cibernetică pe care conducerea trebuie să o aprobe, să o monitorizeze și să o corecteze.
Pentru entitățile financiare, Digital Operational Resilience Act schimbă terminologia, dar nu și riscul de fond. DORA se aplică de la 17 ianuarie 2025 și stabilește un cadru uniform pentru managementul riscurilor TIC, raportarea incidentelor majore legate de TIC, testarea rezilienței operaționale digitale și managementul riscului asociat terților TIC. Article 5 impune mecanisme de guvernanță și control pentru riscul TIC, organismul de conducere definind, aprobând, supraveghind și asumând responsabilitatea pentru mecanismele privind riscul TIC. Article 6 impune un cadru documentat de management al riscurilor TIC, cu politici, proceduri, protocoale și instrumente pentru protejarea activelor TIC. Article 17 impune un proces de gestionare a incidentelor legate de TIC care detectează, înregistrează, clasifică, escaladează și restaurează operațiunile securizate.
GDPR adaugă perspectiva confidențialității și a responsabilității. Article 5(1)(f) impune ca datele cu caracter personal să fie prelucrate cu integritate și confidențialitate. Article 5(2) impune responsabilitate. Article 25 impune protecția datelor încă din faza de proiectare și protecția datelor în mod implicit. Article 32 impune măsuri tehnice și organizatorice adecvate pentru securitatea prelucrării. Dacă un utilizator privilegiat poate exporta înregistrări despre clienți, accesa categorii speciale de date, dezactiva jurnalele de audit sau modifica setări de retenție fără revizuire, organizația nu a făcut doar o eroare IAM. Este posibil să nu poată demonstra securitate adecvată.
ISO/IEC 27001:2022 este coloana vertebrală a sistemului de management care permite gestionarea acestor obligații printr-un program integrat. Clause 4.2 impune organizației să înțeleagă părțile interesate și cerințele acestora, inclusiv obligațiile legale, de reglementare și contractuale. Clause 5.1 impune leadership și angajament. Clause 6.1.2 impune evaluarea riscurilor de securitate a informației. Clause 6.1.3 impune tratarea riscurilor. Clause 8 impune planificare și control operațional.
Pentru accesul privilegiat, aceasta mută conversația de la „ce instrument PAM ar trebui să cumpărăm?” la „ce riscuri tratăm, ce controale sunt selectate, cine le deține, cum sunt operate și ce dovezi demonstrează că funcționează?”
PAM nu este un singur control, ci un lanț de dovezi
Un instrument PAM poate stoca parole în seif, intermedia sesiuni, înregistra apăsări de taste, roti acreditări și impune acces just-in-time. Aceste capabilități contează. Dar dacă organizația nu a definit rolurile privilegiate, nu a aprobat accesul de urgență, nu a mapat accesul la active, nu a revizuit drepturile, nu a protejat jurnalele și nu a instruit administratorii, instrumentul devine un control parțial, cu o capacitate slabă de susținere în audit.
Cea mai utilă modalitate de a guverna accesul privilegiat este să gândim în rezultate de control, nu în denumiri de instrumente.
Zenith Controls: The Cross-Compliance Guide Zenith Controls tratează controlul ISO/IEC 27002:2022 8.2, Privilegii de acces, ca punct central pentru PAM. Acesta clasifică acest control ca preventiv, susținând confidențialitatea, integritatea și disponibilitatea, aliniat la conceptul de securitate cibernetică Protect, la capabilitatea operațională de management al identității și accesului și la domeniul de securitate Protecție.
Controlul 8.2 este puternic deoarece se conectează la controalele adiacente care fac accesul privilegiat verificabil în audit:
| Control ISO/IEC 27002:2022 | De ce contează pentru PAM și conturile break-glass |
|---|---|
| 5.16 Managementul identității | Fiecare utilizator privilegiat trebuie să aibă o identitate verificată și unică înainte ca accesul cu privilegii ridicate să poată fi controlat. |
| 5.18 Drepturi de acces | Alocarea, revizuirea, modificarea și revocarea trebuie să includă drepturile privilegiate și de urgență. |
| 8.3 Restricționarea accesului la informații | Conturile privilegiate nu trebuie să devină căi necontrolate de ocolire către date sensibile. |
| 8.5 Autentificare securizată | Conturile de administrare și de urgență necesită autentificare mai puternică, precum MFA sau un nivel echivalent de asigurare. |
| 6.7 Lucrul la distanță | Administrarea privilegiată de la distanță necesită canale securizate, monitorizare și condiții restricționate. |
| 8.15 Jurnalizare | Acțiunile privilegiate trebuie înregistrate, protejate și revizuite. |
| 8.16 Activități de monitorizare | Jurnalele trebuie să alimenteze detecția, analiza anomaliilor și răspunsul. |
| 8.18 Utilizarea programelor utilitare privilegiate | Instrumentele administrative capabile să ocolească controale trebuie inventariate, restricționate și jurnalizate. |
De aceea, un auditor rareori se oprește la întrebarea: „Aveți un sistem PAM?” Întrebările de audit mai solide sunt: Aveți un inventar al conturilor privilegiate? Rolurile privilegiate sunt aprobate? Drepturile sunt limitate în timp? Acreditările de urgență sunt securizate? Puteți dovedi cine le-a utilizat? Comenzile sunt jurnalizate? Administratorii furnizorilor sunt incluși? Drepturile de acces sunt revizuite? Acreditările au fost resetate? Excepțiile au fost acceptate ca risc?
Maparea drepturilor de acces din Zenith Controls arată direct acest aspect: managementul drepturilor de acces operaționalizează principiile de control al accesului, precum principiul privilegiului minim, principiul necesității de a cunoaște și autorizarea, în timp ce conturile privilegiate necesită analiză specială și revocare promptă atunci când nu mai sunt necesare.
Cerințe de politică pentru acces break-glass de încredere
Un cont break-glass nu este o parolă de administrator partajată într-un plic sigilat. În 2026, acest model este prea slab pentru cloud, fintech, SaaS, sănătate, servicii administrate și operațiuni digitale reglementate.
Un model break-glass defensabil are nevoie de șapte reguli minime de politică:
- Contul trebuie documentat.
- Contul trebuie aprobat.
- Utilizarea trebuie să fie atribuibilă unic acolo unde este posibil din punct de vedere tehnic.
- Utilizarea trebuie limitată la urgențe reale.
- Utilizarea trebuie jurnalizată și revizuită.
- Acreditările sau factorii de autentificare trebuie resetați ori rotiți după utilizare.
- Contul trebuie testat și inclus în domeniul de audit.
Biblioteca de politici Clarysec transformă aceste principii în limbaj de guvernanță utilizabil.
Politica privind gestionarea conturilor de utilizator și a privilegiilor - SME Politica privind gestionarea conturilor de utilizator și a privilegiilor - SME prevede:
„Accesul de urgență (de exemplu, conturile de administrator „break glass”) trebuie documentat clar, securizat și utilizat numai atunci când este absolut necesar.”
Din secțiunea „Tratarea riscurilor și excepții”, clauza de politică 7.3.1.
Aceeași politică SME continuă:
„Astfel de conturi trebuie jurnalizate, revizuite după utilizare și resetate după fiecare eveniment de urgență.”
Din secțiunea „Tratarea riscurilor și excepții”, clauza de politică 7.3.2.
Pentru escaladarea privilegiilor de zi cu zi, politica SME impune, de asemenea:
„Privilegiile ridicate sau administrative necesită aprobare suplimentară din partea Directorului general sau a responsabilului IT și trebuie documentate, limitate în timp și supuse revizuirii periodice.”
Din secțiunea „Cerințe de implementare a politicii”, clauza de politică 6.2.2.
Pentru organizațiile mai mari, setul de politici pentru întreprinderi merge mai în profunzime. Politica privind gestionarea conturilor de utilizator și a privilegiilor Politica privind gestionarea conturilor de utilizator și a privilegiilor impune ca:
„Sesiunile privilegiate trebuie jurnalizate complet, inclusiv comenzile emise și acțiunile efectuate. Jurnalele trebuie revizuite periodic de revizori desemnați.”
Din secțiunea „Cerințe de implementare a politicii”, clauza de politică 6.4.2.
Aceeași politică impune ca toate conturile temporare sau de urgență cu acces privilegiat să urmeze o procedură break-glass documentată în clauza 6.2.5, iar clauza 7.4 descrie cerințele pentru acea procedură.
Politica de control al accesului Politica de control al accesului consolidează păstrarea în scop de audit:
„Deciziile de aprobare trebuie jurnalizate și păstrate în scopuri de audit pentru o perioadă minimă de 2 ani.”
Din secțiunea „Cerințe de guvernanță”, clauza de politică 5.3.2.
Politica de jurnalizare și monitorizare - SME Politica de jurnalizare și monitorizare - SME identifică așteptările privind jurnalizarea autentificării:
„Jurnale de autentificare: tentative de autentificare reușite și eșuate, durata sesiunii, utilizarea MFA”
Din secțiunea „Cerințe de guvernanță”, clauza de politică 5.4.2.
Împreună, aceste clauze transformă accesul de urgență dintr-o soluție eroică de evitare într-un eveniment controlat. Contul este excepțional, dar guvernanța nu este.
Abordarea Zenith Blueprint pentru implementarea PAM
Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint tratează accesul privilegiat ca pe o problemă practică de implementare, nu ca pe o declarație teoretică de control. În faza „Controale în acțiune”, Pasul 19, „Controale tehnologice I”, acesta afirmă:
„În orice sistem informatic, accesul privilegiat înseamnă putere, iar această putere generează risc.”
Din faza „Controale în acțiune”, Pasul 19: „Controale tehnologice I”.
Pasul 19 impune organizațiilor să identifice conturile privilegiate în medii on-premises, cloud, SaaS, de dezvoltare și de infrastructură. Acesta include administratori de domeniu, utilizatori root, administratori ai tenantului cloud, superutilizatori de baze de date și controlere ale fluxurilor CI/CD. De asemenea, subliniază minimizarea accesului privilegiat prin controale de acces bazate pe roluri, elevare just-in-time și fluxuri de aprobare.
Acest lucru contează deoarece multe incidente grave nu încep cu contul break-glass formal. Încep cu privilegii permanente. Un inginer cloud păstrează drepturi de proprietar „pentru orice eventualitate”. Un administrator de baze de date păstrează acces la mediul de producție după ce se mută în altă echipă. Un cont de serviciu CI/CD are permisiuni largi în mai multe medii. Un cont al unui furnizor de servicii administrate este exceptat de la MFA deoarece „au nevoie de acces rapid”.
Pasul 20 din Zenith Blueprint extinde același raționament la utilitare privilegiate. Acesta instruiește organizațiile să creeze sau să actualizeze un inventar al utilitarelor privilegiate, să restricționeze execuția la administratorii autorizați, să verifice că utilizarea este jurnalizată și are alerte activate și să ia în considerare jurnalizarea scripturilor, cum ar fi jurnalizarea PowerShell prin politici de grup. Acest lucru este critic deoarece un cont privilegiat este adesea doar punctul de intrare. Daunele apar atunci când atacatorul rulează instrumente care dezactivează controale, extrag acreditări sau permit deplasarea laterală.
Pasul 22 formalizează ciclul de viață al controlului accesului. Acesta solicită alocare și deprovisionare structurate, ideal integrate cu HR și susținute de fluxuri de solicitări de acces, cu revizuirea documentată trimestrială a drepturilor de acces. Pasul 16 leagă ciclul de viață de încetarea colaborării prin impunerea unei liste de verificare la încetarea activității angajatului, utilizată în comun de HR și IT, inclusiv dezactivarea conturilor, returnarea activelor și reamintiri privind NDA.
Zenith Blueprint transformă PAM într-un model operațional conectat: identitatea, HR, utilitarele privilegiate, jurnalizarea, răspunsul la incidente, revizuirea drepturilor de acces și dovezile de audit se consolidează reciproc.
Un model practic de guvernanță break-glass pentru 2026
Un proces break-glass bine proiectat trebuie să funcționeze în timpul unei defecțiuni. Dacă depinde de același furnizor de identitate, aceeași platformă de ticketing și același serviciu de chat care sunt indisponibile în timpul întreruperii, este doar teatru.
În același timp, accesul de urgență nu poate deveni un canal de ocolire pentru comoditate. Clarysec proiectează de regulă guvernanța break-glass în jurul a patru straturi: prevenire, activare, observare și recuperare.
| Strat | Obiectiv de control | Dovezi practice |
|---|---|---|
| Prevenire | Reducerea necesității accesului de urgență prin principiul privilegiului minim, acces JIT, redundanță și proceduri de recuperare testate. | Inventar PAM, model RBAC, înregistrări ale revizuirilor accesului, teste de reziliență, Plan de tratare a riscurilor. |
| Activare | Asigurarea faptului că accesul de urgență este utilizat numai pentru urgențe aprobate și este limitat în timp. | Procedură break-glass, tichet de aprobare, declarație de incident, aprobator nominal, marcaj temporal al activării. |
| Observare | Captarea evenimentelor produse în timpul activității privilegiate. | Înregistrarea sesiunii, jurnale de comenzi, jurnale de autentificare, dovezi MFA, alerte SIEM, dovezi privind sincronizarea ceasului. |
| Recuperare | Eliminarea riscului rezidual după utilizarea de urgență. | Rotirea acreditărilor, resetarea contului, revizuire după utilizare, cronologia incidentului, lecții învățate, actualizarea Registrului de riscuri. |
Pentru medii cloud, includeți administratori la nivel de tenant, conturi root cloud, administratori de urgență ai furnizorilor de identitate, conturi de serviciu privilegiate, utilizatori master ai bazelor de date, roluri Kubernetes cluster-admin, chei de implementare CI/CD, administratori ai seifurilor de secrete și conturi de suport ale terților.
Pentru medii hibride, includeți administratori de domeniu, administratori de backup, administratori de hipervizor, administratori de firewall, administratori ai consolei EDR și utilizatori ai utilitarelor privilegiate.
Pentru medii sensibile din perspectiva confidențialității, includeți administratorii care pot accesa baze de date ce conțin date cu caracter personal, jurnale care conțin identificatori, înregistrări HR, date de verificare biometrică a identității, sisteme de monitorizare a fraudei sau instrumente de suport pentru clienți.
Starea țintă este simplu de descris și dificil de simulat: fiecare cale de urgență este cunoscută, aprobată, securizată, observabilă, reversibilă și revizuită.
Un exercițiu de 60 de minute pentru dovezi break-glass
Un CISO sau un manager de conformitate poate derula săptămâna aceasta un exercițiu break-glass util fără a cumpăra un instrument nou. Obiectivul nu este doar confirmarea faptului că funcționează contul. Obiectivul este să se dovedească faptul că acest control produce dovezi.
Scenariu
Presupuneți că furnizorul principal de identitate este degradat. Elevarea normală just-in-time nu este disponibilă. Un cluster de baze de date de producție necesită modificări de configurare de urgență pentru restaurarea serviciului. Contul break-glass de administrator cloud trebuie activat.
Pasul 1: Confirmați că acest cont se află în inventarul conturilor privilegiate
Utilizați Zenith Blueprint, faza „Controale în acțiune”, Pasul 19, pentru a valida că acest cont apare în inventarul conturilor privilegiate. Înregistrați numele contului și mediul, proprietarul de business, proprietarul tehnic, sistemele accesibile, impactul asupra datelor cu caracter personal, metoda de autentificare, locația seifului, metoda de rotire și data ultimului test.
Dacă acest cont lipsește, tratați situația ca o lacună de control și adăugați-o în Registrul de riscuri.
Pasul 2: Verificați alinierea la politici
Mapați evenimentul la cerințele Politicii privind gestionarea conturilor de utilizator și a privilegiilor privind procedurile break-glass documentate și jurnalizarea sesiunilor privilegiate. Dacă sunteți un IMM, utilizați clauzele 7.3.1 și 7.3.2 din Politica privind gestionarea conturilor de utilizator și a privilegiilor - SME ca bază minimă: documentat, securizat, necesar, jurnalizat, revizuit și resetat.
Mapați păstrarea aprobărilor la clauza 5.3.2 din Politica de control al accesului, care impune ca deciziile de aprobare să fie jurnalizate și păstrate timp de cel puțin 2 ani.
Pasul 3: Deschideți o înregistrare de acces de urgență
Creați un tichet sau o înregistrare de incident înainte de activare ori la momentul activării. Includeți:
- Motivul urgenței
- Serviciul afectat
- Contul solicitat
- Solicitantul
- Aprobatorul
- Ora de început
- Ora estimată de finalizare
- Impactul asupra clienților sau impactul de reglementare
- Impactul GDPR asupra datelor cu caracter personal
- Indicator de monitorizare pentru raportare NIS2 sau DORA
Nu așteptați până la final pentru a reconstrui povestea. Valoarea de audit este cea mai puternică atunci când înregistrarea începe înainte ca accesul să fie utilizat.
Pasul 4: Activați și observați
Activați contul break-glass. Confirmați că se utilizează MFA sau o autentificare compensatorie, că sesiunea este înregistrată, că comenzile sau acțiunile administrative sunt jurnalizate, că jurnalele sunt transmise către jurnalizarea centralizată, că sincronizarea timpului susține reconstrucția cronologiei și că se generează o alertă pentru utilizarea contului de urgență.
Aceasta se aliniază cu Zenith Controls pentru 8.15 Jurnalizare, care descrie jurnalizarea ca stratul fundamental de date pentru monitorizare și notează că utilizatorii privilegiați și execuția utilitarelor privilegiate trebuie jurnalizate cuprinzător.
Pasul 5: Închideți, resetați și revizuiți
După sarcina de urgență, dezactivați contul sau readuceți-l în stare sigilată, rotiți acreditările ori resetați factorul de autentificare, revizuiți jurnalele de sesiune, documentați comenzile și schimbările de configurare, confirmați că nu a avut loc acces inutil la date, actualizați înregistrarea incidentului, consemnați lecțiile învățate și decideți dacă sunt declanșate praguri de notificare NIS2, DORA sau GDPR.
Dacă au fost accesate date cu caracter personal, implicați DPO. Dacă evenimentul a cauzat o perturbare a serviciului sau ar putea produce un impact material, implicați proprietarul raportării NIS2 sau DORA. Dacă acel cont break-glass a eșuat, documentați situația ca o constatare de reziliență operațională, nu doar ca o problemă IAM.
Maparea cross-compliance pentru controalele PAM și break-glass
Cel mai solid model de guvernanță nu duplică controalele pentru fiecare reglementare. Construiește un singur lanț de dovezi care susține mai multe obligații.
| Cadru | Relevanța PAM și break-glass | Dovezile pe care auditorii și autoritățile de reglementare le așteaptă |
|---|---|---|
| ISO/IEC 27001:2022 | Evaluarea riscurilor, tratarea riscurilor, Declarația de aplicabilitate, controlul operațional și controalele din Anexa A pentru drepturi de acces, acces privilegiat, jurnalizare, monitorizare, gestionarea incidentelor și continuitate. | Domeniul de aplicare al SMSI, Registrul de riscuri, SoA, politici, revizuirea drepturilor de acces, configurația PAM, jurnale, înregistrări de incidente, acțiuni corective. |
| NIS2 | Article 21 impune măsuri tehnice, operaționale și organizatorice adecvate, inclusiv controlul accesului, managementul activelor, MFA sau autentificare continuă, gestionarea incidentelor și igiena cibernetică. Article 20 face explicită supravegherea de către conducere. | Aprobarea consiliului de administrație, bază de igienă cibernetică, politică de acces privilegiat, dovezi privind revizuirea drepturilor de acces, playbook-uri de raportare a incidentelor, controale pentru administratorii furnizorilor. |
| DORA | Articles 5 și 6 impun management guvernat al riscurilor TIC. Article 17 impune detectarea, înregistrarea, clasificarea, escaladarea incidentelor și recuperarea securizată. Articles 28 până la 30 impun managementul riscului asociat terților TIC și controale contractuale. | Cadru de risc TIC, raportare către management, PAM pentru funcții critice, controale de acces pentru administratori terți, jurnale de incidente, analiza cauzei principale, teste de reziliență. |
| GDPR | Articles 5(1)(f), 5(2), 25 și 32 impun integritate, confidențialitate, responsabilitate, protecția datelor încă din faza de proiectare și măsuri de securitate adecvate. | Minimizarea accesului, revizuiri ale rolurilor de administrator, jurnale privind accesul la date cu caracter personal, referințe DPIA unde este relevant, dovezi privind evaluarea încălcării. |
| NIST CSF 2.0 | Rezultatele GOVERN conectează obligațiile legale, apetitul la risc, rolurile, politicile și supravegherea. Rezultatele PROTECT, DETECT, RESPOND și RECOVER susțin controlul accesului, jurnalele, monitorizarea, răspunsul la incidente și recuperarea. | Profiluri curente și țintă, plan de lacune, înregistrări de guvernanță, monitorizarea jurnalelor, exerciții de răspuns la incidente, documentație de recuperare. |
| COBIT 2019 | O perspectivă de guvernanță și management se concentrează pe valoare, risc, resurse, deținerea procesului, obiective de control și asigurarea privind accesul privilegiat. | Deținerea procesului, RACI, indicatori de performanță ai controalelor, raportare către management, constatări de asigurare, urmărirea remedierii. |
NIST CSF 2.0 este deosebit de util atunci când PAM este tradus într-un profil curent și un profil țintă. Metoda sa de profil începe cu domeniul de aplicare, apoi colectează politici, priorități de risc, registre, cerințe, practici și roluri de lucru, înainte de a crea un plan de acțiune prioritizat. Pentru accesul privilegiat, aceasta înseamnă definirea domeniului profilului în jurul securității identității, administrării cloud, rezilienței la ransomware, sistemelor financiare critice sau accesului furnizorilor.
Pentru entitățile financiare acoperite de DORA, DORA funcționează ca regim sectorial al UE de reziliență cibernetică pentru obligațiile echivalente NIS2 privind riscurile și incidentele. Aceasta nu face NIS2 irelevantă. Înseamnă că entitatea financiară trebuie să utilizeze DORA ca regim de guvernanță pentru cerințele privind riscurile și incidentele TIC, menținând în același timp coordonarea cu strategiile naționale de securitate cibernetică, autoritățile competente și CSIRT-urile, acolo unde este aplicabil.
Cum testează auditorii dovezile privind accesul privilegiat
Auditorii nu evaluează PAM doar citind politica. Ei triangulează politica, configurația, jurnalele, tichetele, interviurile și practica observată.
Metodologia de audit Zenith Controls pentru Privilegii de acces face trimitere la practicile de audit ISO/IEC 19011:2018. Auditorii revizuiesc politicile care definesc drepturile ridicate, procedurile de alocare, monitorizare și revocare. Ei examinează inventarele conturilor de utilizator, înregistrările de atribuire a privilegiilor și jurnalele. Coroborează dovezile prin interviuri, instrumente PAM, servicii de director și eșantioane de jurnale.
| Profilul auditorului | Întrebări tipice privind PAM | Dovezi slabe care generează constatări |
|---|---|---|
| Auditor de sistem de management ISO | Este accesul privilegiat inclus în evaluarea riscurilor, tratare, SoA, politică, control operațional și audit intern? | Politica există, dar fără aprobare din partea proprietarului de risc, fără înregistrări ale revizuirilor accesului, fără urmărirea acțiunilor corective. |
| Evaluator tehnic de controale ISO/IEC 27002:2022 | Conturile privilegiate sunt identificate unic, aprobate, limitate în timp, autentificate puternic, jurnalizate și revizuite? | Conturi de administrator partajate, drepturi de administrator inactive, lipsa jurnalelor de sesiune, lipsa dovezilor de revizuire. |
| Autoritate NIS2 | Poate organizația demonstra controlul accesului, managementul activelor, igiena cibernetică, MFA acolo unde este adecvat și pregătirea pentru incidente? | Acces de urgență netestat, acces de administrator al furnizorilor negestionat, dovezi de incident slabe. |
| Auditor de risc TIC DORA | Poate entitatea financiară să demonstreze supravegherea de către management, maparea funcțiilor critice, clasificarea incidentelor, guvernanța administrării de către terți și testarea rezilienței? | Administratori terți în afara PAM, lipsa dovezilor privind cauza principală, lipsa legăturii cu funcțiile critice sau importante. |
| Auditor GDPR sau revizor DPO | Poate organizația demonstra că accesul privilegiat la date cu caracter personal este minimizat, justificat, jurnalizat și luat în considerare în evaluarea încălcării? | Administratorii pot accesa pe scară largă date cu caracter personal, jurnalele sunt incomplete, evaluarea încălcării nu conține dovezi privind accesul. |
| Auditor orientat ISACA sau COBIT | Cine deține procesul, cum este măsurat, cum sunt aprobate excepțiile și cum știe managementul că funcționează? | Lipsa RACI, lipsa metricilor, excepții negestionate, raportare slabă către management. |
Pentru drepturi de acces, Zenith Controls notează că auditorii eșantionează solicitări de acces ale utilizatorilor, verifică aprobările documentate și confirmă că IT a acordat numai accesul aprobat. De asemenea, compară rolurile utilizatorilor cu drepturile efective, verificând dacă se aplică principiul privilegiului minim. Pentru jurnalizare, auditorii inspectează domeniul jurnalizării, tipurile de evenimente, perioadele de retenție, protecțiile și înregistrările efective din jurnale. Ei evaluează dacă autentificările eșuate, accesul la date sensibile și schimbările de configurare sunt captate și revizuite.
Un pachet bun de dovezi break-glass include:
- Solicitare aprobată de acces de urgență
- Contextul incidentului sau al indisponibilității
- Identitatea utilizatorului care activează accesul
- Identitatea aprobatorului
- Ora de început și de sfârșit
- Dovezi MFA sau de autentificare
- Înregistrarea sesiunii sau jurnalul comenzilor
- Jurnale de sistem și alertă SIEM
- Modificări efectuate
- Confirmarea resetării acreditărilor
- Revizuire după utilizare
- Evaluarea accesului la date
- Evaluarea notificării de reglementare
- Acțiuni corective dacă ceva a eșuat
Dacă exercițiul dumneavoastră nu poate produce acest pachet, controlul nu este pregătit pentru audit.
Eșecul ascuns: accesul privilegiat al terților
Multe organizații guvernează administratorii angajați mai bine decât administratorii furnizorilor. Pentru medii cloud, SaaS, fintech și servicii administrate, aceasta este o inversare periculoasă.
NIS2 Article 21 include securitatea lanțului de aprovizionare și relațiile cu furnizorii direcți și furnizorii de servicii. DORA Articles 28 până la 30 merg mai departe pentru entitățile financiare, impunând strategie privind riscul asociat terților TIC, registre ale contractelor de servicii TIC, verificare prealabilă, evaluarea riscului de concentrare, drepturi de audit, drepturi de încetare, strategii de ieșire și măsuri de securitate contractuale.
Accesul privilegiat al furnizorilor trebuie inclus în domeniul PAM dacă furnizorul poate administra producția, susține funcții critice sau importante, accesa date cu caracter personal, modifica configurații de securitate, gestiona backup-uri, implementa cod sau opera instrumente de monitorizare.
Clarysec se așteaptă de regulă ca accesul privilegiat al furnizorilor să includă următoarele controale:
- Utilizatori nominali ai furnizorului, nu conturi partajate ale furnizorului
- Cerințe contractuale de securitate pentru acces privilegiat
- MFA și acces la distanță securizat
- Ferestre de acces limitate în timp
- Aprobare din partea clientului pentru acces de urgență
- Jurnalizarea sesiunilor sau piste de audit echivalente
- Revocare imediată atunci când personalul se schimbă
- Obligații de cooperare în incidente
- Păstrarea dovezilor aliniată la nevoile de audit ale clientului
- Plan de ieșire pentru eliminarea accesului furnizorului
Rezultatele privind lanțul de aprovizionare din NIST CSF 2.0 se aliniază puternic aici. Acestea solicită roluri și responsabilități ale furnizorilor, prioritizarea furnizorilor pe baza criticității, cerințe în contracte, verificare prealabilă, monitorizare continuă, implicarea furnizorilor în planificarea incidentelor și planuri de risc post-contract.
Dacă un cont al unui furnizor de servicii administrate este exceptat de la fluxul dumneavoastră PAM intern, aceasta nu este o comoditate. Este o excepție cu risc ridicat care aparține în Registrul de riscuri, Registrul furnizorilor și revizuirea drepturilor de acces.
Constatări frecvente privind PAM și break-glass în 2026
În misiunile Clarysec, constatările rareori surprind. De obicei sunt combinații de intenții bune, presiune operațională și dovezi incomplete.
Cele mai frecvente constatări sunt:
- Conturile break-glass există, dar nu sunt listate în inventarul conturilor privilegiate.
- Conturile de urgență sunt excluse din revizuirile normale ale accesului.
- Organizația nu poate dovedi cine a utilizat un cont de urgență.
- Contul nu a fost resetat după utilizare.
- Sesiunile privilegiate sunt jurnalizate, dar comenzile nu sunt.
- Jurnalele există local, dar nu sunt protejate împotriva utilizatorilor privilegiați.
- Conturile root cloud nu sunt testate.
- Procesele de recuperare MFA sunt nedocumentate.
- Accesul privilegiat pentru fluxuri CI/CD și conturi de serviciu este ignorat.
- Accesul de suport al terților ocolește aprobarea internă.
- Aprobarea accesului există în mesaje de chat, dar nu este păstrată ca dovadă de audit.
- Încetarea colaborării elimină e-mailul și VPN, dar nu drepturile de administrator SaaS.
- DPO nu este implicat atunci când accesul privilegiat poate expune date cu caracter personal.
- Playbook-urile de incident nu includ puncte de decizie privind notificarea NIS2, DORA sau GDPR.
Fiecare constatare poate fi gestionată prin tratarea riscurilor conform ISO/IEC 27001:2022. Identificați riscul, desemnați un proprietar, selectați controale, actualizați Declarația de aplicabilitate, implementați planul de tratare și păstrați dovezi documentate. Aceasta este forța utilizării unui SMSI în locul unui set dispersat de sarcini de securitate.
Cum arată un model bun
Un model operațional PAM și break-glass matur are cinci rutine repetitive.
În primul rând, inventariați accesul privilegiat lunar sau continuu. Includeți administratori umani, conturi de serviciu, conturi de urgență, roluri cloud, identități CI/CD, utilizatori de baze de date, utilitare privilegiate și administratori terți.
În al doilea rând, aplicați principiul privilegiului minim prin roluri, elevare just-in-time și aprobări. Privilegiile permanente trebuie să fie rare, justificate și revizuite mai frecvent decât accesul utilizatorilor standard.
În al treilea rând, monitorizați comportamentul privilegiat. Jurnalizați autentificarea, durata sesiunii, utilizarea MFA, comenzile, schimbările de configurare, exporturile de date, tentativele eșuate, escaladarea privilegiilor și execuția utilitarelor privilegiate.
În al patrulea rând, testați conturile break-glass înainte de urgență. Un cont break-glass care nu a fost testat niciodată este o ipoteză, nu un control.
În al cincilea rând, raportați către management. NIS2 și DORA ridică securitatea cibernetică și riscul TIC la nivelul responsabilității organului de conducere. Consiliul de administrație nu are nevoie de fiecare jurnal de comandă, dar are nevoie de metrici: numărul conturilor privilegiate, revizuiri restante, activări de urgență, conturi de administrator ale furnizorilor, teste eșuate, excepții critice și starea remedierii.
Aici setul de instrumente Clarysec devine practic. Biblioteca de politici oferă limbajul de guvernanță. Zenith Blueprint oferă secvența de implementare. Zenith Controls oferă maparea cross-compliance, relațiile dintre controale, standardele suport și metodologia de audit.
Pași următori: transformați accesul de urgență în reziliență pregătită pentru audit
Dacă organizația dumneavoastră nu a testat accesul break-glass în ultimele 90 de zile, începeți de acolo. Nu începeți cu un workshop de selecție a instrumentelor. Începeți cu dovezile.
- Construiți sau actualizați inventarul conturilor privilegiate.
- Identificați fiecare cont break-glass și fiecare cale de administrare de urgență.
- Mapați fiecare cont la proprietarul de business, proprietarul de sistem și impactul asupra datelor.
- Confirmați acoperirea prin politici utilizând Politica privind gestionarea conturilor de utilizator și a privilegiilor Politica privind gestionarea conturilor de utilizator și a privilegiilor sau Politica privind gestionarea conturilor de utilizator și a privilegiilor - SME Politica privind gestionarea conturilor de utilizator și a privilegiilor - SME.
- Utilizați Zenith Blueprint Zenith Blueprint, faza „Controale în acțiune”, Pașii 19, 20, 22 și 16, pentru a conecta accesul privilegiat, utilitarele privilegiate, revizuirile ciclului de viață și încetarea colaborării.
- Utilizați Zenith Controls Zenith Controls pentru a mapa controalele ISO/IEC 27002:2022 8.2, 5.18 și 8.15 la așteptările de dovezi NIS2, DORA, GDPR și NIST.
- Derulați un exercițiu de dovezi break-glass și înregistrați rezultatele.
- Adăugați lacunele în planul de tratare a riscurilor și urmăriți remedierea până la închidere.
Accesul privilegiat înseamnă putere. Accesul break-glass înseamnă putere de urgență. În 2026, organizațiile care se recuperează curat după ransomware, indisponibilități cloud și eșecuri ale identității vor fi cele care pot dovedi că accesul de urgență a fost controlat înainte, în timpul și după criză.
Clarysec vă poate ajuta să construiți această dovadă, de la politici la maparea controalelor și până la dovezi pregătite pentru audit. Începeți cu Zenith Blueprint, combinați-l cu Politica privind gestionarea conturilor de utilizator și a privilegiilor și Politica de control al accesului, apoi utilizați Zenith Controls pentru a arăta cum programul dumneavoastră PAM susține ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 și COBIT 2019.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
