Sincronizzazione Identità Ibrida Entra Cloud-Only Privilegiato Orfano: Il Punto Cieco dell'Audit Ibrido

Sincronizzazione Identità Ibrida Entra Cloud-Only Privilegiato Orfano Spiegati

Sincronizzazione identità ibrida Entra cloud-only privilegiato orfano: i due punti ciechi trattati in questo articolo sono gli account cloud-only titolari di un ruolo Microsoft Entra privilegiato che non entrano mai nel perimetro di governance Tier 0 on-premises, e gli utenti sincronizzati orfani che Entra Connect lascia indietro dopo che il loro account on-premises viene eliminato. Entrambi sfuggono al pipeline di sincronizzazione che mantiene la maggior parte degli oggetti scorrere correttamente tra l'Active Directory on-premises e Microsoft Entra ID, ed entrambi sono punti ciechi di audit specifici degli ambienti ibridi, non dell'uno o dell'altro lato preso singolarmente.

Il primo è l'account cloud-only privilegiato: un utente creato direttamente in Entra ID, mai sincronizzato dall'AD on-premises, e titolare di un ruolo Microsoft Entra attivo o idoneo al PIM. Il secondo è l'utente sincronizzato orfano: un oggetto che Entra Connect ha sincronizzato in passato dall'AD, il cui account sorgente on-premises è stato successivamente eliminato o escluso dall'ambito di sincronizzazione, ma il cui oggetto Entra ID non viene mai rimosso in modo pulito. Nessuno dei due compare negli audit che la maggior parte delle organizzazioni ibride esegue già, perché tali audit sono costruiti attorno a un solo lato del confine di sincronizzazione — una revisione di tiering on-premises analizza l'AD, e persino un ampio audit di sicurezza di Entra ID parte solitamente dal presupposto che ogni identità abbia ancora una controparte on-premises attiva.

Account cloud-only privilegiati: una lacuna deliberata che gli audit on-premises non vedono

Tenere gli account Tier 0 fuori dalla sincronizzazione della directory non è un errore — è una raccomandazione documentata da Microsoft. La guida ufficiale di Microsoft afferma chiaramente che « Gli account amministratore Tier 0 vengono utilizzati solo per gli account AD on-premises. Questi account in genere non vengono sincronizzati con Microsoft Entra ID nel cloud », e separatamente che « Gli account Amministratore globale (e altri gruppi privilegiati) dovrebbero essere account cloud-only senza legami con l'Active Directory on-premises » (Secure access practices for administrators in Microsoft Entra ID).

Il punto cieco non è l'architettura — è la lacuna di governance che si apre attorno ad essa. Una revisione di tiering on-premises (sia un audit manuale rispetto a un modello come il modello di tiering di Active Directory, sia uno strumento come PingCastle che analizza l'AD) non ha alcuna visibilità sulle assegnazioni di ruolo in Entra ID, semplicemente perché un account cloud-only non è mai esistito on-premises. Se il programma di governance lato cloud non è stato costruito con lo stesso rigore — assegnazione idonea PIM invece di accesso permanente, Conditional Access che richieda MFA e un dispositivo conforme all'attivazione, e revisioni periodiche degli accessi — un Amministratore globale cloud-only può ritrovarsi con un'assegnazione attiva permanente, senza applicazione dell'MFA e senza logging di attivazione, invisibile a entrambe le metà del programma di audit contemporaneamente.

Questa lacuna porta con sé una superficie di attacco concreta. SyncJacking è una tecnica di takeover tramite hard-match, confermata dal Microsoft Security Response Center come un problema di privilege escalation di severità Importante, in cui un attaccante che controlla attributi su un oggetto AD on-premises può forzare Entra Connect a fare hard-match di quell'oggetto con un utente cloud-managed esistente — incluso uno privilegiato — e prenderne il controllo della source of authority. La tecnica « non lascia traccia nei log AD on-premises e solo una traccia minima nei log di Entra ID » (Semperis: Syncjacking Could Enable Entra ID Account Takeover).

