Azure Tenant Hardening: Security Defaults

Cos'è Azure Tenant Hardening?

Microsoft ora abilita automaticamente i Security Defaults per i nuovi tenant Microsoft 365 e Azure — con un periodo di tolleranza di 24 ore prima dell'applicazione, e solo se il tenant non dispone già di policy di Accesso Condizionale o di MFA legacy per utente. In pratica, molti tenant di produzione operano ancora senza una vera baseline di sicurezza: i Security Defaults vengono disabilitati nel momento in cui un amministratore inizia a costruire un Accesso Condizionale personalizzato e la policy sostitutiva non viene mai completata, i protocolli di autenticazione legacy restano raggiungibili, gli inviti guest sono aperti a qualsiasi utente e nessuna policy di Accesso Condizionale blocca le lacune lasciate indietro.

Il tenant hardening è il processo di revisione e correzione sistematica di queste impostazioni predefinite. Non è un lavoro affascinante, ma è fondamentale: ogni altro controllo di sicurezza di Azure — Accesso Condizionale, PIM, Identity Protection — dipende dalla correttezza della configurazione del tenant.

Questo articolo copre i controlli di configurazione del tenant Azure più critici e come convalidarli e correggerli.

Come Funziona

La configurazione del tenant Azure viene gestita in più posizioni:

• Entra ID > Proprietà — impostazioni a livello di tenant, inclusi i Security Defaults
• Entra ID > Identità Esterne — impostazioni guest e collaborazione B2B
• Entra ID > Metodi di Autenticazione — quali metodi MFA sono consentiti
• Centro Amministrazione Exchange Online — impostazioni di autenticazione legacy per i protocolli email
• Centro Amministrazione Microsoft 365 — impostazioni di sicurezza a livello di servizio

Configurazioni errate in una qualsiasi di queste aree possono creare una superficie di attacco che aggira tutti gli altri controlli. Una policy di Accesso Condizionale configurata perfettamente è irrilevante se l'autenticazione legacy è ancora abilitata a livello di Exchange.

La Catena di Attacco

Sfruttare i Security Defaults Disabilitati

Quando i Security Defaults sono disattivati e nessuna policy di Accesso Condizionale colma il vuoto:

# Password spray contro M365 senza baseline MFA
o365spray --spray -U users.txt -P passwords.txt --domain corp.com

# Bypass dell'autenticazione legacy — l'accesso IMAP ignora l'Accesso Condizionale
curl -u [email protected]:Password1 imaps://outlook.office365.com/INBOX

Sfruttare le Impostazioni B2B Aperte

# Con qualsiasi account membro — invita un'identità esterna controllata dall'attaccante
New-MgInvitation -InvitedUserEmailAddress "[email protected]" `
    -InviteRedirectUrl "https://myapps.microsoft.com" `
    -SendInvitationMessage $false

Checklist di Audit della Configurazione

1. Stato dei Security Defaults

Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgPolicyIdentitySecurityDefaultEnforcementPolicy | Select-Object IsEnabled
# Dovrebbe essere True (se non sono presenti policy CA)

2. Stato dell'Autenticazione Legacy

# Verifica le policy di autenticazione legacy di Exchange Online
Connect-ExchangeOnline
Get-AuthenticationPolicy | Select-Object Name, AllowBasicAuth*
# Tutti i valori AllowBasicAuth* dovrebbero essere False

3. Impostazioni di Invito Guest

# Verifica chi può invitare guest
Get-MgPolicyAuthorizationPolicy | Select-Object AllowInvitesFrom
# Valori validi: none, adminsAndGuestInviters, adminsGuestInvitersAndAllMembers, everyone
# Dovrebbe essere: none o adminsAndGuestInviters

4. Policy dei Metodi di Autenticazione

# Elenca i metodi di autenticazione abilitati
Get-MgPolicyAuthenticationMethodPolicy | Select-Object -ExpandProperty AuthenticationMethodConfigurations |
    Where-Object {$_.State -eq "enabled"} | Select-Object Id, State
# Verifica che SMS non sia l'unico metodo MFA (soggetto a phishing) — preferisci Authenticator App o FIDO2

5. Impostazioni di Accesso Cross-Tenant

# Verifica se la collaborazione B2B in ingresso è aperta a tutte le organizzazioni esterne
Get-MgPolicyCrossTenantAccessPolicyDefault | Select-Object -ExpandProperty B2BCollaborationInbound |
    Select-Object -ExpandProperty UsersAndGroups
# AccessType non dovrebbe essere "allowed" per il target "AllUsers" senza restrizioni aggiuntive

Rilevamento

Microsoft 365 Secure Score

Microsoft 365 Secure Score fornisce una valutazione automatizzata della configurazione del tenant rispetto alla baseline consigliata da Microsoft. Puoi consultarlo su security.microsoft.com > Secure Score.

