Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Åtkomst till en arbetsyta hanteras med hjälp av Azure RBAC. Vanligtvis har användare som har åtkomst till en Log Analytics-arbetsyta som är aktiverad för Microsoft Sentinel också åtkomst till alla arbetsytedata, inklusive säkerhetsinnehåll. Administratörer kan använda Azure roller för att konfigurera åtkomst till specifika funktioner i Microsoft Sentinel, beroende på åtkomstkraven i teamet.
Du kan dock ha vissa användare som bara behöver komma åt specifika data på din arbetsyta, men som inte bör ha åtkomst till hela Microsoft Sentinel miljön. Du kanske till exempel vill ge ett icke-säkerhetsåtgärder (icke-SOC)-team åtkomst till Windows-händelsedata för de servrar som de äger.
För användare som endast behöver tillgång till specifik data i arbetsområdet rekommenderar vi att du konfigurerar din rollbaserade åtkomstkontroll (RBAC) baserat på de resurser som dessa användare har tillgång till, istället för att ge dem tillgång till arbetsytan eller specifika Microsoft Sentinel-funktioner. Den här metoden kallas även för att konfigurera RBAC för resurskontext.
När användare har åtkomst till Microsoft Sentinel data via de resurser som de kan komma åt i stället för arbetsytan kan de visa loggar och arbetsböcker med hjälp av följande metoder:
Via själva resursen, till exempel en Azure virtuell dator. Använd den här metoden om du bara vill visa loggar och arbetsböcker för en specifik resurs.
Via Azure Monitor. Använd den här metoden när du vill skapa frågor som omfattar flera resurser och/eller resursgrupper. När du navigerar till loggar och arbetsböcker i Azure Monitor definierar du omfånget till en eller flera specifika resursgrupper eller resurser.
Aktivera RBAC för resurskontext i Azure Monitor. Mer information finns i Hantera åtkomst till loggdata och arbetsytor i Azure Monitor.
Obs!
Om dina data inte är en Azure resurs, till exempel Syslog, CEF eller Microsoft Entra ID data eller data som samlas in av en anpassad insamlare, måste du manuellt konfigurera resurs-ID:t som används för att identifiera data och aktivera åtkomst. Mer information finns i Konfigurera uttryckligen RBAC för resurskontext för icke-Azure-resurser.
Dessutom stöds inte funktioner och sparade sökningar i resurscentrerade kontexter. Därför stöds inte Microsoft Sentinel funktioner som parsning och normalisering för resurskontext-RBAC i Microsoft Sentinel.
Scenarier för resurskontextbaserad RBAC
I följande tabell visas de scenarier där RBAC för resurskontext är mest användbart. Observera skillnaderna i åtkomstkrav mellan SOC-team och icke-SOC-team.
| Typ av krav | SOC-teamet | Icke-SOC-team |
|---|---|---|
| Behörigheter | Hela arbetsytan | Endast specifika resurser |
| Dataåtkomst | Alla data på arbetsytan | Endast data för resurser som teamet har behörighet att komma åt |
| Upplevelse | Den fullständiga Microsoft Sentinel upplevelsen, eventuellt begränsad av de funktionsbehörigheter som tilldelats användaren | Endast loggfrågor och arbetsböcker |
Om ditt team har liknande åtkomstkrav som det icke-SOC-team som beskrivs i tabellen ovan kan RBAC för resurskontext vara en bra lösning för din organisation.
Följande bild visar till exempel en förenklad version av en arbetsytearkitektur där säkerhets- och åtgärdsteamen behöver åtkomst till olika datauppsättningar och resurskontext-RBAC används för att tillhandahålla de behörigheter som krävs.
I exempeldiagrammet för resurs-kontext RBAC-arkitektur:
- Log Analytics-arbetsytan som är aktiverad för Microsoft Sentinel placeras i en separat prenumeration för att bättre isolera behörigheter från den prenumeration som programteamen använder som värd för sina arbetsbelastningar.
- Programteamen beviljas åtkomst till sina respektive resursgrupper, där de kan hantera sina resurser.
Att placera arbetsområdet i en separat prenumeration och använda resurs-kontext RBAC gör att applikationsteam kan se loggar som genererats av alla resurser de har tillgång till, även när loggarna lagras i en arbetsyta där de inte har direkt åtkomst. Programteamen kan komma åt sina loggar via området Loggar i Azure Portal, för att visa loggar för en specifik resurs, eller via Azure Monitor, för att visa alla loggar som de kan komma åt samtidigt.
Konfigurera uttryckligen RBAC för resurskontext för icke-Azure-resurser
Azure-resurser har inbyggt stöd för RBAC i resurskontext, men kan kräva ytterligare finjustering när du arbetar med icke-Azure-resurser. Till exempel inkluderar data i din Log Analytics-arbetsyta som är aktiverad för Microsoft Sentinel och som inte är Azure-resurser Syslog-, CEF- eller Microsoft Entra ID-data, eller data insamlade av en anpassad insamlare.
För att konfigurera resurs-kontext RBAC för icke-Azure-data, utför följande procedur.
Så här konfigurerar du explicit resurskontextbaserad RBAC:
Kontrollera att du har aktiverat resurskontext-RBAC i Azure Monitor.
Skapa en resursgrupp för varje team med användare som behöver åtkomst till dina resurser utan hela Microsoft Sentinel miljön.
Tilldela loggläsarbehörigheter för var och en av teammedlemmarna.
Tilldela resurser till de resursgruppsgrupper som du skapade och tagga händelser med relevanta resurs-ID:er.
När Azure resurser skickar data till Microsoft Sentinel märks loggposterna automatiskt med datakällans resurs-ID.
Tips
Vi rekommenderar att du grupperar de resurser som du beviljar åtkomst för under en specifik resursgrupp som skapats för ändamålet.
Om du inte kan kontrollerar du att ditt team har loggläsarbehörighet direkt till de resurser som du vill att de ska komma åt.
Mer information om resurs-ID:t finns i:
Resurs-ID:n med vidarebefordran av loggar
När händelser samlas in med Common Event Format (CEF) eller Syslog används loggvidarebefordring för att samla in händelser från flera källsystem.
När till exempel en VM för CEF- eller Syslog-vidarebefordran lyssnar på källor som skickar Syslog-händelser och vidarebefordrar dem till Microsoft Sentinel, tilldelas resurs-ID:t för loggvidarebefordrings-VM:n till alla händelser som den vidarebefordrar.
Om du har flera team kontrollerar du att du har separata virtuella datorer för loggvidarebefordring som bearbetar händelserna för varje separat team.
Om du till exempel separerar dina virtuella datorer ser du till att Syslog-händelser som tillhör team A samlas in med hjälp av den insamlande virtuella datorn A.
Tips
- När du använder en lokal virtuell dator eller en annan virtuell dator i molnet, till exempel AWS som loggvidarebefordrare, kontrollerar du att den har ett resurs-ID genom att implementera Azure Arc.
- Om du vill skala din vm-miljö för vidarebefordring av loggar kan du skapa en VM-skalningsuppsättning för att samla in dina CEF- och Syslog-loggar.
Resurs-ID:n för Logstash-insamling
Om du samlar in dina data med hjälp av plugin-programmet Microsoft Sentinel Logstash-utdata använder du fältet azure_resource_id för att konfigurera din anpassade insamlare så att resurs-ID:t inkluderas i dina utdata.
Om du använder resurs-kontext RBAC och vill att de händelser som samlas in av API:et ska vara tillgängliga för specifika användare, använd resurs-ID:t för den resursgrupp du konfigurerade i Konfigurera explicit resurs-kontext RBAC för icke-Azure-resurser.
Till exempel visar följande Logstash-konfigurationsfil hur man tar in händelser via Beats-inmatning och skickar dem till en Log Analytics-arbetsyta med hjälp av Microsoft Sentinel-utdatapluginet, med azure_resource_id fältet inställt på att tagga händelser med en specifik resursgrupp för resurs-kontext 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>
}
}
Tips
Du kanske vill lägga till flera output avsnitt för att särskilja de taggar som tillämpas på olika händelser.
Resurs-ID:n i Log Analytics API-samlingen
När du samlar in data med Log Analytics Data Collector API kan du tilldela händelser ett resurs-ID med hjälp av HTTP-begärandehuvudet x-ms-AzureResourceId.
Om du använder resurs-kontext RBAC och vill att de händelser som samlas in av API:et ska vara tillgängliga för specifika användare, använd resurs-ID:t för den resursgrupp du konfigurerade i Konfigurera explicit resurs-kontext RBAC för icke-Azure-resurser.
Alternativ till RBAC för resurskontext
Beroende på vilka behörigheter som krävs i din organisation kan användning av resurs-kontext RBAC inte fullt ut uppfylla alla dataåtkomstkrav i din organisation. Till exempel, tänk om en organisation som använder den separata prenumerationsarkitekturen för arbetsytor som beskrivs i Scenarios for resource-context RBAC också måste ge tillgång till Office 365-loggar till ett internrevisionsteam. I det här fallet kan de använda RBAC på tabellnivå för att ge granskningsteamet åtkomst till hela OfficeActivity-tabellen , utan att bevilja behörigheter till någon annan tabell.
I följande lista beskrivs scenarier där andra lösningar för dataåtkomst kan passa dina behov bättre:
| Scenario | Lösning |
|---|---|
| Ett dotterbolag har ett SOC-team som kräver en fullständig Microsoft Sentinel erfarenhet. | I det här fallet använder du en arkitektur för flera arbetsytor för att separera dina databehörigheter. Mer information finns i: |
| Du vill ge åtkomst till en viss typ av händelse. | Ge till exempel en Windows-administratör åtkomst till Windows-säkerhet händelser i alla system. I sådana fall använder du RBAC på tabellnivå för att definiera behörigheter för varje tabell. |
| Begränsa åtkomsten till en mer detaljerad nivå, antingen inte baserat på resursen eller till endast en delmängd av fälten i en händelse | Du kanske till exempel vill begränsa åtkomsten till Office 365 loggar baserat på en användares dotterbolag. I det här fallet ger du åtkomst till data med inbyggd integrering med Power BI-instrumentpaneler och rapporter. |
| Begränsa åtkomsten efter hanteringsgrupp | Placera Microsoft Sentinel under en separat hanteringsgrupp som är dedikerad till säkerhet, vilket säkerställer att endast minimala behörigheter ärvs till gruppmedlemmar. I säkerhetsteamet tilldelar du behörigheter till olika grupper enligt varje gruppfunktion. Eftersom alla team har åtkomst till hela arbetsytan har de åtkomst till den fullständiga Microsoft Sentinel upplevelsen, som endast begränsas av de Microsoft Sentinel roller som de har tilldelats. Mer information finns i Behörigheter i Microsoft Sentinel. |
Relaterat innehåll
Mer information finns i: