Entra ID SSPR falle di sicurezza: non attivato, admin esentati, metodi di reset deboli

Entra ID SSPR falle di sicurezza: di cosa si tratta

Il reset password self-service (SSPR) in Microsoft Entra ID dovrebbe chiudere il ciclo di recupero account che l'autenticazione multifattore apre altrove nel tenant (vedi anche perché l'MFA da solo non basta). In pratica, le stesse tre entra id sspr falle di sicurezza si ripresentano continuamente sui tenant reali: SSPR lasciato disattivato per l'intero tenant, amministratori esclusi da una policy che in realtà richiede una verifica forte, e metodi di reset deboli — domande di sicurezza o SMS — accettati da soli come prova d'identità sufficiente.

SSPR permette agli utenti di riottenere l'accesso a un account bloccato senza aprire un ticket all'helpdesk, verificando la propria identità tramite uno o più metodi registrati (app Authenticator, email, telefono, o domande di sicurezza) su passwordreset.microsoftonline.com. Attivarlo richiede almeno una licenza Microsoft Entra ID P1 e il ruolo Authentication Policy Administrator, e il suo ambito può essere impostato su None, un singolo gruppo (eventualmente annidato), o All (tutti gli utenti), secondo il tutorial di attivazione di Microsoft.

La maggior parte dei rollout si ferma qui, presentata unicamente come un risparmio sui costi — meno chiamate all'helpdesk, reset più veloce per gli utenti finali, una riga in più su un foglio di licenze. È questo inquadramento a permettere che le tre falle seguenti passino inosservate:

• SSPR completamente disattivato (SSPR_NOT_ENABLED) — non esiste alcun percorso self-service, quindi ogni reset passa attraverso un umano.
• Amministratori non coperti da una policy di reset che richieda davvero una verifica forte (SSPR_NOT_REQUIRED_ADMINS) — gli account privilegiati ricadono sullo stesso percorso manuale, sfruttabile con ingegneria sociale.
• Metodi deboli accettati come prova d'identità sufficiente (SSPR_METHODS_WEAK) — domande di sicurezza o chiamate SMS/vocali che soddisfano da sole la policy di reset.

Nessuna di queste è una configurazione errata esotica. Sono stati prossimi al default in cui un tenant scivola semplicemente non rivedendo mai SSPR dopo la configurazione iniziale — il che spiega anche perché vengono raramente rilevate in una revisione di routine: un penetration test o un audit MFA in genere verifica se l'accesso richiede un secondo fattore, non se il percorso di recupero di quello stesso account sia altrettanto solido. Un attaccante non ha bisogno di battere l'MFA sulla porta principale se la porta sul retro — il recupero password — richiede solo una domanda di sicurezza indovinata o una telefonata convincente.

Le tre falle di sicurezza SSPR, una per una

Falla 1 — SSPR completamente disattivato

Quando l'ambito di SSPR è None, ogni reset della password deve passare tramite l'IT o l'helpdesk. Questo percorso manuale è esattamente il vettore descritto nell'avviso CISA su Scattered Spider (AA23-320A): gli attori delle minacce chiamano o mandano SMS al personale dell'helpdesk fingendosi un dipendente, richiedendo un reset della password o un cambio dispositivo MFA come vettore di accesso iniziale. Un tenant con SSPR disattivato non ha eliminato il percorso di reset — ha forzato il 100% dei reset a passare esattamente per il canale che quella tecnica prende di mira, senza dare all'helpdesk una base self-service con cui confrontare una richiesta insolita.

Falla 2 — Admin non obbligati a usare SSPR

Per impostazione predefinita, Microsoft Entra tratta gli account amministratore in modo diverso: sono coperti da una policy a due porte integrata e non modificabile che richiede due elementi di autenticazione, distinta dalla policy (spesso a porta singola) applicata agli utenti normali, secondo la documentazione Microsoft sulla policy SSPR. I tenant che disattivano la policy di reset admin — senza escludere esplicitamente gli admin dalla policy rivolta agli utenti — lasciano che gli account privilegiati si reimpostino nello stesso modo della Falla 1: manualmente, tramite l'helpdesk. Questo è l'account a massimo valore da proteggere da quel percorso, poiché un reset ottenuto con ingegneria sociale su un Global Administrator è una compromissione totale del tenant, non solo di una casella di posta.

Falla 3 — Metodi di reset deboli accettati

Le domande di sicurezza possono essere indovinate da chiunque abbia condotto una leggera ricognizione su un bersaglio, e Microsoft le sta ritirando completamente da SSPR entro marzo 2027 proprio per questo motivo — la documentazione stessa di Microsoft le segnala come "meno sicure di altri metodi" e raccomanda di abbinarle a un secondo metodo se vengono comunque usate. I metodi via telefono cellulare (SMS/chiamata vocale) portano il loro noto rischio di intercettazione e SIM-swap — le linee guida NIST sull'identità digitale classificano i codici consegnati via rete telefonica come autenticatore ristretto proprio per questo motivo, indicando ai verificatori di controllare cambi di SIM e number porting prima di affidarvisi, secondo NIST SP 800-63B. Una policy di reset che accetta uno di questi come unica porta sufficiente è funzionalmente debole quanto l'assenza di policy — l'account è a una risposta indovinata o un SMS intercettato dalla presa di controllo.

