OneLake-beveiliging voor SQL-analyse-eindpunten

Met OneLake-beveiliging breidt Microsoft Fabric uit op welke wijze organisaties toegang tot gegevens kunnen beheren en afdwingen over workloads heen. Dit 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 het eindpunt voor SQL-analyse

Wanneer u het SQL-analyse-eindpunt gebruikt, bepaalt de geselecteerde access modus hoe gegevensbeveiliging wordt afgedwongen. Fabric ondersteunt twee verschillende access modellen, 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 niet-gegevensobjecten (weergaven, opgeslagen procedures, functies) worden ondersteund en zorgen voor consistent beheer 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

De volgende tabel vergelijkt hoe en waar u beveiliging instelt in de gebruikersidentiteitsmodus versus de gedelegeerde identiteitsmodus, opgesplitst op objecttype en beleid voor gegevenstoegang:

Gebruikersidentiteitsmodus in OneLake-beveiliging

In de gebruikersidentiteitsmodus maakt het SQL Analytics-eindpunt gebruik van 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 van tabellen worden geëvalueerd met behulp van de beveiligingsregels die zijn gedefinieerd in OneLake Lakehouse, niet door SQL-niveau GRANT of REVOKE verklaringen.

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 access eenmaal in OneLake moet worden gedefinieerd en overal automatisch moet worden gerespecteerd.

In de gebruikersidentiteitsmodus:

• Toegang tot de tabel wordt volledig door de beveiliging van OneLake beheerd. SQL-instructies GRANT/REVOKE in 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 Lakehouse-pagina in de Fabric-portal en worden beheerd door werkruimterollen (beheerder, lid, inzender).

Zie het model voor gegevenstoegangsbeheer voor OneLake-beveiliging voor meer informatie over het machtigingsmodel met de identiteitsmodus van de gebruiker.

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.

Beveiligingssynchronisatie backoff opnieuw proberen

Beveiligingssynchronisatie bevat een mechanisme voor opnieuw proberen om systeemstabiliteit te beschermen en onnodig rekenverbruik te voorkomen:

• Als er herhaalde fouten optreden tijdens het toepassen van OneLake-beveiligingsrollen op het SQL Analytics-eindpunt, kan het systeem automatische synchronisatiepogingen tijdelijk onderbreken.

• Synchronisatie wordt automatisch hervat wanneer een bestaande OneLake-beveiligingsrol wordt gewijzigd of er een nieuwe wordt gemaakt.

Beveiligingssynchronisatiefouten en -oplossing

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 tot zowel de snelkoppelingbron (huidig Lakehouse of SQL Analytics-eindpunt) als de bestemming waar de gegevens zich fysiek bevinden.

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

• Bij het ontwerpen van 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 access fouten kunnen optreden als cross-Lakehouse-rollen niet zijn uitgelijnd.

Gedelegeerde modus in OneLake-beveiliging

In de gedelegeerde identiteitsmodus behoudt het SQL Analytics-eindpunt achterwaartse compatibiliteit met het traditionele SQL-beveiligingsmodel. Beveiliging wordt gedefinieerd en afgedwongen op de SQL-enginelaag en OneLake-beveiligingsrollen en toegangsbeleid worden niet overgedragen naar toegang op tabelniveau. Alle filters en toegangsbeheer, inclusief toegang tot schema's en tabellen, Row-Level Beveiliging (RLS), Column-Level Security (CLS) en Dynamic Data Masking (DDM) moeten worden gedefinieerd met behulp van SQL-constructies (GRANT/REVOKE, beveiligingsbeleid, enzovoort).

Omdat OneLake-beveiligingsrollen voor de eindgebruiker niet rechtstreeks worden afgedwongen, zijn eventuele beveiligingsregels die zijn gedefinieerd in OneLake (bijvoorbeeld regels die worden afgedwongen door Spark of andere engines die door OneLake worden gelezen) niet van toepassing wanneer dezelfde gegevens worden opgevraagd via het SQL-analyse-eindpunt. Kies deze modus wanneer de workload afhankelijk is van SQL-native beveiligingssemantiek of wanneer bestaande T-SQL-hulpprogramma's volledige compatibiliteit vereisen.

Wanneer een gebruiker verbinding maakt met het SQL Analytics-eindpunt en een query uitgeeft:

• SQL valideert de query op basis van de machtigingen die zijn gedefinieerd op de SQL-laag.

• Als de query wordt geautoriseerd, gaat het systeem verder met toegang krijgen 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, niet de aangemelde gebruiker.

