Integrer Direct Lake-sikkerhed

Direct Lake-sikkerhed sikrer, at kun autoriserede brugere kan forespørge på Delta-tabeller i OneLake. Du kan administrere tilladelser til dataadgang via arbejdsområderoller. Bidragydere, medlemmer og administratorer til arbejdsområder kan læse data i OneLake. Du kan også give adgang til dataene i OneLake via tilladelser på elementniveau og beregning. Den tredje mulighed er at udnytte OneLake-sikkerhed til at gennemtvinge detaljeret rollebaseret sikkerhed på tværs af alle Fabric-beregningsprogrammer. I denne artikel forklares det, hvordan du justerer tilladelsesmodeller, vælger enkeltlogon (SSO) eller faste identiteter og udnytter sikkerhed på objektniveau (OLS) og sikkerhed på rækkeniveau (RLS). Få mere at vide i Oversigt over OneLake-sikkerhed.

Nøglebegreber og terminologi

I denne artikel antages det, at du er bekendt med disse begreber:

• Direct Lake bruger delte M-udtryk i metadata for den semantiske model til at referere til datakilder via Power Query-dataadgangsfunktioner: AzureStorage.DataLake for Direct Lake på OneLake og Sql.Database for Direct Lake på SQL-slutpunkter. Direct Lake bruger dog ikke disse funktioner til at læse Delta-kildetabellerne. Den læser Delta-tabellerne direkte via OneLake-API'er.
• For at sikre, at det kun er autoriserede brugere, der forespørger på dataene, kontrollerer Direct Lake dataadgangstilladelserne for den effektive identitet. Den effektive identitet afhænger af konfigurationen af dataforbindelsen. Direct Lake bruger som standard SSO (Microsoft Entra ID) og bruger identiteten for den aktuelle bruger, der forespørger på den semantiske model. Du kan også binde en Direct Lake-model til en eksplicit cloudforbindelse for at angive en fast identitet.
• Hvis du giver dataadgangstilladelser via arbejdsområderoller, er det kun medlemmer af rollen Bidragydere (eller højere), der kan læse data i OneLake. Arbejdsområdefremvisere har dog ikke læsetilladelse i OneLake. Seere og brugere, der ikke er medlemmer af en arbejdsområderolle, kan få læseadgang via en kombination af elementtilladelser, beregningstilladelser eller OneLake-sikkerhedsroller.
• OneLake-sikkerhed giver medlemmer af rollerne Arbejdsområdeadministrator og Arbejdsområdemedlem mulighed for at definere detaljeret rollebaseret sikkerhed for brugere i rollen Seer. Angiv de tabeller, som en fremviser eller bruger med eksplicit læsetilladelse kan få adgang til og udelade bestemte rækker eller kolonner. Du kan få mere at vide om OneLake-sikkerhedsroller under Tabelsikkerhed i OneLake, Sikkerhed på kolonneniveau i OneLake og sikkerhed på rækkeniveau i OneLake.

Konfiguration af forbindelse

Konfigurer dataforbindelser for en Direct Lake-model på samme måde som andre semantiske modeltyper. Se Opret forbindelse til clouddatakilder i Power BI-tjeneste for at få flere oplysninger.

Da Direct Lake kun opretter forbindelse til Fabric-datakilder, fungerer standardkonfigurationen af SSO (Microsoft Entra ID) normalt, så du ikke behøver at binde semantiske modeller til eksplicitte dataforbindelser. Denne fremgangsmåde reducerer konfigurationskompleksiteten og sænker administrationsomkostningerne.

Med SSO (Microsoft Entra ID) kontrollerer Direct Lake, at den aktuelle bruger, der forespørger på den semantiske model, har læseadgang til dataene. Det er kun brugere med læseadgang , der kan forespørge på dataene. På følgende skærmbillede vises en Direct Lake-model, der bruger standardkonfigurationen af SSO.

Når du bruger en eksplicit dataforbindelse med en fast identitet i stedet for SSO, kræver Direct Lake ikke, at alle brugere har læsetilladelse til de underliggende data. Hvis Microsoft Entra SSO forbliver deaktiveret i dataforbindelsen, bestemmer den faste identitets tilladelser, hvilke data Direct Lake har adgang til.

Notat

Du kan konfigurere en dataforbindelse til at bruge både SSO og en fast identitet. Direct Lake kontrollerer den aktuelle brugers tilladelser på forespørgselstidspunktet og bruger den faste identitet til framing og omkodning på opdateringstidspunktet. Hvis du vil bruge en fast identitet til både forespørgsler og opdateringer, skal du sørge for, at SSO er deaktiveret i dataforbindelseskonfigurationen.

