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.

In dergelijke gevallen raden we u aan om uw op rollen gebaseerd toegangsbeheer (RBAC) te configureren op basis van de resources die zijn toegestaan voor uw gebruikers, in plaats van hen toegang te geven tot de werkruimte of specifieke Microsoft Sentinel functies. Deze methode wordt ook wel RBAC voor resourcecontext ingesteld.

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 resourcecontext-RBAC 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.

Vereistetype SOC-team Niet-SOC-team
Machtigingen De hele werkruimte Alleen specifieke resources
Toegang tot gegevens Alle gegevens in de werkruimte Alleen gegevens voor resources waartoe het team gemachtigd is
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.

Diagram van een voorbeeldarchitectuur voor resourcecontext RBAC.

In deze afbeelding:

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

Met dit afzonderlijke abonnement en resourcecontext-RBAC kunnen deze teams logboeken bekijken die zijn gegenereerd door resources waartoe ze toegang hebben, zelfs wanneer de logboeken zijn 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.

RBAC van resourcecontext expliciet configureren 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. Gegevens in uw Log Analytics-werkruimte die zijn ingeschakeld voor Microsoft Sentinel die niet Azure resources zijn, zijn bijvoorbeeld Syslog-, CEF- of AAD-gegevens of gegevens die zijn verzameld door een aangepaste verzamelaar.

Gebruik de volgende stappen als u RBAC voor resourcecontext wilt configureren, maar uw gegevens geen Azure resource zijn.

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

  1. Zorg ervoor dat u RBAC voor resourcecontext hebt ingeschakeld in Azure Monitor.

  2. 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.

  3. 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-verzameling

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 u RBAC voor resourcecontext gebruikt en wilt dat de gebeurtenissen die door de API worden verzameld, beschikbaar zijn voor specifieke gebruikers, gebruikt u de resource-id van de resourcegroep die u voor uw gebruikers hebt gemaakt.

In de volgende code wordt bijvoorbeeld een voorbeeld van een Logstash-configuratiebestand weergegeven:

 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 met de Log Analytics-API-verzameling

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 .

Als u RBAC voor resourcecontext gebruikt en wilt dat de gebeurtenissen die door de API worden verzameld, beschikbaar zijn voor specifieke gebruikers, gebruikt u de resource-id van de resourcegroep die u voor uw gebruikers hebt gemaakt.

Alternatieven voor resourcecontext RBAC

Afhankelijk van de machtigingen die in uw organisatie zijn vereist, biedt het gebruik van resourcecontext RBAC mogelijk geen volledige oplossing. Overweeg bijvoorbeeld of de organisatie waarvan de architectuur in de vorige sectie wordt beschreven, 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 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. In dit geval gebruikt u een architectuur voor meerdere werkruimten om uw gegevensmachtigingen te scheiden.

Zie voor meer informatie:
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.
Toegang beperken tot een gedetailleerder niveau, niet op basis van de resource, of tot slechts een subset 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.

Verwante onderwerpen

Zie voor meer informatie:

  • Last updated on