OneLake-beveiliging voor SQL Analytics-eindpunten (preview)

Met OneLake-beveiliging breidt Microsoft Fabric uit hoe organisaties toegang tot gegevens kunnen beheren en afdwingen tussen workloads. Dit nieuwe beveiligingsframework biedt beheerders meer flexibiliteit om machtigingen te configureren. Beheerders kunnen kiezen tussen gecentraliseerd beheer via OneLake of gedetailleerd beheer op basis van SQL binnen het SQL-analyse-eindpunt.

Toegangsmodi in SQL Analytics-eindpunt

Wanneer u het SQL Analytics-eindpunt gebruikt, bepaalt de geselecteerde toegangsmodus hoe gegevensbeveiliging wordt afgedwongen. Fabric ondersteunt twee verschillende toegangsmodellen, die elk verschillende voordelen bieden, afhankelijk van uw operationele en nalevingsbehoeften:

• Gebruikersidentiteitsmodus: Hiermee wordt beveiliging afgedwongen met behulp van OneLake-rollen en -beleid. In deze modus geeft het SQL Analytics-eindpunt de identiteit van de aangemelde gebruiker door aan OneLake en wordt leestoegang volledig beheerd door de beveiligingsregels die zijn gedefinieerd in OneLake. Machtigingen op SQL-niveau voor tabellen worden ondersteund en zorgen voor consistente governance voor hulpprogramma's zoals Power BI, notebooks en Lakehouse.

• Gedelegeerde identiteitsmodus: biedt volledige controle via SQL. In deze modus maakt het SQL Analytics-eindpunt verbinding met OneLake met behulp van de identiteit van de eigenaar van de werkruimte of item en wordt de beveiliging uitsluitend beheerd door SQL-machtigingen die in de database zijn gedefinieerd. Dit model ondersteunt traditionele beveiligingsmethoden, waaronder GRANT, REVOKE, aangepaste rollen, Row-Level Beveiliging en Dynamische gegevensmaskering.

Elke modus ondersteunt verschillende governancemodellen. Inzicht in hun implicaties is essentieel voor het kiezen van de juiste benadering in uw Fabric-omgeving.

Vergelijking tussen toegangsmodi

Hier volgt een duidelijke en beknopte vergelijkingstabel die is gericht op hoe en waar u beveiliging instelt in de gebruikersidentiteitsmodus versus de gedelegeerde identiteitsmodus, opgesplitst op objecttype en beleid voor gegevenstoegang:

Beveiligingsdoel	Gebruikersidentiteitsmodus	Gedelegeerde identiteitsmodus
Tables	Toegang wordt beheerd door OneLake-beveiligingsrollen. SQL GRANT/REVOKE is niet toegestaan.	Volledig beheer met behulp van SQL GRANT/REVOKE.
Views	Gebruik SQL GRANT/REVOKE om machtigingen toe te wijzen.	Gebruik SQL GRANT/REVOKE om machtigingen toe te wijzen.
Opgeslagen procedures	Gebruik SQL GRANT EXECUTE om machtigingen toe te wijzen.	Gebruik SQL GRANT EXECUTE om machtigingen toe te wijzen.
Functies	Gebruik SQL GRANT EXECUTE om machtigingen toe te wijzen.	Gebruik SQL GRANT EXECUTE om machtigingen toe te wijzen.
Row-Level Beveiliging (RLS)	Gedefinieerd in de OneLake-gebruikersinterface als onderdeel van OneLake-beveiligingsrollen.	Gedefinieerd met SQL CREATE SECURITY POLICY.
Column-Level Beveiliging (CLS)	Gedefinieerd in de OneLake-gebruikersinterface als onderdeel van OneLake-beveiligingsrollen.	Gedefinieerd met BEHULP van SQL GRANT SELECT met kolomlijst.
Dynamische gegevensmaskering (DDM)	Niet ondersteund in OneLake-beveiliging.	Gedefinieerd met behulp van SQL ALTER TABLE met MASKED de optie.

Gebruikersidentiteitsmodus in OneLake-beveiliging

