Share via


OneLake-model voor toegangsbeheer voor beveiliging (preview)

Dit document bevat een gedetailleerde handleiding voor de werking van het OneLake-model voor toegangsbeheer voor beveiliging. Het bevat details over hoe de rollen zijn gestructureerd, hoe ze van toepassing zijn op gegevens en wat de integratie is met andere structuren binnen Microsoft Fabric.

OneLake-beveiligingsrollen

OneLake-beveiliging maakt gebruik van een RBAC-model (op rollen gebaseerd toegangsbeheer) voor het beheren van toegang tot gegevens in OneLake. Elke rol bestaat uit verschillende belangrijke onderdelen.

  • Type: Of de rol toegang verleent (GRANT) of toegang (DENY) verwijdert. Alleen GRANT-typerollen worden ondersteund.
  • Toestemming: De specifieke actie of acties die worden verleend of geweigerd.
  • Draagwijdte: De OneLake-objecten met de machtiging. Objecten zijn tabellen, mappen of schema's.
  • Leden: Een Microsoft Entra-identiteit die is toegewezen aan de rol, zoals gebruikers, groepen of niet-gebruikersidentiteiten. De rol wordt verleend aan alle leden van een Microsoft Entra-groep.

Door een lid toe te wijzen aan een rol, is die gebruiker vervolgens onderworpen aan de bijbehorende machtigingen voor het bereik van die rol. Omdat OneLake-beveiliging gebruikmaakt van een standaardmodel voor weigeren, beginnen alle gebruikers zonder toegang tot gegevens, tenzij ze expliciet worden verleend door een OneLake-beveiligingsrol.

Machtigingen en ondersteunde items

OneLake-beveiligingsrollen ondersteunen de volgende machtiging:

  • Lezen: Verleent de gebruiker de mogelijkheid om gegevens uit een tabel te lezen en de bijbehorende tabel- en kolommetagegevens weer te geven. In SQL-termen is deze machtiging gelijk aan zowel VIEW_DEFINITION als SELECT. Zie de beveiliging van metagegevens voor meer informatie.
  • ReadWrite: Verleent de gebruiker de mogelijkheid om gegevens te lezen en schrijven uit een tabel of map en de bijbehorende tabel- en kolommetagegevens weer te geven. In SQL-termen is deze machtiging gelijk aan ALTER, DROP, UPDATE en INSERT. Zie De machtiging ReadWrite voor meer informatie.

Met OneLake-beveiliging kunnen gebruikers alleen rollen voor gegevenstoegang definiëren voor de volgende Fabric-items.

Stofoartikel Toestand Ondersteunde machtigingen
Lakehouse Public Preview Lezen, lezen/schrijven
Gespiegelde Azure Databricks-catalogus Public Preview Lezen

Machtigingen voor OneLake-beveiliging en werkruimten

Werkruimtemachtigingen vormen de eerste beveiligingsgrens voor gegevens in OneLake. Elke werkruimte vertegenwoordigt één domein of projectgebied waar teams kunnen samenwerken aan gegevens. U beheert de beveiliging in de werkruimte via Fabric-werkruimterollen. Meer informatie over op rollen gebaseerd toegangsbeheer voor Fabric (RBAC): Werkruimterollen

Infrastructuurwerkruimterollen geven machtigingen die van toepassing zijn op alle items in de werkruimte. De volgende tabel bevat een overzicht van de basismachtigingen die zijn toegestaan door werkruimterollen.

Machtiging admin Lid Inzender Kijker
Bestanden weergeven in OneLake Altijd* Ja Altijd* Ja Altijd* Ja Nee standaard. Gebruik OneLake-beveiliging om de toegang te verlenen.
Bestanden schrijven in OneLake Altijd* Ja Altijd* Ja Altijd* Ja Nee
Kan OneLake-beveiligingsrollen bewerken Altijd* Ja Altijd* Ja Nee Nee

