Hur OneLakes säkerhet kontrollerar dataåtkomst

OneLake-säkerhet är ett rollbaserat system som avgör vem som kan få tillgång till data i OneLake och vilka åtgärder de kan vidta på den datan. Att förstå dataåtkomstkontrollmodellen hjälper dig att ge användare endast den åtkomst de behöver, så att du kan skydda känslig data samtidigt som rätt personer kan arbeta med den.

Den här artikeln förklarar hur OneLakes säkerhetsroller är strukturerade, hur de integreras med arbetsyt- och objektbehörigheter, hur OneLake tillämpar och löser åtkomst till dina data, samt vilka begränsningar du bör ha i åtanke.

OneLake-säkerhetsroller

OneLake-säkerhet använder en rollbaserad åtkomstkontrollmodell (RBAC) för att hantera åtkomst till data i OneLake. I OneLakes säkerhetserfarenhet har varje roll följande komponenter:

Behörigheter: De behörigheter som rollen ger för data, till exempel Läs eller Läs/Skriv.
Typ: Rolltypen. OneLake-säkerhet har endast stöd för Grant-roller, som ger medlemmar åtkomst till de data som ingår i rollen. Den stöder inte Deny-roller som nekar åtkomst.
Data i rollen: Tabellerna, mapparna eller scheman som rollen ger åtkomst till. Du kan också definiera dataåtkomst med säkerhet på rad- och kolumnnivå på tabeller.
Medlemmar i rollen: De Microsoft Entra-identiteter som tilldelats rollen, såsom användare, grupper eller icke-användaridentiteter. Om du tilldelar en Microsoft Entra-grupp ger OneLake-säkerhet rollen till alla gruppens medlemmar.

OneLake-säkerhet använder en deny-by-default-modell, så användare börjar utan tillgång till data om inte en OneLake-säkerhetsroll uttryckligen ger åtkomst. Vissa Fabric-objekt börjar med standardroller som ger användare grundläggande åtkomst baserat på deras arbetsytbehörigheter.

Behörigheter och objekt som stöds

OneLakes säkerhetsroller stödjer följande behörigheter:

Läsa: Ger användaren möjlighet att läsa data från en tabell och visa associerade tabell- och kolumnmetadata. I SQL-termer är denna behörighet ekvivalent med både VIEW_DEFINITION och SELECT. För mer information, se Metadatasäkerhet.
ReadWrite: Ger användaren möjlighet att läsa och skriva data i en tabell eller mapp och se den tillhörande tabell- och kolumnmetadatan. I SQL-termer är denna behörighet ekvivalent med ALTER, DROP, , UPDATEoch INSERT. För mer information, se ReadWrite-behörighet.

Du kan skapa OneLake-säkerhetsroller för följande Fabric-objekt:

Tygföremål	Behörigheter som stöds
Sjöhus	Läs, LäsSkriv
Azure Databricks-speglad katalog	Läs
Speglade databaser	Läs
Spegelvända kataloger	Läs

Läs- och skrivtillstånd

Använd behörigheten ReadWrite för att ge användare med endast läsbehörighet skrivåtkomst till specifika data i ett objekt.

ReadWrite gäller bara för användare med behörigheten Läs för ett objekt, till exempel användare med arbetsyterollen Viewer. Att tilldela ReadWrite till en workspace-administratör, medlem eller bidragsgivare har ingen effekt eftersom dessa workspace-roller redan har skrivbehörighet.

ReadWrite inkluderar alla privilegier som ges av läsbehörigheten, plus att det ger skrivåtkomst till det valda objektet och dess innehåll. Till exempel ger ReadWrite-behörighet på en mapp skrivåtkomst till både mappen och datan i den.

Användare med ReadWrite-behörighet kan utföra följande åtgärder:

Skapa, ta bort eller byt namn på en mapp eller tabell.
Ladda upp eller redigera en fil.
Skapa, ta bort eller byt namn på en genväg.

Användare kan utföra skrivoperationer via Spark-notebooks, OneLake-filutforskaren eller OneLake-API:er. Eftersom Fabric endast stöder skrivningar med endast en motor till data kan användare med ReadWrite-behörighet endast skriva till dessa data via OneLake. Alla frågemotorer fortsätter att konsekvent tillämpa läsoperationer.

