Condividi tramite

Creare una strategia di gestione di controllo di accesso resiliente con Microsoft Entra ID

  • Articolo

Nota

Le informazioni contenute in questo documento rappresentano la posizione attuale di Microsoft Corporation alla data della pubblicazione rispetto alle questioni trattate. Poiché Microsoft deve rispondere alle mutevoli condizioni del mercato, questo non deve essere interpretato come un impegno da parte di Microsoft, che non garantisce l'accuratezza delle informazioni presentate dopo la data di pubblicazione.

Le organizzazioni che proteggono i loro sistemi IT basandosi su un controllo di accesso singolo, ad esempio l'autenticazione a più fattori (MFA) o un unico percorso di rete, sono soggette a errori di accesso alle loro app e risorse se tale controllo di accesso singolo non è disponibile o è non è configurato correttamente. Una calamità naturale, ad esempio, può causare l'indisponibilità di segmenti di grandi dimensioni di un'infrastruttura di telecomunicazioni o reti aziendali. Un'interruzione di questo tipo potrebbe togliere la possibilità di accedere agli utenti finali e agli amministratori.

Questo documento fornisce materiale sussidiario sulle strategie che un'organizzazione deve adottare per garantire la resilienza e ridurre il rischio di blocco durante interruzioni impreviste con i seguenti scenari:

  • Le organizzazioni possono aumentare la resilienza per ridurre il rischio di blocco prima di un'interruzione implementando le strategie di mitigazione o piani di emergenza.
  • Grazie alle strategie di mitigazione e ai piani di emergenza, le organizzazioni possono continuare ad accedere alle app e risorse scelte durante un'interruzione.
  • Le organizzazioni devono assicurarsi di conservare le informazioni, come ad esempio i log, dopo un'interruzione e prima di eseguire il rollback di eventuali contingenze implementate.
  • Le organizzazioni che non hanno implementato strategie di prevenzione o piani alternativi potrebbero implementare opzioni di emergenza per affrontare l'interruzione.

Materiale sussidiario chiave

Da questo documento si traggono quattro punti chiave:

  • Evitare il blocco dell'amministratore usando account di accesso di emergenza.
  • Implementare l'autenticazione a più fattori usando l'accesso condizionale invece dell'autenticazione a più fattori per l'utente.
  • Ridurre il blocco dell'utente tramite più controlli di accesso condizionale.
  • Ridurre i blocchi dell'utente effettuando il provisioning di più metodi o equivalenti di autenticazione per ciascun utente.

Prima di un'interruzione

La riduzione di un'interruzione reale deve essere l'obiettivo principale di un'organizzazione nella gestione dei problemi di controllo di accesso che potrebbero verificarsi. La riduzione del rischio include la pianificazione di un evento reale e l'implementazione di strategie per assicurarsi che i controlli e le operazioni di accesso non siano coinvolti durante le interruzioni.

Perché è necessario il controllo di accesso resiliente?

L'identità è il piano di controllo degli utenti che accedono alle app e risorse. Il sistema di identità consente di controllare quali utenti ottengono accesso alle applicazioni e in quali condizioni, ad esempio tramite controlli di accesso o requisiti di autenticazione. Quando uno o più requisiti di autenticazione o controllo di accesso non sono disponibili per l'autenticazione degli utenti a causa di circostanze impreviste, le organizzazioni possono ritrovarsi in una o entrambe le situazioni seguenti:

  • Blocco dell'amministratore: gli amministratori non possono gestire il tenant o i servizi.
  • Blocco utente: gli utenti non possono accedere alle app o alle risorse.

Piano di emergenza per il blocco dell'amministratore

Microsoft consiglia alle organizzazioni di avere due account di accesso di emergenza solo cloud assegnati in modo permanente al ruolo di amministratore globale. Si tratta di account con privilegi elevati non assegnati a utenti specifici. Tali account sono limitati a scenari di emergenza o "break glass", in cui gli account normali non possono essere usati o tutti gli altri amministratori vengono accidentalmente bloccati. Questi account devono essere creati seguendo i consigli per l'account di accesso di emergenza.

Riduzione del blocco dell'utente

Per attenuare il rischio di blocco dell'utente, usare i criteri di accesso condizionale con più controlli per concedere agli utenti la scelta del modo in cui accedono ad app e risorse. Se si permette a un utente di scegliere tra, ad esempio, accedere con autenticazione a più fattori o da un dispositivo gestito o dalla rete aziendale, se uno dei controlli di accesso non è disponibile l'utente ha altre opzioni per continuare a lavorare.

Elementi consigliati di Microsoft

Incorporare i seguenti controlli di accesso nei criteri di accesso condizionale esistenti per l'organizzazione:

  • Effettuare il provisioning di più metodi di autenticazione per ogni utente che si basano su canali di comunicazione diversi, ad esempio l'app Microsoft Authenticator (basata su internet), il token OATH (generato sul dispositivo) e l'autenticazione via SMS (telefonica).
  • Distribuire Windows Hello for Business nei dispositivi Windows 10 per soddisfare i requisiti di autenticazione a più fattori direttamente dall'accesso del dispositivo.
  • Usare dispositivi attendibili tramite il join ibrido a Microsoft Entra o Microsoft Intune. Un dispositivo attendibile migliora l'esperienza dell'utente, in quanto il dispositivo stesso è in grado di soddisfare i requisiti avanzati di autenticazione dei criteri senza una richiesta di autenticazione a più fattori per l'utente. L'autenticazione a più fattori sarà poi necessaria durante la registrazione di un nuovo dispositivo e durante l'accesso alle app o risorse da dispositivi non attendibili.
  • Usare criteri di protezione dell'identità Microsoft Entra ID basati sul rischio, i quali impediscono l'accesso quando l'utente o l'accesso è a rischio, piuttosto che criteri di autenticazione a più fattori fissi.
  • Se si protegge l'accesso VPN usando l'estensione NPS per l'autenticazione a più fattori di Microsoft Entra, prendere in considerazione la federazione della soluzione VPN come app SAML e determinare la categoria di app come consigliato di seguito.

Nota

I criteri basati sul rischio richiedono licenze Microsoft Entra ID P2.

L'esempio seguente descrive i criteri da creare per fornire un controllo di accesso resiliente all'utente che vuole accedere alle app e risorse. In questo esempio, sono necessari un gruppo di sicurezza AppUsers con gli utenti di destinazione ai quali si vuole consentire l'accesso, uno denominato CoreAdmins con gli amministratori di core e uno denominato EmergencyAccess con gli account di accesso di emergenza. Questo set di criteri di esempio concederà, agli utenti selezionati in AppUsers, l'accesso alle app selezionate se si connettono da un dispositivo attendibile OPPURE se forniscono un'autenticazione avanzata, come l'autenticazione a più fattori. Il criterio esclude gli account di emergenza e gli amministratori di core.

Set di criteri di mitigazione dell'accesso condizionale:

  • Criterio 1: blocca l'accesso a persone all'esterno dei gruppi di destinazione
    • Utenti e gruppi: includere tutti gli utenti. Escludi AppUsers CoreAdmins ed EmergencyAccess
    • App cloud: includere tutte le app
    • Condizioni: (Nessuna)
    • Concedi controllo: Blocca
  • Criterio 2: concedi l'accesso ad AppUsers richiedendo l'autenticazione a più fattori OPPURE un dispositivo attendibile.
    • Utenti e gruppi: includere AppUsers. Escludere CoreAdmins ed EmergencyAccess
    • App cloud: includere tutte le app
    • Condizioni: (Nessuna)
    • Concedi l'accesso, richiedi l'autenticazione a più fattori, richiedi la conformità del dispositivo. Per più controlli: richiedere uno dei controlli selezionati.

Contingenze per blocco dell'utente

In alternativa, l'organizzazione può anche creare dei criteri di emergenza. Per creare i criteri di emergenza, è necessario definire i criteri di compromesso tra continuità aziendale, costo operativo, costo finanziario e rischi relativi alla sicurezza. Ad esempio, è possibile attivare un criterio di emergenza solo in un subset di utenti, per un subset di app, per un subset di client o da un subset di percorsi. I criteri di emergenza forniscono l'accesso ad app e risorse agli amministratori e agli utenti finali durante un'interruzione se non è stato implementato alcun metodo di mitigazione dei rischi. Microsoft consiglia di abilitare i criteri di emergenza in modalità solo report quando non in uso, in modo che gli amministratori possano monitorare il potenziale impatto dei criteri se devono essere attivati.

