Hvordan OneLake-sikkerhed kontrollerer dataadgang

OneLake-sikkerhed er et rollebaseret system, der bestemmer, hvem der kan få adgang til data i OneLake, og hvilke handlinger de kan tage på disse data. At forstå dataadgangskontrolmodellen hjælper dig med kun at give brugerne den adgang, de har brug for, så du kan beskytte følsomme data, samtidig med at de rette personer kan arbejde med dem.

Denne artikel forklarer, hvordan OneLake-sikkerhedsroller er struktureret, hvordan de integrerer med arbejdsområde- og artikeltilladelser, hvordan OneLake anvender og løser adgang til dine data, samt de grænser, du skal være opmærksom på.

OneLake-sikkerhedsroller

OneLake-sikkerhed bruger en rollebaseret adgangskontrol (RBAC)-model til at administrere adgang til data i OneLake. I OneLakes sikkerhedserfaring har hver rolle følgende komponenter:

Tilladelser: De tilladelser, rollen giver på dataene, såsom Læs eller Læs Skriv.
Type: Rolletypen. OneLake-sikkerhed understøtter kun Grant-roller, som giver medlemmer adgang til dataene i rollen. Den understøtter ikke Afslag på roller, der fjerner adgang.
Data i rollen: De tabeller, mapper eller skemaer, som rollen giver adgang til. Du kan også definere dataadgang med række- og kolonne-sikkerhed på tabeller.
Medlemmer i rollen: De Microsoft Entra-identiteter, der er tildelt rollen, såsom brugere, grupper eller ikke-brugeridentiteter. Hvis du tildeler en Microsoft Entra-gruppe, giver OneLake-sikkerhed rollen til alle gruppens medlemmer.

OneLake-sikkerhed bruger en deny-by-default-model, så brugere starter uden adgang til data, medmindre en OneLake-sikkerhedsrolle eksplicit giver adgang. Nogle Fabric-elementer starter med standardroller, der giver brugerne grundlæggende adgang baseret på deres arbejdsområde-tilladelser.

Tilladelser og understøttede elementer

OneLake-sikkerhedsroller understøtter følgende tilladelser:

Læse: Giver brugeren mulighed for at læse data fra en tabel og få vist de tilknyttede tabel- og kolonnemetadata. I SQL-termer er denne tilladelse ækvivalent med både VIEW_DEFINITION og SELECT. For mere information, se Metadata-sikkerhed.
ReadWrite: Giver brugeren mulighed for at læse og skrive data i en tabel eller mappe og se den tilknyttede tabel og kolonnemetadata. I SQL-termer svarer denne tilladelse til ALTER, DROP, UPDATE, og INSERT. For mere information, se ReadWrite-tilladelse.

Du kan oprette OneLake-sikkerhedsroller for følgende Fabric-elementer:

Stof vare	Understøttede tilladelser
Lakehouse	Læs, Læs Skriv
Azure Databricks mirrored catalog	Read
Spejlede databaser	Read
Spejlede kataloger	Read

ReadWrite-tilladelse

Brug ReadWrite-tilladelsen til at give skriveadgang, der kun er læsebrugere, til specifikke data i et element.

ReadWrite gælder kun for brugere med læsetilladelse på et element, såsom brugere med Viewer-arbejdsområderollen. At tildele ReadWrite til en workspace-administrator, medlem eller bidragyder har ingen effekt, fordi disse workspace-roller allerede har skriveadgang.

ReadWrite inkluderer alle privilegier, der gives af læsetilladelsen, og giver desuden skriveadgang til det valgte objekt og dets indhold. For eksempel giver ReadWrite-tilladelse på en mappe skriveadgang til både mappen og dataene i den.

Brugere med ReadWrite-tilladelse kan udføre følgende handlinger:

Oprethold, slet eller omdøb en mappe eller tabel.
Upload eller rediger en fil.
Oprette, slette eller omdøb en genvej.

Brugere kan udføre skriveoperationer via Spark-notebooks, OneLake-filudforskeren eller OneLake API'er. Da Fabric kun understøtter enkelt-engine skrivning til data, kan brugere med ReadWrite-tilladelse kun skrive til disse data via OneLake. Alle forespørgselsmotorer fortsætter med at håndhæve læseoperationer konsekvent.

