Guida di riferimento alle operazioni di gestione dell'autenticazione di Microsoft Entra

Questa sezione della guida di riferimento alle operazioni di Microsoft Entra descrive i controlli e le azioni da eseguire per proteggere e gestire le credenziali, definire l'esperienza di autenticazione (AuthN), delegare l'assegnazione, misurare l'utilizzo e definire i criteri di accesso in base al comportamento di sicurezza aziendale.

Nota

Queste raccomandazioni sono aggiornate a partire dalla data di pubblicazione, ma possono cambiare nel tempo. Le organizzazioni devono valutare continuamente le procedure di identità man mano che i prodotti e i servizi Microsoft si evolvono nel tempo.

Processi operativi chiave

Assegnare proprietari alle attività principali

La gestione di Microsoft Entra ID richiede l'esecuzione continua di attività e processi operativi chiave, che potrebbero non far parte di un progetto di implementazione. È comunque importante configurare queste attività per ottimizzare l'ambiente. Le attività principali e i relativi proprietari consigliati includono:

Attività Proprietario
Gestire il ciclo di vita della configurazione dell'accesso Single Sign-On (SSO) in Microsoft Entra ID Team operativo IAM (Identity and Access Management)
Progettare criteri di accesso condizionale per le applicazioni Microsoft Entra Team di architettura di InfoSec
Archiviare l'attività di accesso in un sistema SIEM (Security Information and Event Management) Team operativo di InfoSec
Archiviare gli eventi di rischio in un sistema SIEM Team operativo di InfoSec
Valutare e analizzare i report di sicurezza Team operativo di InfoSec
Valutazione e analisi degli eventi di rischio Team operativo di InfoSec
Valutare e analizzare gli utenti contrassegnati per i report di rischio e vulnerabilità da Microsoft Entra ID Protection Team operativo di InfoSec

Nota

Microsoft Entra ID Protection richiede una licenza Microsoft Entra ID P2. Per trovare la licenza corretta per i propri requisiti, vedere Confronto delle funzionalità disponibili a livello generale delle edizioni Microsoft Entra ID Free e Microsoft Entra ID P1 o P2.

Quando si esamina l'elenco, potrebbe essere necessario assegnare un proprietario per le attività che mancano a un proprietario o modificare la proprietà per le attività con proprietari non allineati alle raccomandazioni precedenti.

Gestione di credenziali

Criteri per la password

La gestione sicura delle password è una delle parti più critiche di Gestione delle identità e degli accessi e spesso il più grande obiettivo degli attacchi. Microsoft Entra ID supporta diverse funzionalità che consentono di impedire la riuscita di un attacco.

Usare la tabella seguente per trovare la soluzione consigliata per attenuare il problema che deve essere risolto:

Problema Elemento consigliato
Nessun meccanismo per la protezione da password vulnerabili Abilitare la reimpostazione della password self-service di Microsoft Entra ID (SSPR) e la protezione password
Nessun meccanismo per rilevare le password perse Abilitare la sincronizzazione dell'hash delle password (PHS) per ottenere informazioni dettagliate
Utilizzo di AD FS e impossibilità di passare all'autenticazione gestita Abilitare il blocco intelligente extranet di AD FS e/o Microsoft Entra Smart Lockout
I criteri password usano regole basate su complessità, ad esempio lunghezza, più set di caratteri o scadenza Riconsiderare a favore delle procedure consigliate microsoft e passare all'approccio alla gestione delle password e distribuire la protezione delle password di Microsoft Entra.
Gli utenti non sono registrati per l'uso dell'autenticazione a più fattori Registrare tutte le informazioni di sicurezza dell'utente in modo che possa essere usato come meccanismo per verificare l'identità dell'utente insieme alla password
Non esiste alcuna revoca delle password in base al rischio utente Distribuire i criteri di rischio utente di Microsoft Entra Identity Protection per forzare le modifiche delle password alle credenziali perse usando la reimpostazione della password self-service
Non esiste alcun meccanismo di blocco intelligente per proteggere l'autenticazione dannosa da attori malintenzionati provenienti da indirizzi IP identificati Distribuire l'autenticazione gestita dal cloud con la sincronizzazione dell'hash delle password o l'autenticazione pass-through

Abilitare la reimpostazione della password self-service e la protezione password

