Behandle tilgang til Microsoft Sentinel data etter ressurs

Tilgang til et arbeidsområde administreres ved hjelp av Azure RBAC. Vanligvis har brukere som har tilgang til et log analytics-arbeidsområde aktivert for Microsoft Sentinel også tilgang til alle arbeidsområdedataene, inkludert sikkerhetsinnhold. Administratorer kan bruke Azure roller til å konfigurere tilgang til bestemte funksjoner i Microsoft Sentinel, avhengig av tilgangskravene i teamet.

Det kan imidlertid hende at du har noen brukere som bare trenger tilgang til bestemte data i arbeidsområdet, men som ikke skal ha tilgang til hele Microsoft Sentinel miljøet. Du kan for eksempel gi et ikke-sikkerhetsrelatert team (ikke-SOC) tilgang til Windows-hendelsesdataene for serverne de eier.

I slike tilfeller anbefaler vi at du konfigurerer den rollebaserte tilgangskontrollen (RBAC) basert på ressursene som er tillatt for brukerne, i stedet for å gi dem tilgang til arbeidsområdet eller bestemte Microsoft Sentinel funksjoner. Denne metoden kalles også konfigurering av RBAC for ressurskontekst.

Når brukere har tilgang til Microsoft Sentinel data via ressursene de har tilgang til i stedet for arbeidsområdet, kan de vise logger og arbeidsbøker ved hjelp av følgende metoder:

• Via selve ressursen, for eksempel en Azure virtuell maskin. Bruk denne metoden til å vise logger og arbeidsbøker bare for en bestemt ressurs.

• Via Azure Monitor. Bruk denne metoden når du vil opprette spørringer som strekker seg over flere ressurser og/eller ressursgrupper. Når du navigerer til logger og arbeidsbøker i Azure Monitor, definerer du omfanget til én eller flere bestemte ressursgrupper eller ressurser.

Aktiver RBAC for ressurskontekst i Azure Monitor. Hvis du vil ha mer informasjon, kan du se Administrere tilgang til loggdata og arbeidsområder i Azure Overvåke.

Scenarioer for RBAC for ressurskontekst

Tabellen nedenfor uthever scenarioene der RBAC for ressurskontekst er mest nyttig. Legg merke til forskjellene i tilgangskrav mellom SOC-team og ikke-SOC-team.

Hvis teamet har lignende tilgangskrav til ikke-SOC-teamet som er beskrevet i tabellen ovenfor, kan RBAC for ressurskontekst være en god løsning for organisasjonen.

Bildet nedenfor viser for eksempel en forenklet versjon av en arbeidsområdearkitektur der sikkerhets- og driftsteam trenger tilgang til ulike sett med data, og rbac for ressurskontekst brukes til å gi de nødvendige tillatelsene.

I dette bildet:

• Log Analytics-arbeidsområdet som er aktivert for Microsoft Sentinel er plassert i et eget abonnement for bedre å isolere tillatelser fra abonnementet som programteamene bruker til å være vert for arbeidsbelastningene sine.
• Programteamene får tilgang til sine respektive ressursgrupper, der de kan administrere ressursene sine.

Dette separate abonnementet og ressurskontekst-RBAC gjør det mulig for disse teamene å vise logger generert av ressurser de har tilgang til, selv når loggene er lagret i et arbeidsområde der de ikke har direkte tilgang. Programteamene kan få tilgang til loggene sine via Logger-området i Azure Portal, for å vise logger for en bestemt ressurs, eller via Azure Monitor, for å vise alle loggene de har tilgang til samtidig.

Konfigurer eksplisitt RBAC for ressurskontekst for ikke-Azure ressurser

Azure ressurser har innebygd støtte for RBAC for ressurskontekst, men kan kreve ytterligere finjustering når du arbeider med ressurser som ikke Azure. Data i Log Analytics-arbeidsområdet som er aktivert for Microsoft Sentinel som ikke er Azure ressurser, inkluderer Syslog-, CEF- eller AAD-data eller data som samles inn av en egendefinert samler.

