Hantera åtkomst till Microsoft Sentinel data efter resurs

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

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

Scenarier för RBAC för resurskontext

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.

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 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 som värd 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 rbac kan dessa team visa loggar som genereras av alla resurser som 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 resurskontext-RBAC för icke-Azure resurser

Azure resurser har inbyggt stöd för resurskontext-RBAC, men kan kräva ytterligare finjustering när du arbetar med icke-Azure resurser. Data i Log Analytics-arbetsytan som är aktiverade för Microsoft Sentinel som inte är Azure resurser är till exempel Syslog-, CEF- eller AAD-data eller data som samlas in av en anpassad insamlare.

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

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

1. Kontrollera att du har aktiverat resurskontext-RBAC i Azure Monitor.

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

3. 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:t med loggvidarebefordring
   • Resurs-ID:t med Logstash-samlingen
   • Resurs-ID:n med Log Analytics API-samlingen

Resurs-ID:t med loggvidarebefordring

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 virtuell dator med CEF- eller Syslog-vidarebefordran lyssnar efter källorna som skickar Syslog-händelser och vidarebefordrar dem till Microsoft Sentinel tilldelas loggens resurs-ID för vidarebefordrande av virtuell dator till alla händelser som de 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.

Resurs-ID:t med Logstash-samlingen

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 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/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/contosotest" # <your resource ID>   
     }
 }

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 .

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.

Alternativ till RBAC för resurskontext

Beroende på vilka behörigheter som krävs i din organisation kan det hända att rbac för resurskontext inte ger någon fullständig lösning. 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 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:

Relaterat innehåll

Mer information finns i:

• Behörigheter i Microsoft Sentinel
• Hantera åtkomst till Log Analytics-arbetsytor
• Vad är Azure rollbaserad åtkomstkontroll (Azure RBAC)?