Gli utenti che devono modificare o reimpostare le password sono una delle principali fonti di volume e costi delle chiamate all'help desk. Oltre ai costi, la modifica della password come strumento per ridurre il rischio utente è un passaggio fondamentale per migliorare il comportamento di sicurezza dell'organizzazione.

È consigliabile distribuire almeno la reimpostazione della password self-service di Microsoft Entra ID e la protezione password locale per eseguire le operazioni seguenti:

  • Rinviare le chiamate all'help desk.
  • Sostituire l'uso delle password temporanee.
  • Sostituire qualsiasi soluzione di gestione delle password self-service esistente che si basa su una soluzione locale.
  • Eliminare le password vulnerabili nell'organizzazione.

Nota

Per le organizzazioni con una sottoscrizione microsoft Entra ID P2, è consigliabile distribuire la reimpostazione della password self-service e usarla come parte di un criterio di rischio utente di Identity Protection.

Gestione avanzata delle credenziali

Le password da soli non sono sufficientemente sicure per impedire agli attori malintenzionati di ottenere l'accesso all'ambiente. È necessario abilitare almeno qualsiasi utente con un account con privilegi per l'autenticazione a più fattori. Idealmente, è consigliabile abilitare la registrazione combinata e richiedere a tutti gli utenti di registrarsi per l'autenticazione a più fattori e la reimpostazione della password self-service usando l'esperienza di registrazione combinata. Alla fine, è consigliabile adottare una strategia per fornire resilienza per ridurre il rischio di blocco a causa di circostanze impreviste.

Combined user experience flow

Resilienza dell'autenticazione dell'interruzione locale

Oltre ai vantaggi della semplicità e dell'abilitazione del rilevamento delle credenziali perse, Microsoft Entra Password Hash Sync (PHS) e l'autenticazione a più fattori Microsoft Entra consentono agli utenti di accedere alle applicazioni SaaS (Software as a Service) e a Microsoft 365 nonostante le interruzioni locali a causa di attacchi informatici come NotPetya. È anche possibile abilitare PHS insieme alla federazione. L'abilitazione di PHS consente un fallback dell'autenticazione quando i servizi federatibili non sono disponibili.

Se l'organizzazione locale non ha una strategia di resilienza di interruzione o ha una strategia di resilienza non integrata con Microsoft Entra ID, è consigliabile distribuire Microsoft Entra PHS e definire un piano di ripristino di emergenza che include PHS. L'abilitazione di Microsoft Entra PHS consentirà agli utenti di eseguire l'autenticazione con Microsoft Entra ID qualora il Active Directory locale non sia disponibile.

password hash sync flow

Per comprendere meglio le opzioni di autenticazione, vedere Scegliere il metodo di autenticazione appropriato per la soluzione di gestione delle identità ibrida Di Microsoft Entra.

Utilizzo programmatico delle credenziali

Gli script di Microsoft Entra ID che usano PowerShell o le applicazioni che usano l'API Microsoft Graph richiedono l'autenticazione sicura. La gestione delle credenziali insufficienti che eseguono tali script e strumenti aumentano il rischio di furto di credenziali. Se si usano script o applicazioni che si basano su password hardcoded o richieste di password, è necessario prima esaminare le password nei file di configurazione o nel codice sorgente, quindi sostituire tali dipendenze e usare identità gestite di Azure, autenticazione integrata di Windows o certificati quando possibile. Per le applicazioni in cui le soluzioni precedenti non sono possibili, è consigliabile usare Azure Key Vault.

Se si determina che sono presenti entità servizio con credenziali password e non si è certi del modo in cui tali credenziali password sono protette da script o applicazioni, contattare il proprietario dell'applicazione per comprendere meglio i modelli di utilizzo.

Microsoft consiglia anche di contattare i proprietari delle applicazioni per comprendere i modelli di utilizzo se sono presenti entità servizio con credenziali password.

Esperienza di autenticazione

Autenticazione locale

L'autenticazione federata con autenticazione integrata autenticazione di Windows (IWA) o l'autenticazione gestita SSO (Seamless Single Sign-On) con sincronizzazione hash delle password o autenticazione pass-through è l'esperienza utente migliore quando si trova all'interno della rete aziendale con i controller di dominio locali. Riduce al minimo l'affaticamento della richiesta di credenziali e riduce il rischio che gli utenti cadano prede agli attacchi di phishing. Se si usa già l'autenticazione gestita dal cloud con PHS o PTA, ma gli utenti devono comunque digitare la password durante l'autenticazione locale, è necessario distribuire immediatamente l'accesso Single Sign-On facile. D'altra parte, se si è attualmente federati con piani per la migrazione all'autenticazione gestita dal cloud, è necessario implementare Seamless SSO come parte del progetto di migrazione.

