Hvordan OneLake-sikkerhet kontrollerer datatilgang

OneLake-sikkerhet er et rollebasert system som avgjør hvem som kan få tilgang til data i OneLake og hvilke handlinger de kan utføre på disse dataene. Å forstå datakontrollmodellen hjelper deg å gi brukerne kun den tilgangen de trenger, slik at du kan beskytte sensitiv informasjon samtidig som de rette personene kan jobbe med den.

Denne artikkelen forklarer hvordan sikkerhetsroller i OneLake er strukturert, hvordan de integreres med arbeidsområde- og objekttillatelser, hvordan OneLake anvender og løser tilgang til dataene dine, og hvilke begrensninger du bør ha i tankene.

OneLake-sikkerhetsroller

OneLake-sikkerhet bruker en rollebasert tilgangskontroll (RBAC)-modell for å administrere tilgang til data i OneLake. I OneLake-sikkerhetsopplevelsen har hver rolle følgende komponenter:

Tillatelser: Tillatelsene rollen gir på dataene, som Read eller ReadWrite.
Type: Rolletypen. OneLake Security støtter kun Grant-roller, som gir medlemmene tilgang til dataene i rollen. Den støtter ikke Nekt roller som fjerner tilgang.
Data i rollen: Tabellene, mappene eller skjemaene som rollen gir tilgang til. Du kan også definere datatilgang med sikkerhet på rad- og kolonnenivå på tabeller.
Medlemmer i rollen: Microsoft Entra-identitetene som er tildelt rollen, som brukere, grupper eller ikke-brukeridentiteter. Hvis du tildeler en Microsoft Entra-gruppe, gir OneLake-sikkerheten rollen til alle gruppens medlemmer.

OneLake-sikkerhet bruker en deny-by-default-modell, så brukere starter uten tilgang til data med mindre en OneLake-sikkerhetsrolle eksplisitt gir tilgang. Noen Fabric-elementer starter med standardroller som gir brukerne grunnleggende tilgang basert på arbeidsområdets tillatelser.

Tillatelser og støttede elementer

OneLake sikkerhetsroller støtter følgende tillatelser:

Lese: Gir brukeren muligheten til å lese data fra en tabell og vise de tilknyttede tabell- og kolonnemetadataene. I SQL-termer er denne tillatelsen ekvivalent med både VIEW_DEFINITION og SELECT. For mer informasjon, se Metadata-sikkerhet.
ReadWrite: Gir brukeren muligheten til å lese og skrive data i en tabell eller mappe og se tilhørende tabell- og kolonnemetadata. I SQL-termer er denne tillatelsen ekvivalent med ALTER, DROP, , UPDATEog INSERT. For mer informasjon, se ReadWrite-tillatelse.

Du kan opprette OneLake-sikkerhetsroller for følgende Fabric-elementer:

Stoff vare	Støttede tillatelser
Lakehouse	Les, ReadWrite
Azure Databricks mirrored catalog	Read
Speilede databaser	Read
Speilkataloger	Read

ReadWrite-tillatelse

Bruk ReadWrite-tillatelsen for å gi skrivebeskyttede brukere skrivetilgang til spesifikke data i et element.

ReadWrite gjelder kun for brukere med lesetillatelse på et element, for eksempel brukere med rollen Viser-arbeidsområde. Å tildele ReadWrite til en arbeidsområdeadministrator, medlem eller bidragsyter har ingen effekt fordi disse arbeidsområdets rollene allerede har skrivetilgang.

ReadWrite inkluderer alle privilegier gitt av lesetillatelsen, i tillegg til at det gir skrivetilgang til det valgte objektet og dets innhold. For eksempel gir ReadWrite-tillatelse på en mappe skrivetilgang til både mappen og dataene i den.

Brukere med ReadWrite-tillatelse kan utføre følgende handlinger:

Opprett, slett eller gi nytt navn til en mappe eller tabell.
Last opp eller rediger en fil.
Lag, slett eller gi nytt navn til en snarvei.

Brukere kan utføre skriveoperasjoner gjennom Spark-notatbøker, OneLake-filutforskeren eller OneLake-API-er. Siden Fabric kun støtter enkeltmotor-skriving til data, kan brukere med ReadWrite-tillatelse kun skrive til disse dataene via OneLake. Alle spørringsmotorer fortsetter å håndheve leseoperasjoner konsekvent.