OneLake-säkerhetsroller som ger ReadWrite-behörighet kan inte innehålla radnivåsäkerhetsbegränsningar (RLS) eller kolumnnivåsäkerhetsbegränsningar (CLS).

OneLake-säkerhets- och arbetsytebehörigheter

Arbetsyteroller utgör den första säkerhetsgränsen för data i OneLake. De hanterar kontrollplanet – skapar och hanterar Fabric-objekt och behörigheter – och gäller för alla objekt i arbetsytan. För de specifika OneLake-behörigheter som varje arbetsyteroll ger, se Bevilja åtkomst med arbetsyteroller. Om du vill läsa mer om roller för arbetsytor kan du läsa Roller för arbetsytor i Fabric.

Förutom åtkomst till kontrollplanet kan roller för arbetsytor också ge åtkomst till dataobjekt via standardrollerna för OneLake-säkerhet. (Standardroller gäller endast för Viewers, eftersom Admin-, Medlem- och Bidragsrollerna har förhöjd åtkomst via Write-behörigheten.) En standardroll är en vanlig OneLake-säkerhetsroll som Fabric automatiskt skapar med varje nytt objekt. Det ger användare med vissa arbetsytor eller objektbehörigheter en standardnivå för åtkomst till data i objektet. Till exempel har lakehouse-objekt en DefaultReader-roll som låter användare med ReadAll-behörighet se data i lakehouse. Denna standardåtkomst säkerställer att användare som arbetar med ett nyskapat objekt har en grundläggande åtkomstnivå. Alla standardroller använder en virtualiseringsfunktion för medlemmar, vilket innebär att rollens medlemmar är alla användare i arbetsytan som har den behörighet som krävs. Till exempel alla användare med ReadAll-behörighet på lakehouse.

Följande tabell visar standardrollerna. Föremål kan ha specialiserade standardroller som bara gäller för just den föremålstypen.

Tygföremål	Rollnamn	Tillstånd beviljat	Tilldelade medlemmar
Sjöhus	`DefaultReader`	Läs	Alla användare med ReadAll-behörighet
Azure Databricks-speglad katalog	`DefaultReader`	Läs	Alla användare med läsbehörighet
Speglad katalog	`DefaultReader`	Läs	Alla användare med läsbehörighet
Speglad databas	`DefaultReader`	Läs	Alla användare med ReadAll-behörighet

Du kan ändra eller ta bort standardrollen från ett Fabric-objekt för att ändra åtkomst för användarna i den medlemsgruppen.

System- och användaråtkomst till data

OneLakes säkerhet har som standard minsta privilegieåtkomst. Vissa lagringsnivåoperationer kan inte upprätthålla RLS eller CLS, så när en fråga inte kan filtreras säkert blockerar OneLake den helt för att riskera att exponera data som användaren inte får se. Om en fråga filtreras eller blockeras beror på åtkomstvägen – en stödd frågemotor eller direkt användaråtkomst.

För de motorer som stödjer RLS- och CLS-filtrering samt kraven för varje, se Läs data säkrad med OneLake-säkerhet.

Omfattning och tillsyn

Det här avsnittet innehåller information om hur OneLake-säkerhetsroller beviljar åtkomst till specifika omfång, hur åtkomsten fungerar och hur åtkomsten löses mellan flera roller och åtkomsttyper.

Säkerhet på tabellnivå

OneLake representerar alla tabeller som mappar, men ur OneLakes säkerhets- och frågemotorers perspektiv i Fabric är inte alla mappar tabeller. För att vara en giltig tabell måste en mapp uppfylla följande villkor:

Mappen finns i katalogen Tables/ för ett objekt. För schemaaktiverade objekt måste mappen också finnas i en giltig schemamapp.
Mappen innehåller en _delta_log mapp med motsvarande JSON-filer för tabellmetadata.
Mappen innehåller inga barngenvägar.

Om du konfigurerar RLS eller CLS på en tabell nekar OneLake åtkomst när tabellens mapp inte uppfyller dessa kriterier. Utan RLS eller CLS behandlar OneLake en mapp som inte uppfyller dessa kriterier som en mapp och tillämpar mappnivåsäkerhet.

