• Cloud, Guide, Microsoft 365, Sicurezza
• 1 Dicembre 2023

Grazie alle Protected actions dei ruoli di Microsoft Entra ID abbiamo la possibilità di aumentare la sicurezza quando vengono fatte alcune operazioni che richiedono permessi privilegiati. Le Protected Actions sono azioni che richiedono un livello di sicurezza più elevato per essere eseguite, come ad esempio la modifica delle impostazioni di sicurezza, l’aggiunta di un nuovo dispositivo o la gestione degli account utente. Il Conditional Access di Entra ID è una funzionalità che consente di definire delle regole per richiedere una verifica aggiuntiva dell’identità dell’utente prima di consentire l’esecuzione di una Protected Action. In questo modo, si riduce il rischio di accessi non autorizzati o di attacchi informatici.

Attualmente l’utilizzo di questa funzionalità è consentito in:

• Portale di Azure Active Directory
• Portale di Microsoft Entra
• Microsoft Graph PowerShell
• Microsoft Graph Explorer

Per utilizzare le Protected actions in Entra ID Conditional Access abbiamo bisogno delle licenze Entra ID Premium 1.

Questo tipo di funzionalità è sicuramente interessante per implementare la Zero Trust Security, un modello di protezione della rete basato su una filosofia ben definita, ossia che l’accesso ai servizi o sistemi IT di un’azienda da parte di persone o dispositivi, interni o esterni alla rete aziendale, deve essere possibile solo previa autenticazione e costante verifica. Con il modello Zero Trust, nessun utente o dispositivo è considerato affidabile per accedere a una risorsa fino a quando non ne vengono verificate l’identità e l’autorizzazione. Bisogna verificare sempre e non fidarsi mai!

Il modello Zero Trust si basa su metodi di autenticazione e autorizzazione efficaci per ogni dispositivo e persona, prima di consentire l’accesso o il trasferimento dei dati su una rete privata, indipendentemente dal fatto che si trovino all’interno o all’esterno del perimetro di rete.

Il modello Zero Trust di Microsoft

Microsoft suggerisce 3 principi fondamentali del modello Zero Trust:

• Verifica esplicita: Autentica e autorizza sempre sulla base di tutti i punti dati disponibili, inclusi identità utente, posizione, sicurezza dei dispositivi, servizio o carico di lavoro, classificazione dei dati e anomalie.
• Utilizzo di almeno un accesso privilegiato: Limita l’accesso degli utenti con JIT/JEA (just-in-time and just-enough-access), politiche adattive basate sul rischio e protezione dei dati, per garantire la sicurezza dei dati e la produttività.
• Ipotesi di violazione: Riduce al minimo il raggio d’azione e l’accesso al segmento. Verifica la crittografia end-to-end e utilizza l’analisi per ottenere visibilità, eseguire il rilevamento delle minacce e migliorare le difese.

Figura 1: Principi del Zero Trust secondo Microsoft

Come già detto, il modello Zero Trust presuppone una violazione e verifica ogni richiesta come se provenisse da una rete aperta. Indipendentemente dalla provenienza della richiesta o dalla risorsa a cui accede, Zero Trust ci insegna a non fidarci mai e a verificare sempre. Prima di consentire l’accesso, ogni richiesta viene completamente autenticata, autorizzata e crittografata. I principi della microsegmentazione e dell’accesso meno privilegiato vengono applicati per ridurre al minimo i movimenti laterali. Intelligence e analisi avanzate vengono utilizzate per rilevare e rispondere alle anomalie in tempo reale.

Figura 2: Approccio Zero Trust di Microsoft

Un approccio al modello Zero Trust deve estendersi all’intero patrimonio digitale, formato da identità, endpoint, rete, dati, app e infrastruttura. L’architettura Zero Trust funge da strategia end-to-end completa e richiede l’integrazione nei vari elementi.

Alla base della sicurezza Zero Trust ci sono le identità. Le identità umane e non umane necessitano di un’autorizzazione avanzata poiché si connettono da endpoint personali e aziendali con un dispositivo conforme, richiedendo quindi l’accesso basato su criteri complessi fondati sui principi Zero Trust di verifica esplicita, accesso con privilegi minimi e ipotesi di violazione.

