Exempel på arbetsytedesign i Microsoft Sentinel

Den här artikeln beskriver föreslagna arbetsytedesigner för organisationer med följande exempelkrav:

  • Flera klienter och regioner med krav på europeisk datasuveränitet
  • Enskild klientorganisation med flera moln
  • Flera klienter, med flera regioner och centraliserad säkerhet

Exemplen i den här artikeln använder beslutsträdet för design av Microsoft Sentinel-arbetsytor för att fastställa den bästa arbetsytedesignen för varje organisation. Mer information finns i Metodtips för Microsoft Sentinel-arbetsytearkitektur.

Den här artikeln är en del av distributionsguiden för Microsoft Sentinel.

Exempel 1: Flera klienter och regioner

Contoso Corporation är ett multinationellt företag med huvudkontor i London. Contoso har kontor runt om i världen, med viktiga nav i New York City och Tokyo. Contoso har nyligen migrerat sin produktivitetssvit till Office 365 med många arbetsbelastningar migrerade till Azure.

Contoso-klienter

På grund av ett förvärv för flera år sedan har Contoso två Microsoft Entra-klienter: contoso.onmicrosoft.com och wingtip.onmicrosoft.com. Varje klientorganisation har en egen Office 365-instans och flera Azure-prenumerationer, enligt följande bild:

Diagram of Contoso tenants, each with separate sets of subscriptions.

Contosos efterlevnad och regionala distribution

Contoso har för närvarande Azure-resurser i tre olika regioner: USA, östra, EUROPA, norra och västra Japan, och strikta krav för att behålla alla data som genereras i Europa inom Europa-regioner.

Båda Contosos Microsoft Entra-klienter har resurser i alla tre regionerna: USA, östra, EU, norra och Västra Japan

Contosos resurstyper och insamlingskrav

Contoso måste samla in händelser från följande datakällor:

  • Office 365
  • Inloggnings- och granskningsloggar för Microsoft Entra
  • Azure-aktivitet
  • Windows-säkerhet händelser från både lokala och virtuella Azure-datorer
  • Syslog, från både lokala och virtuella Azure-källor
  • CEF, från flera lokala nätverksenheter, till exempel Palo Alto, Cisco ASA och Cisco Meraki
  • Flera Azure PaaS-resurser, till exempel Azure Firewall, AKS, Key Vault, Azure Storage och Azure SQL
  • Cisco Umbrella

Virtuella Azure-datorer finns främst i regionen EU, norra, med bara några få i USA, östra och Västra Japan. Contoso använder Microsoft Defender för servrar på alla sina virtuella Azure-datorer.

Contoso räknar med att mata in cirka 300 GB/dag från alla sina datakällor.

Åtkomstkrav för Contoso

Contosos Azure-miljö har redan en enda befintlig Log Analytics-arbetsyta som används av driftteamet för att övervaka infrastrukturen. Den här arbetsytan finns i Contoso Microsoft Entra-klientorganisationen i regionen NORRA EU och används för att samla in loggar från virtuella Azure-datorer i alla regioner. De matar för närvarande in cirka 50 GB/dag.

Contoso Operations-teamet måste ha åtkomst till alla loggar som de för närvarande har på arbetsytan, som innehåller flera datatyper som inte behövs av SOC, till exempel Perf, InsightsMetrics, ContainerLog med mera. Driftteamet får inte ha åtkomst till de nya loggar som samlas in i Microsoft Sentinel.

Contosos lösning

