OneLake-säkerhetsåtkomstkontrollmodell (förhandsversion)

2025-09-08

Det här dokumentet innehåller en detaljerad guide till hur onelake-säkerhetsåtkomstkontrollmodellen fungerar. Den innehåller information om hur rollerna är strukturerade, hur de tillämpas på data och vad integreringen är med andra strukturer i Microsoft Fabric.

OneLake-säkerhetsroller

OneLake-säkerhet använder en rollbaserad åtkomstkontrollmodell (RBAC) för att hantera åtkomst till data i OneLake. Varje roll består av flera viktiga komponenter.

Typ: Om rollen ger åtkomst (GRANT) eller tar bort åtkomst (DENY). Endast roller av TYPEN GRANT stöds.
Tillåtelse: Den specifika åtgärd eller de åtgärder som beviljas eller nekas.
Omfattning: OneLake-objekten som har behörigheten. Objekt är tabeller, mappar eller scheman.
Medlemmar: Alla Microsoft Entra-identiteter som har tilldelats rollen, till exempel användare, grupper eller icke-användare. Rollen beviljas alla medlemmar i en Microsoft Entra-grupp.

Genom att tilldela en medlem till en roll omfattas användaren sedan av de associerade behörigheterna för rollens omfång. Eftersom OneLake-säkerhet använder en neka-som-standard-modell börjar alla användare utan åtkomst till data om de inte uttryckligen beviljas av en OneLake-säkerhetsroll.

Behörigheter och objekt som stöds

OneLake-säkerhetsroller har stöd för följande behörighet:

Läsa: Ger användaren möjlighet att läsa data från en tabell och visa associerade tabell- och kolumnmetadata. I SQL-termer motsvarar den här behörigheten både VIEW_DEFINITION och SELECT. Mer information finns i metadatasäkerhet.

Med OneLake-säkerhet kan användare endast definiera dataåtkomstroller för följande infrastrukturobjekt.

Tygföremål	Läge	Behörigheter som stöds
Sjöhus	Public Preview	Läs, Skriv upp
Azure Databricks speglad katalog	Public Preview	Läs

OneLake-säkerhets- och arbetsytebehörigheter

Arbetsytebehörigheter är den första säkerhetsgränsen för data i OneLake. Varje arbetsyta representerar en enda domän eller ett projektområde där team kan samarbeta om data. Du hanterar säkerhet i arbetsytan genom Fabric-arbetsyteroller. Lär dig mer om Fabric rollbaserad åtkomstkontroll (RBAC): Arbetsyteroller

Infrastrukturarbetsyteroller ger behörigheter som gäller för alla objekt på arbetsytan. I följande tabell beskrivs de grundläggande behörigheter som tillåts av arbetsyteroller.

Behörighet	Administratör	Medlem	Deltagare	Visare
Visa filer i OneLake	Alltid* Ja	Alltid* Ja	Alltid* Ja	Nej som standard. Använd OneLake-säkerhet för att bevilja åtkomsten.
Skriva filer i OneLake	Alltid* Ja	Alltid* Ja	Alltid* Ja	Nej
Kan redigera OneLake-säkerhetsroller	Alltid* Ja	Alltid* Ja	Nej	Nej

*Eftersom arbetsyteadministratörs-, medlems- och deltagarroller automatiskt beviljar Skrivbehörighet till OneLake åsidosätter de alla Läsbehörigheter för OneLake-säkerhet.

Arbetsyteroller hanterar åtkomsten till kontrollplanets data, vilket innebär interaktioner med att skapa och hantera Infrastrukturartefakter och behörigheter. Dessutom ger arbetsyteroller också standardåtkomstnivåer för dataobjekt med hjälp av OneLake-säkerhetsstandardroller. (Observera att standardroller endast gäller för tittare eftersom administratör, medlem och deltagare har förhöjd åtkomst via skrivbehörigheten) En standardroll är en normal OneLake-säkerhetsroll som skapas automatiskt 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. Detta säkerställer att användare som har åtkomst till ett nyligen skapat objekt har en grundläggande åtkomstnivå. Alla standardroller använder en funktion för medlemsvirtualisering, så att medlemmarna i rollen är alla användare på den arbetsytan med nödvändig behörighet. Till exempel alla användare med ReadAll-behörighet på Lakehouse. I följande tabell visas standardrollerna. Objekt kan ha särskilda standardroller som endast gäller för den objekttypen.

Tygföremål	Rollnamn	Behörighet	Mappar som ingår	Tilldelade medlemmar
Sjöhus	`DefaultReader`	Läs	Alla mappar under `Tables/` och `Files/`	Alla användare med ReadAll-behörighet
Sjöhus	`DefaultReadWriter`	Läs	Alla mappar	Alla användare med skrivbehörighet

Anteckning

Om du vill begränsa åtkomsten till specifika användare eller specifika mappar ändrar du standardrollen eller tar bort den och skapar en ny anpassad roll.

OneLake-säkerhets- och objektbehörigheter

Inom en arbetsyta kan Fabric-objekt ha behörigheter som konfigureras separat från arbetsyterollerna. Du kan konfigurera behörigheter antingen genom att dela ett objekt eller genom att hantera behörigheterna för ett objekt. Följande behörigheter avgör en användares möjlighet att utföra åtgärder på data i OneLake. Mer information om objektdelning finns i Så här fungerar Lakehouse-delning

Behörighet	Kan visa filer i OneLake?	Kan skriva filer i OneLake?	Kan du läsa data via SQL-analysslutpunkten?
Läs	Nej som standard. Använd OneLake-säkerhet för att bevilja åtkomst.	Nej	Nej
LäsAlla	Ja via Rollen DefaultReader. Använd OneLake-säkerhet för att begränsa åtkomsten.	Nej	Nej*
Skriv	Ja	Ja	Ja
Utför, Dela igen, Visa resultat, Visa loggar	N/A – kan inte beviljas på egen hand	N/A – kan inte beviljas på egen hand	N/A – kan inte beviljas på egen hand

*Beror på SQL-analysslutpunktsläget.

Skapa roller

Du kan definiera och hantera OneLake-säkerhetsroller via dina inställningar för åtkomst till lakehouse-data.

Läs mer i Kom igång med dataåtkomstroller.

Motor- och användaråtkomst till data

Dataåtkomst till OneLake sker på ett av två sätt:

Via en Infrastruktur-frågemotor eller
Via användaråtkomst (Frågor från icke-Fabric-motorer betraktas som användaråtkomst)

OneLake-säkerhet säkerställer att data alltid hålls säkra. Eftersom vissa OneLake-säkerhetsfunktioner som säkerhet på rad- och kolumnnivå inte stöds av åtgärder på lagringsnivå kan inte alla typer av åtkomst till data på rad- eller kolumnnivå tillåtas. Detta garanterar att användarna inte kan se rader eller kolumner som de inte har behörighet till. Microsoft Fabric-motorer har aktiverats för att tillämpa säkerhetsfiltrering på rad- och kolumnnivå på datafrågor. Det innebär att när en användare frågar efter data i ett lakehouse eller annat objekt med OneLake security RLS eller CLS på den, tas de resultat som användaren ser bort de dolda raderna och kolumnerna. För användaråtkomst till data i OneLake med RLS eller CLS på blockeras frågan om användaren som begär åtkomst inte får se alla rader eller kolumner i tabellen.

Tabellen nedan beskriver vilka Microsoft Fabric-motorer som stöder RLS- och CLS-filtrering.

Motor	RLS/CLS-filtrering	Status
Sjöhus	Ja	Offentlig förhandsversion
Spark-anteckningsböcker	Ja	Offentlig förhandsversion
SQL Analytics-slutpunkt i "användarens identitetsläge"	Ja	Offentlig förhandsversion
Semantiska modeller med DirectLake i OneLake-läge	Ja	Offentlig förhandsversion
Eventhouse	Nej	Planerat
Externa tabeller för informationslager	Nej	Planerat

Information om OneLake-säkerhetsåtkomstkontrollmodell

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å

Alla OneLake-tabeller representeras av mappar i sjön, men inte alla mappar i sjön är tabeller ur OneLake-säkerhets- och frågemotorernas perspektiv i Fabric. För att betraktas som en giltig tabell måste följande villkor vara uppfyllda:

Mappen finns i Tabeller/-katalogen för ett objekt.
Mappen innehåller en _delta_log mapp med motsvarande JSON-filer för tabellmetadata.
Mappen innehåller inga underordnade genvägar.

Alla tabeller som inte uppfyller dessa kriterier får åtkomst nekad om säkerhet på tabellnivå har konfigurerats för dem.

Metadatasäkerhet

OneLake-säkerhetens läsåtkomst till data ger fullständig åtkomst till data och metadata i en tabell. För användare utan åtkomst till en tabell exponeras aldrig data och i allmänhet är metadata inte synliga. Detta 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. OneLake-säkerhet garanterar dock inte att metadata för en tabell inte är tillgängliga, särskilt i följande fall:

SQL-slutpunktsfrågor: SQL Analytics-slutpunkten använder samma metadatasäkerhetsbeteende som SQL Server. Det innebär att om en användare inte har åtkomst till en tabell eller kolumn, kommer felmeddelandet för frågan uttryckligen att ange de tabell- eller kolumnnamn som användaren inte har åtkomst till.
Semantiska modeller: Genom att ge en användare skapa behörighet för en semantisk modell kan de få åtkomst till att se tabellnamnen som ingår i modellen, oavsett om användaren har åtkomst till dem eller inte. Dessutom visar rapportvisualiseringar som innehåller dolda kolumner kolumnnamnet i felmeddelandet.

Arv av behörigheter

För vilken mapp som helst ärvs OneLake-säkerhetsbehörigheter inom hela hierarkin av mappens filer och undermappar.

Tänk till exempel på följande hierarki för ett sjöhus i OneLake:

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

Du skapar två roller för den här lakehouse. Role1 beviljar läsbehörighet till mapp1 och Role2 beviljar läsbehörighet till mapp2.

För den angivna hierarkin ärver OneLake-säkerhetsbehörigheter för Role1 och Role2 ärver på följande sätt:

Roll1: Läs mapp1

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

Roll 2: Läs mapp2
```
    │   file21.txt
```

Genomgång och listning i OneLake-säkerhet

OneLake-säkerhet ger automatisk bläddering av överordnade objekt för att säkerställa att data är lätta att identifiera. Genom att ge en användare läsbehörighet till undermapp11 kan användaren lista och bläddra i den överordnade katalogmappen1. Den här funktionen liknar Windows-mappbehörigheter där åtkomst till en undermapp ger identifiering och bläddringar för de överordnade katalogerna. Listan och bläddring som beviljas till föräldern omfattar inte andra objekt utanför de direkta föräldrarna, vilket säkerställer att andra mappar hålls säkra.

Tänk till exempel på 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

För den angivna hierarkin ger OneLake-säkerhetsbehörigheter för Roll1 följande åtkomst. Åtkomst till file11.txt visas inte eftersom den inte är en överordnad mapp till undermapp11. På samma sätt för Role2 visas inte file111.txt heller.

Roll1: Läs undermapp 11

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

Role2: Läs undermapp111

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

För genvägar är listningsbeteendet något annorlunda. Genvägar till externa datakällor fungerar på samma sätt som mappar, men genvägar till andra OneLake-platser har ett specialiserat beteende. Målbehörigheterna för genvägen avgör åtkomsten till en OneLake-genväg. När genvägar listas görs inget anrop för att kontrollera åtkomst till målet. När du visar en katalog returneras därför alla interna genvägar oavsett användarens åtkomst till målet. När en användare försöker öppna genvägen utvärderas åtkomstkontrollen och en användare ser bara data som de har de behörigheter som krävs för att se. För mer information om genvägar, se avsnittet om genvägarnas säkerhet .

Överväg följande mapphierarki som innehåller genvägar.

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

Roll1: Läs mapp1

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

Roll 2: Inga definierade behörigheter

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

Säkerhet på radnivå

Med OneLake-säkerhet kan användare ange säkerhet på radnivå genom att skriva SQL-predikat för att begränsa vilka data som visas för en användare. RLS fungerar genom att visa rader där predikatet utvärderas till sant. Mer information finns i säkerhet på radnivå.

Säkerhet på radnivå utvärderar strängdata som skiftlägesokänsliga med hjälp av följande sortering för sortering och jämförelser: Latin1_General_100_CI_AS_KS_WS_SC_UTF8

