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.
| Persona utente | Descrizione |
|---|---|
| Lavoratori dell'informazione | |
| Personale sul campo | |
| Professionisti IT/professionisti 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 "non lasciare che il migliore sia nemico del bene" e implementa le credenziali sicure il più possibile. 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 |
|---|---|---|
| Portatile | 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. |
| Locale | È 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 avviamento prende in carico un utente senza credenziali aziendali esistenti e verifica la sua identità. Avvia la creazione delle loro prime credenziali portatili e utilizza queste credenziali portatili per inizializzare altre credenziali locali su ciascuno dei loro dispositivi informatici. 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 alla modalità senza password resistente al phishing direttamente sui propri dispositivi esistenti, o di utilizzare le credenziali MFA esistenti per inizializzare le 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. Se sei un amministratore che implementa una soluzione senza password resistente agli attacchi di phishing per utenti esistenti, puoi passare direttamente al Passaggio 2 dell'onboarding: configurazione iniziale 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 ad auto-registrarsi per credenziali forti, è 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 per includere le linee guida per le passkey sincronizzate non appena disponibili. Ad esempio, molte organizzazioni possono trarre vantaggio dall'affidarsi alla sincronizzazione per la fase 3 nel diagramma precedente anziché inizializzare 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 il Controllo del volto con Microsoft Entra ID verificato, che aggiunge un livello di corrispondenza facciale alla verifica, assicurandosi che l'utente attendibile stia presentando in quel momento l'ID verificato che conferma l'identità.
Dopo aver verificato la propria identità tramite il processo di verifica, ai nuovi assunti viene assegnato un pass di accesso temporaneo (TAP) che possono usare per avviare le loro prime credenziali portatili.
Fare riferimento alle guide seguenti per abilitare l'integrazione di Microsoft Entra Verified ID e l'emissione 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:
- Controllo del volto con i prezzi di ID verificato di Microsoft Entra
- Piani e prezzi di Microsoft Entra
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: inizializzare una credenziale portatile
Per avviare gli utenti esistenti con credenziali senza password resistenti al phishing, determina prima di tutto se sono già registrati per l'autenticazione a più fattori tradizionale. Gli utenti con metodi di MFA tradizionali registrati possono essere soggetti a politiche 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 del TAP dal passaggio 1 per registrare credenziali portatili che possano eseguire il bootstrap di queste altre credenziali consente all'utente di utilizzare credenziali resistenti al phishing in modo nativo sui numerosi dispositivi che potrebbe possedere.
La tabella seguente elenca le raccomandazioni per le diverse tipologie:
| Persona utente | Credenziali portabili consigliate | Credenziali portabili alternative |
|---|---|---|
| Operatore dell'informazione | Passkey (app di autenticazione) | Chiave di sicurezza, smart card |
| Lavoratore in prima linea | Chiave di sicurezza | Passkey (app di autenticazione), smart card |
| Professionista IT/Ruolo di lavoro DevOps | Authenticator (app Passkey) | Chiave di sicurezza, smart card |
| Lavoratore altamente regolamentato | Certificato (carta intelligente) | 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 |
|---|---|
| Chiavi di accesso | |
| Chiavi di sicurezza | |
| Autenticazione basata su smart card/certificato (CBA) |
Passaggio 3 dell'onboarding: configurare le credenziali locali sui dispositivi informatici
Dopo che gli utenti hanno registrato le credenziali portabili, sono pronti per avviare altre credenziali su ogni dispositivo che usano regolarmente in un rapporto uno a uno, il che offre vantaggi alla loro esperienza 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:
| Persona utente | Credenziali locali consigliate - Windows | Credenziali locali consigliate - macOS | Credenziali locali consigliate - iOS | Credenziali locali consigliate - Android | Credenziali locali consigliate - Linux |
|---|---|---|---|---|---|
| Operatore dell'informazione | Windows Hello for Business | Chiave per l'Enclave Sicura della Piattaforma Single Sign-On (SSO) | Passkey (l'app Authenticator) | Passkey (app Autenticatore) | N/D (usare invece credenziali portabili) |
| Lavoratore in prima linea | 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 dell'enclave sicura SSO della piattaforma | Passkey (app di autenticazione) | Passkey (app Autenticatore) | N/D (usare invece credenziali portabili) |
| Lavoratore altamente regolamentato | Windows Hello for Business o CBA | Chiave della SSO della Piattaforma dell'Enclave Sicura o CBA | Passkey (applicazione Authenticator) o CBA | Passkey (app Authenticator) o autenticazione basata su certificati | N/D (usare invece la carta intelligente) |
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 SSO della piattaforma dell'enclave sicura | |
| Chiavi di accesso |
Considerazioni specifiche per persona
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:
- Lavoratori dell'informazione
- Personale sul campo
- Professionisti IT/lavoratori 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.
- Misura l'implementazione della registrazione per gli utenti pilota utilizzando 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 il successo dell'implementazione utilizzando Azure Monitor e Workbooks.
- 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:
- Lavoratori dell'informazione
- Personale sul campo
- Professionisti IT/lavoratori DevOps
- Lavoratori altamente regolamentati
Usare le sezioni seguenti per creare comunicazioni con gli utenti finali per ogni gruppo di persona, ambiti e distribuzione della funzione di registrazione delle passkey e utilizzare report e monitoraggio per tenere traccia dello stato di avanzamento dell'implementazione.
Guida alla preparazione con il Manuale senza password resistente al phishing (anteprima)
Le organizzazioni possono scegliere di esportare i log di accesso di Microsoft Entra ID in Azure Monitor per la conservazione a lungo termine, la ricerca delle minacce e altri scopi. Microsoft ha rilasciato una cartella di lavoro che le organizzazioni che hanno registri in Azure Monitor possono usare per facilitare varie fasi di una distribuzione senza password resistente al phishing. È possibile accedere alla cartella di lavoro senza password Phishing-Resistant qui: aka.ms/PasswordlessWorkbook. Scegliere la cartella di lavoro denominata Phishing-Resistant Distribuzione senza password (anteprima):
La cartella di lavoro include due sezioni principali:
- Fase di preparazione della registrazione
- Fase di preparazione per l'attuazione
Fase di preparazione della registrazione
Usare la scheda Fase di preparazione della registrazione per analizzare i log di accesso nel tenant, determinare quali utenti sono pronti per la registrazione e quali utenti potrebbero essere bloccati dalla registrazione. Ad esempio, con la scheda Fase di preparazione della registrazione è possibile selezionare iOS come piattaforma del sistema operativo e quindi Il passkey dell'app Authenticator come tipo di credenziale per cui si vuole valutare l'idoneità. È quindi possibile fare clic sulle visualizzazioni della cartella di lavoro per filtrare in base agli utenti che devono avere problemi di registrazione ed esportare l'elenco:
La scheda Fase di preparazione all'iscrizione del foglio di lavoro ti aiuta a valutare la prontezza per i seguenti sistemi operativi e credenziali:
- Windows
- Windows Hello for Business
- Chiave di sicurezza FIDO2
- Passkey dell'Authenticator App
- Autenticazione basata su certificato / Smart Card
- macOS
- Chiave dell'enclave sicura della piattaforma SSO
- Chiave di sicurezza FIDO2
- Passkey dell'Authenticator App
- Autenticazione Basata su Certificato / Smart Card
- iOS
- Chiave di sicurezza FIDO2
- Passkey dell'Authenticator App
- Autenticazione Basata su Certificato / Smart Card
- Android
- Chiave di sicurezza FIDO2
- Passkey dell'app di autenticazione
- Autenticazione basata su certificato / Smart Card
Usare ogni elenco esportato per valutare gli utenti che potrebbero avere problemi di registrazione. Le risposte ai problemi di registrazione devono includere l'assistenza degli utenti nell'aggiornamento delle versioni del sistema operativo del dispositivo, la sostituzione dei dispositivi invecchiati e la scelta di credenziali alternative in cui l'opzione preferita non è valida. Ad esempio, l'organizzazione può scegliere di fornire chiavi di sicurezza FIDO2 fisiche agli utenti Android 13 che non possono usare Passkey nell'app Microsoft Authenticator.
Analogamente, utilizzare il report di preparazione all'iscrizione per facilitare la creazione di elenchi di utenti pronti per iniziare le comunicazioni e le campagne di iscrizione, in linea con la vostra strategia complessiva di lancio .
Fase di preparazione all'attuazione
Il primo passaggio della fase di preparazione all'applicazione consiste nel creare una politica di Accesso Condizionale in modalità Report-Only. Questo criterio popola i log di accesso con dati sull'eventualità che l'accesso venga bloccato se si includessero utenti/dispositivi negli ambiti per l'applicazione di misure resistenti al phishing. Creare un nuovo criterio di accesso condizionale nel tenant con queste impostazioni:
| Impostazione | Valore |
|---|---|
| Assegnazione di utenti/gruppi | Tutti gli utenti, esclusi gli account "break glass" |
| Assegnazione di app | Tutte le risorse |
| Controlli delle autorizzazioni | Richiedi livello di autenticazione - MFA resistente al phishing |
| Abilitare la politica | Solo rapporto |
Crea questo criterio il prima possibile durante il rollout, preferibilmente prima di iniziare le campagne di registrazione. In questo modo si avrà un buon set di dati storico di quali utenti e accessi sarebbero stati bloccati dalla politica se fosse stata applicata.
Quindi, usa la cartella di lavoro per analizzare dove le coppie utente/dispositivo sono pronte per la messa in atto. scaricare elenchi di utenti pronti per l'applicazione e aggiungerli ai gruppi creati in linea con le tue politiche di applicazione . Per iniziare, selezionare i criteri di accesso condizionale di sola lettura nel filtro dei criteri:
Il report fornirà un elenco di utenti che sarebbero stati in grado di superare correttamente il requisito di accesso senza password resistente al phishing su ogni piattaforma del dispositivo. Scaricare ogni elenco e inserire gli utenti appropriati nel gruppo di imposizione allineato alla piattaforma del dispositivo.
Screenshot della fase di applicazione dell'elenco di utenti del workbook senza password resistente al phishing pronti per l'applicazione.
Ripetere questo processo nel tempo fino a raggiungere il punto in cui ogni gruppo di imposizione contiene la maggior parte o tutti gli utenti. Alla fine, si dovrebbe essere in grado di abilitare i criteri di sola segnalazione per applicare le regole per tutti gli utenti e le piattaforme dei dispositivi nel tenant. Dopo aver raggiunto questo stato completato, è possibile rimuovere i singoli criteri di imposizione per ogni sistema operativo del dispositivo, riducendo il numero di criteri di accesso condizionale necessari.
Indagine degli utenti non pronti per l'attuazione
Usare la scheda Analisi dei dati aggiuntivi per esaminare il motivo per cui alcuni utenti non sono pronti per l’implementazione su varie piattaforme. Selezionare la casella di Politica non soddisfatta per filtrare i dati in base agli accessi utente che sarebbero stati bloccati dai criteri di accesso condizionale in modalità solo report.
Usare i dati forniti da questo report per determinare quali utenti sarebbero stati bloccati, quali sistemi operativi dei dispositivi erano presenti, il tipo di app client in uso e le risorse a cui tentavano di accedere. Questi dati dovrebbero aiutarti a indirizzare questi utenti verso varie azioni di rimedio o di registrazione, in modo che possano essere inseriti efficacemente nell'ambito di attuazione.
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:
- Chiavi di accesso per l'assistenza tecnica
- Presto disponibili passkeys
- Registrati per la Passkey dell'App Authenticator
- Promemoria per registrarsi alla funzione 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: ripeti il messaggio
- 30 giorni prima dell'attuazione: comunicare che tra 30 giorni inizierà l'applicazione di misure resistenti al phishing e incoraggiare gli utenti a iscriversi per tempo.
- 15 giorni prima dell'attuazione: ripetere il messaggio precedente e informare gli utenti su come contattare il help desk
- 7 giorni prima dell'attuazione: ripetere il messaggio, informandoli su come contattare il servizio di assistenza
- 1 giorno prima dell'esecuzione: informare gli utenti che l'esecuzione avverrà entro 24 ore e fornire istruzioni su come contattare l'assistenza
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
Usa la cartella di lavoro senza password coperta in precedenza Phishing-Resistant per assistere nel monitoraggio e nella creazione di report sull'implementazione. Usare anche i report illustrati di seguito o basarsi su di essi se non è possibile usare la Phishing-Resistant cartella di lavoro senza password.
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 agli utenti e delle azioni di implementazione. Man mano che il volume dei ticket diminuisce, è possibile intensificare nuovamente queste attività. L'uso di questo approccio richiede una maggiore flessibilità nel piano di implementazione.
Ad esempio, puoi eseguire le distribuzioni e quindi le imposizioni a ondate con intervalli di date anziché date specifiche.
- 1-15 giugno: Distribuzione e campagne di iscrizione della prima coorte
- 16 - 30 giugno: Implementazione e campagne di registrazione della coorte Ciclo 2
- Dal 1° al 15 luglio: Distribuzione della Fase 3 e campagne di registrazione delle coorti
- 16 - 31 luglio: abilitazione dell'applicazione per la coorte del Ciclo 1
- 1 - 15 agosto: attivazione delle misure per la coorte della seconda ondata
- 16–31 agosto: attivazione dell'applicazione per la coorte dell'Ondata 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 è la robustezza dell'autenticazione dell'accesso condizionale. Microsoft consiglia di applicare le policy per ciascuna persona in base a una metodologia di coppia utente/dispositivo. Ad esempio, un'implementazione di un provvedimento può seguire questo modello:
- Lavoratori dell'informazione su Windows e iOS
- Operatori dell'informazione su macOS e Android
- Professionisti IT in iOS e Android
- FLW in iOS e Android
- FLWs su 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.
Utilizzare la cartella di lavoro Passwordless Phishing-Resistant descritta in precedenza per agevolare la fase di applicazione, se possibile.
Per ogni utente, creare un elenco dei sistemi operativi che usa regolarmente per il lavoro. Associare l'elenco alla prontezza all'applicazione di misure di accesso resistenti al phishing per la coppia utente/dispositivo in questione.
| Tipo di sistema operativo | Pronto per l'applicazione | Non pronto per l'esecuzione |
|---|---|---|
| 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 enforcement sulle coppie utente/dispositivo pronte per l'attuazione per bloccare la perdita 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 delle regole. Se hai utilizzato la strategia di distribuzione a ondate, riutilizza i gruppi del passaggio precedente.
Criteri di applicazione dell'accesso condizionale consigliati
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.
| Politica | Nome del gruppo mirato nella politica | Politica - Condizione della piattaforma del dispositivo | Politica – concedere il controllo |
|---|---|---|---|
| 1 | Utenti Windows pronti senza password e resistenti al phishing | Windows | Richiedere livello di autenticazione: MFA resistente al phishing |
| 2 | Utenti macOS pronti per un uso senza password e resistente al phishing | macOS | Richiedere livello di autenticazione: MFA resistente al phishing |
| 3 | Utenti iOS pronti per un'esperienza senza password e resistenti al phishing | iOS | Richiedere livello di autenticazione: MFA resistente al phishing |
| 4 | Utenti Android pronti per un'autenticazione senza password e resistente al phishing | Android | Richiedere livello di autenticazione: MFA resistente al phishing |
| 5 | Altri utenti pronti per un'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
- Intelligenza su minacce di Microsoft Entra
- Browser sospetto
- Utenti malintenzionati
- Possibile tentativo di accesso al token di aggiornamento primario (PRT)
- Altri: Rilevamenti di rischio mappati su 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.