OneLake-sikkerhetsroller som gir ReadWrite-tillatelse kan ikke inneholde radnivå-sikkerhetsbegrensninger (RLS) eller kolonnenivå-sikkerhetsbegrensninger (CLS).

OneLake-sikkerhet og arbeidsområdetillatelser

Workspace-roller er den første sikkerhetsgrensen for data i OneLake. De administrerer kontrollplanet – oppretter og administrerer Fabric-elementer og tillatelser – og gjelder for alle elementer i arbeidsområdet. For de spesifikke OneLake-tillatelsene som hver arbeidsområderolle gir, se Gi tilgang med arbeidsplassroller. For å lære mer om arbeidsplasser, se Roller i arbeidsområder i Fabric.

Utover kontrollplantilgang kan arbeidsplasser også gi tilgang til dataelementer gjennom OneLake sikkerhetsstandardroller. (Standardroller gjelder kun for Viewers, fordi Admin-, Medlem- og Bidragsyter-rollene har forhøyet tilgang gjennom Write-tillatelsen.) En standardrolle er en vanlig OneLake-sikkerhetsrolle som Fabric automatisk oppretter for hvert nytt element. Det gir brukere med bestemte arbeidsområde- eller elementtillatelser et standard tilgangsnivå til data i dette elementet. For eksempel har lakehouse-elementer en DefaultReader-rolle som lar brukere med ReadAll-tillatelsen se data i lakehouse. Denne standardtilgangen sikrer at brukere som jobber med et nyopprettet element har et grunnleggende tilgangsnivå. Alle standardroller bruker en funksjon for medlemvirtualisering, slik at medlemmene i rollen er brukere i det arbeidsområdet med nødvendig tillatelse. For eksempel alle brukere med ReadAll-tillatelse på innsjøhuset.

Tabellen nedenfor viser standard standardroller. Gjenstander kan ha spesialiserte standardroller som kun gjelder for den gjenstandstypen.

Stoff vare	Rollenavn	Tillatelse gitt	Tildelte medlemmer
Lakehouse	`DefaultReader`	Read	Alle brukere med ReadAll-tillatelse
Azure Databricks mirrored catalog	`DefaultReader`	Read	Alle brukere med lesetillatelse
Speilet katalog	`DefaultReader`	Read	Alle brukere med lesetillatelse
Speilet database	`DefaultReader`	Read	Alle brukere med ReadAll-tillatelse

Du kan endre eller fjerne standardrollen fra et Fabric-element for å endre tilgangen for brukerne i den medlemsgruppen.

Motor- og brukertilgang til data

OneLake-sikkerheten er som standard minst privilegert tilgang. Noen lagringsoperasjoner kan ikke håndheve RLS eller CLS, så når en spørring ikke kan filtreres trygt, blokkerer OneLake den helt i stedet for å risikere å eksponere data brukeren ikke får se. Om en spørring filtreres eller blokkeres avhenger av tilgangsstien – en støttet spørringsmotor eller direkte brukertilgang.

For motorene som støtter RLS- og CLS-filtrering og kravene for hver, se Read data sikret med OneLake-sikkerhet.

Omfang og håndhevelse

Denne delen inneholder detaljer om hvordan OneLake-sikkerhetsroller gir tilgang til bestemte omfang, hvordan denne tilgangen fungerer, og hvordan tilgang løses på tvers av flere roller og tilgangstyper.

Sikkerhet på tabellnivå

OneLake representerer alle tabeller som mapper, men fra OneLakes sikkerhets- og spørringsmotorers perspektiv i Fabric er ikke alle mapper tabeller. For å være en gyldig tabell må en mappe oppfylle følgende betingelser:

Mappen finnes i katalogen Tables/ til et element. For skjemaaktiverte elementer må mappen også være i en gyldig skjema-mappe.
Mappen inneholder en _delta_log mappe med tilsvarende JSON-filer for tabellmetadataene.
Mappen inneholder ingen barnesnarveier.

Hvis du konfigurerer RLS eller CLS på en tabell, nekter OneLake tilgang når tabellens mappe ikke oppfyller disse kriteriene. Uten RLS eller CLS behandler OneLake en mappe som ikke oppfyller disse kriteriene som en mappe og anvender mappe-nivå sikkerhet.

Sikkerhet på rad- og kolonnenivå

