OneLake-model til dataadgangskontrol (prøveversion)

Artikel
2025-04-01

OneLake-sikkerhed bruger rolletildelinger til at anvende tilladelser til sine medlemmer. Du kan enten tildele roller til enkeltpersoner eller til sikkerhedsgrupper, Microsoft 365-grupper og distributionslister. Alle medlemmer i brugergruppen får tildelt rollen. Hvis en person er i to eller flere sikkerhedsgrupper eller Microsoft 365-grupper, får vedkommende det højeste tilladelsesniveau, der leveres af rollerne. Hvis du indlejrer brugergrupper og tildeler en rolle til en gruppe, har alle de indeholdte brugere tilladelser.

OneLake-sikkerhed giver brugerne mulighed for kun at definere dataadgangsroller for Lakehouse Items.

OneLake-sikkerhed begrænser dataadgangen for brugere med arbejdsområde Viewer- eller læseadgang til et lakehouse. Det gælder ikke for arbejdsområdeadministratorer, medlemmer eller bidragydere. Derfor understøtter OneLake-sikkerhed kun læserettigheder.

Opret roller

Du kan definere og administrere OneLake-sikkerhedsroller via indstillingerne for dataadgang i lakehouse.

Få mere at vide i Kom i gang med dataadgangsroller.

Standardroller i lakehouse

Når en bruger opretter et nyt lakehouse, genererer OneLake standardroller. Disse roller giver brugerne fabric-arbejdsområderettigheder til at få adgang til dataene i lakehouse. Du kan slette eller redigere standardrollerne som enhver anden rolle.

Standardrolledefinitioner:

Stofelement	Rollenavn	Tilladelse	Mapper inkluderet	Tildelte medlemmer
Lakehouse	`DefaultReader`	Læst	Alle mapper under `Tables/` og `Files/`	Alle brugere med tilladelsen ReadAll
Lakehouse	`DefaultReadWriter`	Læst	Alle mapper	Alle brugere med skrivetilladelse

Bemærk

Hvis du vil begrænse adgangen til bestemte brugere eller bestemte mapper, skal du enten ændre standardrollen eller fjerne den og oprette en ny brugerdefineret rolle.

Nedarvning i OneLake-sikkerhed

For en given mappe arver OneLake-sikkerhedstilladelser altid til hele hierarkiet af mappens filer og undermapper.

Du kan f.eks. overveje følgende hierarki for et lakehouse i OneLake:

Tables/
──── (empty folder)
Files/
────folder1
│   │   file11.txt
│   │
│   └───subfolder11
│       │   file1111.txt
|       │
│       └───subfolder111
|            │   file1111.txt
│   
└───folder2
    │   file21.txt

Du opretter to roller for dette lakehouse. Role1 giver læsetilladelse til folder1, og Role2 giver læsetilladelse til mappe2.

For det angivne hierarki arver OneLake-sikkerhedstilladelser for Role1 og Role2 på følgende måde:

Rolle1: Læs mappe1

│   │   file11.txt
│   │
│   └───subfolder11
│       │   file1111.txt
|       │
│       └───subfolder111
|            │   file1111.txt

Rolle2: Læs mappe2
```
    │   file21.txt
```

Gennemgang og registrering i OneLake-sikkerhed

OneLake-sikkerhed giver automatisk gennemgang af overordnede elementer for at sikre, at data er nemme at finde. Tildeling af læserettigheder til undermappen11 giver brugeren mulighed for at få vist og gennemgå den overordnede mappe1. Denne funktionalitet svarer til Windows-mappetilladelser, hvor det er muligt at finde og gennemgå de overordnede mapper, når du giver adgang til en undermappe. Den liste og gennemgang, der er tildelt den overordnede, udvides ikke til andre elementer uden for de direkte overordnede, så det sikres, at andre mapper bevares sikre.

Overvej f.eks. følgende hierarki for et lakehouse i OneLake.

Tables/
──── (empty folder)
Files/
────folder1
│   │   file11.txt
│   │
│   └───subfolder11
│       │   file111.txt
|       │
│       └───subfolder111
|            │   file1111.txt
│   
└───folder2
    │   file21.txt

For det angivne hierarki giver OneLake-sikkerhedstilladelserne for 'Role1' følgende adgang. Adgang til file11.txt er ikke synlig, da den ikke er overordnet for undermappen11. På samme måde er file111.txt heller ikke synlige for Role2.

Rolle1: Læs undermappe11

Files/
────folder1
│   │
│   └───subfolder11
│       │   file111.txt
|       │
│       └───subfolder111
|            │   file1111.txt

