Best practices voor microsoft Sentinel-werkruimtearchitectuur

Wanneer u de implementatie van uw Microsoft Sentinel-werkruimte plant, moet u ook uw Log Analytics-werkruimtearchitectuur ontwerpen. Beslissingen over de werkruimtearchitectuur worden doorgaans aangestuurd door zakelijke en technische vereisten. In dit artikel worden de belangrijkste beslissingsfactoren beschreven om u te helpen de juiste werkruimtearchitectuur voor uw organisaties te bepalen, waaronder:

• Of u nu één of meerdere tenants wilt gebruiken
• Alle nalevingsvereisten die u hebt voor het verzamelen en opslaan van gegevens
• Toegang tot Microsoft Sentinel-gegevens controleren
• Gevolgen voor de kosten voor verschillende scenario's

Zie Ontwerp uw Microsoft Sentinel-werkruimtearchitectuur en Voorbeeldwerkruimteontwerpen voor algemene scenario's en Activiteiten vóór implementatie en vereisten voor het implementeren van Microsoft Sentinel voor meer informatie.

Zie onze video: Architecting SecOps for Success: Best Practices for Deploying Microsoft Sentinel

Tenancyoverwegingen

Hoewel minder werkruimten eenvoudiger te beheren zijn, hebt u mogelijk specifieke behoeften voor meerdere tenants en werkruimten. Veel organisaties hebben bijvoorbeeld een cloudomgeving die meerdere Azure Active Directory-tenants (Azure AD)bevat die het gevolg zijn van fusies en overnames of vanwege vereisten voor identiteitsscheiding.

Wanneer u bepaalt hoeveel tenants en werkruimten moeten worden gebruikt, moet u er rekening mee houden dat de meeste Microsoft Sentinel-functies werken met behulp van één werkruimte of Microsoft Sentinel-exemplaar, en dat Microsoft Sentinel alle logboeken opeengenomen die in de werkruimte zijn opgeslagen.

Werken met meerdere tenants

Als u meerdere tenants hebt, bijvoorbeeld als u een beheerde MSSP (Security Service Provider) bent, wordt u aangeraden ten minste één werkruimte voor elke Azure AD-tenant te maken ter ondersteuning van ingebouwde service-naar-servicegegevensconnectoren die alleen binnen hun eigen Azure AD-tenant werken.

Alle connectors op basis van diagnostische instellingen kunnen niet worden verbonden met een werkruimte die zich niet in dezelfde tenant bevindt waarin de resource zich bevindt. Dit geldt voor connectors zoals Azure Firewall, Azure Storage, Azure Activity of Azure Active Directory.

Gebruik Azure Lighthouse om meerdere Microsoft Sentinel-exemplaren in verschillende tenants te beheren.

Nalevingsoverwegingen

Nadat uw gegevens zijn verzameld, opgeslagen en verwerkt, kan naleving een belangrijke ontwerpvereiste worden, met een aanzienlijke invloed op uw Microsoft Sentinel-architectuur. De mogelijkheid om te valideren en te bewijzen wie toegang heeft tot welke gegevens onder alle omstandigheden een essentiële gegevenssoevereiniteitsvereiste is in veel landen en regio's, en het beoordelen van risico's en het verkrijgen van inzichten in Microsoft Sentinel-werkstromen is een prioriteit voor veel klanten.

In Microsoft Sentinel worden gegevens voornamelijk opgeslagen en verwerkt in dezelfde geografie of regio, met enkele uitzonderingen, zoals bij het gebruik van detectieregels die gebruikmaken van machine learning van Microsoft. In dergelijke gevallen kunnen gegevens worden gekopieerd buiten de geografie van uw werkruimte voor verwerking.

Zie voor meer informatie:

• Geografische beschikbaarheid en gegevenslocatie
• Gegevensstatus in Azure
• De EU-gegevens opslaan en verwerken in de blog EU - EU-beleid

Als u wilt beginnen met het valideren van uw naleving, evalueert u uw gegevensbronnen en hoe en waar ze gegevens verzenden.

Overwegingen voor regio's

Gebruik afzonderlijke Microsoft Sentinel-exemplaren voor elke regio. Hoewel Microsoft Sentinel kan worden gebruikt in meerdere regio's, hebt u mogelijk vereisten om gegevens te scheiden per team, regio of site, of regelgeving en controles die modellen voor meerdere regio's onmogelijk of complexer maken dan nodig is. Door afzonderlijke exemplaren en werkruimten voor elke regio te gebruiken, voorkomt u bandbreedte-/egress-kosten voor het verplaatsen van gegevens tussen regio's.