Criteri di accesso attendibilità dei dispositivi

Come gli utenti dell'organizzazione, anche i dispositivi rappresentano identità importanti da proteggere. È possibile usare l'identità di un dispositivo per proteggere le risorse in qualsiasi momento e da qualunque posizione. L'autenticazione del dispositivo e la contabilità del tipo di attendibilità migliora il comportamento di sicurezza e l'usabilità:

  • Evitare l'attrito, ad esempio, con l'autenticazione a più fattori, quando il dispositivo è attendibile
  • Blocco dell'accesso da dispositivi non attendibili
  • Per i dispositivi Windows 10, fornire facilmente l'accesso Single Sign-On alle risorse locali.

È possibile eseguire questo obiettivo portando le identità dei dispositivi e gestirle in Microsoft Entra ID usando uno dei metodi seguenti:

  • Le organizzazioni possono usare Microsoft Intune per gestire il dispositivo e applicare criteri di conformità, attestare l'integrità dei dispositivi e impostare criteri di accesso condizionale in base alla conformità del dispositivo. Microsoft Intune può gestire i dispositivi iOS, i desktop Mac (tramite l'integrazione JAMF), i desktop Windows (in modo nativo usando Mobile Gestione dispositivi per Windows 10 e la co-gestione con Microsoft Configuration Manager) e i dispositivi mobili Android.
  • Microsoft Entra hybrid join fornisce la gestione con Criteri di gruppo o Microsoft Configuration Manager in un ambiente con i dispositivi computer aggiunti a un dominio di Active Directory. Le organizzazioni possono distribuire un ambiente gestito tramite PHS o PTA con Seamless SSO. L'uso dei dispositivi in Microsoft Entra ID ottimizza la produttività degli utenti tramite l'accesso Single Sign-On tra le risorse cloud e locali, consentendo allo stesso tempo di proteggere l'accesso alle risorse cloud e locali con l'accesso condizionale.

Se sono presenti dispositivi Windows aggiunti a un dominio non registrati nel cloud o dispositivi Windows aggiunti a un dominio registrati nel cloud ma senza criteri di accesso condizionale, è necessario registrare i dispositivi non registrati e, in entrambi i casi, usare l'aggiunta ibrida a Microsoft Entra come controllo nei criteri di accesso condizionale.

A screenshot of grant in Conditional Access policy requiring hybrid device

Se si gestiscono i dispositivi con MDM o Microsoft Intune, ma non si usano i controlli dei dispositivi nei criteri di accesso condizionale, è consigliabile usare Richiedi che il dispositivo sia contrassegnato come conforme come controllo in tali criteri.

A screenshot of grant in Conditional Access policy requiring device compliance

Windows Hello for Business (Configurare Windows Hello for Business)

In Windows 10 Windows Hello for Business sostituisce le password con l'autenticazione a due fattori avanzata nei PC. Windows Hello for Business consente un'esperienza di autenticazione a più fattori più semplificata per gli utenti e riduce la dipendenza dalle password. Se non hai iniziato a implementare dispositivi Windows 10 o li hai distribuiti solo parzialmente, ti consigliamo di eseguire l'aggiornamento a Windows 10 e abilitare Windows Hello for Business in tutti i dispositivi.

Per altre informazioni sull'autenticazione senza password, vedere Un mondo senza password con l'ID Microsoft Entra.

Autenticazione e assegnazione dell'applicazione

Single Sign-On per le app

Fornire un meccanismo di accesso Single Sign-On standardizzato per l'intera azienda è fondamentale per un'esperienza utente ottimale, la riduzione del rischio, la capacità di segnalare e la governance. Se si usano applicazioni che supportano l'accesso SSO con Microsoft Entra ID ma sono attualmente configurate per l'uso degli account locali, è necessario riconfigurare tali applicazioni per l'uso dell'accesso SSO con Microsoft Entra ID. Analogamente, se si usano applicazioni che supportano l'accesso SSO con Microsoft Entra ID ma si usa un altro provider di identità, è necessario riconfigurare tali applicazioni per l'uso dell'accesso SSO con Microsoft Entra ID. Per le applicazioni che non supportano i protocolli federativi, ma supportano l'autenticazione basata su moduli, è consigliabile configurare l'applicazione per l'uso dell'insieme di credenziali delle password con il proxy dell'applicazione Microsoft Entra.