Rolle2: Læs undermappe111

Files/
────folder1
│   │
│   └───subfolder11
|       │
│       └───subfolder111
|            │   file1111.txt

For genveje er funktionsmåden for listen en smule anderledes. Genveje til eksterne datakilder fungerer på samme måde som mapper, men genveje til andre OneLake-placeringer har en særlig funktionsmåde. Genvejens destinationstilladelser bestemmer adgangen til en OneLake-genvej. Når du angiver genveje, foretages der ikke noget kald for at kontrollere måladgangen. Når du angiver en mappe, returneres alle interne genveje derfor, uanset om en bruger har adgang til destinationen. Når en bruger forsøger at åbne genvejen, evalueres adgangskontrollen, og en bruger kan kun se data, som brugeren har de nødvendige tilladelser til at se. Du kan få flere oplysninger om genveje i afsnittet sikkerhed for genveje.

Overvej følgende mappehierarki, der indeholder genveje.

Files/
────folder1
│   
└───shortcut2
|
└───shortcut3

Rolle1: Læs mappe1

Files/
────folder1
│   
└───shortcut2
|
└───shortcut3

Rolle2: Der er ikke defineret nogen tilladelser

Files/
│   
└───shortcut2
|
└───shortcut3

Sådan evalueres OneLake-sikkerhedstilladelser med Fabric-tilladelser

Med tilladelser til arbejdsområde og element kan du give "grov detaljering" adgang til data i OneLake for det angivne element. OneLake-sikkerhedstilladelser giver dig mulighed for kun at begrænse dataadgangen i OneLake til bestemte mapper.

Diagram, der viser rækkefølgen af evalueringer af tilladelser med arbejdsområde, element og RBAC.

Når en bruger forsøger at få adgang til en mappe i et lakehouse, kontrollerer OneLake-sikkerheden først tilladelserne for arbejdsområdet og derefter lakehouse-elementet og derefter mappen.

Tilladelser til Sikkerhed i OneLake og Arbejdsområde

Tilladelser til arbejdsområder er den første sikkerhedsgrænse for data i OneLake. Hvert arbejdsområde repræsenterer et enkelt domæne eller projektområde, hvor teams kan samarbejde om data. Du administrerer sikkerhed i arbejdsområdet via Roller i Fabric-arbejdsområdet. Få mere at vide om Fabric-rollebaseret adgangskontrol (RBAC): Arbejdsområderoller

Arbejdsområderoller i Fabric tildeler følgende tilladelser i OneLake.

Tilladelse	Admin	Medlem	Bidragyder	Læser
Vis filer i OneLake	Altid* Ja	Altid* Ja	Altid* Ja	Nej som standard. Brug OneLake-sikkerhed til at give adgang.
Skriv filer i OneLake	Altid* Ja	Altid* Ja	Altid* Ja	Nr.

*Da rollerne Arbejdsområdeadministrator, Medlem og Bidragyder automatisk tildeler Skrivetilladelser til OneLake, tilsidesætter de alle Læsetilladelser til OneLake-sikkerhed.

Arbejdsområderolle	Anvender OneLake læsetilladelser til RBAC?
Administrator, bidragyder, medlem	Nej, OneLake Security ignorerer alle OneLake RBC Read-tilladelser
Seer	Ja, hvis det er defineret, anvendes tilladelsen Læs i OneLake

Tilladelserne OneLake Security og Lakehouse

I et arbejdsområde kan Fabric-elementer have tilladelser, der er konfigureret separat fra arbejdsområderollerne. Du kan konfigurere tilladelser enten ved at dele et element eller ved at administrere tilladelserne for et element. Følgende tilladelser bestemmer en brugers mulighed for at udføre handlinger på data i OneLake.

Tilladelser til Lakehouse

Lakehouse-tilladelse	Kan du få vist filer i OneLake?	Kan du skrive filer i OneLake?	Kan du læse data via SQL Analytics-slutpunktet?
Læst	Nej som standard. Brug OneLake-sikkerhed til at give adgang.	Nr.	Nr.
Læs alle	Ja som standard. Brug OneLake-sikkerhed til at begrænse adgangen.	Nr.	Nr.
Skriv	Ja	Ja	Ja
Execute, Reshare, ViewOutput, ViewLogs	I/T – kan ikke tildeles alene	I/T – kan ikke tildeles alene	I/T – kan ikke tildeles alene

Tilladelser til SQL Analytics-slutpunkter i Lakehouse

