Ridurre i rischi di attacchi utilizzando Azure AD Security Defaults

Già dal 22 ottobre 2019 Microsoft ha cominciato ad abilitare gli Azure AD Security Defaults sui nuovi tenants, ma da giugno 2022 ha iniziato una campagna per abilitarli sui tenant che finora non l’hanno fatto oppure hanno abilitato l’accesso condizionale di Azure AD o li hanno disabilitati (argh!).

Eh sì, perché molte aziende hanno disabilitato i security defaults per problemi di autenticazione di software obsoleti o semplicemente perché la multi-factor authentication (MFA) dava “fastidio” agli utenti.

Gli attacchi correlati all’identità, ad esempio il password spray, il replay e il phishing sono molto comuni oggi. Oltre il 99,9% di questi attacchi correlati all’identità vengono invalidati grazie all’utilizzo dell’autenticazione a più fattori (MFA) e bloccando l’autenticazione legacy.

Abbiamo già trattato questi argomenti in precedenti guide su ICTPower.it. Vi invito a leggere i nostri articoli sulla multi-factor authentication di Azure AD, sulla passwordless authentication di Azure AD e sulla modern authentication di Azure AD.

I security defaults (impostazioni predefinite di sicurezza) non hanno costi aggiuntivi e semplificano la protezione dell’azienda dagli attacchi più comuni perpetrati a danno delle identità, abilitando le seguenti impostazioni di sicurezza:

  • Obbligo per tutti gli utenti di eseguire la registrazione per Azure AD Multi-Factor Authentication.
  • Obbligo per gli amministratori di eseguire l’autenticazione a più fattori.
  • Obbligo per gli utenti di eseguire l’autenticazione a più fattori quando necessario.
  • Blocco dei protocolli di autenticazione legacy.
  • Protezione delle attività che richiedono dei privilegi come, ad esempio, l’accesso al portale di Azure.

Abilitazione delle impostazioni predefinite per la sicurezza

Da qualche giorno potrebbe essere apparso a qualcuno di voi un messaggio che invita ad attivare i security defaults entro 14 giorni. In caso contrario, questi verranno abilitati automaticamente da Microsoft. Nella figura sotto è possibile visualizzare il messaggio quando si effettua l’autenticazione ad Azure AD.

Figura 1: Schermata di accesso ad Azure AD che invita ad abilitare i security defaults

Per abilitare i security defaults è sufficiente collegarsi al portale di Azure AD con le credenziali di un Global Admin e da Azure Active DirectoryàProperties cliccare sulla voce Manage security defaults e selezionare Yes su Enable security defaults.

Figura 2: Abilitazione dei Security Defaults

Nel caso nel vostro tenant abbiate abilitato regole di accesso condizionale vi apparirà un messaggio di errore come quello mostrato nella figura sotto. Le due funzionalità sono incompatibili, quindi per abilitare i security defaults è necessario prima disabilitare tutte le policy di accesso condizionale che avete creato.

Se l’azienda ha requisiti di sicurezza complessi o se è necessario un controllo più granulare sui criteri di sicurezza, è consigliabile usare l’accesso condizionale anziché le impostazioni predefinite di sicurezza.

L’accesso condizionale consente di creare e definire criteri che reagiscono agli eventi di autenticazione e richiedono altre azioni prima che un utente sia autorizzato ad accedere a un’applicazione o un servizio. I criteri di accesso condizionale possono essere granulari e specifici, consentendo agli utenti di essere produttivi sempre e ovunque, ma anche di proteggere l’azienda.

Figura 3: I Security Defaults e le regole di accesso condizionale sono incompatibili

Figura 4: Abilitazione dei security defaults

Se disabilitate i security defaults dovrete fornire una giustificazione, come ad esempio motivando che state utilizzando le regole di accesso condizionale oppure che avete problemi di autenticazione a causa di troppe richieste di utilizzo della Multi-Factor Authentication (MFA).

Figura 5: La disabilitazione dei Security Defaults deve essere motivata

Tutti gli utenti del tenant devono registrarsi per l’autenticazione a più fattori (MFA) e hanno 14 giorni per la registrazione. Possono usare l’app Microsoft Authenticator o qualsiasi app che supporta OATH TOTP. Dopo aver superato i 14 giorni, l’utente non può accedere fino al completamento della registrazione. Il periodo di 14 giorni di un utente inizia dopo il primo accesso interattivo completato dopo l’abilitazione delle impostazioni predefinite per la sicurezza.

L’utilizzo dell’app Microsoft Authenticator non richiede licenze aggiuntive ed è gratuita. Gli altri metodi di autenticazione invece richiedono la licenza Azure AD Premium P1 o P2.

Figura 6: Gli utenti hanno 14 giorni per la registrazione per Azure AD Multi-Factor Authentication

