SSO, MFA și gestiunea accesului în aplicațiile business: cine are voie să vadă ce?

Roluri, permisiuni, jurnale de audit și integrarea cu Microsoft Entra ID sau Keycloak open-source.

Într-o companie modernă, angajații utilizează zilnic numeroase aplicații informatice: sisteme ERP, CRM, platforme Help Desk, aplicații de contabilitate, instrumente de colaborare și soluții de administrare a documentelor.

Fiecare dintre aceste sisteme gestionează informații care nu trebuie să fie accesibile tuturor utilizatorilor.

Un angajat din departamentul de vânzări poate avea nevoie să consulte datele clienților, dar nu și salariile colegilor. Un operator Help Desk poate rezolva solicitări tehnice, însă nu ar trebui să modifice configurațiile de securitate ale întregii organizații.

În mod similar, un administrator IT trebuie să poată gestiona infrastructura fără să primească automat acces la toate informațiile comerciale confidențiale.

Această separare a responsabilităților reprezintă una dintre cerințele fundamentale ale securității informatice.

Pentru implementarea ei sunt utilizate tehnologii precum Single Sign-On (SSO), Multi-Factor Authentication (MFA), Role-Based Access Control (RBAC) și sistemele de audit al activităților.

Platforme precum Microsoft Entra ID sau Keycloak permit centralizarea identităților și integrarea mecanismelor moderne de autentificare.

Totuși, securitatea reală nu se limitează la verificarea parolei. Întrebarea esențială este: cine are dreptul să acceseze o anumită informație, în ce condiții și ce operațiuni poate executa?

1. Identitate, autentificare și autorizare: trei concepte diferite

Pentru proiectarea corectă a accesului într-o aplicație business trebuie înțeleasă diferența dintre identitate, autentificare și autorizare.

Identitatea digitală reprezintă asocierea unui utilizator cu un cont și cu anumite informații relevante pentru organizație: identificator, departament, funcție sau apartenență la grupuri.

Autentificarea este procesul prin care sistemul verifică faptul că utilizatorul este persoana sau entitatea care pretinde că este. Aceasta poate utiliza parole, aplicații de autentificare, chei de securitate sau metode biometrice integrate în dispozitive.

Autorizarea stabilește ce operațiuni sunt permise după autentificare. De exemplu, doi angajați se pot conecta folosind același furnizor de identitate, dar unul poate vizualiza facturi, în timp ce celălalt are dreptul să le aprobe.

Această diferență este fundamentală. O persoană autentificată corect nu trebuie să primească automat acces la toate funcțiile aplicației.

Există și o a patra componentă: auditul, care permite urmărirea activităților și investigarea schimbărilor efectuate în sistem.

Împreună, aceste mecanisme formează baza unei arhitecturi de Identity and Access Management (IAM).

2. Ce este Single Sign-On și de ce contează?

Single Sign-On, prescurtat SSO, permite unui utilizator să se autentifice printr-un furnizor central de identitate și să acceseze mai multe aplicații compatibile fără introducerea repetată a credențialelor.

Să presupunem că o companie utilizează un CRM, un sistem ERP și o platformă Help Desk. Fără SSO, angajații ar putea avea trei conturi separate, fiecare cu propriile parole și proceduri de recuperare.

Prin implementarea SSO, aplicațiile pot delega autentificarea către un sistem central. Utilizatorul accesează aplicația, este direcționat către furnizorul de identitate, se autentifică, iar aplicația primește informațiile necesare pentru identificarea sa.

Această abordare simplifică administrarea conturilor și poate facilita aplicarea uniformă a politicilor de securitate.

SSO nu înseamnă însă că toate aplicațiile acordă aceleași drepturi. Fiecare sistem trebuie să decidă ce resurse poate utiliza persoana autentificată.

Un alt aspect important este riscul concentrării autentificării într-un singur punct. Dacă identitatea principală este compromisă, atacatorul ar putea încerca să acceseze mai multe servicii.

De aceea, SSO trebuie combinat cu MFA, monitorizare și politici stricte de acces.

3. Protocoalele utilizate: OpenID Connect și SAML

Pentru integrarea aplicațiilor business cu un furnizor de identitate sunt utilizate protocoale standardizate.

OpenID Connect (OIDC) este folosit frecvent în aplicațiile web moderne și mobile. El permite autentificarea utilizatorilor pe baza unui mecanism construit peste OAuth 2.0.

OAuth 2.0 este un cadru de autorizare pentru acces la resurse, în timp ce OpenID Connect adaugă un nivel standardizat pentru autentificarea identității.

Pentru aplicațiile web moderne se recomandă, în mod obișnuit, Authorization Code Flow, cu PKCE acolo unde este aplicabil.

SAML 2.0 este întâlnit frecvent în aplicațiile enterprise, inclusiv în sisteme mai vechi care folosesc federarea identităților.

Ambele protocoale permit integrarea cu platforme precum Microsoft Entra ID și Keycloak. Alegerea depinde de arhitectura aplicației, compatibilitatea software-ului și cerințele de securitate.

Un principiu important este ca aplicația să valideze riguros tokenurile sau afirmațiile de identitate primite, inclusiv semnătura, emitentul, destinatarul și perioada de valabilitate.

4. MFA: de ce parola nu mai este suficientă

Multi-Factor Authentication presupune verificarea identității prin cel puțin doi factori independenți.

Aceștia pot include ceva ce utilizatorul cunoaște, precum o parolă, ceva ce deține, precum o cheie hardware, sau o caracteristică biometrică utilizată de un autentificator.

Scopul MFA este reducerea riscului ca o parolă furată să permită accesul neautorizat.

În organizații, MFA ar trebui să fie o cerință prioritară pentru conturile administrative, aplicațiile financiare și sistemele care prelucrează informații sensibile.

Există însă diferențe importante între metodele MFA. Codurile temporare generate de aplicații TOTP oferă protecție suplimentară față de utilizarea exclusivă a parolei, dar pot fi interceptate prin anumite atacuri de phishing.

Metodele bazate pe FIDO2 și WebAuthn, inclusiv cheile de securitate și passkeys configurate corespunzător, oferă rezistență mai bună la phishing.

Ghidul NIST SP 800-63B-4, publicat în 2025, evidențiază importanța autentificării rezistente la phishing.

Pentru companii, o strategie eficientă poate presupune MFA obligatoriu și utilizarea metodelor rezistente la phishing pentru administratorii cu privilegii ridicate.

5. RBAC: administrarea accesului prin roluri

Role-Based Access Control este unul dintre cele mai utilizate modele de autorizare în aplicațiile business.

În loc să atribuie individual sute de permisiuni fiecărui angajat, organizația definește roluri care corespund responsabilităților profesionale.

De exemplu, o aplicație poate avea rolurile Administrator, Manager, Operator și Utilizator. Fiecărui rol îi sunt asociate drepturi clare.

Administratorul poate gestiona configurațiile tehnice, managerul poate consulta rapoarte, operatorul poate procesa solicitări, iar utilizatorul poate accesa doar propriile informații.

Această abordare simplifică administrarea și reduce riscul atribuirii accidentale a unor drepturi excesive. Totuși, rolurile trebuie proiectate cu atenție.

Dacă un rol acordă prea multe privilegii, sistemul poate deveni vulnerabil chiar dacă mecanismul de autentificare funcționează corect.

Exemplu de matrice a permisiunilor

Pentru o aplicație Help Desk, drepturile pot fi definite astfel:

Matricea reprezintă un exemplu conceptual. În practică, fiecare operațiune trebuie verificată și în funcție de organizație, departament, proprietarul informației și regulile interne.

6. De la RBAC la ABAC: permisiuni contextuale

Modelul RBAC nu rezolvă toate situațiile. În aplicațiile complexe, accesul poate depinde de mai multe condiții decât simpla apartenență la un rol.

De exemplu, un operator Help Desk trebuie să vizualizeze doar tichetele departamentului său. Un manager regional poate accesa informațiile clienților din regiunea alocată, dar nu și din alte regiuni.

Pentru astfel de situații există Attribute-Based Access Control (ABAC). ABAC permite evaluarea unor atribute ale utilizatorului, resursei și contextului.

O regulă ar putea permite accesul numai dacă utilizatorul are rolul Operator, aparține departamentului responsabil și tichetul se află în aceeași organizație.

Există și modele bazate pe relații, denumite Relationship-Based Access Control (ReBAC), utile pentru resurse partajate între utilizatori, echipe și organizații.

În practică, multe aplicații business folosesc modele hibride: roluri pentru drepturile generale și reguli suplimentare pentru accesul la anumite înregistrări. Aceasta este o soluție mai sigură decât atribuirea unui număr foarte mare de roluri specializate.

7. Principiul privilegiilor minime

Un principiu central al securității informatice este Least Privilege, adică acordarea exclusivă a privilegiilor necesare îndeplinirii responsabilităților.