De eigenaar van het item is daarom verantwoordelijk voor het hebben van voldoende machtigingen in OneLake om de onderliggende bestanden namens de workload te lezen. Elke onjuiste uitlijning tussen SQL-machtigingen die zijn verleend aan eindgebruikers en de Toegang tot OneLake van de itemeigenaar resulteert in queryfouten.

Deze modus ondersteunt bestaande T-SQL-hulpprogramma's en -procedures die worden gebruikt door DBA's of toepassingen, met volledige compatibiliteit voor SQL op alle objectniveaus en door SQL GRANT/REVOKE gedefinieerde RLS, CLS en DDM.

Gedrag van snelkoppelingen in de gedelegeerde modus

Omdat de gedelegeerde modus verbinding maakt met OneLake met behulp van de identiteit van de itemeigenaar, werken snelkoppelingen alleen wanneer de eigenaar onbeperkte toegang heeft tot de hele brontabel. Als in de brontabel een beveiligingsregel op OneLake-niveau is toegepast, zoals Row-Level Beveiliging (RLS), Column-Level Security (CLS) blokkeert het SQL Analytics-eindpunt de toegang tot die snelkoppeling.

Als gevolg hiervan:

• Snelkoppelingen die verwijzen naar brontabellen zonder beveiligingsregels op gegevensniveau werken normaal in de gedelegeerde modus.

• Snelkoppelingen die verwijzen naar brontabellen met RLS of CLS in OneLake-beveiliging op de producent, zijn niet toegankelijk via het SQL-analyse-eindpunt in de gedelegeerde modus, zelfs als de eindgebruiker SQL-machtigingen voor het snelkoppelingsobject heeft.

• Als u snelkoppelingen wilt gebruiken waarvan de bron OneLake-beveiligingsbeleid heeft, gebruikt u de gebruikersidentiteitsmodus op het eindpunt van de consument, zodat de identiteit van de eindgebruiker wordt geëvalueerd op basis van de OneLake-beveiligingsregels van de bron.

De OneLake access-modus wijzigen

De toegangsmodus bepaalt hoe gegevenstoegang wordt geverifieerd en afgedwongen bij het uitvoeren van query's op OneLake via het SQL Analytics-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. Schakel in de rechterbovenhoek over van Lakehouse naar sql-analyse-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. Dwingt OneLake-rollen af.

   • 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 hun toegang te behouden.

• Alleen gebruikers met kijkrechten of gedeelde alleen-lezen toegang vallen onder de OneLake-beveiliging.

• 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 OneLake-access hebben of alle query's kunnen mislukken.

Opmerkingen

• SQL-objecten nemen geen eigendom over: snelkoppelingen werken als tabellen in het SQL-analyse-eindpunt, maar wijken opzettelijk af van standaard-SQL-eigendomsketen om een uniform beveiligingspostuur te behouden.

  • Regel voor geen overname: afgeleide SQL-objecten (weergaven, opgeslagen procedures of functies) nemen geen machtigingen over van de objecteigenaar.

  • Runtimevalidatie: machtigingen worden geverifieerd op basis van de identiteit van de aanroeper tijdens de uitvoering, waardoor SQL-abstracties beleid op OneLake-niveau niet kunnen omzeilen.

  • Beveiliging standaard: beveiligingsbeleid blijft consistent of gegevens worden geopend via SQL, Spark of Power BI.

• Afhankelijkheid van besturingsvlak (strikte identiteitskoppeling): Voor OneLake-beveiliging moet de identiteit die aan de producent is verleend, dezelfde identiteit zijn die wordt herkend tijdens de toegangsevaluatie op het gegevensvlak van de consument. Het systeem valideert de specifieke principal die toegang heeft gekregen bij de bron en breidt het geneste groepslidmaatschap niet uit of leidt effectieve toegang af via indirect lidmaatschap.

  • Letterlijke principalovereenkomst: Toegang wordt geëvalueerd op basis van de exacte object-id die door de producent is verleend.

  • Geen geneste/effectieve oplossing: genest groepslidmaatschap of indirecte overname wordt niet behandeld als voldoende voor afdwinging. Zie de aanduiding in de gebruikersidentiteitsmodus van de OneLake-beveiliging voor een werkvoorbeeld.

• Gedrag van machtigingsevaluatie: machtigingsevaluatie verschilt per tabeltype op basis van het huidige afdwingingsmodel.

  • Snelkoppelingstabellen: Toegang kan worden geweigerd wanneer niet aan de vereiste autorisatievoorwaarden wordt voldaan. Dit is een beperkend afdwingingsresultaat, niet een op rollen gebaseerde DENY-functie in OneLake-beveiliging.

  • Algemene regel: wanneer afdwingen de toegang niet duidelijk kan valideren, past het systeem het meest beperkende resultaat toe.