Innenfor en rolle kan du begrense tilgangen til spesifikke rader og kolonner i en tabell ved å bruke sikkerhet på rad- og kolonnenivå. For mer informasjon om hva hver kontroll gjør og hvordan OneLake håndhever det, se Tabell-, kolonne- og radnivå-sikkerhet i OneLake. For informasjon om hvordan RLS og CLS løses når en bruker tilhører flere roller, se Evaluate multiple OneLake security roles.

Sikkerhet for metadata

OneLake sikkerhets lesetillatelse gir full tilgang til data og metadata i en tabell. For brukere uten tilgang til en tabell blir dataene aldri eksponert. Denne regelen gjelder også for sikkerhet på kolonnenivå og brukerens mulighet til å se eller ikke se en kolonne i den tabellen. Men OneLake-sikkerheten garanterer ikke at metadataene for en tabell ikke er tilgjengelige. Visse feilmeldinger og erfaringer kan vise kolonnenavn.

Mappetillatelsesarv og gjennomkjøring

Mappetillatelser påvirker et hierarki i to retninger:

Arv: Tillatelser gitt på en mappe gjelder nedover for dens filer og undermapper.
Traversering og listing: Når brukere har tillatelse på et barneelement, lar OneLake-sikkerheten dem liste opp og gå gjennom foreldremappene slik at de kan oppdage og navigere til dataene de har tilgang til. Navigering gir ikke tilgang til søskenfiler eller mapper.

Vurder følgende hierarki for et innsjøhus i OneLake:

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

Du oppretter en rolle, Role1, som gir lesetillatelse på subfolder11. Gjennom arv kan medlemmer av den rollen lese file111.txt og alt i subfolder111. Medlemmer kan se og bevege folder1 seg for å nå subfolder11, men de kan ikke se file11.txt fordi det er en søsken av subfolder11 og de kan ikke se Tables fordi det er en søsken av Files.

Files/
│
└───folder1
│   │
│   └───subfolder11 <-- READ
│       │   file111.txt
│       │
│       └───subfolder111
│            │   file1111.txt

Du oppretter en annen rolle, Role2, som gir lesetillatelse på folder2. Gjennom arv kan medlemmene lese file21.txt. Medlemmer kan bevege folder2 seg og Files nå den, men de kan ikke se folder1 eller noen av dens barn.

Files/
│
└───folder2 <-- READ
    │   file21.txt

For snarveier er oppførselen litt annerledes. Snarveier til eksterne datakilder oppfører seg på samme måte som mapper. Men snarveier til andre OneLake-lokasjoner har spesialisert oppførsel. Måltillatelsene for snarveien bestemmer tilgang til en OneLake-snarvei. Når man lister snarveier, ringer ikke OneLake for å sjekke måltilgangen. Som et resultat, når du lister en katalog, returnerer OneLake alle interne snarveier uavhengig av din tilgang til målet. Tilgangskontrollen evalueres når du prøver å åpne snarveien, og da ser du bare dataene du har nødvendige tillatelser til.

Shortcuts

OneLake-sikkerhet integreres med snarveier for å sikre data både inne i og utenfor OneLake. Snarveier bruker en av to autentiseringsmoduser:

Passthrough: Snarveien bruker brukerens identitet for å få tilgang til målet. Passthrough er standard for OneLake-til-OneLake snarveier.
Delegert: Snarveien bruker en konfigurert tilkoblingsidentitet eller legitimasjon for å få tilgang til målet. OneLake-til-OneLake-snarveier kan bruke delegert autentisering, og snarveier til eksterne systemer bruker alltid delegert autentisering.

Å lage en snarvei krever tillatelser både på stien der snarveien opprettes og målstien. For kravene for å opprette og få tilgang til hver snarveitype, se OneLake snarveisikkerhet.

OneLake-sikkerhet i gjennomgangssnarveier

Når en bruker får tilgang til data via en passthrough OneLake-til-OneLake-snarvei, bruker OneLake brukerens identitet for å autorisere tilgang til målstien. Brukerens effektive tilgang er begrenset av deres tillatelser både på snarveien og målstien.

Note

Spørringsmotoridentitet og snarveisautentisering er separate innstillinger. En passthrough-snarvei bruker vanligvis brukerens identitet for å få tilgang til målet. Power BI-semantiske modeller som bruker Direct Lake over SQL- og SQL-analyseendepunkter i delegert identitetsmodus, bruker imidlertid eieridentiteten til forbrukervaren eller datakilden. Denne oppførselen endrer ikke snarveiens konfigurerte autentiseringsmodus. For end-to-end brukeridentitetspassthrough, bruk Direct Lake over OneLake eller konfigurer SQL-analyseendepunktet til å bruke brukerens identitetstilgangsmodus.

