Microsoft Sentinel è la piattaforma SIEM/SOAR cloud-native di Microsoft, costruita sopra un workspace Log Analytics. Come architetto SC-100 il tuo compito non è configurare le regole, ma decidere topologia del workspace, strategia di ingestione e livello di automazione in modo da bilanciare copertura di detection, costo operativo e sovranità dei dati. Ogni scelta va giustificata contro i pilastri dell’Azure Well-Architected Framework, in particolare Security, Cost Optimization e Operational Excellence.

Design del workspace Log Analytics

La prima decisione è single vs multi-workspace.

  • Single workspace semplifica correlazione, regole di analytics, RBAC e gestione delle retention. È la scelta di default quando esiste un unico confine di residenza dei dati e un unico team SOC. Riduce la complessità operativa e i costi duplicati.
  • Multi-workspace diventa necessario quando hai requisiti di data residency divergenti (es. dati UE che non possono lasciare la region), separazione legale tra business unit, o deleghe amministrative distinte. Il prezzo è la frammentazione: le regole cross-workspace richiedono la sintassi workspace() e comportano costi di query aggiuntivi.

Per gli scenari multi-tenant (MSSP o gruppi con più tenant Entra ID) la raccomandazione è Azure Lighthouse: il SOC gestisce Sentinel nei tenant dei clienti tramite delega centralizzata, senza spostare i dati fuori dal tenant del cliente. Questo preserva l’isolamento dei dati e abilita una vista unificata degli incidenti. Da evitare invece la costruzione di un unico workspace centralizzato in cui confluiscono i log di tutti i tenant: viola la separazione e complica la compliance.

Data connectors e tiering dei log

Il costo di Sentinel è dominato dall’ingestione, non dall’analisi. Per questo la scelta del commitment tier (capacity reservation vs pay-as-you-go) e del plan di ogni tabella è una leva architetturale centrale:

  • Analytics logs: full-fidelity, interrogabili in tempo reale, alimentano regole di analytics e hunting. Riservali ai log ad alto valore di detection (sign-in Entra ID, audit di controllo, alert di Defender XDR, EDR).
  • Basic / Auxiliary logs: costo di ingestione molto inferiore, query limitate e retention breve. Ideali per log ad alto volume e basso segnale usati per contesto o investigazione occasionale (firewall verbose, log di rete, proxy, NetFlow).
  • Archive: retention a lungo termine a costo minimo per compliance e forensics, con search job o restore quando serve accedervi.

La logica di design è: classifica ogni sorgente per valore di detection e obbligo di retention, poi assegna il tier di conseguenza. Usa le Data Collection Rules (DCR) per filtrare e trasformare al momento dell’ingestione, scartando ciò che non serve prima che generi costo.

Automazione SOAR con i playbook

La componente SOAR si realizza con i playbook, basati su Azure Logic Apps, orchestrati dalle automation rule. Ne segue la scelta di design tipica:

  • Automation rule per logica leggera e sincrona (assegnazione, tagging, soppressione, chiusura di falsi positivi noti).
  • Playbook per azioni esterne: arricchimento di contesto (threat intelligence), apertura ticket in ITSM, notifica in Teams, o risposta automatica (disabilitare un utente Entra ID, isolare un device via Defender XDR).

Il trade-off è tra velocità di risposta e rischio di automazione distruttiva: le azioni di remediation automatica riducono il MTTR (Operational Excellence) ma vanno gated con approvazioni umane o vincolate a detection ad alta confidenza, per evitare interruzioni di servizio su falsi positivi.

Sentinel vs XDR-only

Non tutti gli scenari richiedono Sentinel. Microsoft Defender XDR copre già correlazione, hunting e risposta automatica sui carichi Microsoft (endpoint, identità, email, cloud app, Office). Se il perimetro è interamente Microsoft e non hai requisiti di retention estesa né sorgenti di terze parti, una configurazione XDR-only è più economica e semplice. Sentinel si raccomanda quando servono: ingestione di sorgenti eterogenee (on-prem, multi-cloud, appliance di rete), correlazione cross-domain oltre l’ecosistema Microsoft, retention a lungo termine per compliance, o orchestrazione SOAR verso sistemi esterni. L’architettura ottimale spesso è XDR come layer di detection nativo integrato in Sentinel come SIEM di aggregazione, non l’uno al posto dell’altro.

Trappole tipiche d’esame

  • Log di firewall/proxy ad alto volume che fanno esplodere i costi in Analytics → instradali in Basic/Auxiliary logs e filtra all’ingestione con le DCR, riservando Analytics ai log ad alto segnale.
  • MSSP che deve gestire Sentinel in più tenant clienti senza spostare i dati → Azure Lighthouse con delega cross-tenant, non un workspace centralizzato unico.
  • Requisito di conservare log 7 anni per compliance a costo minimo → Archive tier, non retention estesa in Analytics.
  • Ambiente 100% Microsoft senza sorgenti esterne né retention lunga → Defender XDR-only; introdurre Sentinel aggiunge costo senza valore incrementale.
  • Disabilitazione automatica di account su alert → playbook Logic Apps innescato da automation rule, gated su detection ad alta confidenza per evitare impatti da falsi positivi.