Delen via

Toegang tot Microsoft Sentinel-gegevens beheren per resource

  • Artikel

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 de toegang tot specifieke functies in Microsoft Sentinel te configureren, afhankelijk van de toegangsvereisten in hun team.

Mogelijk hebt u echter enkele gebruikers die 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)-team toegang geven tot de Windows-gebeurtenisgegevens voor de servers waarvan ze eigenaar zijn.

In dergelijke gevallen wordt u aangeraden uw op rollen gebaseerd toegangsbeheer (RBAC) te configureren op basis van de resources die aan uw gebruikers zijn toegestaan, in plaats van hen toegang te geven tot de werkruimte of specifieke Microsoft Sentinel-functies. Deze methode wordt ook wel resourcecontext-RBAC 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 weergeven met behulp van de volgende methoden:

  • Via de resource zelf, zoals een virtuele Azure-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 in voor resourcecontext in Azure Monitor. Zie Toegang tot logboekgegevens en werkruimten beheren in Azure Monitor voor meer informatie.

Notitie

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

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

Scenario's voor resourcecontext RBAC

In de volgende tabel ziet u de scenario's waarin RBAC voor resourcecontext 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
Gegevenstoegang Alle gegevens in de werkruimte Alleen gegevens voor resources 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 voor het niet-SOC-team dat in de bovenstaande tabel wordt beschreven, is resourcecontext RBAC 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 gegevenssets, en resourcecontext-RBAC wordt gebruikt om de vereiste machtigingen op te geven.

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 machtigingen beter te isoleren van het abonnement dat de toepassingen die teams gebruiken om hun workloads te hosten.
  • De toepassingenteams 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 worden gegenereerd door resources waartoe ze toegang hebben, zelfs wanneer de logboeken worden opgeslagen in een werkruimte waar ze geen directe toegang hebben. De toepassingenteams hebben toegang tot hun logboeken via het gebied Logboeken van 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.

Resourcecontext-RBAC expliciet configureren voor niet-Azure-resources

Azure-resources hebben ingebouwde ondersteuning voor RBAC voor resourcecontext, maar vereist mogelijk extra afstemming bij het werken met niet-Azure-resources. Gegevens in uw Log Analytics-werkruimte die zijn ingeschakeld voor Microsoft Sentinel die geen Azure-resources zijn, bevatten bijvoorbeeld Syslog-, CEF- of AAD-gegevens of gegevens die zijn verzameld door een aangepaste collector.

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

RBAC voor resourcecontext expliciet configureren:

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

  2. Maak een resourcegroep voor elk team van gebruikers die toegang nodig hebben tot uw resources zonder de hele Microsoft Sentinel-omgeving.

    Wijs machtigingen voor logboeklezers 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 verzenden naar Microsoft Sentinel, worden de logboekrecords automatisch gelabeld met de resource-id van de gegevensbron.

    Tip

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

    Als u dat niet kunt, moet u ervoor zorgen dat uw team rechtstreeks machtigingen voor logboeklezers heeft voor de resources waartoe ze toegang moeten hebben.

    Zie voor meer informatie over resource-id's:

Resource-id's met doorsturen van logboeken

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

Als u bijvoorbeeld uw VM's scheidt, zorgt u ervoor 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 gebruikt, zoals AWS, als de 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 behulp van de Microsoft Sentinel Logstash-uitvoerinvoegtoepassing, gebruikt u het azure_resource_id veld om uw aangepaste collector zo te configureren dat de resource-id in uw uitvoer wordt opgenomen.

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.

De volgende code toont bijvoorbeeld een voorbeeld van een Logstash-configuratiebestand:

 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

Bij het verzamelen met behulp van de Log Analytics-gegevensverzamelaar-API kunt u toewijzen aan gebeurtenissen 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 zijn vereist in uw organisatie, biedt het gebruik van RBAC voor resourcecontext mogelijk geen volledige oplossing. Stel dat 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 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 met 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.

In dergelijke gevallen gebruikt u RBAC op tabelniveau om machtigingen voor elke tabel te definiëren.
Beperk de toegang tot een gedetailleerder niveau, niet op basis van de resource of alleen tot 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 voor groepsleden. Wijs binnen uw beveiligingsteam machtigingen toe aan verschillende groepen op basis van elke groepsfunctie. Omdat alle teams toegang hebben tot de hele werkruimte, hebben ze toegang tot de volledige Microsoft Sentinel-ervaring, die alleen wordt beperkt door de Microsoft Sentinel-rollen waaraan ze zijn toegewezen. Zie Machtigingen in Microsoft Sentinel voor meer informatie.

Gerelateerde inhoud

Zie voor meer informatie: