Guvernanța Microsoft Entra Conditional Access în 2026

Este ora 09:12 într-o zi de marți când Maria, CISO-ul unei companii fintech europene aflate în creștere rapidă, deschide un raport de pregătire pentru DORA care ar fi trebuit să fie de rutină. Tabloul ei de bord Microsoft Entra Conditional Access arată bine. MFA este impusă pentru administratori. Autentificarea prin protocoale vechi este blocată. Autentificările cu risc ridicat sunt supuse unei verificări suplimentare sau sunt respinse. Aplicațiile financiare sensibile impun dispozitive conforme. Accesul prin browser de pe endpointuri neadministrate este restricționat.
Apoi citește constatarea auditorului.
„Regulile dumneavoastră Conditional Access sunt solide din punct de vedere tehnic, dar există în vid. Arătați-ne politica aprobată de consiliul de administrație care impune aceste setări. Arătați-ne înregistrarea schimbării pentru regula modificată luna trecută. Arătați-ne cum politica pentru autentificările cu risc ridicat era activă în timpul atacului suspectat de credential stuffing. Arătați-ne cum aceste dovezi susțin ISO 27001, DORA, NIS2 și GDPR.”
Echipa de identitate poate exporta configurația. SOC-ul poate prezenta jurnale de autentificare. Managerul de conformitate poate indica un folder de politici. Dar nimeni nu poate produce o narațiune unitară de dovezi guvernate care să conecteze riscul, politica, aprobarea, configurația, excepțiile, monitorizarea, răspunsul la incidente, obligațiile privind protecția datelor și analiza efectuată de management.
Aceasta este problema guvernanței Conditional Access în 2026.
Microsoft Entra Conditional Access nu mai este doar o setare de identitate. Este un sistem de control la nivelul consiliului de administrație care decide cine poate accesa servicii cloud, în ce condiții, de pe ce dispozitive, cu ce nivel de robustețe a autentificării și cu ce restricții de sesiune. Pentru organizațiile reglementate, aceste decizii trebuie să fie explicabile, justificabile și mapate la obligațiile prevăzute de ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST și COBIT 2019.
Conditional Access este acum un sistem de control auditabil
Conditional Access se află la intersecția dintre identitate, postura de securitate a dispozitivului, sensibilitatea aplicației, locație, riscul de autentificare, riscul utilizatorului, comportamentul sesiunii și jurnalizare. O singură politică poate impune MFA, poate solicita un dispozitiv conform, poate bloca accesul dintr-o locație riscantă, poate restricționa descărcările din browsere neadministrate sau poate forța reautentificarea atunci când riscul se modifică.
Acest lucru îl face unul dintre cele mai puternice puncte de aplicare Zero Trust în mediile cloud Microsoft. De asemenea, îl face extrem de relevant pentru audit.
În ISO/IEC 27001:2022, un control nu este matur doar pentru că există într-un portal. Organizația trebuie să își înțeleagă contextul, să evalueze riscurile de securitate a informațiilor, să selecteze tratamentele riscului, să documenteze Declarația de aplicabilitate, să opereze controalele, să monitorizeze eficacitatea și să îmbunătățească în timp. Clauzele relevante includ Clause 6.1.2 pentru evaluarea riscurilor, Clause 6.1.3 pentru tratarea riscurilor, Clause 7.5 pentru informații documentate, Clause 8.1 pentru planificare și control operațional, Clause 9.1 pentru monitorizare și Clause 9.3 pentru analiza efectuată de management.
Anexa A, aliniată cu ISO/IEC 27002:2022, oferă limbajul practic al controalelor pe care auditorii îl vor recunoaște. Conditional Access susține în mod uzual:
- 5.15 Controlul accesului
- 5.16 Managementul identității
- 5.17 Informații de autentificare
- 5.18 Drepturi de acces
- 8.1 Dispozitivele utilizatorilor finali
- 8.2 Drepturi de acces privilegiat
- 8.3 Restricționarea accesului la informații
- 8.5 Autentificare securizată
- 8.15 Jurnalizare
- 8.16 Activități de monitorizare
Pentru organizațiile reglementate din UE, sarcina de guvernanță este și mai clară. NIS2 Article 20 atribuie organismelor de conducere responsabilitatea de a aproba și supraveghea măsurile de management al riscurilor de securitate cibernetică. NIS2 Article 21 impune măsuri tehnice, operaționale și organizaționale adecvate și proporționale, inclusiv controlul accesului, managementul activelor, igienă cibernetică, gestionarea incidentelor, securitatea lanțului de aprovizionare, evaluarea eficacității și autentificare multifactor sau continuă, după caz. NIS2 Article 23 introduce raportarea etapizată a incidentelor semnificative, inclusiv o avertizare timpurie în termen de 24 de ore, o notificare a incidentului în termen de 72 de ore și un raport final în termen de o lună.
DORA stabilește așteptări similare pentru entitățile financiare. Article 5 impune un cadru intern de guvernanță și control. Article 6 impune un cadru de management al riscurilor TIC. Article 9 acoperă protecția și prevenirea, inclusiv restricțiile de acces și practicile de management al identității. Articles 10, 11, 17, 18 și 19 conectează detectarea, răspunsul, recuperarea, gestionarea incidentelor TIC, clasificarea și raportarea. Deoarece DORA se aplică din 17 ianuarie 2025, entitățile financiare trebuie să trateze Conditional Access ca parte a dovezilor privind reziliența operațională, nu doar ca întărire a securității identității.
GDPR adaugă perspectiva protecției datelor. Dacă Conditional Access protejează sisteme care prelucrează date cu caracter personal, acesta susține principiile responsabilității din Article 5, responsabilitatea operatorului din Article 24, protecția datelor începând cu momentul proiectării din Article 25 și securitatea prelucrării din Article 32. Dacă se suspectează acces neautorizat, jurnalele Conditional Access pot deveni parte a dovezilor pentru evaluarea și notificarea încălcării securității datelor cu caracter personal.
Greșeala constă în tratarea acestor aspecte ca solicitări de audit separate. Abordarea matură este un singur model de guvernanță Conditional Access care poate fi prezentat pe cadre, autorități de reglementare, clienți sau audiențe la nivelul consiliului de administrație.
Configurația nu înseamnă guvernanță
Majoritatea organizațiilor pot răspunde la întrebarea „Ce este configurat?”. Mai puține pot răspunde la întrebările mai dificile:
- De ce este configurată astfel această politică Conditional Access?
- Ce scenariu de risc tratează?
- Ce clauză de politică o impune?
- Cine a aprobat schimbarea?
- Ce utilizatori, aplicații și dispozitive sunt excluse?
- Cum este testată?
- Ce jurnale dovedesc că a funcționat?
- Cât de des este revizuită?
- Ce se întâmplă când eșuează?
Aici apar de regulă constatările de audit. Politicile există, dar nu sunt corelate cu setările Microsoft Entra. Conformitatea dispozitivelor este gestionată de operațiunile IT, dar nu este mapată la riscul de control al accesului. Politicile privind riscul de autentificare sunt activate fără praguri documentate sau reguli de escaladare. Restricțiile de sesiune sunt configurate, dar nu sunt testate niciodată de pe dispozitive neadministrate. Jurnalele sunt păstrate, dar nu sunt structurate ca dovezi de audit.
Clarysec tratează acest aspect ca pe o problemă de trasabilitate. Fiecare decizie Conditional Access trebuie să conecteze politica, riscul, controlul, configurația, dovezile și revizuirea.
Politica SME Cloud Usage Policy-sme Cloud Usage Policy-sme - SME prevede:
Autentificare multifactor (MFA) pentru conturile administrative și de utilizator
Din secțiunea „Cerințe de implementare a politicii”, clauza de politică 6.2.2.
Acea clauză este mandatul. Regula Conditional Access este aplicarea. Jurnalul de autentificare este dovada. Înregistrarea revizuirii demonstrează supravegherea.
Politica SME Network Security Policy-sme Network Security Policy-sme - SME adaugă cerința privind postura de securitate a endpointului:
Sistemele fără antivirus actualizat, patch-uri actualizate sau o stare acceptabilă a dispozitivului trebuie blocate sau plasate în carantină
Din secțiunea „Cerințe de implementare a politicii”, clauza de politică 6.4.3.
În termenii Microsoft Entra, aceasta poate deveni „solicită dispozitiv conform”, „blochează platformele neacceptate de furnizor”, „restricționează sesiunile de browser neadministrate” sau „refuză accesul la aplicații cu risc ridicat de pe dispozitive necunoscute”. Dar controlul nu este complet până când organizația nu poate demonstra domeniul de aplicare, aprobarea, testarea, excepțiile și monitorizarea.
Construiți baza de guvernanță înaintea setului de reguli
Un program Conditional Access solid începe în afara portalului Entra. Începe cu SMSI, Registrul riscurilor, Politica de control al accesului, Politica de utilizare a serviciilor cloud, SoA și modelul de dovezi.
Zenith Blueprint: An Auditor’s 30-Step Roadmap de la Clarysec Zenith Blueprint oferă o secvență practică. În faza de management al riscurilor, Pasul 13, Planificarea tratării riscurilor și Declarația de aplicabilitate, acesta indică organizațiilor să conecteze controalele la riscuri și la factorii de reglementare:
Corelați reglementările: Dacă anumite controale sunt implementate în mod specific pentru a respecta GDPR, NIS2 sau DORA, puteți nota acest lucru fie în Registrul de riscuri (ca parte a justificării impactului riscului), fie în notele SoA.
Pentru Conditional Access, acest lucru schimbă narațiunea dovezilor. În loc să spună „Am activat MFA”, organizația poate spune:
- Scenariu de risc: Credențiale de utilizator compromise permit acces neautorizat la datele clienților în Microsoft 365 și în SaaS financiar.
- Proprietar de risc: Șeful securității IT.
- Tratament: Entra Conditional Access impune MFA puternică pentru roluri privilegiate, MFA pentru utilizatori, blocarea riscului de autentificare, dispozitive conforme pentru aplicații sensibile și restricții de sesiune pentru endpointuri neadministrate.
- Mapare ISO/IEC 27002:2022: 5.15, 5.16, 5.17, 5.18, 8.1, 8.2, 8.3, 8.5, 8.15 și 8.16.
- Mapare reglementară: NIS2 Articles 20, 21 și 23, DORA Articles 5, 6, 9, 10, 17 și 18, GDPR Articles 24, 25, 32 și 33.
- Dovezi: aprobarea politicii, export Conditional Access, tichet de schimbare, rezultate ale testelor, jurnale de autentificare, rapoarte privind conformitatea dispozitivelor, registru de excepții, tichete SOC și procese-verbale ale analizelor efectuate de management.
Zenith Blueprint explică, de asemenea, în faza Controale în acțiune, Pasul 19, de ce postura de securitate a endpointului trebuie să facă parte din decizia de acces:
Accesul la informații prin endpointuri trebuie să fie contextual. De exemplu, îndeplinește dispozitivul standardele minime de securitate înainte de a accesa resursele companiei? A trecut recent o scanare malware? Se conectează dintr-o locație sau rețea neobișnuită? Prin integrarea cu principiile Zero Trust, postura de securitate a endpointului poate alimenta accesul condiționat, refuzând intrarea până când dispozitivul dovedește că este sigur.
Acesta este principiul central de guvernanță. Conditional Access trebuie să fie bazat pe risc, contextual și capabil să producă dovezi.
Mapați deciziile Conditional Access la obiectivele de control
Un program matur definește decizii standard de acces, apoi le mapează pe fiecare la intenția de guvernanță și la dovezi. Aceasta previne proliferarea politicilor și simplifică discuțiile de audit.
| Decizie Conditional Access | Intenție de guvernanță | Dovezi principale | Valoare pentru conformitate încrucișată |
|---|---|---|---|
| Impunerea MFA pentru administratori | Prevenirea compromiterii conturilor privilegiate | Export al politicii CA, listă de roluri, jurnale de autentificare, aprobări ale excepțiilor | Susține ISO/IEC 27002:2022 8.2 și 8.5, MFA în NIS2, restricțiile de acces DORA și confidențialitatea GDPR |
| Solicitarea unui dispozitiv conform pentru aplicații sensibile | Reducerea accesului de pe endpointuri neadministrate sau vulnerabile | Politică de conformitate Intune, politică Entra CA, rapoarte privind conformitatea dispozitivelor | Susține 8.1 Dispozitivele utilizatorilor finali, igiena cibernetică, protecția împotriva riscurilor TIC și măsurile de protecție a datelor |
| Blocarea riscului ridicat de autentificare | Prevenirea utilizării abuzive probabile a credențialelor | Configurația politicii de risc, jurnale ale evenimentelor de risc, tichete de triaj SOC | Susține 8.16 Activități de monitorizare, detectarea incidentelor, pregătirea pentru raportarea NIS2 și clasificarea incidentelor DORA |
| Restricționarea sesiunilor de browser neadministrate | Limitarea scurgerii de date de pe dispozitive neconforme | Politică de sesiune, jurnale de control al aplicațiilor, dovezi de testare | Susține 8.3 Restricționarea accesului la informații, controlul cloud, munca la distanță și protecția datelor cu caracter personal |
| Solicitarea aplicațiilor client aprobate sau a protecției aplicațiilor | Protejarea accesului mobil și BYOD | Politică de protecție a aplicațiilor mobile, setări de acordare CA, jurnale de acces mobil | Susține guvernanța endpointurilor, controalele BYOD și restricțiile de acces la aplicații |
| Blocarea autentificării prin protocoale vechi | Eliminarea căilor slabe de autentificare | Rapoarte privind protocoalele de autentificare, politică CA, rezultate ale testelor | Susține 8.5 Autentificare securizată și reducerea suprafeței de atac |
| Solicitarea reautentificării pentru sesiuni riscante | Reducerea persistenței după modificarea riscului | Setări ale controlului sesiunii, dovezi privind frecvența autentificării, jurnale ale evenimentelor de risc | Susține managementul sesiunii, izolarea incidentelor și responsabilitatea privind protecția datelor |
Politica Enterprise Cloud Usage Policy Cloud Usage Policy susține integrarea centrală a identității:
Integrarea Single Sign-On (SSO) cu IdP-ul organizației este necesară pentru a asigura consecvența autentificării.
Din secțiunea „Cerințe de implementare a politicii”, clauza de politică 6.2.4.
Politica Enterprise User Account and Privilege Management Policy User Account and Privilege Management Policy face monitorizarea explicită:
Utilizarea sistemelor Single Sign-On (SSO) trebuie integrată cu furnizori centrali de identitate (de exemplu, Active Directory (AD), Azure AD) și monitorizată pentru activitate de autentificare anomală.
Din secțiunea „Cerințe de implementare a politicii”, clauza de politică 6.3.4.
Împreună, aceste clauze impun mai mult decât SSO. Ele impun o arhitectură centrală a identității, autentificare consecventă, monitorizarea autentificărilor anormale și dovezi că deciziile de acces sunt revizuite.
Conformitatea dispozitivelor: controlul pe care auditorii îl pot testa
Conformitatea dispozitivelor este una dintre zonele cel mai ușor de supraestimat. Un tablou de bord poate arăta 92% dispozitive conforme, dar un auditor va întreba dacă regula se aplică aplicațiilor relevante, dacă dispozitivele personale sunt permise, dacă platformele neacceptate de furnizor sunt blocate și dacă excepțiile sunt aprobate.
Politica Enterprise Remote Work Policy Remote Work Policy stabilește baza de aprobare:
Dispozitivele BYOD trebuie aprobate explicit și:
Din secțiunea „Cerințe de guvernanță”, clauza de politică 5.2.2.
Această propoziție scurtă contează. BYOD nu este doar o stare tehnică. Este o decizie de guvernanță. În Conditional Access, aceasta trebuie transpusă în reguli privind proprietatea dispozitivului, cerințe minime de conformitate, cerințe de criptare, verificări ale patch-urilor și protecției antimalware, protecția aplicațiilor mobile, tratarea contractorilor și revizuirea excepțiilor.
Zenith Controls: The Cross-Compliance Guide de la Clarysec Zenith Controls mapează controlul ISO/IEC 27002:2022 5.15 Controlul accesului ca preventiv, protejând confidențialitatea, integritatea și disponibilitatea în capabilitatea operațională de management al identității și al accesului. De asemenea, conectează controlul accesului la dispozitivele utilizatorilor finali, deoarece laptopurile, telefoanele mobile și desktopurile neadministrate pot submina aplicarea centralizată a accesului.
Un pachet practic trimestrial de dovezi privind dispozitivele pentru Conditional Access trebuie să includă:
- Cerințe de bază aprobate privind conformitatea dispozitivelor.
- Politici Conditional Access care impun dispozitive conforme.
- Aplicațiile protejate de aceste politici.
- Exportul utilizatorilor, grupurilor, aplicațiilor și platformelor excluse.
- Raport de tendință pentru dispozitive neconforme.
- Exemple de jurnale de autentificare blocată pentru dispozitive neconforme.
- Registru de excepții cu proprietar, motiv, dată de expirare și acceptarea riscului.
- Înregistrare a analizei efectuate de management.
Acest pachet de dovezi susține controlul operațional ISO/IEC 27001:2022, igiena cibernetică NIS2, protecția și prevenirea DORA și responsabilitatea GDPR.
Riscul de autentificare: detecția trebuie să devină dovadă decizională
Conditional Access bazat pe risc este zona în care detectarea la nivel de identitate devine guvernanță a accesului. Microsoft Entra poate evalua semnale precum proprietăți de autentificare nefamiliare, adrese IP anonime, deplasare imposibilă și credențiale divulgate. Dar auditorii nu vor accepta „politică de risc activată” ca răspuns final. Ei vor întreba de ce au fost selectate pragurile, cine revizuiește evenimentele riscante și când o autentificare cu risc ridicat devine incident.
Politica SME Logging and Monitoring Policy-sme Logging and Monitoring Policy-sme - SME definește o cerință minimă de jurnalizare:
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.
Politica Enterprise Logging and Monitoring Policy Logging and Monitoring Policy extinde setul de evenimente așteptate:
Tipuri de evenimente care trebuie capturate (de exemplu, autentificări, eșecuri de acces, modificări de configurație, comenzi administrative, detectarea malware-ului)
Din secțiunea „Cerințe de guvernanță”, clauza de politică 5.1.1.
Pentru Conditional Access, dovezile utile trebuie să includă autentificări reușite, autentificări eșuate, rezultatul politicii Conditional Access, metoda MFA, riscul de autentificare, riscul utilizatorului, starea de conformitate a dispozitivului, aplicația accesată, locația, aplicația client, rezultatul controlului sesiunii, istoricul modificărilor politicilor și acțiunile administrative.
Zenith Controls mapează controlul ISO/IEC 27002:2022 8.16 Activități de monitorizare ca detectiv și corectiv, asociat conceptelor Detectare și Răspuns. Acesta conectează monitorizarea la jurnalizare, evaluarea evenimentelor, informații privind amenințările, monitorizarea furnizorilor și gestionarea incidentelor. De asemenea, mapează activitățile de monitorizare la GDPR Articles 32 și 33, monitorizarea și raportarea incidentelor NIS2, urmărirea incidentelor TIC în DORA, monitorizarea continuă NIST și monitorizarea securității COBIT.
Prin urmare, o autentificare cu risc ridicat blocată de Conditional Access nu este doar un succes de securitate. Este dovada că procesele preventive, detective și de răspuns sunt conectate.
Controalele de sesiune: legătura dintre acces și protecția datelor
Deciziile înainte de acces nu sunt suficiente. După autentificarea utilizatorului, controalele de sesiune determină câtă expunere rămâne. Acest lucru este deosebit de important pentru dispozitive neadministrate, contractori, lucru la distanță, terminale partajate, locații riscante și aplicații care prelucrează date cu caracter personal.
Politica SME Application Security Requirements Policy-sme Application Security Requirements Policy-sme - SME prevede:
Managementul sesiunii: Datele de sesiune trebuie să expire după 15 minute de inactivitate și să includă avertizări de expirare, acolo unde este aplicabil.
Din secțiunea „Cerințe de implementare a politicii”, clauza de politică 6.1.1.3.
În guvernanța Microsoft Entra, aceasta se poate mapa la frecvența autentificării, restricții privind sesiunile persistente de browser, Conditional Access App Control, restricții aplicate de aplicație, blocarea descărcărilor, reautentificare după modificarea riscului și limitări de sesiune bazate pe sensibilitate.
Controalele de sesiune susțin controlul ISO/IEC 27002:2022 8.3 Restricționarea accesului la informații și 8.5 Autentificare securizată. De asemenea, susțin GDPR Article 32 prin reducerea vizualizării neautorizate, descărcării neautorizate sau persistenței accesului la date cu caracter personal. Pentru DORA, restricțiile de sesiune ajută la limitarea expunerii în sistemele TIC și susțin detectarea și răspunsul. Pentru NIS2, acestea sunt măsuri proporționale de control al accesului și igienă cibernetică.
Dovezile trebuie să explice de ce există controlul de sesiune. De exemplu, „blocarea descărcării de pe dispozitive neadministrate pentru aplicații HR și financiare” trebuie mapată la scurgerea de date cu caracter personal, compromiterea endpointului și pierderea confidențialității. Dovezile trebuie să includă configurația, domeniul de aplicare al aplicațiilor, autentificări de test de pe dispozitive administrate și neadministrate, jurnale care arată restricțiile și înregistrări de aprobare.
Creați un registru de control Conditional Access
Un registru de control Conditional Access este puntea operațională dintre Registrul riscurilor, Declarația de aplicabilitate și configurația Microsoft Entra. Nu înlocuiește aceste documente. Le face utilizabile.
| Câmp al registrului | Exemplu de intrare |
|---|---|
| Scenariu de risc | Credențiale compromise utilizate pentru a accesa SaaS financiar de pe un dispozitiv neadministrat |
| Politică Conditional Access | CA-High-Risk-Finance-Require-MFA-Compliant-Device |
| Intenția controlului | Impunerea MFA, solicitarea unui dispozitiv conform, blocarea riscului ridicat de autentificare și restricționarea sesiunilor neadministrate |
| Surse de dovezi | Export CA, jurnale de autentificare, raport privind conformitatea dispozitivelor, registru de excepții și tichet de alertă SOC |
| Mapare de conformitate | ISO/IEC 27002:2022 5.15, 8.1, 8.3, 8.5, 8.15 și 8.16, NIS2 Article 21, DORA Articles 6 și 9, GDPR Article 32 |
Utilizați un ciclu de revizuire în cinci pași:
- Confirmați domeniul de aplicare: Identificați aplicațiile cloud care prelucrează date reglementate, financiare, operaționale sau cu caracter personal.
- Mapați politicile la riscuri: Corelați fiecare politică Conditional Access cu cel puțin un scenariu de risc și un proprietar de risc.
- Validați excluderile: Exportați utilizatorii, rolurile, aplicațiile, grupurile, locațiile și dispozitivele excluse. Fiecare excludere necesită proprietar, motiv, aprobare și termen de expirare.
- Testați aplicarea: Utilizați conturi de test pentru a verifica MFA, conformitatea dispozitivelor, blocarea riscului, blocarea autentificării prin protocoale vechi și restricțiile de sesiune.
- Pachetați dovezile: Stocați exporturile, capturile de ecran, jurnalele și aprobările împreună cu metadatele.
Politica SME Audit and Compliance Monitoring Policy-sme Audit and Compliance Monitoring Policy-sme - SME este critică pentru integritatea dovezilor:
Metadatele (de exemplu, cine le-a colectat, când și din ce sistem) trebuie documentate.
Din secțiunea „Cerințe de implementare a politicii”, clauza de politică 6.2.3.
Capturile de ecran fără sursă, dată, colector și context de sistem sunt dovezi slabe. Exporturile Conditional Access, jurnalele de autentificare și rapoartele de revizuire trebuie tratate ca înregistrări de audit controlate.
Mapare de conformitate încrucișată pentru dovezile Conditional Access
Valoarea Conditional Access constă în faptul că un singur set de controale poate satisface mai multe perspective de audit atunci când este guvernat corespunzător.
| Caracteristică Conditional Access | Control principal ISO/IEC 27002:2022 | Legătură NIS2 | Legătură DORA | Legătură GDPR | Dovezi de furnizat |
|---|---|---|---|---|---|
| MFA pentru administratori | 8.2 Drepturi de acces privilegiat și 8.5 Autentificare securizată | Article 21 controlul accesului și MFA | Articles 5, 6 și 9 guvernanță și protecție | Article 32 securitatea prelucrării | Politică de acces, configurație CA, listă de roluri privilegiate, jurnale de autentificare care arată MFA |
| Blocarea dispozitivelor neadministrate | 8.1 Dispozitivele utilizatorilor finali și 5.15 Controlul accesului | Article 21 igienă cibernetică și managementul activelor | Article 9 protecție și prevenire | Articles 25 și 32 protecția datelor începând cu momentul proiectării și securitate | Politică de telemuncă, politică de conformitate a dispozitivelor, configurație CA, jurnale de autentificare blocată |
| Blocarea autentificărilor cu risc ridicat | 8.16 Activități de monitorizare și 8.5 Autentificare securizată | Articles 21 și 23 monitorizare și pregătire pentru incidente | Articles 10, 17 și 18 detectare și clasificarea incidentelor | Articles 32 și 33 securitate și dovezi privind încălcarea securității datelor | Politică de jurnalizare, configurație de risc, jurnale Identity Protection, tichete SOC |
| Restricționarea sesiunilor neadministrate | 8.3 Restricționarea accesului la informații | Article 21 controlul accesului și igienă cibernetică | Article 9 restricții de acces | Article 32 confidențialitate și integritate | Politică de sesiune, dovezi CA App Control, rezultate ale testelor de pe dispozitive administrate și neadministrate |
| Blocarea autentificării prin protocoale vechi | 8.5 Autentificare securizată | Article 21 controlul accesului | Article 9 protecție și prevenire | Article 32 securitatea prelucrării | Raport de protocol, politică CA, rezultate ale testelor, înregistrare a schimbării |
| Revizuirea trimestrială a excluderilor | 5.18 Drepturi de acces | Article 20 supraveghere și Article 21 evaluarea eficacității | Article 5 responsabilitatea managementului | Article 24 responsabilitate | Registru de excepții, aprobări, date de expirare, procese-verbale ale analizei efectuate de management |
Zenith Controls mapează, de asemenea, 5.15 Controlul accesului la GDPR Article 32, NIS2 Article 21(2)(i), concepte de guvernanță a accesului din DORA, familiile de control al accesului NIST SP 800-53 și COBIT 2019 DSS06.04. Acesta mapează 8.5 Autentificare securizată la GDPR Articles 5, 24, 25 și 32, managementul riscurilor de securitate cibernetică NIS2, managementul riscurilor TIC DORA, identificare și autentificare NIST și identitate și acces logic COBIT.
Lecția este simplă. Cadrele folosesc limbaje diferite, dar așteaptă același tipar de asigurare: utilizatorii potriviți, din contexte acceptabile, folosind autentificare puternică, prin sesiuni guvernate, cu jurnale care dovedesc ce s-a întâmplat.
Cum vor examina auditorii Conditional Access
Un auditor ISO/IEC 27001:2022 va începe cu SMSI. Va întreba dacă Conditional Access este în domeniul de aplicare, ce riscuri tratează, cum apare în SoA, cum sunt aprobate politicile, cum sunt controlate schimbările și dacă dovezile demonstrează eficacitatea operațională. Așteptați-vă la eșantionarea utilizatorilor privilegiați, aplicațiilor sensibile, excluderilor și modificărilor recente de politică.
Un auditor DORA sau NIS2 se va concentra pe reziliența operațională, responsabilitatea managementului și risc. Poate întreba cum protejează controalele de acces funcțiile critice sau importante, cum supraveghează consiliul de administrație riscul de identitate, cum sunt triate autentificările cu risc ridicat și dacă eșecurile de acces alimentează deciziile de clasificare sau raportare a incidentelor.
Un auditor axat pe GDPR va fi interesat de datele cu caracter personal. Poate întreba cum sunt protejate datele HR, financiare sau ale clienților împotriva dispozitivelor neadministrate, cum reduc controalele de sesiune vizualizarea neautorizată, cum este limitat accesul la utilizatori autorizați și cum susțin jurnalele evaluarea încălcărilor securității datelor.
Un evaluator COBIT 2019 va căuta practici de guvernanță, proprietate, metrici, repetabilitate, monitorizarea performanței și îmbunătățire. Un evaluator orientat spre NIST va compara rezultatele privind identitatea, autentificarea, autorizarea, monitorizarea și răspunsul cu dovezile tehnice.
Politica Enterprise Access Control Policy Access Control Policy stabilește direcția pentru accesul privilegiat:
Accesul administrativ trebuie controlat strict prin:
Din secțiunea „Cerințe de guvernanță”, clauza de politică 5.4.1.
Dovezile dumneavoastră Microsoft Entra trebuie să completeze operațional acea propoziție. Ce roluri sunt privilegiate? Care solicită MFA rezistentă la phishing sau puternică? Care sunt eligibile prin managementul identității privilegiate? Ce conturi sunt break-glass? Care sunt excluse din politici? Cine le revizuiește? Unde sunt trimise alertele?
Metrici pentru consiliul de administrație privind guvernanța Conditional Access
Deoarece NIS2 și DORA subliniază responsabilitatea managementului, raportarea Conditional Access trebuie să fie lizibilă pentru consiliul de administrație. Evitați raportarea exclusivă a numelor de politici. Raportați profilul de risc și performanța controlului.
Metrici utile includ:
- Procentul conturilor privilegiate protejate prin MFA puternică.
- Numărul de excluderi Conditional Access pe nivel de risc.
- Numărul de autentificări cu risc ridicat blocate, supuse verificării suplimentare sau permise.
- Procentul accesului la aplicații sensibile care impune dispozitive conforme.
- Numărul de sesiuni de pe dispozitive neadministrate către aplicații reglementate.
- Timpul de triaj al evenimentelor de autentificare cu risc ridicat.
- Numărul de modificări ale politicilor Conditional Access în trimestru.
- Numărul de excepții expirate, reînnoite și restante.
- Acoperirea jurnalizării pentru autentificare, sesiuni și modificări ale politicilor.
- Cazurile de test eșuate din validarea trimestrială Conditional Access.
Aceste metrici transformă configurația identității în dovezi de supraveghere. De asemenea, ajută organismele de conducere să demonstreze aprobarea, revizuirea, alocarea resurselor și îmbunătățirea continuă.
Constatări comune de eliminat înainte de audit
Constatările privind Conditional Access provin de regulă din slăbiciuni de guvernanță, nu din eșecuri tehnologice. Cele mai comune probleme includ:
- Conturile break-glass sunt excluse, dar nu sunt monitorizate.
- Politicile sunt denumite inconsecvent și nu au proprietari.
- Aplicațiile sensibile lipsesc din regulile de conformitate a dispozitivelor.
- Utilizatorii invitați și colaboratorii externi ocolesc controalele standard.
- Conturile de serviciu și identitățile workload nu sunt guvernate separat.
- Detecțiile de risc la autentificare nu sunt triate sau legate de incidente.
- Controalele de sesiune nu sunt testate niciodată de pe dispozitive neadministrate.
- Modificările de politică sunt făcute direct în producție fără înregistrări ale schimbărilor.
- Excluderile sunt permanente, nedocumentate sau aprobate verbal.
- Jurnalele sunt păstrate, dar nu sunt revizuite.
- Dovezile nu au metadate, context de sursă sau lanț de custodie.
O stare-țintă pregătită pentru 2026 include guvernanță a accesului aprobată de management, proiectare Conditional Access bazată pe risc, mapare explicită ISO/IEC 27001:2022 și ISO/IEC 27002:2022, suport documentat pentru NIS2, DORA și GDPR, MFA puternică pe rol și risc, conformitatea dispozitivelor pentru acces sensibil, restricții de sesiune pentru contexte neadministrate, monitorizarea autentificării și a modificărilor de politică, un ciclu de viață al excepțiilor, testare trimestrială și raportare către management.
Transformați Microsoft Entra în dovezi pregătite pentru audit
Politicile dumneavoastră Conditional Access iau deja decizii de securitate în fiecare minut. Întrebarea este dacă aceste decizii sunt guvernate, bazate pe risc, monitorizate și mapate la obligațiile care contează pentru auditorii și autoritățile dumneavoastră de reglementare.
Începeți cu Zenith Blueprint Zenith Blueprint, în special Pasul 13, pentru a conecta politicile Conditional Access la riscuri, tratamente, Declarația de aplicabilitate și note de reglementare. Utilizați Zenith Controls Zenith Controls pentru a mapa controlul accesului, autentificarea securizată, postura de securitate a endpointurilor, jurnalizarea și monitorizarea în ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIS2, DORA, GDPR, NIST și COBIT 2019.
Apoi aliniați cerințele interne cu politicile Clarysec, inclusiv Cloud Usage Policy-sme, Network Security Policy-sme, Logging and Monitoring Policy-sme, Audit and Compliance Monitoring Policy-sme, Application Security Requirements Policy-sme, Cloud Usage Policy, User Account and Privilege Management Policy, Remote Work Policy, Access Control Policy și Logging and Monitoring Policy.
Clarysec vă ajută să transformați Microsoft Entra Conditional Access dintr-o colecție de setări într-un sistem de control aplicabil, măsurabil și pregătit pentru audit. Descărcați kiturile Clarysec relevante, solicitați o revizuire a mapării politicilor sau programați o evaluare pentru a vedea dacă dovezile dumneavoastră Conditional Access pot rezista examinării ISO 27001, NIS2, DORA și GDPR.
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


