Parta dagli amministratori e imponga loro, tramite Conditional Access, la authentication strength integrata Phishing-resistant MFA. Questa consente solo Windows Hello for Business o una credenziale di piattaforma, una chiave di sicurezza FIDO2 oppure l'autenticazione basata su certificato di Entra (multifattore). SMS e approvazioni push non soddisfano più la policy per quegli account sulle risorse da essa coperte, anche se la richiesta della password rimane (vedi Cosa si rompe).
Perché si parte dagli admin
La panoramica sull'autenticazione di Microsoft afferma che l'MFA basata su SMS, OTP via email o app di autenticazione è soggetta a phishing remoto, in cui gli attaccanti rubano password o codici monouso senza mai toccare il dispositivo dell'utente. Microsoft raccomanda invece Windows Hello for Business, passkey (FIDO2), chiavi di sicurezza FIDO2 o l'autenticazione basata su certificato. Un account admin è il punto in cui un codice rubato costa di più, e un team piccolo ne ha solo una manciata da migrare.
Attenzione all'opzione intermedia tra quelle integrate. Secondo la documentazione sulle authentication strength, la strength Passwordless MFA include l'accesso da telefono con Microsoft Authenticator. La strength Phishing-resistant no.
Preparare il tenant
Le passkey (FIDO2) sono disponibili in tutte le edizioni di Entra ID senza licenza aggiuntiva. Conditional Access richiede Entra ID P1.
Le impostazioni si trovano in Entra ID > Security > Authentication methods > Policies > Passkey (FIDO2). Serve almeno il ruolo Authentication Policy Administrator. Tre dettagli sono importanti:
- L'adesione ai profili passkey è a senso unico. Non è possibile tornare indietro e le impostazioni globali attuali vengono spostate in un profilo Default. Sono supportati fino a tre profili, Default incluso.
- Allow self-service set up deve essere su Yes, altrimenti gli utenti non possono registrare una passkey tramite Security info. È un'impostazione globale, non per singolo profilo.
- La registrazione richiede un'MFA completata negli ultimi cinque minuti.
Per gli admin, l'esempio della documentazione è un profilo con tipo di passkey Device-bound ed Enforce attestation impostato su Yes. Device-bound significa che la chiave privata non lascia mai un singolo dispositivo fisico, come una chiave di sicurezza o Microsoft Authenticator. Le passkey sincronizzate non supportano l'attestation e Microsoft indica di considerarle resistenti al phishing, ma con il livello di sicurezza di altri autenticatori privi di attestation. Il testo del NIST richiede all'AAL3, il livello più alto, un autenticatore resistente al phishing con chiave non esportabile, quindi le chiavi device-bound sono la corrispondenza più vicina tra le opzioni di Entra.
Applicare con una authentication strength
Crei una policy di Conditional Access, selezioni come destinatari i vostri ruoli admin o il relativo gruppo e, nei grant controls, scelga Require authentication strength. Selezioni Phishing-resistant MFA. Non è possibile combinarla con Require multifactor authentication nella stessa policy, perché la strength MFA integrata equivale a quel controllo.
Le strength integrate non sono modificabili e Microsoft le aggiorna quando compaiono nuovi metodi. Se Le serve un insieme fisso di metodi consentiti, crei una strength personalizzata.
Non è necessario disattivare gli SMS per tutti. La strength si colloca sopra la policy Authentication methods e la restringe per uno scenario specifico. Il personale può mantenere password e approvazione push per le risorse ordinarie, mentre gli admin sono vincolati alla policy più severa.
Cosa si rompe
Un admin digita comunque prima la password. Conditional Access viene valutato dopo l'autenticazione iniziale, quindi solo a quel punto la strength richiede un metodo resistente al phishing.
Se un utente accede con la password come metodo primario e la strength richiede Windows Hello for Business, il sistema non glielo propone. Deve riavviare la sessione, selezionare Sign-in options e scegliere il metodo richiesto. Lo inserisca nelle istruzioni per i Suoi admin.
Due controlli agiscono in momenti diversi. Enforce attestation si applica solo alla registrazione, quindi una passkey registrata senza attestation non viene bloccata all'accesso una volta attivata l'opzione. Registri di nuovo le chiavi degli admin dopo l'attivazione. Le restrizioni sulle chiavi per AAGUID valgono sia per la registrazione sia per l'accesso, quindi rimuovere un AAGUID prima consentito esclude chiunque abbia registrato quel modello.
La sovrapposizione dei profili è permissiva e incide su registrazione e accesso a livello di policy passkey. Quando un utente rientra in più profili, una passkey è ammessa se ne soddisfa completamente almeno uno, senza un ordine particolare. Un admin che appartiene anche a un gruppo "tutte le passkey sincronizzate o device-bound" può quindi registrare e usare una passkey sincronizzata, almeno per quanto riguarda la policy passkey. Le fonti non chiariscono se la strength di Conditional Access la accetti, quindi verifichi questo caso con un test.
Dopo l'adesione, controlli il profilo Default in Enable and target. Se il suo target è All users e consente passkey sincronizzate, lo riassegni a gruppi che non contengano i Suoi admin. Non escluda invece gli admin nella policy Passkey (FIDO2): un gruppo escluso è bloccato del tutto da registrazione e accesso FIDO2, e questo prevale su qualsiasi inclusione.
Sign-in frequency e strength possono essere soddisfatte in momenti diversi. Con una strength basata su passkey e una sign-in frequency di 1 ora, un accesso con passkey di 24 ore prima più uno sblocco del dispositivo con Windows Hello oggi soddisfano entrambe. Se per gli admin si affida a frequenze brevi, testi questo caso.
Temporary Access Pass compare nella strength MFA ma non in quella phishing-resistant. Una nostra inferenza, che le fonti non riportano: un flusso di recupero o di bootstrap basato su Temporary Access Pass non soddisferà la policy, quindi richiede un'esclusione o una policy separata. Lo decida prima di applicare la policy, non durante l'incidente.
Da dove iniziare
- Elenchi ogni account con un ruolo admin e scelga due o tre account per il gruppo pilota.
- Aderisca ai profili passkey, controlli il target del profilo Default, crei un profilo admin con Device-bound ed Enforce attestation su Yes e lo assegni solo al gruppo pilota.
- Registri almeno due autenticatori per ogni admin del pilota, ad esempio una chiave di sicurezza e Windows Hello, e verifichi che l'accesso funzioni con ciascuno.
- Crei la policy di Conditional Access con la strength Phishing-resistant MFA per il gruppo pilota. Come buona pratica generale (le pagine Microsoft qui utilizzate non trattano gli account break-glass), escluda gli account di accesso di emergenza e assegni a ciascuno una propria chiave FIDO2.
- Estenda a tutti gli admin. Rimuova le passkey registrate prima dell'applicazione dell'attestation solo dopo che ogni admin ha registrato di nuovo una chiave con attestation, così nessuno resta bloccato fuori.
- Faccia verificare il risultato. Il nostro team di consulenza può rivedere la policy e un penetration test mostra se qualche percorso admin accetta ancora un metodo più debole.
