Perché il CSPM è il fondamento della posture cross-cloud

Nel dominio SC-100 “Design a strategy for managing cloud security posture”, il Cloud Security Posture Management (CSPM) è la disciplina che risponde a una domanda architetturale precisa: dato un estate distribuito su Azure, on-premises e altri cloud, come garantisco visibilità unificata e miglioramento continuo della postura? La risposta di riferimento Microsoft è Microsoft Defender for Cloud come piano di controllo CSPM centrale, con la Microsoft Cloud Security Benchmark (MCSB) come baseline normativa applicata di default a ogni risorsa onboardata.

Il segnale operativo primario è il Secure Score: una metrica aggregata che pesa le raccomandazioni di sicurezza sui controlli MCSB. Come architetto non lo tratti come vanity metric, ma come strumento di prioritizzazione basata sul rischio e come KPI per governance e reporting verso il management.

MCSB come baseline e il modello multicloud

La MCSB mappa i propri controlli su framework come CIS, NIST SP 800-53 e PCI-DSS, e — punto cruciale per l’esame — non è Azure-only: definisce controlli equivalenti per AWS e GCP. Questo consente una postura normalizzata su tre cloud con un unico linguaggio di compliance, invece di gestire silos di tooling nativo (AWS Security Hub, GCP Security Command Center) con semantiche divergenti.

Il design dell’onboarding cambia in base alla natura della risorsa:

  • Risorse Azure: onboarding nativo, nessun agente richiesto per il CSPM foundational.
  • Server hybrid / on-premises / VM in altri cloud: si proiettano in Azure tramite Azure Arc, che le rende oggetti ARM di prima classe. Solo così ereditano raccomandazioni, policy e Secure Score. Senza Arc, quelle macchine sono invisibili alla postura.
  • Account AWS e progetti GCP: si collegano tramite i connettori nativi multicloud (basati su ruoli IAM/service account), che ingeriscono la configurazione delle risorse senza spostare workload.

Il trade-off centrale: CSPM Foundational vs Defender CSPM

Questa è la decisione di design più ricorrente. Devi saper motivare quando il tier gratuito è sufficiente e quando serve il piano a pagamento.

Foundational CSPM (gratuito) offre: Secure Score, valutazione continua di compliance MCSB, raccomandazioni di remediation e asset inventory. È adeguato per visibilità di base e igiene di configurazione su tutto l’estate.

Defender CSPM (a pagamento, per risorsa) aggiunge le capability che rispondono a requisiti di prioritizzazione contestuale del rischio:

  • Agentless scanning di VM e container (disk snapshot) e agentless discovery per Kubernetes — vulnerabilità e segreti senza deploy di agenti.
  • Attack path analysis: identifica le catene sfruttabili (es. VM internet-exposed con vulnerabilità critica → managed identity con ruolo privilegiato → storage con dati sensibili), spostando il focus dalle migliaia di misconfiguration isolate ai pochi percorsi realmente pericolosi.
  • Cloud Security Explorer: query graph-based sul grafo delle risorse cross-cloud per threat hunting proattivo sulla postura.
  • Data-aware security posture e integrazione con Microsoft Purview per contestualizzare i data path sensibili.

Raccomandazione di design: per un cliente con solo esigenza di compliance reporting, il foundational basta. Ma se il requisito è “ridurre il rischio prioritizzando ciò che un attaccante sfrutterebbe davvero” o “trovare vulnerabilità e segreti senza impatto sui workload”, la risposta corretta è Defender CSPM — l’attack path analysis e l’agentless scanning non esistono nel tier gratuito.

Allineamento al Well-Architected Framework

Il CSPM è l’implementazione operativa del pilastro Security dell’Azure Well-Architected Framework, in particolare dei principi di continuous validation e defense in depth. Il Secure Score alimenta il ciclo di miglioramento continuo, mentre l’integrazione con Microsoft Defender XDR e Microsoft Sentinel collega la postura (prevenzione) al rilevamento e risposta (detection & response), realizzando la strategia end-to-end che SC-100 richiede di progettare.

Trappole tipiche d’esame

  • Requisito: postura unificata su Azure + AWS + on-premises → soluzione: Defender for Cloud con connettori nativi AWS/GCP per i cloud e Azure Arc per l’hybrid; mai proporre tooling nativo di terze parti separato quando serve un unico piano di controllo.
  • Requisito: identificare le catene di attacco sfruttabili verso dati sensibili → soluzione: abilitare Defender CSPM per attack path analysis e Cloud Security Explorer; il foundational CSPM non le include.
  • Trappola del “solo Azure”: uno scenario che valuta la postura ignorando server on-premises/AWS ha un gap di copertura → la risposta corretta onboarda quelle risorse via Arc/connettori, non le esclude.
  • Requisito: scan di vulnerabilità e segreti senza installare agenti sui workload → soluzione: agentless scanning di Defender CSPM, non il deploy di agent-based extension.
  • Configuration drift: se la richiesta è impedire la deriva (non solo rilevarla), la risposta va oltre il CSPM verso Azure Policy con deny/enforcement e IaC governato; il Secure Score da solo segnala il drift ma non lo blocca.