La protezione dei workload nel cloud (Cloud Workload Protection Platform, CWPP) è uno dei domini centrali dell’esame SC-100: come architetto devi progettare una strategia che copra macchine virtuali, container e pipeline DevOps senza lasciare superfici scoperte. Lo strumento di riferimento in Azure è Microsoft Defender for Cloud, la cui componente CWPP si articola in piani granulari attivabili per tipo di risorsa.

Defender for Servers: Plan 1 vs Plan 2

La prima decisione di design riguarda la protezione dei server (VM Azure, ma anche macchine on-premises e multicloud AWS/GCP tramite Azure Arc). Defender for Servers offre due piani con trade-off netto tra costo e copertura.

  • Plan 1: incentrato sull’endpoint. Include la licenza e l’integrazione automatica di Microsoft Defender for Endpoint (MDE) con EDR, rilevamento minacce a livello di sistema operativo e onboarding agentless. Prezzo per ora, senza impegno annuale.
  • Plan 2: sovrainsieme di Plan 1. Aggiunge vulnerability assessment integrato (Microsoft Defender Vulnerability Management), agentless scanning dei dischi, File Integrity Monitoring (FIM), Just-In-Time VM access, adaptive application controls, network hardening, la free data ingestion (500 MB/giorno) verso Log Analytics e il regulatory compliance dashboard completo.

Raccomandazione di design: se il requisito è solo EDR/antimalware avanzato sui server, Plan 1 è sufficiente e più economico. Se invece serve una postura completa — gestione vulnerabilità, FIM per compliance PCI/ISO, riduzione della superficie d’attacco con JIT — scegli Plan 2. Sull’esame, qualsiasi menzione di vulnerability management, FIM o compliance normativa è il segnale che porta a Plan 2.

Agent-based vs agentless: il trade-off di copertura

Defender for Cloud combina due modalità di raccolta e le usa in modo complementare, non alternativo.

  • Agent-based (MDE, e in passato l’agente MMA/AMA): fornisce telemetria in tempo reale, EDR, risposta attiva e FIM. Costo: overhead operativo di deployment, manutenzione e consumo risorse sull’host.
  • Agentless scanning: analizza uno snapshot del disco per software installato, vulnerabilità, secrets e malware, senza impatto sulle prestazioni e senza gestione di agenti. Limite: è una fotografia periodica, non offre detection real-time né risposta.

Design pattern raccomandato: usa entrambe. L’agentless garantisce copertura ampia e a basso attrito su tutto il parco (comprese VM difficili da gestire), mentre MDE fornisce la profondità di detection dove serve reazione immediata. In ottica Azure Well-Architected Framework, questo bilancia il pilastro Security (visibilità completa) con Operational Excellence e Cost Optimization (meno agenti da mantenere).

Protezione dei container

Per i workload containerizzati il piano è Defender for Containers, che copre AKS, cluster Arc-enabled Kubernetes, ACR e ambienti multicloud (EKS/GKE). Le capacità chiave da progettare:

  • Vulnerability assessment delle immagini in Azure Container Registry, sia at rest nel registry sia at runtime sui container in esecuzione.
  • Runtime threat detection a livello di nodo e cluster tramite sensore Defender.
  • Kubernetes data plane hardening e raccomandazioni sul control plane via audit log.

Raccomandazione: abilita la scansione delle immagini nel registry prima del deploy e mantieni il monitoraggio a runtime — un’immagine pulita al push può diventare vulnerabile per una CVE scoperta dopo.

Defender for DevOps e approccio shift-left

Defender for Cloud DevOps security (spesso citato come Defender for DevOps) estende la protezione alle pipeline Azure DevOps, GitHub e GitLab, portando la sicurezza a sinistra nel ciclo di vita. Copre:

  • Code scanning / secret scanning nei repository per credenziali esposte.
  • IaC scanning (Bicep, Terraform, ARM) per misconfigurations prima del deploy.
  • Dependency e container image scanning in fase di build.
  • Vista unificata della postura DevOps nella console Defender for Cloud, con collegamento tra finding di codice e risorse cloud in produzione.

Lo shift-left riduce drasticamente il costo di remediation intercettando i problemi in fase di commit/PR anziché in produzione — coerente con il pilastro Security del WAF applicato all’intera supply chain.

Trappole tipiche d’esame

  • Requisito: EDR sui server senza necessità di gestione vulnerabilità o FIM → raccomanda Defender for Servers Plan 1 (evita l’over-provisioning di Plan 2).
  • Requisito: FIM, JIT VM access o compliance normativa sui server → Plan 2 (Plan 1 non li include).
  • Scenario: immagini container scansionate solo nel registry ma compromissioni a runtime non rilevate → abilita Defender for Containers con runtime threat detection, non solo la scansione at-rest.
  • Trappola: pipeline CI/CD e repository lasciati scoperti mentre si protegge solo il runtime → abilita Defender for Cloud DevOps security con secret e IaC scanning (shift-left), altrimenti secrets e misconfig arrivano in produzione.
  • Scenario: server multicloud/on-premises da proteggere → onboarding via Azure Arc prima di attivare i piani Defender; senza Arc non c’è copertura CWPP per risorse fuori Azure.