SQL Analytics-slutpunktet er et lager, der automatisk genereres fra et lakehouse i Microsoft Fabric. En kunde kan skifte fra visningen "Lake" i lakehouse (som understøtter data engineering og Apache Spark) til visningen "SQL" for det samme lakehouse. Få mere at vide om SQL Analytics-slutpunktet i dokumentationen til Data Warehouse: SQL-analyseslutpunkt.

tilladelse til SQL Analytics-slutpunkt	brugere kan få vist filer via OneLake-slutpunktet?	brugere kan skrive filer via OneLake-slutpunktet?	Brugere kan læse data via SQL Analytics-slutpunktet?
Læst	Nej som standard. Brug OneLake-sikkerhed til at give adgang.	Nr.	Nej som standard, men kan konfigureres med SQL-detaljerede tilladelser.
ReadData	Nej som standard. Brug OneLake-sikkerhed til at give adgang.	Nr.	Ja
Skriv	Ja	Ja	Ja

Semantiske standardmodeltilladelser for Lakehouse

Når brugeren opretter et lakehouse i Microsoft Fabric, klargør systemet også den tilknyttede semantiske standardmodel. Den semantiske standardmodel indeholder målepunkter oven på lakehouse-data. Den semantiske model gør det muligt for Power BI at indlæse data til rapportering.

Standardtilladelse til semantisk model	Kan du få vist filer i OneLake?	Kan du skrive filer i OneLake?	Kan du se skemaet i semantisk model?	Kan læse data i semantisk model?
Læst	Nej som standard. Brug OneLake-sikkerhed til at give adgang.	Nr.	Nr.	Ja som standard. Kan begrænses med sikkerhed på objektniveau i Power BI og sikkerhed på rækkeniveau i Power BI
Build	Ja som standard. Brug OneLake-sikkerhed til at begrænse adgangen.	Ja	Ja	Ja
Skriv	Ja	Ja	Ja	Ja
Del igen	I/T – kan ikke tildeles alene	I/T – kan ikke tildeles alene	I/T – kan ikke tildeles alene	I/T – kan ikke tildeles alene

Når brugeren deler et lakehouse, giver vedkommende andre brugere eller en gruppe brugere adgang til et lakehouse uden at give adgang til arbejdsområdet og resten af dets elementer.

Når nogen deler et lakehouse, kan de også tildele følgende yderligere tilladelser:

Tilladelsen ReadData til SQL Analytics-slutpunktet
Tilladelsen ReadAll til lakehouse
Tilladelsen Opret for den semantiske standardmodel

Du kan få flere oplysninger under Sådan fungerer Lakehouse-deling

SQL Analytics-slutpunktet er et lager. Du kan få flere oplysninger om tilladelsesmodellen under Share Warehouse-data og administrere tilladelser

indstillingen deling	Kan du få vist filer i OneLake?	Kan du skrive filer i OneLake?	Kan du læse data via SQL Analytics-slutpunktet?	Kan du få vist og bygge semantiske modeller?
Der er ikke valgt flere tilladelser	Nej som standard. Brug OneLake RBAC til at give adgang.	Nr.	Nr.	Nr.
Læs alle SQL-slutpunktsdata	Nej som standard. Brug OneLake RBAC til at give adgang.	Nr.	Ja	Nr.
Læs alle Apache Spark, og abonner på begivenheder	Ja som standard. Brug OneLake RBAC til at begrænse adgangen.	Nr.	Nr.	Nr.
Opret rapporter på standarddatasættet	Ja som standard. Brug OneLake RBAC til at begrænse adgangen.	Nr.	Nr.	Ja

Genveje

OneLake-sikkerhed i interne genveje

For alle mapper i et lakehouse arver tilladelser altid til alle interne genveje, hvor denne mappe er defineret som destination.

Når en bruger får adgang til data via en genvej til en anden OneLake-placering, bruges identiteten for den kaldende bruger til at godkende adgang til dataene i genvejens destinationssti. Derfor skal denne bruger have OneLake-sikkerhedstilladelser på målplaceringen for at kunne læse dataene.

Vigtigt

Når du får adgang til genveje via semantiske Power BI-modeller eller T-SQL-, overføres den kaldende brugers identitet ikke til genvejsmålet. Ejeren af opkaldselementet overføres i stedet for og uddelegerer adgang til den kaldende bruger.

Definition af OneLake-sikkerhedstilladelser for den interne genvej er ikke tilladt og skal defineres i destinationsmappen, der er placeret i destinationselementet. Destinationselementet skal være en elementtype, der understøtter OneLake-sikkerhedsroller. I øjeblikket er det kun Lakehouse, der understøtter OneLake-sikkerhedsroller.