Säkerhet på radnivå och kolumnnivå

Inom en roll kan du begränsa åtkomsten till specifika rader och kolumner i en tabell genom att använda säkerhet på radnivå och kolumnnivå. För mer information om vad varje kontroll gör och hur OneLake upprätthåller det, se Tabell-, kolumn- och radnivåsäkerhet i OneLake. För information om hur RLS och CLS löses när en användare tillhör flera roller, se Utvärdera flera OneLake-säkerhetsroller.

Metadatasäkerhet

OneLake-säkerhetens läsbehörighet ger fullständig åtkomst till data och metadata i en tabell. För användare utan åtkomst till en tabell exponeras aldrig data. Denna regel gäller även för säkerhet på kolumnnivå och en användares möjlighet att se eller inte se en kolumn i den tabellen. Men OneLakes säkerhet garanterar inte att metadata för en tabell inte är tillgänglig. Vissa felmeddelanden och erfarenheter kan visa kolumnnamn.

Ärvning av mappbehörigheter och traversering

Mappbehörigheter påverkar en hierarki i två riktningar:

Arv: Behörigheter som ges på en mapp gäller nedåt för dess filer och undermappar.
Bläddra och lista: När användare har behörighet på ett barnobjekt låter OneLake-säkerheten dem lista och gå igenom dess föräldramappar så att de kan upptäcka och navigera till den data de kan komma åt. Traversal ger inte tillgång till syskonfiler eller mappar.

Betrakta följande hierarki för ett sjöhus i OneLake:

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

Du skapar en roll, Role1, som ger läsbehörighet på subfolder11. Genom arv kan medlemmar i den rollen läsa file111.txt och allt i subfolder111. Medlemmar kan se och ta sig genom folder1 för att komma till subfolder11, men de kan inte se file11.txt eftersom det är en syskonnod till subfolder11, och de kan inte se Tables eftersom det är en syskonnod till Files.

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

Du skapar en annan roll, Role2, som ger läsbehörighet på folder2. Genom arv kan medlemmarna läsa file21.txt. Medlemmar kan traversera folder2 och Files för att nå den, men de kan inte se folder1 eller något av dess barn.

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

För genvägar är beteendet något annorlunda. Genvägar till externa datakällor beter sig på samma sätt som mappar. Men genvägar till andra OneLake-platser har specialiserat beteende. Målbehörigheterna för genvägen avgör åtkomsten till en OneLake-genväg. När genvägar listas gör OneLake inget anrop för att kontrollera åtkomsten till målet. Som ett resultat, när du listar en katalog, returnerar OneLake alla interna genvägar oavsett din åtkomst till målet. Åtkomstkontrollen utvärderar när du försöker öppna genvägen, och då ser du bara den data som du har nödvändiga behörigheter för.

Genvägar

OneLake-säkerhet integreras med genvägar för att säkra data både inom och utanför OneLake. Genvägar använder ett av två autentiseringslägen:

Passthrough: Genvägen använder identiteten för den användare som gör frågan för att komma åt målet. Passthrough är standarden för genvägar från OneLake till OneLake.
Delegerad: Genvägen använder en konfigurerad anslutningsidentitet eller legitimation för att komma åt målet. OneLake-till-OneLake-genvägar kan använda delegerad autentisering, och genvägar till externa system använder alltid delegerad autentisering.

Att skapa en genväg kräver behörigheter både på vägen där genvägen skapas och målvägen. För kraven för att skapa och komma åt varje genvägstyp, se OneLake genvägssäkerhet.

OneLake-säkerhet i vidarekopplingsgenvägar

När en användare får tillgång till data via en genomgångsgenväg mellan OneLake och OneLake använder OneLake den anropande användarens identitet för att auktorisera åtkomst till målvägen. Användarens effektiva åtkomst begränsas av deras behörigheter både på genvägsvägen och målvägen.

Anteckning

