Progettazioni di aree di lavoro di esempio di Microsoft Azure Sentinel

Questo articolo descrive le progettazioni di aree di lavoro suggerite per le organizzazioni con i requisiti di esempio seguenti:

• Più tenant e aree geografiche, con requisiti di sovranità dei dati europei
• Tenant singolo con più cloud
• Più tenant, con più aree e sicurezza centralizzata

Gli esempi in questo articolo usano l'albero delle decisioni di progettazione dell'area di lavoro di Microsoft Sentinel per determinare la progettazione ottimale dell'area di lavoro per ogni organizzazione. Per altre informazioni, vedere Procedure consigliate per l'architettura dell'area di lavoro di Microsoft Sentinel.

Questo articolo fa parte della Guida alla distribuzione per Microsoft Sentinel.

Esempio 1: più tenant e aree

Contoso Corporation è una multinazionale con sede centrale a Londra. Contoso ha uffici in tutto il mondo, con importanti hub a New York City e Tokyo. Di recente, Contoso ha eseguito la migrazione della suite di produttività a Office 365, con molti carichi di lavoro migrati ad Azure.

Tenant Contoso

A causa di un'acquisizione diversi anni fa, Contoso ha due tenant di Microsoft Entra: contoso.onmicrosoft.com e wingtip.onmicrosoft.com. Ogni tenant ha una propria istanza di Office 365 e più sottoscrizioni di Azure, come illustrato nell'immagine seguente:

Conformità di Contoso e distribuzione a livello di area

Contoso ha attualmente risorse di Azure ospitate in tre aree diverse: Stati Uniti orientali, Ue settentrionale e Giappone occidentale e requisiti rigorosi per mantenere tutti i dati generati in Europa all'interno delle aree dell'Europa.

Entrambi i tenant di Microsoft Entra di Contoso hanno risorse in tutte e tre le aree: Stati Uniti orientali, UE settentrionale e Giappone occidentale

Requisiti di raccolta e tipi di risorse Contoso

Contoso deve raccogliere eventi dalle origini dati seguenti:

• Office 365
• Log di accesso e controllo di Microsoft Entra
• Attività di Azure
• Sicurezza di Windows eventi, sia da origini locali che da macchine virtuali di Azure
• Syslog, sia da origini locali che da macchine virtuali di Azure
• CEF, da più dispositivi di rete locali, ad esempio Palo Alto, Cisco ASA e Cisco Meraki
• Più risorse PaaS di Azure, ad esempio Firewall di Azure, servizio Azure Kubernetes, Key Vault, Archiviazione di Azure e Azure SQL
• Cisco Umbrella

Le macchine virtuali di Azure si trovano principalmente nell'area Settentrionale dell'UE, con solo alcuni negli Stati Uniti orientali e nel Giappone occidentale. Contoso usa Microsoft Defender per i server in tutte le macchine virtuali di Azure.

Contoso prevede di inserire circa 300 GB al giorno da tutte le origini dati.

Requisiti di accesso di Contoso

L'ambiente Azure di Contoso ha già una singola area di lavoro Log Analytics esistente usata dal team operativo per monitorare l'infrastruttura. Questa area di lavoro si trova nel tenant Microsoft Entra di Contoso, all'interno dell'area Europa settentrionale e viene usata per raccogliere i log dalle macchine virtuali di Azure in tutte le aree. Attualmente inseriscono circa 50 GB al giorno.

Il team di Contoso Operations deve avere accesso a tutti i log attualmente presenti nell'area di lavoro, che includono diversi tipi di dati non necessari per il SOC, ad esempio Perf, InsightsMetrics, ContainerLog e altro ancora. Il team operativo non deve avere accesso ai nuovi log raccolti in Microsoft Sentinel.

Soluzione di Contoso

La procedura seguente applica l'albero delle decisioni di progettazione dell'area di lavoro di Microsoft Sentinel per determinare la progettazione ottimale dell'area di lavoro per Contoso:

1. Contoso ha già un'area di lavoro esistente, quindi è possibile esplorare l'abilitazione di Microsoft Sentinel nella stessa area di lavoro.

   L'inserimento dati non SOC è inferiore a 100 GB al giorno, quindi è possibile continuare con il passaggio 2 e assicurarsi di selezionare l'opzione pertinente nel passaggio 5.