• Column-Level Beveiligingsontwerp (CLS): CLS onderhoudt een strikte acceptatielijst met kolommen.

  • Als u de naam van een toegestane kolom wijzigt of verwijdert, wordt de beveiligingsregel ongeldig. Hoewel de regel zich blijft voordoen in het systeem, blijft deze inactief ( alle toegang tot de resource wordt geweigerd) totdat de oorspronkelijke kolomnaam is hersteld.

  • Synchronisatiebeveiliging: wanneer een beleid ongeldig is, wordt synchronisatie van metagegevens standaard geblokkeerd totdat de regel wordt gecorrigeerd in het OneLake-beveiligingsvenster.

  • Schemavalidatie: Als u de naam van kolommen wijzigt zonder beveiligingsbeleid bij te werken, worden gebruikersinterfacefouten geactiveerd die aangeven dat de kolom 'niet bestaat' totdat de configuratie is gesynchroniseerd.

• Rolpropagatie en synchronisatie (SLA):

  • OneLake-beveiligingssynchronisatie: wanneer een OneLake-beveiligingsrol verandert in de gebruikersidentiteitsmodus, is de update niet onmiddellijk. Hoewel het meestal snel duurt, kan het tot vijf minuten duren voordat het wordt gesynchroniseerd met het SQL-analyse-eindpunt.

  • Automatisch voorvoegsel: OneLake-beveiligingsrollen worden doorgegeven aan het SQL Analytics-eindpunt met het OLS_ voorvoegsel.

  • Synchronisatieprioriteit: Het beveiligingssynchronisatieproces vernieuwt regelmatig de status van OLS_ rollen. Handmatige wijzigingen in deze rollen worden niet ondersteund en worden overschreven tijdens de volgende synchronisatiecyclus. Als er geen wijzigingen in de synchronisatie zijn, overschrijft de beveiligingssynchronisatie geen handmatige wijzigingen.

• SQL-beveiliging en snelkoppelingen in het magazijn: beveiligingsbeleid dat is gedefinieerd met behulp van SQL-constructies in een warehouse, zoals Row-Level Security (RLS), Column-Level Security (CLS) of Object-Level Security (OLS), worden alleen afgedwongen binnen de SQL-uitvoeringscontext van het warehouse (TDS-eindpunt).

Beperkingen

• Alleen van toepassing op lezers: OneLake-beveiliging wordt voornamelijk afgedwongen voor gebruikers die toegang hebben tot gegevens via werkruimte of itemtoegang op viewerniveau. Gebruikers met bredere werkruimterollen, zoals Beheerder, Lid of Inzender , behouden verhoogde toegang en zijn niet het primaire doel van het afdwingen van OneLake-beveiliging.

  • Uitzonderingen:

    • Gedrag voor weigeren van snelkoppelingen: voor tabellen met snelkoppelingen kan afdwingen de toegang tot beheerders, leden of inzenders in specifieke gevallen nog steeds weigeren.

    • Gevallen van mislukking bij beveiligingssynchronisatie: als de beveiligingssynchronisatie de beveiliging niet correct toepast voor bepaalde tabellen of rollen, kunnen gebruikers in de rollen Admin, Lid of Inzender die lid zijn van de betrokken rollen, ook beperkte toegang ervaren.

    • Beveiliging op rijniveau in de gebruikersidentiteitsmodus: wanneer Row-Level Beveiliging (RLS) is geconfigureerd in de gebruikersidentiteitsmodus, worden de gedefinieerde beveiligingsregels afgedwongen voor alle gebruikers, inclusief die in de rollen Beheerder, Lid en Inzender.

• Afhankelijkheid van beveiligingssynchronisatie: In de gebruikersidentiteitsmodus worden OneLake-beveiligingsrollen gesynchroniseerd met het SQL Analytics-eindpunt via het beveiligingssynchronisatieproces. Totdat de synchronisatie is voltooid, kan SQL de toegang tijdelijk evalueren met behulp van de bestaande SQL-machtigingsstatus. Zodra de synchronisatie is voltooid, weerspiegelt het SQL-eindpunt de OneLake-beveiligingsconfiguratie.

• Kennis van snelkoppelingsgrenzen: het EINDPUNT van SQL Analytics kan in eerste instantie snelkoppelingstabellen evalueren met behulp van standaard semantiek van SQL-objecten. Nadat de beveiligingssynchronisatie is uitgevoerd, wordt OneLake-beveiligingsbeleid toegepast om ervoor te zorgen dat het afdwingen van toegang overeenkomt met artefact- en werkruimtegrenzen.

• Tijdsinstellingen voor het afdwingen van toegang door meerdere artefacten: Toegang tot tabellen die worden ondersteund door OneLake-snelkoppelingen die verwijzen naar gegevens van andere artefacten, wordt afgedwongen via gesynchroniseerde OneLake-beveiligingsrollen. Totdat de synchronisatie plaatsvindt, kan SQL-autorisatie tijdelijk de vorige machtigingsstatus weerspiegelen.

• Eigendomswijzigingen in tabellen met snelkoppelingen: tabellen met snelkoppelingen worden weergegeven als SQL-objecten in het SQL Analytics-eindpunt en bieden daarom ondersteuning voor standaardbewerkingen van SQL-eigendom. Beheeropdrachten, zoals ALTER AUTHORIZATION, kunnen de eigenaar wijzigen van een tabel die door een snelkoppeling wordt ondersteund. In bepaalde scenario's kan dit het eigendomsketengedrag toestaan dat oneLake-beveiligingsbeleid wordt overgeslagen en onbedoelde toegang verleent tot de onderliggende gegevens. Totdat er aanvullende afdwingingsmechanismen worden geïntroduceerd, moeten beheerders voorkomen dat het eigendom van tabellen met snelkoppelingen wordt gewijzigd.

• Downtime voor doelvalidatie: wanneer een snelkoppelingsdoel wordt gewijzigd (bijvoorbeeld naam wijzigen of URL-update), wordt de database kort in de modus voor één gebruiker ingevoerd terwijl het systeem het nieuwe doel valideert. Gedurende deze periode worden query's geblokkeerd. Deze bewerkingen zijn doorgaans snel, maar, afhankelijk van interne processen, kunnen tot vijf minuten duren voordat ze worden gesynchroniseerd.

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

• Tokencaching voor gedelegeerde modus: In de gedelegeerde modus slaat het SQL Analytics-eindpunt het opslagtoegangstoken op dat wordt gebruikt om gegevens op te halen uit OneLake namens de eigenaaridentiteit. Als de machtigingen van de eigenaar veranderen, kan een eerder uitgegeven token geldig blijven totdat het verloopt. Als gevolg hiervan worden toegangswijzigingen die zijn gekoppeld aan de identiteit van de eigenaar mogelijk niet onmiddellijk van kracht en kunnen ze zich blijven voordoen totdat het token verloopt, meestal tot 30 tot 60 minuten.

• Wijzigingen in OneLake-beveiligingsbeleid inzake toekennen/weigeren worden onmiddellijk afgedwongen en worden niet vertraagd door caching van opslagtokens.

• Annulering van actieve query's: Om de gegevensintegriteit en beveiliging te behouden, kunnen actieve query's automatisch worden geannuleerd als er tijdens de uitvoering een snelkoppelingconfiguratie wijzigt.

• beperkingen voor Row-Level Beveiliging (RLS):

  • Voor openbare preview worden alleen tabellen met één expressie ondersteund. Dynamische RLS en Multi-Table RLS zijn niet beschikbaar.

  • Als u een kolom verwijdert die wordt gebruikt in een filterexpressie, vertraagt de synchronisatie van metagegevens totdat de RLS is hersteld in het beveiligingspaneel van OneLake.

• Rolcomplexiteit en metagegevenssynchronisatie: een hoge complexiteit in beveiligingsrollen, met name die met betrekking tot talloze snijpunten en samenvoegingsemantiek met behulp van RLS, kan ertoe leiden dat de beveiligingssynchronisatie mislukt. Een mislukte beveiligingssynchronisatie voorkomt dat beveiligingsbeleid wordt toegepast en blokkeert de mogelijkheid om metagegevens te synchroniseren.

• Schema- en rolbeperkingen:

  • Hernoemingen: OneLake-beveiligingsrollen zijn gekoppeld aan de tabelnaam. Als u de naam van een tabel wijzigt, wordt de koppeling verbroken en worden beleidsregels niet automatisch gemigreerd. Dit kan leiden tot onbedoelde blootstelling van gegevens totdat beleid opnieuw wordt toegepast.

  • Tekenlimieten: Namen van OneLake-beveiligingsrollen mogen niet langer zijn dan 124 tekens; anders mislukt het maken of synchroniseren van rollen op het SQL Analytics-eindpunt.

  • OLS_ rolwijzigingen: gebruikerswijzigingen in OLS_ rollen worden niet ondersteund en kunnen onverwacht gedrag veroorzaken.

• Niet-ondersteunde identiteiten: beveiligingsgroepen en distributielijsten met e-mail worden momenteel niet ondersteund.

• Vereisten voor Lakehouse-eigenaars:

  • 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
• Beveiligingsmodel voor toegangscontrole van OneLake