*Aangezien de rollen Werkruimtebeheerder, Lid en Inzender automatisch schrijfmachtigingen verlenen aan OneLake, overschrijven ze leesmachtigingen voor OneLake-beveiliging.

Werkruimterollen beheren de toegang tot gegevens in het besturingsvlak, wat betekent dat interacties met het maken en beheren van Fabric-artefacten en -machtigingen. Daarnaast bieden werkruimterollen ook standaardtoegangsniveaus voor gegevensitems met behulp van standaardrollen voor OneLake-beveiliging. (Houd er rekening mee dat standaardrollen alleen van toepassing zijn op kijkers, omdat beheerder, lid en inzender verhoogde toegang hebben via de schrijfmachtiging) Een standaardrol is een normale OneLake-beveiligingsrol die automatisch wordt gemaakt met elk nieuw item. Het biedt gebruikers met bepaalde werkruimte- of itemmachtigingen een standaardniveau van toegang tot gegevens in dat item. Lakehouse-items hebben bijvoorbeeld een DefaultReader-rol waarmee gebruikers met de machtiging ReadAll gegevens in Lakehouse kunnen zien. Dit zorgt ervoor dat gebruikers die toegang hebben tot een nieuw item, een basisniveau van toegang hebben. Alle standaardrollen maken gebruik van een lidvirtualisatiefunctie, zodat de leden van de rol een gebruiker in die werkruimte zijn met de vereiste machtiging. Bijvoorbeeld alle gebruikers met de machtiging ReadAll voor lakehouse. In de volgende tabel ziet u wat de standaardrollen zijn. Items hebben mogelijk speciale standaardrollen die alleen van toepassing zijn op dat itemtype.

Stofoartikel Rolnaam Machtiging Mappen die zijn opgenomen Toegewezen leden
Lakehouse DefaultReader Lezen Alle mappen onder Tables/ en Files/ Alle gebruikers met de machtiging ReadAll
Lakehouse DefaultReadWriter Lezen Alle mappen Alle gebruikers met schrijfmachtigingen

Notitie

Als u de toegang tot specifieke gebruikers of specifieke mappen wilt beperken, wijzigt u de standaardrol of verwijdert u deze en maakt u een nieuwe aangepaste rol.

Machtigingen voor OneLake-beveiliging en -items

In een werkruimte kunnen Fabric-onderdelen machtigingen hebben die afzonderlijk van de werkruimterollen zijn geconfigureerd. U kunt machtigingen configureren via het delen van een item of door de machtigingen van een item te beheren. De volgende machtigingen bepalen de mogelijkheid van een gebruiker om acties uit te voeren op gegevens in OneLake. Zie Hoe Lakehouse delen werkt voor meer informatie over het delen van items

Machtiging Kunt u bestanden weergeven in OneLake? Kunt u bestanden schrijven in OneLake? Kunt u gegevens lezen via een SQL-analyse-eindpunt?
Lezen Nee standaard. Gebruik OneLake-beveiliging om toegang te verlenen. Nee Nee
LeesAlles Ja via de rol DefaultReader. Gebruik OneLake-beveiliging om de toegang te beperken. Nee Nee*
Schrijven Ja Ja Ja
Uitvoeren, opnieuw delen, Uitvoer bekijken, Logboeken bekijken N.v.t. - kan niet zelfstandig toegekend worden N.v.t. - kan niet zelfstandig toegekend worden N.v.t. - kan niet zelfstandig toegekend worden

*Is afhankelijk van de eindpuntmodus van SQL Analytics.

Rollen maken

U kunt OneLake-beveiligingsrollen definiëren en beheren via uw lakehouse-instellingen voor gegevenstoegang.

Meer informatie vindt u in Aan de slag met rollen voor gegevenstoegang.

Engine- en gebruikerstoegang tot gegevens

