Creare una strategia di gestione resiliente del controllo di accesso 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 a condizioni di mercato mutevoli, non deve essere interpretato come un impegno da parte di Microsoft e Microsoft non può garantire l'accuratezza delle informazioni presentate dopo la data di pubblicazione.

Le organizzazioni che si basano su un singolo controllo di accesso, ad esempio l'autenticazione a più fattori o un'unica posizione di rete, per proteggere i sistemi IT sono soggetti a errori di accesso alle app e alle risorse, se il singolo controllo di accesso diventa 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 anziché l'autenticazione a più fattori per utente.
  • Attenuare il blocco utente usando 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:

  • Amministrazione istrator lockout: i Amministrazione istrator 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

Per sbloccare l'accesso dell'amministratore al tenant, è consigliabile creare account di accesso di emergenza. Questi account di accesso di emergenza, noti anche come account break glass , consentono l'accesso per gestire la configurazione di Microsoft Entra quando le normali procedure di accesso agli account con privilegi non sono disponibili. Devono essere creati almeno due account di accesso di emergenza seguendo le indicazioni relative agli account di accesso di emergenza.

Riduzione del blocco dell'utente

Per ridurre il rischio di blocco degli utenti, usare i criteri di accesso condizionale con più controlli per consentire agli utenti di scegliere come accedono alle app e alle 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 controlli di accesso seguenti 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'SMS (telefonia).
  • 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 l'aggiunta ibrida Microsoft Entra o Microsoft Intune. I dispositivi attendibili migliorano l'esperienza utente perché il dispositivo attendibile stesso può soddisfare i requisiti di autenticazione avanzata 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 i criteri basati sui rischi di Microsoft Entra ID Protection che impediscono l'accesso quando l'utente o l'accesso è a rischio al posto dei 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 è necessario un gruppo di sicurezza AppUsers con gli utenti di destinazione a cui si vuole concedere l'accesso, un gruppo denominato Core Amministrazione s con gli amministratori di base e un gruppo 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 connette da un dispositivo attendibile O fornisce l'autenticazione avanzata, ad esempio MFA. Il criterio esclude gli account di emergenza e gli amministratori di core.

Set di criteri di mitigazione dell'accesso condizionale:

  • Criterio 1: Bloccare l'accesso alle persone esterne ai gruppi di destinazione
    • Utenti e gruppi: includere tutti gli utenti. Escludi AppUsers CoreAdmins ed EmergencyAccess
    • App cloud: includere tutte le app
    • Condizioni: (Nessuno)
    • Concedi controllo: Blocca
  • Criterio 2: concedere l'accesso ad AppUsers che richiedono MFA o un dispositivo attendibile.
    • Utenti e gruppi: includere AppUsers. Escludere CoreAdmins ed EmergencyAccess
    • App cloud: includere tutte le app
    • Condizioni: (Nessuno)
    • Concedi controllo: concedere l'accesso, richiedere l'autenticazione a più fattori, richiedere che il dispositivo sia conforme. 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 consentono agli amministratori e agli utenti finali di accedere alle app e alle risorse, durante un'interruzione quando non è stato implementato alcun metodo di mitigazione. 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 cruciali in anticipo: quali sono le app a cui è necessario concedere l'accesso, anche con un comportamento 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 finirà con categorie di:
    • Categoria 1 app cruciali che non possono essere disponibili per più di pochi minuti, ad esempio App che influiscono direttamente 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 prepianificare il tipo di accesso che si vuole 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 queste app, Microsoft consiglia anche di pianificare quali vie di accesso si apriranno deliberatamente e quali si chiuderanno:
    • 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 vuole che i criteri per i criteri di emergenza, in particolare per le app cruciali, abbiano esito negativo o esito positivo se non è disponibile un controllo di accesso alternativo?

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 basati sui dispositivi. Per ridurre al minimo le interruzioni impreviste quando è abilitato un criterio di emergenza, i criteri devono rimanere in modalità di sola report quando non sono in uso. Amministrazione istrator può 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 i criteri e disabilitare i normali criteri basati sul controllo.

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 solo report che richiede l'aggiunta a un dominio come controllo, come backup per un criterio attivo che richiede un provider MFA di terze parti.
  • Ridurre il rischio che gli attori malintenzionati indovinano le password, quando l'autenticazione a più fattori non è necessaria, seguendo le procedure del white paper sulle password .
  • Distribuire la reimpostazione password self-service di Microsoft Entra e la protezione password di Microsoft Entra per assicurarsi che gli utenti non usino password e termini comuni che si sceglie di vietare.
  • Usare criteri che limitano l'accesso all'interno delle app se un determinato livello di autenticazione non viene raggiunto invece di 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 per il cloud App, è consigliabile eseguire il fallback a un criterio che coinvolge le app Defender per il cloud e quindi consentire l'accesso in sola lettura, ma non i caricamenti.
  • Assegnare un nome ai criteri per assicurarsi che sia facile trovarli durante un'interruzione. Includere gli elementi seguenti nel nome del criterio:
    • 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.