Du kan ikke definere OneLake-sikkerhetstillatelser direkte på en OneLake-til-OneLake-snarvei. Tillatelser på mappen som inneholder snarveien kombineres med tillatelser på målstien. Hvis målobjektet støtter OneLake-sikkerhet, trenger brukeren tilgang gjennom en OneLake-sikkerhetsrolle. Hvis målobjektet ikke støtter OneLake-sikkerhet, trenger brukeren Fabric ReadAll-tillatelsen på målobjektet. Brukeren trenger ikke Fabric Read-tillatelse på målobjektet kun for å få tilgang til dataene via snarveien.

OneLake-sikkerhet i delegerte snarveier

Delegerte snarveier bruker en konfigurert tilkoblingsidentitet eller legitimasjon i stedet for den anropende brukerens identitet for å få tilgang til målet. OneLake-sikkerheten begrenser hva den ringende brukeren kan få tilgang til gjennom den forbindelsen.

Delegerte snarveier til OneLake

For en delegert OneLake-til-OneLake-snarvei ser den anropende brukeren krysset mellom sin tilgang på snarveien og den konfigurerte tilkoblingsidentitetens tilgang på målstien. Kolonnenivåsikkerhet (CLS) støttes på begge veier. Row-level security (RLS) støttes på målstien, men du kan ikke definere RLS på snarveien.

Delegerte eksterne snarveier

Snarveier til eksterne systemer, som ADLS, Amazon S3 og Dataverse, bruker en konfigurert tilkoblingslegitimasjon for å få tilgang til den eksterne kilden. OneLake-sikkerhet legges på i tillegg til tilgangen gitt av den legitimasjonen.

For eksempel, anta at bruker1 lager en snarvei til et innsjøhus til en mappe i en Amazon S3-bøtte, og bruker2 får tilgang til snarveien fra innsjøhuset. Bruker2 kan kun få tilgang til S3-dataene hvis den konfigurerte S3-tilkoblingsinformasjonen kan få tilgang til kilden, og OneLake-sikkerheten gir bruker2 tillatelse til å få tilgang til snarveien.

Du kan gi OneLake sikkerhetstilgang til hele den eksterne snarveien eller til utvalgte understier. Tillatelser på en mappe arver rekursivt til alle undermappene, inkludert mapper innenfor snarveien. En bruker som når en ekstern snarvei gjennom en annen OneLake-snarvei må fortsatt være autorisert av OneLake-sikkerheten som ble brukt på den opprinnelige eksterne snarveien.

Å få tilgang til en ekstern snarvei via Spark eller et direkte OneLake API-kall krever også Fabric Read-tillatelse på elementet som inneholder den eksterne snarveien. Denne tillatelsen kreves for å løse forbindelsen til det eksterne systemet sikkert.

Evaluer flere sikkerhetsroller i OneLake

En bruker kan tilhøre flere sikkerhetsroller i OneLake. OneLake kombinerer tilgangen gitt av disse rollene til en effektiv rolle, som bestemmer hvilke data brukeren kan få tilgang til. OneLake vurderer den effektive rollen i etapper.

Løs tilgang innenfor hver rolle

OneLake løser først hver rolle uavhengig. Innenfor en rolle kan en bruker kun få tilgang til dataene som er tillatt av alle tre sikkerhetskomponentene:

Objektnivåsikkerhet (OLS) avgjør hvilke tabeller eller mapper rollen kan få tilgang til.
Sikkerhet på radnivå (RLS) begrenser hvilke rader i en gitt tabell rollen kan få tilgang til.
Kolonnenivåsikkerhet (CLS) begrenser hvilke kolonner i en gitt tabell rollen kan få tilgang til.

Fordi alle tre komponentene gjelder, tar OneLake deres skjæringspunkt. For eksempel, hvis Rolle1 gir tilgang til Tabell1 og begrenser rader og kolonner, er den løste tilgangen for Rolle1:

Role1 = R1_OLS ∩ R1_RLS ∩ R1_CLS

