Ce este single sign-on? Ghid pentru guvernanța identităților și controlul accesului în context NIS2

Articol scris de Dragoș Burnescu, O365 L2 Engineer

Un angajat uită o parolă. Se întâmplă de zeci de ori pe zi într-o companie mare. Multiplică asta cu zece aplicații diferite, fiecare cu propria parolă, și ai un departament IT care petrece ore bune pe resetări în loc să facă muncă de securitate reală. Aici intervine single sign-on. O singură autentificare deschide ușa către toate aplicațiile de care are nevoie persoana respectivă.

 

Single sign-on (SSO) este mecanismul prin care un utilizator se autentifică o singură dată, la un furnizor central de identitate, și primește acces la mai multe aplicații fără să reintroducă parola.

 

Sună ca o simplificare și chiar este, până la un punct. Centralizarea accesului reduce fricțiunea, dar concentrează și riscul într-un singur loc. NIS2 nu cere explicit SSO, însă cere politici de control al accesului și, după caz, autentificare puternică. SSO devine astfel o decizie de guvernanță, nu doar o alegere tehnică. Întrebarea reală: cum obții confortul fără să transformi furnizorul de identitate într-un punct unic de eșec?

Single sign-on centralizează accesul printr-un furnizor de identitate, care devine astfel un activ critic de protejat.

 

Ce înseamnă de fapt SSO și cu ce nu trebuie confundat

Termenii din zona de identitate se amestecă des în discuții, chiar și între profesioniști. SSO, IAM, federație, provisioning. Par sinonime, dar fac lucruri diferite. Clarificarea lor nu e pedanterie, pentru că fiecare acoperă o altă parte a problemei de securitate.

 

SSO, IAM și federarea identităților

SSO rezolvă experiența de autentificare. O conectare, mai multe aplicații. Managementul identității și al accesului, pe scurt IAM, este cadrul mai larg care guvernează întreg ciclul de viață al unei identități digitale, de la crearea contului până la ștergerea lui. Federarea identităților merge dincolo de granițele unei singure organizații sau ale unui singur domeniu, permițând unei identități dintr-un sistem să fie recunoscută în altul. Practic, SSO este o funcție, IAM este sistemul care o conține, iar federația este mecanismul care extinde încrederea între domenii.

Un hub central de identitate conectează aplicațiile și serviciile companiei, simplificând accesul și controlul identităților într-un singur punct.

 

Provisioning, deprovisioning și conturile orfane

Un cont nou nu apare din senin. Cineva îl creează, îi atribuie drepturi, îl leagă de grupuri. Acesta e provisioning-ul. Reversul, deprovisioning-ul, se întâmplă când o persoană pleacă din organizație și contul ei ar trebui dezactivat. Aici apare o problemă frecventă: conturile orfane. Angajatul a plecat acum șase luni, dar contul lui e încă activ undeva, într-o aplicație pe care nimeni n-a legat-o de procesul central.

Revocarea centralizată ajută, dar trebuie formulată cu grijă. Poate fi automatizată sau accelerată, însă eficiența ei depinde de cât de bine e integrată fiecare aplicație și de durata sesiunilor active. Dacă o aplicație legacy nu vorbește cu furnizorul de identitate, revocarea din centru n-o atinge. Sincronizarea automată, prin standarde precum SCIM, reduce riscul, dar nu îl elimină complet.

 

RBAC și logica de autorizare

Autentificarea confirmă cine ești. Autorizarea decide ce ai voie să faci. Controlul accesului bazat pe roluri, prin RBAC, leagă drepturile de rolul persoanei, nu de identitatea ei individuală. Un contabil primește accesul rolului „contabilitate”, nu o listă personalizată de permisiuni. E mai curat și mai ușor de auditat, dar are o capcană: un grup configurat greșit poate extinde accesul mult peste intenție, fără ca nimeni să observe imediat.

 

Protocoalele din spate: SAML, OAuth și OpenID Connect