Krav til godkendelse

Direct Lake-modeller bruger Microsoft Entra ID-godkendelse. I konfigurationen af dataforbindelsen skal du vælge OAuth 2.0, Tjenesteprincipal eller Arbejdsområdeidentitet som godkendelsesmetode. Andre metoder, f.eks. nøgle- eller SAS-godkendelse, vises muligvis i konfigurationsbrugergrænsefladen, men understøttes ikke for Direct Lake-modeller.

Tilladelseskrav

Tilladelseskravene varierer mellem Direct Lake på SQL-slutpunkter og Direct Lake på OneLake. Det skyldes, at Direct Lake på SQL-slutpunkter er afhængige af SQL Analytics-slutpunktet for destinationskilden, mens Direct Lake på OneLake bruger OneLake-API'erne til tilladelseskontrol.

Direct Lake på SQL-slutpunkter

Direct Lake på SQL-slutpunkter udfører tilladelseskontrol via SQL-analyseslutpunktet for at afgøre, om den effektive identitet, der forsøger at få adgang til dataene, har de nødvendige tilladelser til dataadgang. Det er bemærkelsesværdigt, at den effektive identitet ikke behøver tilladelse til at læse Delta-tabeller direkte i OneLake. Det er nok at have læseadgang til Fabric-artefaktet, f.eks. et søhus, og SELECT-tilladelse på en tabel via dets SQL-analyseslutpunkt. Det skyldes, at Fabric giver de nødvendige tilladelser til den semantiske model til at læse Delta-tabellerne og tilknyttede Parquet-filer (for at indlæse kolonnedata i hukommelsen). Den semantiske model har tilladelse til regelmæssigt at læse SQL-analyseslutpunktet for at kontrollere, hvilke data den forespørgende bruger (eller faste identitet) har adgang til.

Direkte sø på OneLake

Direct Lake på OneLake bruger ikke et SQL-analyseslutpunkt til tilladelseskontrol. Den bruger OneLake Security. Når OneLake Security er aktiveret, bruger Direct Lake på OneLake den aktuelle bruger (eller faste identitet) til at løse OneLake-sikkerhedsroller og gennemtvinge OLS og RLS på destinationsstrukturartefaktet. Hvis OneLake Security ikke er aktiveret, kræver Direct Lake på OneLake, at den effektive identitet har læse- og læsealletilladelser på destinationsstrukturartefaktet for at få adgang til dens Delta-tabeller i OneLake. Du kan finde flere oplysninger om læse- og læsealletilladelser i afsnittet Elementtilladelser i artiklen Oversigt over OneLake-sikkerhed.

Notat

Bidragydere (eller højere) har læse- og læsealletilladelser i OneLake. Seere og brugere, der ikke er medlemmer af en arbejdsområderolle, skal tildeles læse- og læsealletilladelser eller føjes til en OneLake-sikkerhedsgruppe. Du kan finde flere oplysninger om administration af OneLake-sikkerhedsgrupper under OneLake-model for dataadgangskontrol.

Direkte Lake-brugere

Følgende scenarier viser minimumskrav til tilladelser.

