Toegang tot Microsoft Sentinel gegevens beheren per resource

De toegang tot een werkruimte wordt beheerd met behulp van Azure RBAC. Gebruikers die toegang hebben tot een Log Analytics-werkruimte die is ingeschakeld voor Microsoft Sentinel, hebben doorgaans ook toegang tot alle werkruimtegegevens, inclusief beveiligingsinhoud. Beheerders kunnen Azure rollen gebruiken om toegang tot specifieke functies in Microsoft Sentinel te configureren, afhankelijk van de toegangsvereisten in hun team.

Het is echter mogelijk dat sommige gebruikers alleen toegang nodig hebben tot specifieke gegevens in uw werkruimte, maar die geen toegang moeten hebben tot de hele Microsoft Sentinel omgeving. U kunt bijvoorbeeld een niet-beveiligingsteam (niet-SOC) toegang geven tot de Windows-gebeurtenisgegevens voor de servers waarvan ze eigenaar zijn.

Voor gebruikers die alleen toegang nodig hebben tot specifieke gegevens in de werkruimte, raden wij aan om uw rolgebaseerde toegangscontrole (RBAC) te configureren op basis van de middelen die aan die gebruikers zijn toegestaan, in plaats van hen toegang te geven tot de werkruimte of specifieke Microsoft Sentinel-functies. Deze methode staat ook bekend als het instellen van RBAC voor resourcecontext.

Wanneer gebruikers toegang hebben tot Microsoft Sentinel gegevens via de resources die ze kunnen openen in plaats van de werkruimte, kunnen ze logboeken en werkmappen bekijken met behulp van de volgende methoden:

Via de resource zelf, zoals een Azure virtuele machine. Gebruik deze methode om alleen logboeken en werkmappen voor een specifieke resource weer te geven.
Via Azure Monitor. Gebruik deze methode als u query's wilt maken die meerdere resources en/of resourcegroepen omvatten. Wanneer u navigeert naar logboeken en werkmappen in Azure Monitor, definieert u uw bereik voor een of meer specifieke resourcegroepen of resources.

Schakel RBAC met resourcecontext in Azure Monitor in. Zie Toegang tot logboekgegevens en werkruimten beheren in Azure Monitor voor meer informatie.

Opmerking

Als uw gegevens geen Azure resource zijn, zoals Syslog, CEF of Microsoft Entra ID, of gegevens die zijn verzameld door een aangepaste verzamelaar, moet u de resource-id die wordt gebruikt om de gegevens te identificeren en toegang in te schakelen, handmatig configureren. Zie Expliciet resourcecontext-RBAC configureren voor niet-Azure resources voor meer informatie.

Bovendien worden functies en opgeslagen zoekopdrachten niet ondersteund in resourcegerichte contexten. Daarom worden Microsoft Sentinel functies zoals parseren en normaliseren niet ondersteund voor resourcecontext-RBAC in Microsoft Sentinel.

Scenario’s voor RBAC in resourcecontext

In de volgende tabel ziet u de scenario's waarin resourcecontext-RBAC het nuttigst is. Let op de verschillen in toegangsvereisten tussen SOC-teams en niet-SOC-teams.

Type vereiste	SOC-team	Niet-SOC-team
Machtigingen	De hele werkruimte	Alleen specifieke resources
Toegang tot gegevens	Alle gegevens in de werkruimte	Alleen gegevens voor bronnen waartoe het team toegang heeft
Ervaring	De volledige Microsoft Sentinel ervaring, mogelijk beperkt door de functionele machtigingen die aan de gebruiker zijn toegewezen	Alleen logboekquery's en werkmappen

Als uw team vergelijkbare toegangsvereisten heeft als het niet-SOC-team dat in de bovenstaande tabel wordt beschreven, is RBAC in resourcecontext mogelijk een goede oplossing voor uw organisatie.

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

In het voorbeelddiagram van resource-context RBAC-architectuur:

De Log Analytics-werkruimte die is ingeschakeld voor Microsoft Sentinel, wordt in een afzonderlijk abonnement geplaatst om de machtigingen beter te isoleren van het abonnement dat de toepassingenteams gebruiken om hun workloads te hosten.
De toepassingsteams krijgen toegang tot hun respectieve resourcegroepen, waar ze hun resources kunnen beheren.

