Il modello di responsabilità condivisa guida ogni decisione

Prima di scegliere un controllo, l’architetto deve stabilire chi possiede quel layer. La regola pratica: quanto più il servizio è gestito, tanto più la superficie che rimane in carico al cliente si sposta dall’infrastruttura verso identità, dati e configurazione.

  • IaaS (VM, dischi, VNet): il cliente possiede OS, patching, network, endpoint. Qui hanno senso agent, EDR, hardening del guest, NSG.
  • PaaS (Azure SQL, App Service, Storage, Key Vault): Microsoft gestisce host e runtime; il cliente controlla configurazione del servizio, autenticazione, esposizione di rete (public endpoint vs Private Link) e chiavi.
  • SaaS (Microsoft 365, servizi di terze parti): resta al cliente quasi solo identità, condivisione, DLP e governance dei dati — dominio di Entra ID, Purview e Defender for Cloud Apps.

Il rischio architetturale ricorrente è trattare tutto come IaaS: pretendere un agent o una regola NSG su un servizio PaaS che non espone né OS né subnet, sprecando effort e lasciando scoperti i controlli che contano davvero (identity e data-plane).

MCSB come lingua franca dei controlli

Il Microsoft Cloud Security Benchmark (MCSB) è la baseline autoritativa: raccoglie i controlli per dominio (Network Security, Identity Management, Data Protection, Posture and Vulnerability Management, Logging and Threat Detection…) e li mappa a CIS, NIST 800-53 e PCI-DSS. È il riferimento da citare quando lo scenario chiede “una baseline coerente tra più servizi e più cloud”.

La catena operativa da progettare è:

  1. MCSB definisce l’intento del controllo.
  2. Azure Policy (iniziative Microsoft Cloud Security Benchmark) lo rende misurabile e applicabile su una scope gerarchica (Management Group → Subscription → Resource Group).
  3. Microsoft Defender for Cloud consuma la policy come standard di compliance nel pannello Regulatory Compliance e produce Secure Score e recommendation azionabili.

Azure Policy: dal deny reattivo all’audit continuo

Il trade-off centrale è flessibilità dei team di sviluppo vs guardrail imposti. La leva è la scelta dell’effect:

  • Deny: blocca la creazione di risorse non conformi (es. Storage con allowBlobPublicAccess=true, SQL senza Entra-only auth). Massima protezione, minima libertà — adatto a controlli non negoziabili.
  • Audit / AuditIfNotExists: registra la non conformità senza bloccare. Ideale in fase di adozione, per non fermare i team mentre si misura il gap.
  • DeployIfNotExists / Modify: rimedia automaticamente (abilita diagnostic settings, installa estensioni). Sposta il carico dal team verso la piattaforma.

Pattern raccomandato per l’esame: guardrail deny sui rischi critici e irreversibili, audit + remediation sul resto, il tutto distribuito come iniziativa a livello di Management Group così ogni nuova subscription eredita la baseline (landing zone). Questo è il compromesso che concilia velocità di delivery e postura difendibile.

Defender for Cloud: il piano giusto per ogni tipologia di servizio

Defender for Cloud opera su due assi da non confondere:

  • CSPM (posture): il Foundational CSPM è gratuito e dà Secure Score + recommendation MCSB. Il Defender CSPM (a pagamento) aggiunge attack path analysis, cloud security graph, agentless scanning e governance rules.
  • Workload protection (CWPP): piani per tipologia di risorsa, da abilitare selettivamente. Defender for Servers (IaaS, integra Defender for Endpoint), Defender for Storage, for SQL, for App Service, for Containers, for Key Vault, for APIs.

La scelta è per superficie reale: su una web app PaaS attivo Defender for App Service e Defender for Storage sul relativo account, non Defender for Servers. Su una VM che ospita un DB attivo Defender for Servers e for SQL on machines.

Trappole tipiche d’esame

  • Requisito: impedire alla radice la creazione di Storage con blob pubblici su decine di subscription → NON affidarsi a un allarme Defender (reattivo): assegna un’iniziativa Azure Policy con effect Deny a livello di Management Group. Il deny previene, la recommendation solo rileva.
  • Requisito: baseline unica mappata a NIST/CIS su servizi eterogenei → NON scrivere policy custom da zero: adotta MCSB e monta lo standard nel Regulatory Compliance di Defender for Cloud.
  • Scenario: proteggere un’app PaaS (App Service + Azure SQL) → NON pianificare agent/EDR o Defender for Servers: quelli sono per IaaS. Abilita Defender for App Service + for SQL e chiudi l’esposizione con Private Link, non con NSG sull’“OS” (inesistente).
  • Requisito: i team dev devono continuare a rilasciare, ma serve misurare il gap prima di irrigidire → NON partire con Deny ovunque: usa Audit/AuditIfNotExists in fase pilota e converti a Deny sui soli controlli critici una volta noto l’impatto.
  • Requisito: visibilità sui percorsi di attacco cross-resource e scansione senza agent → NON basta il CSPM gratuito: serve il Defender CSPM (attack path + security graph + agentless scanning).