OneLake-sikkerhedsroller, der giver ReadWrite-tilladelse, må ikke indeholde række-niveau sikkerhed (RLS) eller kolonne-niveau sikkerheds (CLS) begrænsninger.

OneLake-sikkerhed og tilladelser til arbejdsområder

Workspace-roller er den første sikkerhedsgrænse for data i OneLake. De administrerer kontrolplanet – opretter og administrerer Fabric-elementer og tilladelser – og gælder for alle elementer i arbejdsområdet. For de specifikke OneLake-tilladelser, som hver arbejdsområderolle giver, se Giv adgang med arbejdsområderoller. For at lære mere om arbejdsområder, se Roller i arbejdsområder i Fabric.

Ud over kontrolplan-adgang kan arbejdsområders også give adgang til dataelementer via OneLake sikkerhedsstandardroller. (Standardroller gælder kun for Viewers, fordi Admin-, Medlem- og Bidragyderrollerne har forhøjet adgang via Write-tilladelsen.) En standardrolle er en normal OneLake-sikkerhedsrolle, som Fabric automatisk opretter ved hvert nyt element. Det giver brugere med bestemte arbejdsområde- eller elementtilladelser et standardadgangsniveau til data i det pågældende element. For eksempel har lakehouse-elementer en DefaultReader-rolle, der lader brugere med ReadAll-tilladelsen se data i lakehouset. Denne standardadgang sikrer, at brugere, der arbejder med et nyoprettet element, har et grundlæggende adgangsniveau. Alle standardroller bruger en medlemvirtualiseringsfunktion, så medlemmerne af rollen er brugere i det pågældende arbejdsområde med den nødvendige tilladelse. For eksempel alle brugere med ReadAll-tilladelse på søhuset.

Følgende tabel viser de standard standardroller. Genstande kan have specialiserede standardroller, der kun gælder for den pågældende genstandstype.

Stof vare	Rollenavn	Tilladelse givet	Tildelte medlemmer
Lakehouse	`DefaultReader`	Read	Alle brugere med tilladelsen ReadAll
Azure Databricks mirrored catalog	`DefaultReader`	Read	Alle brugere med læsetilladelse
Spejlet katalog	`DefaultReader`	Read	Alle brugere med læsetilladelse
Spejlet database	`DefaultReader`	Read	Alle brugere med tilladelsen ReadAll

Du kan ændre eller fjerne standardrollen fra et Fabric-element for at ændre adgangen for brugerne i den medlemsgruppe.

Motor og brugeradgang til data

OneLake-sikkerheden er som standard til mindst privilegeret adgang. Nogle lagringsoperationer kan ikke håndhæve RLS eller CLS, så når en forespørgsel ikke kan filtreres sikkert, blokerer OneLake den helt i stedet for at risikere at eksponere data, som brugeren ikke har lov til at se. Om en forespørgsel filtreres eller blokeres afhænger af adgangsstien – en understøttet forespørgselsmotor eller direkte brugeradgang.

For de motorer, der understøtter RLS- og CLS-filtrering samt kravene til hver, se Læs data sikret med OneLake sikkerhed.

Omfang og håndhævelse

Dette afsnit indeholder oplysninger om, hvordan OneLake-sikkerhedsroller giver adgang til bestemte områder, hvordan denne adgang fungerer, og hvordan adgang løses på tværs af flere roller og adgangstyper.

Sikkerhed på tabelniveau

OneLake repræsenterer alle tabeller som mapper, men set fra OneLakes sikkerheds- og forespørgselsmotorers perspektiv i Fabric er ikke alle mapper tabeller. For at være en gyldig tabel skal en mappe opfylde følgende betingelser:

Mappen findes i Tables/ mappen for et element. For skemaaktiverede elementer skal mappen også være i en gyldig skemamappe.
Mappen indeholder en _delta_log mappe med tilsvarende JSON-filer til tabelmetadata.
Mappen indeholder ingen genveje til børn.

Hvis du konfigurerer RLS eller CLS på en tabel, nægter OneLake adgang, når tabellens mappe ikke opfylder disse kriterier. Uden RLS eller CLS behandler OneLake en mappe, der ikke opfylder disse kriterier, som en mappe og anvender mappe-niveau sikkerhed.

