Metodtips för arbetsytearkitektur i Microsoft Sentinel
När du planerar distributionen av Microsoft Sentinel-arbetsytan måste du även utforma log analytics-arbetsytearkitekturen. Beslut om arbetsytearkitekturen styrs vanligtvis av affärs- och tekniska krav. Den här artikeln granskar viktiga beslutsfaktorer som hjälper dig att fastställa rätt arbetsytearkitektur för dina organisationer, inklusive:
- Oavsett om du ska använda en enskild klientorganisation eller flera klientorganisationer
- Alla efterlevnadskrav som du har för datainsamling och lagring
- Så här styr du åtkomsten till Microsoft Sentinel-data
- Kostnadskonsekvenser för olika scenarier
Mer information finns i Designa din Microsoft Sentinel-arbetsytearkitektur och Exempel på arbetsytedesign för vanliga scenarier, samt aktiviteter före distribution och förutsättningar för distribution av Microsoft Sentinel.
Se vår video: Architecting SecOps for Success: Best Practices for Deploying Microsoft Sentinel .Se vår video: Architecting SecOps for Success: Best Practices for Deploying Microsoft Sentinel .
Den här artikeln är en del av distributionsguiden för Microsoft Sentinel.
Överväganden för innehavare
Färre arbetsytor är enklare att hantera, men du kan ha specifika behov för flera klienter och arbetsytor. Många organisationer har till exempel en molnmiljö som innehåller flera Microsoft Entra-klienter, till följd av sammanslagningar och förvärv eller på grund av krav på identitetsavgränsning.
När du fastställer hur många klienter och arbetsytor som ska användas bör du tänka på att de flesta Microsoft Sentinel-funktioner fungerar med hjälp av en enda arbetsyta eller Microsoft Sentinel-instans, och Microsoft Sentinel matar in alla loggar som finns på arbetsytan.
Kostnader är en av de viktigaste övervägandena när du fastställer Microsoft Sentinel-arkitekturen. Mer information finns i Kostnader och fakturering för Microsoft Sentinel.
Arbeta med flera klienter
Om du har flera klienter, till exempel om du är en hanterad leverantör av säkerhetstjänster (MSSP), rekommenderar vi att du skapar minst en arbetsyta för varje Microsoft Entra-klientorganisation för att stödja inbyggda tjänst-till-tjänst-dataanslutningar som endast fungerar inom sin egen Microsoft Entra-klientorganisation.
Alla anslutningsappar som baseras på diagnostikinställningar kan inte anslutas till en arbetsyta som inte finns i samma klientorganisation där resursen finns. Detta gäller för anslutningsappar som Azure Firewall, Azure Storage, Azure Activity eller Microsoft Entra-ID.
Använd Azure Lighthouse för att hantera flera Microsoft Sentinel-instanser i olika klientorganisationer.
Kommentar
Partnerdataanslutningar baseras ofta på API- eller agentsamlingar och är därför inte kopplade till en specifik Microsoft Entra-klientorganisation.
Överväganden gällande efterlevnad
När dina data har samlats in, lagrats och bearbetats kan efterlevnad bli ett viktigt designkrav, med en betydande inverkan på din Microsoft Sentinel-arkitektur. Att kunna verifiera och bevisa vem som har åtkomst till vilka data under alla förhållanden är ett kritiskt krav på datasuveränitet i många länder och regioner, och att bedöma risker och få insikter i Microsoft Sentinel-arbetsflöden är en prioritet för många kunder.
I Microsoft Sentinel lagras och bearbetas data främst i samma geografi eller region, med vissa undantag, till exempel när du använder identifieringsregler som använder Microsofts maskininlärning. I sådana fall kan data kopieras utanför arbetsytans geografiska område för bearbetning.
Mer information finns i:
- Geografisk tillgänglighet och datahemvist
- Datahemvist i Azure
- Lagra och bearbeta EU-data i EU – EU:s policyblogg
Om du vill börja verifiera din efterlevnad utvärderar du dina datakällor och hur och var de skickar data.
Kommentar
Log Analytics-agenten stöder TLS 1.2 för att säkerställa datasäkerhet under överföring mellan agenten och Log Analytics-tjänsten samt FIPS 140-standarden.
Om du skickar data till ett geografiskt område eller en annan region än din Microsoft Sentinel-arbetsyta, oavsett om den sändande resursen finns i Azure eller inte, kan du överväga att använda en arbetsyta i samma geografiska område eller region.
Regionöverväganden
Använd separata Microsoft Sentinel-instanser för varje region. Microsoft Sentinel kan användas i flera regioner, men du kan ha krav på att separera data efter team, region eller plats eller regler och kontroller som gör modeller i flera regioner omöjliga eller mer komplexa än vad som behövs. Genom att använda separata instanser och arbetsytor för varje region kan du undvika bandbredds-/utgående kostnader för att flytta data mellan regioner.
Tänk på följande när du arbetar med flera regioner:
Utgående kostnader gäller vanligtvis när Log Analytics- eller Azure Monitor-agenten krävs för att samla in loggar, till exempel på virtuella datorer.
Utgående internet debiteras också, vilket kanske inte påverkar dig om du inte exporterar data utanför Log Analytics-arbetsytan. Du kan till exempel debiteras utgående internetavgifter om du exporterar dina Log Analytics-data till en lokal server.
Bandbreddskostnaderna varierar beroende på käll- och målregion och insamlingsmetod. Mer information finns i:
Använd mallar för dina analysregler, anpassade frågor, arbetsböcker och andra resurser för att göra dina distributioner mer effektiva. Distribuera mallarna i stället för att distribuera varje resurs manuellt i varje region.
Anslut orer som baseras på diagnostikinställningar medför inte kostnader för bandbredd. Mer information finns i Dataöverföringsavgifter med Log Analytics.
Om du till exempel bestämmer dig för att samla in loggar från virtuella datorer i USA, östra och skicka dem till en Microsoft Sentinel-arbetsyta i USA, västra, debiteras du ingresskostnader för dataöverföringen. Eftersom Log Analytics-agenten komprimerar data under överföring kan storleken som debiteras för bandbredden vara lägre än storleken på loggarna i Microsoft Sentinel.
Om du samlar in Syslog- och CEF-loggar från flera källor runt om i världen kanske du vill konfigurera en Syslog-insamlare i samma region som din Microsoft Sentinel-arbetsyta för att undvika bandbreddskostnader, förutsatt att efterlevnad inte är ett problem.
Att förstå om bandbreddskostnaderna motiverar separata Microsoft Sentinel-arbetsytor beror på mängden data som du behöver överföra mellan regioner. Använd Priskalkylatorn för Azure för att beräkna dina kostnader.
Mer information finns i Datahemvist i Azure.
Åtkomstöverväganden
Du kan ha planerat situationer där olika team behöver åtkomst till samma data. Ditt SOC-team måste till exempel ha åtkomst till alla Microsoft Sentinel-data, medan drift- och programteam endast behöver åtkomst till specifika delar. Oberoende säkerhetsteam kan också behöva komma åt Microsoft Sentinel-funktioner, men med olika uppsättningar data.
Kombinera RBAC för resurskontext och RBAC på tabellnivå för att ge dina team ett brett utbud av åtkomstalternativ som bör ha stöd för de flesta användningsfall.
Mer information finns i Behörigheter i Microsoft Sentinel.
RBAC för resurskontext
Följande bild visar en förenklad version av en arbetsytearkitektur där säkerhets- och åtgärdsteam behöver åtkomst till olika datauppsättningar, och RBAC för resurskontext används för att tillhandahålla de behörigheter som krävs.
I den här bilden placeras Microsoft Sentinel-arbetsytan i en separat prenumeration för att bättre isolera behörigheter.
Kommentar
Ett annat alternativ är att placera Microsoft Sentinel under en separat hanteringsgrupp som är dedikerad till säkerhet, vilket skulle säkerställa att endast minimala behörighetstilldelningar ärvs. Inom säkerhetsteamet tilldelas flera grupper behörigheter enligt deras funktioner. Eftersom dessa team har åtkomst till hela arbetsytan har de åtkomst till hela Microsoft Sentinel-upplevelsen, som endast begränsas av de Microsoft Sentinel-roller som de har tilldelats. Mer information finns i Behörigheter i Microsoft Sentinel.
Förutom säkerhetsprenumerationen används en separat prenumeration för programteamen som värd för deras arbetsbelastningar. Programteamen beviljas åtkomst till sina respektive resursgrupper, där de kan hantera sina resurser. Med den här separata prenumerationen och resurskontexten kan dessa team visa loggar som genereras av alla resurser de har åtkomst till, även när loggarna lagras på en arbetsyta där de inte har direkt åtkomst. Programteamen kan komma åt sina loggar via området Loggar i Azure-portalen för att visa loggar för en specifik resurs, eller via Azure Monitor, för att visa alla loggar som de kan komma åt samtidigt.
Azure-resurser har inbyggt stöd för RBAC med resurskontext, men kan kräva ytterligare finjustering när du arbetar med icke-Azure-resurser. Mer information finns i Konfigurera RBAC för resurskontext explicit.
RBAC på tabellnivå
Med RBAC på tabellnivå kan du definiera specifika datatyper (tabeller) som endast ska vara tillgängliga för en angiven uppsättning användare.
Tänk till exempel på om den organisation vars arkitektur beskrivs i bilden ovan också måste bevilja åtkomst till Office 365-loggar till en intern granskningsteam. I det här fallet kan de använda RBAC på tabellnivå för att ge granskningsteamet åtkomst till hela OfficeActivity-tabellen , utan att ge behörighet till någon annan tabell.
Åtkomstöverväganden med flera arbetsytor
Om du har olika entiteter, dotterbolag eller geografiska områden i din organisation, var och en med sina egna säkerhetsteam som behöver åtkomst till Microsoft Sentinel, använder du separata arbetsytor för varje entitet eller dotterbolag. Implementera de separata arbetsytorna i en enda Microsoft Entra-klientorganisation eller mellan flera klienter med hjälp av Azure Lighthouse.
Ditt centrala SOC-team kan också använda ytterligare en valfri Microsoft Sentinel-arbetsyta för att hantera centraliserade artefakter som analysregler eller arbetsböcker.
Mer information finns i Förenkla arbetet med flera arbetsytor.
Tekniska metodtips för att skapa din arbetsyta
Använd följande metodtips när du skapar Log Analytics-arbetsytan som du använder för Microsoft Sentinel:
När du namnger din arbetsyta ska du inkludera Microsoft Sentinel eller någon annan indikator i namnet, så att den enkelt identifieras bland dina andra arbetsytor.
Använd samma arbetsyta för både Microsoft Sentinel och Microsoft Defender för molnet, så att alla loggar som samlas in av Microsoft Defender för molnet också kan matas in och användas av Microsoft Sentinel. Standardarbetsytan som skapas av Microsoft Defender för molnet visas inte som en tillgänglig arbetsyta för Microsoft Sentinel.
Använd ett dedikerat arbetsytekluster om den beräknade datainmatningen är cirka eller mer än 1 TB per dag. Med ett dedikerat kluster kan du skydda resurser för dina Microsoft Sentinel-data, vilket ger bättre frågeprestanda för stora datamängder. Dedikerade kluster ger också möjlighet till mer kryptering och kontroll av organisationens nycklar.
Använd inte ett resurslås på en Log Analytics-arbetsyta som du använder för Microsoft Sentinel. Ett resurslås på en arbetsyta kan orsaka att många Microsoft Sentinel-åtgärder misslyckas.
Förenkla arbetet med flera arbetsytor
Om du behöver arbeta med flera arbetsytor förenklar du incidenthanteringen och undersökningen genom att komprimera och lista alla incidenter från varje Microsoft Sentinel-instans på en enda plats.
Om du vill referera till data som lagras i andra Microsoft Sentinel-arbetsytor, till exempel i arbetsböcker mellan arbetsytor, använder du frågor mellan arbetsytor.
Den bästa tiden att använda frågor mellan arbetsytor är när värdefull information lagras på en annan arbetsyta, prenumeration eller klientorganisation och kan ge värde till den aktuella åtgärden. Följande kod visar till exempel en exempelfråga mellan arbetsytor:
union Update, workspace("contosoretail-it").Update, workspace("WORKSPACE ID").Update
| where TimeGenerated >= ago(1h)
| where UpdateState == "Needed"
| summarize dcount(Computer) by Classification
Mer information finns i Utöka Microsoft Sentinel mellan arbetsytor och klientorganisationer.
Nästa steg
I den här artikeln har du lärt dig om viktiga beslutsfaktorer som hjälper dig att fastställa rätt arbetsytearkitektur för dina organisationer.