Pianificare una distribuzione dell'autenticazione senza password resistente al phishing in Microsoft Entra ID
Quando si distribuisce e si opera l'autenticazione senza password resistente al phishing nell'ambiente, è consigliabile adottare un approccio basato sulle tipologie di utenti. Diversi metodi di autenticazione senza password resistente al phishing sono più efficaci di altri per determinate tipologie di utenti. Questa guida alla distribuzione consente di vedere quali tipi di metodi e piani di implementazione hanno senso per le tipologie di utenti nell'ambiente in uso. L'approccio di distribuzione di autenticazione senza password resistente al phishing prevede in genere 6 passaggi, che si susseguono approssimativamente in ordine, ma non devono essere completati al 100% prima di passare ai passaggi successivi:
Determinare le tipologie di utenti
Determinare le tipologie di utenti rilevanti per l'organizzazione. Questo passaggio è fondamentale per il progetto perché diverse tipologie di utenti hanno esigenze diverse. Microsoft consiglia di prendere in considerazione e valutare almeno 4 tipologie di utenti generiche nell'organizzazione.
| Tipologie di utenti | Descrizione |
|---|---|
| Information worker | |
| Personale sul campo | |
| Professionisti IT/ruoli di lavoro DevOps | |
| Lavoratori altamente regolamentati |
Microsoft consiglia di distribuire l'autenticazione senza password resistente al phishing a livello generale nell'organizzazione. Tradizionalmente, gli information worker sono la tipologia di utenti più semplice da cui iniziare. Non ritardare l'implementazione delle credenziali sicure per gli information worker mentre vengono risolti i problemi che interessano i professionisti IT. Prendi l'approccio di "il meglio è nemico del bene" e distribuisci il più possibile le credenziali sicure. Man mano che più utenti accedono usando credenziali senza password resistenti al phishing, si riduce la superficie di attacco dell'ambiente.
Microsoft consiglia di definire le tipologie di utenti e quindi inserire ogni tipologia in un gruppo di Microsoft Entra ID in modo specifico per quel tipo di utente. Questi gruppi vengono usati nei passaggi successivi per implementare le credenziali a diversi tipi di utenti e quando si inizia ad applicare l'uso di credenziali senza password resistenti al phishing.
Pianificare l'idoneità dei dispositivi
I dispositivi sono un aspetto essenziale di qualsiasi distribuzione senza password resistente al phishing, poiché uno degli obiettivi delle credenziali senza password resistenti al phishing è proteggere le credenziali con l'hardware dei dispositivi moderni. Prima di tutto, acquisire familiarità con il supporto FIDO2 per Microsoft Entra ID.
Assicurarsi che i dispositivi siano preparati per l'autenticazione senza password resistente al phishing applicando patch alle versioni più recenti supportate di ogni sistema operativo. Microsoft consiglia che i dispositivi eseguano almeno queste versioni:
- Windows 10 22H2 (per Windows Hello for Business)
- Windows 11 22H2 (per un'esperienza utente ottimale quando si usano passkey)
- macOS 13 Ventura
- iOS 17
- Android 14
Queste versioni offrono il supporto migliore per le funzionalità integrate in modo nativo, ad esempio passkey, Windows Hello for Business e macOS Platform Credential. I sistemi operativi meno recenti possono richiedere autenticatori esterni, ad esempio chiavi di sicurezza FIDO2, per supportare l'autenticazione senza password resistente al phishing.
Registrare gli utenti per credenziali resistenti al phishing
La registrazione delle credenziali e il bootstrap sono le prime attività principali rivolte agli utenti finali nel progetto di distribuzione di un'autenticazione senza password resistente al phishing. Questa sezione illustra l'implementazione delle credenziali portabili e locali.
| Credenziali | Descrizione | Vantaggi |
|---|---|---|
| Portabili | Possono essere usate in tutti i dispositivi. È possibile usare le credenziali portabili per accedere a un altro dispositivo o per registrare le credenziali in altri dispositivi. | Il tipo di credenziale più importante da registrare per la maggior parte degli utenti, perché può essere usato tra i dispositivi e fornire l'autenticazione resistente al phishing in molti scenari. |
| Locali | È possibile usare le credenziali locali per eseguire l'autenticazione in un dispositivo senza dover fare affidamento su hardware esterno, ad esempio usando il riconoscimento biometrico di Windows Hello for Business per accedere a un'app nel browser Microsoft Edge nello stesso PC | Hanno due vantaggi principali rispetto alle credenziali portabili: |
- Per i nuovi utenti, il processo di registrazione e bootstrap accetta un utente senza credenziali aziendali esistenti e verifica la propria identità. Esegue il bootstrap nelle prime credenziali portabili e usa tali credenziali portabili per eseguire il bootstrap di altre credenziali locali in ognuno dei dispositivi di calcolo. Dopo la registrazione, l'amministratore può applicare l'autenticazione resistente al phishing per gli utenti in Microsoft Entra ID.
- Per gli utenti esistenti, questa fase consente agli utenti di registrarsi direttamente ai dispositivi con autenticazione senza password resistente al phishing o di usare credenziali MFA esistenti per eseguire il bootstrap delle credenziali senza password resistenti al phishing. L'obiettivo finale è lo stesso dei nuovi utenti: la maggior parte degli utenti deve avere almeno le credenziali portabili e quindi le credenziali locali in ogni dispositivo di elaborazione. Gli amministratori che distribuiscono credenziali senza password resistenti al phishing per gli utenti esistenti, possono passare direttamente al Passaggio 2 dell'onboarding: bootstrap di credenziali portatili.
Prima di iniziare, Microsoft consiglia di abilitare passkey e altre credenziali per gli utenti aziendali nel tenant. Se gli utenti sono motivati a registrarsi automaticamente per credenziali complesse, è utile consentirlo. È necessario abilitare almeno il criterio Passkey (FIDO2) in modo che gli utenti possano registrarsi per passkey e chiavi di sicurezza se preferiscono.
Questa sezione è incentrata sulle fasi 1-3:
Gli utenti devono avere almeno due metodi di autenticazione registrati. Con un altro metodo registrato, l'utente dispone di un metodo di backup disponibile se si verifica un evento al metodo primario, ad esempio quando un dispositivo viene smarrito o rubato. Ad esempio, è consigliabile che gli utenti abbiano passkey registrate sia sul telefono che localmente nella workstation in Windows Hello for Business.
Nota
È sempre consigliabile che gli utenti abbiano almeno due metodi di autenticazione registrati. In questo modo l'utente dispone di un metodo di backup disponibile se si verifica un evento al metodo principale, ad esempio in caso di perdita o furto del dispositivo. Ad esempio, è consigliabile che gli utenti abbiano passkey registrate sia sul telefono che localmente nella workstation in Windows Hello for Business.
Nota
Queste indicazioni sono personalizzate per il supporto attualmente esistente per passkey in Microsoft Entra ID, che include passkey associate al dispositivo in Microsoft Authenticator e passkey associate al dispositivo nelle chiavi di sicurezza fisiche. Microsoft Entra ID prevede di aggiungere il supporto per passkey sincronizzate. Per altre informazioni, vedere Anteprima pubblica: espansione del supporto passkey in Microsoft Entra ID. Questa guida verrà aggiornata in modo da includere le linee guida passkey sincronizzate una volta disponibili. Ad esempio, molte organizzazioni possono trarre vantaggio dalla sincronizzazione per la fase 3 nel diagramma precedente anziché eseguire il bootstrap di credenziali completamente nuove.
Passaggio 1 dell'onboarding: verifica dell'identità
Per gli utenti remoti che non hanno dimostrato la propria identità, l'onboarding aziendale è una sfida significativa. Senza una corretta verifica dell'identità, un'organizzazione non può essere completamente certa che stia eseguendo l'onboarding della persona che intende eseguire. ID verificato di Microsoft Entra può fornire una verifica elevata dell'identità. Le organizzazioni possono collaborare con un partner di verifica delle identità (IDV) per verificare le identità dei nuovi utenti remoti nel processo di onboarding. Dopo aver elaborato l'ID rilasciato dall'utente per enti pubblici, l'IDV può fornire un ID verificato che conferma l'identità dell'utente. Il nuovo utente presenta questo ID verificato che conferma l'identità all'organizzazione di assunzione per stabilire la fiducia e verificare che l'organizzazione stia caricando la persona giusta. Le organizzazioni possono aggiungere Verifica viso con ID verificato di Microsoft Entra che aggiunge un livello di corrispondenza facciale alla verifica, assicurandosi che l'utente attendibile presenti l'ID verificato confermando l'identità in quel momento.
Dopo aver verificato la propria identità tramite il processo di correzione, ai nuovi assunti viene assegnato un pass di accesso temporaneo (TAP) che può usare per eseguire il bootstrap delle prime credenziali portabili.
Fare riferimento alle guide seguenti per abilitare l'onboarding ID verificato di Microsoft Entra e il rilascio TAP:
- Eseguire l'onboarding di nuovi dipendenti remoti usando la verifica dell'ID
- Uso di Face Check con ID verificato di Microsoft Entra per sbloccare le verifiche a garanzia elevata su larga scala
- Abilita il criterio pass di accesso temporaneo
Per informazioni dettagliate sulle licenze per ID verificato di Microsoft Entra, vedere i collegamenti seguenti:
Alcune organizzazioni potrebbero scegliere altri metodi rispetto a ID verificato di Microsoft Entra per eseguire l'onboarding degli utenti e rilasciare le prime credenziali. Microsoft consiglia alle organizzazioni di continuare a usare TAP o un altro modo per consentire a un utente di eseguire l'onboarding senza password. Ad esempio, è possibile effettuare il provisioning delle chiavi di sicurezza FIDO2 usando l'API Microsoft Graph.
Passaggio 2 dell'onboarding: bootstrap di credenziali portabili
Per eseguire il bootstrap degli utenti esistenti con credenziali senza password resistenti al phishing, determinare prima di tutto se gli utenti sono già registrati per la MFA tradizionale. Gli utenti con metodi di MFA tradizionali registrati possono essere destinati a criteri di registrazione senza password resistenti al phishing. Possono usare la MFA tradizionale per registrare le loro prime credenziali portabili resistenti al phishing e quindi procedere alla registrazione per le credenziali locali in base alle esigenze.
Per i nuovi utenti o gli utenti senza MFA, eseguire un processo per rilasciare agli utenti un Pass di accesso temporaneo (TAP). È possibile rilasciare un TAP nello stesso modo in cui si assegnano ai nuovi utenti le prime credenziali o usando le integrazioni di ID verificato di Microsoft Entra. Una volta che gli utenti hanno un TAP, sono pronti per eseguire il bootstrap delle prime credenziali resistenti al phishing.
È importante che le prime credenziali senza password dell'utente siano credenziali portabili utilizzabili per l'autenticazione in altri dispositivi di elaborazione. Ad esempio, le passkey possono essere usate per eseguire l'autenticazione in locale in un telefono iOS, ma possono anche essere usati per l'autenticazione in un PC Windows usando un flusso di autenticazione tra dispositivi. Questa funzionalità tra dispositivi consentono l'uso di passkey portabili per avviare Windows Hello for Business nel PC Windows.
Inoltre, è importante che ogni dispositivo su cui l'utente lavora regolarmente disponga di credenziali disponibili in locale per offrire l'esperienza utente più fluida possibile. Le credenziali disponibili in locale riducono il tempo necessario per l'autenticazione perché gli utenti non devono usare più dispositivi e sono necessari meno passaggi. L'uso di TAP come da passaggio 1 per registrare credenziali portabili, in grado di eseguire il bootstrap di queste altre credenziali, consente all'utente di usare le credenziali resistenti al phishing in modo nativo nei molti dispositivi che potrebbe possedere.
La tabella seguente elenca le raccomandazioni per le diverse tipologie:
| Tipologie di utenti | Credenziali portabili consigliate | Credenziali portabili alternative |
|---|---|---|
| Information Worker | Passkey (app Authenticator) | Chiave di sicurezza, smart card |
| Dipendente sul campo | Chiave di sicurezza | Passkey (app Authenticator), smart card |
| Professionista IT/Ruolo di lavoro DevOps | Passkey (app Authenticator) | Chiave di sicurezza, smart card |
| Lavoratore altamente regolamentato | Certificato (smart card) | Passkey (app Authenticator), chiave di sicurezza |
Usare le indicazioni seguenti per abilitare le credenziali portabili consigliate e alternative per le tipologie di utenti rilevanti per l'organizzazione:
| Metodo | Indicazioni |
|---|---|
| Passkey | |
| Chiavi di sicurezza | |
| Autenticazione basata su smart card/certificato (CBA) |
Passaggio 3 dell'onboarding: bootstrap di credenziali locali nei dispositivi di elaborazione
Dopo che gli utenti hanno registrato credenziali portabili, sono pronti per il bootstrap di altre credenziali in ogni dispositivo di elaborazione che usano regolarmente in una relazione 1:1, che offre vantaggi all'esperienza utente quotidiana. Questo tipo di credenziali è comune per gli information worker e i professionisti IT, ma non per i dipendenti sul campo che condividono i dispositivi. Gli utenti che possono solo condividere i dispositivi, devono usare credenziali portabili.
L'organizzazione deve determinare quali tipologie di credenziali sono preferibili per ogni tipologia di utente in questa fase. Consigli di Microsoft:
| Tipologie di utenti | Credenziali locali consigliate - Windows | Credenziali locali consigliate - macOS | Credenziali locali consigliate - iOS | Credenziali locali consigliate - Android | Credenziali locali consigliate - Linux |
|---|---|---|---|---|---|
| Information Worker | Windows Hello for Business | Chiave della piattaforma Single Sign-On (SSO) dell'enclave sicura | Passkey (app Authenticator) | Passkey (app Authenticator) | N/D (usare invece credenziali portabili) |
| Dipendente sul campo | N/D (usare invece credenziali portabili) | N/D (usare invece credenziali portabili) | N/D (usare invece credenziali portabili) | N/D (usare invece credenziali portabili) | N/D (usare invece credenziali portabili) |
| Professionista IT/Ruolo di lavoro DevOps | Windows Hello for Business | Chiave della piattaforma SSO dell'enclave sicura | Passkey (app Authenticator) | Passkey (app Authenticator) | N/D (usare invece credenziali portabili) |
| Lavoratore altamente regolamentato | Windows Hello for Business o CBA | Chiave della piattaforma SSO dell'enclave sicura o CBA | Passkey (app Authenticator) o CBA | Passkey (app Authenticator) o CBA | N/D (usare invece smart card) |
Usare le indicazioni seguenti per abilitare le credenziali locali consigliate nell'ambiente per le tipologie di utenti rilevanti per l'organizzazione:
| Metodo | Indicazioni |
|---|---|
| Windows Hello for Business | |
| Chiave della piattaforma SSO dell'enclave sicura | |
| Passkey |
Considerazioni specifiche per tipologia
Ogni tipologia di utenti ha le proprie sfide e considerazioni che in genere si presentano durante le distribuzioni di autenticazioni senza password resistenti al phishing. Quando si identificano le tipologie di utenti da soddisfare, è necessario tenere conto di queste considerazioni nella pianificazione del progetto di distribuzione. I collegamenti seguenti contengono indicazioni specifiche per ogni tipologia:
- Information worker
- Personale sul campo
- Professionisti IT/ruoli di lavoro DevOps
- Lavoratori altamente regolamentati
Promuovere l'utilizzo delle credenziali resistenti al phishing
Questo passaggio illustra come semplificare l'adozione di credenziali resistenti al phishing da parte degli utenti. È consigliabile testare la strategia di distribuzione, pianificare l'implementazione e comunicare il piano agli utenti finali. È quindi possibile creare report e monitorare lo stato di avanzamento prima di applicare credenziali resistenti al phishing nell'organizzazione.
Testare la strategia di distribuzione
Microsoft consiglia di testare la strategia di distribuzione creata nel passaggio precedente con un set di utenti test e pilota. Questa fase dovrebbe includere i passaggi seguenti:
- Creare un elenco di utenti test e early adopter. Questi utenti dovrebbero rappresentare le diverse tipologie di utenti e non solo di amministratori IT.
- Creare un gruppo Microsoft Entra ID e aggiungere gli utenti test al gruppo.
- Abilitare i criteri dei metodi di autenticazione in Microsoft Entra ID e definire l'ambito del gruppo di test per i metodi abilitati.
- Misurare l'implementazione della registrazione per gli utenti pilota usando il report Attività dei metodi di autenticazione.
- Creare criteri di accesso condizionale per applicare le credenziali senza password resistenti al phishing in ogni tipo di sistema operativo e definire come destinazione il gruppo pilota.
- Misurare l'esito positivo dell'applicazione usando Monitoraggio di Azure e Cartelle di lavoro.
- Raccogliere feedback dagli utenti sul successo dell'implementazione.
Pianificare la strategia di implementazione
Microsoft consiglia di guidare l'utilizzo in base alle tipologie di utenti più pronte per la distribuzione. In genere, ciò significa distribuire per gli utenti in questo ordine, ma questo può cambiare a seconda dell'organizzazione:
- Information worker
- Personale sul campo
- Professionisti IT/ruoli di lavoro DevOps
- Lavoratori altamente regolamentati
Usare le sezioni seguenti per creare comunicazioni con gli utenti finali per ogni gruppo di tipologia, ambito e implementazione della funzionalità di registrazione passkey e report e monitoraggio degli utenti per tenere traccia dello stato di implementazione.
Pianificare le comunicazioni dell'utente finale
Microsoft fornisce modelli di comunicazione per gli utenti finali. Il materiale di implementazione dell'autenticazione include modelli email personalizzabili per informare gli utenti sulla distribuzione dell'autenticazione senza password resistente al phishing. Usare i seguenti modelli per comunicare con gli utenti in modo che comprendano la distribuzione di autenticazione senza password resistente al phishing:
- Passkeys per l'assistenza tecnica
- Passkeys presto disponibile
- Registra per la Passkey dell'App Authenticator
- Promemoria per la registrazione per l' Passkey dell'app Authenticator
Le comunicazioni devono essere ripetute più volte per consentire di intercettare il maggior numero possibile di utenti. Ad esempio, l'organizzazione può scegliere di comunicare le diverse fasi e timeline con un modello simile al seguente:
- 60 giorni prima dell'applicazione: comunicare il valore dei metodi di autenticazione resistenti al phishing e incoraggiare gli utenti a registrarsi proattivamente
- 45 giorni prima dell'applicazione: ripetere il messaggio
- 30 giorni prima dell'applicazione: comunicare che entro 30 giorni inizierà l'applicazione dell'autenticazione resistente al phishing e incoraggiare gli utenti a registrarsi proattivamente
- 15 giorni prima dell'applicazione: ripetere il messaggio e informare gli utenti su come contattare l'help desk
- 7 giorni prima dell'applicazione: ripetere il messaggio e informare gli utenti su come contattare l'help desk
- 1 giorno prima dell'applicazione: informare gli utenti che l'applicazione avverrà entro 24 ore e fornire istruzioni su come contattare l'help desk
Microsoft consiglia di comunicare agli utenti tramite altri canali oltre alla semplice email. Altre opzioni possono includere messaggi di Microsoft Teams, poster nelle sale relax e programmi campione in cui i dipendenti selezionati sono addestrati a sostenere il programma ai propri colleghi.
Monitoraggio e creazione di report
I report di Microsoft Entra ID (ad esempio Attività dei metodi di autenticazione e Dettagli dell'evento di accesso per l'autenticazione a più fattori di Microsoft Entra) forniscono approfondimenti tecnici e aziendali che consentono di misurare e promuovere l'adozione.
Dal dashboard Attività dei metodi di autenticazione è possibile visualizzare la registrazione e l'utilizzo.
- La registrazione mostra il numero di utenti in grado di eseguire l'autenticazione senza password resistente al phishing e altri metodi di autenticazione. È possibile visualizzare grafici che mostrano i metodi di autenticazione registrati dagli utenti e la registrazione recente per ogni metodo.
- L'utilizzo mostra i metodi di autenticazione usati per l'accesso.
I proprietari di applicazioni aziendali e tecniche devono possedere e ricevere report in base ai requisiti dell'organizzazione.
- Tenere traccia dell'implementazione delle credenziali senza password resistenti al phishing con i report sulle attività di registrazione dei metodi di autenticazione.
- Tenere traccia dell'adozione di credenziali senza password resistenti al phishing con i report sulle attività di accesso dei metodi di autenticazione e con i log di accesso.
- Usare il report delle attività di accesso per tenere traccia dei metodi di autenticazione usati per accedere alle varie applicazioni. Selezionare la riga dell'utente; selezionare Dettagli autenticazione per visualizzare il metodo di autenticazione e l'attività di accesso corrispondente.
Microsoft Entra ID aggiunge voci ai log di controllo quando si verificano queste condizioni:
- Un amministratore modifica i metodi di autenticazione.
- Un utente apporta qualsiasi tipo di modifica alle proprie credenziali all'interno di Microsoft Entra ID.
Microsoft Entra ID conserva la maggior parte dei dati di controllo per 30 giorni. Consigliamo una conservazione prolungata per il controllo, l'analisi delle tendenze e altre esigenze aziendali.
Accedere ai dati di controllo nell'interfaccia di amministrazione o nell'API di Microsoft Entra e scaricarli nei sistemi di analisi. Se è necessaria una conservazione più lunga, esportare e utilizzare i log in uno strumento Security Information and Event Management (SIEM), ad esempio Microsoft Sentinel, Splunk o Sumo Logic.
Monitorare il volume dei ticket dell'help desk
L'help desk IT può fornire un segnale prezioso sull'avanzamento della distribuzione, perciò Microsoft consiglia di tenere traccia del volume dei ticket dell'help desk durante l'esecuzione di una distribuzione di autenticazione senza password resistente al phishing.
Man mano che il volume dei ticket dell'help desk aumenta, è necessario rallentare il ritmo delle distribuzioni, delle comunicazioni degli utenti e delle azioni di applicazione. Man mano che il volume del ticket diminuisce, è possibile riprendere queste attività. L'uso di questo approccio richiede una maggiore flessibilità nel piano di implementazione.
Ad esempio, è possibile eseguire le distribuzioni e quindi le applicazioni in cicli con intervalli di date anziché date specifiche:
- 1 - 15 giugno: Ciclo 1 di distribuzione e campagne di registrazione della coorte
- 16 - 30 giugno: Ciclo 2 di distribuzione e campagne di registrazione della coorte
- 1 - 15 luglio: Ciclo 3 di distribuzione e campagne di registrazione della coorte
- 16 - 31 luglio: abilitazione dell'applicazione per la coorte del Ciclo 1
- 1 - 15 agosto: abilitazione dell'applicazione per la coorte del Ciclo 2
- 16 - 31 agosto: abilitazione dell'applicazione per la coorte del Ciclo 3
Durante l'esecuzione di queste diverse fasi, potrebbe essere necessario rallentare a seconda del volume di ticket help desk aperti e quindi riprendere quando il volume è diminuito. Per eseguire questa strategia, Microsoft consiglia di creare un gruppo di sicurezza Microsoft Entra ID per ogni ciclo e di aggiungere ogni gruppo ai criteri uno alla volta. Questo approccio consente di evitare di sovraccaricare i team di supporto.
Applicare metodi resistenti al phishing per l'accesso
Questa sezione è incentrata sulla fase 4.
La fase finale di una distribuzione di autenticazione senza password resistente al phishing consiste nell'applicare l'uso di credenziali resistenti al phishing. Il meccanismo principale per eseguire questa operazione in Microsoft Entra ID è l'uso dei livelli di autenticazione dell'accesso condizionale. Microsoft consiglia di adottare l'applicazione per ogni tipologia in base a una metodologia di coppia utente/dispositivo. Ad esempio, un'implementazione dell'applicazione potrebbe seguire questo modello:
- Information Worker in Windows e iOS
- Information Worker in macOS e Android
- Professionisti IT in iOS e Android
- FLW in iOS e Android
- FLW in Windows e macOS
- Professionisti IT in Windows e macOS
Microsoft consiglia di creare un report di tutti le coppie utente/dispositivo usando i dati di accesso del tenant. È possibile usare strumenti di query come Monitoraggio di Azure e Cartelle di lavoro. Al minimo, provare a identificare tutti le coppie utente/dispositivo che corrispondono a queste categorie.
Per ogni utente, creare un elenco dei sistemi operativi che usa regolarmente per il lavoro. Eseguire il mapping dell'elenco all'idoneità per l'applicazione dell'accesso resistente al phishing per la coppia utente/dispositivo.
| Tipo di sistema operativo | Pronto per l'applicazione | Non pronto per l'applicazione |
|---|---|---|
| Windows | 10+ | 8.1 e versioni precedenti, Windows Server |
| iOS | 17+ | 16 e versioni precedenti |
| Android | 14+ | 13 e versioni precedenti |
| macOS | 13+ (Ventura) | 12 e versioni precedenti |
| VDI | Dipende1 | Dipende1 |
| Altro | Dipende1 | Dipende1 |
1Per ogni coppia utente/dispositivo in cui la versione del dispositivo non è immediatamente pronta per l'imposizione, determinare come risolvere la necessità di applicare la resistenza al phishing. Considerare le opzioni seguenti per i sistemi operativi meno recenti, l'infrastruttura Virtual Desktop Infrastructure (VDI) e altri sistemi operativi, ad esempio Linux:
- Applicare la resistenza al phishing usando hardware esterno: chiavi di sicurezza FIDO2
- Applicare la resistenza al phishing usando hardware esterno: smart card
- Applicare la resistenza al phishing usando credenziali remote, ad esempio passkey, nel flusso di autenticazione tra dispositivi
- Applicare la resistenza al phishing usando credenziali remote all'interno di tunnel RDP (in particolare per VDI)
L'attività principale consiste nel misurare attraverso i dati quali utenti, e relative tipologie, sono pronti per l'applicazione in determinate piattaforme. Iniziare le azioni di applicazione sulle coppie utente/dispositivo pronte per l'applicazione per "fermare l'emorragia" e ridurre la quantità di autenticazioni vulnerabili al phishing che si verificano nell'ambiente.
Passare, quindi, ad altri scenari in cui le coppie utente/dispositivo richiedono attività di idoneità. Procedere attraverso l'elenco di coppie utente/dispositivo fino a implementare l'autenticazione resistente al phishing su tutta la linea.
Creare un set di gruppi Microsoft Entra ID per implementare gradualmente l'applicazione. Riutilizzare i gruppi del passaggio precedente se è stato usato l'approccio di implementazione a cicli.
Specificare come destinazione ogni gruppo con criteri di accesso condizionale specifici. Questo approccio consente di implementare gradualmente i controlli di applicazione in base alla coppia utente/dispositivo.
| Criteri | Nome del gruppo di destinazione nei criteri | Criteri: condizione per le piattaforme del dispositivo | Criteri: concedere il controllo |
|---|---|---|---|
| 1 | Utenti Windows pronti per l'autenticazione senza password resistente al phishing | Windows | Richiedere livello di autenticazione: MFA resistente al phishing |
| 2 | Utenti macOS pronti per l'autenticazione senza password resistente al phishing | macOS | Richiedere livello di autenticazione: MFA resistente al phishing |
| 3 | Utenti iOS pronti per l'autenticazione senza password resistente al phishing | iOS | Richiedere livello di autenticazione: MFA resistente al phishing |
| 4 | Utenti Android pronti per l'autenticazione senza password resistente al phishing | Android | Richiedere livello di autenticazione: MFA resistente al phishing |
| 5 | Utenti di altro tipo pronti per l'autenticazione senza password resistente al phishing | Qualsiasi ad eccezione di Windows, macOS, iOS o Android | Richiedere livello di autenticazione: MFA resistente al phishing |
Aggiungere ogni utente a ogni gruppo quando si determina se il dispositivo e il sistema operativo sono pronti o se non hanno un dispositivo di quel tipo. Alla fine dell'implementazione, ogni utente deve trovarsi in uno dei gruppi.
Rispondere al rischio per gli utenti senza password
Microsoft Entra ID Protection consente alle organizzazioni di rilevare, analizzare e correggere i rischi basati sull'identità. Microsoft Entra ID Protection fornisce rilevamenti importanti e utili per gli utenti anche dopo il passaggio all'uso di credenziali senza password resistenti al phishing. Ad esempio, alcuni rilevamenti significativi per gli utenti con autenticazione resistente al phishing includono:
- Attività da un indirizzo IP anonimo
- L'amministratore ha confermato che l'utente è compromesso
- Token anomalo
- Indirizzo IP dannoso
- Intelligence sulle minacce per Microsoft Entra
- Browser sospetto
- Utenti malintenzionati
- Possibile tentativo di accesso al token di aggiornamento primario (PRT)
- Altri: rilevamenti dei rischi mappati a riskEventType
Microsoft consiglia ai clienti di Microsoft Entra ID Protection di eseguire le azioni seguenti per proteggere al meglio gli utenti con autenticazione senza password resistente al phishing:
- Verificare le linee guida per la distribuzione di Microsoft Entra ID Protection: Pianificare una distribuzione di ID Protection
- Configurare i log di rischio per l'esportazione in un SIEM
- Indagare e agire su qualsiasi rischio utente di livello medio
- Configurare un criterio di accesso condizionale per bloccare gli utenti ad alto rischio
Dopo aver distribuito Microsoft Entra ID Protection, è consigliabile usare la protezione con token dell'accesso condizionale. Man mano che gli utenti accedono con credenziali senza password resistenti al phishing, gli attacchi e i rilevamenti continuano a evolversi. Ad esempio, quando le credenziali utente non possono più essere facilmente sottratte tramite phishing, gli utenti malintenzionati potrebbero provare a esfiltrare i token dai dispositivi degli utenti. La protezione con token consente di ridurre questo rischio associando i token all'hardware del dispositivo a cui sono stati rilasciati.