Creare una strategia di gestione di controllo di accesso resiliente con Azure Active Directory

Nota

Le informazioni contenute in questo documento rappresentano la posizione attuale di Microsoft Corporation sulle problematiche trattate alla data di pubblicazione. 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, 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:

  • Blocco amministratore: Gli amministratori non possono gestire il tenant o i servizi.
  • Blocco utente: Gli utenti non possono accedere ad app o 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, noti anche come account break glass, consentono l'accesso per gestire la configurazione di Azure AD quando non sono disponibili le normali procedure di accesso con privilegi. 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 accederanno 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'autenticazione via SMS (telefonica). Lo script di PowerShell seguente consente di identificare in anticipo i metodi aggiuntivi che gli utenti devono registrare: Script per l'analisi del metodo di autenticazione MFA Azure AD.
  • 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 Azure AD join ibrido o Microsoft Endpoint Manager. Un dispositivo attendibile migliorerà 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à di Azure AD 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 Azure AD'estensione NPS MFA, 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 di Azure AD Premium 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, saranno 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 sono connessi 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: Bloccare l'accesso a 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 richiede MFA O 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 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 forniranno 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 l'impatto potenziale dei criteri qualora debbano 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 livello 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 Azure AD MFA, MFA di terze parti, controlli basati sui rischi o basati su dispositivo. Per ridurre al minimo le interruzioni impreviste quando è abilitato un criterio di emergenza, i criteri devono rimanere in modalità solo report quando non sono in uso. Gli amministratori possono monitorare il potenziale impatto dei criteri di emergenza usando l'accesso condizionale Insights cartella di lavoro. 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 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 Azure AD (SSPR) e Protezione della password di Azure AD 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, prendere in considerazione il ritorno a un criterio che impegna Defender for Cloud Apps e quindi consentire l'accesso di 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 MFA
    • 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 avrà il formato seguente:

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

L'esempio seguente: esempio di 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 MFA per tutti i Exchange Online e l'accesso online SharePoint e l'interruzione in questo caso è il provider MFA per il cliente ha un'interruzione (sia Azure AD MFA, provider MFA locale o MFA 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, saranno 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 ripristinare l'accesso alle app di collaborazione critiche:

  • Criterio 1: Richiedere dispositivi aggiunti al dominio per Exchange e SharePoint
    • Nome: EM001 - ENABLE IN EMERGENCY: Interruzione MFA[1/4] - Exchange SharePoint - Richiedi aggiunta di Azure AD ibrido
    • Utenti e gruppi: includere ContingencyAccess. Escludere CoreAdmins ed EmergencyAccess
    • App cloud: Exchange Online e SharePoint online
    • Condizioni: Qualsiasi
    • Controllo di concessione: Richiedere l'aggiunta al dominio
    • Stato: solo report
  • Criteri 2: Blocca piattaforme diverse da Windows
    • Nome: EM002 - ENABLE IN EMERGENCY: MFA Disruption[2/4] - Exchange SharePoint - Blocca l'accesso tranne Windows
    • Utenti e gruppi: includere tutti gli utenti. Escludere CoreAdmins ed EmergencyAccess
    • App cloud: Exchange Online e SharePoint online
    • Condizioni: Piattaforma dispositivi includono tutte le piattaforme, escludere Windows
    • Controllo di concessione: Blocca
    • Stato: solo report
  • Criteri 3: Bloccare reti diverse da CorpNetwork
    • Nome: EM003 - ENABLE IN EMERGENCY: MFA Disruption[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: Le posizioni includono qualsiasi posizione, escludere CorpNetwork
    • Controllo di concessione: Blocca
    • Stato: solo report
  • Criterio 4: Blocca EAS in modo esplicito
    • Nome: EM004 - ENABLE IN EMERGENCY: MFA Disruption[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 Sincronizzazione attiva
    • Controllo di concessione: 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 al dominio che non si trovino nei gruppi di esclusione possano 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 trovino nel gruppo di esclusione non possano accedere a SharePoint Online e Exchange Online dai propri 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 trovino nei gruppi di esclusione non possano accedere a SharePoint e Exchange fuori dalla rete aziendale, anche con un computer aggiunto al 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 nativa nei dispositivi mobili.
  6. Disabilitare i criteri di autenticazione a più fattori esistenti per SharePoint Online ed Exchange Online.

In questo esempio , 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, in genere, il cliente richiede che l'accesso a Salesforce (configurato per l'accesso singolo con Azure AD) 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 concederanno 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 nel team SalesContingency
    • Name: EM001 - ENABLE IN EMERGENCY: Device Compliance Disruption[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
    • Controllo di concessione: Blocca
    • Stato: solo report
  • Criterio 2: Bloccare il team sales da qualsiasi piattaforma diversa da mobile (per ridurre l'area di attacco)
    • Nome: EM002 - ENABLE IN EMERGENCY: Interruzione della conformità del dispositivo[2/2] - Salesforce - Blocca tutte le piattaforme tranne iOS e Android
    • Utenti e gruppi: includere SalesforceContingency. Escludere SalesAdmins
    • App cloud: Salesforce
    • Condizioni: La piattaforma dispositivi include tutte le piattaforme, escludere iOS e Android
    • Controllo di concessione: 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 computer portatili Windows/Mac, ma possono comunque accedere dai propri dispositivi mobili. Verificare che SalesAdmin possa comunque accedere a Salesforce da qualsiasi dispositivo.
  4. Disabilitare i criteri di conformità del dispositivo esistenti per Salesforce.

Contingencies for user lockout from on-prem resources (estensione NPS)

Se si protegge l'accesso VPN usando Azure AD estensione NPS MFA, prendere in considerazione la federazione della soluzione VPN come app SAML e determinare la categoria di app come consigliato di seguito.

Se è stata distribuita Azure AD estensione MFA NPS per proteggere le risorse locali, ad esempio VPN e Gateway Desktop remoto, con MFA, è consigliabile considerare 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 criteri di rete verificherà solo l'autenticazione primaria e non applichererà l'autenticazione 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 la chiave Parametri.
  • Riavviare il servizio Servizio criteri di rete (IAS) per le modifiche da apportare
  • Determinare se l'autenticazione primaria per VPN ha esito positivo.

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

  • Importare la chiave del Registro di sistema da HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AuthSrv\Parameters di backup
  • Riavviare il servizio Servizio criteri di rete (IAS) per le modifiche da apportare
  • Determinare se l'autenticazione primaria e l'autenticazione secondaria per VPN ha esito positivo.
  • Esaminare il server dei criteri di rete e il log VPN per determinare quali utenti 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 Azure AD 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 dei rischi segnalati dopo l'interruzione dell'attività sospetta.
  6. Revocare tutti i token di aggiornamento rilasciati usando PowerShell e destinati a 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 caso di emergenza e l'organizzazione non ha implementato in precedenza un piano di mitigazione o di emergenza, seguire le raccomandazioni nella sezione Contingencies for user lockout se usano già criteri di accesso condizionale per applicare MFA. 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 di rischio associati agli indirizzi IP (ad esempio, i percorsi impossibili o non familiari) non verranno generati.

Nota

La configurazione di indirizzi IP attendibili per Azure AD MFA è disponibile solo con licenze di Azure AD Premium.

Altre informazioni