Logging Entra ID: Retention, Diagnostic Settings, SIEM Esportazione

Logging Entra ID, retention, diagnostic settings, esportazione SIEM: cosa manca

Logging Entra ID, retention, diagnostic settings, esportazione SIEM — tre controlli distinti, e per default nessuno dei tre fa ciò che la maggior parte dei team presume. I log di accesso e audit scadono in giorni, non in mesi. Nulla viene instradato da nessuna parte senza un diagnostic setting esplicito. E finché nessuno ha collegato un event hub o un workspace Log Analytics, Microsoft Sentinel o un SIEM di terze parti non vede mai un singolo evento Entra ID.

Questa è una lacuna di configurazione, non una tecnica di attacco — ma è una delle lacune a più alto impatto dell'intero catalogo Azure, perché decide se ogni altra rilevazione di questo blog è effettivamente utilizzabile. Una policy di accesso condizionale che blocca l'autenticazione legacy non serve a nulla per l'indagine a posteriori se l'accesso che l'ha scatenata è già scaduto dal log. Una rilevazione di rischio di identity protection non significa nulla per un SOC che non ha alcun canale che la alimenti verso il proprio SIEM.

Quattro risultati correlati compongono questo cluster:

• AZ_AUDIT_LOG_RETENTION_SHORT — i log di audit vengono conservati per meno tempo di quanto la licenza del tenant consenta (o di quanto richieda una finestra di incident response).
• AZ_SIGN_IN_LOGS_NOT_RETAINED — i log di accesso sono sulla finestra predefinita del livello gratuito e scompaiono prima che inizino la maggior parte delle cronologie di rilevazione delle violazioni.
• AZ_DIAGNOSTIC_SETTINGS_MISSING — non esiste alcun diagnostic setting per instradare i log da qualche parte, quindi la finestra di retention predefinita è l'unica retention esistente.
• AZ_NO_SIEM_EXPORT — i log possono raggiungere un workspace Log Analytics ma non ne escono mai verso un SIEM monitorato, quindi nessuno riceve alert.

Come nascono davvero queste lacune

La retention è un tetto di licenza, non un'impostazione da configurare

Secondo la documentazione Microsoft sulla retention dei dati di Microsoft Entra, la finestra di retention integrata per i log di audit e accesso è:

Due dettagli peggiorano la situazione:

1. Le modifiche alla retention non sono retroattive. La documentazione Microsoft lo afferma direttamente: passando da Free a P1/P2, si recupera solo ciò che si trova ancora nella finestra gratuita di 7 giorni — i dati già scaduti sono persi, a meno che non fossero stati archiviati in precedenza.
2. I log di attività di Microsoft Graph non sono affatto disponibili su Entra ID Free, e non vengono conservati per default nemmeno su P1/P2 — la tabella di retention di Microsoft li elenca come richiedenti integrazione con storage o strumenti analitici fin dal primo giorno; non esiste una finestra predefinita di ripiego come per i log di audit e accesso.

Se un incidente viene scoperto nove giorni dopo i fatti — una tempistica molto comune per una compromissione basata su credenziali — un tenant P1/P2 senza esportazione configurata ha già perso le prove di accesso per i primi due giorni dell'intrusione, e un tenant Free ha perso quasi tutto.

I diagnostic settings sono opt-in, per categoria di log, per destinazione

Instradare i log fuori dalla finestra di retention predefinita di Entra ID richiede un diagnostic setting, configurato in Centro amministrativo Entra → Monitoring & health → Diagnostic settings da un utente con il ruolo Security Administrator (Come configurare i diagnostic settings di Microsoft Entra). Non è automatico, e non copre "tutto" a meno che ogni categoria di log rilevante non venga selezionata esplicitamente.

Microsoft documenta le categorie di log trasmissibili, ciascuna da selezionare individualmente (Log disponibili per lo streaming da Microsoft Entra ID) — quelle rilevanti per la sicurezza includono:

AuditLogs                          SignInLogs
NonInteractiveUserSignInLogs       ServicePrincipalSignInLogs
ManagedIdentitySignInLogs          ProvisioningLogs
ADFSSignInLogs                     RiskyUsers
UserRiskEvents                     RiskyServicePrincipals
ServicePrincipalRiskEvents         RiskyAgents / AgentRiskEvents
NetworkAccessTrafficLogs           MicrosoftGraphActivityLogs
EnrichedOffice365AuditLogs         CustomSecurityAttributeAuditLogs

Un tenant può avere un diagnostic setting che inoltra solo AuditLogs, mentre SignInLogs, RiskyUsers e UserRiskEvents — le categorie che effettivamente contengono la telemetria di autenticazione e rischio — restano non instradate e soggette al tetto di 7/30 giorni sopra descritto. È uno stato semi-configurato molto comune: qualcuno ha attivato il logging una volta per una spunta di compliance, ha scelto una o due categorie, e non ci è più tornato. La stessa lacuna compromette direttamente le indagini sull'attività dei ruoli privilegiati tracciata tramite Azure PIM — una cronologia di attivazione è durevole solo quanto il log di audit in cui è scritta.

La destinazione stessa deve già esistere prima che il diagnostic setting possa puntarvi: un workspace Log Analytics, un event hub, o un account di storage. I log possono impiegare fino a tre giorni per apparire dopo il salvataggio di un setting, un dettaglio rilevante quando si convalida una correzione.

Un workspace Log Analytics non è un SIEM

Qui è dove AZ_NO_SIEM_EXPORT diverge da AZ_DIAGNOSTIC_SETTINGS_MISSING: un tenant può avere diagnostic settings completamente configurati, che riversano ogni categoria in un workspace Log Analytics, e avere comunque copertura di rilevazione pari a zero — perché nessuno esegue regole analitiche su quel workspace, o perché il workspace non è mai stato collegato a Microsoft Sentinel né esportato verso un SIEM di terze parti (Splunk, Elastic, QRadar) via event hub.

La stessa documentazione di integrazione Microsoft nota che collegare i log Entra ai log di Azure Monitor attiva automaticamente il connettore dati Microsoft Entra all'interno di Microsoft Sentinel (Integrare i log Microsoft Entra con i log di Azure Monitor) — ma solo se Sentinel è distribuito su quello stesso workspace in primo luogo. Un workspace senza Sentinel (o un'ingestione SIEM equivalente) sopra è un archivio di sola scrittura: i dati vengono conservati, ma nessuno, e niente, li guarda.

Rilevazione

Verifica ciascuna delle quattro lacune in modo indipendente — un tenant ha spesso corretto alcune ma non tutte.

1. Conferma cosa è effettivamente configurato, non ciò che presumi sia configurato. Nel centro amministrativo Entra, vai su Monitoring & health → Diagnostic settings e controlla ogni setting esistente: quali categorie di log sono selezionate, e verso quale destinazione puntano. Se l'elenco è vuoto, AZ_DIAGNOSTIC_SETTINGS_MISSING si applica immediatamente — il tenant funziona solo con la retention predefinita.

2. Verifica il tetto di retention imposto dalla licenza rispetto ai tuoi effettivi requisiti di incident response. Una finestra di 7 giorni su Entra ID Free, o persino la finestra di 30 giorni su P1/P2, è breve rispetto alle statistiche tipiche di dwell time per le intrusioni basate sull'identità — se nulla la estende, segnala AZ_AUDIT_LOG_RETENTION_SHORT / AZ_SIGN_IN_LOGS_NOT_RETAINED.

3. Verifica che i dati arrivino effettivamente in Log Analytics, non solo che un setting esista. In Sentinel o in un workspace collegato, esegui:

SigninLogs
| summarize LastEvent = max(TimeGenerated), Count = count()

AuditLogs
| summarize LastEvent = max(TimeGenerated), Count = count()

Nota che i nomi delle tabelle usano SigninLogs ("i" minuscola) in Log Analytics, diverso dal nome della categoria del diagnostic setting SignInLogs — una fonte comune di confusione sul "perché la mia query è vuota". Se LastEvent è obsoleto o la tabella non esiste, il diagnostic setting non è salvato, non include quella categoria, oppure punta a un workspace diverso da quello che stai interrogando.