Sikkerhed på række- og søjleniveau

Inden for en rolle kan du begrænse adgangen til specifikke rækker og kolonner i en tabel ved at bruge sikkerhed på række- og søjleniveau. For mere information om, hvad hver kontrol gør, og hvordan OneLake håndhæver den, se tabel-, kolonne- og række-niveau sikkerhed i OneLake. For information om, hvordan RLS og CLS afgøres, når en bruger tilhører flere roller, se Evaluate multiple OneLake security roles.

Sikkerhed for metadata

OneLake securitys læsetilladelse giver fuld adgang til data og metadata i en tabel. For brugere uden adgang til en tabel bliver dataene aldrig eksponeret. Denne regel gælder også for sikkerhed på kolonneniveau og en brugers mulighed for at se eller ikke se en kolonne i den tabel. Men OneLakes sikkerhed garanterer ikke, at metadata for en tabel ikke er tilgængelig. Visse fejlmeddelelser og oplevelser kan vise kolonnenavne.

Mappetilladelsesarv og gennemgang

Mappetilladelser påvirker et hierarki i to retninger:

Arv: Tilladelser givet på en mappe gælder nedad for dens filer og undermapper.
Traversering og listning: Når brugere har tilladelse til et underordnet element, lader OneLake-sikkerhed dem liste og gennemgå dets overordnede mapper, så de kan opdage og navigere til de data, de kan tilgå. Gennemgang giver ikke adgang til søskendefiler eller -mapper.

Overvej følgende hierarki for et søhus i OneLake:

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

Du opretter en rolle, Role1, som giver læsetilladelse på subfolder11. Gennem arv kan medlemmer af den rolle læse file111.txt og alt i subfolder111. Medlemmer kan se og bevæge folder1 sig for at nå subfolder11, men de kan ikke se, file11.txt fordi det er en søskende til subfolder11 , og de kan ikke se, Tables fordi det er en søskende af Files.

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

Du opretter en anden rolle, Role2, som giver læsetilladelse på folder2. Gennem arv kan medlemmer læse file21.txt. Medlemmer kan bevæge folder2 sig rundt og Files nå den, men de kan ikke se folder1 eller nogen af dens børn.

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

For genveje er adfærden en smule anderledes. Genveje til eksterne datakilder opfører sig på samme måde som mapper. Men genveje til andre OneLake-lokationer har specialiseret adfærd. Genvejens destinationstilladelser bestemmer adgangen til en OneLake-genvej. Når genveje oplistes, ringer OneLake ikke til at tjekke måladgangen. Som følge heraf returnerer OneLake alle interne genveje, når du lister en mappe, uanset din adgang til målet. Adgangskontrollen evalueres, når du prøver at åbne genvejen, og så ser du kun de data, du har de nødvendige tilladelser til at se.

Shortcuts

OneLake-sikkerhed integreres med genveje til at sikre data både inden for og uden for OneLake. Genveje bruger en af to autentificeringstilstande:

Passthrough: Genvejen bruger brugerens identitet til at få adgang til målet. Passthrough er standarden for genveje mellem OneLake og OneLake.
Delegeret: Genvejen bruger en konfigureret forbindelsesidentitet eller legitimationsoplysninger til at få adgang til målet. OneLake-til-OneLake genveje kan bruge delegeret autentificering, og genveje til eksterne systemer bruger altid delegeret autentificering.

Oprettelse af en genvej kræver tilladelser både på stien, hvor genvejen oprettes, og på målstien. For kravene til at oprette og tilgå hver genvejstype, se OneLake genvejssikkerhed.

OneLake-sikkerhed i passthrough-genveje

Når en bruger tilgår data via en genvej til at pass-through OneLake til OneLake, bruger OneLake den kaldende brugers identitet til at autorisere adgang til målstien. Brugerens effektive adgang er begrænset af deres tilladelser på både genvejsstien og målstien.

Note

Forespørgselsmotorens identitet og genvejsgodkendelse er separate indstillinger. En passthrough-genvej bruger normalt den kaldende brugers identitet til at få adgang til målet. Dog bruger Power BI semantiske modeller, der bruger Direct Lake over SQL- og SQL-analyseendepunkter i delegeret identitetstilstand, ejeridentiteten for forbrugerproduktet eller datakilden. Denne adfærd ændrer ikke genvejens konfigurerede autentificeringstilstand. For end-to-end brugeridentitetspassthrough skal du bruge Direct Lake over OneLake eller konfigurere SQL-analyseendpointet til at bruge brugerens identitetsadgangstilstand.