In de gebruikersidentiteitsmodus gebruikt het SQL Analytics-eindpunt een passthrough-verificatiemechanisme om toegang tot gegevens af te dwingen. Wanneer een gebruiker verbinding maakt met het EINDPUNT van SQL Analytics, wordt de entra-id doorgegeven aan OneLake, waarmee de machtigingscontrole wordt uitgevoerd. Alle leesbewerkingen op basis van tabellen worden geëvalueerd met behulp van de beveiligingsregels die zijn gedefinieerd in OneLake Lakehouse, niet door een GRANT- of REVOKE-instructie op SQL-niveau.

Met deze modus kunt u de beveiliging centraal beheren, waardoor consistente afdwinging in alle Fabric-ervaringen mogelijk is, waaronder Power BI, notebooks, lakehouse en SQL-analyse-eindpunt. Het is ontworpen voor governancemodellen waarbij de toegang eenmaal in OneLake moet worden gedefinieerd en overal automatisch moet worden gerespecteerd.

In de gebruikersidentiteitsmodus:

• Tabeltoegang wordt volledig beheerd door OneLake-beveiliging. SQL GRANT/REVOKE-instructies voor tabellen worden genegeerd.

• RLS (Row-Level Security), CLS (Column-Level Security) en Object-Level Security zijn allemaal gedefinieerd in de OneLake-ervaring.

• SQL-machtigingen zijn toegestaan voor niet-gegevensobjecten, zoals weergaven, opgeslagen procedures en functies, waardoor flexibiliteit mogelijk is voor het definiëren van aangepaste logica of gebruikersgerichte toegangspunten voor gegevens.

• Schrijfbewerkingen worden niet ondersteund op het SQL Analytics-eindpunt. Alle schrijfbewerkingen moeten plaatsvinden via de Gebruikersinterface van Lakehouse en vallen onder werkruimterollen (Beheerder, Lid, Inzender).

Belangrijk

Voor het SQL Analytics-eindpunt is een een-op-een-toewijzing vereist tussen itemmachtigingen en leden in een OneLake-beveiligingsrol om correct te synchroniseren. Als u een identiteit toegang verleent tot een OneLake-beveiligingsrol, moet diezelfde identiteit ook de machtiging Fabric Read hebben voor het lakehouse. Als een gebruiker bijvoorbeeld 'user123@microsoft.com' toewijst aan een OneLake-beveiligingsrol, moet 'user123@microsoft.com' ook aan dat lakehouse worden toegewezen.

Gedrag van werkruimterol

Gebruikers met de rol Beheerder, Lid of Inzender op werkruimteniveau zijn niet onderworpen aan het afdwingen van De beveiliging van OneLake. Deze rollen hebben verhoogde bevoegdheden en omzeilen RLS-, CLS- en OLS-beleid volledig. Volg deze vereisten om ervoor te zorgen dat oneLake-beveiliging wordt gerespecteerd:

• Gebruikers de rol Viewer toewijzen in de werkruimte of

• Deel het Lakehouse- of SQL Analytics-eindpunt met gebruikers met behulp van alleen-lezenmachtigingen . Alleen gebruikers met alleen-lezentoegang hebben hun query's gefilterd op basis van OneLake-beveiligingsrollen.

Rolprioriteit: de meeste permissieve toegang wint

Als een gebruiker deel uitmaakt van meerdere OneLake-rollen, definieert de meest permissieve rol hun effectieve toegang. Voorbeeld:

• Als de ene rol volledige toegang verleent tot een tabel en een andere rol RLS toepast om rijen te beperken, wordt de RLS niet afgedwongen.

• De bredere toegangsrol heeft voorrang. Dit gedrag zorgt ervoor dat gebruikers niet per ongeluk worden geblokkeerd, maar er is een zorgvuldig rolontwerp nodig om conflicten te voorkomen. Het wordt aanbevolen om beperkende en permissieve rollen wederzijds exclusief te houden bij het afdwingen van toegangsbeheer op rij- of kolomniveau.

Zie het model voor gegevenstoegangsbeheer voor OneLake-beveiliging voor meer informatie.

Beveiligingssynchronisatie tussen OneLake en SQL Analytics-eindpunt

