Progettazioni di aree di lavoro log analytics di esempio per Microsoft Sentinel

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

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

Per altre informazioni, vedere Progettare un'architettura dell'area di lavoro Log Analytics.

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

Esempio 1: Più tenant e aree

Contoso Corporation è un'azienda multinazionale con sede a Londra. Contoso ha uffici in tutto il mondo, con importanti hub a New York e Tokyo. Di recente, Contoso ha migrato la suite di produttività in Office 365, con molti carichi di lavoro migrati in Azure.

Tenant di Contoso

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

Conformità di Contoso e distribuzione a livello di area

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

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

Tipi di risorse e requisiti di raccolta di Contoso

Contoso deve raccogliere eventi dalle origini dati seguenti:

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

Azure macchine virtuali si trovano principalmente nell'area settentrionale dell'UE, con solo poche macchine virtuali negli Stati Uniti orientali e nel Giappone occidentale. Contoso usa Microsoft Defender per i server in tutte le macchine virtuali 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 dispone già di una singola area di lavoro Log Analytics esistente usata dal team operativo per monitorare l'infrastruttura. Questa area di lavoro si trova in Contoso Microsoft Entra tenant, all'interno dell'area settentrionale dell'UE, e viene usata per raccogliere i log da Azure macchine virtuali in tutte le aree. Attualmente inseriranno 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 soluzione di Constoso include le considerazioni seguenti:

• Contoso ha già un'area di lavoro esistente e vuole esplorare l'abilitazione di Microsoft Sentinel nella stessa area di lavoro.
• Contoso ha requisiti normativi, quindi è necessaria almeno un'area di lavoro Log Analytics abilitata per Microsoft Sentinel in Europa.
• La maggior parte delle macchine virtuali di Contoso è l'area dell'UE settentrionale, in cui è già disponibile un'area di lavoro. Pertanto, in questo caso, i costi della larghezza di banda non sono un problema.
• Contoso ha due tenant di Microsoft Entra diversi e raccoglie da origini dati a livello di tenant, ad esempio Office 365 e Microsoft Entra log di accesso e controllo, e sono necessarie almeno un'area di lavoro per ogni tenant.
• Contoso deve raccogliere dati non SOC, anche se non c'è 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 l'efficienza dei costi.
• Contoso ha un singolo team SOC che userà Microsoft Sentinel, quindi non è necessaria alcuna separazione aggiuntiva.
• 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 risultante per Contoso è illustrata nell'immagine seguente:

La soluzione suggerita include:

• Un'area di lavoro Log Analytics separata per il team di Contoso Operations. 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 Log Analytics abilitate per Microsoft Sentinel, una in ogni tenant Microsoft Entra, per inserire dati da Office 365, attività Azure, Microsoft Entra ID e tutti i servizi PaaS Azure.
• Tutti gli altri dati, provenienti da origini dati locali, possono essere indirizzati a una delle due aree di lavoro.

Esempio 2: Tenant singolo con più cloud

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

Requisiti di tenancy di Fabrikam

Fabrikam ha un singolo tenant Microsoft Entra.

Conformità fabrikam e distribuzione a livello di area

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

Requisiti di raccolta e tipi di risorse Fabrikam

Fabrikam deve raccogliere eventi dalle origini dati seguenti:

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

Requisiti di accesso di Fabrikam

Il team di Fabrikam Operations deve accedere a:

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

Il team SOC di Fabrikam deve accedere a:

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

Soluzione di Fabrikam

La soluzione fabrikam include le considerazioni seguenti:

• Fabrikam non ha un'area di lavoro esistente, quindi sarà necessaria automaticamente una nuova area di lavoro.

• Fabrikam non ha requisiti normativi che richiedono la separazione dei dati.

• Fabrikam ha un ambiente a tenant singolo e non richiede aree di lavoro separate per ogni tenant.

