Risorse · 24
Implementare un'autenticazione resistente al phishing con ripristino sicuro.
Utilizzare fattori associati al servizio autentico e proteggere la registrazione, la perdita e la revoca.
Aggiornato · 3 min
Obiettivi di questa guida
- Mappare i percorsi di accesso
- Selezionare un protocollo resistente
- Proteggere la registrazione
- Esercitazione di ripristino.
Verifica rapida
- Quali account accedono a dati o funzioni critiche?
- Il fattore è crittograficamente associato al servizio autentico?
- Chi autorizza un nuovo autenticatore?
- Come viene revocato un dispositivo smarrito?
- Le eccezioni hanno un responsabile e una data di fine?
Metodo passo passo
- 1
Inventariare i percorsi di accesso
Elencare applicazioni, federazione, amministratori, account di emergenza e metodi attuali. Identificare gli accessi che accettano ancora codici inseriti manualmente.
Risultato: matrice account, applicazione e fattore.
- 2
Selezionare la resistenza richiesta
Valutare i protocolli crittografici associati a un canale o a un nome di verificatore, come WebAuthn/FIDO2, laddove l'applicazione lo supporti. Il NIST non considera gli OTP inseriti manualmente resistenti al phishing perché un sito falso può inoltrarli.
Risultato atteso: scelta del metodo e limitazioni note.
- 3
Testare gli account sensibili.
Testare browser, dispositivi, delega, possibile utilizzo offline e accessibilità con un gruppo rappresentativo. Fornire più di un percorso autorizzato senza accumulare accessi inattivi.
Risultato: scenari pilota e criteri di successo.
- 4
Proteggere la registrazione
Verificare l'identità e la sessione prima di aggiungere una chiave, notificare l'utente e registrare l'evento. Testare il rifiuto di una richiesta di registrazione da un contesto sospetto.
Risultato: procedura di registrazione e registro degli eventi.
- 5
Pianificare la gestione della perdita e della revoca.
Documentare la segnalazione, la disabilitazione, il ripristino e i controlli di identità per un autenticatore smarrito. Testare il percorso senza aggirare la protezione tramite un canale più debole.
Risultato: esercitazione di ripristino e revoca.
- 6
Espandere e monitorare.
Implementare per gruppi, misurare la copertura, monitorare guasti ed eccezioni, quindi dismettere i metodi legacy una volta che il processo di ripristino testato lo consente.
Risultato: dashboard di migrazione e registro delle eccezioni.
Indicatori di gestione
| Indicatore | Cosa misura | Prima azione |
|---|---|---|
| Copertura | Account sensibili con metodi resistenti | Estensione del rollout |
| Registrazione | Aggiunte con controlli e notifiche | Correzione dei punti deboli |
| Ripristino | Perdite simulate risolte senza bypass | Ripetizione dell'esercizio |
| Eccezioni | Accesso residuo con proprietario e scadenza | Dismissione dei fattori legacy |
Errori comuni
- Definire ogni metodo MFA resistente al phishing
- Protezione dell'accesso ma registrazione debole
- Mancanza di amministratori e account di emergenza
- Dismissione di un metodo legacy prima che il ripristino funzioni
Domande frequenti
È sufficiente un codice monouso?
Il NIST spiega che un codice inserito manualmente può essere trasmesso da un servizio di impostore e non è resistente al phishing.
È necessaria una chiave hardware per tutti?
La scelta dipende dalla sicurezza e dal contesto; alcuni autenticatori WebAuthn sincronizzabili possono essere adatti ad alcuni utilizzi con opzioni di ripristino appropriate.
Cosa succede in caso di smarrimento del dispositivo?
Revoca l'autenticatore interessato, segui la procedura di ripristino verificata e notifica l'utente in base alle policy di servizio.
Riferimenti ufficiali
I riferimenti supportano il metodo. Adattare i controlli al proprio contesto; non costituiscono una certificazione. I titoli dei riferimenti originali e i documenti di origine potrebbero essere in un'altra lingua.