Comprendere l'esposizione durante un'interruzione aiuta a ridurre i rischi ed è una parte essenziale del processo di pianificazione. Per creare il piano di emergenza, determinare innanzitutto i seguenti requisiti aziendali dell'organizzazione:

  1. Determinare le app mission critical in anticipo: quali sono le app a cui è necessario concedere l'accesso, anche con una postura di rischio/sicurezza inferiore? Compilare un elenco di queste app e assicurarsi che gli altri stakeholder (business, sicurezza, legali, leadership) concordino sul fatto che se tutto il controllo di accesso è indisponibile, l'esecuzione di queste app deve comunque continuare. È probabile che si vadano a formare le seguenti categorie:
    • Categoria 1: app di importanza strategica fondamentale che non possono essere indisponibili per più di pochi minuti, ad esempio le app che hanno un effetto diretto sui ricavi dell'organizzazione.
    • Categoria 2: app importanti che devono tornare accessibili per l'azienda entro poche ore.
    • Categoria 3: app di priorità bassa che possono sopportare un'interruzione di alcuni giorni.
  2. Per le app nella categoria 1 e 2, Microsoft consiglia di pianificare in anticipo quale tipo di livello di accesso si desidera consentire:
    • Si desidera consentire l'accesso completo o una sessione con restrizioni, come la limitazione dei download?
    • Si desidera consentire l'accesso a parte dell'app, ma non all'intera app?
    • Si desidera consentire l'accesso all'information worker e bloccare l'accesso dell'amministratore fino al ripristino del controllo di accesso?
  3. Per tali app, è consigliato inoltre pianificare quali vie di accesso saranno aperte deliberatamente e quali invece saranno chiuse:
    • Si desidera consentire esclusivamente l'accesso dal browser e bloccare i rich client in grado di salvare i dati offline?
    • Si desidera consentire l'accesso solo agli utenti all'interno della rete aziendale e mantenere il blocco degli utenti esterni?
    • Si desidera consentire l'accesso esclusivamente da determinati paesi o aree geografiche durante l'interruzione?
    • Si desidera che i criteri di emergenza, in particolare nel casi di app di importanza strategica fondamentale, abbiano esito positivo o negativo se un controllo di accesso alternativo non è disponibile?

Elementi consigliati di Microsoft

Un criterio di accesso condizionale di emergenza è un criterio di backup che omette l'autenticazione a più fattori di Microsoft Entra, l'autenticazione a più fattori di terze parti, i controlli basati sui rischi o sui dispositivi. Per ridurre al minimo le interruzioni impreviste quando è abilitato un criterio di emergenza, i criteri devono rimanere in modalità di solo report quando non sono in uso. Gli amministratori possono monitorare il potenziale impatto dei criteri di emergenza usando la cartella di lavoro informazioni dettagliate sull'accesso condizionale. Quando l'organizzazione decide di attivare il piano di emergenza, gli amministratori possono abilitare il criterio e disabilitare i normali criteri basati sui controlli.

Importante

La disabilitazione dei criteri che applicano la sicurezza sugli utenti, anche solo temporaneamente, ridurrà il livello di sicurezza mentre il piano di emergenza è in funzione.

  • Configurare un set di criteri di fallback se un'interruzione in un tipo di credenziali o in un meccanismo di controllo di accesso ha effetti sull'accesso alle app. Configurare un criterio di solo report che richiede il controllo di aggiunta a un dominio come backup per un criterio attivo che richiede un provider di autenticazione a più fattori di terze parti.
  • Ridurre il rischio di password indovinate da malintenzionati, quando l'autenticazione a più fattori non è necessaria, seguendo le procedure consigliate nel white paper relativo alle indicazioni sulle password.
  • Distribuire Reimpostazione self-service delle password di Microsoft Entra (SSPR) e Protezione della password di Microsoft Entra per assicurarsi che gli utenti non usino password comuni e termini esclusi.
  • Usare criteri che limitano l'accesso all'interno delle app se non si raggiunge un determinato livello di autenticazione, anziché eseguire semplicemente il fallback all'accesso completo. Ad esempio:
    • Configurare un criterio di backup che invia l'attestazione di sessione con restrizioni a Exchange e SharePoint.
    • Se l'organizzazione usa Microsoft Defender for Cloud Apps, è consigliabile eseguire il fallback a un criterio che coinvolge Defender for Cloud Apps e quindi consentire l'accesso in sola lettura, ma non i caricamenti.
  • Assegnare un nome ai criteri per esseri sicuri di trovarli facilmente durante un'interruzione. Includere gli elementi seguenti nel nome dei criteri:
    • Un numero di etichetta per i criteri.
    • Il testo da visualizzare. Questo criterio è destinato solo ai casi di emergenza. Ad esempio: ENABLE IN EMERGENCY
    • L'interruzione a cui si applica il criterio. Ad esempio: durante l'interruzione dell'autenticazione a più fattori
    • Un numero di sequenza per mostrare l'ordine in cui è necessario attivare i criteri.
    • Le app a cui si applica il criterio.
    • I controlli a cui si applicherà il criterio.
    • Le condizioni richieste.

Lo standard di denominazione per i criteri di emergenza ha il formato seguente:

EMnnn - ENABLE IN EMERGENCY: [Disruption][i/n] - [Apps] - [Controls] [Conditions]

L'esempio seguente: Esempio A - Criteri di accesso condizionale di emergenza per ripristinare l'accesso alle app di collaborazione cruciali è una tipica emergenza aziendale. In questo scenario, l'organizzazione in genere richiede l'autenticazione a più fattori per tutti gli accessi a Exchange Online e SharePoint Online. In questo caso, l'interruzione coinvolge il servizio del provider di autenticazione a più fattori per il cliente (Autenticazione a più fattori Microsoft Entra, provider MFA locale o di terze parti). Questo criterio riduce l'interruzione permettendo a utenti di destinazione specifici di accedere a tali app da dispositivi Windows attendibili esclusivamente quando l'accesso all'app si verifica tramite la rete aziendale attendibile. Anche gli account di emergenza e degli amministratori di core saranno esclusi da queste restrizioni. Gli utenti di destinazione otterranno quindi l'accesso a Exchange Online e SharePoint Online, mentre gli altri utenti continueranno a non poter accedere alle app a causa dell'interruzione del servizio. In questo esempio, sono necessari un percorso di rete denominato CorpNetwork, un gruppo di sicurezza ContingencyAccess con gli utenti di destinazione, uno denominato CoreAdmins con gli amministratori di core e uno denominato EmergencyAccess con gli account di accesso di emergenza. L'emergenza richiede quattro criteri per garantire l'accesso desiderato.

Esempio A: criteri di accesso condizionale di emergenza per il ripristino dell'accesso alle app di collaborazione di importanza strategica fondamentale:

  • Criterio 1: richiedere dispositivi aggiunti a un dominio per Exchange e SharePoint
    • Nome: EM001 - ENABLE IN EMERGENCY: interruzione MFA[1/4] - Exchange SharePoint - Richiede join ibrido Microsoft Entra
    • Utenti e gruppi: includere ContingencyAccess. Escludere CoreAdmins ed EmergencyAccess
    • App cloud: Exchange Online e SharePoint Online
    • Condizioni: Qualsiasi
    • Concedi controllo: richiedere l'aggiunta a un dominio
    • Stato: solo report
  • Criterio 2: bloccare le piattaforme diverse da Windows
    • Nome: EM002 - ENABLE IN EMERGENCY: Interruzione MFA[2/4] - Exchange SharePoint - Blocca l'accesso ad eccezione di Windows
    • Utenti e gruppi: includere tutti gli utenti. Escludere CoreAdmins ed EmergencyAccess
    • App cloud: Exchange Online e SharePoint Online
    • Condizioni: La piattaforma del dispositivo include tutte le piattaforme, esclude Windows
    • Concedi controllo: Blocca
    • Stato: solo report
  • Criterio 3: bloccare reti diverse da CorpNetwork
    • Nome: EM003 - ENABLE IN EMERGENCY: Interruzione MFA[3/4] - Exchange SharePoint - Blocca l'accesso ad eccezione della rete aziendale
    • Utenti e gruppi: includere tutti gli utenti. Escludere CoreAdmins ed EmergencyAccess
    • App cloud: Exchange Online e SharePoint Online
    • Condizioni: i percorsi includono qualsiasi percorso, escludono CorpNetwork
    • Concedi controllo: Blocca
    • Stato: solo report
  • Criterio 4: Bloccare EAS in modo esplicito
    • Nome: EM004 - ENABLE IN EMERGENCY: Interruzione MFA[4/4] - Exchange - Blocca EAS per tutti gli utenti
    • Utenti e gruppi: includere tutti gli utenti
    • App cloud: includere Exchange Online
    • Condizioni: App client: Exchange Active Sync
    • Concedi controllo: Blocca
    • Stato: solo report