Un angajat care trebuie să consulte rapoarte nu are nevoie de dreptul de a modifica baza de date. Un dezvoltator care verifică o eroare nu trebuie să primească automat acces permanent la informațiile reale ale tuturor clienților.

În plus, drepturile administrative ar trebui separate de conturile utilizate pentru activități obișnuite. Pentru operațiuni sensibile pot fi implementate aprobări, acces temporar și autentificare suplimentară.

Un alt principiu important este Deny by Default: dacă o operațiune nu este permisă explicit, accesul este refuzat.

Conform recomandărilor OWASP, verificările de autorizare trebuie realizate la fiecare cerere relevantă, inclusiv la nivelul API-urilor. Ascunderea unui buton din interfața utilizatorului nu reprezintă o măsură suficientă de securitate.

8. Controlul accesului la date și prevenirea expunerilor

Una dintre cele mai periculoase greșeli din aplicațiile business este verificarea exclusivă a accesului la pagini, fără verificarea drepturilor asupra informațiilor individuale.

De exemplu, un utilizator poate avea dreptul să deschidă pagina unui tichet, dar nu și să vizualizeze orice tichet din sistem.

Dacă aplicația verifică doar existența unei sesiuni autentificate, modificarea identificatorului unei înregistrări ar putea permite accesul la datele altui client. Aceste probleme apar frecvent în aplicațiile care expun API-uri.

Pentru prevenirea lor, verificările trebuie realizate pe server și trebuie să țină cont de proprietarul resursei, organizație, rol și context.

Într-o aplicație multiclient, identificatorul organizației trebuie verificat pentru fiecare operațiune relevantă. Nu este suficient ca interfața să transmită un identificator de client. Serverul trebuie să stabilească independent dacă utilizatorul poate accesa acea organizație.

Aceste controale sunt esențiale pentru aplicațiile SaaS, CRM, ERP și Help Desk care gestionează informațiile mai multor companii.

9. Audit log: cine a accesat sau modificat informațiile?

Un sistem de securitate eficient trebuie să ofere posibilitatea investigării activităților importante.

Jurnalul de audit, cunoscut ca audit log, înregistrează evenimente relevante privind autentificarea, autorizarea și operațiunile executate în aplicație.

Un eveniment de audit bine proiectat poate include identificatorul utilizatorului, data și ora, acțiunea, resursa afectată, organizația, rezultatul și un identificator de corelare.

De exemplu, jurnalul poate arăta că un manager a modificat nivelul de acces al unui angajat sau că un utilizator a încercat să consulte o resursă pentru care nu avea permisiuni.

În anumite aplicații poate fi justificată înregistrarea accesului la documente sensibile, nu numai a modificărilor.

Este importantă distincția dintre jurnalul furnizorului de identitate și jurnalul aplicației. Microsoft Entra ID sau Keycloak pot înregistra evenimente privind autentificarea și administrarea identităților, dar nu cunosc automat fiecare operațiune comercială realizată în ERP sau CRM.

Aplicația trebuie să genereze propriile evenimente de audit pentru acțiunile importante. Jurnalele trebuie protejate împotriva modificării neautorizate, monitorizate și păstrate conform unor politici documentate.

Nu se recomandă stocarea parolelor, tokenurilor de sesiune sau altor secrete în audit log.

10. Microsoft Entra ID: identitate și acces pentru mediul enterprise

Microsoft Entra ID, cunoscut anterior ca Azure Active Directory, este platforma Microsoft pentru gestionarea identităților și a accesului la aplicații și resurse.

Este utilizată frecvent în organizațiile care folosesc Microsoft 365, Azure și aplicații enterprise.

Entra ID permite autentificare centralizată, Single Sign-On, administrarea utilizatorilor și grupurilor, precum și integrarea aplicațiilor prin OpenID Connect și SAML.

O funcționalitate importantă este Conditional Access. Aceasta permite aplicarea unor politici care țin cont de utilizator, aplicație, dispozitiv și alte semnale relevante. De exemplu, accesul la o aplicație financiară poate necesita autentificare multifactor sau utilizarea unui dispozitiv conform politicilor organizației.

Pentru aplicațiile dezvoltate intern, Microsoft Entra permite definirea unor App Roles care pot fi atribuite utilizatorilor sau grupurilor și transmise aplicației prin tokenuri. Aplicația trebuie să interpreteze aceste roluri și să execute propriile verificări de autorizare.