SSO nu funcționează prin magie. În spate lucrează protocoale standardizate. SAML 2.0 este cel clasic, folosit mult în mediile enterprise pentru federație. OAuth 2.0 gestionează autorizarea, adică delegarea accesului fără partajarea parolei. OpenID Connect adaugă un strat de autentificare peste OAuth. Nu intrăm în configurarea lor aici, pentru că scopul articolului e de guvernanță, nu de implementare tehnică. Important e să știi că alegerea protocolului influențează ce aplicații pot fi integrate și cât de solidă e federația.

 

Ce câștigă efectiv organizația din SSO

Beneficiile SSO se vând ușor într-o prezentare. În realitate, fiecare vine cu o limitare pe care merită s-o cunoști dinainte, ca să nu ai surprize după implementare.

Beneficiu	Mecanism	Limitare
Mai puține parole	Autentificare centrală, o singură identitate	Furnizorul de identitate devine critic
Mai puține tichete de resetare	Politici de parolă aplicate central	Nu elimină toate problemele de acces
Revocare mai rapidă	Integrare directă cu aplicațiile	Aplicațiile legacy pot rămâne independente
Vizibilitate mai bună	Loguri și registru central de acces	Logurile trebuie efectiv monitorizate
Acces coerent pe roluri	RBAC și grupuri de securitate	Grupurile greșit configurate extind accesul

Observi tiparul? Fiecare beneficiu are un „da, dar”. SSO reduce numărul de parole, însă face furnizorul de identitate indispensabil. Oferă vizibilitate prin loguri, dar logurile nemonitorizate sunt doar date care ocupă spațiu. Beneficiul real apare doar când limitarea e gestionată conștient, nu ignorată.

O precizare de onestitate: nu voi afirma că angajații folosesc „în medie zeci de aplicații”, pentru că n-am o sursă verificată pentru o astfel de cifră. Ce se poate spune cu certitudine e că numărul aplicațiilor de business a crescut semnificativ odată cu adoptarea SaaS, iar fiecare aplicație cu propria parolă e o oportunitate în plus pentru un atacator.

 

Autentificarea puternică: nu toate formele de MFA sunt egale

Multă lume pune semn de egalitate între „avem MFA” și „suntem protejați”. Realitatea e mai nuanțată. Unele forme de autentificare multifactor rezistă la atacuri moderne, altele cad la primul phishing bine construit.

 

Nivelurile de autentificare diferă radical în rezistența la phishing; MFA prin SMS și cea criptografică nu oferă aceeași protecție.

 

O ierarhie a nivelurilor de protecție

Gândește protecția autentificării ca pe o scară, nu ca pe un comutator pornit sau oprit:

1. parola singură, cel mai slab nivel;
2. MFA prin SMS sau cod primit pe telefon;
3. MFA printr-o aplicație de autentificare sau token hardware;
4. autentificare criptografică, bazată pe certificate;
5. FIDO2 și passkeys, cu protecție nativă împotriva phishingului.

1.  

1.  

1.  

1.  

De ce SMS-ul nu mai e suficient pentru conturi sensibile

SMS-ul a fost un progres uriaș față de parola simplă. Azi are vulnerabilități cunoscute. Atacul de tip SIM swap permite unui atacator să preia numărul de telefon al victimei și, odată cu el, codurile primite prin SMS. Interceptarea mesajelor e și ea posibilă în anumite condiții. Pentru conturile obișnuite, SMS-ul tot e mai bun decât nimic. Pentru administratori și date sensibile, e un nivel pe care nu te poți baza.

Un alt punct des ratat: un cod OTP introdus manual nu este considerat, în general, autentificare rezistentă la phishing. Dacă utilizatorul poate fi păcălit să tasteze codul pe un site fals, protecția dispare. Rezistența reală la phishing vine din metode criptografice legate de domeniu, precum FIDO2, unde cheia pur și simplu nu funcționează pe un site fraudulos.

 

Conditional Access și confirmarea intenției

Autentificarea puternică nu înseamnă doar factorul în sine, ci și contextul. Conditional Access evaluează locația, dispozitivul, nivelul de risc și comportamentul înainte de a acorda accesul. O conectare de pe un dispozitiv gestionat, din biroul obișnuit, trece ușor. Aceeași conectare de pe un dispozitiv necunoscut, dintr-o altă țară, la ora trei noaptea, declanșează verificări suplimentare sau blocare.

