Hoe OneLake-beveiliging data-toegang beheert

OneLake-beveiliging is een rolgebaseerd systeem dat bepaalt wie toegang heeft tot data in OneLake en welke acties ze kunnen uitvoeren op die gegevens. Het begrijpen van het data-toegangscontrolemodel helpt je gebruikers alleen de toegang te geven die ze nodig hebben, zodat je gevoelige gegevens kunt beschermen en toch de juiste mensen ermee kunt werken.

Dit artikel legt uit hoe OneLake-beveiligingsrollen zijn gestructureerd, hoe ze integreren met werkruimte- en itemrechten, hoe OneLake toegang tot je data toepast en oplost, en welke grenzen je moet in gedachten houden.

OneLake-beveiligingsrollen

OneLake-beveiliging gebruikt een rolgebaseerd toegangscontrolemodel (RBAC) om de toegang tot gegevens in OneLake te beheren. In de OneLake-beveiligingservaring heeft elke functie de volgende componenten:

  • Machtigingen: De rechten die de rol toekent voor de gegevens, zoals Lezen of Lezen/schrijven.
  • Type: Het roltype. OneLake-beveiliging ondersteunt alleen Grant-rollen, die leden toegang geven tot de gegevens in de rol. Het ondersteunt geen Deny rollen die toegang verwijderen.
  • Data in rol: De tabellen, mappen of schema's waar de rol toegang toe verleent. Je kunt ook data-toegang definiëren met rij- en kolombeveiliging op tabellen.
  • Leden in rol: De Microsoft Entra-identiteiten die aan de rol zijn toegewezen, zoals gebruikers-, groeps- of niet-gebruikersidentiteiten. Als je een Microsoft Entra-groep toewijst, kent OneLake-beveiliging de rol toe aan alle leden van de groep.

OneLake-beveiliging gebruikt een deny-by-default-model, dus gebruikers beginnen zonder toegang tot data tenzij een OneLake-beveiligingsrol expliciet toegang verleent. Sommige Fabric-items beginnen met standaardrollen die gebruikers basistoegang geven op basis van hun werkruimterechten.

Machtigingen en ondersteunde items

OneLake-beveiligingsrollen ondersteunen de volgende permissies:

  • 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 toestemming gelijkwaardig aan zowel VIEW_DEFINITION als SELECT. Voor meer informatie, zie Metadata beveiliging.
  • ReadWrite: Geeft de gebruiker de mogelijkheid om data in een tabel of map te lezen en te schrijven en de bijbehorende tabel- en kolommetadata te bekijken. In SQL-termen is deze toestemming gelijkwaardig aan ALTER, DROP, , UPDATEen INSERT. Voor meer informatie, zie ReadWrite-toestemming.

Je kunt OneLake-beveiligingsrollen aanmaken voor de volgende Fabric-items:

Stofoartikel Ondersteunde machtigingen
Lakehouse Lezen, lezen/schrijven
Azure Databricks gespiegelde catalogus Lezen
Gespiegelde databases Lezen
Gespiegelde catalogi Lezen

Lees- en schrijfrechten

Gebruik de ReadWrite-toestemming om alleen-lezende gebruikers schrijftoegang te geven tot specifieke gegevens in een item.

ReadWrite geldt alleen voor gebruikers met de Read-rechten op een item, zoals gebruikers met de Viewer-werkruimterol. Het toewijzen van ReadWrite aan een workspace-beheerder, lid of bijdrager heeft geen effect omdat deze workspace-rollen al schrijftoegang hebben.

ReadWrite bevat alle privileges die door de Leesrechten worden verleend, plus het verleent schrijftoegang tot het geselecteerde object en de inhoud daarvan. Bijvoorbeeld, ReadWrite-toestemming op een map geeft schrijftoegang tot zowel de map als de gegevens erin.

Gebruikers met ReadWrite-toestemming kunnen de volgende acties uitvoeren:

  • Maak een map of tabel aan, verwijder of hernoem ze.
  • Upload of bewerk een bestand.
  • Maak een snelkoppeling aan, verwijder of hernoem deze.

Gebruikers kunnen schrijfbewerkingen uitvoeren via Spark-notebooks, de OneLake-bestandsverkenner of OneLake API's. Omdat Fabric alleen single-engine schrijfopdrachten naar data ondersteunt, kunnen gebruikers met ReadWrite-toestemming alleen via OneLake naar die data schrijven. Alle query-engines blijven leesbewerkingen consequent afdwingen.