Du kan ikke definere OneLake-sikkerhedstilladelser direkte på en OneLake-til-OneLake genvej. Tilladelser på mappen, der indeholder genvejen, kombineres med tilladelser på målstien. Hvis målobjektet understøtter OneLake-sikkerhed, har brugeren brug for adgang gennem en OneLake-sikkerhedsrolle. Hvis målobjektet ikke understøtter OneLake-sikkerhed, har brugeren brug for Fabric ReadAll-tilladelsen på målobjektet. Brugeren behøver ikke Fabric Read-tilladelse på målobjektet alene for at få adgang til dets data via genvejen.

OneLake-sikkerhed i delegerede genveje

Delegerede genveje bruger en konfigureret forbindelsesidentitet eller legitimationsoplysninger i stedet for den kaldende brugers identitet til at få adgang til målet. OneLakes sikkerhed begrænser, hvad den kaldende bruger kan få adgang til via den forbindelse.

Delegerede OneLake-genveje

For en delegeret OneLake-til-OneLake-genvej ser den kaldende bruger krydset mellem deres adgang på genvejsstien og den konfigurerede forbindelsesidentitets adgang på målstien. Kolonne-niveau sikkerhed (CLS) understøttes på begge veje. Række-niveau sikkerhed (RLS) understøttes på målstien, men du kan ikke definere RLS på genvejsstien.

Delegerede eksterne genveje

Genveje til eksterne systemer, såsom ADLS, Amazon S3 og Dataverse, bruger en konfigureret forbindelseslegitimation til at få adgang til den eksterne kilde. OneLake-sikkerhed anvendes oven i den adgang, som denne legitimation giver.

For eksempel, antag at bruger1 opretter en genvej til et lakehouse til en mappe i en Amazon S3-bucket, og bruger2 får adgang til genvejen fra lakehouse. Bruger2 kan kun få adgang til S3-dataene, hvis den konfigurerede S3-forbindelseslegitimation kan få adgang til kilden, og OneLake-sikkerhed giver bruger2 tilladelse til at få adgang til genvejsstien.

Du kan give OneLake sikkerhedsadgang til hele den eksterne genvej eller til udvalgte underveje. Tilladelser på en mappe arver rekursivt til alle dens undermapper, inklusive mapper inden for genvejen. En bruger, der når en ekstern genvej gennem en anden OneLake-genvej, skal stadig være autoriseret af den OneLake-sikkerhed, der er anvendt på den oprindelige eksterne genvej.

Adgang til en ekstern genvej via Spark eller et direkte OneLake API-kald kræver også Fabric Read-tilladelse på det element, der indeholder den eksterne genvej. Denne tilladelse er nødvendig for sikkert at løse forbindelsen til det eksterne system.

Evaluer flere OneLake-sikkerhedsroller

En bruger kan tilhøre flere OneLake-sikkerhedsroller. OneLake kombinerer den adgang, som disse roller giver, til en effektiv rolle, som bestemmer de data, brugeren kan få adgang til. OneLake vurderer den effektive rolle i etaper.

Løs adgang inden for hver rolle

OneLake løser først hver rolle uafhængigt. Inden for en rolle kan en bruger kun få adgang til de data, som alle tre sikkerhedskomponenter tillader:

Objektniveau-sikkerhed (OLS) bestemmer, hvilke tabeller eller mapper rollen kan tilgå.
Række-niveau sikkerhed (RLS) begrænser, hvilke rækker i en given tabel rollen kan få adgang til.
Kolonne-niveau sikkerhed (CLS) begrænser, hvilke kolonner i en given tabel rollen kan tilgå.

Fordi alle tre komponenter gælder, tager OneLake deres kryds. For eksempel, hvis Rolle1 giver adgang til Tabel1 og begrænser dens rækker og kolonner, er den løste adgang for Rolle1:

Role1 = R1_OLS ∩ R1_RLS ∩ R1_CLS