Ordine di attivazione:

  1. Escludere ContingencyAccess, CoreAdmins ed EmergencyAccess dai criteri di autenticazione a più fattori esistenti. Verificare che un utente in ContingencyAccess possa accedere a SharePoint Online ed Exchange Online.
  2. Abilitare criterio 1: verificare che gli utenti su dispositivi aggiunti a un dominio che non sono presenti nei gruppi di esclusione siano in grado di accedere a Exchange Online e SharePoint Online. Verificare che gli utenti nel gruppo Exclude possano accedere a SharePoint Online ed Exchange da qualsiasi dispositivo.
  3. Abilitare criterio 2: verificare che gli utenti non presenti nel gruppo di esclusione non possano accedere a SharePoint Online ed Exchange Online dai dispositivi mobili. Verificare che gli utenti nel gruppo Exclude possano accedere a SharePoint ed Exchange da qualsiasi dispositivo (Windows/iOS/Android).
  4. Abilitare criterio 3: verificare che gli utenti non presenti nei gruppi di esclusione non possano accedere a SharePoint ed Exchange dalla rete aziendale, anche con un computer aggiunto a un dominio. Verificare che gli utenti nel gruppo di esclusione possano accedere a SharePoint ed Exchange da qualsiasi rete.
  5. Abilitare criterio 4: verificare che tutti gli utenti non possano accedere a Exchange Online dalle applicazioni native di posta elettronica nei dispositivi mobili.
  6. Disabilitare i criteri di autenticazione a più fattori esistenti per SharePoint Online ed Exchange Online.

In questo esempio successivo, Esempio B: criteri di accesso condizionale di emergenza per consentire l'accesso a Salesforce da dispositivi mobili, viene ripristinato l'accesso a un app aziendale. In questo scenario, in genere, il cliente richiede che l'accesso a Salesforce (configurato per l'accesso singolo con Microsoft Entra ID) da parte degli addetti alla vendita con dispositivi mobili sia consentito solo se tramite dispositivi conformi. L'interruzione, in questo caso, consiste in un problema nella valutazione della conformità dei dispositivi. Si è verificata un'interruzione a un orario delicato, dove il team vendite deve accedere a Salesforce per chiudere delle operazioni commerciali. Questi criteri di emergenza concedono l'accesso a Salesforce da un dispositivo mobile agli utenti fondamentali, in modo da poter continuare a chiudere operazioni commerciali senza interrompere le attività. In questo esempio, SalesforceContingency contiene tutti gli addetti alle vendite che hanno bisogno di mantenere l'accesso, mentre SalesAdmins include gli amministratori di Salesforce necessari.

Esempio B - Criteri di accesso condizionale di emergenza:

  • Criterio 1: bloccare tutti gli utenti non inclusi nel team SalesContingency
    • Name: EM001 - ENABLE IN EMERGENCY: interruzione conformità dispositivi[1/2] - Salesforce - Blocca tutti gli utenti tranne SalesforceContingency
    • Utenti e gruppi: includere tutti gli utenti. Escludere SalesAdmins e SalesforceContingency
    • App cloud: Salesforce.
    • Condizioni: Nessuna
    • Concedi controllo: Blocca
    • Stato: solo report
  • Criterio 2: bloccare il team vendite da tutte le piattaforme diverse dai dispositivi mobili (per ridurre la superficie di attacco)
    • Nome: EM002 - ENABLE IN EMERGENCY: Interruzione conformità dispositivi[2/2] - Salesforce - Blocca tutte le piattaforme tranne iOS e Android
    • Utenti e gruppi: includere SalesforceContingency. Escludere SalesAdmins
    • App cloud: Salesforce
    • Condizioni: La piattaforma del dispositivo include tutte le piattaforme, esclude iOS e Android
    • Concedi controllo: Blocca
    • Stato: solo report