Houd rekening met het volgende wanneer u met meerdere regio's werkt:

• Egress zijn doorgaans van toepassing wanneer de Log Analytics- of Azure Monitor-agent vereist is voor het verzamelen van logboeken, zoals op virtuele machines.

• Er worden ook kosten in rekening gebracht voor internetuitvoer, wat mogelijk niet van invloed is op u, tenzij u gegevens buiten uw Log Analytics-werkruimte exporteert. Er kunnen bijvoorbeeld kosten voor internetuitvoer in rekening worden gebracht als u uw Log Analytics-gegevens exporteert naar een on-premises server.

• De bandbreedtekosten variëren afhankelijk van de bron- en doelregio en verzamelingsmethode. Zie voor meer informatie:

  • Bandbreedteprijzen
  • Kosten voor gegevensoverdrachten met behulp van Log Analytics .

• Gebruik sjablonen voor uw analyseregels, aangepaste query's, werkmappen en andere resources om uw implementaties efficiënter te maken. Implementeer de sjablonen in plaats van elke resource in elke regio handmatig te implementeren.

• Connectors die zijn gebaseerd op diagnostische instellingen, brengen geen kosten in rekening voor bandbreedte. Zie Gebruik en kosten beheren met Azure Monitor logboeken voor meer informatie.

Als u bijvoorbeeld besluit logboeken te verzamelen van Virtual Machines in VS - oost en ze naar een Microsoft Sentinel-werkruimte in VS - west te verzenden, worden er kosten in rekening gebracht voor de gegevensoverdracht. Omdat de Log Analytics-agent de gegevens tijdens de overdracht comprimeert, is de bandbreedte mogelijk kleiner dan de grootte van de logboeken in Microsoft Sentinel.

Als u Syslog- en CEF-logboeken verzamelt van meerdere bronnen over de hele wereld, kunt u een Syslog-collector instellen in dezelfde regio als uw Microsoft Sentinel-werkruimte om bandbreedtekosten te voorkomen, mits naleving geen probleem is.

Begrijpen of bandbreedtekosten afzonderlijke Microsoft Sentinel-werkruimten rechtvaardigen, is afhankelijk van de hoeveelheid gegevens die u tussen regio's moet overdragen. Gebruik de Azure-prijscalculator om uw kosten te schatten.

Zie Gegevensstatus in Azure voor meer informatie.

Overwegingen bij toegang

Mogelijk zijn er situaties gepland waarin verschillende teams toegang tot dezelfde gegevens nodig hebben. Uw SOC-team moet bijvoorbeeld toegang hebben tot alle Microsoft Sentinel-gegevens, terwijl operations- en toepassingsteams alleen toegang nodig hebben tot specifieke onderdelen. Onafhankelijke beveiligingsteams hebben mogelijk ook toegang nodig tot Microsoft Sentinel-functies, maar met verschillende gegevenssets.

Combineer resourcecontext RBAC en RBAC op tabelniveau om uw teams een breed scala aan toegangsopties te bieden die de meeste gebruiksgevallen moeten ondersteunen.

Zie Machtigingen in Microsoft Sentinel voor meer informatie.

RBAC voor resourcecontext

In de volgende afbeelding ziet u een vereenvoudigde versie van een werkruimtearchitectuur waarin beveiligings- en operationele teams toegang nodig hebben tot verschillende gegevenssets en resourcecontext RBAC wordt gebruikt om de vereiste machtigingen te bieden.

In deze afbeelding wordt de Microsoft Sentinel-werkruimte in een afzonderlijk abonnement geplaatst om machtigingen beter te isoleren.

Naast het beveiligingsabonnement wordt er een afzonderlijk abonnement gebruikt voor de toepassingsteams om hun workloads te hosten. De toepassingsteams krijgen toegang tot hun respectieve resourcegroepen, waar ze hun resources kunnen beheren. Met dit afzonderlijke abonnement en RBAC voor resourcecontext kunnen deze teams logboeken weergeven die zijn gegenereerd door resources waar ze toegang tot hebben, zelfs wanneer de logboeken worden opgeslagen in een werkruimte waar ze geen directe toegang hebben. De toepassingsteams hebben toegang tot hun logboeken via het gebied Logboeken van de Azure Portal, om logboeken weer te geven voor een specifieke resource of via Azure Monitor, om alle logboeken weer te geven die ze op hetzelfde moment kunnen openen.

Azure-resources hebben ingebouwde ondersteuning voor RBAC voor resourcecontext, maar vereisen mogelijk extra afstemming wanneer u werkt met niet-Azure-resources. Zie RBAC voor resourcecontext expliciet configureren voor meer informatie.

RBAC op tabelniveau

Met RBAC op tabelniveau kunt u specifieke gegevenstypen (tabellen) definiëren die alleen toegankelijk zijn voor een opgegeven set gebruikers.

Overweeg bijvoorbeeld of de organisatie waarvan de architectuur wordt beschreven in de bovenstaande afbeelding ook toegang moet verlenen tot Office 365 logboeken aan een intern auditteam. In dit geval kunnen ze RBAC op tabelniveau gebruiken om het auditteam toegang te verlenen tot de hele tabel OfficeActivity, zonder machtigingen te verlenen aan een andere tabel.

Overwegingen voor toegang met meerdere werkruimten

Als u binnen uw organisatie verschillende entiteiten, dochterondernemingen of geografieën hebt, elk met hun eigen beveiligingsteams die toegang nodig hebben tot Microsoft Sentinel, gebruikt u afzonderlijke werkruimten voor elke entiteit of dochteronderneming. Implementeert de afzonderlijke werkruimten binnen één Azure AD-tenant of in meerdere tenants met behulp van Azure Lighthouse.

Uw centrale SOC-team kan ook een extra, optionele Microsoft Sentinel-werkruimte gebruiken voor het beheren van gecentraliseerde artefacten, zoals analyseregels of werkmappen.

Zie Werken met meerdere werkruimten vereenvoudigen voor meer informatie.

Technische best practices voor het maken van uw werkruimte

Gebruik de volgende best practice bij het maken van de Log Analytics-werkruimte die u voor Microsoft Sentinel gaat gebruiken:

• Wanneer u uw werkruimte een naam geeft, moet u Microsoft Sentinel of een andere indicator in de naam opnemen, zodat deze gemakkelijk kan worden geïdentificeerd in uw andere werkruimten.

• Gebruik dezelfde werkruimte voor zowel Microsoft Sentinel als Microsoft Defender for Cloud, zodat alle logboeken die door Microsoft Defender for Cloud worden verzameld, ook kunnen worden opgenomen en gebruikt door Microsoft Sentinel. De standaardwerkruimte die door Microsoft Defender for Cloud is gemaakt, wordt niet weergegeven als een beschikbare werkruimte voor Microsoft Sentinel.

• Gebruik een toegewezen werkruimtecluster als uw verwachte gegevensingestie ongeveer 1 TB per dag is. Met een toegewezen cluster kunt u resources beveiligen voor uw Microsoft Sentinel-gegevens, waardoor betere queryprestaties voor grote gegevenssets mogelijk zijn. Toegewezen clusters bieden ook de mogelijkheid voor meer versleuteling en controle over de sleutels van uw organisatie.

Het werken met meerdere werkruimten vereenvoudigen

Als u met meerdere werkruimten moet werken, vereenvoudigt u uw incidentbeheer en -onderzoek door alle incidenten van elk Microsoft Sentinel-exemplaar op één locatie samen te stellen en weer te geven.

Als u wilt verwijzen naar gegevens die zijn opgevraagd in andere Microsoft Sentinel-werkruimten,zoals in werkmappen tussen werkruimten, gebruikt u query's tussen werkruimten.

Het beste moment om query's voor meerdere werkruimten te gebruiken, is wanneer waardevolle informatie wordt opgeslagen in een andere werkruimte, abonnement of tenant en waarde kan bieden aan uw huidige actie. In de volgende code ziet u bijvoorbeeld een voorbeeldquery voor een werkruimte:

union Update, workspace("contosoretail-it").Update, workspace("WORKSPACE ID").Update
| where TimeGenerated >= ago(1h)
| where UpdateState == "Needed"
| summarize dcount(Computer) by Classification

Zie Microsoft Sentinel uitbreiden naar werkruimten en tenants voor meer informatie.

Volgende stappen