Sesiunea 7
Microsoft Entra ID & Zero Trust
Identitate, Conditional Access, PIM și Passwordless
Introducere
Microsoft Entra ID & Zero Trust Architecture
Obiective de învățare
Ghid complet zero-to-hero în limba română. Material didactic pentru ingineri cloud la început de drum, administratori Azure și arhitecți care vor să construiască implementări moderne, sigure și ușor de operat.
Ce vei stăpâni după acest curs
Autentificare vs. autorizare
Diferența clară dintre autentificare, autorizare, identitate și controlul privilegiilor.
Roluri și identități
Când folosești Microsoft Entra roles, Azure RBAC, service principals și managed identities.
Conditional Access
Construiești politici Conditional Access din portal și le testezi în report-only înainte de enforce.
PIM & Just-in-Time
Implementezi PIM pentru acces just-in-time și reduci standing privilege pentru rolurile sensibile.
Passwordless rollout
Proiectezi un rollout passwordless realist, inclusiv Temporary Access Pass pentru onboarding.
Zero Trust în scenarii reale
Aplici principiile Zero Trust în Azure: Portal, AKS, App Service, Key Vault, Storage, SQL și admin access.
Slide 3
De ce identitatea este atât de importantă
În trecut, multe organizații tratau rețeaua ca pe o clădire de birouri. Dacă ai trecut de poarta principală, presupunerea era că ești de încredere. Astăzi, modelul acesta nu mai funcționează bine. Utilizatorii lucrează de acasă, folosesc SaaS, deschid aplicații din browser și accesează API-uri care nu locuiesc toate în același subnet.
Securitatea modernă nu înseamnă doar VNet, NSG și firewall. Înseamnă decizii de acces luate dinamic, bazate pe identitate, dispozitiv, risc, aplicație, rol și comportament.
Analogia aeroportului: Nu este suficient să fii în parcarea aeroportului ca să poți urca în avion. Treci prin verificarea identității, control de securitate, verificare a biletului, eventual control suplimentar dacă apar factori de risc. Conditional Access și PIM fac exact acest lucru pentru accesul digital.
Slide 4–5
Microsoft Entra ID și ecosistemul Azure
Ce este Microsoft Entra ID
Fostul Azure Active Directory este serviciul de identitate și access control al ecosistemului Microsoft. Stochează utilizatori, grupuri, aplicații, enterprise applications, device identities, metode de autentificare și politicile de acces.
Când te conectezi în Azure Portal, în Microsoft 365 sau într-o aplicație enterprise federată, Entra ID face autentificarea și emite tokenul.
Separarea esențială
Entra ID
Identitate și autentificare. Răspunde la: "Cine ești?" și "În ce condiții te las să intri?"
Azure RBAC
Autorizare pe resurse Azure. Intervine după autentificare. Răspunde la: "Ce ai voie să faci după ce ai intrat?"
Managed Identity
Identitate fără secrete pentru workload-uri. Gestionată de platformă, fără parole sau certificate manuale.
Obiecte și concepte importante în Entra ID
Tenant
Instanța ta logică de identitate. O organizație poate avea unul sau mai multe tenants.
User
Identitatea unei persoane. Poate fi cloud-only, sincronizată din AD sau invitată B2B.
Group
Folosit pentru a grupa utilizatori și a simplifica assignment-urile.
App Registration
Definiția logică a unei aplicații care vrea să folosească identitatea Microsoft.
Service Principal
Instanța acelei aplicații într-un tenant; identitatea pe care o vede organizația ta.
Enterprise Application
Reprezentarea unei aplicații folosite în tenant pentru SSO, provisioning și policy.
Slide 6–8
Zero Trust pe înțelesul tuturor
Zero Trust nu este un singur produs și nici un singur buton din portal. Este un mod de a proiecta securitatea pe baza a trei idei simple.
Analogia hotelului modern: Chiar dacă ai intrat în recepție, nu poți deschide orice cameră. Cardul tău este verificat pentru o anumită ușă, într-un anumit interval de timp, iar camerele tehnice au acces separat și mai strict. Exact așa ar trebui tratat și accesul în cloud.
Cele trei principii Zero Trust
Verifică explicit
Folosești semnale precum identitatea, rolul, riscul, dispozitivul, locația, aplicația și sensibilitatea resursei înainte să permiți accesul. Nicio decizie de acces nu se ia implicit.
Acordă minimul necesar
Nu oferi Owner sau Global Administrator pentru orice nevoie. Dai exact cât trebuie, la nivelul de scope potrivit și pe durata potrivită.
Presupune că există deja o breșă
Segmentezi accesul, monitorizezi, faci review-uri și construiești astfel încât compromiterea unei identități să nu însemne compromiterea întregii organizații.
Slide 10–14
Conditional Access în profunzime
Conditional Access este policy engine-ul Zero Trust al Microsoft Entra. Politicile sunt reguli de tip if-then: dacă un anumit user sau workload încearcă să acceseze o resursă într-un anumit context, atunci aplică grant controls sau session controls.
Cele mai comune semnale sunt: utilizator sau grup, aplicație, device platform, locație, client app, sign-in risk, user risk, authentication strength și filtre pentru workload identities.
Best practice: Începe cu report-only. Astfel vezi în jurnale cine ar fi fost blocat sau forțat să facă MFA, fără să strici producția în prima zi.
Componentele unei politici Conditional Access
| Componentă | Rol |
|---|---|
| Assignments | Cui se aplică și ce resurse acoperă: users, groups, workload identities, cloud apps, actions. |
| Conditions | Context suplimentar: locație, platformă, client app, sign-in risk, device filter. |
| Grant controls | Ce trebuie să se întâmple: require MFA, compliant device, authentication strength, block access. |
| Session controls | Ce se întâmplă după autentificare: sign-in frequency, app enforced restrictions, CAE. |
| Policy state | Disabled, Report-only sau On. |
Politici Conditional Access recomandate
MFA pentru administratori
Require MFA sau authentication strength phishing-resistant pentru toți administratorii privilegiați.
Blocare legacy authentication
Blocare protocoale care ocolesc controalele moderne de autentificare.
Compliant device
Require compliant device pentru aplicații sau date sensibile.
Politici pentru workload identities
Controale separate — serviciile nu pot face MFA ca un om.
Named locations și risc
Politici pentru scenarii din afara țării sau din rețele nesigure, bazate pe locație sau risc.
Exclude-uri controlate strict
Doar pentru break-glass accounts și conturi de urgență, bine documentate.
Cum creezi o politică Conditional Access — pas cu pas
Navighează la Conditional Access
Microsoft Entra admin center → Protection → Conditional Access → Policies → New policy.
Alege un nume clar
Exemplu: CA - Admins - Require MFA sau CA - Storage - Require compliant device.
Selectează Users / Workload identities
Folosește grupuri dedicate, nu selecții haotice user-cu-user.
Target resources
Alege aplicațiile sau acțiunile. Multe organizații aleg All resources și rafinează cu excepții.
Conditions
Setezi contextul: locații, platforme, client apps, filters, risk.
Grant controls
Require MFA, authentication strength, compliant device sau block access.
Report-only → validare → On
Pune politica în Report-only, validează în sign-in logs, apoi comută pe On.
Capcane frecvente în Conditional Access
Politici direct pe All users
Fără test pilot și fără conturi break-glass — cel mai rapid mod de a te bloca singur afară din tenant.
Amestecarea politicilor
Un serviciu nu poate satisface aceleași controale interactive ca un utilizator uman.
Confuzia autentificare vs. autorizare
Conditional Access decide intrarea; RBAC decide operațiile după intrare.
Lipsa monitorizării
O politică bună este una observabilă, nu doar una bifată în portal.
Slide 15–18
Privileged Identity Management (PIM)
PIM există pentru a reduce standing privilege. În loc să ții un om permanent Owner, Privileged Role Administrator sau Global Administrator, îl faci Eligible și îi permiți activarea rolului doar când are nevoie, pentru o durată limitată și cu controale suplimentare.
Analogia cheii de la camera tehnică: Nu o ții tot timpul în buzunarul tuturor. Ea stă într-un seif, iar cine o ia trebuie să lase urme: cine e, de ce are nevoie, pentru cât timp și cine aprobă.
Termeni esențiali PIM
Cum activezi PIM și configurezi un rol — pas cu pas
Navighează la PIM
Microsoft Entra admin center → Identity Governance → Privileged Identity Management.
Alege tipul de rol
Microsoft Entra roles, Azure resources sau Groups.
Selectează rolul sensibil
De exemplu: Global Reader, Security Administrator sau Contributor pe o subscription.
Configurează ca Eligible
Assignment Eligible, nu Active, pentru utilizatorii normali de administrare.
Setează controalele de activare
Activation duration, require MFA on activation, ticket info sau justification și approvers.
Adaugă Access Reviews
Recertificarea periodică a accesului și eliminarea privilegiilor expirate.
Monitorizează
Verifică activity history și alerts pentru roluri prea largi sau activări neobișnuite.
Slide 19–22
Managed Identities pentru workload-uri
Managed identity este modul preferat în Azure pentru a da unei resurse o identitate fără să salvezi manual parole, client secrets sau certificate în config files. Azure creează și gestionează identitatea pentru resursă, iar aplicația obține tokenul din platformă.
Analogia badge-ului: În loc să-i dai aplicației o cheie fizică și să te rogi să nu o piardă, îi dai un badge emis și rotit de clădire, iar badge-ul poate fi revocat și controlat central.
System-assigned vs. User-assigned Managed Identity
| Criteriu | System-assigned | User-assigned |
|---|---|---|
| Lifecycle | Legat de resursă | Independent |
| Partajare | Nu poate fi partajată | Poate fi partajată între resurse |
| Ideal pentru | Resurse independente | Integrări shared |
| Configurare | Simplă, din portal | Administrare centralizată |
| Recomandare | Prima alegere pentru majoritatea scenariilor | Când mai multe resurse chiar au nevoie de aceeași identitate |
Deploy din portal: App Service + Managed Identity + Key Vault
Activează System-assigned Identity
App Service → Identity → System assigned = On. Azure creează automat identity principal-ul în Entra ID.
Acordă acces în Key Vault
Key Vault → Access control (IAM). Atribuie Key Vault Secrets User, la scope-ul corect.
Folosește DefaultAzureCredential în cod
SDK-ul obține token automat fără nimic sensibil în appsettings.
Testează și verifică logs
Testează din aplicație și verifică în diagnostic logs și activity logs.
Regulă de aur: Nu da Administrator dacă aplicația trebuie doar să citească un secret.
Bune practici pentru Managed Identities
System-assigned pentru resurse unice
Când identitatea aparține clar unei singure resurse.
User-assigned pentru resurse partajate
Când mai multe resurse partajează aceeași identitate controlat.
Roluri minime
Evită Contributor sau Owner fără justificare clară.
Evită secretele long-lived
Nu pune secrete în pipelines și aplicații dacă o managed identity rezolvă scenariul.
Separă prod de non-prod
Nu reutiliza aceeași identitate peste tot.
Monitorizează role assignments
Verifică periodic privilegiile excesive acordate identity-urilor.
Slide 23–26
Passwordless și phishing-resistant authentication
Passwordless nu înseamnă doar confort. Înseamnă reducerea dependenței de parole, care pot fi phishing-uite, reutilizate sau slabe. În Entra ID, metodele moderne includ Windows Hello for Business, passkeys/FIDO2 security keys și Temporary Access Pass pentru onboarding și recovery.
Parola este ca un cod scris pe un bilețel pe care îl poți dicta la telefon. O metodă phishing-resistant este mai aproape de o cheie criptografică legată de dispozitivul tău și de o confirmare biometrică locală.
Strategia practică de rollout passwordless
Pilot cu IT și security champions
Începe cu un pilot: IT, security champions și câțiva utilizatori din business.
Activează metodele în Entra
Authentication Methods: definește ce grupuri au voie să folosească fiecare metodă.
Configurează Temporary Access Pass
TAP pentru onboarding și recovery controlat. Este etapa de bootstrap, nu metoda permanentă.
Comunică experiența de înrolare
Device requirements, ce faci dacă schimbi telefonul sau pierzi cheia FIDO2.
Migrare treptată
Mută grupurile critice spre metode phishing-resistant și redu dependența de SMS.
Slide 27–28
Zero Trust într-o implementare reală Azure
Să luăm un exemplu realist: o echipă administrează un AKS, un App Service, un Key Vault și un Storage Account.
Design recomandat pentru roluri și privilegii
| Rol / identitate | Model recomandat |
|---|---|
| Break-glass accounts | Foarte puține, excluse controlat, monitorizate sever și protejate offline. |
| Administratori uzuali | Eligibili în PIM, MFA obligatoriu la activare, role assignment la scope minim. |
| Developeri | Acces pe dev/test, Contributor doar unde e nevoie, fără Owner implicit. |
| Workload App Service | System-assigned MI, rol Key Vault Secrets User, fără secret în config. |
| Workload shared | User-assigned MI doar dacă mai multe resurse chiar au nevoie de aceeași identitate. |
Slide 29–30
Monitorizare, audit și operațiuni
Identitatea trebuie tratată ca un sistem operațional, nu doar ca o configurare inițială. Asta înseamnă să urmărești sign-in logs, audit logs, activări PIM, role assignments și modificări de politică.
Ce ar trebui să urmărească un inginer cloud
Roluri mari active permanent
Conturi cu roluri mari active permanent în loc de eligibile prin PIM — standing privilege necontrolat.
Politici CA neevaluate
Politici care există dar nu sunt niciodată evaluate. O politică neevaluată nu protejează nimic.
Identități cu roluri excesive
Service principals și managed identities cu Contributor sau Owner fără justificare clară.
Utilizatori cu metode slabe
Utilizatori care încă depind de SMS deși organizația a făcut rollout passwordless.
Excepții vechi nejustificate
Excepții care au rămas în politici. Tratează-le ca security debt și curăță periodic.
Slide 31
Compararea controalelor: când folosești ce
Ghid de decizie pentru controale
| Control | Ce face | Îl alegi când | Nu uita |
|---|---|---|---|
| Conditional Access | Controlează condițiile de acces | Vrei MFA, compliant device, auth strength | Nu înlocuiește RBAC |
| PIM | Reduce standing privilege, forțează JIT | Ai roluri privilegiate administrative | Combini cu Conditional Access |
| Azure RBAC | Ce acțiuni poți face pe resurse | VM, Storage, AKS, KV, subscription | Nu decide metoda de autentificare |
| Managed Identity | Identitate fără secrete | Workload-uri care accesează alte resurse | Nu este pentru oameni |
| Passwordless | Îmbunătățește autentificarea | Reduci parolele și phishing-ul | Planifică onboarding-ul și recovery |
Slide 32
Laborator practic recomandat
Lab: 90–120 minute
Scenariu: un tenant de test cu câțiva utilizatori, un grup de administratori, un App Service, un Key Vault și o subscription lab.
Creează grupuri pilot
Un grup pilot pentru Conditional Access și un grup separat pentru administratori eligibili în PIM.
Politică CA în report-only
Cere MFA pentru grupul admin la All resources. Verifică rezultatele fără a bloca nimeni.
Testează sign-in
Generează un test sign-in și verifică rezultatul în sign-in logs.
Configurează PIM
PIM pentru un rol Azure pe subscription sau RG și testează activarea cu justificare și MFA.
Managed Identity + Key Vault
System-assigned MI pe un App Service și acces minim în Key Vault.
TAP + Passwordless (opțional)
Configurează Temporary Access Pass și pornește înrolarea unei metode passwordless.
Recapitulare finală
Cere studenților să explice diferența dintre Conditional Access, PIM și RBAC.
Slide 33
Troubleshooting: probleme frecvente
Cum gândești problemele frecvente
| Problemă | Cum o abordezi |
|---|---|
| Politica CA nu pare să se aplice | Verifică scope-ul, exclude-urile, starea report-only și dacă tokenul vechi mai este valid. |
| Un admin are acces prea mare | Verifică dacă rolul este Active în loc de Eligible și dacă există assignment-uri directe în afara PIM. |
| Aplicația nu poate citi secretul din Key Vault | Verifică identity-ul activat, rolul RBAC corect, access policy vs RBAC model și rețeaua/PE. |
| Passwordless rollout are rezistență | Pilot, comunicare, TAP pentru bootstrap și instrucțiuni foarte simple de recovery. |
| Prea multe excepții în politici | Curăță periodic și tratează excepțiile ca debt de securitate. |
Slide 34–35
Best Practices și Mini-glosar
Best Practices de reținut
Identitatea ≠ rețeaua
Zero Trust începe adesea cu identitatea, nu cu firewall-ul.
Group-based assignments
Naming clar pentru politici și roluri. Evită selecțiile haotice user-cu-user.
Report-only → pilot → enforce
Nu aplica politici puternice direct în producție fără validare.
PIM pentru roluri mari
Eligible este starea normală, Active este excepția.
Managed identities
Preferă managed identities în locul secretelor manuale în config files.
Phishing-resistant
Redu dependența de SMS și parole acolo unde este posibil.
Review regulat
Fă review la policies, role assignments și excepții. Tratează excepțiile vechi ca security debt.
Combină controalele
CA + PIM + RBAC + private access + monitorizare. Niciun strat nu este singurul gardian.
Mini-glosar pentru studenți
Întrebări de recapitulare
1 Care este diferența dintre autentificare și autorizare?
Autentificarea verifică cine ești (Entra ID); autorizarea decide ce ai voie să faci pe resurse (Azure RBAC).
2 De ce este important să folosești PIM în loc de roluri permanente?
PIM reduce standing privilege: rolul este Eligible, se activează doar când e nevoie, cu MFA, justificare și durată limitată, reducând blast radius-ul.
3 Când alegi system-assigned vs. user-assigned managed identity?
System-assigned pentru resurse independente (lifecycle legat de resursă). User-assigned când mai multe resurse partajează aceeași identitate.
4 Care sunt cele trei principii Zero Trust?
Verifică explicit, acordă minimul necesar, presupune că există deja o breșă.
5 Ce rol joacă Conditional Access în Zero Trust?
Este policy engine-ul care decide condițiile de acces bazate pe semnale (identitate, dispozitiv, risc, locație) înainte de autentificare.
Temă pentru acasă
Exerciții practice pentru consolidarea cunoștințelor
Configurează o politică CA
Creează o politică Conditional Access în report-only care cere MFA pentru un grup de test și analizează sign-in logs.
Testează PIM
Configurează un rol Eligible în PIM, testează activarea cu MFA și justificare, apoi verifică în activity history.
Deploy cu Managed Identity
Activează system-assigned MI pe un App Service și configurează acces minim la Key Vault fără secrete în cod.
Explorează passwordless
Activează Temporary Access Pass pentru un utilizator de test și înrolează o metodă passwordless (FIDO2 sau Windows Hello).
Folosește un tenant de test sau un lab sandbox — nu experimenta direct pe producție!
Concluzie
În Azure modern, identitatea este una dintre cele mai importante suprafețe de securitate și de operațiuni. Nu este un subiect doar pentru echipa de identity; este un subiect pentru orice cloud engineer.
Când stăpânești Entra ID, Conditional Access, PIM, managed identities și passwordless, nu doar că securizezi mai bine platforma, ci și simplifici foarte mult modul în care aplicațiile și oamenii lucrează în cloud.
Acesta este tipul de cunoaștere care face diferența dintre a ști să creezi resurse în Azure și a ști să operezi Azure într-un mod matur, enterprise și rezilient.
Ce să faci acum (A07)
- Reascultă rezumatul audio sau recitește secțiunile cheie — salt la audio.
- Verifică notele cu quiz-ul acestei sesiuni.
- Laborator legat: Security Mindset în Practică.
Opțional: repetă termenii în Studiu sau joacă un modul din Game Hub.
Crează-ți profil
Dacă nu te loghezi, parcursul prin sesiuni rămâne doar în acest browser: nu îl vezi pe alt dispozitiv sau în alt browser și îl pierzi dacă ștergi datele site-ului ori folosești incognito.
PIN-ul nu este un cont securizat și nu trebuie să fie aceeași combinație ca parole importante (Microsoft, email bancă). Este doar o etichetă locală + sincronizare pentru progresul din Learn Cloud.
Cu prenume, nume și PIN (4 cifre) îți poți continua cursul oriunde — același cont ca în Game Hub și Realizări(vizite, audio, quiz, lectură).
Ai uitat PIN-ul?
Nu există recuperare automată a PIN-ului. Încearcă combinația salvată sau creează un profil nou cu alt nume/prenume (generând alt ID). Pentru date pe server vezi Ajutor · PIN.
Backup & date locale
Exportul este un fișier JSON pentru arhivă personală; nu îl încărca în locuri publice (poate conține pseudo-identificatori).