Cosa verifica davvero un audit ibrido AD/Entra e perché molti team falliscono al primo tentativo

Chiedi ad alcuni team IT come gestiscono l’offboarding e sentirai sempre la stessa risposta: disabilitare l’account in Active Directory, chiudere il ticket e passare oltre.

Poi un revisore estrae l'inventario di Entra ID e scopre che l'account è ancora abilitato e assegnato allo stesso ruolo applicativo del primo giorno. La sincronizzazione non ha recepito la modifica, non è scattato alcun avviso perché non ne era stato configurato nessuno ed entrambe le directory indicavano che l'account era integro. Semplicemente, non concordavano sul suo stato.

Sento spesso dire cose simili da team convinti di avere sotto controllo la gestione delle identità, almeno fino al loro primo audit ibrido.

«Abbiamo sotto controllo l'igiene di AD» non equivale a dire «supereremo un audit ibrido»

La maggior parte dei team dispone di una qualche procedura di pulizia di AD: revisioni trimestrali degli account inattivi, audit dei gruppi con privilegi e verifiche dei criteri per le password. È un processo concreto e, in genere, funziona… per Active Directory.

La maggior parte delle raccomandazioni pubblicate sulla sicurezza di AD mira a rafforzarlo contro gli attacchi tramite l’applicazione di patch, la suddivisione degli account amministrativi in livelli e la chiusura dei percorsi di delega. Sono tutte misure utili, ma non rispondono alla domanda che interessa davvero a un auditor. L’obiettivo non è verificare se la directory resisterebbe a un attacco, bensì se i dati relativi alle identità possano costituire prove attendibili quando vengono esaminati a posteriori.

Il problema è l'ambito. Quel processo è quasi sempre limitato all'AD locale, perché è lì che risiedono gli strumenti, le responsabilità e le prassi consolidate dell'organizzazione. Gli auditor, però, definiscono diversamente l'ambito delle verifiche: valutano l'identità così come esiste e opera ovunque possa essere utilizzata. In un ambiente Microsoft ibrido, ciò include anche il lato sincronizzato di Entra ID.

È questa la differenza tra ciò che i team di sicurezza presumono venga controllato e ciò che un auditor verifica effettivamente:

• Ciò che i team presumono venga controllato: igiene degli account AD, conformità alle policy sulle password e appartenenza ai gruppi AD con privilegi.
• Cosa verificano concretamente gli auditor: tutto questo, oltre allo stato e al ritardo della sincronizzazione, alle discrepanze nelle autorizzazioni tra le due directory, alla cronologia delle modifiche della configurazione di sincronizzazione e a qualsiasi privilegio presente in Entra che non abbia un equivalente on-premises con cui confrontarlo. Anche i framework lo confermano: sia i criteri di accesso logico SOC 2 (CC6.1–CC6.3) sia i controlli degli accessi di ISO 27001:2022 (A.5.15, A.5.18 e A.8.2 sugli accessi privilegiati) richiedono che gli accessi vengano esaminati per come sono effettivamente, non per come vengono rappresentati da un singolo sistema. È proprio questo il punto cieco di una visione limitata ad AD che la maggior parte dei team si porta dietro in una verifica di un ambiente ibrido.

I team superano la parte dell’elenco relativa ad AD, ma restano sorpresi da quella relativa a Entra perché applicano un processo di igiene dell’era AD a un ambiente dell’era ibrida, non perché siano negligenti.

Le cinque cose che un auditor richiede nella prima settimana

