Utforma din Microsoft Sentinel-arbetsytearkitektur

Den här artikeln innehåller ett beslutsträd som hjälper dig att fatta viktiga beslut om hur du utformar arkitekturen för Microsoft Sentinel-arbetsytan. Mer information finns i Microsoft Sentinel-exempel på arbetsytedesign och Metodtips för Microsoft Sentinel-arbetsytearkitektur.

Förutsättningar

Kontrollera att du har följande information innan du går igenom beslutsträdet:

Beslutsträd

Följande bild visar ett fullständigt flödesschema för beslutsträd som hjälper dig att förstå hur du bäst utformar din arbetsyta.

Följande avsnitt innehåller en fulltextversion av det här beslutsträdet, inklusive följande anteckningar som refereras från bilden:

Anmärkning nr 1 | Anmärkning nr 2 | Anmärkning nr 3 | Anmärkning nr 4 | Anmärkning nr 5 | Anmärkning nr 6 | Anmärkning nr 7 | Anmärkning nr 8 | Anmärkning nr 9 | Anmärkning nr 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 vilket fall som helst, fortsätter du direkt med steg 2.

• Om du har en befintlig arbetsyta som du kan använda kan du fundera på hur mycket data du kommer att mata in.

  • Om du ska mata in mer än 100 GB per dag rekommenderar vi att du använder en separat arbetsyta för kostnadseffektivitet.

  • Om du ska mata in mindre än 100 GB/dag fortsätter du med steg 2 för ytterligare utvärdering. Överväg den här frågan igen när den uppstår i steg 5.

Steg 2: Lagra 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 lagra data i olika Azure-geografiska områden fortsätter du med steg 3.

Steg 3: Har du flera Azure-klienter?

• 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 365 Defender.

  • 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 Azure AD-klientorganisation. Fortsätt med steg 4 för andra överväganden.

    Beslutsträdsnotering nr 1:Loggar som är specifika för klientgränser, till exempel från Office 365 och Microsoft Defender for Cloud, 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 kommer du inte att kunna 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 som krävs för de anpassade anslutningsapparna, till exempel att använda Azure Functions och Logic Apps.

    Om dessa nackdelar inte är något 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/återfakturering?

Om du behöver dela upp din fakturering eller debitering bör du överväga om användningsrapporteringen eller den manuella korsavgiften fungerar för dig.

• Om du inte behöver dela upp din fakturering eller återfakturering fortsätter du med steg 5.

• Om du behöver dela upp din fakturering eller återfakturering bör du överväga om användningsrapportering eller manuella korsde avgifter fungerar för dig.

  • Om användningsrapportering eller manuell korsdeladering fungerar för dig fortsätter du med steg 5.

  • Om varken användningsrapportering eller manuell korsdeladering fungerar för dig använder du en separat Microsoft Sentinel-arbetsyta för varje kostnadsägare.

  Beslutsträdsnotering nr 2:Mer information finns i Kostnader och fakturering för Microsoft Sentinel.

Steg 5: Samla in icke-SOC-data?

• Om du inte samlar in några icke-SOC-data, till exempel driftdata, kan du gå 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 överlappande data endast som SOC-data. Överväg sedan om inmatningen för både SOC- och icke-SOC-data individuellt är mindre än 100 GB/dag, men mer än 100 GB/dag i kombination:

  • Ja: Fortsätt med steg 6 för ytterligare utvärdering.
  • Nej: Vi rekommenderar inte att du använder samma arbetsyta av kostnadseffektivitetsskäl. Fortsätt med steg 6 för ytterligare utvärdering.

  I båda fallen finns mer information i anmärkning 10.

  Om du inte har några överlappande data bör du överväga om datainmatningen för både SOC- och icke-SOC-data individuellt är mindre än 100 GB/dag, men mer än 100 GB/dag i kombination:

  • 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 av kostnadseffektivitetsskäl. Fortsätt med steg 6 för ytterligare utvärdering.

Kombinera SOC- och icke-SOC-data