Microsoft ha da allora rilasciato una mitigazione a livello di piattaforma. Secondo la documentazione di troubleshooting di Microsoft stessa: « A partire dal 1° luglio 2026, Microsoft Entra ID applica automaticamente l'hardening di sicurezza dell'hard match », bloccando un hard match ogni volta che l'account cloud target ha già onPremisesObjectIdentifier impostato, detiene un ruolo Entra privilegiato attivo, o è idoneo per uno (Microsoft Entra Connect: Troubleshoot errors during synchronization — InvalidHardMatch). Questo hardening protegge il percorso di takeover — non fa nulla per chiudere la lacuna di governance che ha permesso in primo luogo l'esistenza di un admin cloud-only non monitorato, che è esattamente ciò a cui puntano le sezioni di rilevamento e remediation di questo articolo. Vale la pena anche abbinare questa revisione lato accesso agli account di accesso di emergenza che ogni tenant mantiene per un vero scenario break-glass — vedi igiene degli account break-glass di Entra ID per come questi dovrebbero (e non dovrebbero) essere delimitati nello specifico.

Utenti sincronizzati orfani: cosa succede quando Entra Connect non rimuove un account on-premises eliminato

Dall'altro lato del confine, eliminare un utente nell'AD on-premises non garantisce che il suo gemello in Entra ID scompaia. Due meccanismi documentati lasciano indietro oggetti sincronizzati:

Protezione dall'eliminazione accidentale. Microsoft Entra Connect viene fornito con la protezione dall'eliminazione attivata per impostazione predefinita, con un limite di 500 eliminazioni di oggetti per ciclo di esportazione. Se una pulizia massiva on-premises, uno spostamento di OU, o un filtro di sincronizzazione rotto causa l'eliminazione di più oggetti della soglia in un'unica esecuzione, l'esportazione semplicemente si ferma — il Synchronization Service Manager riporta stopped-deletion-threshold-exceeded nella fase Export, e ciascuna di quelle eliminazioni resta non applicata in Entra ID finché un amministratore non la rivede e riavvia il job (Microsoft Entra Connect Sync: Prevent accidental deletes). In pratica questo significa che un singolo superamento della soglia passato inosservato può lasciare decine di account on-premises eliminati ancora pienamente attivi e apparentemente sincronizzati nel cloud.

Esclusione dall'ambito senza conversione. Quando un oggetto viene spostato fuori dall'ambito di sincronizzazione (una modifica del filtro OU/gruppo, ad esempio) invece di essere eliminato direttamente, Entra Connect esegue un soft-delete dell'oggetto Entra ID e imposta DirSyncEnabled su False — ma, secondo la documentazione di Microsoft stessa, « questo processo tuttavia non converte l'oggetto in cloud managed, viene ancora considerato un oggetto sincronizzato dall'Active Directory on-premises », e resta idoneo per un nuovo hard match in seguito (Microsoft Entra Connect: Troubleshoot errors during synchronization). Un utente in questo stato non è né eliminato in modo pulito né genuinamente cloud-native — è un oggetto migrato a metà per cui la maggior parte delle revisioni degli accessi non ha una categoria adatta, in uno spirito simile agli account privilegiati obsoleti che gli audit on-premises già segnalano, tranne che questo è invisibile dal lato AD perché l'oggetto sorgente è già scomparso.

Rilevamento: individuare account cloud-only privilegiati e account sincronizzati orfani

La proprietà onPremisesSyncEnabled della risorsa user di Microsoft Graph è l'ancora di entrambi i controlli: restituisce true per un oggetto attivamente sincronizzato, false per un oggetto che era sincronizzato ma non lo è più, e null per un oggetto che non è mai stato sincronizzato — cioè genuinamente cloud-native.

Interrogare Microsoft Graph per i candidati orfani

Per estrarre direttamente l'elenco dei candidati orfani / SOA ripristinata, Microsoft documenta questa query Graph:

GET https://graph.microsoft.com/v1.0/users?$count=true&$filter=OnPremisesSyncEnabled ne true and OnPremisesImmutableId ne null

(Fonte: How to audit and monitor User Source of Authority (SOA) in Microsoft Entra ID.) I filtri avanzati su onPremisesSyncEnabled potrebbero richiedere l'header ConsistencyLevel: eventual e $count=true per restituire risultati in modo affidabile.

Incrociare i ruoli privilegiati con lo stato di sincronizzazione

Per il lato cloud-only privilegiato, incrociate le assegnazioni di ruolo (idonee PIM e attive) con lo stato di sincronizzazione:

# Utenti con un ruolo Entra attivo o idoneo che non sono mai stati sincronizzati dall'on-premises
Get-MgUser -Filter "onPremisesSyncEnabled eq null" -ConsistencyLevel eventual -CountVariable c -All |
    Where-Object { (Get-MgUserMemberOf -UserId $_.Id) -match "RoleAssignable" }

Rimedio

Colmare la lacuna cloud-only privilegiata

1. Estendere la governance Tier 0 agli account cloud-only privilegiati. Ogni account cloud-only con un ruolo Entra attivo o idoneo dovrebbe avere: assegnazione idonea PIM (non permanente), una policy di Conditional Access che richieda MFA e un dispositivo conforme/gestito all'attivazione (molti tenant hanno lacune qui — vedi lacune di copertura della policy base di Conditional Access), e l'inclusione nella stessa revisione periodica degli accessi del Tier 0 on-premises — vedi igiene dei gruppi nidificati e assegnabili a ruolo per l'equivalente lato gruppi di questa stessa lacuna.
2. Mantenere l'eccezione ristretta. Gli unici account che dovrebbero restare completamente fuori dal controllo di PIM e Conditional Access sono i veri account di accesso di emergenza break-glass — due, cloud-only, monitorati, secondo le indicazioni di Microsoft (vedi igiene degli account break-glass). Tutto il resto etichettato come «cloud-only perché il Tier 0 non deve sincronizzarsi» ha comunque bisogno di un owner e di una cadenza di revisione.

Ripulire gli utenti sincronizzati orfani

3. Regolare la protezione dall'eliminazione accidentale invece di alzarla alla cieca. Confermate che la soglia di eliminazione dell'export (Enable-ADSyncExportDeletionThreshold) sia impostata deliberatamente per il vostro ambiente, instradate la notifica di stop verso una casella di posta monitorata, e trattate ogni evento stopped-deletion-threshold-exceeded come un trigger di indagine prima di riprendere l'export — riprendere senza revisione è ciò che trasforma una modifica di configurazione in decine di orfani attivi.
4. Riconciliare lo stato di sincronizzazione obsoleto secondo una pianificazione. Interrogate onPremisesSyncEnabled = false con un onPremisesLastSyncDateTime datato, verificate presso l'AD on-premises se l'oggetto sorgente esiste ancora, e ripristinate il mapping oppure deprovisionate formalmente l'oggetto cloud — non lasciatelo in questo stato migrato a metà.
5. Collegare le eliminazioni a un processo di uscita governato. I Lifecycle Workflows di Microsoft Entra ID Governance possono attivare attività di disattivazione/rimozione accesso/eliminazione pianificata a partire da un segnale autorevole (feed HR o attributo AD) invece di affidarsi esclusivamente all'export di sincronizzazione per propagare un offboarding — questo intercetta il caso in cui l'export fallisce silenziosamente.

Prepararsi all'hardening dell'hard match

6. Pianificare fin da ora l'hardening dell'hard match, non il 1° luglio 2026. Qualsiasi processo che dipenda dal riabbinare un account cloud privilegiato o idoneo PIM a un oggetto on-premises (recupero foresta, runbook di migrazione tenant) verrà bloccato per impostazione predefinita una volta che l'hardening di Microsoft entrerà in vigore. Testate i vostri runbook di ripristino con la soluzione alternativa documentata — rimuovere temporaneamente il ruolo o l'idoneità, completare l'hard match, quindi ripristinarlo — prima di averne bisogno sotto la pressione di un incidente.

Come EtcSec rileva questo problema

I controlli Entra ID di EtcSec segnalano direttamente entrambi i lati di questa lacuna: HYBRID_CLOUD_ONLY_PRIVILEGED fa emergere gli utenti cloud-only titolari di un ruolo privilegiato, e HYBRID_ORPHANED_CLOUD_USER fa emergere gli oggetti il cui stato di sincronizzazione indica un probabile orfano. Questi controlli sono abbinati a UNRESOLVED_PRIVILEGED_MEMBERS (assegnazioni di ruoli privilegiati che referenziano un principal che non si risolve più), PA_ADMIN_STALE_ACCOUNT (account amministrativi senza attività recente), e PA_GLOBAL_ADMIN_NOT_MFA (Amministratori globali senza MFA applicato), così che un account cloud-only privilegiato non venga solo individuato, ma verificato secondo lo stesso standard di igiene degli accessi di qualsiasi altra identità Tier 0.