Rilevamento

Se stai conducendo una revisione di sicurezza Entra ID più ampia, la postura SSPR appartiene allo stesso passaggio di Conditional Access e PIM — si verifica con gli stessi permessi Graph e la stessa sessione dell'admin center.

Interrogare direttamente la copertura di registrazione

Connect-MgGraph -Scopes "Reports.Read.All", "Policy.Read.All"

# Postura SSPR degli admin
Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/v1.0/policies/authorizationPolicy" |
  Select-Object -ExpandProperty allowedToUseSSPR

# Utenti abilitati per SSPR ma non effettivamente registrati
Get-MgReportAuthenticationMethodUserRegistrationDetail -All `
  -Filter "isSsprEnabled eq true and isSsprRegistered eq false" |
  Select-Object UserPrincipalName, IsAdmin, IsSsprRegistered, MethodsRegistered

Qualsiasi account restituito da questa seconda query può essere abilitato per SSPR sulla carta pur non avendo alcun metodo conforme effettivamente registrato — il che significa che il suo percorso di reset reale, oggi, resta l'helpdesk. Incrocia prima la colonna IsAdmin con la tua lista di ruoli privilegiati; un account Global Administrator o di directory presente in quel risultato cumula la Falla 2 e la Falla 3 sulla stessa identità, il che lo rende la combinazione da gestire per prima in questo elenco.

Remediation

Chiudere la Falla 1 — Attivare SSPR per l'intero tenant

Nell'admin center Entra, sotto Protection → Password reset → Properties, imposta l'ambito su All piuttosto che None o un singolo gruppo pilota. Questo richiede il ruolo Authentication Policy Administrator e una licenza Entra ID P1+, secondo il tutorial Microsoft.

Chiudere la Falla 2 — Sottoporre gli account admin a una vera policy di reset

Conferma che allowedToUseSSPR su authorizationPolicy rifletta una decisione intenzionale, e che i ruoli privilegiati siano coperti dalla policy admin integrata a due porte di Entra invece che silenziosamente esclusi, secondo la documentazione Microsoft sulla policy SSPR. Per i ruoli più sensibili (Global Administrator ed equivalenti), abbina questo a metodi resistenti al phishing e ad account di accesso di emergenza break-glass strettamente monitorati ed esclusi da Conditional Access, così che il recupero non dipenda mai unicamente da SSPR o da una chiamata all'helpdesk. Incrocia le assegnazioni permanenti con la tua revisione degli accessi privilegiati — un account che non dovrebbe essere admin permanente in primo luogo non ha bisogno che questo problema gli venga risolto.

Chiudere la Falla 3 — Richiedere due metodi ed eliminare quelli deboli

Configura la policy di reset per richiedere almeno due porte, e rimuovi Security questions come opzione autonoma — Microsoft le ritira comunque da SSPR entro marzo 2027, secondo la sua documentazione. Preferisci l'app Authenticator o la registrazione passkey rispetto a SMS/chiamata vocale.

Poi, chiudere il cerchio su registrazione e monitoraggio

Attiva la campagna di registrazione dei metodi di autenticazione così che gli utenti abbiano metodi conformi registrati prima di dover mai reimpostare una password, chiudendo AUTH_METHODS_NO_REGISTRATION insieme alle altre tre falle. Se il tuo tenant sta anche lavorando sull'applicazione SSPR solo metodi registrati di novembre 2026, lo stesso report di registrazione alimenta entrambe le correzioni — quel cambiamento smette di accettare telefono/email di directory non registrati come fallback, il che conta solo se la copertura di registrazione viene effettivamente tracciata in primo luogo.

Infine, monitora le due attività di audit più importanti — Self-service password reset policy changes e Reset password (by admin) — così che un futuro indebolimento dell'ambito, del numero di metodi, o dei metodi consentiti emerga immediatamente invece di riaprire silenziosamente queste falle. Un picco di reset eseguiti da un admin per lo stesso pugno di utenti è di solito il primo segno visibile che SSPR ha smesso di funzionare per loro, ben prima che qualcuno apra un ticket a riguardo.

Come EtcSec rileva questo

L'audit Entra ID di EtcSec verifica SSPR_NOT_ENABLED (SSPR limitato a None), SSPR_NOT_REQUIRED_ADMINS (amministratori non coperti da una policy di reset conforme), e SSPR_METHODS_WEAK (domande di sicurezza o telefono cellulare da soli che soddisfano la policy), insieme a AUTH_METHODS_SMS_ENABLED e AUTH_METHODS_NO_REGISTRATION per la postura circostante dei metodi di autenticazione. Insieme, questi cinque controlli offrono una vista unica se il percorso di recupero account sia realmente solido quanto il percorso di accesso che dovrebbe supportare — perché un tenant che ha irrobustito ogni accesso con Conditional Access e MFA, ma ha lasciato il recupero password su una configurazione SSPR di default, ha appena costruito una porta d'ingresso solida accanto a un ingresso laterale non chiuso a chiave.