Scenarie	Direct Lake på SQL-slutpunkter	Direkte sø på OneLake	Comments
Brugere kan se rapporter	- Giv læsetilladelse til rapporterne og læsetilladelse til den semantiske model. - Hvis Direct Lake bruger SSO, skal du give brugerne mindst læsetilladelse til destinationsstrukturartefaktet og SELECT-tilladelser til tabellerne.	- Giv læsetilladelse til rapporterne og læsetilladelse til den semantiske model. - Hvis Direct Lake bruger SSO, skal du give brugerne mindst læsetilladelse til destinations-Fabric-artefaktet og føje dem til en OneLake-sikkerhedsrolle eller give dem ReadAll-tilladelse .	Rapporter behøver ikke at tilhøre det samme arbejdsområde som den semantiske model. Du kan få flere oplysninger under Strategi for skrivebeskyttede forbrugere.
Brugere kan oprette rapporter	- Giv tilladelsen Opret til den semantiske model. - Hvis Direct Lake bruger SSO, skal du give brugerne mindst læsetilladelse til destinationsstrukturartefaktet og SELECT-tilladelser til tabellerne.	- Giv tilladelsen Opret til den semantiske model. - Hvis Direct Lake bruger SSO, skal du give brugerne mindst læsetilladelse til destinations-Fabric-artefaktet og føje dem til en OneLake-sikkerhedsrolle eller give dem ReadAll-tilladelse .	Brugere kan kun oprette rapporter på de tabeller og kolonner, de har adgang til. Dette kan være en delmængde af det fulde sæt af tabeller og kolonner i modellen. Du kan finde flere oplysninger under Strategi for indholdsoprettere.
Brugere kan forespørge på den semantiske model, men nægtes at forespørge på lakehouse- eller SQL-analyseslutpunktet	- Bind Direct Lake-modellen til en cloudforbindelse med en fast identitet, og lad SSO være deaktiveret. - Giv den faste identitet mindst læsetilladelse til destinationsartefaktet Fabric og SELECT-tilladelser til tabellerne. - Giv ikke brugerne tilladelse til målartefaktet Fabric.	- Bind Direct Lake-modellen til en cloudforbindelse med en fast identitet, og lad SSO være deaktiveret. - Giv den faste identitet mindst læsetilladelse til destinationsstrukturartefaktet, og føj den til en OneLake-sikkerhedsrolle, eller giv den ReadAll-tilladelse . - Giv ikke brugerne tilladelse til målartefaktet Fabric.	Kun egnet, når cloud-forbindelsen bruger en fast identitet.
Brugere kan forespørge på den semantiske model og SQL-analyseslutpunktet, men nægtes forespørgsler på søhuset	- Giv læse- og læsedatatilladelser til destinationsstofartefaktet.	Ikke anvendelig.	Vigtigt!: Forespørgsler, der sendes til SQL Analytics-slutpunktet, omgår dataadgangstilladelser, der gennemtvinges af den semantiske model.
Administrer den semantiske model, herunder opdateringsindstillinger	- Kræver ejerskab af semantisk model.	- Kræver ejerskab af semantisk model.	Du kan få flere oplysninger under Semantisk modelejerskab.

Vigtigt

Test altid tilladelser, før du frigiver din semantiske model og rapporter til produktion.

Du kan få flere oplysninger under Semantiske modeltilladelser.

Direkte ejere af søen

Ud over den effektive identitet (aktuel bruger eller fast identitet) kræver Direct Lake også, at ejeren af den semantiske model har læseadgang til kildetabellerne, så Direct Lake kan indramme den semantiske model som en del af dataopdateringen. Uanset hvem der opdaterer en Direct Lake-model, kontrollerer Direct Lake ejerens tilladelse for at sikre, at modellen har tilladelse til at få adgang til dataene. Ejerens krav til dataadgangstilladelser er de samme som for brugere, der forespørger modellen.

Hvis ejeren af den semantiske model ikke har de påkrævede tilladelser til dataadgang, udløser Direct Lake følgende fejl under indramning: We cannot refresh this semantic model because one or multiple source tables either do not exist or access was denied. Please contact a data source admin to verify that the tables exist and ensure that the owner of this semantic model does have read access to these tables. Some restricted tables including fully restricted and partially restricted (indicating column constraints): '\<list of tables\>'.

Genveje til kildetabeller

Genveje er OneLake-objekter, som du føjer til et stofsøhus eller en anden stofartefakt for at pege på interne eller eksterne lagringssteder. I en Direct Lake-model vises Delta-tabeller, der tilføjes via genveje, som oprindelige i den tilsluttede Fabric-artefakt, fordi genveje er gennemsigtige, når du får adgang til data via OneLake-API'en.

Når du får adgang til genveje via Direct Lake over SQL-slutpunkter, validerer Direct Lake først, at den effektive identitet (aktuel bruger eller fast identitet) kan få adgang til tabellen i den semantiske models datakilde. I forbindelse med interne genveje bruger Direct Lake datakildeejerens identitet til at læse Delta-tabellen gennem genvejen ved tabellens Fabric-artefakt. Ejeren af datakilden skal have adgangstilladelse på destinations-OneLake-placeringen. I forbindelse med eksterne genveje skal ejeren af datakilden også have tilladelsen Brug på cloudforbindelsen til det eksterne system, der er vært for Delta-tabellen. Du kan få flere oplysninger under OneLake-genveje.

Direct Lake over OneLake har forskellige tilladelseskrav, fordi SQL Analytics-slutpunktet ikke er involveret. Når en bruger får adgang til data via en intern genvej til en anden OneLake-placering, skal den effektive identitet (aktuel bruger eller fast identitet) have tilladelse på destinationsplaceringen. Den effektive identitet skal være bidragyder (eller højere), have læse- og læsealletilladelser eller være i en OneLake-sikkerhedsrolle, der giver læseadgang .

Sikkerhed på objektniveau (OLS) og sikkerhed på rækkeniveau (RLS)

Både OneLake Security- og Direct Lake-modellerne understøtter OLS og RLS. OLS gør det muligt for artefaktejere og -administratorer at sikre bestemte tabeller eller kolonner. Sikkerhed på rækkeniveau kan bruges til at begrænse dataadgang på rækkeniveau baseret på filtre. Du kan definere OLS og sikkerhed på rækkeniveau i OneLake Security, i en Direct Lake-model eller på begge placeringer.

Vigtigt

Direct Lake understøtter ikke SQL Analytics Endpoint OLS/RLS. Hvis du vil returnere korrekte data, falder Direct Lake over SQL-slutpunkter tilbage til DirectQuery-tilstand, hvis en Fabric-artefakt bruger OLS eller RLS. Hvis DirectQuery-fallback er deaktiveret, mislykkes forespørgsler via SQL-slutpunkter, når OLS/RLS er defineret på SQL Analytics-slutpunktet. Direct Lake over OneLake undgår denne begrænsning.

Direkte sø på OneLake OLS/RLS med OneLake Security OLS/RLS

Direct Lake på OneLake evaluerer adgangen til OLS/RLS-sikrede objekter ved at løse den effektive identitets OneLake-sikkerhedsroller og anvende de definerede OLS/RLS-regler. OneLake-sikkerhedsrollerne håndteres på samme måde som Direct Lake-roller. Hvis den effektive identitet tilhører flere roller i OneLake Security og Direct Lake, forener Direct Lake først OneLake Security-rollerne og skærer derefter resultatet med Direct Lake-rollerne.

Denne tabel viser almindelige fejlfindingssituationer, der skyldes modstridende OneLake-sikkerheds- og Direct Lake-regler.

Scenarie	Comments
Ingen linjer returneres på grund af RLS-filtrering	Hvis den effektive identitet mangler adgangstilladelser på rækkeniveau, kan forespørgsler returnere tomme resultater. Dette problem forventes, når RLS-filtre udelader alle rækker for den aktuelle bruger.
Kan ikke finde tabel Kolonnen blev ikke fundet Navn kunne ikke fortolkes Ikke et gyldigt tabel-, variabel- eller funktionsnavn	Disse fejl opstår normalt, når objekttilladelser mangler efter anvendelse af OneLake-sikkerhedsroller.

Forskelle i OLS/RLS-omfang

Håndhævelse af OLS og sikkerhed på rækkeniveau i OneLake Security anvender reglerne på tværs af alle beregningsprogrammer og sikrer samlet adgangskontrol for brugerne. Det betyder, at uanset beregningsprogrammet – lakehouse, lagersted, semantisk model eller anden artefakt – styrer OneLake Security-regler brugerens dataadgang. I modsætning hertil finder OLS/RLS, der er defineret i en Direct Lake-semantisk model, kun anvendelse inden for rammerne af den pågældende model. Andre beregningsprogrammer anvender ikke disse Direct Lake-sikkerhedsregler, som kan give forskellige resultater, når brugerne får adgang til dataene via andre stier.

Vigtigt

Når du bruger både OneLake Security OLS/RLS og Direct Lake OLS/RLS, kan brugere, der har OneLake-adgang, stadig hente og arbejde med dataene – selvom Direct Lake-modelregler begrænser dataene yderligere – fordi regler på modelniveau ikke strækker sig ud over modellen. Brug OneLake Security til omfattende adgangskontrol på tværs af alle beregningsprogrammer.

OneLake OLS og metadata for semantiske modeller

Metadata for semantisk model omfatter definitioner af tabeller, kolonner, relationer og andre skemaelementer. Brugere med build-tilladelser eller højere tilladelser kan få vist modelmetadataene via XMLA (XMLA) og REST API'er. Du kan få flere oplysninger under Semantiske modeltilladelser.