AppProxy Password-based Sign-on

Nota

Se non si dispone di un meccanismo per individuare le applicazioni non gestite nell'organizzazione, è consigliabile implementare un processo di individuazione usando un broker di sicurezza delle applicazioni cloud , ad esempio Microsoft Defender per il cloud App.

Infine, se si dispone di una raccolta di app Microsoft Entra e si usano applicazioni che supportano l'accesso SSO con Microsoft Entra ID, è consigliabile elencare l'applicazione nella raccolta di app.

Migrazione delle applicazioni AD FS a Microsoft Entra ID

La migrazione di app da AD FS a Microsoft Entra ID consente funzionalità aggiuntive sulla sicurezza, sulla gestibilità più coerente e su un'esperienza di collaborazione migliore. Se si dispone di applicazioni configurate in AD FS che supportano l'accesso SSO con Microsoft Entra ID, è necessario riconfigurare tali applicazioni per l'uso dell'accesso SSO con Microsoft Entra ID. Se sono presenti applicazioni configurate in AD FS con configurazioni non comuni non supportate dall'ID Microsoft Entra, è necessario contattare i proprietari dell'app per capire se la configurazione speciale è un requisito assoluto dell'applicazione. Se non è necessario, è necessario riconfigurare l'applicazione per l'uso dell'accesso Single Sign-On con Microsoft Entra ID.

Microsoft Entra ID as the primary identity provider

Nota

Microsoft Entra Connessione Health per AD FS può essere usato per raccogliere i dettagli di configurazione su ogni applicazione che può essere potenzialmente migrata a Microsoft Entra ID.

Assegnare utenti alle applicazioni

L'assegnazione di utenti alle applicazioni è il mapping ottimale usando i gruppi perché consentono una maggiore flessibilità e capacità di gestire su larga scala. I vantaggi dell'uso dei gruppi includono l'appartenenza dinamica dei gruppi basata su attributi e la delega ai proprietari delle app. Pertanto, se si usano già e si gestiscono i gruppi, è consigliabile eseguire le azioni seguenti per migliorare la gestione su larga scala:

  • Delegare la gestione e la governance dei gruppi ai proprietari delle applicazioni.
  • Consentire l'accesso self-service all'applicazione.
  • Definire gruppi dinamici se gli attributi utente possono determinare in modo coerente l'accesso alle applicazioni.
  • Implementare l'attestazione ai gruppi usati per l'accesso alle applicazioni usando le verifiche di accesso di Microsoft Entra.

D'altra parte, se si trovano applicazioni che hanno l'assegnazione a singoli utenti, assicurarsi di implementare la governance in tali applicazioni.

Criteri di accesso

Posizioni specifiche

Con i percorsi denominati in Microsoft Entra ID, è possibile etichettare intervalli di indirizzi IP attendibili nell'organizzazione. Microsoft Entra ID usa posizioni denominate per:

Named location

In base alla priorità, usare la tabella seguente per trovare la soluzione consigliata che soddisfi al meglio le esigenze dell'organizzazione:

Priorità Scenario Consiglio
1 Se si usa PHS o PTA e le posizioni denominate non sono state definite Definire posizioni denominate per migliorare il rilevamento degli eventi di rischio
2 Se si è federati e non si usa l'attestazione "insideCorporateNetwork" e i percorsi denominati non sono stati definiti Definire posizioni denominate per migliorare il rilevamento degli eventi di rischio
3 Se non si usano posizioni denominate nei criteri di accesso condizionale e non sono previsti rischi o controlli dei dispositivi nei criteri di accesso condizionale Configurare i criteri di accesso condizionale per includere posizioni denominate
4 Se si è federati e si usa l'attestazione "insideCorporateNetwork" e i percorsi denominati non sono stati definiti Definire posizioni denominate per migliorare il rilevamento degli eventi di rischio
5 Se si usano indirizzi IP attendibili con autenticazione a più fattori anziché percorsi denominati e contrassegnandoli come attendibili Definire posizioni denominate e contrassegnarle come attendibili per migliorare il rilevamento degli eventi di rischio

Criteri di accesso basati sui rischi