Identitet i frågemotorn och autentisering av genvägar är separata inställningar. En passthrough-genväg använder normalt den anropande användarens identitet för att komma åt målet. Power BI-semantiska modeller som däremot använder Direct Lake via SQL- och SQL-analysändpunkter i delegerat identitetsläge använder ägaridentiteten för konsumentobjektet eller datakällan. Detta beteende ändrar inte genvägens konfigurerade autentiseringsläge. För användaridentitetsvidarebefordran från slutpunkt till slutpunkt använder du Direct Lake över OneLake eller konfigurerar SQL-analysslutpunkten för att använda användarens identitetsbaserade åtkomstläge.

Du kan inte definiera OneLake-säkerhetsbehörigheter direkt via en genväg från OneLake till OneLake. Behörigheter på mappen som innehåller genvägen kombineras med behörigheter på målvägen. Om målobjektet stödjer OneLake-säkerhet behöver användaren åtkomst via en OneLake-säkerhetsroll. Om målobjektet inte stöder OneLake-säkerhet behöver användaren Fabric ReadAll-behörigheten på målobjektet. Användaren behöver inte Fabric Read-behörighet på målobjektet enbart för att komma åt dess data via genvägen.

OneLake-säkerhet i delegerade genvägar

Delegerade genvägar använder en konfigurerad anslutningsidentitet eller inloggningsuppgifter istället för den anropande användarens identitet för att komma åt målet. OneLakes säkerhet begränsar vad den uppringande användaren kan komma åt via den anslutningen.

Delegerade OneLake-genvägar

För en delegerad OneLake-till-OneLake-genväg ser den anropande användaren korsningen mellan sin åtkomst på genvägsvägen och den konfigurerade anslutningsidentitetens åtkomst på målvägen. Kolumnnivåsäkerhet (CLS) stöds på båda vägarna. Row-level security (RLS) stöds på målsökvägen, men du kan inte definiera RLS på genvägssökvägen.

Delegerade externa genvägar

Genvägar till externa system, såsom ADLS, Amazon S3 och Dataverse, använder en konfigurerad anslutningslegitimation för att komma åt den externa källan. OneLake-säkerhet tillämpas utöver den åtkomst som beviljas av den autentiseringsuppgiften.

Till exempel, anta att användare1 skapar en sjöhusgenväg till en mapp i en Amazon S3-hink, och användar2 får tillgång till genvägen från sjöhuset. User2 kan endast komma åt S3-data om den konfigurerade S3-anslutningslegitimationen kan komma åt källan och OneLake-säkerheten ger user2 tillstånd att komma åt genvägsvägen.

Du kan ge OneLake säkerhetsåtkomst till hela den externa genvägen eller till utvalda delvägar. Behörigheter på en mapp ärver rekursivt till alla dess undermappar, inklusive mappar inom genvägen. En användare som når en extern genväg via en annan OneLake-genväg måste fortfarande vara auktoriserad av den OneLake-säkerhet som appliceras på den ursprungliga externa genvägen.

Att komma åt en extern genväg via Spark eller ett direkt OneLake API-anrop kräver också Fabric Read-behörighet på det objekt som innehåller den externa genvägen. Denna behörighet krävs för att säkert lösa anslutningen till det externa systemet.

Utvärdera flera OneLake-säkerhetsroller

En användare kan tillhöra flera säkerhetsroller i OneLake. OneLake kombinerar åtkomsten som ges av dessa roller till en effektiv roll, som bestämmer vilken data användaren kan komma åt. OneLake utvärderar den gällande rollen stegvis.

Lös åtkomst inom varje roll

OneLake löser först varje roll oberoende. Inom en roll kan en användare endast komma åt den data som tillåts av alla tre säkerhetskomponenter:

Objektnivåsäkerhet (OLS) avgör vilka tabeller eller mappar rollen kan komma åt.
Säkerheten på radnivå (RLS) begränsar vilka rader i en given tabell rollen kan komma åt.
Kolumnnivåsäkerhet (CLS) begränsar vilka kolumner i en given tabell rollen kan komma åt.

Eftersom alla tre komponenterna gäller tar OneLake deras korsning. Till exempel, om Roll1 ger tillgång till Tabell1 och begränsar dess rader och kolumner, är den lösta åtkomsten för Roll1:

Role1 = R1_OLS ∩ R1_RLS ∩ R1_CLS