1. Ritardi e divergenze nella sincronizzazione: L’account è disabilitato in AD, ma mantiene privilegi in Entra perché la sincronizzazione non è stata eseguita, è stata completata solo in parte oppure esclude silenziosamente un ambito che non era mai stata configurata per coprire. Gli auditor chiedono un confronto delle differenze, non un’istantanea, e la maggior parte dei team non ne ha mai generato uno. Nessun fornitore o analista pubblica un tasso aggregato sulla frequenza di questi casi, perché nessuno misura il divario che vi viene chiesto di colmare. Il confronto delle differenze è l’unico modo per capire qual è la vostra situazione.
2. Una cronologia delle modifiche alla configurazione di sincronizzazione: Devi sapere chi ha modificato l'ambito della sincronizzazione o le regole di filtro e quando. È importante perché, negli incidenti reali, rappresenta un punto di svolta documentato, non una semplice casella da spuntare per l'audit. Nel resoconto di Microsoft dell'agosto 2025 sul gruppo ransomware Storm-0501 viene descritto esattamente questo scenario: gli autori dell'attacco hanno compromesso un server Entra Connect Sync non monitorato, estratto le credenziali dell'account di sincronizzazione della directory e quindi reimpostato la password locale dell'utente preso di mira. Entra Connect Sync ha poi propagato correttamente e legittimamente la nuova password all'identità cloud, consegnando agli aggressori un account Global Administrator sincronizzato che non era mai stato registrato per l'MFA. Il meccanismo di sincronizzazione ha fatto esattamente ciò per cui era stato progettato, ma per conto di un aggressore che aveva individuato l'unico server che nessuno monitorava. Se la configurazione di sincronizzazione e le relative credenziali amministrative non dispongono di un registro delle modifiche, non puoi escludere questo scenario, e nemmeno un revisore può farlo. Non si tratta neppure di un caso isolato: l'avviso congiunto di CISA/FBI/RCMP/ASD/NCSC-UK sul gruppo Scattered Spider documenta la stessa tecnica di fondo presso più vittime: la reimpostazione delle credenziali o dell'MFA tramite l'help desk, usata per passare a ruoli cloud privilegiati attraverso il percorso di sincronizzazione ibrida.
3. Privilegi esclusivamente cloud senza equivalenti on-premise: I ruoli o le appartenenze a gruppi assegnati direttamente in Entra, senza mai passare da AD, sono invisibili a qualsiasi processo di revisione ancora incentrato su AD. È tanto facile crearli per errore quanto dimenticarsene completamente.
4. I privilegi dell’account di sincronizzazione/servizio: L’account che esegue il processo Connect Sync o Cloud Sync dispone spesso di privilegi permanenti superiori a quelli di qualsiasi account umano nell’ambiente ed è solitamente quello meno esaminato durante una revisione ordinaria di AD, perché non sembra un «utente».
5. Una traccia probatoria che copra entrambi i lati, non solo lo stato attuale: Gli auditor vogliono sapere chi ha modificato cosa e quando, in entrambe le directory. La maggior parte dei team riesce a produrre un report chiaro sullo stato attuale, ma sono molti meno quelli in grado di crearne uno che copra davvero il confine tra AD ed Entra.

Chi è responsabile della lacuna?

AD è solitamente gestito da un team dedicato all'infrastruttura o alle identità, mentre Entra è gestito da un team cloud o M365. Il problema è questa separazione delle responsabilità, non una carenza degli strumenti. Di conseguenza, anche la preparazione agli audit risente di tale divisione: ogni team può presentare un report senza criticità, ma limitato alla propria area.

Anziché colmare questa lacuna, gli strumenti nativi la accentuano. Il Centro di amministrazione di Active Directory offre una visione chiara di AD, mentre l'interfaccia di amministrazione di Entra mostra chiaramente Entra. Nessuno dei due mostra cosa accade tra i due ambienti, perché nessuno dei due ne è responsabile.

L'audit fallisce perché la directory è divisa in due e nessuno si occupa di ciò che resta nel mezzo, non perché la directory sia sporca.

Cosa controllare questa settimana

Non devi aspettare una notifica di audit per sapere a che punto sei. Prima della prossima verifica:

1. Recupera i log degli errori di sincronizzazione: non solo il riepilogo di successi e fallimenti, ma verifica anche se qualche processo presenta errori parziali o silenziosi nascosti nel suo stato di «successo».
2. Confronta le appartenenze ai gruppi con privilegi tra AD ed Entra direttamente, anziché esaminare separatamente ciascun ambiente.
3. Fai l'inventario dei privilegi degli account di sincronizzazione e di servizio come faresti per un account amministratore umano.
4. Verificare la conservazione della cronologia delle modifiche esistente e confrontabile su entrambi i lati, non solo per lo stato attuale, ma anche per la cronologia.
5. Verifica la presenza di assegnazioni di ruoli esclusivamente nel cloud che non hanno un equivalente in AD con cui effettuare il confronto.

Nessuna di queste attività richiede nuovi strumenti per iniziare, ma serve qualcuno che esegua il confronto tra entrambe le directory anziché esaminarle separatamente.

Cosa significa per te

Un audit ibrido di AD/Entra verifica aspetti sostanzialmente diversi rispetto a un audit di AD, quindi non è semplicemente una versione più complessa della stessa attività. La maggior parte dei team si presenta ancora con una checklist dedicata esclusivamente ad AD, ed è per questo che il primo audit tende a far emergere criticità che nessuno aveva previsto.

Netwrix Directory Manager non segnala automaticamente questa lacuna nella sincronizzazione, ma può aiutarti a svolgere gran parte delle attività di riconciliazione manuale descritte sopra, evitando di dover ricostruire tutto a mano. Offre un unico punto da cui visualizzare il ciclo di vita dei gruppi, i relativi proprietari e le attività amministrative in AD, Entra ID e Google Workspace, oltre a un audit trail integrato delle azioni degli amministratori. In questo modo, parti avvantaggiato nella raccolta delle evidenze che un auditor richiederà.