2. Contoso ha requisiti normativi, quindi è necessaria almeno un'area di lavoro di Microsoft Sentinel in Europa.

3. Contoso ha due tenant Microsoft Entra diversi e raccoglie da origini dati a livello di tenant, ad esempio Office 365 e i log di controllo e di accesso di Microsoft Entra, quindi è necessaria almeno un'area di lavoro per ogni tenant.

4. Contoso non richiede il chargeback, quindi è possibile continuare con il passaggio 5.

5. Contoso deve raccogliere dati non SOC, anche se non esiste alcuna sovrapposizione tra i dati SOC e non SOC. Inoltre, i dati SOC rappresentano circa 250 GB al giorno, quindi devono usare aree di lavoro separate per garantire un'efficienza dei costi.

6. La maggior parte delle macchine virtuali di Contoso è l'area settentrionale dell'UE, dove ha già un'area di lavoro. Pertanto, in questo caso, i costi della larghezza di banda non sono un problema.

7. Contoso ha un singolo team SOC che usa Microsoft Sentinel, quindi non è necessaria alcuna separazione aggiuntiva.

8. Tutti i membri del team SOC di Contoso avranno accesso a tutti i dati, quindi non è necessaria alcuna separazione aggiuntiva.

La progettazione dell'area di lavoro di Microsoft Sentinel risultante per Contoso è illustrata nell'immagine seguente:

La soluzione suggerita include:

• Un'area di lavoro Log Analytics separata per il team operatore contoso. Questa area di lavoro conterrà solo i dati non necessari per il team SOC di Contoso, ad esempio le tabelle Perf, InsightsMetrics o ContainerLog .

• Due aree di lavoro di Microsoft Sentinel, una in ogni tenant di Microsoft Entra, per inserire i dati da Office 365, Attività di Azure, Microsoft Entra ID e tutti i servizi PaaS di Azure.

• Tutti gli altri dati, provenienti da origini dati locali, possono essere indirizzati a una delle due aree di lavoro di Microsoft Sentinel.

Esempio 2: Tenant singolo con più cloud

Fabrikam è un'organizzazione con sede centrale a New York City e uffici in tutto il Stati Uniti. Fabrikam sta iniziando il percorso cloud e deve comunque distribuire la prima zona di destinazione di Azure ed eseguire la migrazione dei primi carichi di lavoro. Fabrikam ha già alcuni carichi di lavoro in AWS, che intende monitorare con Microsoft Sentinel.

Requisiti di tenancy di Fabrikam

Fabrikam ha un singolo tenant di Microsoft Entra.

Conformità di Fabrikam e distribuzione a livello di area

Fabrikam non ha requisiti di conformità. Fabrikam include risorse in diverse aree di Azure situate negli Stati Uniti, ma i costi della larghezza di banda tra le aree non rappresentano un problema importante.

Requisiti di raccolta e tipi di risorse Fabrikam

Fabrikam deve raccogliere eventi dalle origini dati seguenti:

• Log di accesso e controllo di Microsoft Entra
• Attività di Azure
• Eventi di sicurezza, da origini locali e di macchine virtuali di Azure
• Eventi di Windows, da origini locali e di macchine virtuali di Azure
• Dati sulle prestazioni, provenienti sia da origini locali che da macchine virtuali di Azure
• AWS CloudTrail
• Log di controllo e prestazioni del servizio Azure Kubernetes

Requisiti di accesso di Fabrikam

Il team Fabrikam Operations deve accedere a:

• Eventi di sicurezza ed eventi di Windows, sia da origini locali che da macchine virtuali di Azure
• Dati sulle prestazioni, provenienti sia da origini locali che da macchine virtuali di Azure
• Log di controllo e prestazioni del servizio Azure Kubernetes (Container Insights)
• Tutti i dati dell'attività di Azure

Il team SOC di Fabrikam deve accedere a:

• Log di accesso e controllo di Microsoft Entra
• Tutti i dati dell'attività di Azure
• Eventi di sicurezza, sia da origini locali che da macchine virtuali di Azure
• Log di AWS CloudTrail
• Log di controllo del servizio Azure Kubernetes
• Portale completo di Microsoft Sentinel

Soluzione di Fabrikam

La procedura seguente applica l'albero delle decisioni di progettazione dell'area di lavoro di Microsoft Sentinel per determinare la progettazione ottimale dell'area di lavoro per Fabrikam:

1. Fabrikam non ha un'area di lavoro esistente, quindi continuare con il passaggio 2.

2. Fabrikam non ha requisiti normativi, quindi continuare con il passaggio 3.

3. Fabrikam ha un ambiente a tenant singolo. quindi continuare con il passaggio 4.

4. Fabrikam non ha bisogno di suddividere gli addebiti, quindi continuare con il passaggio 5.

5. Fabrikam dovrà disporre di aree di lavoro separate per i team SOC e Operations:

   Il team Fabrikam Operations deve raccogliere i dati sulle prestazioni, sia dalle macchine virtuali che dal servizio Azure Kubernetes. Poiché il servizio Azure Kubernetes è basato sulle impostazioni di diagnostica, è possibile selezionare log specifici da inviare a aree di lavoro specifiche. Fabrikam può scegliere di inviare i log di controllo del servizio Azure Kubernetes all'area di lavoro di Microsoft Sentinel e tutti i log del servizio Azure Kubernetes a un'area di lavoro separata, in cui Microsoft Sentinel non è abilitato. Nell'area di lavoro in cui Microsoft Sentinel non è abilitato, Fabrikam abiliterà la soluzione Container Insights.

   Per le macchine virtuali Windows, Fabrikam può usare l'agente di monitoraggio di Azure per suddividere i log, inviare eventi di sicurezza all'area di lavoro di Microsoft Sentinel e eventi di Windows e prestazioni all'area di lavoro senza Microsoft Sentinel.

   Fabrikam sceglie di considerare i dati sovrapposti, ad esempio eventi di sicurezza ed eventi di attività di Azure, come solo dati SOC e li invia all'area di lavoro con Microsoft Sentinel.

6. I costi della larghezza di banda non rappresentano un problema importante per Fabrikam, quindi continuare con il passaggio 7.

7. Fabrikam ha già deciso di usare aree di lavoro separate per i team SOC e Operations. Non sono necessarie ulteriori separazioni.

8. Fabrikam deve controllare l'accesso per i dati sovrapposti, inclusi gli eventi di sicurezza e gli eventi di attività di Azure, ma non esiste alcun requisito a livello di riga.

   Gli eventi di sicurezza e gli eventi di attività di Azure non sono log personalizzati, quindi Fabrikam può usare il controllo degli accessi in base al ruolo a livello di tabella per concedere l'accesso a queste due tabelle per il team operativo.

La progettazione dell'area di lavoro di Microsoft Sentinel risultante per Fabrikam è illustrata nell'immagine seguente, incluse solo le origini dei log chiave per semplicità di progettazione:

La soluzione suggerita include:

• Due aree di lavoro separate nell'area degli Stati Uniti: una per il team SOC con Microsoft Sentinel abilitata e un'altra per il team operativo, senza Microsoft Sentinel.

• Agente di monitoraggio di Azure usato per determinare quali log vengono inviati a ogni area di lavoro da Azure e dalle macchine virtuali locali.

• Impostazioni di diagnostica, usate per determinare quali log vengono inviati a ogni area di lavoro da risorse di Azure, ad esempio il servizio Azure Kubernetes.

• Dati sovrapposti inviati all'area di lavoro di Microsoft Sentinel, con il controllo degli accessi in base al ruolo a livello di tabella per concedere l'accesso al team operativo in base alle esigenze.

Esempio 3: Più tenant e aree e sicurezza centralizzata

Adventure Works è una multinazionale con sede a Tokyo. Adventure Works ha 10 sottoentità diverse, basate in paesi/aree geografiche diverse in tutto il mondo.

Adventure Works è un cliente di Microsoft 365 E5 e ha già carichi di lavoro in Azure.

Requisiti di tenancy Adventure Works

Adventure Works ha tre diversi tenant di Microsoft Entra, uno per ognuno dei continenti in cui hanno sottoentità: Asia, Europa e Africa. I paesi/aree geografiche delle diverse sottoentità hanno le proprie identità nel tenant del continente a cui appartengono. Ad esempio, gli utenti giapponesi si trovano nel tenant asia , gli utenti tedeschi si trovano nel tenant Europa e gli utenti egiziani si trovano nel tenant Africa .

Requisiti di conformità e di area di Adventure Works

Adventure Works usa attualmente tre aree di Azure, ognuna allineata al continente in cui risiedono le sottoentità. Adventure Works non ha requisiti di conformità rigorosi.