Come applicazione di criteri unificati, i criteri Zero Trust intercettano la richiesta e verificano in modo esplicito i segnali dei 6 elementi fondamentali basati sulla configurazione criterio e applicano l’accesso con privilegi minimi. I segnali includono il ruolo dell’utente, la posizione, la conformità del dispositivo, la riservatezza dei dati, la riservatezza dell’applicazione e molto altro. Oltre ai dati telemetrici e alle informazioni sullo stato, la valutazione dei rischi dalla protezione dalle minacce fa sì che il motore dei criteri risponda automaticamente alle minacce in tempo reale. I criteri sono applicati al momento dell’accesso e valutati continuamente durante la sessione.

Questi criteri vengono ulteriormente rafforzati dall’ottimizzazione dei criteri. Governance e conformità sono aspetti fondamentali per un’implementazione di Zero Trust efficace. La valutazione della postura di sicurezza e l’ottimizzazione della produttività sono necessarie per misurare i dati telemetrici nei servizi e sistemi.

Quindi, riassumendo, cosa devo fare?

• Identità: Verifica e proteggi ciascuna identità con un’autenticazione efficace in tutto il tuo digital estate.
• Endpoint: Ottieni visibilità sui dispositivi che accedono alla rete. Verifica la conformità e lo stato integrità prima di consentire l’accesso.
• Applicazioni: Scopri se nella tua rete c’è shadow IT, cioè se qualcuno utilizza applicazioni non autorizzate, verifica le autorizzazioni in-app appropriate, ottieni l’accesso basato sull’analisi in tempo reale e monitora e controlla le azioni degli utenti.
• Dati: Passa da una protezione dati basata sul perimetro a una protezione basata sui dati. Utilizza l’intelligence per classificare ed etichettare i dati. Crittografa e limita l’accesso in base alle politiche organizzative.
• Infrastruttura: Utilizza la telemetria per rilevare attacchi e anomalie, bloccare e segnalare automaticamente i comportamenti a rischio e utilizzare i principi di accesso meno privilegiati.
• Rete: Assicurati che dispositivi e utenti non siano sicuri solo perché si trovano su una rete interna. Crittografa tutte le comunicazioni interne, limita l’accesso in base ai criteri e utilizza la microsegmentazione e il rilevamento delle minacce in tempo reale.

Creazione dell’authentication context

Entra ID Authentication context è una funzionalità di sicurezza pensata per proteggere ulteriormente i dati e le azioni nelle applicazioni quando si effettua l’autenticazione tramite Azure Active Directory. Queste applicazioni possono essere applicazioni personalizzate, applicazioni line-of-business personalizzate, applicazioni come SharePoint o applicazioni protette da Microsoft Defender for Cloud Apps.

Possiamo usare i contesti di autenticazione per rafforzare l’accesso ad applicazioni sensibili, come ad esempio siti di SharePoint che contengono dati riservati. Per accedere a questi siti possiamo imporre, tramite regole di accesso condizionale, che vengano utilizzati dei dispositivi di autenticazione particolari, come ad esempio le chiavi FIDO2, o vincolando l’accesso solo da un dispositivo gestito, magari dopo aver accettato delle condizioni di utilizzo.

Ne ho già parlato nell’articolo Utilizzare Azure AD Authentication context per proteggere l’accesso alle applicazioni – ICT Power

I contesti di autenticazione vengono gestiti nel portale di Microsoft Entra collegandosi a Protection > Conditional Access > Authentication contexts. Facendo clic su + New authentication context si può creare il nuovo contesto di autenticazione. Usate un nome riconoscibile, che verrà usato per identificare il contesto di autenticazione in Entra ID e tra applicazioni che usano contesti di autenticazione. È consigliabile usare nomi che possono essere usati tra diverse risorse. La casella di controllo Publish to apps quando selezionata annuncia il contesto di autenticazione alle app e li rende disponibili per l’assegnazione.

Figura 3: Creazione di un nuovo Authentication context

Figura 4: Creazione dell’authentication context completata

Sempre dal Microsoft Entra admin center selezionate Roles & admins > Protected actions > + Add protected actions per decidere quali azioni volete proteggere ed in quale contesto.