När du använder säkerhet på radnivå ska du se till att RLS-uttrycken är rena och lätta att förstå. Använd heltalskolumner för sortering och större än eller mindre än åtgärder. Undvik strängjämvikter om du inte känner till indataformatet, särskilt i förhållande till unicode-tecken eller accentkänslighet.

Säkerhet på kolumnnivå

OneLake-säkerhet stöder begränsning av åtkomst till kolumner genom att ta bort (dölja) en användares åtkomst till en kolumn. En dold kolumn behandlas som att den inte har några behörigheter tilldelade, vilket resulterar i standardprincipen för ingen åtkomst. Dolda kolumner visas inte för användare och frågor om data som innehåller dolda kolumner returnerar inga data för den kolumnen. Som anges i metadatasäkerhet finns det vissa fall där metadata för en kolumn fortfarande kan vara synliga i vissa felmeddelanden.

Säkerhet på kolumnnivå följer också ett striktare beteende i SQL-slutpunkten genom att använda en neka-semantik. Neka på en kolumn i SQL-slutpunkten säkerställer att all åtkomst till kolumnen blockeras, även om flera roller skulle kombineras för att ge åtkomst till den. Därför fungerar CLS i SQL-slutpunkten med hjälp av en skärningspunkt mellan alla roller som en användare är en del av i stället för det fackliga beteende som finns för alla andra behörighetstyper. Mer information om hur roller kombineras finns i avsnittet Utvärdera flera OneLake-säkerhetsroller.

Genvägar

Översikt över genvägar

OneLake-säkerhet integreras med genvägar i OneLake för att säkerställa att data i och utanför OneLake enkelt kan skyddas. Det finns två huvudsakliga autentiseringslägen för genvägar:

Genvägar för genomströmning (SSO): Frågeanvändarens autentiseringsuppgifter utvärderas mot genvägsmålet för att avgöra vilka data som tillåts visas.
Delegerade genvägar: Genvägen använder en fast autentiseringsuppgift för att komma åt målet och den frågande användaren utvärderas mot OneLake-säkerhet innan den delegerade autentiseringsuppgiftens åtkomst till källan kontrolleras.

Dessutom utvärderas OneLake-säkerhetsbehörigheter när du skapar genvägar i OneLake. Läs mer om genvägsbehörigheter i säkerhetsdokumentet för genvägar.

OneLake-säkerhet i genvägar för genomströmning

Säkerhetsuppsättningen i en OneLake-mapp flödar alltid över alla interna genvägar för att begränsa åtkomsten till genvägskällans sökväg. När en användare kommer åt data via en genväg till en annan OneLake-plats används identiteten för den anropande användaren för att auktorisera åtkomst till data i målsökvägen för genvägen. Därför måste den här användaren ha OneLake-säkerhetsbehörigheter på målplatsen för att kunna läsa data.

Viktigt!

När du kommer åt genvägar via Power BI-semantikmodeller med DirectLake över SQL- eller T-SQL-motorer i läget Delegerad identitet skickas inte den anropande användarens identitet till genvägsmålet. I stället skickas identiteten för den anropande objektägaren, vilket delegerar åtkomsten till den anropande användaren. Lös detta genom att använda Power BI-semantiska modeller i DirectLake över OneLake-läge eller T-SQL i användarens identitetsläge.

Det går inte att definiera OneLake-säkerhetsbehörigheter för den interna genvägen och måste definieras i målmappen som finns i målobjektet. Målobjektet måste vara en objekttyp som stöder OneLake-säkerhetsroller. Om målobjektet inte stöder OneLake-säkerhet utvärderas användarens åtkomst baserat på om de har behörigheten Fabric ReadAll för målobjektet. Användare behöver inte behörigheten Infrastrukturläsning för ett objekt för att få åtkomst till det via en genväg.

OneLake-säkerhet i delegerade genvägar

OneLake har stöd för att definiera behörigheter för genvägar som ADLS-, S3- och Dataverse-genvägar. I det här fallet tillämpas behörigheterna ovanpå den delegerade auktoriseringsmodellen som är aktiverad för den här typen av genväg.

