De architectuur van uw Microsoft Sentinel-werkruimte ontwerpen

Dit artikel bevat een beslissingsstructuur om u te helpen belangrijke beslissingen te nemen over het ontwerpen van uw Microsoft Sentinel-werkruimtearchitectuur. Zie de best practices voor microsoft Sentinel-voorbeeldwerkruimten en best practices voor de architectuur van Microsoft Sentinel-werkruimten voor meer informatie. Dit artikel maakt deel uit van de implementatiehandleiding voor Microsoft Sentinel.

Vereisten

Voordat u de beslissingsstructuur doorloopt, moet u ervoor zorgen dat u over de volgende informatie beschikt:

Vereiste	Beschrijving
Wettelijke vereisten met betrekking tot Azure-gegevenslocatie	Microsoft Sentinel kan in de meeste werkruimten worden uitgevoerd, maar niet in alle regio's die worden ondersteund in GA voor Log Analytics. Het kan enige tijd duren voordat nieuw ondersteunde Log Analytics-regio's de Microsoft Sentinel-service onboarden. Gegevens die worden gegenereerd door Microsoft Sentinel, zoals incidenten, bladwijzers en analyseregels, bevatten mogelijk enkele klantgegevens die afkomstig zijn uit de Log Analytics-werkruimten van de klant. Zie Geografische beschikbaarheid en gegevenslocatie voor meer informatie.
Gegevensbronnen	Ontdek welke gegevensbronnen u nodig hebt om verbinding te maken, inclusief ingebouwde connectors voor zowel Microsoft- als niet-Microsoft-oplossingen. U kunt ook Common Event Format (CEF), Syslog of REST-API gebruiken om uw gegevensbronnen te verbinden met Microsoft Sentinel. Als u Azure-VM's op meerdere Azure-locaties hebt waaruit u de logboeken moet verzamelen en de kosten voor uitgaand gegevensverkeer moet besparen, moet u de kosten voor uitgaand gegevens berekenen met behulp van de prijscalculator Bandbreedte voor elke Azure-locatie.
Gebruikersrollen en toegangsniveaus voor gegevens/machtigingen	Microsoft Sentinel maakt gebruik van op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) om ingebouwde rollen te bieden die kunnen worden toegewezen aan gebruikers, groepen en services in Azure. Alle ingebouwde Microsoft Sentinel-rollen verlenen leestoegang tot de gegevens in uw Microsoft Sentinel-werkruimte. Daarom moet u erachter komen of er behoefte is aan het beheren van gegevenstoegang per gegevensbron of rijniveau, omdat dit van invloed is op de ontwerpbeslissing van de werkruimte. Zie Aangepaste rollen en geavanceerde Azure RBAC voor meer informatie.
Dagelijkse opnamesnelheid	De dagelijkse opnamesnelheid, meestal in GB/dag, is een van de belangrijkste factoren in kostenbeheer en planningsoverwegingen en werkruimteontwerp voor Microsoft Sentinel. In de meeste cloud- en hybride omgevingen produceren netwerkapparaten, zoals firewalls of proxy's, en Windows- en Linux-servers de meest opgenomen gegevens. Om de meest nauwkeurige resultaten te verkrijgen, raadt Microsoft een uitgebreide inventarisatie van gegevensbronnen aan. De kostencalculator van Microsoft Sentinel bevat ook tabellen die handig zijn bij het schatten van footprints van gegevensbronnen. Belangrijk: Deze schattingen zijn een uitgangspunt en de instellingen voor de uitgebreidheid van logboeken en de workload produceren afwijkingen. U wordt aangeraden uw systeem regelmatig te controleren om wijzigingen bij te houden. Regelmatige bewaking wordt aanbevolen op basis van uw scenario. Zie prijsinformatie over Azure Monitor Logs voor meer informatie.

Beslissingsstructuur

In de volgende afbeelding ziet u een volledig beslissingsstructuurdiagram, zodat u begrijpt hoe u uw werkruimte het beste kunt ontwerpen.