Mai e un fenomen de care trebuie ținut cont: MFA fatigue. Atacatorul bombardează utilizatorul cu notificări de aprobare până când, enervat sau neatent, acesta apasă „aprob”. Soluția e confirmarea intenției, prin metode care cer utilizatorului să introducă un număr afișat pe ecran, nu doar să apese un buton. Pentru contexte deosebit de sensibile, certificatele și cheile hardware de securitate oferă cel mai înalt nivel.

 

Despre nivelurile AAL

Cadrul NIST definește niveluri de asigurare a autentificării, cunoscute ca AAL (Authentication Assurance Levels), în publicația actuală NIST SP 800-63-4. Acestea oferă un limbaj comun pentru a discuta cât de solidă e o metodă de autentificare. De reținut un lucru: AAL este un cadru tehnic NIST, util ca referință, nu o obligație nominală impusă de NIS2. NIS2 cere autentificare adecvată riscului, iar AAL te ajută să traduci „adecvat” în decizii concrete.

 

Conturile privilegiate: unde SSO concentrează cel mai mult risc

Un administrator nu e un utilizator ca oricare altul. Are chei la aproape tot. De aceea valoarea lui pentru un atacator e disproporționat de mare. Compromiterea unui cont obișnuit e o problemă. Compromiterea unui cont de administrator e un dezastru.

 

Un cont de administrator este o țintă de valoare mare; accesul just-in-time reduce fereastra în care poate fi exploatat.

 

Accesul permanent versus accesul temporar

Modelul vechi dădea administratorilor drepturi permanente. Ești admin, rămâi admin, non-stop. Problema e evidentă: un cont cu privilegii permanente e o țintă permanentă. Modelul modern înlocuiește, unde se poate, accesul permanent cu acces temporar, acordat doar când e nevoie și expirat automat după. Principiul se numește just-in-time, iar logica e simplă. Dacă privilegiile există doar în fereastra în care sunt folosite, suprafața de atac se micșorează drastic restul timpului.

 

Igiena conturilor administrative

Câteva reguli care par de bun simț, dar sunt încălcate constant în practică:

• conturile administrative nu se folosesc pentru activități obișnuite, precum cititul e-mailului sau navigarea;
• privilegiile ridicate ar trebui să expire automat, nu să rămână active la nesfârșit;
• sesiunile administrative trebuie înregistrate și corelate cu identitatea persoanei reale din spate;
• accesul privilegiat se revizuiește separat de accesul standard, cu o frecvență mai mare;
• fiecare acțiune administrativă ar trebui să fie atribuibilă unei persoane, nu unui cont generic partajat.

•  

•  

•  

•  

Pentru organizațiile din ecosistemul Microsoft, instrumente precum Azure PIM, Entra ID și Conditional Access pot pune în practică aceste principii. Le menționez ca exemple tehnice pentru cine folosește deja Microsoft, nu ca soluții obligatorii pentru NIS2. Directiva cere rezultatul, controlul privilegiilor, nu un produs anume.

 

Când cade furnizorul de identitate: SSO ca punct unic de eșec

Iată scenariul care ține CISO treaz noaptea. Ai centralizat totul prin SSO. Furnizorul de identitate cade. Nimeni nu se mai poate autentifica nicăieri. Toată organizația, blocată afară din propriile aplicații. Centralizarea care aducea confort devine, într-o clipă, vulnerabilitatea maximă.

 

Reziliența furnizorului de identitate se construiește prin redundanță, arhitectură hibridă și conturi break-glass izolate și monitorizate.

 

Trei scenarii distincte, trei răspunsuri diferite

„Furnizorul de identitate are o problemă” nu e o singură situație. Sunt trei, și fiecare cere altă reacție:

• IdP indisponibil, fără indicii de compromitere. E o problemă de disponibilitate. Răspunsul ține de continuitate: failover, redundanță, acces de urgență.
• IdP compromis, cu risc asupra mai multor aplicații. E o problemă de securitate. Răspunsul include izolare, investigație și, posibil, revocarea sesiunilor.
• Pierderea conectivității dintre aplicație și IdP. E o problemă de rețea sau integrare. Răspunsul ține de arhitectură și de rutele alternative.

