Mike Masciulli Amministratore delegato, Prodotti e servizi per la migrazione

La migrazione di Active Directory non ha migliorato la sicurezza. In molti contesti, ha addirittura l'effetto opposto.

«Come lo sai?»

È questa la domanda scomoda su cui continuo a tornare quando parlo con le organizzazioni che stanno pianificando fusioni, transizioni al cloud e progetti di modernizzazione.

Troppo spesso le aziende investono milioni in un progetto di migrazione e consolidamento di Active Directory (AD) e lo trattano come un semplice trasferimento di dati: trasferiscono utenti, gruppi e applicazioni in una nuova foresta, dichiarano il progetto concluso con successo e danno per scontato che la parte più difficile sia ormai superata.

Ma se si ripetono gli stessi errori relativi alla delega, al nesting dei gruppi, alle relazioni di fiducia e agli account con privilegi eccessivi, è possibile ricreare gli stessi vettori di attacco in un nuovo ambiente — e talvolta renderli più difficili da individuare. Un passaggio senza intoppi non garantisce necessariamente una situazione di sicurezza ottimale.

Ecco undici rischi comuni che riscontro nelle tipiche migrazioni di Active Directory. Se affrontate la migrazione di Active Directory ponendo la sicurezza al primo posto, potrete ridurre l'esposizione ai rischi ereditati dal sistema precedente, anziché trasferirli al nuovo ambiente.


1. Privilegi amministrativi ereditati

Una migrazione AD può trasformarsi in un veicolo di escalation dei privilegi quando i diritti di amministratore di dominio o di amministratore aziendale ereditati vengono trasferiti nell'ambiente di destinazione senza un'adeguata verifica. Ciò che sembra una semplice continuità è in realtà il trasferimento di vecchi errori amministrativi in un nuovo ambiente che avrebbe dovuto essere progettato secondo le attuali pratiche di sicurezza.

Ho visto casi in cui le migrazioni hanno mantenuto in piedi strutture di privilegio che risalivano a decenni fa. Se i vecchi privilegi sopravvivono, sopravvivono con essi anche i vecchi rischi.


2. Percorsi di attacco storici ricreati

Se si mantengono le scorciatoie relative all'annidamento dei gruppi, alla delega e alla coesistenza senza analizzare le relazioni di privilegio prima del passaggio al nuovo sistema, gli aggressori potranno continuare a sfruttare gli stessi percorsi di movimento laterale di cui disponevano già. La migrazione potrebbe risultare operativamente trasparente, ma dal punto di vista della sicurezza il percorso di attacco rimane lo stesso.

In alcuni casi, la migrazione comporta una conseguenza ancora più pericolosa: la creazione di un ponte tra un ambiente di origine compromesso e quello di destinazione. Ciò che non si riesce a verificare durante la migrazione spesso diventa in seguito un incidente a carico di qualcun altro.


3. Esposizione delle credenziali durante la migrazione

Le finestre di migrazione sono instabili. Le credenziali vengono condivise, vengono aggiunti rapporti di fiducia, la sincronizzazione si espande e i cambiamenti legittimi generano un rumore di fondo tale da nascondere le attività dannose sotto gli occhi di tutti.

Nell'aprile 2026, Microsoft ha modificato l'impostazione predefinita del KDC Kerberos in modo da privilegiare l'AES per gli account privi di impostazioni di crittografia esplicite; tale cambiamento può causare il malfunzionamento degli account di servizio che dipendono dall'RC4 durante la fase di coesistenza, qualora i team non abbiano individuato preventivamente tali dipendenze. Come spiego nel mio post "RC4 e migrazione AD: scopri gli scenari di malfunzionamento nascosti nel tuo dominio di origine", i progetti di migrazione sono particolarmente esposti a questo rischio poiché gli strumenti standard possono trasferire un account senza tener conto delle sue impostazioni di crittografia.

Se a ciò si aggiunge il rischio che gli hacker sfruttino le relazioni di fiducia — o addirittura creino delle «foreste fantasma» per raccogliere credenziali mentre i team sono concentrati sul passaggio al nuovo sistema — diventa chiaro che la finestra di migrazione rappresenta una delle fasi più rischiose nel ciclo di vita delle identità.


4. Abuso della cronologia SID

L'attributo SID-History è utile per garantire la continuità, ma può rivelarsi pericoloso se non gestito correttamente. Alcuni pen tester lo hanno utilizzato mesi dopo la migrazione per accedere a risorse obsolete tramite identità che non avrebbero più dovuto avere alcuna rilevanza.

In pratica, un malintenzionato può attribuire la cronologia dei SID di un account amministrativo a un account con privilegi inferiori e riottenere così l'accesso effettivo all'ambiente di origine. Peggio ancora, questi SID obsoleti spesso permangono per anni perché le organizzazioni non li eliminano mai completamente.


5. Criteri di autorizzazione (ACL) non corretti o eccessivamente permissivi

La traduzione delle liste di controllo degli accessi (ACL) senza verifica è uno dei modi più rapidi per causare una deriva dei permessi. Dati sensibili relativi alle risorse umane o alla contabilità possono diventare accessibili a vasti gruppi di utenti, e spesso le organizzazioni se ne accorgono solo quando un audit fallisce o un utente visualizza dati a cui non avrebbe mai dovuto avere accesso.

In contesti ampi e disordinati, con un numero elevato di gruppi, è facile che si crei una deriva, a meno che non si definisca con chiarezza ciò che deve davvero emergere.