Questo standard di denominazione per i criteri di emergenza è il 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 richiede in genere l'autenticazione a più fattori per l'accesso a Exchange Online e SharePoint Online e l'interruzione in questo caso è il provider MFA per il cliente ha un'interruzione (sia che Microsoft Entra multifactor authentication, provider MFA locale o MFA di terze parti). Questo criterio riduce questa interruzione consentendo a utenti specifici di accedere a queste app da dispositivi Windows attendibili solo quando accedono all'app dalla 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. Questo esempio richiede un percorso di rete denominato CorpNetwork e un gruppo di sicurezza ContingencyAccess con gli utenti di destinazione, un gruppo denominato Core Amministrazione s con gli amministratori di base e un gruppo 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 ripristinare l'accesso alle app di collaborazione cruciali:

  • Criterio 1: Richiedere dispositivi aggiunti a un dominio per Exchange e SharePoint
    • Name: EM001 - ENABLE IN EMERGENCY: MFA Disruption[1/4] - Exchange SharePoint - Require Microsoft Entra hybrid join
    • 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 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 posizione, escludere CorpNetwork
    • Concedi controllo: Blocca
    • Stato: solo report
  • Criterio 4: Bloccare in modo esplicito EAS
    • 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. Abilita criterio 1: verificare che gli utenti nei dispositivi aggiunti a un dominio che non si trovino 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. Abilita criterio 2: verificare che gli utenti che non si trovano 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. Abilita criterio 3: verificare che gli utenti che non si trovano 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. Abilita criterio 4: verificare che tutti gli utenti non possano ottenere Exchange Online dalle applicazioni di posta native nei dispositivi mobili.
  6. Disabilitare i criteri di autenticazione a più fattori esistenti per SharePoint Online ed Exchange Online.

In questo esempio seguente, l'esempio B - Criteri di accesso condizionale di emergenza per consentire l'accesso mobile a Salesforce, viene ripristinato l'accesso di un'app aziendale. In questo scenario, il cliente richiede in genere l'accesso dei dipendenti alle vendite a Salesforce (configurato per l'accesso Single Sign-On con MICROSOFT Entra ID) dai dispositivi mobili per essere consentito solo dai dispositivi conformi. L'interruzione in questo caso è che si è verificato un problema relativo alla valutazione della conformità del dispositivo e l'interruzione avviene in un momento sensibile in cui il team di vendita deve accedere a Salesforce per chiudere le trattative. Questi criteri di emergenza concedono agli utenti critici l'accesso a Salesforce da un dispositivo mobile in modo che possano continuare a chiudere le trattative e non interrompere l'azienda. 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 nel team SalesContingency
    • Name: EM001 - ENABLE IN EMERGENCY: Device Compliance Disruption[1/2] - Salesforce - Block All users except SalesforceContingency
    • Utenti e gruppi: includere tutti gli utenti. Escludere SalesAdmins e SalesforceContingency
    • App cloud: Salesforce.
    • Condizioni: Nessuno
    • Concedi controllo: Blocca
    • Stato: solo report
  • Criterio 2: Bloccare il team vendite da qualsiasi piattaforma diversa da mobile (per ridurre la superficie di attacco)
    • Name: EM002 - ENABLE IN EMERGENCY: Device Compliance Disruption[2/2] - Salesforce - Block All platforms except iOS and 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 esterni a 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 nel gruppo SalesContingency non possano accedere a Salesforce dai portatili Windows/Mac, ma possono 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 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 Server dei criteri di rete, di conseguenza, il server dei criteri di rete verificherà solo l'autenticazione primaria e non applichererà mFA agli utenti.

Disabilitare l'estensione NPS:

  • Eseguire 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 se si è federati o si usa l'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 tramite la procedura guidata microsoft Entra Connessione, indipendentemente dal fatto che l'organizzazione usi l'autenticazione federativa o pass-through.

Importante

Non è necessario convertire gli utenti da federati all'autenticazione gestita per usare la sincronizzazione dell'hash delle password.

Durante un'interruzione

Se si è scelto di implementare un piano di mitigazione, è possibile sopravvivere automaticamente a una singola interruzione del controllo di accesso. Tuttavia, se si è scelto di creare un piano di emergenza, è 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, gli attori malintenzionati potrebbero avere già password che in precedenza non concedevano l'accesso a qualsiasi risorsa che può essere tentata durante questa finestra. 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 dei rischi segnalati dopo l'interruzione dell'attività sospetta.
  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

In un'emergenza e l'organizzazione non ha implementato in precedenza un piano di mitigazione o di emergenza, quindi seguire le raccomandazioni nella sezione Contingencies for user lockout se usano già i criteri di accesso condizionale per applicare 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 ampliano gli indirizzi IP attendibili per sbloccare l'accesso, i rilevamenti dei rischi associati agli indirizzi IP (ad esempio, percorsi impossibili o non familiari) non verranno generati.

Nota

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

Altre informazioni