Gegevenstoegang tot OneLake vindt op twee manieren plaats:

  • Via een Fabric-query-engine of
  • Via gebruikerstoegang (query's van niet-Fabric-engines worden beschouwd als gebruikerstoegang)

OneLake-beveiliging zorgt ervoor dat gegevens altijd veilig blijven. Omdat bepaalde OneLake-beveiligingsfuncties, zoals beveiliging op rij- en kolomniveau, niet worden ondersteund door bewerkingen op opslagniveau, kunnen niet alle typen toegang tot beveiligde gegevens op rij- of kolomniveau worden toegestaan. Dit garandeert dat gebruikers geen rijen of kolommen kunnen zien die niet zijn toegestaan. Microsoft Fabric-engines zijn ingeschakeld om beveiliging op rij- en kolomniveau toe te passen op gegevensquery's. Dit betekent dat wanneer een gebruiker gegevens opvraagt in een lakehouse of een ander item met OneLake-beveiligings-RLS of CLS, de resultaten die de gebruiker ziet, de verborgen rijen en kolommen worden verwijderd. Voor gebruikerstoegang tot gegevens in OneLake met RLS of CLS erop wordt de query geblokkeerd als de gebruiker die toegang aanvraagt niet alle rijen of kolommen in die tabel mag zien.

In de onderstaande tabel wordt beschreven welke Microsoft Fabric-engines RLS en CLS-filtering ondersteunen.

Motor RLS/CLS-filtering Status
Lakehouse Ja Openbare preview
Spark-notebooks Ja Openbare preview
SQL Analytics-eindpunt in de identiteitsmodus van de gebruiker Ja Openbare preview
Semantische modellen die DirectLake gebruiken in de OneLake-modus Ja Openbare preview
Eventhouse Nee Planned
Externe datawarehousetabellen Nee Planned

Details van oneLake-beveiligingstoegangsbeheermodel

In deze sectie vindt u meer informatie over hoe OneLake-beveiligingsrollen toegang verlenen tot specifieke bereiken, hoe die toegang werkt en hoe de toegang wordt omgezet in meerdere rollen en toegangstypen.

Beveiliging op tabelniveau

Alle OneLake-tabellen worden vertegenwoordigd door mappen in OneLake, maar niet alle mappen in OneLake zijn tabellen vanuit het perspectief van OneLake's beveiligings- en query-engines in Fabric. Als u een geldige tabel wilt beschouwen, moet aan de volgende voorwaarden worden voldaan:

  • De map bevindt zich in de Tabellendirectory van een item.
  • De map bevat een _delta_log map met bijbehorende JSON-bestanden voor de metagegevens van de tabel.
  • De map bevat geen onderliggende snelkoppelingen.

Tabellen die niet aan deze criteria voldoen, zal de toegang worden geweigerd als de beveiliging op tabelniveau is geconfigureerd.

Beveiliging van metagegevens

De leestoegang van OneLake-beveiliging tot gegevens verleent volledige toegang tot de gegevens en metagegevens in een tabel. Voor gebruikers zonder toegang tot een tabel worden de gegevens nooit weergegeven en zijn de metagegevens over het algemeen niet zichtbaar. Dit geldt ook voor beveiliging op kolomniveau en de mogelijkheid van een gebruiker om een kolom in die tabel te zien of niet te zien. OneLake-beveiliging garandeert echter niet dat de metagegevens voor een tabel niet toegankelijk zijn, met name in de volgende gevallen:

  • SQL-eindpuntquery's: SQL Analytics-eindpunt maakt gebruik van hetzelfde gedrag voor metagegevensbeveiliging als SQL Server. Dit betekent dat als een gebruiker geen toegang heeft tot een tabel of kolom, het foutbericht voor die query expliciet de tabel- of kolomnamen vermeldt waartoe de gebruiker geen toegang heeft.
  • Semantische modellen: als u een gebruiker samenstellingsmachtiging geeft voor een semantisch model, hebben ze toegang tot de tabelnamen die zijn opgenomen in het model, ongeacht of de gebruiker toegang tot het model heeft of niet. Daarnaast geven rapportvisuals die verborgen kolommen bevatten, de kolomnaam in het foutbericht weer.

Overerfbaarheid van toestemming

Voor elke willekeurige map worden beveiligingsmachtigingen voor OneLake altijd geërfd door de hele hiërarchie van de bestanden en submappen.

Denk bijvoorbeeld aan de volgende hiërarchie van een lakehouse in OneLake:

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

Je maakt twee rollen voor dit lakehouse. Role1 verleent leesmachtigingen voor map1 en Role2 leesmachtigingen verleent aan map2.

Voor de opgegeven hiërarchie worden de beveiligingsmachtigingen van Role1Role2 OneLake op de volgende manier overgenomen:

  • Role1: Map1 Lezen

    │   │   file11.txt
    │   │
    │   └───subfolder11
    │       │   file1111.txt
    |       │
    │       └───subfolder111
    |            │   file1111.txt
    
  • Rol2: Map lezen2

        │   file21.txt
    

Verkenning en lijstweergave in OneLake-beveiliging

OneLake-beveiliging biedt automatisch doorzoeken van bovenliggende items om ervoor te zorgen dat gegevens eenvoudig te vinden zijn. Als u een gebruiker leesmachtigingen verleent voor submap11, verleent u de gebruiker de mogelijkheid om de bovenliggende map map1 weer te geven en te doorlopen. Deze functionaliteit is vergelijkbaar met Windows-mapmachtigingen, waarbij het verlenen van toegang tot een submap de mogelijkheid biedt om de hoofdmapstructuren te ontdekken en te doorbladeren. De lijst en toegang die aan de bovenliggende items worden verleend, worden niet uitgebreid naar andere items buiten de rechtstreekse bovenliggende items, om ervoor te zorgen dat andere mappen veilig blijven.

Denk bijvoorbeeld aan de volgende hiërarchie van een lakehouse in OneLake.

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

Voor de opgegeven hiërarchie biedt OneLake-beveiligingsmachtigingen voor 'Role1' de volgende toegang. Toegang tot file11.txt is niet zichtbaar omdat het geen bovenliggende map van subfolder11 is. Ook voor Role2 is file111.txt ook niet zichtbaar.

  • Rol1: Submap11 lezen

    Files/
    ────folder1
    │   │
    │   └───subfolder11
    │       │   file111.txt
    |       │
    │       └───subfolder111
    |            │   file1111.txt
    
  • nl-NL: Role2: Submap111 lezen

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

Voor snelkoppelingen is de manier waarop ze worden weergegeven iets anders. Snelkoppelingen naar externe gegevensbronnen gedragen zich hetzelfde als mappen, maar snelkoppelingen naar andere OneLake-locaties hebben gespecialiseerd gedrag. De doeltoestemmingen van de snelkoppeling bepalen de toegang tot een OneLake-snelkoppeling. Bij het weergeven van snelkoppelingen wordt er geen aanroep uitgevoerd om de doeltoegang te controleren. Als gevolg hiervan worden bij het weergeven van een map alle interne snelkoppelingen geretourneerd, ongeacht de toegang van een gebruiker tot het doel. Wanneer een gebruiker de snelkoppeling probeert te openen, evalueert de toegangscontrole en ziet een gebruiker alleen gegevens die ze de vereiste machtigingen hebben om te zien. Zie de sectie beveiliging van snelkoppelingenvoor meer informatie over snelkoppelingen.

Bekijk de volgende maphiërarchie die snelkoppelingen bevat.

Files/
────folder1
│   
└───shortcut2
|
└───shortcut3
  • Role1: Map1 Lezen

    Files/
    ────folder1
    │   
    └───shortcut2
    |
    └───shortcut3
    
  • Rol2: Er zijn geen machtigingen gedefinieerd

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

Beveiliging op het niveau van rijen

Met OneLake-beveiliging kunnen gebruikers beveiliging op rijniveau opgeven door SQL-predicaten te schrijven om te beperken welke gegevens worden weergegeven aan een gebruiker. RLS werkt door rijen weer te geven waarin het predicaat waar wordt geëvalueerd. Zie de beveiliging op rijniveau voor meer informatie.

Beveiliging op rijniveau evalueert tekenreeksgegevens als niet hoofdlettergevoelig, met behulp van de volgende sortering voor sorteren en vergelijkingen: Latin1_General_100_CI_AS_KS_WS_SC_UTF8

Wanneer u beveiliging op rijniveau gebruikt, moet u ervoor zorgen dat de RLS-instructies schoon en gemakkelijk te begrijpen zijn. Gebruik kolommen met gehele getallen voor het sorteren en groter dan of kleiner dan bewerkingen. Vermijd tekenreeksen als u de notatie van de invoergegevens niet kent, met name in relatie tot Unicode-tekens of accentgevoeligheid.

Beveiliging op kolomniveau

OneLake-beveiliging biedt ondersteuning voor het beperken van de toegang tot kolommen door de toegang van een gebruiker tot een kolom te verwijderen (verbergen). Een verborgen kolom wordt behandeld als er geen machtigingen aan zijn toegewezen, wat resulteert in het standaardbeleid van geen toegang. Verborgen kolommen zijn niet zichtbaar voor gebruikers en query's op gegevens met verborgen kolommen retourneren geen gegevens voor die kolom. Zoals vermeld in de beveiliging van metagegevens , zijn er bepaalde gevallen waarin de metagegevens van een kolom mogelijk nog steeds zichtbaar zijn in sommige foutberichten.

Beveiliging op kolomniveau volgt ook een strikter gedrag in SQL-eindpunt door te werken via een semantisch weigeren. Weigeren voor een kolom in SQL Endpoint zorgt ervoor dat alle toegang tot de kolom wordt geblokkeerd, zelfs als meerdere rollen er toegang toe zouden geven. Als gevolg hiervan werkt CLS in SQL Endpoint met behulp van een snijpunt tussen alle rollen waarvan een gebruiker deel uitmaakt in plaats van het samenvoeggedrag voor alle andere machtigingstypen. Zie de sectie Meerdere OneLake-beveiligingsrollen evalueren voor meer informatie over hoe rollen worden gecombineerd.

Lees- en schrijfrechten

De machtiging ReadWrite biedt alleen-lezengebruikers de mogelijkheid om schrijfbewerkingen uit te voeren op specifieke items. De LeesSchrijfmachtiging is alleen van toepassing op Viewers of gebruikers met de Leesmachtiging voor een item. Het toewijzen van ReadWrite-toegang tot een beheerder, lid of inzender heeft geen effect omdat deze rollen die machtiging al impliciet hebben.

Met ReadWrite-toegang kunnen gebruikers schrijfbewerkingen uitvoeren via Spark-notebooks, de OneLake-verkenner of OneLake-API's. Schrijfbewerkingen via de Lakehouse UX voor kijkers worden niet ondersteund.

De machtiging ReadWrite werkt op de volgende manieren:

  • De machtiging ReadWrite bevat alle bevoegdheden die zijn verleend door de machtiging Lezen.
  • Gebruikers met leesmachtigingen voor een object kunnen schrijfbewerkingen uitvoeren op dat object, inclusief. Dat wil gezegd, alle bewerkingen kunnen ook worden uitgevoerd op het object zelf.
  • ReadWrite staat de volgende acties toe:
    • Een nieuwe map of tabel maken
    • Een map of tabel verwijderen
    • De naam van een map of tabel wijzigen
    • Een bestand uploaden of bewerken
    • Snelkoppeling maken
    • Een snelkoppeling verwijderen
    • De naam van een snelkoppeling wijzigen
  • OneLake-beveiligingsrollen met ReadWrite-toegang mogen geen RLS- of CLS-beperkingen bevatten.
  • Omdat Fabric alleen schrijfbewerkingen van één engine naar gegevens ondersteunt, kunnen gebruikers met de machtiging ReadWrite voor een object alleen naar die gegevens schrijven via OneLake. De leesbewerkingen worden echter consistent afgedwongen via alle query-engines.

Snelkoppelingen

Overzicht van snelkoppelingen

OneLake-beveiliging kan worden geïntegreerd met snelkoppelingen in OneLake om ervoor te zorgen dat gegevens binnen en buiten OneLake eenvoudig kunnen worden beveiligd. Er zijn twee hoofdverificatiemodi voor snelkoppelingen:

  • Passthrough-snelkoppelingen (SSO): de referentie van de querygebruiker wordt geëvalueerd op basis van het snelkoppelingsdoel om te bepalen welke gegevens mogen worden gezien.
  • Gedelegeerde snelkoppelingen: De snelkoppeling maakt gebruik van een vaste referentie voor toegang tot het doel en de querygebruiker wordt geëvalueerd op basis van OneLake-beveiliging voordat de toegang van de gedelegeerde referentie tot de bron wordt gecontroleerd.

Daarnaast worden beveiligingsmachtigingen voor OneLake geëvalueerd bij het maken van snelkoppelingen in OneLake. Lees meer over snelkoppelingsmachtigingen in het beveiligingsdocument voor snelkoppelingen.

OneLake-beveiliging in passthrough-snelkoppelingen

Beveiliging die is ingesteld op een OneLake-map loopt altijd over interne snelkoppelingen om de toegang tot het bronpad van de snelkoppeling te beperken. Wanneer een gebruiker gegevens opent via een snelkoppeling naar een andere OneLake-locatie, wordt de identiteit van de aanroepende gebruiker gebruikt om toegang tot de gegevens in het doelpad van de snelkoppeling te autoriseren. Als gevolg hiervan moet deze gebruiker oneLake-beveiligingsmachtigingen hebben op de doellocatie om de gegevens te lezen.

Belangrijk

Wanneer u snelkoppelingen opent via semantische Power BI-modellen met behulp van DirectLake via SQL - of T-SQL-engines in de modus Gedelegeerde identiteit, wordt de identiteit van de aanroepende gebruiker niet doorgegeven aan het snelkoppelingsdoel. De identiteit van de eigenaar van het aanroepende item wordt doorgegeven, waardoor de toegang wordt gedelegeerd aan de aanroepende gebruiker. U kunt dit oplossen door semantische Power BI-modellen te gebruiken in DirectLake via de OneLake-modus of T-SQL in de identiteitsmodus van de gebruiker.

Het definiëren van OneLake-beveiligingsmachtigingen voor de interne snelkoppeling is niet toegestaan en moet worden gedefinieerd in de doelmap in het doelitem. Het doelitem moet een itemtype zijn dat ondersteuning biedt voor OneLake-beveiligingsrollen. Als het doelitem oneLake-beveiliging niet ondersteunt, wordt de toegang van de gebruiker geëvalueerd op basis van of ze de machtiging Fabric ReadAll voor het doelitem hebben. Gebruikers hebben geen leesmachtiging voor fabric nodig voor een item om het te kunnen openen via een snelkoppeling.

OneLake-beveiliging in gedelegeerde snelkoppelingen

OneLake ondersteunt het definiëren van machtigingen voor snelkoppelingen zoals ADLS-, S3- en Dataverse-snelkoppelingen. In dit geval worden de machtigingen toegepast op het gedelegeerde autorisatiemodel dat voor dit type snelkoppeling is ingeschakeld.

Stel dat gebruiker1 een S3-snelkoppeling maakt in een lakehouse die verwijst naar een map in een AWS S3-bucket. Vervolgens probeert gebruiker2 toegang te krijgen tot gegevens in deze snelkoppeling.

Autoriseert de S3-verbinding toegang voor de gedelegeerde gebruiker1? Autoriseert OneLake-beveiliging toegang voor de aanvragende gebruiker2? Resultaat: Heeft gebruiker2 toegang tot gegevens in S3 Shortcut?
Ja Ja Ja
Nee Nee Nee
Nee Ja Nee
Ja Nee Nee

De OneLake-beveiligingsmachtigingen kunnen worden gedefinieerd voor het volledige bereik van de snelkoppeling of voor geselecteerde submappen. Machtigingen die op een map zijn ingesteld, worden recursief toegepast op alle submappen, zelfs als de submap zich binnen een snelkoppeling bevindt. Beveiligingsset op een externe snelkoppeling kan worden ingesteld om toegang te verlenen tot de hele snelkoppeling of een subpad in de snelkoppeling. Een andere interne snelkoppeling die verwijst naar een externe snelkoppeling, vereist nog steeds dat de gebruiker toegang heeft tot de oorspronkelijke externe snelkoppeling.

In tegenstelling tot andere typen toegang in OneLake-beveiliging, is voor een gebruiker die toegang heeft tot een externe snelkoppeling leesmachtiging vereist voor het gegevensitem waarin de externe snelkoppeling zich bevindt. Dit is nodig om de verbinding met het externe systeem veilig op te lossen.

Meer informatie over S3-, ADLS- en Dataverse-snelkoppelingen vindt u in OneLake-snelkoppelingen.

Meerdere OneLake-beveiligingsrollen evalueren

Gebruikers kunnen lid zijn van meerdere verschillende OneLake-beveiligingsrollen, elk met een eigen toegang tot gegevens. De combinatie van deze rollen wordt de 'effectieve rol' genoemd en is wat een gebruiker ziet bij het openen van gegevens in OneLake. Rollen combineren in OneLake-beveiliging met behulp van een UNION- of minst beperkend model. Dit betekent dat als Role1 toegang geeft tot TableA en Role2 toegang geeft tot TableB, kan de gebruiker zowel TableA als TableB zien.

OneLake-beveiligingsrollen bevatten ook beveiliging op rij- en kolomniveau, waardoor de toegang tot de rijen en kolommen van een tabel wordt beperkt. Elk RLS- en CLS-beleid bestaat binnen een rol en beperkt de toegang tot gegevens voor alle gebruikers binnen die ene rol. Als Role1 bijvoorbeeld toegang geeft tot Table1, maar RLS op Table1 heeft en alleen enkele kolommen van Table1 weergeeft, wordt de effectieve rol voor Role1 de subsets RLS en CLS van Table1. Dit kan worden uitgedrukt als (R1ols n R1cls n R1rls), waarbij n het SNIJPUNT is van elk onderdeel in de rol.

Bij het omgaan met meerdere rollen, combineren RLS en CLS met een union-semantische op de respectieve tabellen. CLS is een directe samenvoeging van de tabellen die zichtbaar zijn in elke rol. RLS wordt gecombineerd tussen predicaten met behulp van een OR-operator. Bijvoorbeeld WHERE city = 'Redmond' OR city = 'New York'.

Als u meerdere rollen met RLS of CLS wilt evalueren, wordt elke rol eerst omgezet op basis van de toegang die door de rol zelf wordt gegeven. Dit betekent dat het SNIJPUNT van alle beveiliging op object-, rij- en kolomniveau wordt geëvalueerd. Elke geëvalueerde rol wordt vervolgens gecombineerd met alle andere rollen waarvan een gebruiker lid is via de union-bewerking. De uitvoer is de effectieve rol voor die gebruiker. Dit kan worden uitgedrukt als:

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

Ten slotte genereert elke snelkoppeling in een lakehouse een set uitgestelde rollen die worden gebruikt om de machtigingen van het snelkoppelingsdoel door te geven aan het item waarop een query wordt uitgevoerd. Uitgestelde rollen werken op een vergelijkbare manier als niet-uitgestelde rollen, behalve dat ze eerst worden omgezet op het snelkoppelingsdoel voordat ze worden gecombineerd met rollen in het snelkoppelings lakehouse. Dit zorgt ervoor dat de overname van machtigingen voor de snelkoppeling lakehouse wordt verbroken en dat de uitgestelde rollen correct worden geëvalueerd. De volledige combinatielogica kan vervolgens worden uitgedrukt als:

( (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)) )

