Come leggere un tenant ereditato

Prendere in carico un tenant Microsoft 365 configurato da qualcun altro è una delle situazioni più frequenti nel nostro lavoro. È anche una delle più rischiose se non si sa dove guardare. Il problema non è la tecnologia — è che non sapete quello che non sapete: quali policy esistono, chi ha accesso a cosa, cosa è stato configurato frettolosamente e perché. Questa guida descrive il processo che usiamo per costruire una mappa affidabile di un ambiente che non abbiamo configurato noi.

Perché i tenant ereditati sono sempre complicati

Un tenant Microsoft 365 accumulato nel tempo senza governance riflette ogni decisione presa in situazioni di urgenza: l'account creato di fretta per il consulente esterno e mai rimosso, la policy di Conditional Access lasciata in Report-only dopo il test iniziale, il Global Administrator aggiunto durante un'emergenza e mai degradato. Ogni shortcut ha lasciato una traccia.

Il problema principale non è trovare i problemi — è sapere che esistono. Un tenant mal configurato funziona. Le email arrivano, Teams funziona, SharePoint è accessibile. La configurazione sbagliata non si manifesta finché non si manifesta: un account compromesso, un dato esposto, un accesso non autorizzato che nessuno ha visto perché i log non erano configurati.

I primi 15 minuti: cosa controllare subito

Quando prendiamo in carico un tenant nuovo, le prime azioni non sono tecniche — sono organizzative. Dobbiamo capire cosa abbiamo davanti prima di toccare qualsiasi configurazione.

Chiedere le domande giuste al cliente

• Chi era il precedente amministratore? Ha ancora accesso?
• Esiste una documentazione? Dove?
• Ci sono stati incidenti di sicurezza o anomalie negli ultimi mesi?
• Quali integrazioni di terze parti esistono? (CRM, gestionale, firma digitale, backup)
• Ci sono utenti o account speciali di cui dobbiamo sapere?

Le risposte a queste domande determinano l'ordine dei controlli successivi. Se il precedente amministratore ha lasciato in cattivi rapporti, la revoca degli accessi diventa la prima azione — non l'ultima.

Accesso all'interfaccia di amministrazione

Verificare di avere accesso a admin.microsoft.com con un account Global Administrator. Se possibile, non usare l'account del precedente amministratore — creare subito un account dedicato.

La lista rossa: i segnali di allarme immediati

Alcuni segnali richiedono azione immediata — prima di qualsiasi analisi approfondita.

• Account di ex-dipendenti abilitati con licenza attiva: potenziale vettore di attacco, richiede disabilitazione immediata dell'accesso
• Account Global Administrator che non appartengono a persone identificabili: admin@azienda.it senza owner noto, account di consulenti non più attivi
• Nessun MFA su nessun account: il rischio di compromissione delle credenziali è immediato e concreto
• Security Defaults disabilitati senza Conditional Access attivo: il tenant è completamente privo di protezione baseline
• Log di accesso che mostrano accessi da Paesi inattesi: da verificare nel Sign-in log di Entra ID, sezione Rilevamenti di rischio
• Connettori email o regole di inoltro non documentati: possibile esfiltrazione di dati in corso

Mappare gli account amministrativi

Il primo report da estrarre in un tenant nuovo è la lista completa degli account con ruoli amministrativi. In Entra ID la gerarchia dei privilegi è complessa — ci sono decine di ruoli, ognuno con permessi diversi.

Connect-MgGraph -Scopes "RoleManagement.Read.All","User.Read.All"

# Tutti i ruoli con i loro membri
Get-MgDirectoryRole | ForEach-Object {
    $ruolo = $_.DisplayName
    Get-MgDirectoryRoleMember -DirectoryRoleId $_.Id |
    ForEach-Object {
        [PSCustomObject]@{
            Ruolo   = $ruolo
            Utente  = $_.AdditionalProperties.userPrincipalName
            Display = $_.AdditionalProperties.displayName
        }
    }
} | Sort-Object Ruolo,Utente | Export-Csv admin-report.csv -NoTypeInformation

Una volta estratto il report, per ogni account amministrativo verifichiamo:

• L'account appartiene a una persona reale ancora in azienda?
• Il ruolo assegnato è quello minimo necessario per le sue funzioni?
• L'account ha MFA abilitato?
• L'account è un account dedicato all'amministrazione o viene usato anche per la posta quotidiana?

Quest'ultimo punto è importante: gli account Global Administrator non dovrebbero essere usati per la posta quotidiana. L'esposizione di un account admin al phishing quotidiano è un rischio non necessario — gli amministratori dovrebbero avere un account separato per le attività di amministrazione.

Dove si nasconde la configurazione legacy

Microsoft 365 ha accumulato anni di funzionalità e interfacce. Alcune configurazioni sono nascoste in portali amministrativi ormai quasi dimenticati. Queste sono le aree dove troviamo più frequentemente configurazioni problematiche:

Classic Exchange Admin Center

Il vecchio EAC (outlook.office365.com/ecp) è ancora accessibile e alcune configurazioni di Exchange Online — in particolare i connettori e le regole di trasporto — sono lì o nel nuovo EAC. Cercare regole di inoltro automatico verso domini esterni: un segnale classico di account compromesso o esfiltrazione dati.

Connect-ExchangeOnline

# Tutte le regole di inoltro attive sulle mailbox
Get-Mailbox -ResultSize Unlimited |
Where-Object { $_.ForwardingSmtpAddress -ne $null -or $_.ForwardingAddress -ne $null } |
Select-Object DisplayName, UserPrincipalName, ForwardingSmtpAddress, ForwardingAddress

Azure AD Connect / Entra Connect

Se il tenant è in configurazione ibrida (Active Directory on-premise sincronizzato con Entra ID), verificare lo stato e la versione di Azure AD Connect o Entra Connect. Versioni vecchie non ricevono aggiornamenti di sicurezza e la sincronizzazione può essere vettore di problemi dall'on-premise al cloud.

App registrations e Service Principals

In Entra ID → App registrations si trovano le applicazioni di terze parti registrate nel tenant. Ogni app ha permessi definiti — alcune potrebbero avere permessi eccessivi (es. accesso in lettura a tutte le mailbox) concessi in passato senza revisione.

Il piano di remediation: da dove iniziare

Dopo la fase di assessment, si ha un quadro delle criticità. Il piano di remediation deve essere prioritizzato per rischio, non per facilità di esecuzione.

La sequenza che seguiamo:

• Priorità 1 — Sicurezza immediata: disabilitare gli account non autorizzati, revocare gli accessi degli amministratori non più necessari, abilitare MFA sugli account admin, creare il break-glass account
• Priorità 2 — Visibilità: attivare i log di audit (Purview → Ricerca log di controllo), configurare gli alert base in Defender for Cloud Apps o Microsoft Sentinel
• Priorità 3 — Policy baseline: attivare le policy di Conditional Access di base (MFA per tutti, blocco legacy auth)
• Priorità 4 — Pulizia: rimuovere le licenze orfane, eliminare le app registrations non necessarie, aggiornare i connettori legacy
• Priorità 5 — Documentazione: documentare tutto quello che è stato trovato e tutto quello che è stato fatto

L'errore più comune è iniziare dalla priorità 4 perché è la più facile. Rimuovere licenze orfane è operativamente semplice — ma se mentre fate pulizia un account compromesso esfiltrava dati e non avevate i log attivi, non lo saprete mai.