Sign-in logs e audit logs: due domande diverse

Quando qualcosa non torna, l’amministratore apre il Microsoft Entra admin center e va in Entra ID > Monitoring & health. Lì trova due registri che rispondono a domande diverse, e confonderli è il modo più rapido per perdere mezz’ora.

I sign-in logs registrano i tentativi di accesso. La doc li descrive con tre coordinate: Who (l’identità che accede), How (l’applicazione usata), What (la risorsa raggiunta). Rispondono alla domanda “questo utente è entrato, e se no perché”. Non riguardano solo le persone: i tipi di log sono quattro — Interactive user sign-ins, Non-interactive user sign-ins, Service principal sign-ins e Managed identity sign-ins — quindi anche un’app o un’identità gestita lascia una riga.

Gli audit logs registrano invece i cambiamenti: la doc li presenta come un report completo di ogni evento loggato in Microsoft Entra ID, e cita le modifiche ad applicazioni, gruppi, utenti e licenze. Rispondono a “chi ha fatto questa modifica, e quando”. La tabella mostra data e ora, il servizio che ha loggato l’evento, categoria e nome dell’attività e il suo stato; aprendo una riga compaiono il Correlation ID, i dettagli di attore e target e, dove applicabile, il valore vecchio e quello nuovo della proprietà cambiata. Entrambi i registri sono generati dal sistema e non si possono modificare né cancellare. Per la vista completa dei log di attività di Microsoft 365 serve invece il Microsoft 365 admin center.

Perché quell’accesso è stato bloccato

Sintomo tipico: “non riesco ad entrare”. Si apre il sign-in log, si filtra (utili Correlation ID, Conditional Access, Username, Date, Resource) e si guardano le schede dell’evento. La scheda Conditional Access mostra quale policy o quali policy hanno prodotto l’interruzione, e dal Policy Name si arriva alla configurazione. Le schede Basic Info, Location, Device Info, Authentication Details e Additional Details danno il contesto di utente e dispositivo usato nella valutazione. I codici che l’utente vede nel browser hanno prefisso AADSTS: per esempio 53003 BlockedByConditionalAccess, 53000 DeviceNotCompliant.

Se l’evento non basta c’è uno strumento guidato, il Sign-in diagnostic, raggiungibile da Diagnose & solve problems oppure dall’evento stesso con Launch the Sign-in diagnostic. Produce un Authentication summary e dei Diagnostic results con spiegazione e raccomandazioni, e copre scenari come MFA richiesta da una policy di conditional access, MFA “proofup” non completata, account bloccato, autenticazione legacy, security defaults, accesso bloccato da una risk policy. Per provare una policy prima di metterla in produzione si usa invece il What If tool.

Il terzo pezzo è il rischio. Microsoft Entra ID Protection mette a disposizione tre report: Risk detections, Risky sign-ins e Risky users. La distinzione da tenere ferma: un risky sign-in riguarda quel singolo accesso, un risky user riguarda l’identità. Alcune detection sono calcolate in tempo reale, altre offline: per questo un rischio può comparire dopo che l’accesso è già avvenuto.

Identity Secure Score: un indicatore, non un voto

L’Identity Secure Score si trova in Entra ID > Identity Secure Score, oppure fra le Recommendations filtrando su Security. È una percentuale che indica quanto la configurazione del tenant è allineata alle raccomandazioni Microsoft; ogni improvement action è calcolata sulla configurazione reale e il punteggio viene ricalcolato ogni 24 ore. Alcune azioni valgono tutto o nulla, altre danno un punteggio parziale, come la copertura MFA proporzionale agli utenti effettivamente protetti. Un’azione può essere marcata To address, Planned, Risk accepted, Resolved through third party o Resolved through alternate mitigation, e una raccomandazione ignorata non entra nel calcolo.

Qui sta la confusione tipica, e la doc è netta: il punteggio non esprime la probabilità di subire una violazione, esprime quanto si sono adottate funzionalità capaci di ridurre il rischio. Non c’è un valore minimo da inseguire: conta di più stare bene sulle raccomandazioni ad alta importanza. Da non confondere con i vicini: l’Identity Secure Score è la parte identità del Microsoft Secure Score, che ha cinque categorie (Identity, Data, Devices, Infrastructure, Apps) e si consulta nel portale Microsoft Defender XDR; Compliance Manager, in Microsoft Purview, misura un’altra cosa ancora, cioè la conformità normativa.

PIM, App registrations ed Enterprise apps

Privileged Identity Management (PIM) è il servizio che gestisce, controlla e monitora l’accesso alle risorse importanti. L’idea centrale è il privilegio just-in-time: permessi temporanei, concessi quando servono e destinati a scadere. Un’assegnazione è eligible — l’utente può attivare il ruolo quando ne ha bisogno — oppure active, e in quel caso il privilegio ce l’ha già senza fare nulla. L’attivazione può richiedere MFA, una giustificazione o l’approvazione di approvatori designati; PIM invia notifiche, consente access review e permette di scaricare l’audit history. Richiede licenze. Il punto d’esame: PIM non crea permessi nuovi, cambia quando quelli esistenti sono attivi.

Ultima coppia, la più insidiosa. App registrations elenca gli application object: la definizione dell’applicazione, che vive nel tenant dove è stata registrata e fa da template per creare i service principal. Enterprise applications elenca i service principal presenti nel tenant, cioè le istanze locali, con i permessi, i consensi concessi e da chi sono stati concessi, le assegnazioni di utenti e gruppi e l’attività di accesso. In sintesi: l’application object è la rappresentazione globale, il service principal quella locale. Per cambiare come l’app è definita si va in App registrations; per vedere o revocare che cosa può fare nel tuo tenant si va in Enterprise applications.