Ordine di attivazione:

  1. Escludere SalesAdmins e SalesforceContingency dai criteri di conformità del dispositivo esistenti per Salesforce. Verificare che un utente nel gruppo SalesforceContingency possa accedere a Salesforce.
  2. Abilita criterio 1: verificare che gli utenti al di fuori di SalesContingency non possano accedere a Salesforce. Verificare che gli utenti in SalesAdmins e SalesforceContingency possano accedere a Salesforce.
  3. Abilita criterio 2: verificare che gli utenti del gruppo SalesContingency non possano accedere a Salesforce dai computer portatili Windows o Mac, ma che possano comunque accedere dai dispositivi mobili. Verificare che SalesAdmin possa comunque accedere a Salesforce da qualsiasi dispositivo.
  4. Disabilitare i criteri di conformità del dispositivo esistenti per Salesforce.

Contingenze per il blocco dell’utente dalle risorse locali (estensione NPS)

Se si protegge l'accesso VPN usando l'estensione NPS per l'autenticazione a più fattori di Microsoft Entra, prendere in considerazione la federazione della soluzione VPN come app SAML e determinare la categoria di app come consigliato di seguito.

Se è stata distribuita l'estensione NPS per l'autenticazione a più fattori di Microsoft Entra per proteggere le risorse locali, ad esempio VPN e Gateway Desktop remoto, con MFA è consigliabile prendere in considerazione in anticipo se si è pronti a disabilitare l'autenticazione a più fattori in caso di emergenza.

In questo caso, è possibile disabilitare l'estensione NPS; di conseguenza, il server NPS verificherà solo l'autenticazione primaria e non applicherà MFA agli utenti.

Disabilitare l'estensione NPS:

  • Esportare la chiave del Registro di sistema HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AuthSrv\Parameters come backup.
  • Eliminare i valori del Registro di sistema per "AuthorizationDLLs" e "ExtensionDLLs", non per la chiave Parameters.
  • Riavviare il servizio IAS (Network Policy Service) per rendere effettive le modifiche
  • Determinare se l'autenticazione primaria per VPN ha esito positivo.

Dopo che il servizio è stato ripristinato e si è pronti per applicare nuovamente l'autenticazione a più fattori agli utenti, abilitare l'estensione NPS:

  • Importare la chiave del Registro di sistema dal backup HKEY_LOCAL_MACHINE\system\CurrentControlSet\Services\AuthSrv\Parameters
  • Riavviare il servizio IAS (Network Policy Service) per rendere effettive le modifiche
  • Determinare se l'autenticazione primaria e l'autenticazione secondaria per VPN hanno esito positivo.
  • Esaminare il server dei criteri di rete e il log VPN per determinare gli utenti che hanno eseguito l'accesso durante la finestra di emergenza.

Distribuire la sincronizzazione dell'hash delle password, anche in caso di federazione o uso dell'autenticazione pass-through

Il blocco dell'utente può inoltre verificarsi se sussistono le condizioni seguenti:

  • L'organizzazione usa una soluzione a identità ibrida con autenticazione pass-through o federazione.
  • I sistemi di identità in locale (ad esempio Active Directory, AD FS o un componente dipendente) non sono disponibili.

Per essere più resiliente, l'organizzazione dovrebbe abilitare la sincronizzazione dell'hash delle password, in quanto consente di passare all'uso della sincronizzazione dell'hash delle password se i sistemi di identità in locale sono inattivi.

Elementi consigliati di Microsoft

Abilitare la sincronizzazione dell'hash delle password usando la procedura guidata di Microsoft Entra Connect, indipendentemente dal fatto che l'organizzazione usi l'autenticazione pass-through o la federazione.

Importante

Per usare la sincronizzazione dell'hash delle password, non è necessario convertire gli utenti dalla federazione all'autenticazione gestita.