Waarbij R1' en R2 de uitgestelde rollen zijn en R1 en R2 de snelkoppeling lakehouse-rollen zijn.

Belangrijk

Als twee rollen zodanig worden gecombineerd dat de kolommen en rijen niet zijn uitgelijnd op de query's, wordt de toegang geblokkeerd om ervoor te zorgen dat er geen gegevens naar de eindgebruiker worden gelekt.

Beveiligingsbeperkingen voor OneLake

  • Als u een OneLake-beveiligingsrol toewijst aan een B2B-gastgebruiker, moet u uw instellingen voor externe samenwerking configureren voor B2B in Microsoft Entra External ID. De instelling gastgebruikerstoegang moet zijn ingesteld op gastgebruikers dezelfde toegang hebben als leden (meest inclusief).

  • OneLake-beveiliging biedt geen ondersteuning voor snelkoppelingen tussen regio's. Pogingen om via een snelkoppeling toegang te krijgen tot gegevens in verschillende capaciteitsregio's resulteren in 404-fouten.

  • Als u een distributielijst toevoegt aan een rol in OneLake-beveiliging, kan het SQL-eindpunt de leden van de lijst niet oplossen om toegang af te dwingen. Het resultaat is dat gebruikers geen lid zijn van de rol wanneer ze toegang hebben tot het SQL-eindpunt. DirectLake op semantische SQL-modellen is ook onderhevig aan deze beperking.

  • Als u query's wilt uitvoeren op gegevens uit een Spark-notebook met behulp van Spark SQL, moet de gebruiker ten minste viewertoegang hebben in de werkruimte waar ze query's op uitvoeren.

  • Query's in de gemengde modus worden niet ondersteund. Enkele query's die toegang hebben tot zowel OneLake-beveiliging als niet-OneLake-beveiligingsgegevens, mislukken met queryfouten.

  • Spark-notebooks vereisen dat de omgeving 3.5 of hoger is en fabric-runtime 1.3 gebruikt.

  • OneLake-beveiliging werkt niet met private link-beveiliging.

  • De preview-functie voor het delen van externe gegevens is niet compatibel met de preview-versie van gegevenstoegangsrollen. Wanneer u de preview-versie van gegevenstoegangsrollen inschakelt in een Lakehouse, werken bestaande externe gegevensshares mogelijk niet meer.

  • OneLake-beveiliging werkt niet met Azure Data Share of Purview Data Share. Zie Azure Data Share voor meer informatie.

  • De volgende tabel bevat de beperkingen van Rollen voor Gegevenstoegang van OneLake.

    Scenariobeschrijving Grenswaarde
    Maximum aantal OneLake-beveiligingsrollen per fabric-item 250 rollen per lakehouse
    Maximum aantal leden per OneLake-beveiligingsrol 500 gebruikers of gebruikersgroepen per rol
    Maximum aantal machtigingen per OneLake-beveiligingsrol 500 machtigingen per rol

Latenties in OneLake-beveiliging

  • Het duurt ongeveer vijf minuten voordat wijzigingen in roldefinities zijn toegepast.
  • Wijzigingen in een gebruikersgroep in een OneLake-beveiligingsrol duren ongeveer een uur voordat OneLake de machtigingen van de rol toepast op de bijgewerkte gebruikersgroep.
    • Sommige Fabric-engines hebben hun eigen cachelaag, dus het kan een extra uur duren voordat de toegang in alle systemen wordt bijgewerkt.