• Fabrikam, tuttavia, richiederà aree di lavoro separate per i team SOC e Operations.

  Il team di Fabrikam Operations deve raccogliere dati sulle prestazioni, sia dalle macchine virtuali che dal servizio Azure Kubernetes. Poiché il servizio Azure Kubernetes si basa 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 Log Analytics abilitata per Microsoft Sentinel e tutti i log del servizio Azure Kubernetes a un'area di lavoro separata, dove 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 Azure (AMA) per suddividere i log, inviando eventi di sicurezza all'area di lavoro, nonché prestazioni ed eventi di Windows all'area di lavoro senza Microsoft Sentinel.

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

• Fabrikam deve controllare l'accesso per i dati sovrapposti, inclusi gli eventi di sicurezza e gli eventi di attività Azure, ma non è previsto alcun requisito a livello di riga. Poiché gli eventi di sicurezza e gli eventi di attività Azure non sono log personalizzati, 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 risultante per Fabrikam è illustrata nell'immagine seguente, incluse solo le origini di log chiave per motivi di semplicità di progettazione:

La soluzione suggerita include:

• Due aree di lavoro separate nell'area Stati Uniti: una per il team SOC con Microsoft Sentinel abilitata e un'altra per il team operativo, senza Microsoft Sentinel.
• Il Azure Monitoring Agent (AMA), usato per determinare quali log vengono inviati a ogni area di lavoro da Azure e macchine virtuali locali.
• Impostazioni di diagnostica, usate per determinare quali log vengono inviati a ogni area di lavoro da Azure risorse, ad esempio il servizio Azure Kubernetes.
• Dati sovrapposti inviati all'area di lavoro Log Analytics abilitata per Microsoft Sentinel, con 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 geografiche e sicurezza centralizzata

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

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

Requisiti di tenancy di Adventure Works

Adventure Works ha tre diversi tenant Microsoft Entra, uno per ognuno dei continenti in cui hanno sotto-entità: Asia, Europa e Africa. I diversi paesi/aree geografiche delle sotto-entità 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 .

Conformità di Adventure Works e requisiti a livello di area

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

Tipi di risorse e requisiti di raccolta di Adventure Works

Adventure Works deve raccogliere le origini dati seguenti per ogni sotto-entità:

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

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

Requisiti di accesso di Adventure Works

Adventure Works dispone di un singolo team SOC centralizzato che supervisiona le operazioni di sicurezza per tutte le diverse entità secondarie.

Adventure Works ha anche tre team SOC indipendenti, uno per ognuno dei continenti. Il team SOC di ogni continente deve essere in grado di accedere solo ai dati generati all'interno dell'area, senza visualizzare i dati provenienti da altri continenti. Ad esempio, il team soc Asia deve accedere ai dati solo da Azure risorse distribuite in Asia, Microsoft Entra accessi dal tenant Asia e i 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 personalizzate senza Microsoft Sentinel.

Soluzione Adventure Works

La soluzione Adventure Works include le considerazioni seguenti:

• Il team operativo di Adventure Works ha già aree di lavoro personalizzate, quindi non è necessario crearne una nuova.

• Adventure Works non ha requisiti normativi che richiedono la separazione dei dati.

• Adventure Works dispone di tre tenant Microsoft Entra ed è necessario raccogliere origini dati a livello di tenant, ad esempio i log Office 365. Adventure Works deve quindi creare almeno un'area di lavoro Log Analytics abilitata per Microsoft Sentinel in ogni tenant.

• Anche se tutti i dati considerati in questa decisione verranno usati dal team di Adventure Works SOC, devono separare i dati in base alla proprietà, poiché ogni team soc deve accedere solo ai dati rilevanti per tale team. Ogni team soc deve anche accedere al portale di Microsoft Sentinel completo. Adventure Works non deve controllare l'accesso ai dati in base alla tabella.

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

La soluzione suggerita include:

• Un'area di lavoro Log Analytics separata abilitata per Microsoft Sentinel per ogni tenant 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, assicurando che solo i log generati all'interno del limite del tenant siano accessibili da ogni team SOC.
• Il team centrale del SOC può comunque operare da un tenant Microsoft Entra separato, usando Azure Lighthouse per accedere a ognuno dei diversi ambienti Microsoft Sentinel. Se non c'è nessun 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 ai 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.

Preparare più aree di lavoro