Een essentieel onderdeel van de gebruikersidentiteitsmodus is de beveiligingssynchronisatieservice. Deze achtergrondservice bewaakt wijzigingen in beveiligingsrollen in OneLake en zorgt ervoor dat deze wijzigingen worden doorgevoerd in het SQL Analytics-eindpunt.

De beveiligingssynchronisatieservice is verantwoordelijk voor het volgende:

• Wijzigingen in OneLake-rollen detecteren, waaronder nieuwe rollen, updates, gebruikerstoewijzingen en wijzigingen in tabellen.

• Door OneLake gedefinieerde beleidsregels (RLS, CLS, OLS) te vertalen in gelijkwaardige databaserolstructuren die compatibel zijn met SQL.

• Ervoor zorgen dat snelkoppelingsobjecten (tabellen die afkomstig zijn van andere lakehouses) correct worden gevalideerd, zodat de oorspronkelijke OneLake-beveiligingsinstellingen worden gehonoreerd, zelfs wanneer ze extern worden geopend.

Deze synchronisatie zorgt ervoor dat OneLake-beveiligingsdefinities gezaghebbend blijven, waardoor handmatige tussenkomst op SQL-niveau niet meer nodig is om het beveiligingsgedrag te repliceren. Omdat beveiliging centraal wordt afgedwongen:

• U kunt RLS, CLS of OLS niet rechtstreeks definiëren met behulp van T-SQL in deze modus.

• U kunt nog steeds SQL-machtigingen toepassen op weergaven, functies en opgeslagen procedures met behulp van GRANT- of EXECUTE-instructies.

Beveiligingssynchronisatiefouten en -oplossing

Scenario	Gedrag in gebruikersidentiteitsmodus	Gedrag in de gedelegeerde modus	Corrigerende actie	Opmerkingen
RLS-beleid verwijst naar een verwijderde of hernoemde kolom	Fout: *Beveiligingsbeleid op rijniveau verwijst naar een kolom die niet meer bestaat.*Database voert de foutstatus in totdat het beleid is opgelost.	Fout: Ongeldige kolomnaamkolomnaam <>	Werk een of meer betrokken rollen bij of verwijder deze of herstel de ontbrekende kolom.	De update moet worden uitgevoerd in het lakehouse waar de rol is gemaakt.
CLS-beleid verwijst naar een verwijderde of hernoemde kolom	Fout: *Beveiligingsbeleid op kolomniveau verwijst naar een kolom die niet meer bestaat.*Database voert de foutstatus in totdat het beleid is opgelost.	Fout: Ongeldige kolomnaamkolomnaam <>	Werk een of meer betrokken rollen bij of verwijder deze of herstel de ontbrekende kolom.	De update moet worden uitgevoerd in het lakehouse waar de rol is aangemaakt.
RLS/CLS-beleid verwijst naar een verwijderde of hernoemde tabel	Fout: Beveiligingsbeleid verwijst naar een tabel die niet meer bestaat.	Er is geen fout opgetreden; query mislukt op de achtergrond als de tabel ontbreekt.	Werk een of meer betrokken rollen bij of verwijder deze of herstel de ontbrekende tabel.	De update moet worden uitgevoerd in het lakehouse waar de rol is gemaakt.
DDM-beleid (Dynamic Data Masking) verwijst naar een verwijderde of hernoemde kolom	DDM wordt niet ondersteund vanuit OneLake Security, moet worden geïmplementeerd via SQL.	Fout: Ongeldige kolomnaamkolomnaam <>	Werk een of meer betrokken DDM-regels bij of verwijder deze of herstel de ontbrekende kolom.	Werk het DDM-beleid bij in het SQL Analytics-eindpunt.
Systeemfout (onverwachte fout)	Fout: er is een onverwachte systeemfout opgetreden. Probeer het opnieuw of neem contact op met de ondersteuning.	Fout: er is een interne fout opgetreden tijdens het toepassen van tabelwijzigingen op SQL.	Bewerking opnieuw proberen; Als het probleem zich blijft voordoen, neemt u contact op met Microsoft Ondersteuning.	N/A
Gebruiker heeft geen machtiging voor het artefact	Fout: gebruiker heeft geen machtiging voor het artefact	Fout: gebruiker heeft geen machtiging voor het artefact	Geef de gebruiker toestemming met objectID {objectID} om toegang tot het artefact te verkrijgen.	De object-ID moet exact overeenkomen tussen het lid van de OneLake-beveiligingsrol en de Fabric-itemmachtigingen. Als een groep wordt toegevoegd aan het rollidmaatschap, moet diezelfde groep de Fabric-leesmachtiging krijgen. Het toevoegen van een lid van die groep aan het item telt niet als een directe overeenstemming.
De gebruikersprincipal wordt niet ondersteund.	Fout: Gebruiker-hoofdcomponent wordt niet ondersteund.	Fout: User principal wordt niet ondersteund.	Verwijder de gebruiker {username} uit de rol DefaultReader	Deze fout treedt op als de gebruiker geen geldige Entra-id meer is, bijvoorbeeld als de gebruiker uw organisatie heeft verlaten of is verwijderd. Verwijder deze uit de rol om deze fout op te lossen.

