Perché il monitoraggio dell’identità

In Microsoft Entra ID il monitoraggio è la base per investigazioni di sicurezza, audit di conformità e troubleshooting degli accessi. L’amministratore delle identità deve sapere quale log risponde a quale domanda, come filtrarlo e — soprattutto — come conservarlo oltre la retention nativa. I dati vivono nella sezione Monitoring del portale (Audit logs, Sign-in logs, Provisioning logs) e sono esportabili altrove tramite i diagnostic settings.

Audit log: chi ha fatto cosa

L’audit log registra le modifiche al tenant: creazione utenti, reset password, assegnazione ruoli, cambi di membership di gruppo, aggiornamenti alle app registrations e alle policy. Ogni voce risponde alla domanda “chi ha fatto cosa, quando e con quale esito”. I campi chiave per l’investigazione sono:

  • Category e Activity (es. “Add member to role”)
  • Initiated by (actor: utente o service principal)
  • Target(s) (l’oggetto modificato)
  • Status (success/failure) e Date/time

È lo strumento giusto quando devi capire chi ha modificato una configurazione, non chi ha effettuato un accesso.

Sign-in log: chi ha effettuato l’accesso

Il sign-in log traccia i tentativi di autenticazione. Attenzione: esistono quattro tipi di sign-in distinti, ciascuno in una scheda separata, ed è un tema d’esame ricorrente:

  • Interactive: l’utente si autentica attivamente (inserisce credenziali, MFA).
  • Non-interactive: sign-in effettuati per conto dell’utente da un client (token refresh, accessi silenziosi). Sono ad alto volume.
  • Service principal: applicazioni/service principal che si autenticano con proprio secret o certificato, senza utente.
  • Managed identity: risorse Azure che accedono a Entra ID senza credenziali gestite manualmente.

Per l’investigazione filtra su User, Application, Status, Conditional Access (quali policy hanno agito), IP address, Location e soprattutto il failure reason con il relativo sign-in error code, utile per distinguere una password errata da un blocco Conditional Access o da un MFA fallito.

Diagnostic settings: esportare i log

Questo è il punto architetturale centrale. Dal portale, in Diagnostic settings, scegli quali log-stream inviare (AuditLogs, SignInLogs, NonInteractiveUserSignInLogs, ServicePrincipalSignInLogs, ManagedIdentitySignInLogs, RiskyUsers, ecc.) verso tre destinazioni, da selezionare in base allo scenario:

  • Log Analytics workspace → quando serve query KQL, alerting, correlazione con Microsoft Sentinel e uso dei workbook. È la scelta per analisi e indagine.
  • Storage account → quando l’obiettivo è archiviazione a basso costo e long-term retention per compliance (es. conservazione pluriennale).
  • Event Hub → quando devi fare streaming dei log verso un SIEM di terze parti (Splunk, QRadar) o pipeline esterne.

Le tre destinazioni non si escludono: puoi attivarle insieme (es. Log Analytics per l’analisi + Storage per l’archivio).

Workbook e report di Identity Protection

I workbook (basati su Log Analytics) forniscono dashboard preconfezionate — Sign-ins, Conditional Access insights, Sensitive operations — per visualizzare i dati esportati senza scrivere KQL da zero. Microsoft Entra ID Protection (P2) aggiunge i report Risky users, Risky sign-ins e Risk detections: anche questi flussi si esportano via diagnostic settings, così un rilevamento di rischio può generare un alert in Sentinel o essere conservato oltre la finestra nativa.

La retention nativa è limitata

Punto cruciale: la conservazione dentro Entra ID è breve. Con licenze P1/P2 i log (audit e sign-in) restano 30 giorni; con licenza gratuita solo 7 giorni (e il sign-in log richiede almeno P1). Superata la finestra, i dati vengono cancellati automaticamente. Quindi per audit, forensics o compliance che richiedono mesi o anni devi esportare con un diagnostic setting prima che i dati scadano: attivarlo dopo un incidente non recupera lo storico perduto.

Trappole tipiche d’esame

  • “Serve conoscere quale amministratore ha modificato un ruolo” → Audit log, non il sign-in log (che copre solo autenticazioni).
  • “Conservare i sign-in log per 1 anno / analizzarli con KQL e alert” → Diagnostic setting verso Log Analytics (analisi) o Storage account (archivio economico); la retention nativa di 30 giorni non basta.
  • “Investigare accessi di un’applicazione senza utente / di una risorsa Azure” → scheda Service principal sign-ins / Managed identity sign-ins, non Interactive.
  • “Inviare i log a Splunk/QRadar in tempo reale” → destinazione Event Hub, non Storage né Log Analytics.
  • “Vedere perché un utente è stato bloccato all’accesso” → Sign-in log, colonna Conditional Access + failure reason/error code; i report di rischio stanno in Entra ID Protection (P2).