Anta att user1 skapar en S3-genväg i ett sjöhus som pekar på en mapp i en AWS S3-bucket. Sedan försöker user2 komma åt data i den här genvägen.

Tillåter S3-anslutningen åtkomst för den delegerade användaren1?	Tillåter OneLake-säkerhet åtkomst för den begärande användaren2?	Resultat: Kan user2 komma åt information i S3-genväg?
Ja	Ja	Ja
Nej	Nej	Nej
Nej	Ja	Nej
Ja	Nej	Nej

OneLake-säkerhetsbehörigheterna kan definieras antingen för hela omfånget för genvägen eller för valda undermappar. Behörigheter som angetts för en mapp ärver rekursivt till alla undermappar, även om undermappen finns inom genvägen. Säkerhetsuppsättningen på en extern genväg kan begränsas för att ge åtkomst till hela genvägen eller någon undersökväg i genvägen. En annan intern genväg som pekar på en extern genväg kräver fortfarande att användaren har åtkomst till den ursprungliga externa genvägen.

Till skillnad från andra typer av åtkomst i OneLake-säkerhet kräver en användare som kommer åt en extern genväg behörighet att läsa infrastrukturresurser för det dataobjekt där den externa genvägen finns. Detta är nödvändigt för att säkert hantera anslutningen till det externa systemet.

Läs mer om S3-, ADLS- och Dataverse-genvägar i OneLake-genvägar.

Utvärdera flera OneLake-säkerhetsroller

Användare kan vara medlemmar i flera olika OneLake-säkerhetsroller, där var och en ger sin egen åtkomst till data. Kombinationen av dessa roller tillsammans kallas "effektiv roll" och är vad en användare ser när de kommer åt data i OneLake. Roller kombineras i OneLake-säkerhet med hjälp av en UNION-modell eller en minst restriktiv modell. Det innebär att om Role1 ger åtkomst till TableA och Role2 ger åtkomst till TableB kan användaren se både TableA och TableB.

OneLake-säkerhetsroller innehåller också säkerhet på rad- och kolumnnivå, vilket begränsar åtkomsten till raderna och kolumnerna i en tabell. Varje RLS- och CLS-princip finns inom en roll och begränsar åtkomsten till data för alla användare inom den enskilda rollen. Om Roll1 till exempel ger åtkomst till Table1, men har RLS på Table1 och bara visar vissa kolumner i Table1, kommer den effektiva rollen för Role1 att vara RLS- och CLS-delmängderna i Table1. Detta kan uttryckas som (R1ols n R1cls n R1rls) där n är INTERSECTION för varje komponent i rollen.

När du hanterar flera roller kombinerar RLS och CLS med en UNION-semantik i respektive tabeller. CLS är en direkt uppsättning UNION av tabellerna som visas i varje roll. RLS kombineras mellan predikat med hjälp av en OR-operator. Till exempel WHERE city = 'Redmond' OR city = 'New York'.

För att utvärdera flera roller var och en med RLS eller CLS löses varje roll först baserat på den åtkomst som ges av själva rollen. Det innebär att utvärdera SKÄRNINGSPUNKTEN för alla säkerheter på objekt-, rad- och kolumnnivå. Varje utvärderad roll kombineras sedan med alla andra roller som en användare är medlem i via UNION-åtgärden. Utdata är den effektiva rollen för den användaren. Detta kan uttryckas som:

( (R1ols n R1cls n R1rls) u (R2ols n R2cls n R2rls) )

Slutligen genererar varje genväg i ett lakehouse en uppsättning härledda roller som används för att sprida genvägsmålets behörigheter till det objekt som efterfrågas. Härledda roller fungerar på ett liknande sätt som icke-uppskjutna roller, förutom att de löses först på plats på genvägsmålet innan de kombineras med roller i genvägen lakehouse. Detta säkerställer att alla arv av behörigheter på genvägen lakehouse bryts och de härledda rollerna utvärderas korrekt. Den fullständiga kombinationslogik kan sedan uttryckas som:

( (R1ols n R1cls n R1rls) u (R2ols n R2cls n R2rls) ) n ( (R1'ols n R1'cls n R1'rls) u (R2'ols n R2'cls n R2'rls)) )

Där R1 och R2 är de härledda rollerna och R1 och R2 är genvägsrollerna lakehouse.