Microsoft Entra ID può calcolare il rischio per ogni accesso e ogni utente. L'uso del rischio come criterio nei criteri di accesso può offrire un'esperienza utente migliore, ad esempio un minor numero di richieste di autenticazione e una maggiore sicurezza, ad esempio richiedere agli utenti solo quando sono necessari e automatizzare la risposta e la correzione.

Sign-in risk policy

Se si possiedono già licenze Microsoft Entra ID P2 che supportano l'uso di rischi nei criteri di accesso, ma non vengono usati, è consigliabile aggiungere rischi al comportamento di sicurezza.

Criteri di accesso alle applicazioni client

Microsoft Intune Application Management (MAM) offre la possibilità di eseguire il push dei controlli di protezione dei dati, ad esempio crittografia dell'archiviazione, PIN, pulizia dell'archiviazione remota e così via. per applicazioni per dispositivi mobili client compatibili, ad esempio Outlook Mobile. Inoltre, è possibile creare criteri di accesso condizionale per limitare l'accesso ai servizi cloud, ad esempio Exchange Online, da app approvate o compatibili.

Se i dipendenti installano applicazioni compatibili con MAM, ad esempio le app per dispositivi mobili di Office, per accedere a risorse aziendali come Exchange Online o SharePoint in Microsoft 365 e supportano anche BYOD (bring your own device), è consigliabile distribuire i criteri MAM dell'applicazione per gestire la configurazione dell'applicazione nei dispositivi personali senza registrazione MDM e quindi aggiornare i criteri di accesso condizionale per consentire l'accesso solo dai client con supporto MAM.

Conditional Access Grant control

Se i dipendenti installano applicazioni compatibili con MAM sulle risorse aziendali e l'accesso è limitato nei dispositivi gestiti da Intune, è consigliabile valutare la possibilità di distribuire i criteri MAM dell'applicazione per gestire la configurazione dell'applicazione per i dispositivi personali e aggiornare i criteri di accesso condizionale per consentire solo l'accesso dai client con supporto MAM.

Implementazione dell'accesso condizionale

L'accesso condizionale è uno strumento essenziale per migliorare il comportamento di sicurezza dell'organizzazione. È quindi importante seguire queste procedure consigliate:

  • Assicurarsi che tutte le applicazioni SaaS abbiano almeno un criterio applicato
  • Evitare di combinare il filtro Tutte le app con il controllo blocco per evitare rischi di blocco
  • Evitare di usare tutti gli utenti come filtro e aggiungere inavvertitamente guest
  • Eseguire la migrazione di tutti i criteri "legacy" al portale di Azure
  • Intercettare tutti i criteri per utenti, dispositivi e applicazioni
  • Usare i criteri di accesso condizionale per implementare l'autenticazione a più fattori, anziché usare un'autenticazione a più fattori per utente
  • Avere un piccolo set di criteri di base che possono essere applicati a più applicazioni
  • Definire gruppi di eccezioni vuoti e aggiungerli ai criteri per avere una strategia di eccezione
  • Pianificare gli account break glass senza controlli di autenticazione a più fattori
  • Assicurarsi un'esperienza coerente tra le applicazioni client di Microsoft 365, ad esempio Teams, OneDrive, Outlook e così via. implementando lo stesso set di controlli per servizi come Exchange Online e SharePoint in Microsoft 365
  • L'assegnazione ai criteri deve essere implementata tramite gruppi, non singoli utenti
  • Eseguire revisioni regolari dei gruppi di eccezioni usati nei criteri per limitare il tempo che gli utenti non rientrano nel comportamento di sicurezza. Se si è proprietari di Microsoft Entra ID P2, è possibile usare le verifiche di accesso per automatizzare il processo

Superficie di accesso

Autenticazione legacy

Le credenziali complesse, ad esempio l'autenticazione a più fattori, non possono proteggere le app usando protocolli di autenticazione legacy, che lo rendono il vettore di attacco preferito da utenti malintenzionati. Il blocco dell'autenticazione legacy è fondamentale per migliorare il comportamento di sicurezza degli accessi.

L'autenticazione legacy è un termine che fa riferimento ai protocolli di autenticazione usati dalle app, ad esempio:

  • Client office meno recenti che non usano l'autenticazione moderna (ad esempio, client di Office 2010)
  • Client che usano protocolli di posta elettronica come IMAP (Internet Message Access Protocol)/Simple Mail Transfer Protocol (SMTP)/punto di presenza (POP)