Skæringssymbolet (∩) betyder, at brugeren kun modtager den adgang, som OLS, RLS og CLS tillader i den rolle.

Kombiner adgang på tværs af roller

Efter at have løst hver rolle, kombinerer OneLake rollerne ved at bruge en union- eller mindst restriktiv model. Unionsymbolet (∪) betyder, at adgang, der gives af enhver rolle, bliver en del af den effektive rolle. Hvis Rolle1 giver adgang til TableA og Role2 giver adgang til TableB, kan en bruger, der tilhører begge roller, få adgang til begge tabeller.

For to roller er den effektive rolle:

Effective role = Role1 ∪ Role2

Når flere roller giver adgang til den samme tabel, kombineres sikkerhedsregler på rækkeniveau med en OR operator. For eksempel prædikater, der tillader city = 'Redmond' og city = 'New York' kombineres som city = 'Redmond' OR city = 'New York'.

Sikkerhedsregler på kolonneniveau kombineres også som en union, undtagen i SQL-analyse-endpointet. I SQL-analyse-endpointet bruger CLS en strengere deny-semantik. Hvis en rolle skjuler en kolonne, blokerer endpointet adgangen til den kolonne. Som følge heraf krydser endpointet CLS-tilladte lister på tværs af alle brugerens roller i stedet for at kombinere dem som en union.

Important

Behold RLS- og CLS-regler, der skal gælde sammen i samme rolle. OneLake understøtter ikke en rollekombination, hvor to roller tillader et forskelligt sæt kolonner til en tabel, og begge roller anvender også RLS på den tabel. For eksempel kan en bruger ikke tilhøre Rolle1, som tillader kolonnerne c1 og c2 samt et delmængde af rækker, og Rolle2, som tillader kolonnerne c2 og c3.

Kombiner genvej og måladgang

For en genvej vurderer OneLake rollerne ved genvejsstedet og ved genvejsmålet separat. Målrollerne bliver til udledte roller på genvejsstedet. OneLake krydser derefter den kombinerede adgang fra genvejsrollerne med den samlede adgang fra de udledte målroller. Dette trin forhindrer adgang, der arves på genvejsstedet, i at tilsidesætte begrænsninger på målet.

For to genvejsroller og to udledte målroller er den effektive adgang:

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

I dette udtryk ShortcutRole1 er og ShortcutRole2 roller ved genvejsplaceringen. InferredRole1 og InferredRole2 er de tilsvarende udledte roller fra genvejsmålet. Hver rolle løses ud fra sine OLS-, RLS- og CLS-komponenter, før OneLake kombinerer rollerne.

Begrænsninger for OneLake-sikkerhed

Hvis du tildeler en OneLake-sikkerhedsrolle til en B2B-gæstebruger, skal du konfigurere indstillingerne for eksternt samarbejde for B2B i Microsoft Entra eksternt id. Sæt indstillingen for gæstebrugeradgang, så gæstebrugere har samme adgang som medlemmer (mest inkluderende).
Hvis du tilføjer en distributionsliste til en rolle i OneLake-sikkerhed, kan SQL-analyse-endpointet ikke løse medlemmerne af listen for at håndhæve adgang. Som følge heraf ser det ud til, at brugerne ikke er medlemmer af rollen, når de tilgår SQL-analyse-endpointet. Direct Lake på SQL semantiske modeller er også underlagt denne begrænsning.
Spark-notebooks kræver, at miljøet er 3,5 eller højere og bruger Fabric runtime 1.3.
Ikke-skema lakehouses understøtter ikke dataforhåndsvisning for RLS- og CLS-sikrede tabeller. Brug skema-aktiverede lakehouses med OneLake-sikkerhed.
OneLake-sikkerhed fungerer ikke med Azure Data Share eller Purview Data Share. For mere information, se Azure Data Share.

Følgende tabel viser begrænsningerne ved OneLakes sikkerhedsroller.

Scenario	Limit
Maksimalt antal OneLake-sikkerhedsroller pr. Stofelement	250 roller pr. punkt (se note)
Maksimalt antal medlemmer pr. OneLake-sikkerhedsrolle	500 brugere eller brugergrupper pr. rolle
Maksimalt antal tilladelser pr. OneLake-sikkerhedsrolle	500 tilladelser pr. rolle