Intersektionssymbolen (∩) betyder att användaren endast får den åtkomst som tillåts av OLS, RLS och CLS i den rollen.

Kombinera åtkomst mellan roller

När varje roll har fastställts kombinerar OneLake rollerna samman med hjälp av en unionsmodell, eller den minst restriktiva modellen. Unionsymbolen (∪) betyder att åtkomst som ges av vilken roll som helst blir en del av den effektiva rollen. Om Roll1 ger tillgång till TabellA och Roll2 ger tillgång till TabellB, kan en användare som tillhör båda rollerna komma åt båda tabellerna.

För två roller är den effektiva rollen:

Effective role = Role1 ∪ Role2

När flera roller ger tillgång till samma tabell kombineras säkerhetsregler på radnivå med en OR operator. Till exempel predikat som tillåter både city = 'Redmond' och city = 'New York' kombineras till city = 'Redmond' OR city = 'New York'.

Säkerhetsregler på kolumnnivå kombineras också som en union, förutom i SQL-analysändpunkten. I SQL-analysändpunkten använder CLS en striktare deny-semantik. Om någon roll döljer en kolumn blockerar endpointen åtkomst till den kolumnen. Som ett resultat skär slutpunkten CLS-tillåtningslistor över alla användarens roller istället för att kombinera dem som en union.

Viktigt!

Behåll RLS- och CLS-regler som måste gälla tillsammans i samma roll. OneLake stöder inte en rollkombination där två roller tillåter olika kolumner för en tabell och båda rollerna även tillämpar RLS på den tabellen. Till exempel kan en användare inte tillhöra Role1, som tillåter kolumnerna c1 och c2 samt en delmängd av rader, och Role2, som tillåter kolumnerna c2 och c3.

Kombinera genväg och åtkomst till målet

För en genväg utvärderar OneLake roller vid genvägsplatsen och vid genvägsmålet separat. Målrollerna blir antydda roller vid genvägsplatsen. OneLake beräknar sedan snittet mellan den kombinerade åtkomsten från genvägsrollerna och den kombinerade åtkomsten från de härledda målrollerna. Detta steg förhindrar att åtkomst som ärvs vid genvägsplatsen åsidosätter begränsningar på målet.

För två genvägsroller och två härledda målroller är den faktiska åtkomsten:

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

I detta uttryck är ShortcutRole1 och ShortcutRole2 roller på genvägens plats. InferredRole1 och InferredRole2 är motsvarande härledda roller från genvägsmålet. Varje roll fastställs utifrån sina OLS-, RLS- och CLS-komponenter innan OneLake kombinerar rollerna.

Säkerhetsbegränsningar för OneLake

Om du tilldelar en OneLake-säkerhetsroll till en B2B-gästanvändare måste du konfigurera dina externa samarbetsinställningar för B2B i Microsoft Entra External ID. Ställ in inställningen för gästanvändaråtkomst till att gästanvändare har samma tillgång som medlemmar (mest inkluderande).
Om du lägger till en distributionslista i en roll i OneLake-säkerhet går det inte för SQL-analysslutpunkten att identifiera medlemmarna i listan för att tillämpa åtkomst. Som ett resultat verkar användarna inte vara medlemmar i rollen när de får åtkomst till slutpunkten för SQL-analys. Direct Lake på SQL-semantiska modeller omfattas också av denna begränsning.
Spark-notebooks kräver att miljön är 3.5 eller högre och att den använder Fabric runtime 1.3.
Lakehouses utan schema stöder inte förhandsgranskning av data för tabeller som skyddas med RLS och CLS. Använd schemastödda lakehouse-lösningar med OneLake-säkerhet.
OneLake-säkerhet fungerar inte med Azure Data Share eller Purview Data Share. Mer information finns i Azure Data Share.

Följande tabell listar begränsningarna för OneLakes säkerhetsroller.

Scenarium	Gräns
Maximalt antal OneLake-säkerhetsroller per Fabric-komponent	250 roller per objekt (se anmärkning)
Maximalt antal medlemmar per OneLake-säkerhetsroll	500 användare eller användargrupper per roll
Maximalt antal behörigheter per OneLake-säkerhetsroll	500 tillstånd per roll