Durante un'interruzione

Se si è scelto di implementare il piano di mitigazione, sarà possibile sopravvivere automaticamente a un'interruzione del controllo di accesso singolo. Tuttavia, se si è scelto di creare un piano di emergenza, sarà possibile attivare i criteri di emergenza durante l'interruzione del controllo di accesso:

  1. Abilitare i criteri di emergenza che concedono l'accesso ad app specifiche, da reti specifiche, agli utenti di destinazione.
  2. Disabilitare i normali criteri basati sui controlli.

Elementi consigliati di Microsoft

A seconda delle mitigazioni o emergenze usate durante un'interruzione, l'organizzazione potrebbe garantire l'accesso mediante le sole password. Non adottare nessuna misura di protezione è un rischio per la sicurezza notevole da valutare con attenzione. Le organizzazioni devono:

  1. Come parte della strategia di controllo modifiche, documentare tutte le modifiche e lo stato precedente per poter eseguire il rollback di qualsiasi emergenza implementata non appena i controlli di accesso sono completamente operativi.
  2. Presupporre che i malintenzionati tenteranno di rubare password tramite attacchi di tipo password spray o phishing quando si disabilita l'autenticazione a più fattori. Inoltre, i malintenzionati potrebbero avere già password che, se in precedenza non consentivano l'accesso a nessuna risorsa, possono essere tentate durante questo intervallo. Per gli utenti fondamentali, come i dirigenti, è possibile ridurre parzialmente questo rischio reimpostando le loro password prima di disabilitare l'autenticazione a più fattori.
  3. Archiviare tutte le attività di accesso per identificare chi accede a cosa durante la fase in cui l'autenticazione a più fattori è disabilitata.
  4. Valutare tutti i rilevamenti dei rischi segnalati durante questa finestra.

Dopo un'interruzione

Annullare le modifiche apportate nell'ambito del piano di emergenza attivato una volta ripristinato il servizio che ha causato l'interruzione.

  1. Abilitare i criteri normali
  2. Disabilitare i criteri di emergenza in modalità solo report.
  3. Eseguire il rollback delle modifiche apportate e documentate durante l'interruzione.
  4. Se si usa un account di accesso di emergenza, ricordarsi di rigenerare le credenziali e proteggere fisicamente i dettagli delle nuove credenziali come parte delle procedure di account di accesso di emergenza.
  5. Continuare a valutare tutti i rilevamenti di rischio segnalati dopo l'interruzione per rilevare attività sospette.
  6. Revocare tutti i token di aggiornamento rilasciati per impostare come destinazione un set di utenti. La revoca di tutti i token di aggiornamento è importante per gli account con privilegi usati durante l'interruzione. Questa operazione costringerà gli utenti a ripetere l'autenticazione e rispettare il controllo dei criteri ripristinati.

Opzioni di emergenza

Se si verifica una situazione di emergenza, ma l'organizzazione non ha implementato un piano di emergenza o mitigazione, seguire le indicazioni contenute nella sezione Emergenze per il blocco dell'utente se si usano già criteri di accesso condizionale per imporre l'autenticazione a più fattori. Se l'organizzazione usa criteri di autenticazione a più fattori obsoleti per l'utente, è possibile prendere in considerazione l'alternativa seguente:

  • Se si dispone dell'indirizzo IP in uscita della rete aziendale, è possibile aggiungerli come indirizzi IP attendibili per abilitare l'autenticazione esclusivamente sulla rete aziendale.
  • Se non si ha l'inventario degli indirizzi IP in uscita, o se è necessario abilitare l'accesso all'interno e all'esterno della rete aziendale, è possibile aggiungere l'intero spazio indirizzi IPv4 come indirizzi IP attendibili specificando 0.0.0.0/1 e 128.0.0.0/1.

Importante

Se si estendono gli indirizzi IP attendibili per sbloccare l'accesso, non verranno generati i rilevamenti di rischio associati con gli indirizzi IP (ad esempio, comunicazione impossibile o posizioni non note).

Nota

La configurazione di indirizzi IP attendibili per l'autenticazione a più fattori Di Microsoft Entra è disponibile solo con le licenze P1 o P2 di Microsoft Entra ID.

Altre informazioni