Utforma arkitekturen för Microsoft Sentinel-arbetsytan
Den här artikeln innehåller ett beslutsträd som hjälper dig att fatta viktiga beslut om hur du utformar din Microsoft Sentinel-arbetsytearkitektur. Mer information finns i Microsoft Sentinel-exempel på arbetsytedesign och metodtips för Microsoft Sentinel-arbetsytearkitektur. Den här artikeln är en del av distributionsguiden för Microsoft Sentinel.
Förutsättningar
Kontrollera att du har följande information innan du går igenom beslutsträdet:
| Förutsättning | beskrivning |
|---|---|
| Regelkrav som rör Azure-datahemvist | Microsoft Sentinel kan köras på arbetsytor i de flesta, men inte alla regioner som stöds i GA för Log Analytics. Nyligen stödda Log Analytics-regioner kan ta lite tid att registrera Microsoft Sentinel-tjänsten. Data som genereras av Microsoft Sentinel, till exempel incidenter, bokmärken och analysregler, kan innehålla vissa kunddata som kommer från kundens Log Analytics-arbetsytor. Mer information finns i Geografisk tillgänglighet och datahemvist. |
| Datakällor | Ta reda på vilka datakällor du behöver ansluta, inklusive inbyggda anslutningsappar till både Microsoft- och icke-Microsoft-lösningar. Du kan också använda Common Event Format (CEF), Syslog eller REST-API för att ansluta dina datakällor till Microsoft Sentinel. Om du har virtuella Azure-datorer på flera Azure-platser som du behöver samla in loggarna från och det är viktigt att spara datautgående kostnader måste du beräkna datautgående kostnad med hjälp av priskalkylatorn bandbredd för varje Azure-plats. |
| Användarroller och dataåtkomstnivåer/behörigheter | Microsoft Sentinel använder rollbaserad åtkomstkontroll i Azure (Azure RBAC) för att tillhandahålla inbyggda roller som kan tilldelas till användare, grupper och tjänster i Azure. Alla inbyggda Microsoft Sentinel-roller ger läsåtkomst till data på din Microsoft Sentinel-arbetsyta. Därför måste du ta reda på om det finns ett behov av att styra dataåtkomsten per datakälla eller radnivå eftersom det påverkar designbeslutet för arbetsytan. Mer information finns i Anpassade roller och avancerad Azure RBAC. |
| Daglig inmatningshastighet | Den dagliga inmatningshastigheten, vanligtvis i GB/dag, är en av de viktigaste faktorerna för kostnadshantering och planeringsöverväganden och arbetsytedesign för Microsoft Sentinel. I de flesta moln- och hybridmiljöer producerar nätverksenheter, till exempel brandväggar eller proxyservrar, och Windows- och Linux-servrar de data som matas in mest. För att få de mest exakta resultaten rekommenderar Microsoft en fullständig inventering av datakällor. Alternativt innehåller Microsoft Sentinel-kostnadskalkylatorn tabeller som är användbara för att uppskatta fotavtryck för datakällor. Viktigt: De här uppskattningarna är en startpunkt, och loggens utförlighetsinställningar och arbetsbelastning ger varianser. Vi rekommenderar att du övervakar systemet regelbundet för att spåra eventuella ändringar. Regelbunden övervakning rekommenderas baserat på ditt scenario. Mer information finns i Prissättning i Azure Log Analytics. |
Beslutsträd
Följande bild visar ett fullständigt beslutsträdsflödesdiagram som hjälper dig att förstå hur du utformar din arbetsyta på bästa sätt.
Följande avsnitt innehåller en fulltextversion av det här beslutsträdet, inklusive följande anteckningar som refereras från bilden:
Obs! #1 | Anteckning #2 | Anteckning #3 | Anteckning #4 | Anteckning #5 | Anteckning #6 | Anteckning #7 | Anteckning #8 | Anteckning #9 | Anteckning #10
Steg 1: Ny eller befintlig arbetsyta?
Har du en befintlig arbetsyta som du kan använda för Microsoft Sentinel?
Om inte, och du kommer att skapa en ny arbetsyta i alla fall, fortsätter du direkt med steg 2.
Om du har en befintlig arbetsyta som du kan använda bör du överväga hur mycket data du ska mata in.
Steg 2: Behålla data i olika Azure-geografiska områden?
Om du har regelkrav för att lagra data i olika Azure-geografiska områden använder du en separat Microsoft Sentinel-arbetsyta för varje Azure-region som har efterlevnadskrav. Mer information finns i Regionöverväganden.
Om du inte behöver behålla data i olika Azure-geografiska områden fortsätter du med steg 3.
Steg 3: Har du flera Azure-klientorganisationer?
Om du bara har en enda klientorganisation fortsätter du direkt med steg 4.
Om du har flera Azure-klienter bör du överväga om du samlar in loggar som är specifika för en klientgräns, till exempel Office 365 eller Microsoft Defender XDR.
Om du inte har några klientspecifika loggar fortsätter du direkt med steg 4.
Om du samlar in klientspecifika loggar använder du en separat Microsoft Sentinel-arbetsyta för varje Microsoft Entra-klientorganisation. Fortsätt med steg 4 för andra överväganden.
Beslutsträdsanteckning nr 1: Loggar som är specifika för klientorganisationsgränser, till exempel från Office 365 och Microsoft Defender för molnet, kan bara lagras på arbetsytan inom samma klientorganisation.
Även om det är möjligt att använda anpassade insamlare för att samla in klientspecifika loggar från en arbetsyta i en annan klientorganisation rekommenderar vi inte detta på grund av följande nackdelar:
- Data som samlas in av anpassade anslutningsappar matas in i anpassade tabeller. Därför kan du inte använda alla inbyggda regler och arbetsböcker.
- Anpassade tabeller beaktas inte av några av de inbyggda funktionerna, till exempel UEBA och maskininlärningsregler.
- Ytterligare kostnader och arbete krävs för anpassade anslutningsappar, till exempel användning av Azure Functions och Logic Apps.
Om dessa nackdelar inte är ett problem för din organisation fortsätter du med steg 4 i stället för att använda separata Microsoft Sentinel-arbetsytor.
Steg 4: Dela upp fakturering/återbetalning?
Om du behöver dela upp din fakturering eller återbetalning bör du överväga om användningsrapportering eller manuell korsavgift fungerar för dig.
Om du inte behöver dela upp din fakturering eller återbetalning fortsätter du med steg 5.
Om du behöver dela upp din fakturering eller återbetalning kan du överväga att använda manuell korskostnad. För att få korrekta kostnader per entitet kan du använda en modifierad version av Microsoft Sentinel Cost-arbetsboken som delar upp kostnaden per entitet.
Om användningsrapportering eller manuell korsladdning fungerar åt dig fortsätter du med steg 5.
Om varken användningsrapportering eller manuell korsladdning fungerar för dig använder du en separat Microsoft Sentinel-arbetsyta för varje kostnadsägare.
Beslutsträdsanteckning nr 2: Mer information finns i Kostnader och fakturering för Microsoft Sentinel.
Steg 5: Samla in alla icke-SOC-data?
Om du inte samlar in några icke-SOC-data, till exempel driftdata, kan du hoppa direkt till steg 6.
Om du samlar in icke-SOC-data bör du överväga om det finns några överlappningar, där samma datakälla krävs för både SOC- och icke-SOC-data.
Om du har överlappningar mellan SOC- och icke-SOC-data behandlar du endast överlappande data som SOC-data. Fundera sedan på om inmatningen för både SOC- och icke-SOC-data individuellt är mindre än 100 GB/dag, men mer än 100 GB/dag när de kombineras:
- Ja: Fortsätt med steg 6 för ytterligare utvärdering.
- Nej: Vi rekommenderar inte att du använder samma arbetsyta för kostnadseffektivitetens skull. Fortsätt med steg 6 för ytterligare utvärdering.
Mer information finns i anmärkning 10 i båda fallen.
Om du inte har några överlappande data bör du överväga om inmatningen för både SOC- och icke-SOC-data individuellt är mindre än 100 GB/dag, men mer än 100 GB/dag när de kombineras:
- Ja: Fortsätt med steg 6 för ytterligare utvärdering. Mer information finns i anmärkning 3.
- Nej: Vi rekommenderar inte att du använder samma arbetsyta för kostnadseffektivitetens skull. Fortsätt med steg 6 för ytterligare utvärdering.
Kombinera dina SOC- och icke-SOC-data
Beslutsträdsanteckning nr 3: Även om vi vanligtvis rekommenderar att kunderna behåller en separat arbetsyta för sina icke-SOC-data så att icke-SOC-data inte omfattas av Microsoft Sentinel-kostnader, kan det finnas situationer där det är billigare att kombinera SOC- och icke-SOC-data än att separera dem.
Tänk dig till exempel en organisation som har säkerhetsloggar som matas in på 50 GB/dag, driftloggar som matas in på 50 GB/dag och en arbetsyta i regionen USA, östra.
I följande tabell jämförs arbetsytealternativ med och utan separata arbetsytor.
Kommentar
Kostnader och termer som anges i följande tabell är falska och används endast för illustrativa ändamål. Uppdaterad kostnadsinformation finns i priskalkylatorn för Microsoft Sentinel.
| Arkitektur för arbetsyta | beskrivning |
|---|---|
| SOC-teamet har en egen arbetsyta med Microsoft Sentinel aktiverat. Ops-teamet har en egen arbetsyta utan Microsoft Sentinel aktiverat. |
SOC-team: Microsoft Sentinel-kostnaden för 50 GB/dag är 6 500 USD per månad. De första tre månaderna av kvarhållning är kostnadsfria. Ops-teamet: – Kostnaden för Log Analytics på 50 GB/dag är cirka 3 500 USD per månad. – De första 31 dagarna av kvarhållning är kostnadsfria. Den totala kostnaden för båda är 10 000 USD per månad. |
| Både SOC- och Ops-team delar samma arbetsyta med Microsoft Sentinel aktiverat. | Genom att kombinera båda loggarna blir inmatningen 100 GB/dag och kvalificerar sig för åtagandenivån (50 % för Sentinel och 15 % för LA). Kostnaden för Microsoft Sentinel för 100 GB/dag är 9 000 USD per månad. |
I det här exemplet skulle du ha en kostnadsbesparingar på 1 000 USD per månad genom att kombinera båda arbetsytorna, och Ops-teamet får också 3 månaders kostnadsfri kvarhållning i stället för bara 31 dagar.
Det här exemplet är bara relevant när både SOC- och icke-SOC-data har en inmatningsstorlek på >=50 GB/dag och <100 GB/dag.
Beslutsträdsanteckning nr 10: Vi rekommenderar att du använder en separat arbetsyta för icke-SOC-data så att icke-SOC-data inte utsätts för Microsoft Sentinel-kostnader.
Den här rekommendationen för separata arbetsytor för icke-SOC-data kommer dock från ett rent kostnadsbaserat perspektiv, och det finns andra viktiga designfaktorer att undersöka när du avgör om du ska använda en enda eller flera arbetsytor. För att undvika dubbla inmatningskostnader bör du överväga att endast samla in överlappande data på en enda arbetsyta med Azure RBAC på tabellnivå.
Steg 6: Flera regioner?
Om du samlar in loggar från virtuella Azure-datorer i en enda region fortsätter du direkt med steg 7.
Om du samlar in loggar från virtuella Azure-datorer i flera regioner, hur bekymrad är du över kostnaden för utgående data?
Beslutsträdsanteckning nr 4: Datautgående avser bandbreddskostnaden för att flytta data från Azure-datacenter. Mer information finns i Regionöverväganden.
Om det är en prioritet att minska mängden arbete som krävs för att underhålla separata arbetsytor fortsätter du med steg 7.
Om datautgående kostnaden är tillräckligt viktig för att göra det värt att underhålla separata arbetsytor använder du en separat Microsoft Sentinel-arbetsyta för varje region där du behöver minska kostnaden för utgående data.
Beslutsträdsanteckning nr 5: Vi rekommenderar att du har så få arbetsytor som möjligt. Använd priskalkylatorn för Azure för att beräkna kostnaden och avgöra vilka regioner du faktiskt behöver och kombinera arbetsytor för regioner med låga utgående kostnader. Bandbreddskostnader kan bara vara en liten del av din Azure-faktura jämfört med separata inmatningskostnader för Microsoft Sentinel och Log Analytics.
Din kostnad kan till exempel uppskattas på följande sätt:
- 1 000 virtuella datorer, var och en genererar 1 GB /dag;
- Skicka data från en region i USA till en EU-region.
- Använda en komprimeringshastighet på 2:1 i agenten
Beräkningen för den här uppskattade kostnaden skulle vara:
1000 VMs * (1GB/day ÷ 2) * 30 days/month * $0.05/GB = $750/month bandwidth costDen här exempelkostnaden skulle vara mycket billigare jämfört med månadskostnaderna för en separat Microsoft Sentinel- och Log Analytics-arbetsyta.
Kommentar
Listade kostnader är falska och används endast för illustrativa ändamål. Uppdaterad kostnadsinformation finns i priskalkylatorn för Microsoft Sentinel.
Steg 7: Separera data eller definiera gränser efter ägarskap?
Om du inte behöver separera data eller definiera några ägarskapsgränser fortsätter du direkt med steg 8.
Behöver varje dataägare använda Microsoft Sentinel-portalen om du behöver separera data eller definiera gränser baserat på ägarskap?
Om varje dataägare måste ha åtkomst till Microsoft Sentinel-portalen använder du en separat Microsoft Sentinel-arbetsyta för varje ägare.
Beslutsträdsanteckning nr 6: Åtkomst till Microsoft Sentinel-portalen kräver att varje användare har en roll som minst en Microsoft Sentinel-läsare med läsbehörighet för alla tabeller på arbetsytan. Om en användare inte har åtkomst till alla tabeller på arbetsytan måste de använda Log Analytics för att komma åt loggarna i sökfrågor.
Om åtkomsten till loggarna via Log Analytics räcker för alla ägare utan åtkomst till Microsoft Sentinel-portalen fortsätter du med steg 8.
Mer information finns i Behörigheter i Microsoft Sentinel.
Steg 8: Styra dataåtkomsten efter datakälla/tabell?
Om du inte behöver styra dataåtkomsten via källa eller tabell använder du en enda Microsoft Sentinel-arbetsyta.
Om du behöver styra dataåtkomsten via källa eller tabell bör du överväga att använda RBAC för resurskontext i följande situationer:
Om du behöver kontrollera åtkomsten på radnivå, till exempel att tillhandahålla flera ägare för varje datakälla eller tabell
Om du har flera anpassade datakällor/tabeller, där var och en behöver separata behörigheter
Om du i andra fall inte behöver styra åtkomsten på radnivå anger du flera anpassade datakällor/tabeller med separata behörigheter, använder en enda Microsoft Sentinel-arbetsyta med RBAC på tabellnivå för dataåtkomstkontroll.
Överväganden för RBAC på resurskontext eller tabellnivå
När du planerar att använda RBAC på resurskontext eller tabellnivå bör du tänka på följande information:
Beslutsträdsanteckning nr 7: Om du vill konfigurera resurskontext-RBAC för icke-Azure-resurser kanske du vill associera ett resurs-ID till data när du skickar till Microsoft Sentinel, så att behörigheten kan begränsas med hjälp av resurskontext-RBAC. Mer information finns i Konfigurera rbac - och åtkomstlägen för resurskontext explicit efter distribution.
Beslutsträdsanteckning nr 8: Resursbehörigheter eller resurskontext tillåter användare att endast visa loggar för resurser som de har åtkomst till. Åtkomstläget för arbetsytan måste vara inställt på Behörigheter för användarresurser eller arbetsytor. Endast tabeller som är relevanta för de resurser där användaren har behörighet tas med i sökresultaten från sidan Loggar i Microsoft Sentinel.
Beslutsträdsanteckning nr 9: Med RBAC på tabellnivå kan du definiera mer detaljerad kontroll för data på en Log Analytics-arbetsyta utöver de andra behörigheterna. Med den här kontrollen kan du definiera specifika datatyper som endast är tillgängliga för en viss uppsättning användare. Mer information finns i RBAC på tabellnivå i Microsoft Sentinel.
Nästa steg
I den här artikeln har du granskat ett beslutsträd som hjälper dig att fatta viktiga beslut om hur du utformar din Microsoft Sentinel-arbetsytearkitektur.