Come Conditional Access e PIM fermano effettivamente gli attacchi?

Le policy delle password fermano gli attacchi di forza bruta. Non fanno niente contro un token di sessione rubato, un prompt MFA phished, o un account admin permanente che è rimasto lì con i diritti di Global Administrator per due anni. Conditional Access e Privileged Identity Management (PIM) sono i due controlli di Azure AD / Entra ID che affrontano effettivamente queste lacune, e funzionano meglio insieme.

Cosa fa Conditional Access dietro le quinte

Conditional Access è un motore if-this-then-that valutato al momento del sign-in. Il lato "if" (segnali) include l'appartenenza a utente/gruppo, lo stato di conformità del dispositivo, la posizione di rete, il rischio di sign-in (da Identity Protection), l'applicazione a cui si accede, e il tipo di app client (browser rispetto a protocollo legacy). Il lato "then" (controlli) include: richiedere MFA, richiedere un dispositivo conforme, richiedere un'app client approvata, bloccare l'accesso completamente, o richiedere l'accettazione delle condizioni d'uso.

Una policy che importa in quasi ogni tenant: bloccare l'autenticazione legacy. I protocolli come POP, IMAP, e SMTP più vecchio non supportano le sfide MFA moderne, quindi sono la prima cosa che provano gli strumenti di credential stuffing. Controlla i log di sign-in filtrati per "Client App = Other clients" prima di bloccare — spesso troverai uno scanner legacy o una vecchia stampante multifunzione che si autentica ancora con basic auth.

Una seconda che vale avere dal primo giorno: richiedere MFA per tutti gli utenti, con un ambito di esclusione per soli account break-glass. Non limitare MFA a "solo admin." Gli account utente standard compromessi sono come gli attaccanti ottengono il loro primo punto d'appoggio prima ancora che inizi l'escalazione dei privilegi.

Rischio di sign-in vs. rischio di utente — segnali diversi, risposte diverse

Identity Protection (parte di Entra ID P2) genera due punteggi di rischio separati ed è facile confonderli:

• Rischio di sign-in — questo specifico tentativo di autenticazione sembra anomalo (viaggio impossibile, IP anonimo, proprietà di sign-in non familiari).
• Rischio di utente — questo account è stato contrassegnato per un motivo legato all'identità stessa (credenziali trapelate trovate in un corpus di violazione, attività di compromesso confermata).

Una policy di Conditional Access che risponde al rischio di sign-in dovrebbe tipicamente sfidare con MFA — se l'utente vero può completare la sfida, lascialo passare. Una policy che risponde al rischio di utente dovrebbe forzare un reset della password, perché la sola MFA non aiuta se la credenziale stessa è già bruciata.

Perché l'accesso permanente da admin è il problema più grande

Anche con Conditional Access ermetico, un account che detiene Global Administrator in permanenza è un bersaglio in chiaro nella directory. Chiunque lo comprometta eredita il controllo completo del tenant senza nessun step aggiuntivo richiesto. PIM rimuove la parte "permanente".

Con PIM, i ruoli di admin vengono assegnati come idonei piuttosto che attivi. L'utente deve esplicitamente attivare il ruolo, il che innesca una giustificazione richiesta, un flusso di approvazione opzionale, una ri-conferma MFA, e una finestra limitata nel tempo — comunemente da 1 a 8 ore — dopo la quale il ruolo si disattiva automaticamente. Nessuno, nemmeno il proprietario dell'account, ha Global Admin permanente a meno che non lo stia attivamente usando.

Una configurazione minima di PIM che è effettivamente usabile

• Ogni ruolo sopra Helpdesk Administrator: idoneo, non permanente.
• Global Administrator e Privileged Role Administrator: richiedono approvazione da un secondo admin, non solo auto-attivazione.
• MFA richiesta all'attivazione, nessuna eccezione.
• Durata di attivazione massima di 4 ore forza la gente a riattivare per sessioni di lavoro genuinamente separate, il che produce anche audit trail più puliti.
• Revisioni di accesso ogni 90 giorni su tutti gli assegnamenti idonei — gli account vengono aggiunti per un progetto e mai rimossi diversamente.

Dove i team sbagliano

L'errore più comune non è il design della policy, è la lista di esclusione. Una policy di Conditional Access con un gruppo "escludi questi utenti perché l'app non supporta MFA" sempre più grande alla fine esclude metà del tenant. Traccia le esclusioni come un elemento backlog con un proprietario e una data di rimozione, non come un bucket permanente.

Il secondo errore è gli account break-glass che non vengono effettivamente testati. Due account di emergenza, esclusi da Conditional Access e PIM, con password casuali lunghe memorizzate offline e alert su qualsiasi sign-in — e qualcuno dovrebbe provare a effettuare il login su di essi trimestralmente per confermare che funzionano ancora.

Conditional Access e PIM non sono una casella di controllo per un audit di conformità. Sono la differenza tra una credenziale phished che è un inconveniente e una compromissione completa del tenant. Se stai mappando i controlli di identità come parte di un build-out Blue Team, i segmenti Cloud e Blue Team di Korra Studio coprono il lato della detection — cosa gli eventi di rischio di Identity Protection assomigliano effettivamente in Sentinel e come alertare su pattern di attivazione PIM impossibili.