Den næste tabel angiver, om det tilsvarende genvejsscenarie understøtter OneLake-sikkerhedstilladelser.

Internt genvejsscenarie	Understøttes OneLake-sikkerhedstilladelser?	Kommentarer
Genvej i et lakehouse, der peger på folder2 i samme lakehouse.	Understøttet.	Hvis du vil begrænse adgangen til data i genvejen, skal du definere OneLake-sikkerhed for mappe2.
Genvej i et lakehouse, der peger på folder2 i et andet lakehouse-	Understøttet.	Hvis du vil begrænse adgangen til data i genvejen, skal du definere OneLake-sikkerhed for mappe2 i det andet lakehouse.
Genvej i et lakehouse, der peger på en tabel, der er placeret i et data warehouse	Ikke understøttet.	OneLake understøtter ikke definition af sikkerhedstilladelser i data warehouses. Adgangen bestemmes i stedet på baggrund af tilladelsen ReadAll.
Genvej i et lakehouse, der peger på en tabel i en KQL-database	Ikke understøttet.	OneLake understøtter ikke definition af sikkerhedstilladelser i KQL-databaser. Adgangen bestemmes i stedet på baggrund af tilladelsen ReadAll.

OneLake-sikkerhed i eksterne genveje (ADLS, S3, Dataverse)

OneLake understøtter definition af tilladelser til genveje, f.eks. ADLS-, S3- og Dataverse-genveje. I dette tilfælde anvendes tilladelserne oven på den delegerede godkendelsesmodel, der er aktiveret for denne type genvej.

Antag, at user1 opretter en S3-genvej i et lakehouse, der peger på en mappe i en AWS S3-bucket. Derefter forsøger user2 at få adgang til data i denne genvej.

Tillader S3-forbindelse adgang for den delegerede bruger1?	Tillader OneLake-sikkerheden adgang for den anmodende bruger2?	Resultat: Kan user2 få adgang til data i S3 Genvej?
Ja	Ja	Ja
Nr.	Nr.	Nr.
Nr.	Ja	Nr.
Ja	Nr.	Nr.

OneLake-sikkerhedstilladelserne kan defineres enten for hele genvejens omfang eller for de valgte undermapper. Tilladelser, der er angivet for en mappe, nedarver rekursivt til alle undermapper, også selvom undermappen er inden for genvejen.

Få mere at vide om genvejene S3, ADLS og Dataverse i OneLake-genveje.

Sikkerhed for rækker og kolonner

OneLake-sikkerhedsroller giver mulighed for sikkerhed på rækkeniveau (RLS) og sikkerhed på kolonneniveau (CLS) i tabeller i et lakehouse. Sikkerhed på rækkeniveau og CLS følger specifikke sammensætningsregler for enkelte og flere roller. Generelt er sikkerhed på rækkeniveau og CLS et skæringspunkt inden for en rolle og består af en forening på tværs af flere roller.

Bemærk

OneLake-sikkerhed er i øjeblikket i en begrænset prøveversion. Hvis du vil anmode om at deltage i prøveversionen og få adgang til disse funktioner, skal du udfylde formularen på https://aka.ms/onelakesecuritypreview.

Enkelt rolle

Når en rolle defineres med sikkerhed på rækkeniveau og CLS, vælger en bruger først tabeller, der skal tildeles adgang til. Fra denne markering kan begrænsninger som RLS og CLS defineres i en eller flere tabeller. RLS og CLS opretter som filtre på det fulde skema og de data, der er tildelt til en tabel.

Eksempler:

UserA er medlem af Role1. Role1 har følgende definition:

Læseadgang til Table1
CLS: Table1 har Column1 fjernet.
RLS: Table1 where Column2 = "US".

Når UserA kører en forespørgsel på Table1, kan de se alle kolonner undtagen Column1 og kun rækker, hvor Column2 har værdien "US".

Flere roller

For sikkerhed på rækkeniveau og CLS på tværs af flere roller kombineres sikkerheden via en samling af hver kategori. Hver rolle opretter en visning af en tabel med RLS- og CLS-regler, og brugeren får vist en forening af disse visninger.

CLS kombinerer som en simpel forening på tværs af roller. Enhver begrænsning, der er forbundet uden begrænsninger, medfører ingen begrænsninger for den pågældende tabel.

RLS kombineres med et OR mellem SQL-sætninger. På samme måde som CLS medfører alle RLS-regler, der er forbundet med fuld adgang til tabellen, at alle rækker er synlige.