Obbligo per gli amministratori di eseguire l’autenticazione a più fattori

Gli amministratori di Azure AD devono essere trattati con maggiore cura a causa del loro potere ed è obbligatorio che abbiano abilitato l’autenticazione a più fattori.

Dopo aver abilitato i security defaults e dopo aver completato la registrazione con Azure AD Multi-Factor Authentication, i seguenti ruoli amministrativi avranno l’obbligo di utilizzo della MFA:

  • Global administrator
  • Application administrator
  • Authentication administrator
  • Billing administrator
  • Cloud application administrator
  • Conditional Access administrator
  • Exchange administrator
  • Helpdesk administrator
  • Password administrator
  • Privileged authentication administrator
  • Security administrator
  • SharePoint administrator
  • User administrator

Account amministratore di backup

Ogni organizzazione deve avere almeno due account di amministratore di backup configurati. Questi account possono essere usati negli scenari in cui non è possibile usare gli account di amministratore normali. Le credenziali per questi account di accesso di emergenza devono essere archiviate offline in una posizione sicura, ad esempio in una cassaforte ignifuga. È possibile scegliere di disabilitare la scadenza della password per questi account usando Azure AD PowerShell.

Richiedere agli utenti di eseguire l’autenticazione a più fattori quando necessario

Si tende a pensare che gli account amministratore siano gli unici account che richiedono livelli aggiuntivi di autenticazione. Gli amministratori hanno accesso esteso alle informazioni sensibili e possono apportare modifiche alle impostazioni a livello di sottoscrizione. Ma gli utenti malintenzionati spesso hanno come obiettivo gli utenti finali.

Dopo che questi utenti malintenzionati ottengono l’accesso, possono richiedere l’accesso alle informazioni con privilegi per il titolare dell’account originale. Possono anche scaricare l’intera directory per eseguire un attacco di phishing sull’intera azienda.

Diventa quindi di fatto necessario che TUTTI gli utenti della vostra azienda utilizzino l’MFA.

Blocco dei protocolli di autenticazione legacy

Per consentire agli utenti di accedere facilmente alle app cloud, Azure AD supporta diversi protocolli di autenticazione, tra cui l’autenticazione legacy. Con il termine autenticazione legacy si fa riferimento a una richiesta di autenticazione effettuata da:

  • Client che non usano l’autenticazione moderna (ad esempio, un client Office 2010).
  • Qualsiasi client che usi protocolli di posta elettronica precedenti come IMAP, SMTP o POP3.

Oggi, la maggior parte dei tentativi di accesso da parte di malintenzionati proviene dall’autenticazione legacy, perché non supporta l’autenticazione a più fattori.

Una volta abilitate le impostazioni predefinite per la sicurezza nel tenant, tutte le richieste di autenticazione effettuate da un protocollo legacy verranno bloccate. Quindi è necessario verificare prima che non ci siano disservizi dovuti a questa attivazione e che tutte le applicazioni funzionino correttamente.

Accesso condizionale

Come già scritto prima, è possibile usare l’accesso condizionale per configurare criteri simili alle impostazioni predefinite per la sicurezza, ma con maggiore granularità. I criteri di accesso condizionale consentono di selezionare altri metodi di autenticazione e la possibilità di escludere gli utenti, che non sono disponibili nelle impostazioni predefinite di sicurezza.

Le impostazioni predefinite di sicurezza sono disponibili per tutti i clienti, mentre l’accesso condizionale richiede uno dei piani seguenti:

  • Azure AD Premium P1 o P2.
  • Microsoft 365 Business Premium
  • Microsoft 365 E3 o E5
  • Enterprise Mobility & Security E3 o E5

Se si tenta di creare una regola di accesso condizionale quando i security defaults sono abilitati. Un banner nel wizard di creazione ci avviserà che sarà necessario prima disabilitarli, come mostrato nella figura sotto:

Figura 7: Se si usano le impostazioni predefinite per la sicurezza, è necessario disattivarle prima di usare l’accesso condizionale. Non si possono usare entrambi contemporaneamente

Conclusioni

Le impostazioni predefinite di sicurezza sono state progettate per proteggere gli account utente dell’azienda fin dall’inizio. L’autenticazione a più fattori è un primo passaggio importante per proteggere l’azienda e i security defaults semplificano l’implementazione della MFA.

Appare chiaro che la disabilitazione dei protocolli legacy e l’imposizione dell’MFA creino non pochi problemi alle aziende e richiedano che ci sia una maggiore sensibilizzazione verso i temi della cybersecurity. “Svecchiare” i software o convincere gli utenti dei vantaggi dell’MFA non sono certo operazioni semplici, ma il buon senso ormai ci obbliga a considerare di implementare questi cambiamenti il prima possibile.