NIS2 și securitatea credențialelor: ce cere Articolul 21 și cum dovedești că funcționează
de Claudiu Hulea · IT Management Consultant
NIS2 a mutat securitatea credențialelor din zona de „bună practică” în cea de obligație legală. În România, directiva (UE) 2022/2555 e transpusă prin OUG 155/2024 și Legea 124/2025, cu DNSC drept autoritate (detalii despre încadrare, termene și sancțiuni în articolul nostru NIS2 în România). Dar legea nu îți spune ce să cumperi. Spune ce rezultate trebuie să obții. Diferența asta e tot subiectul de mai jos.
Acest material e informativ, nu consultanță juridică: pentru situația ta specifică, verifică la DNSC și cu un consultant.
Ce cere de fapt Articolul 21
Articolul 21 enumeră măsuri minime de gestionare a riscurilor, proporționale cu expunerea. Pentru credențiale și acces, relevante sunt:
- igiena de bază și formarea personalului (21(2)(g)), inclusiv cum sunt create, folosite și schimbate parolele;
- controlul accesului, securitatea resurselor umane și gestionarea activelor (21(2)(i)): cine are acces la ce, pe ce durată, și inventarul a ceea ce trebuie protejat;
- autentificarea cu mai mulți factori sau continuă, acolo unde e cazul (21(2)(j));
- politici de criptografie și criptare (21(2)(h)), relevante pentru cum sunt stocate secretele, nu doar traficul;
- proceduri care evaluează dacă măsurile funcționează (21(2)(f)), partea pe care o ignoră cei mai mulți.
Observă ce lipsește: numele vreunui produs. Legea descrie proprietăți ale sistemului tău, nu un raft de magazin.
„Acolo unde e cazul” nu înseamnă „opțional”
Formularea de la MFA, „acolo unde e cazul”, e des înțeleasă greșit drept portiță. Nu e. Înseamnă proporționalitate: tu decizi unde riscul justifică controlul, dar decizia trebuie să fie una conștientă, documentată și apărabilă.
Pe un acces expus pe internet sau pe un cont privilegiat, lipsa MFA e greu de justificat în fața unui incident. Costul poate ordona implementarea în timp, poate să amâne un segment cu risc scăzut, dar nu poate fi scuza pentru un acces critic lăsat pe parolă simplă. Întrebarea la care trebuie să ai răspuns nu e „ai MFA peste tot?”, ci „poți arăta de ce ai pus MFA aici și nu acolo?”.
Secretele nu sunt doar parolele oamenilor
Când aud „credențiale”, multe organizații se gândesc la parolele angajaților. Partea periculoasă e alta: cheile API, tokenurile, conturile de serviciu, cheile SSH și certificatele. Sunt credențiale care adesea au mai multe drepturi decât orice utilizator uman, trăiesc în fișiere de configurare, în variabile de mediu, în scripturi și în istoricul de versiuni, și nu expiră singure.
Controlul accesului și gestionarea activelor din Articolul 21 le includ explicit. Nu poți proteja ce nu știi că există, așa că primul pas e un inventar: ce secrete ai, unde stau, cine și ce le folosește. Un secret uitat într-un repository sau într-un fișier de config este exact tipul de acces pe care grupurile oportuniste îl caută întâi.
Proba că funcționează, nu doar politica
Aici e miezul și, de fapt, teza pe care o repetăm des: un control pe care nu îl poți demonstra este, pentru un auditor, un control care nu există. Articolul 21(2)(f) cere proceduri care evaluează eficacitatea măsurilor. Practic, la o verificare DNSC nu contează că ai o politică de parole într-un document, ci că poți arăta:
- loguri de acces care dovedesc cine a intrat, unde și când;
- date de revizie ale drepturilor, cu dovada că accesele inutile au fost scoase;
- înregistrarea excepțiilor, cu motiv și termen, nu derogări tăcute.
O politică fără probe e o afirmație. Dovada o transformă în control. Am dezvoltat ideea asta separat, fiindcă e valabilă dincolo de NIS2, în controlul care trece testul.
Ce faci concret, proporțional cu riscul
Fără a cumpăra nimic anume, ordinea care rezistă unei verificări:
- Inventariază credențialele și secretele, umane și tehnice, și unde trăiesc.
- Aplică privilegiul minim și revizuiește periodic drepturile, cu dovada reviziei.
- Pune MFA pe accesele expuse și privilegiate întâi, apoi extinde, documentând deciziile.
- Scoate secretele din cod și din fișierele de config și tratează-le ca active gestionate.
- Loghează accesul și rotește credențialele, mai ales după plecări (vezi și omul care pleacă).
- Strânge dovezile pe măsură ce lucrezi, nu cu o zi înainte de audit.
Ce reținem
NIS2 nu îți cere un produs, îți cere o proprietate verificabilă: accesele sunt controlate, autentificarea e pe măsura riscului, secretele sunt gestionate, iar toate astea pot fi demonstrate. Cine citește Articolul 21 ca pe o listă de cumpărături ratează esența. Cine îl citește ca pe o listă de rezultate pe care trebuie să le poată proba ajunge și conform, și efectiv mai sigur.
Vrei să știi unde stai față de cerințele NIS2 pe control al accesului și credențiale, și ce ai de remediat prioritar? Scrie-ne și pornim de la un audit.
Surse
Întrebări frecvente
NIS2 obligă la un manager de parole?
Nu. Articolul 21 cere rezultate, nu produse: control al accesului, igienă de bază, autentificare puternică acolo unde e cazul și dovada că măsurile funcționează. Cum le obții e alegerea ta, proporțional cu riscul. Niciun text legal nu numește o unealtă anume.
Ce înseamnă „acolo unde e cazul” la MFA (Articolul 21(2)(j))?
Că decizia e proporțională cu riscul: tu stabilești unde expunerea justifică controlul. Costul poate justifica ordinea în care implementezi, nu absența controlului pe un acces expus pe internet sau privilegiat. Important e să poți explica decizia, nu să o lași nedocumentată.
De ce nu e suficientă o politică scrisă?
Fiindcă Articolul 21(2)(f) cere proceduri care evaluează dacă măsurile chiar funcționează. La o verificare, o politică fără probe (loguri de acces, date de revizie, înregistrarea excepțiilor) e tratată ca un control care nu există.
Secretele tehnice intră la „credențiale”?
Da. Cheile API, tokenurile, conturile de serviciu, cheile SSH și certificatele sunt tot credențiale, adesea cu mai multe drepturi decât o parolă de utilizator. Controlul accesului și gestionarea activelor din Articolul 21 le includ, iar ele sunt exact partea pe care organizațiile o pierd din vedere.