Gedrag van snelkoppelingen met beveiligingssynchronisatie

OneLake-beveiliging wordt afgedwongen bij de bron van waarheid, dus met de beveiligingssynchronisatie wordt eigendomskoppeling voor tabellen en weergaven met betrekking tot snelkoppelingen uitgeschakeld. Dit zorgt ervoor dat bronsysteemmachtigingen altijd worden geëvalueerd en gehonoreerd, zelfs voor query's uit een andere database.

Als gevolg hiervan:

• Gebruikers moeten geldige toegang hebben op zowel de snelkoppelingsbron (huidig Lakehouse- of SQL-analyse-eindpunt) als het doel waar de gegevens zich fysiek bevinden.

• Als de gebruiker aan beide zijden geen machtigingen heeft, mislukken query's met een toegangsfout.

• Bij het ontwerpen van uw toepassingen of weergaven die verwijzen naar snelkoppelingen, moet u ervoor zorgen dat roltoewijzingen aan beide uiteinden van de snelkoppelingsrelatie correct zijn geconfigureerd.

Dit ontwerp behoudt de beveiligingsintegriteit over de grenzen van Lakehouse, maar introduceert scenario's waarin toegangsfouten kunnen optreden als cross-Lakehouse-rollen niet zijn uitgelijnd.

Gedelegeerde modus in OneLake-beveiliging

In de gedelegeerde identiteitsmodus maakt het SQL-analyse-eindpunt gebruik van hetzelfde beveiligingsmodel dat zich momenteel in Microsoft Fabric bevindt. Beveiliging en machtigingen worden volledig beheerd op de SQL-laag en OneLake-rollen of toegangsbeleid worden niet afgedwongen voor toegang op tabelniveau. Wanneer een gebruiker verbinding maakt met het SQL Analytics-eindpunt en een query uitgeeft:

• SQL valideert de toegang op basis van SQL-machtigingen (GRANT, REVOKE, RLS, CLS, DDM, rollen, enzovoort).

• Als de query is geautoriseerd, krijgt het systeem toegang tot gegevens die zijn opgeslagen in OneLake.

• Deze gegevenstoegang wordt uitgevoerd met behulp van de identiteit van de eigenaar van het Lakehouse- of SQL Analytics-eindpunt, ook wel het itemaccount genoemd.

In dit model:

• De aangemelde gebruiker wordt niet doorgegeven aan OneLake.

• Bij het afdwingen van toegang wordt ervan uitgegaan dat ze worden verwerkt op de SQL-laag.

• De eigenaar van het item is verantwoordelijk voor het hebben van voldoende machtigingen in OneLake om de onderliggende bestanden namens de workload te lezen.

Omdat dit een gedelegeerd patroon is, leidt elke onjuiste uitlijning tussen SQL-machtigingen en OneLake-toegang voor de eigenaar tot queryfouten. Deze modus biedt volledige compatibiliteit met:

• SQL GRANT/REVOKE op alle objectniveaus

• Door SQL gedefinieerdeRow-Level Beveiliging, Column-Level Beveiliging en Dynamische gegevensmaskering