De volgende secties bevatten een volledige tekstversie van deze beslissingsstructuur, inclusief de volgende opmerkingen waarnaar wordt verwezen vanuit de afbeelding:

Opmerking #1 | Opmerking #2 | Opmerking #3 | Opmerking #4 | Opmerking #5 | Opmerking #6 | Opmerking #7 | Opmerking #8 | Opmerking #9 | Notitie #10

Stap 1: Nieuwe of bestaande werkruimte?

Hebt u een bestaande werkruimte die u kunt gebruiken voor Microsoft Sentinel?

• Als dat niet het geval is en u in elk geval een nieuwe werkruimte maakt, gaat u rechtstreeks verder met stap 2.

• Als u een bestaande werkruimte hebt die u kunt gebruiken, kunt u overwegen hoeveel gegevens u wilt opnemen.

  • Als u meer dan 100 GB per dag opneemt, wordt u aangeraden een afzonderlijke werkruimte te gebruiken voor kostenefficiëntie.

  • Als u minder dan 100 GB per dag opneemt, gaat u verder met stap 2 voor verdere evaluatie. Houd deze vraag opnieuw in overweging wanneer deze zich voordoet in stap 5.

Stap 2: Gegevens in verschillende Azure-geografische gebieden bewaren?

• Als u wettelijke vereisten hebt om gegevens in verschillende Azure-regio's te bewaren, gebruikt u een afzonderlijke Microsoft Sentinel-werkruimte voor elke Azure-regio met nalevingsvereisten. Zie Regiooverwegingen voor meer informatie.

• Als u geen gegevens in verschillende Azure-geografische gebieden hoeft te bewaren, gaat u verder met stap 3.

Stap 3: Hebt u meerdere Azure-tenants?

• Als u slechts één tenant hebt, gaat u rechtstreeks verder met stap 4.

• Als u meerdere Azure-tenants hebt, kunt u overwegen of u logboeken verzamelt die specifiek zijn voor een tenantgrens, zoals Office 365 of Microsoft Defender XDR.

  • Als u geen tenantspecifieke logboeken hebt, gaat u rechtstreeks verder met stap 4.

  • Als u tenantspecifieke logboeken verzamelt, gebruikt u een afzonderlijke Microsoft Sentinel-werkruimte voor elke Microsoft Entra-tenant. Ga verder met stap 4 voor andere overwegingen.

    Opmerking voor beslissingsstructuur #1: Logboeken die specifiek zijn voor tenantgrenzen, zoals van Office 365 en Microsoft Defender voor Cloud, kunnen alleen worden opgeslagen in de werkruimte binnen dezelfde tenant.

    Hoewel het mogelijk is om aangepaste collectors te gebruiken om tenantspecifieke logboeken van een werkruimte in een andere tenant te verzamelen, raden we dit niet aan vanwege de volgende nadelen:

    • Gegevens die door aangepaste connectors worden verzameld, worden opgenomen in aangepaste tabellen. Daarom kunt u niet alle ingebouwde regels en werkmappen gebruiken.
    • Aangepaste tabellen worden niet beschouwd door een aantal ingebouwde functies, zoals UEBA en machine learning-regels.
    • Extra kosten en moeite die nodig zijn voor de aangepaste connectors, zoals het gebruik van Azure Functions en Logic Apps.

    Als deze nadelen geen probleem zijn voor uw organisatie, gaat u verder met stap 4 in plaats van afzonderlijke Microsoft Sentinel-werkruimten te gebruiken.

Stap 4: Facturering/kosten splitsen?

Als u uw facturering of kosten wilt splitsen, kunt u overwegen of de gebruiksrapportage of handmatige kruiskosten voor u werken.

• Als u uw facturering of kosten niet hoeft te splitsen, gaat u verder met stap 5.