OneLake-beveiligingsrollen die ReadWrite-toestemming verlenen, kunnen geen beperkingen voor beveiliging op rijniveau (RLS) of beveiliging op kolomniveau (CLS) bevatten.

Machtigingen voor OneLake-beveiliging en werkruimten

Workspace-rollen zijn de eerste beveiligingsgrens voor data in OneLake. Ze beheren het controlevlak - het aanmaken en beheren van Fabric-items en -rechten - en passen toe op alle items in de werkruimte. Voor de specifieke OneLake-rechten die elke werkruimterol verleent, zie Toegang verlenen met werkruimterollen. Voor meer informatie over werkruimterollen, zie Rollen in werkruimtes in Fabric.

Naast toegang tot de control plane kunnen werkruimterollen ook toegang geven tot data-items via de standaardbeveiligingsrollen van OneLake. (Standaardrollen gelden alleen voor Viewers, omdat Admin-, Lid- en Contributor-rollen verhoogde toegang hebben via de Write-recht.) Een standaardrol is een normale OneLake-beveiligingsrol die Fabric automatisch aanmaakt bij 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. Deze standaardtoegang zorgt ervoor dat gebruikers die met een nieuw aangemaakt item werken een basisniveau van toegang hebben. Alle standaardrollen gebruiken een functie voor gevirtualiseerd lidmaatschap, waardoor de leden van de rol bestaan uit alle gebruikers in die werkruimte met de vereiste machtiging. Bijvoorbeeld alle gebruikers met de machtiging ReadAll voor het lakehouse.

De volgende tabel toont de standaard standaardrollen. Items kunnen gespecialiseerde standaardrollen hebben die alleen op dat itemtype van toepassing zijn.

Stofoartikel Rolnaam Toestemming verleend Toegewezen leden
Lakehouse DefaultReader Lezen Alle gebruikers met de machtiging ReadAll
Azure Databricks gespiegelde catalogus DefaultReader Lezen Alle gebruikers met leesmachtigingen
Gespiegelde catalogus DefaultReader Lezen Alle gebruikers met leesmachtigingen
Gespiegelde database DefaultReader Lezen Alle gebruikers met de machtiging ReadAll

Je kunt de standaardrol van een Fabric-item aanpassen of verwijderen om de toegang voor de gebruikers in die ledengroep te wijzigen.

Engine- en gebruikerstoegang tot gegevens

OneLake-beveiliging is standaard op least privileged access. Sommige opslagoperaties kunnen RLS of CLS niet afdwingen, dus wanneer een query niet veilig kan worden gefilterd, blokkeert OneLake deze volledig om het risico te lopen data bloot te stellen die de gebruiker niet mag zien. Of een query gefilterd of geblokkeerd is, hangt af van het toegangspad - een ondersteunde query-engine of directe gebruikerstoegang.

Voor de engines die RLS- en CLS-filtering ondersteunen en de vereisten per engine, raadpleegt u Read data secured with OneLake security.

Reikwijdte en handhaving

In deze sectie vindt u meer informatie over hoe OneLake-beveiligingsrollen toegang verlenen tot specifieke bereik, hoe die toegang functioneert en hoe toegang wordt opgelost over meerdere rollen en toegangstypen.

Beveiliging op tabelniveau

OneLake vertegenwoordigt alle tabellen als mappen, maar vanuit het perspectief van OneLake-beveiligings- en query-engines in Fabric zijn niet alle mappen tabellen. Om een geldige tabel te zijn, moet een map aan de volgende voorwaarden voldoen:

  • De map bevindt zich in de Tables/ map van een item. Voor items met schema's moet de map zich ook in een geldige schemamap bevinden.
  • De map bevat een _delta_log map met bijbehorende JSON-bestanden voor de metadata van de tabel.
  • De map bevat geen kindsnelkoppelingen.

Als je RLS of CLS op een tabel configureert, weigert OneLake toegang wanneer de map van de tabel niet aan deze criteria voldoet. Zonder RLS of CLS behandelt OneLake een map die niet aan deze criteria voldoet als een map en past mappenbeveiliging toe.

Beveiliging op rij- en kolomniveau

Binnen een rol kun je de toegang beperken tot specifieke rijen en kolommen van een tabel door gebruik te maken van rij- en kolombeveiliging. Voor meer informatie over wat elke controle doet en hoe OneLake dit afdwingt, zie beveiliging op tabel-, kolom- en rijniveau in OneLake. Voor informatie over hoe RLS en CLS worden opgelost wanneer een gebruiker tot meerdere rollen behoort, zie Evaluate multiple OneLake security roles.

Beveiliging van metagegevens