Hvis du vil beskytte følsomme tabel- og kolonnenavne i OneLake med OneLake OLS, skal du huske, at OneLake Security kun gælder for medlemmer af arbejdsområdets fremviserrolle. OneLake OLS forhindrer ikke medlemmer af arbejdsområderollen Bidragyder (eller højere) i at finde sikrede tabeller eller kolonner, fordi de allerede har skrivetilladelse til alle arbejdsområdeartefakter. Medlemmer af rollen Fremviser med build-tilladelser eller højere tilladelser på en Direct Lake-model kan finde følsomme skemaoplysninger via metadataene for den semantiske model. Disse højere privilegerede seere har stadig ikke dataadgang, men de kan se, at de sikrede tabeller og kolonner findes.

Der findes muligvis en Direct Lake-model i det samme arbejdsområde som kildeartefaktet eller i et separat arbejdsområde. Giv en fremviser i det samme arbejdsområdebuild (eller højere) adgang til en Direct Lake-model via elementtilladelser. I et separat arbejdsområde kan en bruger være bidragyder (eller højere) eller have build-elementtilladelser (eller højere) til at få adgang til modelmetadataene.

OneLake OLS- og Git-integration

Git-integration gør det muligt for udviklere at integrere deres ALM-processer (Application Lifecycle Management) i Fabric-platformen. Git-lageret bevarer arbejdsområdestrukturen, herunder alle understøttede artefakter. Udviklere har fuld synlighed over metadataene for alle deres elementer i Git-lageret. Direct Lake-modelmetadata giver dem mulighed for at se, at der findes sikrede tabeller eller kolonner, selvom de ikke har adgang til destinationsdatakilden i et andet arbejdsområde. Du kan få flere oplysninger under Hvad er Microsoft Fabric Git-integration?

Overvejelser og begrænsninger

Overvej disse Direct Lake-sikkerhedsbegrænsninger.

Notat

Funktionerne og funktionerne i Direct Lake-semantiske modeller og OneLake-sikkerhed udvikler sig hurtigt. Vend tilbage med jævne mellemrum for opdateringer.

• Tildel arbejdsområdefremvisere OneLake-sikkerhedsroller, der giver læseadgang til kilde-Fabric-artefakterne. Hvis en kildeartefakt har genveje til en anden Fabric-artefakt, skal brugeren også have læseadgang til hver genvejs målartefakt.
• Brug en fast identitet til at isolere brugere fra en kildeartefakt af typen Fabric. Bind Direct Lake-modellen til en cloudforbindelse. Hold SSO deaktiveret på cloudforbindelsen for at bruge den faste identitet til opdateringer og forespørgsler.
• Direct Lake-semantiske modeller, der er afhængige af Fabric OneLake-sikkerhed på kildeartefaktet, understøtter ikke sikkerhedskopieringshandlinger.
• Tovejsrelationer understøttes ikke i en Direct Lake-model, hvis kildeartefaktet er afhængig af OneLake-sikkerhedssikkerhed på rækkeniveau.
• Under den offentlige prøveversion understøtter OneLake-sikkerhed kun statisk sikkerhed på sikkerhed på rækkeniveau på en enkelt tabel.
• Under den offentlige prøveversion understøtter OneLake-sikkerhed ikke dynamiske definitioner eller komplekse rollekonfigurationer, f.eks. kombination af flere OLS- og RLS-roller på tværs af relaterede tabeller.
• Konsolider OneLake-sikkerhed RLS- og OLS-tilladelser til én rolle pr. bruger i stedet for at tildele flere roller.
• Hvis OneLake-sikkerhedskonfigurationen ændres, f.eks. på grund af genvejsændringer i destinationsartefaktet, skal du opdatere Direct Lake på OneLake-modeller, der har adgang til den pågældende artefakt. Hvis automatisk synkronisering er aktiveret, opdaterer tjenesten dem normalt automatisk. Ellers skal du opdatere modellerne manuelt.
• Hvis et Lakehouse har OneLake-sikkerhed:
  • SQL-analyseslutpunktet er som standard fast identitet til ejeren af Lakehouse, så SQL-analyseslutpunktets OneLake-sikkerhed er den samme som ejeren (ingen begrænsninger). Direct Lake på SQL fortsætter med at bruge Direct Lake, medmindre der tilføjes ekstra SQL-granulære adgangsroller.
  • SQL-analyseslutpunktet kan ændres til SSO. Når dette sker, tilføjes OneLake-sikkerhedsroller som detaljerede SQL-adgangskontrolregler, og brugeren blokeres fra at redigere dem direkte på SQL-analyseslutpunktet. På dette tidspunkt falder Direct Lake på SQL tilbage til DirectQuery 100% af tiden.