• Als u uw facturering of kosten wilt splitsen, kunt u overwegen om handmatige kruiskosten te gebruiken. Als u nauwkeurige kosten per entiteit wilt ophalen, kunt u een gewijzigde versie van de Microsoft Sentinel Cost-werkmap gebruiken die de kosten per entiteit opsplitst.

  • Als gebruiksrapportage of handmatige kruislingse kosten voor u werken, gaat u verder met stap 5.

  • Als geen van beide gebruiksrapportages of handmatige kruislingse kosten voor u werkt, gebruikt u een afzonderlijke Microsoft Sentinel-werkruimte voor elke kosteneigenaar.

  Opmerking van beslissingsstructuur #2: Zie Microsoft Sentinel-kosten en -facturering voor meer informatie.

Stap 5: Eventuele niet-SOC-gegevens verzamelen?

• Als u geen niet-SOC-gegevens verzamelt, zoals operationele gegevens, kunt u direct doorgaan naar stap 6.

• Als u niet-SOC-gegevens verzamelt, kunt u overwegen of er overlappingen zijn, waarbij dezelfde gegevensbron vereist is voor zowel SOC- als niet-SOC-gegevens.

  Als u wel overlapt tussen SOC- en niet-SOC-gegevens, behandelt u de overlappende gegevens alleen als SOC-gegevens. Overweeg vervolgens of de opname voor zowel SOC- als niet-SOC-gegevens afzonderlijk kleiner is dan 100 GB per dag, maar meer dan 100 GB per dag wanneer deze worden gecombineerd:

  • Ja: Ga verder met stap 6 voor verdere evaluatie.
  • Nee: We raden u niet aan om dezelfde werkruimte te gebruiken omwille van kostenefficiëntie. Ga verder met stap 6 voor verdere evaluatie.

  Zie 10 voor meer informatie.

  Als u geen overlappende gegevens hebt, kunt u overwegen of de opname voor zowel SOC- als niet-SOC-gegevens afzonderlijk kleiner is dan 100 GB per dag, maar meer dan 100 GB per dag wanneer deze worden gecombineerd:

  • Ja: Ga verder met stap 6 voor verdere evaluatie. Zie opmerking 3 voor meer informatie.
  • Nee: We raden u niet aan om dezelfde werkruimte te gebruiken omwille van kostenefficiëntie. Ga verder met stap 6 voor verdere evaluatie.

Uw SOC- en niet-SOC-gegevens combineren

Beslissingsstructuurnotitie #3: Hoewel we in het algemeen aanbevelen dat klanten een afzonderlijke werkruimte voor hun niet-SOC-gegevens behouden, zodat niet-SOC-gegevens niet onderhevig zijn aan de kosten van Microsoft Sentinel, kunnen er situaties zijn waarin het combineren van SOC- en niet-SOC-gegevens goedkoper is dan het scheiden ervan.

Denk bijvoorbeeld aan een organisatie met beveiligingslogboeken die worden opgenomen op 50 GB/dag, bewerkingslogboeken die worden opgenomen op 50 GB/dag en een werkruimte in de regio VS - oost.

In de volgende tabel worden werkruimteopties vergeleken met en zonder afzonderlijke werkruimten.

Notitie

Kosten en termen die in de volgende tabel worden vermeld, zijn nep en worden alleen gebruikt voor illustratieve doeleinden. Zie de prijscalculator van Microsoft Sentinel voor actuele kosten.

Werkruimtearchitectuur	Beschrijving
Het SOC-team heeft een eigen werkruimte, waarbij Microsoft Sentinel is ingeschakeld. Het Ops-team heeft een eigen werkruimte, zonder Dat Microsoft Sentinel is ingeschakeld.	SOC-team: De kosten van Microsoft Sentinel voor 50 GB/dag bedragen $ 6500 per maand. De eerste drie maanden retentie zijn gratis. Ops-team: - De kosten van Log Analytics op 50 GB/dag bedragen ongeveer $ 3500 per maand. - De eerste 31 dagen retentie zijn gratis. De totale kosten voor beide bedragen gelijk aan $ 10.000 per maand.
Zowel SOC- als Ops-teams delen dezelfde werkruimte met Microsoft Sentinel ingeschakeld.	Door beide logboeken te combineren, is opname 100 GB per dag, in aanmerking komen voor geschiktheid voor de toezeggingslaag (50% voor Sentinel en 15% voor LA). De kosten van Microsoft Sentinel voor 100 GB per dag zijn $ 9.000 per maand.

