Dal requisito normativo al controllo tecnico

Il compito dell’architetto non è “essere compliant”, ma tradurre un obbligo normativo in un controllo tecnico misurabile e in un’evidenza che un auditor possa verificare senza ambiguità. Regolamenti come GDPR, NIS2, DORA, ISO 27001 o PCI-DSS descrivono cosa dev’essere garantito (riservatezza, tracciabilità, resilienza); l’architetto decide come realizzarlo su Azure e dove dimostrarlo.

Il pattern raccomandato — e ricorrente nelle domande SC-100 — è la catena requisito → controllo → evidenza:

  • Requisito: la clausola normativa o contrattuale (es. “log di accesso ai dati personali conservati 12 mesi”).
  • Controllo: l’implementazione tecnica (diagnostic settings verso un Log Analytics workspace con retention policy).
  • Evidenza: l’artefatto auditabile e ripetibile (report Compliance Manager, export Azure Policy compliance state, query KQL firmata).

Chi salta lo step intermedio produce controlli senza evidenza — invisibili in audit — oppure evidenze scollegate dal requisito, difficili da difendere.

Gli strumenti e il loro ruolo nel design

Microsoft Purview Compliance Manager

È il piano di governance della compliance: fornisce assessment template pre-costruiti (GDPR, ISO, NIST, DORA) scomposti in improvement action con punteggio. Distingue le azioni your controls (a carico del cliente, tecniche o procedurali) dalle Microsoft-managed, materializzando la responsabilità condivisa. Il valore architetturale non è il compliance score in sé, ma il fatto che ogni azione diventa un contenitore di evidenze con owner, stato e allegati — perfetto come registro requisito→evidenza.

Azure Policy — regulatory compliance initiative

Sono le initiative (set di policy) mappate 1:1 sui framework normativi. Portano il controllo dentro la piattaforma: valutano continuamente la conformità delle risorse (deny/audit/deployIfNotExists) e producono uno compliance state esportabile. Sono il ponte tra la governance descrittiva di Compliance Manager e l’enforcement tecnico sui workload.

Microsoft Cloud Security Benchmark (MCSB)

La baseline di sicurezza autoritativa di Microsoft, allineata a CIS e NIST 800-53 e integrata in Defender for Cloud come standard di default. Raccomandala come fondamento comune: prima si applica MCSB come baseline trasversale, poi si aggiungono le initiative specifiche del regolatore. Evita di reinventare controlli già coperti dal benchmark.

Design raccomandato: MCSB come baseline → regulatory initiative in Azure Policy per l’enforcement continuo → Compliance Manager come registro di evidenze e responsabilità → Microsoft Purview (Information Protection, DLP, Data Lifecycle) per i controlli sul dato.

Il trade-off residenza dei dati vs multi-region

Molti requisiti (GDPR, sovranità nazionale, settore pubblico) impongono che i dati restino in una geografia. Questo confligge direttamente con i pilastri Reliability e Performance Efficiency del Azure Well-Architected Framework, che spingono verso topologie multi-region per alta disponibilità e latenza.

Come si risolve:

  • La residenza vince sul design DR “libero”: se il regolatore vieta la replica fuori area, non puoi usare un pair cross-geography. Scegli region dentro il confine consentito o servizi con data residency configurabile (es. availability zone intra-region invece di geo-replication).
  • Distingui dato a riposo da metadati/telemetria: alcuni servizi processano metadati altrove. Verifica sempre dove finiscono log e backup, non solo il dato primario.
  • EU Data Boundary e le region sovereign rispondono a requisiti di sovranità stringenti quando la sola scelta della region non basta.
  • Documenta il trade-off accettato (RTO/RPO più alti in cambio di conformità) come decisione architetturale tracciata — è ciò che l’auditor e l’esame si aspettano.

La trappola della compliance “una tantum”

L’errore concettuale più penalizzato è trattare la compliance come progetto con una data di fine. Le risorse cloud cambiano di continuo: una nuova VM senza encryption, uno storage reso pubblico, un tag mancante fanno driftare la postura. La compliance è quindi un processo continuo, non uno stato.

Design raccomandato per la continuità:

  • Azure Policy in valutazione permanente con effetti deny/deployIfNotExists per rimediare automaticamente il drift.
  • Defender for Cloud con il pannello Regulatory Compliance per il monitoraggio continuo rispetto agli standard.
  • Compliance Manager rivalutato periodicamente, con evidenze aggiornate e owner responsabilizzati.
  • Allineamento al pilastro Security del Well-Architected Framework: la governance è ricorrente e misurata, non firmata una volta.

Trappole tipiche d’esame

  • Requisito: “dimostrare in audit la conformità GDPR continua e assegnare le azioni ai responsabili” → Microsoft Purview Compliance Manager con assessment GDPR (registro evidenze + owner), non un semplice export di Azure Policy.
  • Requisito: “impedire il deploy di risorse non conformi al framework normativo” → regulatory compliance initiative di Azure Policy con effetto deny, non Defender for Cloud (che rileva ma non blocca).
  • Requisito: “baseline di sicurezza trasversale allineata a NIST/CIS prima dei controlli specifici” → MCSB in Defender for Cloud come standard di default, non policy custom sparse.
  • Requisito: “i dati personali non devono lasciare l’UE ma serve resilienza” → region interne al boundary + zone-redundancy / EU Data Boundary, accettando RTO/RPO superiori; la residenza prevale sulla geo-replication cross-region.
  • Requisito: “evitare che la postura di compliance degradi nel tempo” → monitoraggio continuo con Azure Policy + Regulatory Compliance di Defender for Cloud, non una verifica manuale una tantum.