Microsoft Sentinel non si crea: si aggiunge a un workspace di Log Analytics che esiste già. Per abilitarlo serve il ruolo Contributor sulla subscription che ospita il workspace; per usarlo, Microsoft Sentinel Contributor o Microsoft Sentinel Reader sul resource group.

Il workspace: tre vincoli che scopri troppo tardi

Il primo: i workspace creati in automatico da Microsoft Defender for Cloud non compaiono nell’elenco e non possono ospitare Sentinel. Il secondo: una volta che Sentinel è attivo su un workspace, spostare quel workspace in un altro resource group o in un’altra subscription non è supportato. Il terzo, il più insidioso: sotto i piani tariffari legacy il workspace nasce con una conservazione di 30 giorni, e per avere tutte le funzionalità di Sentinel la documentazione chiede di portarla a 90 giorni. Nessuno te lo ricorda durante la creazione.

C’è anche un cambio di portale in corso, e va capito adesso. Dal luglio 2025 molti nuovi clienti finiscono automaticamente nel portale Defender: se chi abilita Sentinel è Owner della subscription o User access administrator, il workspace viene agganciato da solo e gli utenti useranno Sentinel solo da lì. Dopo il 31 marzo 2027 Sentinel non sarà più supportato nel portale Azure. Nel portale Defender ogni tenant ha un workspace primario più eventuali secondari.

Quando servono davvero più workspace

Un workspace è legato a una regione, quindi la sovranità del dato è la prima ragione legittima per moltiplicarli. La seconda è il confine di tenant: Sentinel raccoglie dati da risorse Microsoft e SaaS solo dentro il proprio tenant Entra, e un connettore basato su diagnostic settings non può puntare a un workspace che vive in un tenant diverso. Un tenant, un workspace: su questo non si tratta. Restano la proprietà del dato fra società controllate e la fatturazione separata per subscription.

Due ragioni che si sentono citare spesso, invece, non reggono più. Se ti servono permessi granulari la risposta è il resource-context RBAC o il RBAC a livello di tabella, non un secondo workspace. Se ti serve una conservazione diversa per tipo di dato, esistono le impostazioni di retention per tabella. Moltiplicare i workspace per questi due motivi è architettura ereditata, non progetto. Per un MSSP il discorso si ribalta: quasi tutti i requisiti valgono insieme, quindi almeno un workspace per tenant, gestiti con Azure Lighthouse.

Ruoli: assegnali al resource group, non al workspace

I ruoli Azure dedicati sono cinque e vanno assegnati al resource group che contiene il workspace. Il motivo è pratico: così anche le Logic App e i playbook, che sono risorse separate, ricadono sotto le stesse assegnazioni. Se li assegni al workspace devi replicarli sulla risorsa SecurityInsights dentro quel workspace, e poi inseguire a mano ogni risorsa nuova.

La scala è cumulativa: Reader vede dati, incidenti e workbook; Responder aggiunge la gestione degli incidenti; Contributor aggiunge la creazione di regole e risorse e la gestione del content hub. Playbook Operator elenca ed esegue i playbook a mano. Automation Contributor non si assegna alle persone: serve a Sentinel per agganciare i playbook alle regole di automazione.

Dove il modello sorprende:

  • nessun ruolo Sentinel, Contributor incluso, crea o modifica un playbook: per quello serve Logic App Contributor;
  • per creare workbook serve anche Workbook Contributor;
  • perché una regola di automazione esegua un playbook, l’account di servizio va autorizzato esplicitamente sul resource group del playbook, e per concedere quel permesso tu devi essere Owner;
  • collegare una sorgente dati richiede permessi di scrittura sul workspace, più quanto chiede il singolo connettore.

Per i team non-SOC che devono vedere solo i log delle proprie macchine c’è il resource-context RBAC: accesso ai dati attraverso la risorsa, senza l’esperienza Sentinel. Ha un limite netto e poco noto: funzioni e ricerche salvate non sono supportate in contesto risorsa, quindi per quegli utenti niente parser e niente normalizzazione ASIM.

Content hub: template e contenuti attivi non sono la stessa cosa

Per installare, aggiornare o eliminare contenuti serve Microsoft Sentinel Contributor a livello di resource group. Il hub distribuisce due cose: le soluzioni, pacchetti versionati che raggruppano connettori, regole analitiche, query di hunting, playbook, parser, watchlist e workbook, e i contenuti standalone. La differenza operativa: gli standalone si aggiornano da soli, le soluzioni no, compaiono con lo stato Update e le aggiorni tu, singolarmente o in blocco dalla vista a elenco.

L’errore classico è credere che installare basti. L’installazione porta nel workspace dei template; i contenuti attivi li crei tu da Manage: dal template della regola crei la regola, dal template del workbook salvi la tua copia, dal template del playbook crei il playbook. I parser fanno eccezione, arrivano già come funzioni del workspace. E se ti serve un solo elemento di una soluzione, devi comunque installare la soluzione intera.

Due dettagli finali. Le soluzioni che usano i connettori unificati AMA per CEF, Syslog o custom log hanno dipendenze: usa Install with dependencies, altrimenti il connettore richiesto non arriva. E il modello di supporto non è uniforme — Microsoft, partner o community, indicato nel riquadro Support della soluzione: per un problema su una soluzione partner il canale è il partner, non il supporto Azure.