In dit voorbeeld hebt u een kostenbesparing van $ 1.000 per maand door beide werkruimten te combineren, en het Ops-team heeft ook 3 maanden gratis retentie in plaats van slechts 31 dagen.

Dit voorbeeld is alleen relevant wanneer zowel SOC- als niet-SOC-gegevens elk een opnamegrootte hebben van >=50 GB/dag en <100 GB/dag.

Opmerking voor beslissingsstructuur #10: Het is raadzaam om een afzonderlijke werkruimte te gebruiken voor niet-SOC-gegevens, zodat niet-SOC-gegevens niet worden onderworpen aan de kosten van Microsoft Sentinel.

Deze aanbeveling voor afzonderlijke werkruimten voor niet-SOC-gegevens is echter afkomstig van een puur kostenperspectief en er zijn andere belangrijke ontwerpfactoren die moeten worden onderzocht bij het bepalen of één of meerdere werkruimten moeten worden gebruikt. Om dubbele opnamekosten te voorkomen, kunt u overwegen om overlappende gegevens in één werkruimte alleen te verzamelen met Azure RBAC op tabelniveau.

Stap 6: Meerdere regio's?

• Als u alleen logboeken van Azure-VM's in één regio verzamelt, gaat u rechtstreeks verder met stap 7.

• Als u logboeken verzamelt van Azure-VM's in meerdere regio's, hoe maakt u zich zorgen over de kosten voor uitgaand gegevensverkeer?

  Opmerking van beslissingsstructuur #4: Uitgaand gegevensverkeer verwijst naar de bandbreedtekosten voor het verplaatsen van gegevens uit Azure-datacenters. Zie Regiooverwegingen voor meer informatie.

  • Als het verminderen van de hoeveelheid werk die nodig is voor het onderhouden van afzonderlijke werkruimten een prioriteit is, gaat u verder met stap 7.

  • Als de kosten voor uitgaand gegevens voldoende zijn om het onderhouden van afzonderlijke werkruimten de moeite waard te maken, gebruikt u een afzonderlijke Microsoft Sentinel-werkruimte voor elke regio waar u de kosten voor uitgaand gegevens moet verlagen.

    Opmerking van beslissingsstructuur #5: U wordt aangeraden zo weinig mogelijk werkruimten te hebben. Gebruik de Azure-prijscalculator om de kosten te schatten en te bepalen welke regio's u daadwerkelijk nodig hebt en werkruimten te combineren voor regio's met lage kosten voor uitgaand verkeer. Bandbreedtekosten zijn mogelijk slechts een klein deel van uw Azure-factuur in vergelijking met afzonderlijke microsoft Sentinel- en Log Analytics-opnamekosten.

    Uw kosten kunnen bijvoorbeeld als volgt worden geschat:

    • 1000 VM's, die elk 1 GB per dag genereren;
    • Gegevens verzenden vanuit een Amerikaanse regio naar een EU-regio;
    • Een compressiesnelheid van 2:1 gebruiken in de agent

    De berekening voor deze geschatte kosten is: 1000 VMs * (1GB/day ÷ 2) * 30 days/month * $0.05/GB = $750/month bandwidth cost

    Deze voorbeeldkosten zijn veel goedkoper in vergelijking met de maandelijkse kosten van een afzonderlijke Microsoft Sentinel- en Log Analytics-werkruimte.

    Notitie

    Vermelde kosten zijn nep en worden alleen gebruikt voor illustratieve doeleinden. Zie de prijscalculator van Microsoft Sentinel voor actuele kosten.

Stap 7: Gegevens scheiden of grenzen definiëren door eigendom?

• Als u geen gegevens hoeft te scheiden of eigendomsgrenzen hoeft te definiëren, gaat u rechtstreeks verder met stap 8.

