Authentication strengths (Preview) in Azure AD

In Azure AD esistono diversi metodi di autenticazione e di verifica e ho avuto modo già di presentarveli in altri articoli che ho scritto, parlandovi di autenticazione senza password (passwordless), Windows Hello, chiavi di sicurezza FIDO2, app Microsoft Authenticator, ecc.

Azure AD Multifactor Authentication (MFA) aggiunge ulteriore sicurezza rispetto al semplice uso di una password per l’accesso dell’utente. All’utente possono venire richieste altre forme di autenticazione, ad esempio rispondere a una notifica push, immettere un codice da un token software o hardware oppure rispondere a un SMS o a una telefonata.

La tabella seguente illustra alcune considerazioni sul livello di sicurezza dei metodi di autenticazione disponibili. La colonna disponibilità si riferisce alla possibilità per l’utente di usare il metodo di autenticazione e non alla disponibilità del servizio in Azure AD:

Figura 1: Metodi di autenticazione disponibili in Azure AD

Alcuni metodi di autenticazione possono essere usati come fattore primario quando si accede a un’applicazione o un dispositivo, ad esempio usando una chiave di sicurezza FIDO2 o una password. Altri metodi di autenticazione sono disponibili solo come fattore secondario quando si usa Azure AD Multifactor Authentication o la reimpostazione della password self-service.

La tabella seguente illustra quando è possibile usare un metodo di autenticazione come primario o secondario durante un evento di accesso:

Figura 2: Metodi di autenticazione utilizzabili durante un evento di accesso

Authentication strengths

In Azure AD sono attualmente disponibili in preview come metodi di autenticazione gli Authentication strengths.

Un Authentication Strenght può includere una combinazione di metodi di autenticazione. Gli utenti possono soddisfare i requisiti richiesti da un’autenticazione forte utilizzando una delle combinazioni consentite.

Ad esempio, la combinazione Phishing-resistant MFA prevede che si possano utilizzare Windows Hello for Business oppure FIDO2 security key oppure Azure AD Certificate-Based Authentication (Multi-Factor).

Figura 3: Phishing-resistant MFA in Authetication Strenght

Nella tabella seguente sono elencate le combinazioni di metodi di autenticazione per ogni authentication strenght predefinito. A seconda dei metodi disponibili, gli utenti possono usare una delle combinazioni per l’accesso.

Figura 4: Combinazione die metodi di autenticazione per ogni authentication strenght attualmente disponibile

Creazione di Authentication Strenght personalizzati

Oltre agli Authentication Stregnht predefiniti è anche possibile crearne di personalizzati. Dal portale di Azure AD navigate in Azure Active Directory > Security > Authentication methods > Authentication strengths (Preview). Fate clic su + New authentication strenght e selezionate solo le opzioni che volete rendere disponibili.

Io ho deciso di forzare l’utilizzo di chiavi FIDO2 ed in particolare della chiave Feitian K26, di cui ho già parlato nell’articolo Abilitare il passwordless sign-in per Azure AD e per Microsoft 365 utilizzando una security key FIDO2 biometrica – ICT Power

Figura 5: Creazione di una nuova Authentication Strenght che utilizza le chiavi FIDO2 e le opzioni disponibili

Nel caso delle chiavi hardware FIDO2 è possibile filtrare il tipo di chiavi autorizzate, inserendo il loro AAGUID. L’AAGUID è UNICO per ogni modello di chiave e non per ogni singola chiave.

Cliccate su Advanced Options ed inserite gli AAGUID delle chiavi da filtrare. Io ho inserito l’AAGUID della mia chiave Feitian K26 che ho recuperato dalla pagina https://fido.ftsafe.com/products/ . È possibile visualizzare l’AAGUID della chiave anche visitando la pagina delle proprie security Info, dove avete registrato i dispositivi di autenticazione https://mysignins.microsoft.com/security-info .

Figura 6: L’AAGUID della security key FIDO2 è visibile anche nella pagina delle Security Info dell’utente

NOTA: Potete trovare diversi articoli sui prodotti Feitian utilizzando la chiave di ricerca https://www.ictpower.it/?s=feitian

Figura 7: Inserimento dell’ AAGUID della chiave FIDO2 Feitian K26

Figura 8: Completamento della procedura di creazione della nuova Authentication Strenght

Figura 9: La nuova Authentication Strenght è disponibile e può essere utilizzata

Figura 10: FEITIAN BioPass K26

Utilizzo delle Authentication Strenght nelle policy di accesso condizionale

È adesso possibile utilizzare queste combinazioni di metodi di autenticazione forte nelle policy di accesso condizionale alle applicazioni che richiedono Azure AD per l’autenticazione. In questo modo possiamo richiedere metodi di autenticazione diversi a seconda dell’applicazione e di chi dovrà utilizzare quell’applicazione, forzando ad esempio gli amministratori all’utilizzo di un’autenticazione a più fattori (MFA) più forte rispetto a quella dei normali utenti.

Come si può vedere dalla figura sotto, nelle regole di controllo dell’accesso è disponibile la voce Require authentication strenght (preview) e sono selezionabili le combinazioni disponibili, compresa quella personalizzata che abbiamo appena creato. Una volta selezionata questa opzione, la voce Require multifactor authentication non sarà più selezionabile.

Figura 11: Utilizzo di Require authentication strenght (preview) nelle regole di controllo dell’accesso

Test di funzionamento

Se l’utente tenta di entrare nell’applicazione e di autenticarsi tramite Azure AD senza utilizzare il metodo che abbiamo imposto riceverà un avviso come quello mostrato nella figura sotto. Inizialmente, infatti, mi sono autenticato ad Azure AD utilizzando la passwordless authentication e utilizzando l’app Microsoft Authenticator. Nella finestra successiva, dopo essermi autenticato, sono stato invitato ad utilizzare un metodo diverso, cioè quello più forte imposto dalla authentication strenght.

Figura 12: Richiesta di verifica dell’identità utilizzando il metodo della authentication strenght definita nella policy di accesso condizionale

Se l’utente non usa una delle security key FIDO2 autorizzate non sarà capace di effettuare l’accesso. Come si può vedere dalla figura sotto, ho utilizzato una chiave diversa da quelle autorizzate (non ho usato la Feitian K26) e non è stato possibile accedere, perché la policy di accesso condizionale non me lo ha permesso.

Figura 13: Utilizzando una security key FIDO2 diversa da quelle autorizzate, la policy di accesso condizionale non permette l’accesso

Conclusioni

In Azure AD è possibile migliorare la sicurezza degli accessi imponendo delle policy diverse di accesso condizionale per amministratori e per utenti standard, che prevedano l’utilizzo di metodi più forti di multifactor authentication o di passworless authentication. I metodi di autenticazione definiti dagli authentication strength permettono di definire strategie diverse e migliorano di fatto l’impatto che la sicurezza ha sulla nostra quotidianità.