Progettazioni di aree di lavoro Log Analytics di esempio per Microsoft Sentinel
Questo articolo descrive le progettazioni suggerite dell'area di lavoro Log Analytics 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
Per altre informazioni, vedere Progettare l’architettura di un’area di lavoro Log Analytics.
Questo articolo fa parte della Guida alla distribuzione di 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 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 Europa settentrionale, dove ha già un'area di lavoro. Pertanto, in questo caso, i costi della larghezza di banda non sono un problema.
- Contoso ha due diversi tenant di Microsoft Entra e raccoglie da origini dati a livello di tenant, ad esempio Office 365 e i log di controllo e di accesso di Microsoft Entra, ed è necessaria almeno un'area di lavoro per tenant.
- 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.
- Contoso ha un singolo team SOC che usa 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 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 Log Analytics abilitate per 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.
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 soluzione di 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 li richiedono per mantenere separati i dati.
Fabrikam ha un ambiente a tenant singolo e non richiede aree di lavoro separate per ogni tenant.
Fabrikam richiede tuttavia 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 Log Analytics abilitata per Microsoft Sentinel e tutti i log del servizio Azure Kubernetes in 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 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.
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. Poiché gli eventi di sicurezza e gli eventi di attività di 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 operatore.
La progettazione dell'area di lavoro 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 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 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
La soluzione Adventure Works include le considerazioni seguenti:
Il team operativo di Adventure Works dispone già di aree di lavoro proprie, quindi non è necessario crearne uno nuovo.
Adventure Works non ha requisiti normativi che li richiedono per mantenere separati i dati.
Adventure Works include tre tenant di Microsoft Entra e deve raccogliere origini dati a livello di tenant, ad esempio i log di Office 365. Pertanto, Adventure Works deve 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 SOC di Adventure Works, devono separare i dati in base alla proprietà, perché ogni team SOC deve accedere solo ai dati rilevanti per tale team. Ogni team SOC deve anche accedere al portale completo di Microsoft Sentinel. 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 semplicità di progettazione:
La soluzione suggerita include:
- Un'area di lavoro Log Analytics separata abilitata per 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.