• Als u gegevens moet scheiden of grenzen moet definiëren op basis van eigendom, moet elke gegevenseigenaar de Microsoft Sentinel-portal gebruiken?

  • Als elke gegevenseigenaar toegang moet hebben tot de Microsoft Sentinel-portal, gebruikt u een afzonderlijke Microsoft Sentinel-werkruimte voor elke eigenaar.

    Opmerking voor beslissingsstructuur #6: Toegang tot de Microsoft Sentinel-portal vereist dat elke gebruiker een rol heeft van ten minste een Microsoft Sentinel-lezer, met leesmachtigingen voor alle tabellen in de werkruimte. Als een gebruiker geen toegang heeft tot alle tabellen in de werkruimte, moet hij of zij Log Analytics gebruiken voor toegang tot de logboeken in zoekquery's.

  • Als toegang tot de logboeken via Log Analytics voldoende is voor eigenaren zonder toegang tot de Microsoft Sentinel-portal, gaat u verder met stap 8.

  Zie Machtigingen in Microsoft Sentinel voor meer informatie.

Stap 8: De toegang tot gegevens per gegevensbron/tabel beheren?

• Als u de toegang tot gegevens niet per bron of tabel hoeft te beheren, gebruikt u één Microsoft Sentinel-werkruimte.

• Als u de gegevenstoegang per bron of tabel wilt beheren, kunt u overwegen om RBAC voor resourcecontext te gebruiken in de volgende situaties:

  • Als u de toegang op rijniveau wilt beheren, zoals het verstrekken van meerdere eigenaren voor elke gegevensbron of tabel

  • Als u meerdere, aangepaste gegevensbronnen/tabellen hebt, waarbij elke gegevensbron afzonderlijke machtigingen nodig heeft

  In andere gevallen moet u, wanneer u de toegang op rijniveau niet hoeft te beheren, meerdere aangepaste gegevensbronnen/tabellen met afzonderlijke machtigingen opgeven, één Microsoft Sentinel-werkruimte gebruiken met RBAC op tabelniveau voor toegangsbeheer voor gegevens.

Overwegingen voor resourcecontext of RBAC op tabelniveau

Wanneer u van plan bent om RBAC op resourcecontext of tabelniveau te gebruiken, moet u rekening houden met de volgende informatie:

• Opmerking voor beslissingsstructuur #7: Als u RBAC voor resourcecontext wilt configureren voor niet-Azure-resources, kunt u een resource-id aan de gegevens koppelen wanneer u naar Microsoft Sentinel verzendt, zodat de machtiging kan worden beperkt met behulp van RBAC voor resourcecontext. Zie De resourcecontext-RBAC - en toegangsmodi expliciet configureren per implementatie voor meer informatie.

• Opmerking van beslissingsstructuur #8: Met resourcemachtigingen of resourcecontext kunnen gebruikers alleen logboeken weergeven voor resources waartoe ze toegang hebben. De toegangsmodus voor werkruimten moet zijn ingesteld op gebruikersresource- of werkruimtemachtigingen. Alleen tabellen die relevant zijn voor de resources waar de gebruiker machtigingen heeft, worden opgenomen in de zoekresultaten van de pagina Logboeken in Microsoft Sentinel.

• Opmerking in beslissingsstructuur #9: met RBAC op tabelniveau kunt u naast de andere machtigingen gedetailleerdere controle definiëren voor gegevens in een Log Analytics-werkruimte. Met dit besturingselement kunt u specifieke gegevenstypen definiëren die alleen toegankelijk zijn voor een specifieke set gebruikers. Zie RBAC op tabelniveau in Microsoft Sentinel voor meer informatie.

Volgende stappen

In dit artikel hebt u een beslissingsstructuur bekeken om belangrijke beslissingen te nemen over het ontwerpen van uw Microsoft Sentinel-werkruimtearchitectuur.

Voorbeeldontwerpen van Microsoft Sentinel-werkruimte