4. Conferma il lato SIEM, non solo il canale. Se Microsoft Sentinel è la destinazione, verifica che Data connectors → Microsoft Entra ID mostri "connesso", con SignInLogs e AuditLogs entrambi attivati — è un interruttore separato dal diagnostic setting lato Entra, ed entrambi devono puntare allo stesso workspace. Per un SIEM di terze parti, conferma che l'event hub abbia effettivamente un consumer group attivo che lo legge, non solo che il diagnostic setting elenchi un event hub come destinazione.

5. Per la raccolta di evidenze programmatica, l'SDK Microsoft Graph PowerShell espone direttamente i dati sottostanti, indipendentemente da qualsiasi pipeline SIEM, il che è utile per confermare cosa Entra ID conserva attualmente:

# Conferma fino a quando risalgono attualmente i dati di accesso
Get-MgAuditLogSignIn -Top 1 -Sort "createdDateTime asc"

# Stessa verifica per gli eventi di audit della directory
Get-MgAuditLogDirectoryAudit -Top 1 -Sort "activityDateTime asc"

Remediation

1. Prepara prima la destinazione. Crea (o individua) un workspace Log Analytics, e se serve anche uno storage a freddo a lungo termine, un account di storage separato — i diagnostic settings richiedono che la destinazione esista già prima di potervi puntare.
2. Crea il diagnostic setting con ogni categoria rilevante per la sicurezza selezionata, non solo AuditLogs. Come minimo: AuditLogs, SignInLogs, NonInteractiveUserSignInLogs, ServicePrincipalSignInLogs, RiskyUsers, UserRiskEvents. Aggiungi ADFSSignInLogs e ProvisioningLogs se pertinenti al tuo ambiente.
3. Collega il workspace a Microsoft Sentinel (o al consumer event hub del tuo SIEM) e conferma che il connettore dati Microsoft Entra ID mostri SignInLogs e AuditLogs come connessi — un workspace che riceve dati senza un SIEM che li legga chiude AZ_DIAGNOSTIC_SETTINGS_MISSING ma lascia aperto AZ_NO_SIEM_EXPORT.
4. Estendi la retention oltre il tetto di licenza configurando la policy di retention propria del workspace Log Analytics o dell'account di storage, indipendentemente dalla finestra predefinita di 7/30 giorni di Entra ID — la finestra di retention di Entra ID smette di contare una volta che i dati risiedono in Azure Monitor. Le organizzazioni con licenza Microsoft 365 E5 / Purview Suite possono in alternativa estendere la retention tramite Microsoft Purview Audit (Premium).
5. Riesegui le query di rilevazione sopra dopo aver salvato il setting — concedi fino a tre giorni prima di concludere che non ha funzionato — e conferma che LastEvent in SigninLogs / AuditLogs sia aggiornato, non solo che la query restituisca alcune righe.
6. Documenta chi è responsabile della rivalidazione. I diagnostic settings driftano silenziosamente: una migrazione di workspace, un onboarding di Sentinel che ha dimenticato di ripuntare il connettore, o una licenza Purview scaduta possono interrompere silenziosamente la pipeline senza alcun errore visibile nel centro amministrativo Entra.

Come EtcSec rileva questo problema

EtcSec verifica AZ_AUDIT_LOG_RETENTION_SHORT, AZ_SIGN_IN_LOGS_NOT_RETAINED, AZ_DIAGNOSTIC_SETTINGS_MISSING e AZ_NO_SIEM_EXPORT come parte di ogni audit Azure/Entra ID — confermando non solo che un diagnostic setting esista, ma quali categorie di log inoltri effettivamente e se la destinazione è monitorata dal tuo SOC. Questo è un controllo complementare al quadro più ampio di hardening del tenant trattato in come effettuare l'audit della sicurezza di Microsoft Entra ID e nella baseline di hardening del tenant Azure.