Platforma oferă și jurnale de autentificare, audit și aprovizionare a identităților, în funcție de funcționalitățile disponibile.

Trebuie luate în calcul licențele: Conditional Access necesită, în general, Microsoft Entra ID P1 sau o licență care include funcționalitatea. Politicile avansate bazate pe risc pot necesita P2.

Entra ID reprezintă o alegere practică pentru organizațiile deja integrate în ecosistemul Microsoft.

11. Keycloak: alternativa open-source pentru identitate și SSO

Keycloak este o platformă open-source de Identity and Access Management care poate fi instalată pe infrastructura proprie.

Sistemul oferă Single Sign-On, integrare OpenID Connect și SAML, administrarea utilizatorilor, grupurilor și rolurilor, precum și mecanisme de autentificare multifactor.

Keycloak permite integrarea cu furnizori externi de identitate și cu directoare LDAP sau Active Directory, în funcție de arhitectura implementării.

Un avantaj important îl reprezintă posibilitatea personalizării fluxurilor de autentificare. Organizația poate controla interfața de autentificare, regulile de acces, sesiunile și anumite politici de autorizare.

Keycloak include funcționalități pentru înregistrarea evenimentelor utilizatorilor și administratorilor, care trebuie activate și configurate corespunzător pentru cerințele de audit.

Pentru organizațiile interesate de suveranitate digitală europeană, instalarea Keycloak pe un server administrat în Uniunea Europeană poate reprezenta o opțiune interesantă.

Totuși, open-source nu înseamnă administrare fără costuri. Sunt necesare actualizări, copii de rezervă, monitorizare, protejarea cheilor criptografice și proceduri de recuperare în cazul incidentelor.

În mediile de producție trebuie asigurate disponibilitatea și securitatea serviciului de identitate, deoarece indisponibilitatea lui poate afecta accesul la toate aplicațiile conectate.

12. Microsoft Entra ID versus Keycloak

Cele două platforme răspund unor cerințe similare, dar au modele operaționale diferite.

Microsoft Entra ID poate reduce efortul operațional al organizațiilor care utilizează deja servicii Microsoft.

Keycloak oferă flexibilitate și control sporit asupra infrastructurii, dar necesită competențe tehnice de administrare.

Cele două soluții nu se exclud. Keycloak poate funcționa și ca intermediar de identitate pentru autentificarea utilizatorilor prin Microsoft Entra ID.

Această abordare poate fi utilă atunci când o organizație dorește să păstreze integrarea cu identitățile Microsoft, dar să standardizeze autentificarea mai multor aplicații proprii prin Keycloak.

13. Exemplu practic: accesul într-un sistem Help Desk

Să considerăm o companie care furnizează servicii IT pentru mai mulți clienți. Firma utilizează o platformă Help Desk conectată la Microsoft Entra ID sau Keycloak.

Angajații se autentifică folosind SSO, iar conturile cu privilegii ridicate necesită MFA.

În aplicație sunt definite roluri precum Operator, Manager și Administrator. Un operator poate consulta numai tichetele organizațiilor pentru care este responsabil. Managerul poate vizualiza rapoartele departamentului și poate redistribui solicitările.

Administratorul poate gestiona configurațiile tehnice, dar accesul la informațiile confidențiale poate rămâne supus unor permisiuni separate.

Clienții se autentifică în propriul portal și pot consulta exclusiv solicitările pentru care au drepturi.

Când un angajat încearcă să acceseze un tichet, aplicația verifică identitatea, rolul, organizația și relația utilizatorului cu resursa solicitată. Dacă operațiunea nu este permisă, serverul refuză accesul.

Evenimentele relevante sunt înregistrate în audit log, astfel încât echipa de securitate să poată investiga eventualele incidente.

Această arhitectură separă autentificarea centralizată de regulile comerciale de acces.

14. Ciclul de viață al identităților

Securitatea accesului nu se termină în momentul în care un cont este creat. Organizațiile trebuie să gestioneze întregul ciclu de viață al identității.

La angajare, utilizatorul primește accesul necesar funcției sale. La schimbarea departamentului, drepturile trebuie actualizate, iar privilegiile care nu mai sunt necesare trebuie eliminate. La încetarea colaborării, conturile și sesiunile trebuie dezactivate conform procedurilor interne.

Această abordare este cunoscută drept Joiner–Mover–Leaver.

În companiile mari, procesele pot fi automatizate prin integrarea sistemelor IAM cu aplicațiile de resurse umane.