•  

•  

Cum construiești reziliența

Protecția împotriva căderii IdP se construiește pe mai multe straturi. Redundanța și failover-ul asigură că o singură defecțiune nu oprește totul. O arhitectură multi-regiune, acolo unde e disponibilă și justificată de risc, distribuie dependența geografic. O arhitectură hibridă poate menține un nivel de acces chiar când componenta cloud e indisponibilă. Conturile break-glass, izolate și folosite exclusiv în urgențe, oferă o cale de intrare când totul cedează.

Nu descriu aici pașii de creare a unui cont break-glass, pentru că nu e un tutorial. Principiile de guvernanță contează mai mult: aceste conturi trebuie izolate de SSO, protejate cu cele mai puternice metode disponibile, iar folosirea lor trebuie monitorizată strict. Un cont break-glass folosit fără o urgență declarată e un semnal de alarmă în sine. Și, la fel de important, procedurile de recuperare trebuie testate. Un plan de continuitate netestat e doar un document.

 

Dependența de un singur furnizor cloud

Dacă furnizorul tău de identitate și cea mai mare parte a infrastructurii stau la același furnizor cloud, ai un risc dublu: de furnizor și de continuitate. O cădere majoră a acelui furnizor îți poate afecta simultan și accesul, și aplicațiile. Nu înseamnă că trebuie evitat un singur furnizor cu orice preț, dar înseamnă că dependența trebuie recunoscută explicit și gestionată, nu ignorată pentru că „până acum a mers”.

 

Ce leagă SSO de cerințele NIS2

NIS2 nu pomenește SSO pe nume. Cere însă o serie de măsuri pe care SSO, bine implementat, le poate susține. Legătura e indirectă, dar reală.

Măsură	Obiectiv
Controlul accesului	Limitarea accesului neautorizat la sisteme
MFA și autentificare continuă	Reducerea riscului de utilizare abuzivă a identității
Jurnalizare	Detectarea și investigarea incidentelor
Revizuirea privilegiilor	Aplicarea principiului least privilege
Redundanță	Continuitatea serviciilor esențiale
Evaluarea furnizorilor	Reducerea riscului de lanț de aprovizionare

 

Ce spune concret articolul 21

Articolul 21 din Directiva NIS2 menționează politicile de control al accesului și, după caz, utilizarea autentificării cu mai mulți factori sau a soluțiilor de autentificare continuă. SSO este o opțiune de implementare care poate ajuta la îndeplinirea acestor cerințe, nu o obligație explicită. Poți fi conform NIS2 și fără SSO, dacă ai alt mod de a controla accesul. SSO devine atractiv pentru că centralizează controlul și face mai ușoară aplicarea coerentă a politicilor, nu pentru că ar fi impus.

 

Contextul legislativ românesc

La nivel național, NIS2 a fost transpusă prin OUG nr. 155/2024, aprobată și modificată prin Legea nr. 124/2025, cu DNSC în rol de autoritate competentă. Forma legislativă exactă și actele subsecvente trebuie verificate la data implementării, pentru că detaliile se pot ajusta prin norme ulterioare. Scopul aici rămâne operațional, nu juridic.

 

Monitorizare, semnale de atac și raportarea incidentelor

Logurile de autentificare sunt o mină de aur pentru detectarea atacurilor, cu o condiție: cineva să se uite la ele. Un furnizor de identitate care generează loguri pe care nu le monitorizează nimeni oferă vizibilitate doar pe hârtie.

 

Integrarea cu SIEM și SOAR

Logurile de la furnizorul de identitate ar trebui să curgă într-un sistem de tip SIEM, care centralizează și corelează evenimentele de securitate. Acolo unde există automatizări mature, un sistem SOAR poate declanșa răspunsuri automate la anumite semnale, precum blocarea unui cont suspect. Integrarea asta transformă logurile din arhivă pasivă în instrument activ de detecție.

 

Semnale care merită investigate

Câteva tipare care, în zona de identitate, cer o privire mai atentă:

• password spraying, adică încercarea aceleiași parole pe multe conturi;
• autentificări din locații imposibil de reconciliat în timp, așa-numitul „imposibil travel”;
• schimbări neobișnuite ale apartenenței la grupuri;
• escaladări bruște de privilegii;
• folosirea unui cont break-glass;
• modificări ale configurației de federare;
• tentative de preluare a sesiunii, prin session hijacking.

•  

•  

•  

•  

•  

•  

Un lucru de reținut: aceste semnale sunt indicii pentru analiză, nu confirmări automate ale unui atac. Un „imposibil travel” poate fi un VPN, nu un atacator. Rolul lor e să îndrepte atenția analistului, nu să declanșeze panică.

 

Termenele de raportare în România

Când un incident devine semnificativ, intervin obligații de raportare cu termene stricte. OUG 155/2024 prevede o avertizare timpurie în cel mult 24 de ore, o notificare în cel mult 72 de ore și un raport final în termen de o lună. Logurile ajută la evaluarea incidentului, dar nu înlocuiesc procesul de clasificare și raportare. Datele îți spun ce s-a întâmplat; decizia dacă e „semnificativ” și raportarea rămân responsabilitatea organizației.

 

Control demonstrabil: diferența dintre ce scrie și ce e

Aici e cea mai frecventă capcană în conformitate. O politică scrisă frumos nu dovedește nimic dacă realitatea din sisteme nu o reflectă. Un control DNSC nu se mulțumește cu documentul; cere dovada că e aplicat.

 

Patru straturi care trebuie să coincidă

Între intenție și realitate sunt mai multe niveluri, și ele nu coincid automat:

• politica declarată, ce spui că faci;
• configurația reală, ce e setat efectiv în sisteme;
• accesul efectiv, cine chiar poate ajunge la ce;
• dovezile generate de sistem, ce poți arăta la un control.

•  

•  

•  

Exemplul clasic: politica prevede MFA obligatoriu pentru toți administratorii. Sună bine. Dar verificarea reală trebuie să arate dacă MFA este chiar activă în configurație și, mai ales, dacă există excepții strecurate în timp. Un singur administrator exceptat „temporar” acum un an, uitat acolo, sparge toată politica. Diferența dintre ce scrie în document și ce e activ în sistem poate fi exact gaura prin care intră atacatorul.

 

De la verificarea anuală la monitorizarea continuă

Mulți tratează verificarea configurației ca pe un ritual de dinainte de audit. Odată pe an, cu o săptămână înainte, cineva trece prin setări. Problema e că restul anului configurația trăiește singură. Se adaugă excepții, se modifică grupuri, apar conturi noi. Monitorizarea continuă sau periodică a configurației, nu doar verificarea anuală, e ce îți arată realitatea pe măsură ce se schimbă, nu cu luni întârziere.

 

Cum vă poate ajuta Security OptiApp

Pentru organizațiile care vor să reducă distanța dintre politica declarată și postura tehnică reală, o platformă precum Security OptiApp poate servi ca sursă de evaluare a configurației efective și a drepturilor privilegiate. Rolul ei practic e să adune într-un loc postura tehnică și dovezile, astfel încât diferența dintre „ce spunem că facem” și „ce e activ în sisteme” să devină vizibilă, nu ascunsă până la următorul audit.

Dacă integrările cu Entra ID, Conditional Access, MFA și Azure PIM sunt confirmate pentru versiunea utilizată, acestea pot fi folosite ca surse tehnice pentru a verifica dacă politicile de acces sunt efectiv aplicate și unde există excepții. De precizat onest: Security OptiApp nu este un audit formal, o certificare sau o garanție de conformitate. Rolul ei e să ofere vizibilitate și dovezi, nu să înlocuiască procesul de evaluare independentă. Mai multe pe Security OptiApp.

Single sign-on nu e nici panaceu, nici capcană. E o decizie de guvernanță care, bine condusă, reduce fricțiunea și face controlul accesului coerent și demonstrabil. Prost condusă, concentrează riscul într-un punct pe care un atacator abia așteaptă să-l găsească. Diferența nu stă în tehnologie, ci în felul în care gestionezi conturile privilegiate, autentificarea puternică, reziliența furnizorului de identitate și distanța dintre politică și realitate.

