Metodtips för Microsoft Sentinel-arbetsytearkitektur

När du planerar distributionen av Microsoft Sentinel-arbetsytan måste du också utforma log Analytics-arbetsytans arkitektur. Beslut om arbetsytans arkitektur styrs vanligtvis av affärskrav och tekniska krav. Den här artikeln går igenom viktiga beslutsfaktorer som hjälper dig att fastställa rätt arbetsytearkitektur för dina organisationer, inklusive:

• Oavsett om du ska använda en enda klient eller flera klienter
• Eventuella efterlevnadskrav för datainsamling och lagring
• Så här styr du åtkomsten till Microsoft Sentinel-data
• Kostnadskonsekvenser för olika scenarier

Mer information finns i Utforma din Microsoft Sentinel-arbetsytearkitektur och Exempel på arbetsytedesign för vanliga scenarier, samt Aktiviteter före distribution och förutsättningar för att distribuera Microsoft Sentinel.

Se vår video: Architecting SecOps for Success: Best Practices for Deploying Microsoft Sentinel (Skapa SecOps för framgång: Metodtips för att distribuera 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 Azure Active Directory-klientorganisationer (Azure AD),till följd av sammanslagningar och förvärv eller på grund av krav på identitetsavskiljning.

När du bestämmer 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.

Arbeta med flera klienter

Om du har flera klienter, till exempel om du är en leverantör av hanterade säkerhetstjänster (MSSP), rekommenderar vi att du skapar minst en arbetsyta för varje Azure AD-klient för att stödja inbyggda tjänst-till-tjänst-dataanslutningar som endast fungerar i deras egen Azure AD-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-aktivitet eller Azure Active Directory.

Använd Azure Lighthouse för att hantera flera Microsoft Sentinel-instanser i olika klienter.

Överväganden för efterlevnad

När dina data har samlats in, lagrats och bearbetats kan efterlevnad bli ett viktigt designkrav, med stor 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 utvärdera risker och få insikter i Microsoft Sentinel-arbetsflöden är en prioritet för många kunder.

I Microsoft Sentinel lagras och bearbetas data huvudsakligen i samma geografiska område eller region, med vissa undantag, till exempel när du använder identifieringsregler som utnyttjar 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 datahemhemlighet
• Datahemhemlighet i Azure
• Lagra och bearbeta EU-data i EU – EU-policybloggen

Börja verifiera din efterlevnad genom att utvärdera dina datakällor och hur och var de skickar data.

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 webbplats, eller regler och kontroller som gör modeller för 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:

• Egress 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-utgående trafik debiteras också, vilket kanske inte påverkar dig såvida du inte exporterar data utanför Log Analytics-arbetsytan. Du kan till exempel debiteras för utgående Internet-trafik om du exporterar Log Analytics-data till en lokal server.

• Bandbreddskostnaderna varierar beroende på käll- och målregion och insamlingsmetod. Mer information finns i:

  • Prissättning för bandbredd
  • Avgifter för dataöverföringar med Log Analytics .

• 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 manuellt distribuera varje resurs i varje region.

• Anslutningsappar som baseras på diagnostikinställningar medför inte kostnader för bandbredd. Mer information finns i Hantera användning och kostnader med Azure Monitor loggar.

Om du till exempel bestämmer dig för att samla in loggar från Virtual Machines i USA, östra och skicka dem till en Microsoft Sentinel-arbetsyta i USA, västra debiteras du indatakostnader 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 över hela 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 något problem.

Att förstå om bandbreddskostnader motiverar separata Microsoft Sentinel-arbetsytor beror på den mängd 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 Datahemlighet 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 programteamen bara behöver åtkomst till specifika delar. Oberoende säkerhetsteam kan också behöva komma åt Microsoft Sentinel-funktioner, men med olika datamängder.

Kombinera RBAC för resurskontext och RBAC på tabellnivå för att ge dina team en mängd olika åtkomstalternativ som bör stödja 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 driftteam 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.

Förutom säkerhetsprenumerationen används en separat prenumeration som programteamen använder som värd för sina arbetsbelastningar. Programteamen beviljas åtkomst till sina respektive resursgrupper, där de kan hantera sina resurser. Med den här separata prenumerationen och RBAC för resurskontext kan dessa team visa loggar som genereras av alla resurser som de har åtkomst till, även om loggarna lagras på en arbetsyta där de inte har direkt åtkomst. Programteamen kan komma åt sina loggar via området Loggar i Azure Portal 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 på samma gång.

Azure-resurser har inbyggt stöd för RBAC för resurskontext, men kan kräva ytterligare finjustering när du arbetar med icke-Azure-resurser. Mer information finns i Konfigurera explicit RBAC för resurskontext.

RBAC på tabellnivå

Med RBAC på tabellnivå kan du definiera specifika datatyper (tabeller) så att de endast är tillgängliga för en angiven uppsättning användare.

Överväg till exempel om den organisation vars arkitektur beskrivs i bilden ovan också måste bevilja åtkomst till Office 365 loggar till ett internt 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 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 Azure AD-klient eller över 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 metodvägledning när du skapar Log Analytics-arbetsytan som du ska använda 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 kan identifieras bland dina andra arbetsytor.

• Använd samma arbetsyta för både Microsoft Sentinel och Microsoft Defender for Cloud , 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 din projicerade datainmatning är runt 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.

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-instanspå en enda plats.

Om du vill referera till data som lagrasi andra Microsoft Sentinel-arbetsytor, till exempel i arbetsböcker mellan arbetsytor, använder du frågor mellan arbetsytor.

Det bästa sättet 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 din aktuella åtgärd. 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 klienter.

Nästa steg