Un element important este verificarea periodică a drepturilor existente, cunoscută ca access review. Prin aceste verificări, managerii și responsabilii de securitate confirmă dacă utilizatorii mai au nevoie de privilegiile atribuite.

Trebuie analizate inclusiv conturile tehnice, aplicațiile care comunică prin API și identitățile utilizate de automatizări.

15. Suveranitate digitală, GDPR și controlul accesului

În contextul suveranității digitale europene, administrarea identităților reprezintă o componentă importantă a controlului asupra infrastructurii informatice.

GDPR impune măsuri tehnice și organizatorice adecvate pentru protejarea datelor personale, ținând cont de riscurile prelucrării. Controlul accesului, autentificarea puternică și jurnalizarea pot contribui la îndeplinirea acestor obligații.

Totuși, implementarea Microsoft Entra ID sau Keycloak nu garantează automat conformitatea cu GDPR. Organizația trebuie să stabilească politici de acces, perioade de păstrare a datelor, proceduri de răspuns la incidente și responsabilități documentate.

Keycloak poate permite găzduirea identităților pe infrastructură europeană, însă trebuie evaluate și dependențele externe. Microsoft Entra ID poate fi utilizat într-o arhitectură conformă cerințelor aplicabile, dacă sunt analizate configurația, contractele și fluxurile de date.

Alegerea trebuie fundamentată pe analiza riscurilor, nu exclusiv pe denumirea sau originea furnizorului.

16. Recomandări pentru implementarea securității accesului

Un proiect de gestiune a identităților trebuie să înceapă cu inventarierea aplicațiilor, utilizatorilor și informațiilor sensibile.

Ulterior, organizația poate defini o politică unitară de autentificare și o matrice a drepturilor pentru fiecare aplicație.

• Integrarea SSO trebuie realizată gradual, începând cu sistemele care permit utilizarea protocoalelor standard.
• MFA trebuie activat pentru conturile relevante, cu prioritate pentru administratorii și utilizatorii care accesează informații sensibile.
• Echipele de dezvoltare trebuie să implementeze verificări de autorizare la nivelul fiecărei operațiuni importante.
• O atenție specială trebuie acordată aplicațiilor multiclient, în care separarea informațiilor între organizații este esențială.
• Înaintea lansării trebuie testate inclusiv situațiile în care utilizatorii încearcă să acceseze informații aparținând altor departamente sau organizații.
• Trebuie pregătite proceduri pentru revocarea accesului, indisponibilitatea furnizorului de identitate și recuperarea conturilor administrative.

Auditul, monitorizarea și revizuirea periodică a privilegiilor trebuie tratate ca procese continue.

Concluzie: securitatea nu înseamnă doar conectarea în aplicație

Pe măsură ce organizațiile adoptă tot mai multe aplicații business, administrarea identităților și a accesului devine o problemă strategică.

Single Sign-On simplifică autentificarea și permite centralizarea politicilor. Multi-Factor Authentication reduce riscul compromiterii conturilor, iar modelele RBAC și ABAC stabilesc ce informații și operațiuni sunt accesibile utilizatorilor.

Jurnalele de audit oferă vizibilitate asupra activităților importante și contribuie la investigarea incidentelor.

Microsoft Entra ID și Keycloak sunt două opțiuni relevante pentru construirea acestei infrastructuri. Prima oferă integrare puternică într-un ecosistem enterprise administrat, în timp ce a doua permite implementarea unui serviciu de identitate open-source pe infrastructura aleasă de organizație.

Indiferent de platformă, securitatea depinde de proiectarea corectă a rolurilor, verificarea permanentă a permisiunilor și administrarea responsabilă a identităților.

Întrebarea care trebuie să stea la baza oricărei aplicații business nu este doar „Cine se poate autentifica?”, ci mai ales „Cine are voie să vadă ce, să modifice ce și în ce condiții?”. Răspunsul la această întrebare definește adevărata maturitate a securității digitale într-o organizație.

Surse și documentație tehnică

1. Microsoft Entra ID – documentație oficială
2. Microsoft Entra – Single Sign-On
3. Microsoft Entra – Application Roles
4. Microsoft Entra – Conditional Access
5. Keycloak – documentație oficială
6. Keycloak – Server Administration Guide
7. OWASP – Authorization Cheat Sheet
8. NIST SP 800-63B-4 – Authentication Guidelines

Articol tehnic informativ, actualizat pentru octombrie 2026. Funcționalitățile disponibile și condițiile de licențiere trebuie verificate înaintea implementării.