Requisiti di raccolta e tipi di risorse Adventure Works

Adventure Works deve raccogliere le origini dati seguenti per ogni sottoentità:

• Log di accesso e controllo di Microsoft Entra
• Log di Office 365
• Log non elaborati di Microsoft Defender XDR per endpoint
• Attività di Azure
• Microsoft Defender for Cloud
• Risorse PaaS di Azure, ad esempio da Firewall di Azure, Archiviazione di Azure, Azure SQL e Azure WAF
• Eventi di sicurezza e windows da macchine virtuali di Azure
• Log CEF da dispositivi di rete locali

Le macchine virtuali di Azure sono distribuite nei tre continenti, ma i costi della larghezza di banda non sono un problema.

Requisiti di accesso di Adventure Works

Adventure Works ha un singolo team SOC centralizzato che supervisiona le operazioni di sicurezza per tutte le diverse sottoentità.

Adventure Works ha anche tre team SOC indipendenti, uno per ognuno dei continenti. Il team SOC di ogni continente dovrebbe essere in grado di accedere solo ai dati generati all'interno della propria area, senza visualizzare i dati provenienti da altri continenti. Ad esempio, il team SOC asia deve accedere solo ai dati delle risorse di Azure distribuite in Asia, agli accessi di Microsoft Entra dal tenant Asia e ai log di Defender per endpoint dal tenant asia.

Il team SOC di ogni continente deve accedere all'esperienza completa del portale di Microsoft Sentinel.

Il team operativo di Adventure Works viene eseguito in modo indipendente e dispone di aree di lavoro proprie senza Microsoft Sentinel.

Soluzione Adventure Works

I passaggi seguenti applicano l'albero delle decisioni di progettazione dell'area di lavoro di Microsoft Sentinel per determinare la progettazione ottimale dell'area di lavoro per Adventure Works:

1. Il team operativo di Adventure Works ha aree di lavoro proprie, quindi continuare con il passaggio 2.

2. Adventure Works non ha requisiti normativi, quindi continuare con il passaggio 3.

3. Adventure Works include tre tenant di Microsoft Entra e deve raccogliere origini dati a livello di tenant, ad esempio i log di Office 365. Adventure Works deve quindi creare almeno aree di lavoro di Microsoft Sentinel, una per ogni tenant.

4. Adventure Works non ha bisogno di suddividere gli addebiti, quindi continuare con il passaggio 5.

5. Poiché il team operativo di Adventure Works ha aree di lavoro proprie, tutti i dati presi in considerazione in questa decisione verranno usati dal team SOC adventure works.

6. I costi della larghezza di banda non rappresentano un problema importante per Adventure Works, quindi continuare con il passaggio 7.

7. Adventure Works deve separare i dati in base alla proprietà, perché il team SOC di ogni contenuto deve accedere solo ai dati rilevanti per tale contenuto. Tuttavia, anche il team SOC di ogni continente deve accedere al portale completo di Microsoft Sentinel.

8. Adventure Works non deve controllare l'accesso ai dati in base alla tabella.

La progettazione dell'area di lavoro di Microsoft Sentinel risultante per Adventure Works è illustrata nell'immagine seguente, incluse solo le origini di log chiave per semplicità di progettazione:

La soluzione suggerita include:

• Un'area di lavoro separata di Microsoft Sentinel per ogni tenant di Microsoft Entra. Ogni area di lavoro raccoglie i dati correlati al tenant per tutte le origini dati.

• Il team SOC di ogni continente ha accesso solo all'area di lavoro nel proprio tenant, assicurandosi che solo i log generati entro il limite del tenant siano accessibili da ogni team SOC.

• Il team SOC centrale può comunque operare da un tenant Microsoft Entra separato, usando Azure Lighthouse per accedere a ognuno dei diversi ambienti di Microsoft Sentinel. Se non è presente un altro tenant, il team SOC centrale può comunque usare Azure Lighthouse per accedere alle aree di lavoro remote.

• Il team SOC centrale può anche creare un'altra area di lavoro se deve archiviare gli artefatti che rimangono nascosti dai team SOC del continente o se vuole inserire altri dati non rilevanti per i team SOC del continente.

Passaggi successivi

In questo articolo è stato esaminato un set di progettazioni di aree di lavoro suggerite per le organizzazioni.

Prepararsi per più aree di lavoro