De leesmachtiging van OneLake-beveiliging verleent volledige toegang tot de gegevens en metagegevens in een tabel. Voor gebruikers zonder toegang tot een tabel worden de gegevens nooit weergegeven. Deze regel geldt ook voor beveiliging op kolomniveau en de mogelijkheid van een gebruiker om een kolom in die tabel wel of niet te zien. OneLake-beveiliging garandeert echter niet dat de metadata van een tabel niet toegankelijk is. Bepaalde foutmeldingen en gebruikerservaringen kunnen kolomnamen tonen.

Overerving van mapmachtigingen en mapdoorkruising

Mapmachtigingen hebben invloed op een hiërarchie in twee richtingen:

  • Overerving: Toestemmingen die op een map worden verleend, gelden naar beneden voor de bestanden en submappen.
  • Doorlopen en vermelden: Wanneer gebruikers toestemming hebben voor een kinditem, laat OneLake-beveiliging hen de oudermappen vermelden en doorlopen zodat ze de data kunnen ontdekken en ernaar navigeren. Doorlopen geeft geen toegang tot bestanden of mappen van broers en zussen.

Overweeg de volgende hiërarchie van een meerhuis in OneLake:

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

Je maakt een rol aan, Role1, die leestoestemming geeft op subfolder11. Via overerving kunnen leden van die rol file111.txt en alles in subfolder111 lezen. Leden kunnen kijken en bewegen folder1 om te bereiken subfolder11, maar ze kunnen niet zien file11.txt omdat het een broer of zus is subfolder11 en ze kunnen niet zien Tables omdat het een broer of zus van Filesis.

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

Je maakt een andere rol aan, Role2, die leestoestemming geeft op folder2. Door erfenis kunnen leden lezen file21.txt. Leden kunnen via folder2 en Files ernaartoe navigeren, maar ze kunnen folder1 of een van de onderliggende items niet zien.

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

Voor snelkoppelingen is het gedrag iets anders. Snelkoppelingen naar externe databronnen gedragen zich hetzelfde als mappen. Shortcuts naar andere OneLake-locaties hebben echter specifiek gedrag. De doeltoestemmingen van de snelkoppeling bepalen de toegang tot een OneLake-snelkoppeling. Bij het vermelden van snelkoppelingen belt OneLake niet om de doeltoegang te controleren. Als gevolg daarvan, wanneer je een directory vermeldt, geeft OneLake alle interne snelkoppelingen terug, ongeacht je toegang tot het doelwit. De toegangscontrole beoordeelt zodra je probeert de snelkoppeling te openen, en dan zie je alleen de gegevens waarvoor je de vereiste rechten hebt.

Snelkoppelingen

OneLake-beveiliging integreert met snelkoppelingen om data binnen en buiten OneLake te beveiligen. Snelkoppelingen gebruiken een van twee authenticatiemodi:

  • Passthrough: De snelkoppeling gebruikt de identiteit van de gebruiker die de query uitvoert voor toegang tot het doel. Passthrough is de standaard voor snelkoppelingen van OneLake naar OneLake.
  • Gedelegeerd: De snelkoppeling gebruikt een geconfigureerde verbindingsidentiteit of inloggegevens om toegang te krijgen tot het doel. OneLake-naar-OneLake snelkoppelingen kunnen gedelegeerde authenticatie gebruiken, en snelkoppelingen naar externe systemen gebruiken altijd gedelegeerde authenticatie.

Het maken van een snelkoppeling vereist rechten op zowel het pad waar de snelkoppeling is gemaakt als het doelpad. Voor de vereisten voor het maken en openen van elk type snelkoppeling raadpleegt u de beveiliging van OneLake-snelkoppelingen.

OneLake-beveiliging in passthrough-snelkoppelingen

Wanneer een gebruiker via een passthrough OneLake-naar-OneLake snelkoppeling gegevens raadpleegt, gebruikt OneLake de identiteit van de aanroepende gebruiker om toegang tot het doelpad te autoriseren. De effectieve toegang van de gebruiker wordt beperkt door hun rechten op zowel het snelkoppelpad als het doelpad.

Notitie

Query-engine identiteit en snelkoppelingsauthenticatie zijn aparte instellingen. Een passthrough snelkoppeling gebruikt normaal gesproken de identiteit van de bellende gebruiker om toegang te krijgen tot het doelwit. Power BI semantische modellen die Direct Lake gebruiken via SQL- en SQL-analyse-eindpunten in gedelegeerde identiteitsmodus, gebruiken echter de eigenaaridentiteit van het consumentenproduct of de databron. Dit gedrag verandert de geconfigureerde authenticatiemodus van de snelkoppeling niet. Voor end-to-end-doorgifte van gebruikersidentiteit gebruikt u Direct Lake via OneLake of configureert u het SQL-analyse-eindpunt voor het gebruik van de toegangsmodus voor gebruikersidentiteit.

Je kunt OneLake-beveiligingsrechten niet direct definiëren via een OneLake-naar-OneLake snelkoppeling. Machtigingen op de map die de snelkoppeling bevat, worden gecombineerd met machtigingen op het doelpad. Als het doelitem OneLake-beveiliging ondersteunt, heeft de gebruiker toegang nodig via een OneLake-beveiligingsrol. Als het doelitem geen OneLake-beveiliging ondersteunt, heeft de gebruiker de Fabric ReadAll-toestemming nodig voor het doelobject. De gebruiker heeft geen Fabric Read-toestemming nodig op het doelitem alleen om via de snelkoppeling toegang te krijgen tot de gegevens.

OneLake-beveiliging in gedelegeerde snelkoppelingen

Gedelegeerde snelkoppelingen gebruiken een geconfigureerde verbindingsidentiteit of credential in plaats van de identiteit van de oproepende gebruiker om toegang te krijgen tot het doelwit. De beveiliging van OneLake beperkt wat de bellende gebruiker via die verbinding kan bereiken.

OneLake-gedelegeerde snelkoppelingen

Voor een gedelegeerde OneLake-naar-OneLake-snelkoppeling ziet de aanroepende gebruiker de overlap in zijn of haar toegangsrechten op het pad van de snelkoppeling en de toegangsrechten van de geconfigureerde verbindingsidentiteit op het doelpad. Beveiliging op kolomniveau (CLS) wordt op beide paden ondersteund. Row-level security (RLS) wordt ondersteund op het doelpad, maar je kunt RLS niet definiëren op het shortcutpad.

Gedelegeerde externe snelkoppelingen

Snelkoppelingen naar externe systemen, zoals ADLS, Amazon S3 en Dataverse, gebruiken een geconfigureerd verbindingsinlogificatie om toegang te krijgen tot de externe bron. OneLake-beveiliging wordt toegepast bovenop de toegang die door dat inlogement wordt verleend.

Stel bijvoorbeeld dat gebruiker1 een snelkoppeling in het lakehouse aanmaakt naar een map in een Amazon S3-bucket, en user2 toegang krijgt tot de snelkoppeling vanuit het lakehouse. User2 kan alleen toegang krijgen tot de S3-gegevens als het geconfigureerde S3-verbindingscredential toegang heeft tot de bron en OneLake-beveiliging autoriseert user2 om toegang te krijgen tot het snelkoppelpad.

Je kunt OneLake beveiligingstoegang geven tot de volledige externe snelkoppeling of tot geselecteerde subpaden. Machtigingen op een map worden recursief overgenomen door alle submappen, inclusief mappen binnen de snelkoppeling. Een gebruiker die via een andere OneLake-snelkoppeling een externe snelkoppeling bereikt, moet nog steeds geautoriseerd zijn door de OneLake-beveiliging die op de oorspronkelijke externe snelkoppeling is toegepast.

Het openen van een externe snelkoppeling via Spark of een directe OneLake API-aanroep vereist ook Fabric Read-toestemming voor het item dat de externe snelkoppeling bevat. Deze toestemming is vereist om de verbinding met het externe systeem veilig op te lossen.

Evalueer meerdere OneLake beveiligingsrollen

Een gebruiker kan tot meerdere OneLake-beveiligingsrollen behoren. OneLake combineert de toegang die door die rollen wordt verleend tot een effectieve rol, die bepaalt welke data de gebruiker kan benaderen. OneLake evalueert de effectieve rol in fasen.

Toegang binnen elke rol oplossen

OneLake lost eerst elke rol onafhankelijk op. Binnen een rol kan een gebruiker alleen toegang krijgen tot de gegevens die door alle drie de beveiligingscomponenten zijn toegestaan:

  • Beveiliging op objectniveau (OLS) bepaalt tot welke tabellen of mappen de rol toegang heeft.
  • Row-level security (RLS) beperkt welke rijen van een bepaalde tabel de rol kan benaderen.
  • Kolomniveau beveiliging (CLS) beperkt welke kolommen van een bepaalde tabel de rol kan benaderen.

Omdat alle drie de componenten van toepassing zijn, neemt OneLake de intersectie ervan. Als Rol1 bijvoorbeeld toegang verleent tot Tabel1 en de rijen en kolommen beperkt, is de opgeloste toegang voor Rol1:

Role1 = R1_OLS ∩ R1_RLS ∩ R1_CLS

Het intersectiesymbool (∩) betekent dat de gebruiker alleen toegang krijgt die door OLS, RLS en CLS binnen die rol wordt toegestaan.

Combineer toegang tussen rollen

Nadat elke rol is opgelost, combineert OneLake de rollen volgens een uniemodel, ofwel het minst beperkende model. Het uniesymbool (∪) betekent dat toegang verleend door elke rol onderdeel wordt van de effectieve rol. Als Rol1 toegang geeft tot TableA en Role2 toegang tot TableB, kan een gebruiker die tot beide rollen behoort toegang krijgen tot beide tabellen.

Voor twee rollen is de effectieve rol:

Effective role = Role1 ∪ Role2

Wanneer meerdere rollen toegang verlenen tot dezelfde tabel, worden beveiligingsregels op rijniveau gecombineerd met een OR-operator. Bijvoorbeeld, predicaten die city = 'Redmond' en city = 'New York' accepteren, worden gecombineerd tot city = 'Redmond' OR city = 'New York'.

Beveiligingsregels op kolomniveau worden ook samengevoegd tot een unie, behalve bij het eindpunt voor SQL-analyses. In het SQL-analytics-eindpunt gebruikt CLS een strengere deny-semantiek. Als een rol een kolom verbergt, blokkeert het eindpunt de toegang tot die kolom. Als gevolg daarvan kruist het eindpunt CLS-toelatingslijsten over alle rollen van de gebruiker in plaats van ze als een unie te combineren.

Belangrijk

Beheer de RLS- en CLS-regels die samen moeten gelden binnen dezelfde rol. OneLake ondersteunt geen rolcombinatie waarbij twee rollen een verschillende set kolommen voor een tabel toestaan en beide rollen ook RLS op die tabel toepassen. Bijvoorbeeld, een gebruiker kan niet behoren tot Role1, die kolommen c1 en c2 en een deelverzameling van rijen toestaat, en Role2, die kolommen c2 en c3 toestaat.

Snelkoppeling en doeltoegang combineren

Voor een shortcut evalueert OneLake de rollen op de shortcut-locatie en bij het shortcut-doel apart. De doelrollen worden op de locatie van de snelkoppeling afgeleide rollen. OneLake bepaalt vervolgens de overlap tussen de gecombineerde toegang van de shortcutrollen en de gecombineerde toegang van de afgeleide doelrollen. Deze stap voorkomt dat toegangsrechten die op de locatie van de snelkoppeling zijn overgenomen, beperkingen op de doellocatie opheffen.

Voor twee shortcut-rollen en twee afgeleide doelrollen is de effectieve toegang:

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

In deze uitdrukking zijn ShortcutRole1 en ShortcutRole2 rollen op de locatie van de snelkoppeling. InferredRole1 en InferredRole2 zijn de overeenkomstige afgeleide rollen van het snelkoppelingsdoel. Elke rol wordt opgelost vanuit zijn OLS-, RLS- en CLS-componenten voordat OneLake de rollen combineert.

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 Externe id. Stel de instelling voor gastgebruikerstoegang in op Gastgebruikers die dezelfde toegang hebben als leden (meest inclusief).

  • Als u een distributielijst toevoegt aan een rol in OneLake-beveiliging, kan het SQL Analytics-eindpunt de leden van de lijst niet oplossen om toegang af te dwingen. Daardoor lijken gebruikers geen lid van de rol te zijn wanneer ze toegang krijgen tot het SQL-analyse-endpoint. Direct Lake op SQL semantische modellen valt ook onder deze beperking.

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

  • Niet-schema lakehouses ondersteunen geen data-preview voor RLS- en CLS-beveiligde tabellen. Gebruik schemaondersteunde lakehouses met OneLake-beveiliging.

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

  • De volgende tabel geeft een overzicht van de beperkingen van OneLake beveiligingsrollen.

    Scenariobeschrijving Grenswaarde
    Maximum aantal OneLake-beveiligingsrollen per fabric-item 250 rollen per onderdeel (zie opmerking)
    Maximum aantal leden per OneLake-beveiligingsrol 500 gebruikers of gebruikersgroepen per rol
    Maximum aantal machtigingen per OneLake-beveiligingsrol 500 machtigingen per rol

    Notitie

    Je kunt een verhoging van het aantal rollen per item aanvragen tot 1.000. Neem contact op met Azure Support om een verhoging aan te vragen.

Latenties

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.

Verwante onderwerpen

  • Last updated on