Hantera åtkomst till Microsoft Sentinel-data efter resurs

Artikel
10/16/2024

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

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ärdsteam (icke-SOC) åtkomst till Windows-händelsedata för de servrar som de äger.

I sådana fall rekommenderar vi att du konfigurerar din rollbaserade åtkomstkontroll (RBAC) baserat på de resurser som tillåts för dina användare, i stället för att ge dem åtkomst till arbetsytan eller specifika Microsoft Sentinel-funktioner. Den här metoden kallas även för att konfigurera RBAC för resurskontext.

När användarna har åtkomst till Microsoft Sentinel-data via de resurser 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 virtuell Azure-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.

Kommentar

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 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 RBAC med resurskontext i Microsoft Sentinel.

Scenarier för RBAC för resurskontext

I följande tabell visas de scenarier där RBAC med resurskontext är mest användbart. Observera skillnaderna i åtkomstkrav mellan SOC-team och icke-SOC-team.

Kravtyp	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
Uppleva	Den fullständiga Microsoft Sentinel-upplevelsen, eventuellt begränsad av de funktionella behö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ärdsteam behöver åtkomst till olika datauppsättningar, och resurskontext-RBAC används för att tillhandahålla de behörigheter som krävs.

Titta på den här bilden:

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 för att vara värdar för sina arbetsbelastningar.
Programteamen beviljas åtkomst till sina respektive resursgrupper, där de kan hantera sina resurser.

Med den här separata prenumerationen och resurskontexten kan dessa team visa loggar som genereras av alla resurser de har åtkomst till, även när loggarna lagras på 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 med resurskontext, men kan kräva ytterligare finjustering när du arbetar med icke-Azure-resurser. Data på din Log Analytics-arbetsyta som är aktiverad för Microsoft Sentinel och som inte är Azure-resurser inkluderar syslog-, CEF- eller AAD-data eller data som samlas in av en anpassad insamlare.

Använd följande steg om du vill konfigurera RBAC för resurskontext, men dina data är inte en Azure-resurs.

Så här konfigurerar du rbac för resurskontext explicit:

Kontrollera att du har aktiverat RBAC för resurskontext i Azure Monitor.
Skapa en resursgrupp för varje team med användare som behöver komma åt dina resurser utan hela Microsoft Sentinel-miljön.

Tilldela loggläsarbehörigheter för var och en av teammedlemmarna.
Tilldela resurser till de resursteamgrupper som du skapade och tagga händelser med relevanta resurs-ID:er.

När Azure-resurser skickar data till Microsoft Sentinel taggas loggposterna automatiskt med datakällans resurs-ID.

Dricks

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:t med loggvidarebefordring

När händelser samlas in med Common Event Format (CEF) eller Syslog används vidarebefordring av loggar för att samla in händelser från flera källsystem.

När till exempel en CEF- eller Syslog-vidarebefordrande virtuell dator lyssnar efter de källor som skickar Syslog-händelser och vidarebefordrar dem till Microsoft Sentinel, tilldelas loggvidarebefordring av VM-resurs-ID till alla händelser som de vidarebefordrar.

Om du har flera team kontrollerar du att du har separata virtuella loggvidarebefordringsdatorer 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.

Dricks

När du använder en lokal virtuell dator eller en annan virtuell dator i molnet, till exempel AWS, som loggvidare, kontrollerar du att den har ett resurs-ID genom att implementera Azure Arc.
Om du vill skala loggvidarebefordringsmiljön för virtuella datorer bör du överväga att skapa en VM-skalningsuppsättning för att samla in dina CEF- och Sylog-loggar.

Resurs-ID:t med Logstash-samling

Om du samlar in dina data med hjälp av plugin-programmet för Microsoft Sentinel Logstash-utdata använder du fältet azure_resource_id för att konfigurera din anpassade insamlare så att den inkluderar resurs-ID:t i dina utdata.

Om du använder resurskontext-RBAC och vill att de händelser som samlas in av API:et ska vara tillgängliga för specifika användare använder du resurs-ID:t för den resursgrupp som du skapade för dina användare.

Följande kod visar till exempel en Logstash-exempelkonfigurationsfil:

 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/wvvu95a2-99u4-uanb-hlbg-2vatvgqtyk7b/resourceGroups/contosotest" # <your resource ID>   
     }
 }

Dricks

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 med Log Analytics API-samlingen

När du samlar in med log analytics-api:et för datainsamlare kan du tilldela händelser med ett resurs-ID med hjälp av begärandehuvudet HTTP x-ms-AzureResourceId.

Alternativ till RBAC för resurskontext

Beroende på vilka behörigheter som krävs i din organisation kanske det inte finns någon fullständig lösning med hjälp av resurskontext-RBAC. Tänk till exempel på om den organisation vars arkitektur beskrivs i föregående avsnitt också måste bevilja åtkomst till Office 365-loggar till en intern granskningsteam. I det här fallet kan de använda RBAC på tabellnivå för att ge granskningsteamet åtkomst till hela OfficeActivity-tabellen , utan att ge behörighet 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-upplevelse.	I det här fallet använder du en arkitektur för flera arbetsytor för att separera dina databehörigheter. För ytterligare information, se: Utöka Microsoft Sentinel mellan arbetsytor och klientorganisationer >Arbeta med incidenter på många arbetsytor samtidigt
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 hela 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.

Nästa steg

Mer information finns i Behörigheter i Microsoft Sentinel.

Dela via