Door de werkruimte in een apart abonnement te plaatsen en resource-context RBAC te gebruiken, kunnen applicatieteams logs bekijken die door alle bronnen waar ze toegang toe hebben, zelfs wanneer de logs 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 voor een specifieke resource weer te geven, of via Azure Monitor, om alle logboeken weer te geven die ze tegelijkertijd kunnen openen.

Configureer resourcecontext-RBAC expliciet voor niet-Azure-resources

Azure resources hebben ingebouwde ondersteuning voor RBAC in resourcecontext, maar mogelijk moet u extra afstemmen wanneer u met niet-Azure resources werkt. Bijvoorbeeld, gegevens in je Log Analytics-werkruimte die zijn ingeschakeld voor Microsoft Sentinel en geen Azure-bronnen zijn, omvatten Syslog-, CEF- of Microsoft Entra ID-gegevens, of gegevens verzameld door een aangepaste verzamelaar.

Om resource-context RBAC te configureren voor niet-Azure data, voltooit u de volgende procedure.

Ga als volgende te werk om RBAC voor resourcecontext expliciet te configureren:

Zorg ervoor dat u RBAC voor resourcecontext hebt ingeschakeld in Azure Monitor.
Maak een resourcegroep voor elk team gebruikers dat toegang moet hebben tot uw resources zonder de volledige Microsoft Sentinel omgeving.

Wijs machtigingen voor logboeklezer toe voor elk van de teamleden.
Wijs resources toe aan de resourceteamgroepen die u hebt gemaakt en tag gebeurtenissen met de relevante resource-id's.

Wanneer Azure resources gegevens naar Microsoft Sentinel verzenden, worden de logboekrecords automatisch gelabeld met de resource-id van de gegevensbron.

Tip

U wordt aangeraden de resources waarvoor u toegang verleent te groepeer onder een specifieke resourcegroep die voor dit doel is gemaakt.

Als dat niet lukt, controleert u of uw team rechtstreeks machtigingen voor logboeklezers heeft voor de resources waartoe u ze toegang wilt geven.

Zie voor meer informatie over resource-id's:

Resource-id's met logboekdoorsturen

Wanneer gebeurtenissen worden verzameld met behulp van CEF (Common Event Format) of Syslog, wordt het doorsturen van logboeken gebruikt om gebeurtenissen van meerdere bronsystemen te verzamelen.

Wanneer een CEF- of Syslog-doorstuur-VM bijvoorbeeld luistert naar de bronnen die Syslog-gebeurtenissen verzenden en deze doorstuurt naar Microsoft Sentinel, wordt de resource-id van de VM voor het doorsturen van logboeken toegewezen aan alle gebeurtenissen die ze doorsturen.

Als u meerdere teams hebt, moet u ervoor zorgen dat u afzonderlijke VM's voor het doorsturen van logboeken hebt die de gebeurtenissen voor elk afzonderlijk team verwerken.

Het scheiden van uw VM's zorgt er bijvoorbeeld voor dat Syslog-gebeurtenissen die deel uitmaken van Team A worden verzameld met behulp van de collector-VM A.

Tip

Wanneer u een on-premises VM of een andere cloud-VM, zoals AWS, gebruikt als doorstuurserver voor logboeken, moet u ervoor zorgen dat deze een resource-id heeft door Azure Arc te implementeren.
Als u de vm-omgeving voor het doorsturen van logboeken wilt schalen, kunt u een VM-schaalset maken om uw CEF- en Syslog-logboeken te verzamelen.

Resource-ID's met Logstash-gegevensverzameling

Als u uw gegevens verzamelt met de Microsoft Sentinel Logstash-uitvoerinvoegtoepassing, gebruikt u het veld azure_resource_id om uw aangepaste collector te configureren om de resource-id in uw uitvoer op te nemen.

Als je resource-context RBAC gebruikt en wilt dat de door de API verzamelde events beschikbaar zijn voor specifieke gebruikers, gebruik dan de resource ID van de resourcegroep die je hebt geconfigureerd in Expliciet resource-context RBAC configureren voor niet-Azure resources.

Het volgende Logstash-configuratiebestand toont bijvoorbeeld hoe je gebeurtenissen via Beats-invoer kunt invoeren en deze naar een Log Analytics-werkruimte kunt sturen met behulp van de Microsoft Sentinel output-plugin, waarbij het azure_resource_id veld is ingesteld om gebeurtenissen te taggen met een specifieke resourcegroep voor resource-context RBAC:

 input {
     beats {
         port => "5044"
     }
 }
 filter {
 }
 output {
     microsoft-logstash-output-azure-loganalytics {
       workspace_id => "4g5tad2b-a4u4-147v-a4r7-23148a5f2c21" # <your workspace id>
       workspace_key => "u/saRtY0JGHJ4Ce93g5WQ3Lk50ZnZ8ugfd74nk78RPLPP/KgfnjU5478Ndh64sNfdrsMni975HJP6lp==" # <your workspace key>
       custom_log_table_name => "tableName"
       azure_resource_id => "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/contosotest" # <your resource ID>   
     }
 }

Tip

U kunt meerdere output secties toevoegen om onderscheid te maken tussen de tags die zijn toegepast op verschillende gebeurtenissen.

Resource-id's in de verzameling van de Log Analytics API

Wanneer u verzamelt met behulp van de Log Analytics-gegevensverzamelaar-API, kunt u gebeurtenissen toewijzen met een resource-id met behulp van de HTTP x-ms-AzureResourceId-aanvraagheader .

Alternatieven voor resourcecontext-RBAC

Afhankelijk van de benodigde rechten in uw organisatie, kan het gebruik van resource-context RBAC niet volledig voldoen aan alle gegevenstoegangsvereisten in uw organisatie. Overweeg bijvoorbeeld dat een organisatie die de aparte-subscription workspace-architectuur gebruikt zoals beschreven in Scenarios for resource-context RBAC, ook toegang tot Office 365-logs moet verlenen aan een intern auditteam. In dit geval kunnen ze RBAC op tabelniveau gebruiken om het auditteam toegang te verlenen tot de hele OfficeActivity-tabel , zonder machtigingen te verlenen aan een andere tabel.

In de volgende lijst worden scenario's beschreven waarin andere oplossingen voor gegevenstoegang mogelijk beter aan uw vereisten voldoen:

Scenario	Oplossing
Een dochteronderneming heeft een SOC-team dat een volledige Microsoft Sentinel ervaring vereist.	Gebruik in dit geval een multi-werkruimtearchitectuur om uw gegevenstoegangsrechten te scheiden. Zie voor meer informatie: Microsoft Sentinel uitbreiden voor werkruimten en tenants > Werken met incidenten in veel werkruimten tegelijk
U wilt toegang verlenen tot een specifiek type gebeurtenis.	Geef bijvoorbeeld een Windows-beheerder toegang tot Windows-beveiliging gebeurtenissen in alle systemen. Gebruik in dergelijke gevallen RBAC op tabelniveau om machtigingen voor elke tabel te definiëren.
Beperk de toegang tot een fijner detailniveau, hetzij zonder dit op de resource te baseren, hetzij tot slechts een deelverzameling van de velden in een gebeurtenis	U kunt bijvoorbeeld de toegang tot Office 365 logboeken beperken op basis van de dochteronderneming van een gebruiker. In dit geval biedt u toegang tot gegevens met behulp van ingebouwde integratie met Power BI-dashboards en -rapporten.
Toegang beperken per beheergroep	Plaats Microsoft Sentinel onder een afzonderlijke beheergroep die is toegewezen aan beveiliging, zodat alleen minimale machtigingen worden overgenomen aan groepsleden. Wijs binnen uw beveiligingsteam machtigingen toe aan verschillende groepen op basis van elke groepsfunctie. Omdat alle teams toegang hebben tot de volledige werkruimte, hebben ze toegang tot de volledige Microsoft Sentinel ervaring, beperkt door alleen de Microsoft Sentinel rollen die aan ze zijn toegewezen. Zie Machtigingen in Microsoft Sentinel voor meer informatie.

Zie voor meer informatie:

Feedback

Is deze pagina nuttig?

Last updated on 2026-08-14