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.
Se il tenant non ha un break-glass account, createlo prima di fare qualsiasi altra cosa. Un account di emergenza escluso da tutte le policy di Conditional Access, con credenziali documentate fisicamente. Se durante la remediation bloccate accidentalmente tutti gli amministratori (succede), questo è l'unico modo per recuperare l'accesso senza chiamare il supporto Microsoft.
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.
Frequently asked questions
Where do you start auditing an inherited Microsoft 365 tenant?
The audit starts from six areas: 1) Licence inventory (M365 Admin Center → Active users); 2) Admin role review (Entra ID → Roles); 3) Secure Score in Microsoft Defender; 4) MFA and Conditional Access check; 5) Mailflow, DMARC and SPF review; 6) SharePoint and Teams permissions. Document everything before touching any setting.
What do you typically find in a poorly managed inherited tenant?
Recurring patterns are: active accounts of ex-employees with assigned licences, too many Global Admins, disabled MFA, no DMARC on the domain, SharePoint with 'Everyone' permissions, and licences assigned to generic accounts like 'info@' that are never used. Remediation typically takes 2-3 weeks.
Do you need admin access to audit the tenant?
The Global Reader role is sufficient — it lets you view the entire configuration without being able to modify anything. It's the ideal role for an initial audit as it eliminates the risk of accidental changes. Always document the baseline state of the tenant before any intervention.