Come Cybersecurity Architect il tuo compito non è “installare prodotti”, ma tradurre requisiti di business e di rischio in una postura difendibile. Le due risorse Microsoft che ti servono per farlo con rigore sono la Microsoft Cybersecurity Reference Architecture (MCRA) e la Microsoft Cloud Security Benchmark (MCSB). La prima ti dice dove posizionare una capability nell’ecosistema; la seconda ti dice quali controlli implementare e come misurarli. In SC-100 vengono usate come blueprint impliciti dietro quasi ogni scenario di design.

MCRA: posizionare le capability, non i prodotti

La MCRA è un insieme di diagrammi di riferimento, parte del Security Adoption Framework, che mappa le capability di sicurezza Microsoft sui domini Zero Trust: identità, endpoint, SOC, dati, rete, OT/IoT, multicloud. Il suo valore architetturale è il posizionamento relativo: mostra che Microsoft Entra ID governa l’identità e il Conditional Access, che Microsoft Defender XDR correla i segnali di endpoint, identità, email e cloud app, che Microsoft Sentinel fa da SIEM/SOAR cloud-native sopra il SOC, che Defender for Cloud copre CSPM e CWP sul workload multicloud, e che Microsoft Purview presidia data governance, classificazione e Insider Risk.

Usa la MCRA come checklist di copertura: dato un requisito (“rilevare movimenti laterali”), individui quale layer lo soddisfa (Defender for Identity dentro XDR) invece di partire dal prodotto. Questo è il ribaltamento mentale che l’esame premia: requisito → capability → prodotto, mai il contrario.

MCSB: baseline di controlli misurabili

La MCSB è la baseline tecnica di riferimento, evoluzione dell’Azure Security Benchmark, organizzata in famiglie di controllo (Network Security, Identity Management, Privileged Access, Data Protection, Logging & Threat Detection, Posture & Vulnerability Management, ecc.). Ogni controllo è azionabile e misurabile: ha guida di implementazione specifica per Azure e, sempre più, per AWS e GCP.

Il punto architetturale chiave: la MCSB è nativamente integrata in Microsoft Defender for Cloud come standard di default del regulatory compliance dashboard e alimenta il Secure Score. Questo la rende non un documento statico ma un KPI continuo — puoi mostrare al business un valore percentuale che si muove nel tempo. Quando in uno scenario ti serve “una baseline applicabile e monitorabile automaticamente sui workload Azure/multicloud”, la risposta canonica è MCSB via Defender for Cloud, non un framework generico.

Trade-off: controlli nativi vs mapping a framework esterni

Ecco la decisione ricorrente. La MCSB mappa già i propri controlli verso NIST SP 800-53 e CIS Controls (oltre a PCI-DSS). Devi scegliere:

  • Adottare MCSB come standard primario quando l’obiettivo è velocità operativa e misurabilità: monitoraggio automatico, guida cloud-specifica, integrazione nativa con Secure Score. È la scelta di default in ambienti prevalentemente Azure/Microsoft.
  • Ancorare a un framework esterno (NIST/CIS/ISO 27001) come autorità, applicando la MCSB come implementazione tecnica sottostante, quando esiste un mandato di compliance o audit che richiede quel linguaggio. In Defender for Cloud aggiungi quindi lo standard NIST/CIS/ISO al dashboard in aggiunta alla MCSB.

Il pilastro Security del Azure Well-Architected Framework rinforza questa logica: definire baseline, misurare la postura e ridurre la superficie d’attacco in modo continuo. MCSB è lo strumento con cui operazionalizzi quel pilastro; MCRA è la mappa con cui verifichi di non avere domini scoperti.

RaMP: dalla baseline alla roadmap prioritizzata

Baseline e architettura non bastano senza sequenza. Il Rapid Modernization Plan (RaMP) fornisce iniziative prioritizzate a “quick win” — proteggere le identità e gli accessi privilegiati, difendersi dal ransomware, proteggere i dati — con checklist di owner e deliverable. In un design, RaMP è la risposta alla domanda “da dove parto e in che ordine”, collegando i gap emersi dalla MCRA e dal Secure Score MCSB a una roadmap difendibile davanti alla leadership.

Trappole tipiche d’esame

  • Requisito: “raccomanda una baseline di sicurezza tecnica, misurabile e monitorata automaticamente sui workload Azure e multicloud” → MCSB applicata via Defender for Cloud, che ne traccia la conformità nel Secure Score. Non proporre un documento NIST “a mano”.
  • Requisito: “esiste un mandato di audit ISO 27001 / NIST 800-53” → mantieni MCSB come implementazione tecnica e aggiungi lo standard richiesto al regulatory compliance dashboard; sfrutta il mapping già esistente, non riparti da zero.
  • Requisito: “verifica che nessun dominio di sicurezza resti scoperto” → usa la MCRA come mappa di copertura capability-per-capability, non un elenco di prodotti da acquistare.
  • Trappola classica: elencare prodotti (Sentinel, Defender, Entra) senza legarli a requisiti → l’esame penalizza il “product dump”. Parti sempre da requisito di business/rischio → capability MCRA → prodotto, con priorità data dal RaMP.
  • Requisito: “definisci quick win iniziali per il programma Zero Trust” → RaMP, non l’intero framework Zero Trust in una volta; RaMP fornisce iniziative sequenziate con owner e deliverable.