6. Errori degli account di servizio e privilegi nascosti

Le dipendenze relative all'identità dei servizi sono spesso documentate in modo inadeguato, motivo per cui le applicazioni aziendali possono smettere di funzionare giorni dopo una migrazione. Tuttavia, i problemi relativi agli account di servizio non riguardano solo la disponibilità. Spesso mettono in luce password obsolete, diritti eccessivi, dipendenze non documentate e percorsi di autenticazione che nessuno aveva intenzione di mantenere.

Se non si configurano correttamente gli account di servizio, non si aggiornano gli ACL sui servizi e sugli oggetti COM e non si tiene conto delle identità gestite dal sistema, è possibile che, una volta disattivata l'istanza di origine, ci si accorga troppo tardi che alcune applicazioni critiche nell'istanza di destinazione dipendono ancora da essa. A quel punto, la "migrazione completata" si trasforma in un "disagio operativo in corso" e i vecchi privilegi potrebbero essere ancora incorporati nel livello dei servizi.


7. Conflitti di identità e mappature errate

Una logica di abbinamento inadeguata può causare pericolose confusioni di identità. Un esempio semplice è l'associazione dell'amministratore delegato di una società acquisita a una persona con un nome simile nell'ambiente di destinazione. La persona sbagliata potrebbe ereditare un alias, un indirizzo e-mail o delle appartenenze a gruppi errati.

Non si tratta solo di una questione di ordine nelle directory. Una mappatura errata degli oggetti comporta accessi inappropriati, esposizione dei dati e problemi di autenticazione difficili da tracciare, che minano la fiducia nell'intero processo di migrazione.


8. Una coesistenza che amplifica l'impatto delle violazioni

La connettività durante la fase di migrazione può amplificare l'impatto di una violazione. Se l'origine e la destinazione non sono sufficientemente isolate durante la coesistenza, l'infrastruttura di migrazione stessa può diventare il ponte che gli aggressori utilizzano per estendere la compromissione dalla foresta legacy a quella nuova.

La coesistenza è utile dal punto di vista operativo, ma può rivelarsi pericolosa se la si considera affidabile di default. Una foresta ricostruita non è automaticamente una foresta protetta.


9. Lacune in materia di conformità e revisione

Quando i revisori chiedono chi avesse accesso durante la migrazione, perché siano state modificate le autorizzazioni o quando sia stato aggiunto lo SID-History, «non ne siamo sicuri» non è una risposta accettabile.

Se la migrazione non prevede flussi di lavoro verificabili e report chiari, i team di sicurezza non sono in grado di dimostrare di avere il controllo sulle modifiche relative alle identità. Ciò rende particolarmente difficile il dialogo con i revisori, i team legali e le compagnie di assicurazione contro i rischi informatici, che richiedono prove concrete e non semplici supposizioni.


10. Punti ciechi forensi dopo il passaggio al nuovo sistema

La registrazione degli eventi non è facoltativa durante la migrazione. Se, settimane dopo, si verificano attività sospette e i registri risultano incompleti, poco chiari o mancanti, non sarà più possibile ricostruire cosa sia successo e in che modo l'autore dell'attacco sia riuscito a penetrare nel sistema.

Se non si riesce a quantificare con certezza la via di accesso all'attacco, non è possibile dimostrare di averla bloccata. Si tratta di una posizione difficile da sostenere dopo un incidente.


11. Una nuova foresta con vecchie scorciatoie

Questi rischi più generali derivano tutti dallo stesso errore: lasciare inalterati i difetti perché nessuno vuole apportare modifiche in questo momento.

I conti inattivi, i SID orfani e le configurazioni discutibili sopravvivono al trasferimento. Il debito di sicurezza rimane nascosto finché un successivo audit, un'iniziativa cloud o una violazione non lo portano alla luce.

E questa è l'ipotesi più pericolosa di tutte: credere che una foresta ricostruita sia sicura semplicemente perché è nuova. La vera prova di una migrazione AD non sta nel fatto che gli utenti possano accedere il lunedì, ma nel fatto che il nuovo ambiente sia effettivamente più difficile da compromettere rispetto a quello che ha sostituito.


Trasforma la migrazione di Active Directory in una trasformazione della sicurezza

Le migrazioni AD rappresentano alcune delle migliori opportunità che un'organizzazione possa mai avere per ridurre le vie di accesso agli attacchi, eliminare le vulnerabilità dei sistemi legacy e modernizzare la sicurezza delle identità. Tuttavia, ciò avviene solo se la sicurezza viene integrata nel piano di migrazione sin dall'inizio, anziché essere considerata un'operazione di ripulitura da svolgere dopo il passaggio al nuovo sistema.

Se la vostra organizzazione sta pianificando una migrazione di Active Directory, l'integrazione di una fusione o acquisizione, oppure un progetto di modernizzazione della foresta, questo è il momento giusto per decidere se vi limiterete a trasferire l'infrastruttura o se migliorerete in modo sostanziale il vostro livello di sicurezza.

Noi di Semperis consideriamo la migrazione un evento di sicurezza, non un semplice trasferimento "lift-and-shift". Aiutiamo le organizzazioni a ridurre i rischi legati ai sistemi legacy durante il passaggio, invece di riportarli nel nuovo ambiente e doverne pagare le conseguenze in seguito. Scopri di più sui nostri servizi di migrazione di Active Directory.


Scopri di più su come eseguire con successo la migrazione di AD