Administrer adgang til Microsoft Sentinel data efter ressource

Adgang til et arbejdsområde administreres ved hjælp af Azure RBAC. Brugere, der har adgang til et Log Analytics-arbejdsområde, der er aktiveret for Microsoft Sentinel har typisk også adgang til alle arbejdsområdedataene, herunder sikkerhedsindhold. Administratorer kan bruge Azure roller til at konfigurere adgang til bestemte funktioner i Microsoft Sentinel, afhængigt af adgangskravene i deres team.

Du kan dog have nogle brugere, der kun har brug for at få adgang til bestemte data i dit arbejdsområde, men som ikke skal have adgang til hele Microsoft Sentinel miljø. Det kan f.eks. være, at du vil give et team af ikke-sikkerhedsrelaterede handlinger (ikke-SOC) adgang til Windows-hændelsesdataene for de servere, de ejer.

I sådanne tilfælde anbefaler vi, at du konfigurerer din rollebaserede adgangskontrol (RBAC) baseret på de ressourcer, der er tilladt for dine brugere, i stedet for at give dem adgang til arbejdsområdet eller bestemte Microsoft Sentinel funktioner. Denne metode kaldes også konfiguration af ressourcekontekst-RBAC.

Når brugerne har adgang til Microsoft Sentinel data via de ressourcer, de kan få adgang til i stedet for arbejdsområdet, kan de få vist logge og projektmapper ved hjælp af følgende metoder:

Via selve ressourcen, f.eks. en Azure virtuel maskine. Brug denne metode til kun at få vist logge og projektmapper for en bestemt ressource.
Via Azure monitor. Brug denne metode, når du vil oprette forespørgsler, der strækker sig over flere ressourcer og/eller ressourcegrupper. Når du navigerer til logge og projektmapper i Azure Overvågning, skal du definere dit omfang til en eller flere specifikke ressourcegrupper eller ressourcer.

Aktivér ressourcekontekst-RBAC i Azure Monitor. Du kan få flere oplysninger under Administrer adgang til logføring af data og arbejdsområder i Azure Monitor.

Bemærk!

Hvis dine data ikke er en Azure ressource, f.eks. Syslog, CEF eller Microsoft Entra ID data eller data, der indsamles af en brugerdefineret indsamler, skal du manuelt konfigurere det ressource-id, der bruges til at identificere dataene og give adgang. Du kan få flere oplysninger under Konfigurer eksplicit ressourcekontekst-RBAC for ikke-Azure ressourcer.

Derudover understøttes funktioner og gemte søgninger ikke i ressourcecentrerede kontekster. Derfor understøttes Microsoft Sentinel funktioner som fortolkning og normalisering ikke for ressourcekontekst-RBAC i Microsoft Sentinel.

Scenarier for ressourcekontekst for RBAC

I følgende tabel fremhæves de scenarier, hvor ressourcekontekst-RBAC er mest nyttig. Bemærk forskellene i adgangskrav mellem SOC-teams og ikke-SOC-teams.

Kravtype	SOC-team	Ikke-SOC-team
Tilladelser	Hele arbejdsområdet	Kun specifikke ressourcer
Dataadgang	Alle data i arbejdsområdet	Kun data for ressourcer, som teamet har tilladelse til at få adgang til
Oplevelse	Den fulde Microsoft Sentinel oplevelse, muligvis begrænset af de funktionstilladelser, der er tildelt brugeren	Logfør kun forespørgsler og projektmapper

Hvis dit team har lignende adgangskrav til det ikke-SOC-team, der er beskrevet i tabellen ovenfor, kan RBAC med ressourcekontekst være en god løsning for din organisation.

På følgende billede kan du f.eks. se en forenklet version af en arbejdsområdearkitektur, hvor sikkerheds- og driftsteams skal have adgang til forskellige datasæt, og RBAC bruges til at levere de nødvendige tilladelser.

På dette billede:

Det Log Analytics-arbejdsområde, der er aktiveret for Microsoft Sentinel, placeres i et separat abonnement for bedre at isolere tilladelser fra det abonnement, som programteamene bruger til at hoste deres arbejdsbelastninger.
Programteams får adgang til deres respektive ressourcegrupper, hvor de kan administrere deres ressourcer.

Dette separate abonnement og ressourcekontekst-RBAC gør det muligt for disse teams at få vist logge, der er genereret af de ressourcer, de har adgang til, selv når loggene er gemt i et arbejdsområde, hvor de ikke har direkte adgang. Programteamene kan få adgang til deres logge via området Logge i Azure Portal, til at få vist logge for en bestemt ressource eller via Azure Overvågning for at få vist alle de logge, de kan få adgang til på samme tid.

Konfigurer eksplicit ressourcekontekst-RBAC for ressourcer, der ikke er Azure

Azure ressourcer har indbygget understøttelse af ressourcekontekst-RBAC, men kan kræve yderligere finjustering, når der arbejdes med ressourcer, der ikke er Azure. Data i dit Log Analytics-arbejdsområde, der er aktiveret for Microsoft Sentinel, som ikke er Azure ressourcer, omfatter f.eks. Syslog-, CEF- eller AAD-data eller data, der indsamles af en brugerdefineret indsamling.

Brug følgende trin, hvis du vil konfigurere ressourcekontekst-RBAC, men dine data ikke er en Azure ressource.

Sådan konfigurerer du eksplicit ressourcekontekst for RBAC:

Sørg for, at du har aktiveret ressourcekontekst-RBAC i Azure Monitor.
Opret en ressourcegruppe for hver gruppe af brugere, der skal have adgang til dine ressourcer uden hele Microsoft Sentinel miljø.

Tildel tilladelser til loglæser for hvert af teammedlemmerne.
Tildel ressourcer til de ressourcegruppegrupper, du har oprettet, og mærk hændelser med de relevante ressource-id'er.

Når Azure ressourcer sender data til Microsoft Sentinel, mærkes logposterne automatisk med datakildens ressource-id.

Tip

Vi anbefaler, at du grupperer de ressourcer, du tildeler adgang til, under en bestemt ressourcegruppe, der er oprettet til formålet.

Hvis du ikke kan, skal du sørge for, at dit team har loglæsertilladelser direkte til de ressourcer, du vil have dem til at få adgang til.

Du kan få flere oplysninger om ressource-id'er under:

Ressource-id'er med videresendelse af logfil

Når hændelser indsamles ved hjælp af CEF (Common Event Format) eller Syslog, bruges videresendelse af logfiler til at indsamle hændelser fra flere kildesystemer.

Når en CEF eller Syslog-videresendelse af VM f.eks. lytter efter de kilder, der sender Syslog-hændelser, og videresender dem til Microsoft Sentinel, tildeles det VM-ressource-id, der videresendes i logfilen, til alle de hændelser, de videresender.

Hvis du har flere teams, skal du sørge for, at du har separate vm'er til videresendelse af logfiler, der behandler hændelserne for hvert enkelt team.

Adskillelse af dine VM'er sikrer f.eks., at Syslog-hændelser, der tilhører Team A, indsamles ved hjælp af samlerens VM A.

Tip

Når du bruger en virtuel maskine i det lokale miljø eller en anden cloud-VM, f.eks. AWS, som din log forwarder, skal du sørge for, at den har et ressource-id ved at implementere Azure Arc.
Hvis du vil skalere dit vm-miljø til videresendelse af logfiler, bør du overveje at oprette et VM-skaleringssæt for at indsamle dine CEF- og Syslog-logge.

Ressource-id'er med Logstash-samling

Hvis du indsamler dine data ved hjælp af output-plug-in'en Microsoft Sentinel Logstash, skal du bruge feltet azure_resource_id til at konfigurere din brugerdefinerede indsamling til at inkludere ressource-id'et i outputtet.

Hvis du bruger ressourcekontekst-RBAC og ønsker, at de hændelser, der indsamles af API, skal være tilgængelige for bestemte brugere, skal du bruge ressource-id'et for den ressourcegruppe, du har oprettet for dine brugere.

Følgende kode viser f.eks. et eksempel på en Logtash-konfigurationsfil:

 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

Det kan være en god idé at tilføje flere output sektioner for at skelne mellem de mærker, der anvendes på forskellige hændelser.

Ressource-id'er med Log Analytics API-samlingen

Når du indsamler ved hjælp af LOG Analytics-dataindsamlings-API'en, kan du tildele hændelser med et ressource-id ved hjælp af http-x-ms-AzureResourceId-anmodningsheaderen .

Alternativer til ressourcekontekst for RBAC

Afhængigt af de tilladelser, der kræves i din organisation, leverer RBAC muligvis ikke en komplet løsning ved hjælp af ressourcekontekst. Overvej f.eks., om den organisation, hvis arkitektur er beskrevet i forrige afsnit, også skal give adgang til Office 365 logge til et internt overvågningsteam. I dette tilfælde kan de bruge RBAC på tabelniveau til at give overvågningsteamet adgang til hele OfficeActivity-tabellen uden at tildele tilladelser til andre tabeller.

På følgende liste beskrives scenarier, hvor andre løsninger til dataadgang kan passe bedre til dine krav:

Scenarie	Løsning
Et datterselskab har et SOC-team, der kræver en komplet Microsoft Sentinel oplevelse.	I dette tilfælde skal du bruge en arkitektur med flere arbejdsområder til at adskille dine datatilladelser. Du kan finde flere oplysninger under: Udvid Microsoft Sentinel på tværs af arbejdsområder og lejere > Arbejd med hændelser i mange arbejdsområder på én gang
Du vil give adgang til en bestemt type hændelse.	Giv f.eks. en Windows-administrator adgang til Windows Sikkerhed hændelser i alle systemer. I sådanne tilfælde skal du bruge RBAC på tabelniveau til at definere tilladelser for hver tabel.
Begræns adgangen til et mere detaljeret niveau, enten ikke baseret på ressourcen, eller kun til et undersæt af felterne i en hændelse	Det kan f.eks. være, at du vil begrænse adgangen til Office 365 logge baseret på en brugers datterselskab. I dette tilfælde skal du give adgang til data ved hjælp af indbygget integration med Power BI-dashboards og -rapporter.
Begræns adgang efter administrationsgruppe	Placer Microsoft Sentinel under en separat administrationsgruppe, der er dedikeret til sikkerhed, for at sikre, at kun minimale tilladelser nedarves til gruppemedlemmer. I dit sikkerhedsteam skal du tildele tilladelser til forskellige grupper i henhold til hver gruppefunktion. Da alle teams har adgang til hele arbejdsområdet, har de adgang til den fulde Microsoft Sentinel oplevelse, der kun er begrænset af de Microsoft Sentinel roller, de er tildelt. Du kan få flere oplysninger under Tilladelser i Microsoft Sentinel.

Du kan finde flere oplysninger under:

Feedback

Var denne side nyttig?

Last updated on 2026-04-23