Preparare più aree di lavoro e tenant in Microsoft Sentinel

Per prepararsi per la distribuzione, è necessario determinare se un'architettura di più aree di lavoro è pertinente per l'ambiente in uso. Questo articolo illustra come Microsoft Sentinel può estendersi tra più aree di lavoro e tenant, in modo da determinare se questa funzionalità è adatta alle esigenze dell'organizzazione. Questo articolo fa parte della Guida alla distribuzione per Microsoft Sentinel.

Se si è deciso di configurare l'ambiente per estendersi tra aree di lavoro, vedere Estendere Microsoft Sentinel tra aree di lavoro e tenant e gestire centralmente più aree di lavoro di Microsoft Sentinel con il responsabile dell'area di lavoro.

La necessità di usare più aree di lavoro di Microsoft Sentinel

Quando si esegue l'onboarding di Microsoft Sentinel, il primo passaggio consiste nel selezionare l'area di lavoro Log Analytics. Sebbene sia possibile sfruttare appieno l'esperienza di Microsoft Sentinel con una singola area di lavoro, in alcuni casi, è possibile estendere l'area di lavoro per eseguire query e analizzare i dati tra aree di lavoro e tenant.

Questa tabella elenca alcuni di questi scenari e, quando possibile, suggerisce come usare una singola area di lavoro per lo scenario.

Requisito Descrizione Modi per ridurre il numero di aree di lavoro
Sovranità e conformità alle normative Un'area di lavoro è associata a un'area specifica. Per mantenere i dati in aree geografiche di Azure diverse per soddisfare i requisiti normativi, suddividere i dati in aree di lavoro separate.
Proprietà dei dati I limiti della proprietà dei dati, ad esempio da società affiliate o società affiliate, sono meglio delineati usando aree di lavoro separate.
Più tenant di Azure Microsoft Sentinel supporta la raccolta dati dalle risorse SaaS di Microsoft e Azure solo entro il limite del tenant Microsoft Entra. Di conseguenza, ogni tenant di Microsoft Entra richiede un'area di lavoro separata.
Controllo granulare dell'accesso ai dati Un'organizzazione potrebbe dover consentire a gruppi diversi, all'interno o all'esterno dell'organizzazione, di accedere ad alcuni dei dati raccolti da Microsoft Sentinel. Ad esempio:
  • Accesso dei proprietari delle risorse ai dati relativi alle risorse
  • Accesso dei SOC regionali o sussidiari ai dati rilevanti per le loro parti dell'organizzazione
Usare il controllo degli accessi in base al ruolo di Azure o il controllo degli accessi in base al ruolo di Azure a livello di tabella
Impostazioni di conservazione dei dati granulari Storicamente, più aree di lavoro erano l'unico modo per impostare periodi di conservazione diversi per tipi di dati diversi. Ciò non è più necessario in molti casi, grazie all'introduzione delle impostazioni di conservazione a livello di tabella. Usare le impostazioni di conservazione a livello di tabella o automatizzare l'eliminazione dei dati
Suddivisione della fatturazione Inserendo aree di lavoro in sottoscrizioni separate, possono essere fatturate a parti diverse. Report di utilizzo e addebito incrociato
Architettura legacy L'uso di più aree di lavoro può derivare da una progettazione cronologica che ha preso in considerazione limitazioni o procedure consigliate che non sono più vere. Si potrebbe trattare anche di una scelta di progettazione arbitraria che può essere modificata per supportare meglio Microsoft Sentinel.

Alcuni esempi:
  • Uso di un'area di lavoro predefinita per sottoscrizione durante la distribuzione di Microsoft Defender per il cloud
  • La necessità di un controllo di accesso granulare o di impostazioni di conservazione, le soluzioni per le quali sono relativamente nuove
Riprogettare le aree di lavoro

Provider del servizio di sicurezza gestito (MSSP)

In caso di MSSP, molti se non tutti i requisiti precedenti si applicano, rendendo più aree di lavoro, tra tenant, la procedura consigliata. MSSP può usare Azure Lighthouse per estendere le funzionalità tra aree di lavoro di Microsoft Sentinel tra tenant.

Architettura con più aree di lavoro di Microsoft Sentinel

Come implicito nei requisiti precedenti, esistono casi in cui un singolo SOC deve gestire e monitorare centralmente più aree di lavoro di Microsoft Sentinel, potenzialmente nei tenant di Microsoft Entra.

  • Un servizio MSSP di Microsoft Sentinel.

  • Un SOC globale che gestisce più filiali, ognuna con il proprio SOC locale.

  • Un SOC che monitora più tenant di Microsoft Entra all'interno di un'organizzazione.

Per risolvere questi casi, Microsoft Sentinel offre funzionalità con più aree di lavoro che consentono il monitoraggio centrale, la configurazione e la gestione, offrendo un unico riquadro di vetro su tutto ciò che riguarda il SOC. Questo diagramma mostra un'architettura di esempio per tali casi d'uso.

Diagram showing extend workspace across multiple tenants: architecture.

Questo modello offre vantaggi significativi rispetto a un modello completamente centralizzato in cui tutti i dati vengono copiati in una singola area di lavoro:

  • Assegnazione di ruolo flessibile ai SOC globali e locali o al provider di servizi gestito dai clienti.

  • Meno sfide relative alla proprietà dei dati, alla privacy dei dati e alla conformità alle normative.

  • Latenza di rete e addebiti minimi.

  • Facile onboarding e offboarding di nuove filiali o clienti.

Nelle sezioni seguenti verrà illustrato come usare questo modello e in particolare come:

  • Monitorare centralmente più aree di lavoro, potenzialmente tra i tenant, fornendo al SOC un unico riquadro di vetro.

  • Configurare e gestire centralmente più aree di lavoro, potenzialmente tra tenant, usando l'automazione.

Passaggi successivi

In questo articolo si è appreso come Microsoft Sentinel può estendersi tra più aree di lavoro e tenant.