Centralizarea accesului merită efortul doar dacă vine la pachet cu reziliență și cu dovezi. Întrebarea de verificat nu e „avem SSO?”, ci „dacă furnizorul de identitate cade sau este compromis mâine, cât de repede ne revenim și ce putem demonstra?”

 

Întrebări frecvente despre single sign-on și NIS2

Ce este single sign-on?

Este mecanismul prin care un utilizator se autentifică o singură dată, la un furnizor central de identitate, și primește acces la mai multe aplicații fără să reintroducă parola pentru fiecare.

SSO este obligatoriu pentru NIS2?

Nu. NIS2 cere politici de control al accesului și, după caz, autentificare puternică. SSO este o opțiune de implementare care ajută la îndeplinirea acestor cerințe, nu o obligație explicită.

Care este diferența dintre SSO și MFA?

SSO se ocupă de experiența de autentificare, o conectare pentru mai multe aplicații. MFA adaugă factori suplimentari de verificare a identității. Cele două se completează, nu se exclud.

De ce MFA prin SMS nu este suficientă pentru administratori?

SMS-ul e vulnerabil la atacuri precum SIM swap și la interceptare. Pentru conturi sensibile sunt recomandate metode rezistente la phishing, precum FIDO2 sau cheile de securitate hardware.

Ce sunt conturile orfane?

Sunt conturi rămase active după ce persoana a plecat din organizație, de obicei în aplicații neintegrate cu procesul central de deprovisioning. Reprezintă o cale de acces uitată și periculoasă.

Ce este un cont break-glass?

Este un cont de urgență, izolat de SSO și protejat cu cele mai puternice metode, folosit exclusiv când furnizorul de identitate este indisponibil. Utilizarea lui trebuie monitorizată strict.

Ce se întâmplă dacă furnizorul de identitate cade?

Fără măsuri de reziliență, accesul la toate aplicațiile integrate se blochează. De aceea sunt necesare redundanța, failover-ul, eventual o arhitectură multi-regiune și conturi break-glass testate.

Ce este accesul just-in-time pentru conturile privilegiate?

Este modelul în care drepturile de administrator se acordă temporar, doar când sunt necesare, și expiră automat după. Reduce fereastra în care un cont privilegiat poate fi atacat.

Care sunt termenele de raportare a incidentelor în România?

OUG 155/2024 prevede avertizare timpurie în cel mult 24 de ore, notificare în cel mult 72 de ore și raport final în termen de o lună pentru incidentele semnificative.

De ce nu e suficientă o politică scrisă pentru conformitate?

Pentru că un control verifică dacă politica este efectiv aplicată în configurația reală. Diferența dintre ce scrie în document și ce e activ în sisteme, mai ales excepțiile, este exact ce caută un auditor.

 

Despre Echipa Optimizor

Consultanță și servicii IT gestionate pentru organizații cu infrastructuri hibride. Specializare în securitate, guvernanța identității, conformitate NIS2 și ecosistemul Microsoft, cu certificările ISO 20000-1 și ISO 9001. Optimizor este dezvoltatorul soluției Security OptiApp și furnizor de servicii IT gestionate în România. Analiza din acest articol se bazează pe surse publice primare și pe practica operațională a echipei, fără ajustări favorabile produsului propriu. Cerințele legale concrete și nivelurile tehnice de autentificare trebuie verificate în normele și actele subsecvente aplicabile la data implementării.

 

Surse

1. Directiva (UE) 2022/2555 (NIS2), articolul 21 privind măsurile de gestionare a riscurilor de securitate cibernetică. Parlamentul European și Consiliul UE, 2022. eur-lex.europa.eu
2. NIST SP 800-63-4, Digital Identity Guidelines, Authentication Assurance Levels. National Institute of Standards and Technology, 2024. csrc.nist.gov
3. OUG nr. 155/2024 privind securitatea cibernetică și transpunerea NIS2. Portal legislativ, 2024. legislatie.just.ro
4. Legea nr. 124/2025 privind aprobarea OUG 155/2024. Portal legislativ, 2025. legislatie.just.ro
5. ENISA Threat Landscape, atacuri asupra identității și autentificării. European Union Agency for Cybersecurity (ENISA), 2024. enisa.europa.eu

1.  

1.  

1.  

1.