Interseksjonssymbolet (∩) betyr at brukeren kun mottar den tilgangen som er tillatt av OLS, RLS og CLS i den rollen.

Kombiner tilgang på tvers av roller

Etter å ha løst hver rolle, kombinerer OneLake rollene ved å bruke en union, eller minst restriktiv, modell. Unionsymbolet (∪) betyr at tilgang gitt av en hvilken som helst rolle blir en del av den effektive rollen. Hvis Rolle1 gir tilgang til TabellA og Rolle2 gir tilgang til TabellB, kan en bruker som tilhører begge rollene få tilgang til begge tabellene.

For to roller er den effektive rollen:

Effective role = Role1 ∪ Role2

Når flere roller gir tilgang til samme tabell, kombineres sikkerhetsregler på radnivå med en OR operatør. For eksempel, predikater som tillater city = 'Redmond' og city = 'New York' kombineres som city = 'Redmond' OR city = 'New York'.

Sikkerhetsregler på kolonnenivå kombineres også som en union, bortsett fra i SQL-analyse-endepunktet. I SQL-analyse-endepunktet bruker CLS en strengere deny-semantik. Hvis en rolle skjuler en kolonne, blokkerer endepunktet tilgangen til den kolonnen. Som et resultat krysser endepunktet CLS-tillatelseslister på tvers av alle brukerens roller i stedet for å kombinere dem som en union.

Important

Behold RLS- og CLS-regler som må gjelde sammen i samme rolle. OneLake støtter ikke en rollekombinasjon der to roller tillater et forskjellig sett med kolonner for en tabell, og begge rollene anvender også RLS på den tabellen. For eksempel kan en bruker ikke tilhøre Rolle1, som tillater kolonnene c1 og c2 og et delsett av rader, og Rolle2, som tillater kolonnene c2 og c3.

Kombiner snarvei og måltilgang

For en snarvei evaluerer OneLake roller ved snarveisstedet og ved snarveimålet separat. Målrollene blir utledede roller på snarveien. OneLake krysser deretter den kombinerte tilgangen fra snarveisrollene med den kombinerte tilgangen fra de utledede målrollene. Dette trinnet forhindrer at tilgangen som arves på snarveisstedet overstyrer begrensninger på målet.

For to snarveisroller og to utledede målroller er den effektive tilgangen:

Effective shortcut access = (ShortcutRole1 ∪ ShortcutRole2) ∩ (InferredRole1 ∪ InferredRole2)

I dette uttrykket ShortcutRole1 er og ShortcutRole2 roller på snarveien. InferredRole1 og InferredRole2 er de tilsvarende utledede rollene fra snarveimålet. Hver rolle løses fra sine OLS-, RLS- og CLS-komponenter før OneLake kombinerer rollene.

Sikkerhetsbegrensninger for OneLake

Hvis du tilordner en OneLake-sikkerhetsrolle til en B2B-gjestebruker, må du konfigurere innstillingene for eksternt samarbeid for B2B i Ekstern ID for Microsoft Entra. Sett innstillingen for gjestebrukertilgang til at gjestbrukere har samme tilgang som medlemmer (mest inkluderende).
Hvis du legger til en distribusjonsliste i en rolle i OneLake-sikkerheten, kan ikke SQL-analyseendepunktet løse medlemmene i listen for å håndheve tilgang. Som et resultat ser det ut til at brukere ikke er medlemmer av rollen når de får tilgang til SQL-analyse-endepunktet. Direct Lake på SQL-semantiske modeller er også underlagt denne begrensningen.
Spark-notatbøker krever at miljøet er 3.5 eller høyere og bruker Fabric runtime 1.3.
Ikke-skjema lakehouses støtter ikke dataforhåndsvisning for RLS- og CLS-sikrede tabeller. Bruk skjema-aktiverte lakehouses med OneLake-sikkerhet.
OneLake-sikkerhet fungerer ikke med Azure Data Share eller Purview Data Share. For mer informasjon, se Azure Data Share.

Tabellen nedenfor viser begrensningene ved OneLake sikkerhetsroller.

Scenario	Limit
Maksimalt antall OneLake-sikkerhetsroller per Stoffelement	250 roller per gjenstand (se merknad)
Maksimalt antall medlemmer per OneLake-sikkerhetsrolle	500 brukere eller brukergrupper per rolle
Maksimalt antall tillatelser per OneLake-sikkerhetsrolle	500 tillatelser per rolle