Följande steg tillämpar beslutsträdet för design av Microsoft Sentinel-arbetsytor för att fastställa den bästa arbetsytedesignen för Contoso:

  1. Contoso har redan en befintlig arbetsyta, så vi kan utforska hur du aktiverar Microsoft Sentinel på samma arbetsyta.

    Datainmatning som inte är SOC är mindre än 100 GB/dag, så vi kan fortsätta till steg 2 och se till att välja relevant alternativ i steg 5.

  2. Contoso har regelkrav, så vi behöver minst en Microsoft Sentinel-arbetsyta i Europa.

  3. Contoso har två olika Microsoft Entra-klienter och samlar in från datakällor på klientorganisationsnivå, till exempel Office 365- och Microsoft Entra-inloggnings- och granskningsloggar, så vi behöver minst en arbetsyta per klientorganisation.

  4. Contoso behöver inte återbetalning, så vi kan fortsätta med steg 5.

  5. Contoso behöver samla in icke-SOC-data, även om det inte finns någon överlappning mellan SOC- och icke-SOC-data. SOC-data står också för cirka 250 GB/dag, så de bör använda separata arbetsytor för kostnadseffektivitetens skull.

  6. De flesta av Contosos virtuella datorer är regionen EU, norra, där de redan har en arbetsyta. Därför är bandbreddskostnader i det här fallet inte ett problem.

  7. Contoso har ett enda SOC-team som ska använda Microsoft Sentinel, så ingen extra separation krävs.

  8. Alla medlemmar i Contosos SOC-team kommer att ha åtkomst till alla data, så ingen extra separation krävs.

Den resulterande Microsoft Sentinel-arbetsytedesignen för Contoso illustreras i följande bild:

Diagram of Contoso's solution, with a separate workspace for the Ops team.

Den föreslagna lösningen omfattar:

  • En separat Log Analytics-arbetsyta för Contoso Operations-teamet. Den här arbetsytan innehåller endast data som inte behövs av Contosos SOC-team, till exempel tabellerna Perf, InsightsMetrics eller ContainerLog .

  • Två Microsoft Sentinel-arbetsytor, en i varje Microsoft Entra-klientorganisation, för att mata in data från Office 365, Azure Activity, Microsoft Entra ID och alla Azure PaaS-tjänster.

  • Alla andra data, som kommer från lokala datakällor, kan dirigeras till en av de två Microsoft Sentinel-arbetsytorna.

Exempel 2: Enskild klientorganisation med flera moln

Fabrikam är en organisation med huvudkontor i New York City och kontor runt om i USA. Fabrikam börjar sin molnresa och behöver fortfarande distribuera sin första Azure-landningszon och migrera sina första arbetsbelastningar. Fabrikam har redan vissa arbetsbelastningar på AWS, som de tänker övervaka med hjälp av Microsoft Sentinel.

Fabrikam-innehavarkrav

Fabrikam har en enda Microsoft Entra-klientorganisation.

Fabrikam-efterlevnad och regional distribution

Fabrikam har inga efterlevnadskrav. Fabrikam har resurser i flera Azure-regioner i USA, men bandbreddskostnader mellan regioner är inte något större problem.

Fabrikam-resurstyper och samlingskrav

Fabrikam måste samla in händelser från följande datakällor:

  • Inloggnings- och granskningsloggar för Microsoft Entra
  • Azure-aktivitet
  • Säkerhetshändelser från både lokala och virtuella Azure-källor
  • Windows-händelser från både lokala och virtuella Azure-källor
  • Prestandadata från både lokala och virtuella Azure-datorer
  • AWS CloudTrail
  • AKS-gransknings- och prestandaloggar

Åtkomstkrav för Fabrikam

Fabrikam Operations-teamet måste komma åt:

  • Säkerhetshändelser och Windows-händelser från både lokala och virtuella Azure-datorer
  • Prestandadata från både lokala och virtuella Azure-datorer
  • AKS-prestanda (Container Insights) och granskningsloggar
  • Alla Azure-aktivitetsdata

Fabrikam SOC-teamet måste komma åt:

  • Inloggnings- och granskningsloggar för Microsoft Entra
  • Alla Azure-aktivitetsdata
  • Säkerhetshändelser från både lokala och virtuella Azure-källor
  • AWS CloudTrail-loggar
  • AKS-granskningsloggar
  • Den fullständiga Microsoft Sentinel-portalen

Fabrikams lösning

