Cum opresc realmente Conditional Access și PIM atacurile?

Politicile de parolă opresc atacurile prin ghicire. Nu fac nimic împotriva unui token de sesiune furat, a unei solicitări MFA phished sau a unui cont de administrator permanent care stă acolo de doi ani cu drepturi de Global Administrator. Conditional Access și Privileged Identity Management (PIM) sunt cele două controale Azure AD / Entra ID care tratează cu adevărat acele goluri, și funcționează cel mai bine împreună.

Ce face Conditional Access în spatele scenei

Conditional Access este un motor if-this-then-that evaluat la momentul autentificării. Partea "if" (semnale) include apartenența utilizatorului/grupului, starea conformității dispozitivului, locația rețelei, riscul autentificării (din Identity Protection), aplicația accesată și tipul aplicației client (browser vs. protocol legacy). Partea "then" (controale) include: necesită MFA, necesită un dispozitiv conform, necesită o aplicație client aprobată, blochează accesul complet, sau necesită acceptarea unor termeni de utilizare.

O politică care are importanță în aproape fiecare entitate: blochează autentificarea legacy. Protocoale precum POP, IMAP și SMTP mai vechi nu suportă provocări MFA moderne, deci sunt primul lucru pe care îl încearcă instrumentele de credential stuffing. Verifică jurnalele de autentificare filtrate după "Client App = Other clients" înainte să blochezi — adesea vei găsi un scanner legacy sau o imprimantă multifuncțională veche care se mai autentifică cu basic auth.

O a doua politică care merită să o ai de la început: necesită MFA pentru toți utilizatorii, limitată cu un grup de excludere numai pentru conturi de break-glass. Nu limita MFA la "doar administratori." Conturile utilizatorilor standard compromise sunt modul în care atacatorii capătă primul lor picior înainte chiar să înceapă escalada de privilegii.

Riscul de autentificare vs. riscul utilizatorului — semnale diferite, răspunsuri diferite

Identity Protection (parte din Entra ID P2) generează două scoruri de risc separate și este ușor să le confunzi:

• Riscul de autentificare — această încercare de autentificare specifică arată anomal (imposibilă călătorie, IP anonim, proprietăți de autentificare nefamiliar).
• Riscul utilizatorului — acest cont a fost marcat dintr-un motiv legat de identitatea în sine (credențiale scurse găsite într-un corpus de cărări, activitate de compromitere confirmată).

O politică Conditional Access care răspunde la riscul de autentificare ar trebui să provoace tipic cu MFA — dacă utilizatorul real poate completa provocarea, lasă-l să treacă. O politică care răspunde la riscul utilizatorului ar trebui să forțeze o resetare a parolei, pentru că MFA singur nu ajută dacă credențialul în sine este deja ars.

De ce accesul administrator permanent este mai mare problemă

Chiar și cu Conditional Access perfect etanș, un cont care deține Global Administrator permanent este o țintă șezând pe vedere în director. Oricine îl compromite moștenește controlul plin al entității fără niciun pas suplimentar necesar. PIM elimină partea "permanent".

Cu PIM, rolurile de administrator sunt atribuite ca eligibile mai degrabă decât active. Utilizatorul trebuie să activeze explicit rolul, ceea ce declanșează o justificare necesară, fluxul de lucru al aprobării opțional, reconfirmarea MFA și o fereastră limitată în timp — obișnuit 1 la 8 ore — după care rolul se dezactivează automat. Nimeni, inclusiv proprietarul contului, nu are Global Admin permanent decât dacă îl folosește în mod activ.

O configurație minimă PIM care este de fapt utilizabilă

• Fiecare rol deasupra Helpdesk Administrator: eligibil, nu permanent.
• Global Administrator și Privileged Role Administrator: necesită aprobarea dintr-un al doilea administrator, nu doar auto-activare.
• MFA de activare necesar, fără excepții.
• Durata maximă de activare de 4 ore forțează oamenii să reactiveze pentru sesiuni de lucru cu adevărat separate, care produce și piste de audit mai curate.
• Evaluări de acces la fiecare 90 de zile pe toate atribuirile eligibile — conturile sunt adăugate pentru un proiect și niciodată eliminate altfel.

Unde greșesc echipele

Eșecul cel mai obișnuit nu este designul politicii, ci lista de excludere. O politică Conditional Access cu un grup "excludeți acești utilizatori pentru că aplicația nu suportă MFA" care crește constant exclude în sfârșit jumătate din entitate. Urmărește excluderile ca element din backlog cu un proprietar și o dată de ștergere, nu o găleată permanentă.

Al doilea eșec sunt conturile de break-glass care nu sunt de fapt testate. Două conturi de urgență, excluse din Conditional Access și PIM, cu parolele lungi și aleatoare stocate offline și alertare la orice autentificare — și cineva ar trebui să încerce să se conecteze în ele trimestrial pentru a confirma că funcționează încă.

Conditional Access și PIM nu sunt o casetă pentru un audit de conformitate. Sunt diferența dintre o credențială phished fiind o incomoditate și ea fiind o compromitere completă a entității. Dacă mapezi controale de identitate ca parte a unei construcții Blue Team, segmentele Cloud și Blue Team ale Korra Studio acoperă partea de detecție — cum arată cu adevărat evenimentele de risc Identity Protection în Sentinel și cum să alerți pe modelele de activare PIM imposibile.