Gli utenti malintenzionati preferiscono fortemente questi protocolli, in realtà quasi il 100% degli attacchi password spray usa protocolli di autenticazione legacy. Gli hacker usano protocolli di autenticazione legacy, perché non supportano l'accesso interattivo, che è necessario per problemi di sicurezza aggiuntivi, ad esempio l'autenticazione a più fattori e l'autenticazione del dispositivo.

Se l'autenticazione legacy è ampiamente usata nell'ambiente in uso, è consigliabile pianificare la migrazione dei client legacy ai client che supportano l'autenticazione moderna il prima possibile. Nello stesso token, se alcuni utenti usano già l'autenticazione moderna, ma altri che usano ancora l'autenticazione legacy, è necessario seguire questa procedura per bloccare i client di autenticazione legacy:

  1. Usare i report attività di accesso per identificare gli utenti che usano ancora l'autenticazione legacy e pianificare la correzione:

    1. Eseguire l'aggiornamento ai client con funzionalità di autenticazione moderna per gli utenti interessati.

    2. Pianificare un intervallo di tempo di cutover per bloccare i passaggi seguenti.

    3. Identificare quali applicazioni legacy hanno una dipendenza rigida dall'autenticazione legacy. Vedere il passaggio 3 seguente.

  2. Disabilitare i protocolli legacy nell'origine (ad esempio Cassetta postale di Exchange) per gli utenti che non usano l'autenticazione legacy per evitare un'esposizione maggiore.

  3. Per gli account rimanenti (idealmente identità non umane, ad esempio gli account del servizio), usare l'accesso condizionale per limitare i protocolli legacy dopo l'autenticazione.

In un attacco di concessione del consenso illecito, l'utente malintenzionato crea un'applicazione registrata di Microsoft Entra che richiede l'accesso ai dati, ad esempio informazioni di contatto, posta elettronica o documenti. Gli utenti potrebbero concedere il consenso ad applicazioni dannose tramite attacchi di phishing durante l'atterraggio su siti Web dannosi.

Di seguito è riportato un elenco di app con autorizzazioni che è possibile esaminare per i servizi Microsoft Cloud:

  • App con app o delegate *. Autorizzazioni readWrite
  • Le app con autorizzazioni delegate possono leggere, inviare o gestire la posta elettronica per conto dell'utente
  • App concesse tramite le autorizzazioni seguenti:
Conto risorse Autorizzazione
Exchange Online EAS. AccessAsUser.All
EWS.AccessAsUser.All
Mail.Read
API di Microsoft Graph Mail.Read
Mail.Read.Shared
Mail.ReadWrite
  • Le app hanno concesso la rappresentazione utente completa dell'utente connesso. Ad esempio:
Conto risorse Autorizzazione
API di Microsoft Graph Directory.AccessAsUser.All
API REST di Azure user_impersonation

Per evitare questo scenario, è necessario fare riferimento a Rilevare e correggere le concessioni di consenso illecite in Office 365 per identificare e correggere eventuali applicazioni con concessioni illecite o applicazioni con più concessioni di quanto necessario. Rimuovere quindi completamente le procedure self-service e stabilire le procedure di governance. Infine, pianificare revisioni regolari delle autorizzazioni dell'app e rimuoverle quando non sono necessarie.

Impostazioni utente e gruppo

Di seguito sono riportate le impostazioni utente e gruppo che possono essere bloccate se non è necessario un'azienda esplicita:

Impostazioni utente

  • Utenti esterni: la collaborazione esterna può avvenire in modo organico nell'organizzazione con servizi come Teams, Power BI, SharePoint in Microsoft 365 e Azure Information Protection. Se si hanno vincoli espliciti per controllare la collaborazione esterna avviata dall'utente, è consigliabile abilitare gli utenti esterni usando la gestione entitlement di Microsoft Entra o un'operazione controllata, ad esempio tramite l'help desk. Se non si vuole consentire la collaborazione esterna organica per i servizi, è possibile impedire ai membri di invitare completamente utenti esterni. In alternativa, è anche possibile consentire o bloccare domini specifici negli inviti degli utenti esterni.
  • Registrazioni app: quando Registrazioni app sono abilitati, gli utenti finali possono eseguire l'onboarding delle applicazioni stesse e concedere l'accesso ai propri dati. Un esempio tipico di Registrazione app è che gli utenti abilitano i plug-in di Outlook o assistenti vocali come Alexa e Siri per leggere la posta elettronica e il calendario o inviare messaggi di posta elettronica per loro conto. Se il cliente decide di disattivare la registrazione dell'app, i team infoSec e IAM devono essere coinvolti nella gestione delle eccezioni (registrazioni di app necessarie in base ai requisiti aziendali), in quanto dovranno registrare le applicazioni con un account amministratore e probabilmente richiedono la progettazione di un processo per rendere operativo il processo.
  • Amministrazione istration Portal: le organizzazioni possono bloccare il pannello Microsoft Entra nel portale di Azure in modo che gli utenti non possano accedere alla gestione di Microsoft Entra nel portale di Azure e si confondono. Passare alle impostazioni utente nel portale di gestione di Microsoft Entra per limitare l'accesso:

Administration portal restricted access

Nota

Gli utenti non amministratori possono comunque accedere alle interfacce di gestione di Microsoft Entra tramite la riga di comando e altre interfacce a livello di codice.

Impostazioni dei gruppi

Gestione gruppi self-service/ Gli utenti possono creare gruppi di sicurezza/gruppi di Microsoft 365. Se non è disponibile alcuna iniziativa self-service corrente per i gruppi nel cloud, i clienti potrebbero decidere di disattivarlo fino a quando non sono pronti a usare questa funzionalità.

Traffico da posizioni impreviste

Gli utenti malintenzionati provengono da diverse parti del mondo. Gestire questo rischio usando i criteri di accesso condizionale con la posizione come condizione. La condizione di posizione di un criterio di accesso condizionale consente di bloccare l'accesso alle posizioni da cui non esiste alcun motivo aziendale per accedere.

Create a new named location

Se disponibile, usare una soluzione SIEM (Security Information and Event Management) per analizzare e trovare modelli di accesso tra aree. Se non si usa un prodotto SIEM o non si inseriscono informazioni di autenticazione da Microsoft Entra ID, è consigliabile usare Monitoraggio di Azure per identificare i modelli di accesso tra aree.

Utilizzo dell'accesso

Log di Microsoft Entra archiviati e integrati con piani di risposta agli eventi imprevisti

L'accesso alle attività di accesso, ai controlli e agli eventi di rischio per Microsoft Entra ID è fondamentale per la risoluzione dei problemi, l'analisi dell'utilizzo e le indagini forensi. Microsoft Entra ID fornisce l'accesso a queste origini tramite LE API REST con un periodo di conservazione limitato. Un sistema SIEM (Security Information and Event Management) o una tecnologia di archiviazione equivalente è fondamentale per l'archiviazione a lungo termine di controlli e supporto. Per abilitare l'archiviazione a lungo termine dei log di Microsoft Entra, è necessario aggiungerli alla soluzione SIEM esistente o usare Monitoraggio di Azure. Archiviare i log che possono essere usati come parte dei piani di risposta agli eventi imprevisti e delle indagini.

Riepilogo

Esistono 12 aspetti per un'infrastruttura di identità sicura. Questo elenco consente di proteggere e gestire ulteriormente le credenziali, definire l'esperienza di autenticazione, delegare l'assegnazione, misurare l'utilizzo e definire i criteri di accesso in base al comportamento di sicurezza aziendale.

  • Assegnare proprietari alle attività principali.
  • Implementare soluzioni per rilevare password deboli o perse, migliorare la gestione e la protezione delle password e proteggere ulteriormente l'accesso utente alle risorse.
  • Gestire l'identità dei dispositivi per proteggere le risorse in qualsiasi momento e da qualsiasi posizione.
  • Implementare l'autenticazione senza password.
  • Fornire un meccanismo di accesso Single Sign-On standardizzato nell'organizzazione.
  • Eseguire la migrazione delle app da AD FS a Microsoft Entra ID per migliorare la sicurezza e la gestibilità più coerente.
  • Assegnare utenti alle applicazioni usando gruppi per consentire una maggiore flessibilità e capacità di gestire su larga scala.
  • Configurare i criteri di accesso basati sui rischi.
  • Bloccare i protocolli di autenticazione legacy.
  • Rilevare e correggere le concessioni di consenso illecite.
  • Bloccare le impostazioni utente e gruppo.
  • Abilitare l'archiviazione a lungo termine dei log di Microsoft Entra per la risoluzione dei problemi, l'analisi dell'utilizzo e le indagini forensi.

Passaggi successivi

Introduzione ai controlli operativi e alle azioni di Identity Governance.