Följande steg tillämpar beslutsträdet för design av Microsoft Sentinel-arbetsytor för att fastställa den bästa arbetsytedesignen för Fabrikam:

  1. Fabrikam har ingen befintlig arbetsyta, så fortsätt till steg 2.

  2. Fabrikam har inga regelkrav, så fortsätt till steg 3.

  3. Fabrikam har en miljö med en enda klientorganisation. så fortsätt till steg 4.

  4. Fabrikam behöver inte dela upp avgifter, så fortsätt till steg 5.

  5. Fabrikam behöver separata arbetsytor för sina SOC- och driftteam:

    Fabrikam Operations-teamet måste samla in prestandadata från både virtuella datorer och AKS. Eftersom AKS baseras på diagnostikinställningar kan de välja specifika loggar som ska skickas till specifika arbetsytor. Fabrikam kan välja att skicka AKS-granskningsloggar till Microsoft Sentinel-arbetsytan och alla AKS-loggar till en separat arbetsyta, där Microsoft Sentinel inte är aktiverat. På arbetsytan där Microsoft Sentinel inte är aktiverat aktiverar Fabrikam Container Insights-lösningen.

    För virtuella Windows-datorer kan Fabrikam använda Azure Monitoring Agent (AMA) för att dela upp loggarna, skicka säkerhetshändelser till Microsoft Sentinel-arbetsytan samt prestanda och Windows-händelser till arbetsytan utan Microsoft Sentinel.

    Fabrikam väljer att överväga överlappande data, till exempel säkerhetshändelser och Azure-aktivitetshändelser, som endast SOC-data, och skickar dessa data till arbetsytan med Microsoft Sentinel.

  6. Bandbreddskostnader är inte ett stort problem för Fabrikam, så fortsätt med steg 7.

  7. Fabrikam har redan bestämt sig för att använda separata arbetsytor för SOC- och driftteamen. Ingen ytterligare separation krävs.

  8. Fabrikam behöver kontrollera åtkomsten för överlappande data, inklusive säkerhetshändelser och Azure-aktivitetshändelser, men det finns inget krav på radnivå.

    Säkerhetshändelser och Azure-aktivitetshändelser är inte anpassade loggar, så Fabrikam kan använda RBAC på tabellnivå för att bevilja åtkomst till dessa två tabeller för driftteamet.

Den resulterande Microsoft Sentinel-arbetsytedesignen för Fabrikam illustreras i följande bild, inklusive endast nyckelloggkällor för enkelhetens skull:

Diagram of Fabrikam's solution, with a separate workspace for the Ops team.

Den föreslagna lösningen omfattar:

  • Två separata arbetsytor i regionen USA: en för SOC-teamet med Microsoft Sentinel aktiverat och en annan för driftteamet, utan Microsoft Sentinel.

  • Azure Monitoring Agent (AMA) används för att avgöra vilka loggar som skickas till varje arbetsyta från Azure och lokala virtuella datorer.

  • Diagnostikinställningar som används för att avgöra vilka loggar som skickas till varje arbetsyta från Azure-resurser, till exempel AKS.

  • Överlappande data som skickas till Microsoft Sentinel-arbetsytan med RBAC på tabellnivå för att bevilja åtkomst till driftteamet efter behov.

Exempel 3: Flera klienter och regioner och centraliserad säkerhet

Adventure Works är ett multinationellt företag med huvudkontor i Tokyo. Adventure Works har 10 olika underentiteter , baserade i olika länder/regioner runt om i världen.

Adventure Works är Microsoft 365 E5-kund och har redan arbetsbelastningar i Azure.

Krav för Adventure Works-innehav

Adventure Works har tre olika Microsoft Entra-klienter, en för var och en av de kontinenter där de har underentiteter: Asien, Europa och Afrika. De olika underentiteternas länder/regioner har sina identiteter i klientorganisationen för den kontinent som de tillhör. Japanska användare finns till exempel i asienklientorganisationen, tyska användare finns i europaklientorganisationenoch egyptiska användare finns i afrikaklientorganisationen.

Adventure Works efterlevnad och regionala krav

Adventure Works använder för närvarande tre Azure-regioner, var och en i linje med den kontinent där underentiteterna finns. Adventure Works har inte strikta efterlevnadskrav.

Resurstyper och samlingskrav för Adventure Works