Figura 5: Creazione delle protected actions

Selezionate quindi dal menu a tendina il Conditional access authentication context da associare alle protected actions.

Figura 6: Scelta del Conditional access authentication context da associare alle protected actions

Da + Select permissions scegliete invece quali azioni e permessi volete proteggere. Al temine della scelta fate clic su Add.

Figura 7: Scelta dei permessi da proteggere

Salvate le vostre configurazioni facendo clic su Save.

Figura 8: Salvataggio delle protected actions

Figura 9: Protected actions create

Utilizzo degli authentication context nei criteri di accesso condizionale di Entra ID

Gli amministratori possono utilizzare i contesti di autenticazione nei criteri di accesso condizionale. Al momento della creazione o della modifica di una conditional access policy si può scegliere uno dei contesti pubblicati.

Create una nuova policy di accesso condizionale dal portale amministrativo di Microsoft Entra scegliendo Protection > Conditional Access > Policies > + New policy.

Figura 10: Creazione di una nuova policy di accesso condizionale

Date un nome alla policy e decidete quali utenti dovranno essere assoggettati alla policy di accesso condizionale.

Figura 11: Scelta del gruppo di utenti che dovrà essere assoggettato alla policy di accesso condizionale

In Assignments > Target resources scegliete dal menu a tendina la voce Authentication context e selezionate l’authentication context a cui la policy verrà applicata.

Figura 12: Scelta dell’authentication context a cui la policy verrà applicata

Scegliete a questo punto quale tipo di enforcement applicare. Come già scritto nella guida Authentication strengths (Preview) in Azure AD – ICT Power, in Azure AD sono attualmente disponibili 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 13: Scelta del controllo da effettuare e imposizione di un metodo di autenticazione forte

Figura 14: Completamento della creazione della policy di accesso condizionale

Figura 15: Policy di accesso condizionale creata con successo

Test di funzionamento

Supponiamo che l’amministratore si colleghi al portale amministrativo di Microsoft Entra e utilizzi la passwordless authentication. In questo esempio dovrà effettuare il matching del numero che appare a video con l’app Microsoft Authenticator.

Figura 16: Login al portale amministrativo con la passwordless authentication

Ha necessità di operare con le Named locations e vuole effettuare delle modifiche. Questa operazione è una protected action che abbiamo deciso di proteggere. Quando tenterà di modificare la Named Location gli verrà notiifcato che questa operazione è protetta e richiede un livello di accesso aggiuntivo, come mostrato nella figura sotto:

Figura 17: L’amministratore decide di modificare la configurazione di una Named Location

A questo punto interviene la regola di accesso condizionale basata sull’authentication context, che chiede all’amministratore di fornire una modalità di autenticazione che sia Phishing-resistant MFA (utilizzo di Windows Hello for Business oppure FIDO2 security key oppure Azure AD Certificate-Based Authentication (Multi-Factor)).

Io ho deciso di utilizzare una FIDO2 security key

Figura 18: Per effettuare la cancellazione della policy è necessario utilizzare una modalità di autenticazione combinazione Phishing-resistant

Dopo aver effettuato l’ulteriore autenticazione sarà possibile modificare o cancellare la Named Location. L’amministratore ha deciso di modificarla.

Figura 19: Dopo aver effettuato l’ulteriore autenticazione la policy viene cancellata

Figura 20: Named Location configurata con successo

Conclusioni

Le Protected actions sono una potente funzionalità che permette di applicare delle condizioni aggiuntive per l’accesso a determinate risorse o applicazioni. In questo modo, si può aumentare il livello di sicurezza e di conformità delle proprie aziende.

Questa funzionalità offre diversi vantaggi per la sicurezza e la gestione delle risorse aziendali, come ad esempio prevenire l’accesso non autorizzato ai dati sensibili o alle applicazioni critiche da parte di utenti o dispositivi compromessi o non conformi alle policy di sicurezza e ridurre il rischio di attacchi informatici basati su tecniche di phishing, spoofing, malware o brute force, limitando le azioni che possono essere eseguite da utenti o dispositivi sospetti o non verificati.