Zero Trust come principio architetturale end-to-end

Zero Trust: una strategia, non un prodotto

Il primo errore architetturale — e la trappola d’esame più frequente in SC-100 — è trattare Zero Trust come qualcosa che si “compra e accende”. Zero Trust è un modello di sicurezza end-to-end che ridisegna il modo in cui concedi fiducia agli accessi. Nessun perimetro implicito: ogni richiesta viene valutata come se provenisse da una rete non attendibile. La Microsoft Cybersecurity Reference Architecture (MCRA) e la Zero Trust Guidance traducono questo modello in controlli concreti distribuiti su Microsoft Entra ID, Defender XDR, Defender for Cloud, Purview e Sentinel.

I tre principi guida vanno applicati contemporaneamente a ogni decisione:

• Verify explicitly — autentica e autorizza sempre sulla base di tutti i segnali disponibili (identità, salute del device, posizione, sensibilità del dato, comportamento).
• Use least privilege — accesso Just-In-Time e Just-Enough-Access, policy adattive basate sul rischio, protezione dei dati.
• Assume breach — segmenta per contenere il raggio d’azione, cifra end-to-end, usa analytics per rilevare e rispondere.

Mappare i sei pilastri ai controlli

Il framework organizza i controlli su sei pilastri. Il compito dell’architetto è partire dal requisito del cliente e risalire al controllo, non elencare prodotti.

• Identity — il piano di controllo primario. Requisito “accesso condizionato al rischio” → Entra Conditional Access con segnali di Identity Protection (user/sign-in risk) e MFA phishing-resistant (FIDO2, Passkey, certificate-based). Per accessi privilegiati → PIM (JIT + approvazione).
• Endpoints — requisito “solo device sani e gestiti” → compliance Intune come condizione in Conditional Access, con segnali di Defender for Endpoint.
• Apps — requisito “visibilità e controllo sulla shadow IT / sessioni rischiose” → Defender for Cloud Apps e App Governance; app moderne integrate via Entra con scoping dei permessi.
• Data — requisito “protezione che segue il dato” → Microsoft Purview con classificazione, sensitivity label e cifratura persistente; DLP e Insider Risk Management.
• Infrastructure — requisito “hardening e detection su workload cloud/ibridi” → Defender for Cloud (CSPM + CWP), baseline e JIT VM access.
• Network — requisito “micro-segmentazione e ispezione” → segmentazione, private endpoint, Azure Firewall/WAF, eliminazione degli accessi flat.

Su tutto, Microsoft Sentinel fornisce il livello SIEM/SOAR che realizza operativamente “assume breach”: correlazione dei segnali cross-pillar e risposta automatizzata.

Il trade-off: percorso incrementale vs big-bang

La domanda architetturale ricorrente è la strategia di adozione. Un approccio big-bang — riprogettare tutti i pilastri in un unico programma — promette coerenza ma nella pratica genera rischio operativo elevato, resistenza degli utenti e blocco della produttività; raramente è raccomandabile per un’organizzazione con estate legacy.

La raccomandazione da architetto è quasi sempre un percorso di maturità incrementale (traditional → advanced → optimal), che permette di dimostrare valore rapidamente e correggere la rotta. La leva decisionale è il rischio residuo: si prioritizza dove l’esposizione è massima e il controllo attuale è minimo.

In chiave Azure Well-Architected Framework, questo bilancia il pilastro Security con Operational Excellence e Reliability: introdurre Conditional Access in enforcement senza fase di report-only viola l’affidabilità operativa; irrigidire i privilegi senza PIM danneggia la produttività.

Priorità tipica basata sul rischio: (1) mettere in sicurezza l’identità — MFA phishing-resistant, eliminazione legacy auth, PIM sugli admin; (2) portare i device sotto compliance; (3) proteggere i dati critici con label e DLP; (4) segmentare rete e workload. L’identità precede tutto perché è il vettore di attacco più sfruttato e il moltiplicatore di ogni altro controllo.

Trappole tipiche d’esame

• Requisito: “adottare Zero Trust” con budget e tempi limitati → NON un unico progetto big-bang, ma roadmap incrementale che parte dal pilastro Identity (massimo rischio residuo, massimo ritorno). Zero Trust è strategia, non deployment one-shot.
• Requisito: “bloccare l’accesso da device non conformi alle app SaaS” → Conditional Access con condizione di compliance Intune + segnale Defender for Endpoint, non una regola di firewall di rete (il perimetro non è più il controllo primario).
• Requisito: “la protezione deve seguire il documento anche fuori dal tenant” → sensitivity label di Microsoft Purview con cifratura persistente, non una semplice DLP di rete o permessi di SharePoint (che non viaggiano col file).
• Requisito: “ridurre lo standing access degli amministratori” → Entra PIM (JIT + approvazione + access review), non aggiungere semplicemente MFA agli account admin permanenti (MFA verifica, ma non rimuove il privilegio permanente → viola least privilege).
• Requisito: “rilevare movimento laterale post-compromissione” → assume breach con Sentinel + Defender XDR per correlazione cross-pillar, non affidarsi solo a controlli preventivi di accesso (che presuppongono di non essere già stati violati).