Pianificare una distribuzione di Protezione ID
Microsoft Entra ID Protection rileva rischi basati sull'identità, li segnala e consente agli amministratori di analizzare e correggere questi rischi per proteggere e proteggere le organizzazioni. I rischi possono essere ulteriormente inseriti in strumenti come l'accesso condizionale per prendere decisioni di accesso o reinserci in uno strumento SIEM (Security Information and Event Management) per ulteriori indagini.
Questo piano di distribuzione estende i concetti introdotti nel piano di distribuzione dell'accesso condizionale.
Prerequisiti
- Un tenant Microsoft Entra funzionante con Microsoft Entra ID P2 o una licenza di valutazione abilitata. Se necessario, crearne uno gratuitamente.
- Gli amministratori che interagiscono con Identity Protection devono avere una o più delle assegnazioni di ruolo seguenti a seconda delle attività eseguite. Per seguire il principio Zero Trust dei privilegi minimi, prendere in considerazione l'uso di Privileged Identity Management (PIM) per attivare le assegnazioni di ruolo con privilegi JIT.
- Leggere Identity Protection e criteri di accesso condizionale e configurazioni
- Gestire Identity Protection
- Creare o modificare criteri di accesso condizionale
- Un utente di test che non è un amministratore per verificare che i criteri funzionino come previsto prima della distribuzione agli utenti reali. Se è necessario creare un utente, vedere Guida introduttiva: Aggiungere nuovi utenti a Microsoft Entra ID.
- Gruppo a cui appartiene l'utente. Se è necessario creare un gruppo, vedere Creare un gruppo e aggiungere membri in Microsoft Entra ID.
Coinvolgere gli stakeholder appropriati
Quando i progetti tecnologici hanno esito negativo, in genere lo fanno a causa di aspettative non corrispondenti sull'impatto, sui risultati e sulle responsabilità. Per evitare queste insidie, assicurarsi di coinvolgere gli stakeholder giusti e che i ruoli degli stakeholder nel progetto siano ben compresi documentando gli stakeholder, l'input del progetto e la responsabilità.
Comunicazione della modifica
La comunicazione è fondamentale per il successo di qualsiasi nuova funzionalità. È consigliabile comunicare in modo proattivo con gli utenti come cambia l'esperienza , quando cambia e come ottenere supporto in caso di problemi.
Passaggio 1: Esaminare i report esistenti
È importante esaminare i report di Identity Protection prima di distribuire criteri di accesso condizionale basati sul rischio. Questa revisione offre l'opportunità di analizzare eventuali comportamenti sospetti esistenti. È possibile scegliere di ignorare il rischio o confermare questi utenti come sicuri se si determina che non sono a rischio.
- Analizzare i rilevamenti degli eventi di rischio
- Correggere i rischi e sbloccare gli utenti
- Apportare modifiche in blocco con Microsoft Graph PowerShell
Per garantire l'efficienza, è consigliabile consentire agli utenti di correggere automaticamente i criteri illustrati nel passaggio 3.
Passaggio 2: Pianificare i criteri di rischio di accesso condizionale
Identity Protection invia segnali di rischio all'accesso condizionale, per prendere decisioni e applicare criteri aziendali come la richiesta di autenticazione a più fattori o la modifica della password. Esistono diversi elementi che le organizzazioni devono pianificare prima di creare i criteri.
Esclusioni di criteri
I criteri di accesso condizionale sono strumenti potenti, ma è consigliabile escludere dai criteri i seguenti account:
- Gli account di accesso di emergenza o critici per impedire il blocco degli account a livello di tenant. Nell'improbabile scenario in cui tutti gli amministratori siano bloccati dal tenant, l'account di amministrazione con accesso di emergenza può essere utilizzato per accedere al tenant e ripristinare l'accesso.
- Altre informazioni sono disponibili nell'articolo Gestire gli account di accesso di emergenza in Microsoft Entra ID.
- Account del servizio e entità servizio, ad esempio l'account di sincronizzazione Microsoft Entra Connect. Gli account del servizio sono account non interattivi che non sono collegati a un utente specifico. Vengono in genere usati dai servizi back-end che consentono l'accesso a livello di codice alle applicazioni, ma vengono usati anche per accedere ai sistemi per scopi amministrativi. Gli account del servizio di questo tipo dovrebbero essere esclusi poiché l'autenticazione a più fattori non può essere eseguita a livello di codice. Le chiamate effettuate dalle entità servizio non verranno bloccate dai criteri di accesso condizionale con ambito utenti. Usare l'accesso condizionale per le identità identità dei carichi di lavoro al fine di definire criteri destinati alle entità servizio.
- Se l'organizzazione dispone di questi account in uso negli script o nel codice, è consigliabile sostituirli con identità gestite. Come soluzione alternativa temporanea, è possibile escludere questi account specifici dai criteri di base.
Autenticazione a più fattori
Per consentire agli utenti di correggere autonomamente i rischi, tuttavia, è necessario registrarsi per l'autenticazione a più fattori Di Microsoft Entra prima che diventino rischiosi. Per altre informazioni, vedere l'articolo Pianificare una distribuzione dell'autenticazione a più fattori di Microsoft Entra.
Percorsi di rete noti
È importante configurare posizioni denominate nell'accesso condizionale e aggiungere gli intervalli VPN alle app di Defender per il cloud. Gli accessi da posizioni denominate, contrassegnati come attendibili o noti, migliorano l'accuratezza dei calcoli dei rischi di Microsoft Entra ID Protection. Questi accessi consentono di ridurre il rischio di un utente quando eseguono l'autenticazione da una posizione contrassegnata come attendibile o nota. Questa procedura riduce i falsi positivi per alcuni rilevamenti nell'ambiente in uso.
Modalità solo report
La modalità solo report è uno stato dei criteri di accesso condizionale che consente agli amministratori di valutare l'effetto dei criteri di accesso condizionale prima di applicarli nel proprio ambiente.
Passaggio 3: Configurare i criteri
criteri di registrazione MFA di Identity Protection
Usare i criteri di registrazione dell'autenticazione a più fattori di Identity Protection per consentire agli utenti di registrare l'autenticazione a più fattori di Microsoft Entra prima di usarla. Seguire la procedura descritta nell'articolo Procedura: Configurare i criteri di registrazione dell'autenticazione a più fattori di Microsoft Entra per abilitare questo criterio.
Criteri di accesso condizionale
Rischio di accesso: la maggior parte degli utenti ha un comportamento normale che può essere monitorato, quando non rientrano in questa norma potrebbe essere rischioso consentire loro di accedere. Potrebbe essere necessario bloccare l'utente o chiedere loro di eseguire l'autenticazione a più fattori per dimostrare che sono realmente chi dicono di essere. Per iniziare, definire l'ambito di questi criteri in un subset degli utenti.
Rischio utente: Microsoft collabora con ricercatori, forze dell'ordine, vari team di sicurezza di Microsoft e altre fonti attendibili per trovare coppie nome utente e password perse. Quando questi utenti vulnerabili vengono rilevati, è consigliabile richiedere agli utenti di eseguire l'autenticazione a più fattori e quindi reimpostare la password.
L'articolo Configurare e abilitare i criteri di rischio fornisce indicazioni per creare criteri di accesso condizionale per risolvere questi rischi.
Passaggio 4: Monitoraggio e esigenze operative continue
Notifiche tramite posta elettronica
Abilitare le notifiche in modo da poter rispondere quando un utente viene contrassegnato come a rischio, in modo da poter iniziare immediatamente l'analisi. È anche possibile configurare messaggi di posta elettronica di digest settimanali, offrendo una panoramica del rischio per la settimana.
Monitorare e analizzare
La cartella di lavoro di Identity Protection consente di monitorare e cercare modelli nel tenant. Monitorare questa cartella di lavoro per individuare le tendenze e anche i risultati della modalità Solo report di accesso condizionale per verificare se sono presenti modifiche che devono essere apportate, ad esempio aggiunte a posizioni denominate.
Microsoft Defender per il cloud App fornisce un framework di indagine che le organizzazioni possono usare come punto di partenza. Per altre informazioni, vedere l'articolo Come analizzare gli avvisi di rilevamento anomalie.
È anche possibile usare le API di Identity Protection per esportare le informazioni sui rischi in altri strumenti, in modo che il team di sicurezza possa monitorare e avvisare gli eventi di rischio.
Durante i test, potrebbe essere necessario simulare alcune minacce per testare i processi di indagine.
Passaggi successivi
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per