• Bestaande T-SQL-hulpprogramma's en -procedures die worden gebruikt door DBA's of toepassingen

De OneLake-toegangsmodus wijzigen

De toegangsmodus bepaalt hoe gegevenstoegang wordt geverifieerd en afgedwongen bij het uitvoeren van query's op OneLake via sql-analyse-eindpunt. U kunt schakelen tussen de gebruikersidentiteitsmodus en de gedelegeerde identiteitsmodus met behulp van de volgende stappen:

1. Navigeer naar uw Fabric-werkruimte en open uw lakehouse. Ga in de rechterbovenhoek van Lakehouse naar sql Analytics-eindpunt.

2. Ga in de bovenste navigatiebalk naar het tabblad Beveiliging en selecteer een van de volgende OneLake-toegangsmodi:

   • Gebruikersidentiteit : maakt gebruik van de identiteit van de aangemelde gebruiker. Hiermee worden OneLake-rollen afgedwongen.

   • Gedelegeerde identiteit : maakt gebruik van de identiteit van de eigenaar van het item; dwingt alleen SQL-machtigingen af.

3. Er wordt een pop-up gestart om uw selectie te bevestigen. Selecteer Ja om de wijziging te bevestigen.

Overwegingen bij het schakelen tussen modi

Overschakelen naar de gebruikersidentiteitsmodus

• SQL RLS-, CLS- en tabelmachtigingen worden genegeerd.

• OneLake-rollen moeten worden geconfigureerd voor gebruikers om toegang te behouden.

• Alleen gebruikers met viewermachtigingen of gedeelde alleen-lezentoegang worden beheerd door De beveiliging van OneLake.

• Bestaande SQL-rollen worden verwijderd en kunnen niet worden hersteld.

Overschakelen naar de gedelegeerde identiteitsmodus

• OneLake-rollen en beveiligingsbeleidsregels worden niet meer toegepast.

• SQL-rollen en beveiligingsbeleid worden actief.

• De eigenaar van het item moet geldige Toegang tot OneLake hebben of alle query's kunnen mislukken.

Beperkingen

• Alleen van toepassing op lezers: OneLake Security bepaalt dat gebruikers toegang hebben tot gegevens als viewers. Gebruikers in andere werkruimterollen (Beheerderlid of Inzender) omzeilen OneLake Security en behouden volledige toegang.

• SQL-objecten nemen geen eigendom over: snelkoppelingen worden weergegeven in sql Analytics-eindpunten als tabellen. Wanneer u deze tabellen opent, rechtstreeks of via weergaven, opgeslagen procedures en andere afgeleide SQL-objecten geen eigendom op objectniveau heeft; alle machtigingen worden tijdens runtime gecontroleerd om te voorkomen dat de beveiliging wordt omzeild.

• Downtime van snelkoppelingswijzigingen activeren validatietijd: wanneer een snelkoppelingsdoel wordt gewijzigd (bijvoorbeeld naam wijzigen, URL-update), wordt de database kort in de modus voor één gebruiker geactiveerd terwijl het systeem het nieuwe doel valideert. Tijdens deze periode worden query's geblokkeerd, deze bewerkingen zijn vrij snel, maar soms kan het tot 5 minuten duren voordat een ander intern proces wordt gesynchroniseerd.

  • Het maken van schemasnelkoppelingen kan een bekende fout veroorzaken die van invloed is op de synchronisatie van validatie en vertragingen van metagegevens.

• Vertraagde doorgifte van machtigingen: machtigingswijzigingen zijn niet onmiddellijk. Schakelen tussen beveiligingsmodi (gebruikersidentiteit versus gedelegeerd) kan tijd vereisen om door te geven voordat deze van kracht wordt, maar het duurt minder dan 1 minuut.

• Afhankelijkheid van besturingsvlak: machtigingen kunnen niet worden toegepast op gebruikers of groepen die nog niet bestaan in het besturingsvlak van de werkruimte. U moet het bronitem delen of de gebruiker moet lid zijn van de werkruimterol Viewer. Houd er rekening mee dat dezelfde object-id zich op beide locaties moet bevinden. Een groep en een lid van deze groep tellen niet als een match.