Adventure Works måste samla in följande datakällor för varje underentitet:

  • Inloggnings- och granskningsloggar för Microsoft Entra
  • Office 365-loggar
  • Microsoft Defender XDR för endpoint raw-loggar
  • Azure-aktivitet
  • Microsoft Defender for Cloud
  • Azure PaaS-resurser, till exempel från Azure Firewall, Azure Storage, Azure SQL och Azure WAF
  • Säkerhets- och windowshändelser från virtuella Azure-datorer
  • CEF-loggar från lokala nätverksenheter

Virtuella Azure-datorer är spridda över de tre kontinenterna, men bandbreddskostnaderna är inte ett problem.

Åtkomstkrav för Adventure Works

Adventure Works har ett enda, centraliserat SOC-team som övervakar säkerhetsåtgärder för alla olika underentiteter.

Adventure Works har också tre oberoende SOC-team, ett för var och en av kontinenterna. Varje kontinents SOC-team bör endast kunna komma åt de data som genereras i regionen, utan att se data från andra kontinenter. Till exempel bör Asia SOC-teamet endast komma åt data från Azure-resurser som distribuerats i Asien, Microsoft Entra-inloggningar från Asien-klientorganisationen och Defender för Endpoint-loggar från den är Asien-klientorganisationen.

Varje kontinents SOC-team måste få åtkomst till hela Microsoft Sentinel-portalen.

Adventure Works driftteam körs oberoende av varandra och har egna arbetsytor utan Microsoft Sentinel.

Adventure Works-lösning

Följande steg använder designbeslutsträdet för Microsoft Sentinel-arbetsytor för att fastställa den bästa arbetsytedesignen för Adventure Works:

  1. Adventure Works driftteam har egna arbetsytor, så fortsätt till steg 2.

  2. Adventure Works har inga regelkrav, så fortsätt till steg 3.

  3. Adventure Works har tre Microsoft Entra-klienter och måste samla in datakällor på klientnivå, till exempel Office 365-loggar. Därför bör Adventure Works skapa minst Microsoft Sentinel-arbetsytor, en för varje klientorganisation.

  4. Adventure Works behöver inte dela upp avgifter, så fortsätt till steg 5.

  5. Eftersom Adventure Works driftteam har egna arbetsytor kommer alla data som beaktas i det här beslutet att användas av Adventure Works SOC-teamet.

  6. Bandbreddskostnader är inte ett stort problem för Adventure Works, så fortsätt med steg 7.

  7. Adventure Works behöver separera data efter ägarskap, eftersom varje innehålls SOC-team bara behöver komma åt data som är relevanta för innehållet. Men varje kontinents SOC-team behöver också åtkomst till den fullständiga Microsoft Sentinel-portalen.

  8. Adventure Works behöver inte styra dataåtkomsten per tabell.

Den resulterande Microsoft Sentinel-arbetsytedesignen för Adventure Works illustreras i följande bild, inklusive endast nyckelloggkällor för enkelhetens skull:

Diagram of Adventure Works's solution, with separate workspaces for each Azure AD tenant.

Den föreslagna lösningen omfattar:

  • En separat Microsoft Sentinel-arbetsyta för varje Microsoft Entra-klientorganisation. Varje arbetsyta samlar in data som är relaterade till klientorganisationen för alla datakällor.

  • Varje kontinents SOC-team har endast åtkomst till arbetsytan i sin egen klientorganisation, vilket säkerställer att endast loggar som genereras inom klientgränsen är tillgängliga för varje SOC-team.

  • Det centrala SOC-teamet kan fortfarande arbeta från en separat Microsoft Entra-klientorganisation med hjälp av Azure Lighthouse för att få åtkomst till var och en av de olika Microsoft Sentinel-miljöerna. Om det inte finns någon annan klientorganisation kan det centrala SOC-teamet fortfarande använda Azure Lighthouse för att komma åt fjärrarbetsytorna.

  • Det centrala SOC-teamet kan också skapa en annan arbetsyta om det behöver lagra artefakter som förblir dolda från SOC-teamen på kontinenten, eller om de vill mata in andra data som inte är relevanta för SOC-teamen på kontinenten.

Nästa steg

I den här artikeln har du granskat en uppsättning föreslagna arbetsytedesigner för organisationer.