Beslutsträdsnotering 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 vid 50 GB per dag, operationsloggar som matas in vid 50 GB per dag och en arbetsyta i regionen USA, östra.

I följande tabell jämförs alternativ för arbetsytor med och utan separata arbetsytor.

I det här exemplet skulle du ha en kostnadsbesparing på 1 000 USD per månad genom att kombinera båda arbetsytorna. Ops-teamet får också tre månaders kostnadsfri kvarhållning i stället för bara 31 dagar.

Det här exemplet är endast relevant när både SOC- och icke-SOC-data har en datainmatningsstorlek på >=50 GB/dag och <100 GB/dag.

Beslutsträdsnotering 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 kostnader för Microsoft Sentinel.

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 eller flera arbetsytor. För att undvika dubbla datainmatningskostnader bör du överväga att samla in överlappande data på en enskild arbetsyta endast med Azure RBAC på tabellnivå.

Steg 6: Flera regioner?

• Om du endast samlar in loggar från virtuella Azure-datorer i en enda region fortsätter du direkt med steg 7.

• Hur oroas du över kostnaden för utgående data om du samlar in loggar från virtuella Azure-datorer i flera regioner?

  Beslutsträdsnotering nr 4:Utgående data 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 kostnaden för utgående data är tillräckligt stor för att det ska vara 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ädsnotering 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. Bandbreddskostnaderna kan bara vara en liten del av din Azure-faktura jämfört med separata kostnader för Microsoft Sentinel- och Log Analytics-inmatning.

    Kostnaden kan till exempel beräknas på följande sätt:

    • 1 000 virtuella datorer som var och en genererar 1 GB/dag.
    • Skicka data från en region i USA till en EU-region.
    • Använda komprimeringsfrekvensen 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 cost

    Den här exempelkostnaden skulle vara mycket billigare jämfört med månadskostnaden för en separat Microsoft Sentinel- och Log Analytics-arbetsyta.

    Anteckning

    Listade kostnader är falska och används endast i illustrerande syfte. Uppdaterad kostnadsinformation finns i Priskalkylatorn för Microsoft Sentinel.

Steg 7: Separera data eller definiera gränser efter ägarskap?

• Om du inte behöver åtsegrera data eller definiera några ägarskapsgränser fortsätter du direkt med steg 8.

• Om du behöver åtsega data eller definiera gränser baserat på ägarskap , behöver varje dataägare använda Microsoft Sentinel-portalen?

  • 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ädsnotering #6:Åtkomst till Microsoft Sentinel-portalen kräver att varje användare har en roll som minst En Microsoft Sentinel-läsare,med läsarbehörighet för alla tabeller i 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 tillräcklig 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: Kontrollera dataåtkomst efter datakälla/tabell?

• Om du inte behöver styra dataåtkomsten efter källa eller tabell använder du en enda Microsoft Sentinel-arbetsyta.

• Om du behöver styra dataåtkomsten efter 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 genom att ange 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

  I andra fall, när du inte behöver kontrollera å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 resurskontext eller RBAC på tabellnivå

Tänk på följande när du planerar att använda RBAC för resurskontext eller tabellnivå:

• Beslutsträdsnotering nr 7:Om du vill konfigurera RBAC för resurskontext för icke-Azure-resurser kan du associera ett resurs-ID till data när du skickar till Microsoft Sentinel, så att behörigheten kan vara begränsad med hjälp av RBAC för resurskontext. Mer information finns i Konfigurera explicit RBAC för resurskontext och åtkomstlägen efter distribution.

• Beslutsträdsnotering 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å Användarresurs- eller arbetsytebehörigheter. 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ädsnotering nr 9: Med RBAC på tabellnivå kan du definiera mer detaljerad kontroll för data i 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 specifik uppsättning användare. Mer information finns i RBAC på tabellnivå i Microsoft Sentinel.

Nästa steg

Exempel på det här beslutsträdet i praktiken finns i Microsoft Sentinel-exempelarbetsytans utformning.

Mer information finns i:

• Metodtips för Microsoft Sentinel-arbetsytearkitektur
• Metodtips för Microsoft Sentinel