• De meeste permissieve toegang heeft voorrang: wanneer gebruikers deel uitmaken van meerdere groepen of rollen, wordt de meest missieve effectieve machtiging gehonoreerd : Als een gebruiker zowel DENY via één rol als GRANT via een andere heeft, krijgt de GRANT voorrang.

• Beperkingen voor gedelegeerde modus: In de gedelegeerde modus kunnen metagegevenssynchronisatie op snelkoppelingstabellen mislukken als het bronitem OneLake-beveiligingsbeleid heeft dat geen volledige tabeltoegang verleent aan de eigenaar van het item.

• DENY-gedrag: wanneer meerdere rollen van toepassing zijn op één snelkoppelingstabel, volgt het snijpunt van machtigingen de semantiek van SQL Server: DENY overschrijft GRANT. Dit kan onverwachte toegangsresultaten opleveren.

• Verwachte foutvoorwaarden: Gebruikers kunnen fouten tegenkomen in scenario's zoals:

  • Naam van snelkoppelingsdoel gewijzigd of ongeldig

    • Voorbeeld: Als de bron van de tabel is verwijderd.

  • Onjuiste configuratie van beveiliging op rijniveau (Row-Level-beveiliging)

    • Sommige expressies voor RLS-filtering worden niet ondersteund in OneLake en het is mogelijk dat onbevoegde gegevenstoegang is toegestaan.

    • Als u de kolom verwijdert die in de filterexpressie wordt gebruikt, wordt de RLS- en metagegevenssynchronisatie verlopen totdat de RLS is opgelost in het OneLake-beveiligingsvenster.

    • Voor openbare preview ondersteunen we alleen tabellen met één expressie. Dynamische beveiliging op rijniveau en RLS met meerdere tabellen worden momenteel niet ondersteund.

  • beperkingen voor Column-Level Beveiliging (CLS)

    • CLS werkt door een acceptatielijst met kolommen te onderhouden. Als een toegestane kolom wordt verwijderd of de naam ervan is gewijzigd, wordt het CLS-beleid ongeldig.

    • Wanneer CLS ongeldig is, wordt synchronisatie van metagegevens geblokkeerd totdat de CLS-regel is opgelost in het deelvenster OneLake-beveiliging.

  • Synchronisatiefout met metagegevens of machtigingen

    • Als er wijzigingen in de tabel zijn, zoals het wijzigen van de naam van een kolom, wordt de beveiliging niet gerepliceerd voor het nieuwe object en ontvangt u UI-fouten die laten zien dat de kolom niet bestaat.

• Tabelnamen behouden geen beveiligingsbeleid: als DE ROLLEN van OneLake Security (OLS) zijn gedefinieerd op schemaniveau, blijven deze rollen alleen van kracht zolang de tabelnaam ongewijzigd blijft. Als u de naam van de tabel wijzigt, wordt de koppeling verbroken en wordt het beveiligingsbeleid niet automatisch gemigreerd. Dit kan leiden tot onbedoelde blootstelling van gegevens totdat beleid opnieuw wordt toegepast.

• OneLake-beveiligingsrollen mogen geen namen hebben die langer zijn dan 124 tekens; anders kan de beveiligingssynchronisatie de rollen niet synchroniseren.

• OneLake-beveiligingsrollen worden doorgegeven op het SQL Analytics-eindpunt met het voorvoegsel OLS_.

• Gebruikerswijzigingen in de OLS_ rollen worden niet ondersteund en kunnen onverwacht gedrag veroorzaken.

• Beveiligingsgroepen en distributielijsten met e-mail worden niet ondersteund.

• De eigenaar van het lakehouse moet lid zijn van de werkruimterollen beheerder, lid of inzender; Anders wordt beveiliging niet toegepast op het SQL Analytics-eindpunt.

• De eigenaar van het lakehouse kan geen service principal zijn om de beveiligingssynchronisatie mogelijk te maken.

Verwante inhoud

• Aanbevolen procedures voor het beveiligen van gegevens in OneLake
• OneLake-beveiligingstoegangsbeheermodel