Microsoft limita ogni azione consigliata a un massimo di 10 punti, e ne valuta molte come percentuale della configurazione del tuo tenant piuttosto che come valore fisso — non esiste un valore in punti universale e fisso per ogni azione. Esempi concreti tratti dalla guida di scoring di Microsoft: richiedere l'MFA per i ruoli amministrativi vale 10 punti, garantire che tutti gli utenti possano completare l'MFA vale 9 punti, e bloccare l'autenticazione legacy tramite Accesso Condizionale vale 7 punti. Anche limitare gli inviti guest e abilitare il Privileged Identity Management aumentano il punteggio — consulta l'elenco di raccomandazioni di Secure Score per i valori esatti nel tuo tenant.

Log di Audit di Entra ID

// Rileva la disabilitazione dei Security Defaults
AuditLogs
| where OperationName == "Update security defaults"
| mv-expand props = TargetResources.modifiedProperties
| where tostring(props.newValue) has "false"

Rimedio

Abilitare i Security Defaults (Se Non è Presente l'Accesso Condizionale)

Entra ID > Proprieta > Gestisci Security Defaults > Abilitato = Si

Disabilitare l'Autenticazione Legacy a Livello Globale

# Crea una policy di autenticazione che blocca tutta l'autenticazione di base
New-AuthenticationPolicy -Name "Blocca Basic Auth"
Set-AuthenticationPolicy -Identity "Blocca Basic Auth" `
    -AllowBasicAuthImap $false -AllowBasicAuthPop $false `
    -AllowBasicAuthSmtp $false -AllowBasicAuthWebServices $false `
    -AllowBasicAuthRpc $false -AllowBasicAuthMapi $false

# Applica a tutti gli utenti
Get-User -ResultSize Unlimited | Set-User -AuthenticationPolicy "Blocca Basic Auth"

Limitare gli Inviti Guest

Entra ID > Identita Esterne > Impostazioni di collaborazione esterna:
Impostazioni di invito guest = "Solo gli utenti con ruoli di amministratore specifici possono invitare"

Abilitare Metodi MFA Resistenti al Phishing

Entra ID > Metodi di autenticazione > Chiavi di sicurezza FIDO2 = Abilitato (per tutti o solo per gli admin)
Entra ID > Metodi di autenticazione > Microsoft Authenticator = Abilitato
Entra ID > Metodi di autenticazione > SMS = Disabilitato (soggetto a phishing, sostituire con Authenticator)

Come EtcSec Rileva Questo

EtcSec controlla la configurazione completa del tuo tenant Azure a ogni scansione, verificando ogni impostazione che influisce sulla baseline di sicurezza.

AZ_SECURITY_DEFAULTS_DISABLED segnala i tenant in cui i Security Defaults sono disabilitati — una lacuna fondamentale della baseline che elimina protezioni a livello di tenant come l'applicazione base dell'MFA.

CA_NO_LEGACY_AUTH_BLOCK segnala l'assenza di una policy di Accesso Condizionale che blocchi i protocolli di autenticazione legacy, lasciando aperto un bypass dell'MFA per qualsiasi attaccante in possesso di una password rubata.

GUEST_INVITATION_UNRESTRICTED segnala i tenant in cui la policy di invito guest consente a qualsiasi utente di invitare guest esterni, invece di limitare gli inviti agli admin o a ruoli specifici.

Priorità di Revisione

Azure Tenant Hardening: Correggere le Impostazioni Predefinite Non Sicure va trattato come una reale esposizione all'interno del tuo tenant Entra ID e Azure, non come un'impostazione isolata. Inizia definendo il perimetro della revisione: quali admin, guest, service principal, app registration, esclusioni di policy e account break-glass sono coinvolti, quali workflow di business dipendono da essi, quali privilegi espongono e quali eccezioni di emergenza sono state aggiunte nel tempo. Questa fase di definizione del perimetro previene una remediation superficiale, perché il sintomo tecnico è spesso più piccolo del blast radius operativo. Documentando il percorso completo dalla configurazione al privilegio, il team può dare priorità ai cambiamenti che riducono il rischio rapidamente senza interrompere l'accesso in produzione. Questo crea anche una baseline difendibile per le validazioni successive e offre alla leadership una spiegazione chiara del motivo per cui il problema è rilevante ora.

Controlli Adiacenti da Verificare

Quando gli attaccanti raggiungono il tuo tenant Entra ID e Azure, raramente si fermano al primo punto debole. Intorno a Azure Tenant Hardening: Correggere le Impostazioni Predefinite Non Sicure, normalmente verificano se il percorso esposto può essere concatenato con autenticazione legacy, governance guest debole, consenso applicativo troppo ampio, account di emergenza obsoleti e ruoli mai rivisti. Questo significa che i difensori devono rivedere non solo la debolezza principale, ma ogni dipendenza vicina che trasforma l'accesso in persistenza o escalation di privilegi. Verifica quali identità, ruoli, permessi e presupposti di trust possono essere riutilizzati da un operatore motivato. Se una correzione chiude un solo oggetto lasciando intatti i percorsi di privilegio adiacenti, il rischio effettivo cambia poco. Una revisione disciplinata delle opportunità di concatenamento è ciò che trasforma questo argomento in un esercizio pratico di hardening, invece che in una semplice casella da spuntare una tantum.

Evidenze e Telemetry da Raccogliere

Una risposta solida a Azure Tenant Hardening: Correggere le Impostazioni Predefinite Non Sicure richiede evidenze che possano essere riviste sia dal team di engineering che da quello di detection. Raccogli i log di accesso, gli audit log, le modifiche alle assegnazioni di ruolo, gli eventi di consenso, le modifiche alle credenziali applicative e i segnali di sign-in a rischio, confronta i cambiamenti recenti con le finestre di manutenzione note e isola gli account o i sistemi che hanno cambiato comportamento senza un motivo di business chiaro. Usa queste evidenze per rispondere a tre domande: quando è comparso il percorso a rischio, chi può ancora utilizzarlo e se un'esposizione simile esiste altrove nel tuo tenant Entra ID e Azure. Una buona revisione della telemetry aiuta anche a distinguere il debito tecnico ereditato dall'abuso attivo. Questa distinzione conta, perché il piano di remediation per una configurazione errata obsoleta è diverso dal piano per un percorso che mostra già attività simili a quelle di un attaccante o eccezioni di policy ripetute.

Debolezze Vicine da Rivedere

Pochissimi ambienti contengono solo Azure Tenant Hardening: Correggere le Impostazioni Predefinite Non Sicure in isolamento. In pratica, lo stesso tenant o segmento di directory contiene spesso anche autenticazione legacy, governance guest debole, consenso applicativo troppo ampio, account di emergenza obsoleti e ruoli mai rivisti, e queste debolezze vicine determinano se il problema è semplicemente rumoroso o davvero critico. Rivedi gli owner condivisi, i permessi ereditati, le eccezioni duplicate e le scorciatoie amministrative di lunga data. Verifica se lo stesso team ha approvato pattern a rischio simili in più punti, perché decisioni ripetute di solito indicano una lacuna di processo piuttosto che un singolo bug tecnico. Questa revisione più ampia previene una pulizia parziale e aumenta le probabilità di rimuovere l'intero percorso di attacco. Migliora anche la prontezza per gli audit, perché lo stato finale è più facile da spiegare e da monitorare nel tempo.

Ordine di Remediation che Riduce Rapidamente il Rischio

Per Azure Tenant Hardening: Correggere le Impostazioni Predefinite Non Sicure, la remediation dovrebbe seguire un ordine che riduce l'esposizione prima di inseguire la perfezione. Rimuovi prima i percorsi di espansione dei privilegi più semplici, poi blocca le identità o gli oggetti a più alto valore, e solo dopo occupati delle lacune secondarie di hygiene. Usa Accesso Condizionale, PIM, minimo privilegio, access review, verifiche di ownership delle applicazioni, workflow di approvazione e MFA forte come insieme di controlli che definiscono lo stato target. Ogni modifica dovrebbe avere un owner, una nota di rollback e una fase di validazione. Questo evita che i progetti lunghi si blocchino dopo la prima correzione tecnica. Se una riprogettazione completa non è immediatamente possibile, documenta controlli temporanei che riducono oggi il potenziale di abuso e pianifica il lavoro strutturale nella prossima review operativa settimanale e review di hardening mensile. Il punto importante è la riduzione misurabile del rischio, non una conformità puramente cosmetica.

Validazione Dopo Ogni Cambiamento

Dopo aver modificato qualsiasi impostazione legata a Azure Tenant Hardening: Correggere le Impostazioni Predefinite Non Sicure, convalida il risultato sia dal punto di vista amministrativo che dal punto di vista del percorso di attacco. Conferma che gli utenti e i sistemi previsti continuino a funzionare, poi dimostra che il percorso pericoloso non offre più la stessa leva. Ripeti la raccolta delle evidenze su log di accesso, audit log, modifiche alle assegnazioni di ruolo, eventi di consenso, modifiche alle credenziali applicative e segnali di sign-in a rischio, rivedi i registri di approvazione e verifica che gli oggetti vicini non conservino ancora una via alternativa. La validazione dovrebbe includere anche una semplice dichiarazione scritta dei criteri di successo, in modo che il team sappia cosa significa chiusura. Nei team maturi, questo passaggio è ciò che previene le regressioni: la correzione viene accettata solo quando il percorso a rischio è chiuso, il servizio di business continua a funzionare e lo stato risultante corrisponde all'obiettivo di hardening che si vuole davvero raggiungere.

Azure Tenant Hardening: Convalida Prima della Chiusura

Una revisione solida di Azure Tenant Hardening dovrebbe concludersi con evidenze di produzione, non con l'assunzione che il percorso a rischio sia scomparso. Prima di chiudere il rilievo, ricontrolla le assegnazioni di ruolo, l'ambito delle policy, i permessi applicativi o le impostazioni guest, le evidenze di sign-in, audit o rischio provenienti dal tenant reale, e il percorso di eccezione che potrebbe ricreare silenziosamente l'esposizione. Conferma che lo stato più sicuro si applichi all'ambito che conta davvero: l'OU di produzione, l'assegnazione di ruolo effettiva, il percorso applicativo o il percorso di trust e delega che un attaccante sfrutterebbe realmente. Registra l'owner tecnico, la dipendenza di business e la condizione di rollback, in modo che la prossima revisione possa stabilire se lo stato più sicuro è stato mantenuto.

Usa una breve checklist di chiusura:

• verifica che lo stato a rischio sia scomparso dal punto di vista dell'attaccante, non solo da uno screenshot amministrativo
• conserva un export o un campione di log prima/dopo che dimostri il cambiamento dell'ambito interessato
• documenta l'owner e la decisione sull'eccezione se il controllo non ha potuto essere applicato completamente

Per l'esposizione adiacente, confronta il risultato con Conformita AD e Azure: NIS2, ISO 27001, CIS, Lacune accesso condizionale Entra ID: quali errori lasciano una reale esposizione, Accesso Privilegiato Azure: Troppi Admin Globali e Confronto strumento audit AD: come confrontare PingCastle, Purple Knight e workflow di audit ripetibili. La stessa lacuna di controllo spesso riappare in percorsi di identità vicini, lacune di logging o permessi delegati, motivo per cui la fase di validazione finale conta quanto il rilievo iniziale.

Azure Tenant Hardening: Evidenze da Conservare per il Prossimo Ciclo di Revisione

Il prossimo revisore non dovrebbe dover ricostruire il caso a memoria. Conserva le evidenze che hanno originariamente giustificato il rilievo, la prova che la modifica è stata applicata e la nota che spiega perché lo stato finale è accettabile. Per questo argomento, le evidenze più utili di solito combinano l'export del tenant o lo screenshot che mostra l'ambito interessato, le evidenze di sign-in, audit o policy che dimostrano che il controllo ora si applica, e la nota su owner, approvazione ed eccezione relativa allo stato finale. Questo pacchetto compatto rende molto più rapide le revisioni trimestrali o post-modifica e aiuta a spiegare se il problema è stato rimosso, ridotto o accettato formalmente.

Se una successiva modifica amministrativa, di policy o applicativa riapre il percorso, questa evidenza storica rende anche più facile dimostrare cosa è andato in deriva. È questo che trasforma Azure Tenant Hardening da un controllo una tantum in un processo di assurance ripetibile.

Letture Correlate

Analizza questo argomento insieme a Lacune accesso condizionale Entra ID: quali errori lasciano una reale esposizione, Accesso Privilegiato Azure: Troppi Admin Globali, Account Guest Azure: governance, MFA e rischio di accesso esterno, App Azure con Privilegi Eccessivi nel Tenant e Azure Identity Protection: Bloccare le Credenziali Divulgate. Questi articoli correlati mostrano come le stesse debolezze di identità si concatenano solitamente in una valutazione reale, invece di comparire come rilievi isolati.

• Lacune accesso condizionale Entra ID: quali errori lasciano una reale esposizione
• Accesso Privilegiato Azure: Troppi Admin Globali
• Account Guest Azure: governance, MFA e rischio di accesso esterno
• App Azure con Privilegi Eccessivi nel Tenant
• Azure Identity Protection: Bloccare le Credenziali Divulgate

L'uso di questi riferimenti mantiene la discussione sulla remediation concentrata sull'intero percorso di attacco, invece che su una singola lacuna di controllo.

Convalidare la Baseline di Hardening nel Tempo

Le impostazioni predefinite dovrebbero essere trattate come un punto di partenza, non come il risultato finale dell'hardening. Dopo aver applicato impostazioni predefinite del tenant più sicure, verifica quali team dipendono ancora da eccezioni troppo ampie, se nuove applicazioni o utenti possono aggirare i controlli previsti, e come viene monitorata la deriva nel tempo. Un tenant sottoposto a hardening resta resiliente solo quando ownership, cadenza delle revisioni e gestione delle eccezioni sono altrettanto disciplinate quanto il rollout iniziale.