I tre principi di Zero Trust

Zero Trust non è un prodotto che si accende, è l’approccio di sicurezza che la documentazione Microsoft riassume in un’idea sola: “never trust, always verify”. L’accesso viene concesso solo dopo aver verificato chi lo sta chiedendo, quale dispositivo sta usando, da dove e con quale comportamento, e con quale livello di rischio. E la verifica non avviene una volta sola all’ingresso: è continua per tutta la durata della sessione.

Su questa base la doc enuncia tre principi, e per l’esame vanno saputi con questi nomi:

  • Verify explicitly — ogni richiesta di accesso viene, testualmente, “authenticated and authorized using all available signals”. Notare che il principio contiene entrambi i verbi: prima si stabilisce l’identità, poi si stabilisce il diritto di accesso. È la formulazione stessa del principio a tenere separate le due cose.
  • Use least privilege access — utenti e workload ricevono solo l’accesso di cui hanno bisogno, e per il tempo più breve necessario. Nel Microsoft 365 admin center questo principio si traduce in una raccomandazione esplicita: usare i ruoli con il minor numero di permessi e limitare quante persone hanno permessi amministrativi. In concreto, a chi deve solo consultare report e impostazioni su Copilot e agenti si assegna AI Reader, non AI Administrator; e a chi deve solo resettare password si assegna Password Administrator o Helpdesk Administrator, non Global Administrator.
  • Assume breach — i controlli si progettano dando per scontato che un attaccante possa già operare dentro l’ambiente. L’obiettivo si sposta dal tenerlo fuori a limitare l’impatto della compromissione e ad accelerare rilevamento e risposta.

Piccola nota terminologica utile a non farsi spiazzare: nella pagina che applica Zero Trust a Microsoft 365 Copilot il secondo principio compare scritto come Use least privileged access. È lo stesso principio, con una lettera in più.

Autenticazione e autorizzazione non sono sinonimi

Questa è la distinzione che l’esame verifica quasi certamente, e sulla quale si costruiscono i distrattori più insidiosi.

L’autenticazione è il processo con cui si dimostra di essere chi si dichiara di essere: verifica l’identità di una persona o di un dispositivo, e la doc la abbrevia in AuthN. La piattaforma di identità Microsoft usa il protocollo OpenID Connect per gestirla.

L’autorizzazione è l’atto di concedere a una parte già autenticata il permesso di fare qualcosa: stabilisce a quali dati si può accedere e cosa ci si può fare, e si abbrevia in AuthZ. Qui il protocollo è OAuth 2.0, ma non è l’unico meccanismo: la doc elenca anche i Microsoft Entra built-in roles, Azure RBAC e Exchange RBAC come sistemi di autorizzazione distinti. Questo spiega perché l’autorizzazione, a differenza dell’autenticazione, non si configura in un unico posto.

L’ordine è la chiave mnemonica: prima AuthN, poi AuthZ. Un utente autenticato correttamente può essere perfettamente autorizzato a nulla, e non è un errore di configurazione — è least privilege che funziona.

Lo stesso schema vale per le app e per gli agenti, non solo per le persone. Le delegated permissions valgono nello scenario in cui l’app agisce a nome di un utente che ha fatto l’accesso, e la doc è netta: l’applicazione non riesce ad accedere a niente a cui l’utente stesso non potrebbe accedere. Le application permissions (chiamate anche app roles) valgono invece senza utente collegato, e possono essere approvate solo da un amministratore. Con lo user consent è l’utente ad autorizzare per i propri dati; con l’admin consent l’amministratore autorizza per sé o per l’intera organizzazione.

I metodi di autenticazione e la resistenza al phishing

La multifactor authentication funziona richiedendo due o più metodi appartenenti a categorie diverse: qualcosa che sai, tipicamente una password; qualcosa che hai, come un dispositivo attendibile non facilmente duplicabile — un telefono o una chiave hardware; qualcosa che sei, cioè dati biometrici come impronta digitale o scansione del volto.

Microsoft Entra ID distingue per ogni metodo tre usi possibili: primary authentication (primo fattore), secondary authentication con MFA, e SSPR / Account recovery. La password serve solo come primo fattore, mai come secondo. Passkey (FIDO2), Windows Hello for Business, certificate-based authentication e Microsoft Authenticator possono coprire il primo fattore e l’MFA. Voice call, software OATH tokens ed Email OTP non fanno da primo fattore. Attenzione a Verified ID: la doc lo qualifica come capacità di verifica dell’identità, non come metodo di autenticazione tradizionale, e serve al recupero dell’account — non a fare sign-in, MFA o SSPR.

Non tutti i fattori aggiuntivi valgono lo stesso. SMS, email OTP e app di autenticazione migliorano molto rispetto alla sola password, ma la doc li descrive come esposti ad attacchi di phishing remoto: l’attaccante ruba la credenziale o il codice usa-e-getta senza mai toccare il dispositivo della vittima. I metodi che Microsoft elenca come phishing-resistant sono Windows Hello for Business, Platform Credential for macOS, synced passkeys (FIDO2), FIDO2 security keys, passkeys in Microsoft Authenticator e certificate-based authentication.

Il motivo tecnico va capito, non memorizzato: le passkey usano crittografia a chiave pubblica legata all’origine e richiedono un’interazione locale dell’utente. La chiave privata resta sul dispositivo, la chiave pubblica sta presso il sito o l’app, e servono entrambe — quindi quella passkey funziona solo sul sito per cui è stata creata, e un attaccante non può indurti a usarla su un dominio che controlla lui. Le device-bound passkeys tengono la chiave privata su un solo dispositivo fisico; le synced passkeys la sincronizzano attraverso un cloud passkey provider.

Il punto in cui questa gerarchia diventa operativa è Conditional Access: con il controllo Require authentication strength si scelgono tre livelli predefiniti — Multifactor authentication strength, Passwordless MFA strength e Phishing-resistant MFA strength — e si può pretendere il più alto solo sulle risorse sensibili. Dove Conditional Access non è disponibile, il ripiego indicato sono i security defaults.

Che cosa verifica l’esame

A livello fundamentals nessuno chiede di configurare una policy. Chiedono di riconoscere il concetto giusto. Le trappole ricorrenti sono tre. La prima è lo scambio dei termini: se la domanda descrive “stabilire quali dati un utente può leggere”, la risposta è autorizzazione, anche se il testo parla di accesso e di sign-in. La seconda è dare per equivalenti MFA e resistenza al phishing: password più SMS è MFA a tutti gli effetti, ma non è phishing-resistant. La terza è trattare Zero Trust come una funzionalità da attivare, quando è un insieme di principi che si realizzano attraverso strumenti diversi — ruoli, Conditional Access, metodi di autenticazione.