Bruk følgende fremgangsmåte hvis du vil konfigurere RBAC for ressurskontekst, men dataene er ikke en Azure ressurs.

Slik konfigurerer du eksplisitt RBAC for ressurskontekst:

1. Kontroller at du har aktivert RBAC for ressurskontekst i Azure Monitor.

2. Opprett en ressursgruppe for hver gruppe med brukere som trenger tilgang til ressursene dine uten hele Microsoft Sentinel miljøet.

   Tilordne logglesertillatelser for hvert av teammedlemmene.

3. Tilordne ressurser til ressursgruppegruppene du opprettet, og merk hendelser med de relevante ressurs-ID-ene.

   Når Azure ressurser sender data til Microsoft Sentinel, merkes loggpostene automatisk med ressurs-ID-en for datakilden.

   Tips

   Vi anbefaler at du grupperer ressursene du gir tilgang til under en bestemt ressursgruppe som er opprettet for formålet.

   Hvis du ikke kan, må du kontrollere at gruppen har logglesertillatelser direkte til ressursene du vil at de skal få tilgang til.

   Hvis du vil ha mer informasjon om ressurs-ID-er, kan du se:

   • Ressurs-ID-er med videresending av logg
   • Ressurs-ID-er med Logstash-samling
   • Ressurs-ID-er med API-samlingen log analytics

Ressurs-ID-er med videresending av logg

Når hendelser samles inn ved hjelp av Common Event Format (CEF) eller Syslog, brukes videresending av logg til å samle hendelser fra flere kildesystemer.

Når for eksempel en VM for videresending av CEF eller Syslog lytter etter kildene som sender Syslog-hendelser, og videresender dem til Microsoft Sentinel, tilordnes ressurs-ID-en for den viderekoblede vm-maskinen til alle hendelsene de videresender.

Hvis du har flere team, må du kontrollere at du har separate virtuelle maskiner for videresending av logger som behandler hendelsene for hvert eget team.

Hvis du for eksempel skiller virtuelle maskiner, sikrer du at Syslog-hendelser som tilhører Team A samles inn ved hjelp av samler-VM A.

Ressurs-ID-er med Logstash-samling

Hvis du samler inn dataene ved hjelp av plugin-modulen Microsoft Sentinel Logstash-utdata, bruker du azure_resource_id-feltet til å konfigurere den egendefinerte samleren til å inkludere ressurs-ID-en i utdataene.

Hvis du bruker RBAC for ressurskontekst og vil at hendelsene som samles inn av API-en skal være tilgjengelige for bestemte brukere, kan du bruke ressurs-ID-en for ressursgruppen du opprettet for brukerne.

Følgende kode viser for eksempel en logstash-konfigurasjonsfil:

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

Ressurs-ID-er med API-samlingen log analytics

Når du samler inn ved hjelp av API-en for Log Analytics-datainnsamling, kan du tilordne hendelser med en ressurs-ID ved hjelp av forespørselshodet HTTP x-ms-AzureResourceId .

Hvis du bruker RBAC for ressurskontekst og vil at hendelsene som samles inn av API-en skal være tilgjengelige for bestemte brukere, kan du bruke ressurs-ID-en for ressursgruppen du opprettet for brukerne.

Alternativer til RBAC for ressurskontekst

Avhengig av tillatelsene som kreves i organisasjonen, kan det hende at det å bruke RBAC for ressurskontekst ikke gir en fullstendig løsning. Vurder for eksempel om organisasjonen hvis arkitektur er beskrevet i forrige del, også må gi tilgang til Office 365 logger til et internt overvåkingsteam. I dette tilfellet kan de bruke RBAC på tabellnivå til å gi overvåkingsteamet tilgang til hele OfficeActivity-tabellen , uten å gi tillatelser til noen annen tabell.

Listen nedenfor beskriver scenarioer der andre løsninger for datatilgang kan passe bedre til kravene dine:

Beslektet innhold

Hvis du vil ha mer informasjon, kan du se:

• Tillatelser i Microsoft Sentinel
• Administrer tilgang til Log Analytics-arbeidsområder
• Hva er Azure rollebasert tilgangskontroll (Azure RBAC)?