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.

Skærmbillede af Direct Lake-modelforbindelsesindstillinger, der viser standard Microsoft Entra ID SSO aktiveret til dataadgang.

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.

Skærmbillede af Direct Lake-modelforbindelsesindstillinger med Microsoft Entra-id SSO deaktiveret og en fast identitet valgt.

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.

Tips

Brug SSO til interaktive scenarier, hvor godkendelse pr. bruger er påkrævet. Brug en cloud-forbindelse med fast identitet til indlejrede eller skrivebeskyttede forbrugerscenarier, hvor kildeadgangen er begrænset til en enkelt servicekonto. Anvend least-privilege-principperne både på kilde- og arbejdsområdeniveau, og test og valider adfærd for begge autentificeringstilstande før produktionsimplementering.

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. Denne forskel eksisterer, fordi Direct Lake på SQL-endpoints er afhængig af SQL Analytics Endpoint fra måldatakilden, mens Direct Lake på OneLake bruger OneLake API'er til tilladelsestjek.

Direct Lake på SQL-slutpunkter

Direct Lake på SQL-endpoints tjekker tilladelser gennem SQL analytics-endpointet for at se, om den effektive identitet, der forsøger at få adgang til dataene, har de rigtige tilladelser. Den effektive identitet behøver ikke tilladelse for at læse Delta-tabeller direkte i OneLake. Den behøver kun læseadgang til Fabric-elementet, som et lakehouse, og SELECT-tilladelse på en tabel gennem sit SQL-analyse-endpoint. Fabric giver den semantiske model de tilladelser, den har brug for til at læse Delta-tabellerne og relaterede Parquet-filer for at indlæse kolonnedata i hukommelsen. Den semantiske model kan regelmæssigt læse SQL-analyse-endpointet for at tjekke, hvilke data den forespørgende bruger (eller den faste identitet) kan tilgå.

Direkte sø på OneLake

Direct Lake på OneLake bruger ikke et SQL-analyse-endpoint til at tjekke tilladelser. Den bruger OneLake sikkerhed. Når OneLake-sikkerhed er slået til, bruger Direct Lake på OneLake den nuværende bruger (eller den faste identitet) til at finde OneLake-sikkerhedsroller og håndhæve OLS og RLS på det målrettede Fabric-element. Hvis OneLake-sikkerheden ikke er aktiveret, skal Direct Lake på OneLake have den effektive identitet for at have læse- og læsetilladelser på det målrettede Fabric-element for at få adgang til dets Delta-tabeller i OneLake. For mere information om Læs- og LæsAlle-tilladelser, se Del elementer og sæt elementniveau-tilladelser.

Notat

Bidragydere (eller højere) har læse- og læsealletilladelser i OneLake. Brugere og brugere uden at være medlemmer af en arbejdsområderolle skal have læse- og læsealle-tilladelser eller blive tilføjet 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, giv brugerne mindst læsetilladelse for mål-Fabric-elementet og SELECT-tilladelser for tabellerne.		 - Giv læsetilladelse til rapporterne og læsetilladelse til den semantiske model.
- Hvis Direct Lake bruger SSO, giv brugerne mindst læsetilladelse for mål-Fabric-elementet og tilføj dem til en OneLake-sikkerhedsrolle eller giv 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, giv brugerne mindst læsetilladelse for mål-Fabric-elementet og SELECT-tilladelser for tabellerne.		 - Giv tilladelsen Opret til den semantiske model.
- Hvis Direct Lake bruger SSO, giv brugerne mindst læsetilladelse for mål-Fabric-elementet og tilføj dem til en OneLake-sikkerhedsrolle eller giv dem ReadAll-tilladelse.		 Brugere kan kun oprette rapporter på de tabeller og kolonner, de har adgang til. Denne betingelse 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 for det målte Fabric-element og SELECT-tilladelser for tabellerne.
- Giv ikke brugerne nogen tilladelse til det målrettede Fabric-objekt.		 - Bind Direct Lake-modellen til en cloudforbindelse med en fast identitet, og lad SSO være deaktiveret.
- Giv den faste identitet mindst læsetilladelse for mål-Fabric-elementet og tilføj den til en OneLake-sikkerhedsrolle eller giv den ReadAll-tilladelse.
- Giv ikke brugerne nogen tilladelse til det målrettede Fabric-objekt.		 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æsedata-tilladelser for mål-Fabric-elementet. Ikke anvendelig. Vigtigt: Forespørgsler sendt til SQL-analyse-endpointet omgår dataadgangstilladelser, som den semantiske model håndhæver.
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 (nuværende bruger eller fast identitet) kræver Direct Lake, at ejeren af den semantiske model har læseadgang til kildetabellerne, så Direct Lake kan indramme den semantiske model som en del af dataopdatering. 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 tilføjer til et Fabric lakehouse eller et andet Fabric-objekt for at pege på interne eller eksterne opbevaringssteder. I en Direct Lake-model fremstår Delta-tabeller tilføjet via genveje som native i det tilknyttede Fabric-element, fordi genveje er gennemsigtige, når du tilgår 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. For interne genveje, efter at denne kontrol er bestået, bruger Direct Lake datakildeejerens identitet til at læse Delta-tabellen gennem genvejen ved tabellens Fabric-element. 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.

Skærmbillede af diagram, der viser Direct Lake, der validerer den effektive identitet og derefter bruger datakildeejeridentitet til at få adgang til intern eller ekstern genvejsdestination.

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-sikkerheds- og Direct Lake-modellerne understøtter OLS og RLS. OLS gør det muligt for item-ejere og administratorer at sikre specifikke 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 RLS i OneLake-sikkerhed, i en Direct Lake-model eller i begge lokationer.

Vigtigt

Direct Lake understøtter ikke SQL analytics endpoint OLS/RLS i hukommelsen. Direct Lake over SQL-endpoints håndterer disse begrænsninger forskelligt afhængigt af typen. Hvis en forespørgsel rører ved en tabel eller kolonne, der er begrænset af SQL analytics endpoint OLS eller kolonne-niveau sikkerhed (CLS), returnerer forespørgslen en fejl. Hvis en forespørgsel refererer til en tabel, der håndhæver RLS eller en visning ved SQL-analyse-endpointet, falder forespørgslen tilbage til DirectQuery-tilstand. Hvis DirectQuery-fallback er deaktiveret, fejler forespørgsler, der afhænger af RLS eller visninger over SQL-endpoints. Direct Lake over OneLake undgår disse begrænsninger. For detaljer, se Hvordan forespørgsler evalueres i Direct Lake på SQL.

Direct Lake på OneLake OLS/RLS med OneLake sikkerheds-OLS/RLS

Direct Lake på OneLake evaluerer adgang 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-rollerne. Hvis den effektive identitet tilhører flere roller i OneLake-sikkerhed og Direct Lake, sammenlægger Direct Lake først OneLake-sikkerhedsrollerne og krydser derefter resultatet med Direct Lake-rollerne.

Denne tabel viser almindelige fejlfindingssituationer forårsaget af konflikt mellem 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 RLS i OneLake-sikkerhed anvender reglerne på tværs af alle compute-motorer og sikrer samlet adgangskontrol for brugerne. Det betyder, at uanset hvilken beregningsmotor – lakehouse, lager, semantisk model eller andet element – styrer OneLake-sikkerhedsreglerne 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 sikkerheds-OLS/RLS og Direct Lake OLS/RLS, kan brugere med OneLake-adgang stadig hente og arbejde med dataene – selvom Direct Lake-modelreglerne yderligere begrænser data – fordi modelniveau-regler ikke rækker ud over modellen. Brug OneLake-sikkerhed til omfattende adgangskontrol på tværs af alle compute-motorer.

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.

For at beskytte følsomme tabel- og kolonnenavne i OneLake med OneLake OLS, husk at OneLake-sikkerhed kun gælder for medlemmer af arbejdsområdets Viewer-rolle. OneLake OLS forhindrer ikke medlemmer af bidragyder- (eller højere) arbejdsområde-rollen i at opdage sikrede tabeller eller kolonner, fordi de allerede har skrive-tilladelse til alle arbejdsområdeelementer. 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.

En Direct Lake-model kan eksistere i samme arbejdsområde som kildeelementet 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-repositoryet bevarer arbejdsområdets struktur, inklusive alle understøttede elementer. 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?

Hvordan forespørgsler evalueres i Direct Lake på SQL

Grunden til at udvikle semantiske Direct Lake-modeller er at opnå forespørgsler med høj ydeevne over store datamængder i OneLake. Derfor bør du bestræbe dig på at designe en løsning, der maksimerer chancerne for forespørgsler i hukommelsen.

De følgende trin tilnærmer sig, hvordan Direct Lake på SQL-forespørgsler evalueres (og om de fejler). Fordelene ved Direct Lake-lagringstilstanden er kun mulige, når det femte trin er nået.

  1. Hvis forespørgslen indeholder en tabel eller kolonne, der er begrænset af den semantiske model OLS, returneres der et fejlresultat (rapportvisualiseringer kan ikke gengives).
  2. Hvis forespørgslen indeholder en kolonne, der er begrænset af SQL Analytics-slutpunktet CLS (eller tabellen afvises), returneres der et fejlresultat (rapportvisualiseringer kan ikke gengives).
    1. Hvis cloudforbindelsen bruger SSO (standard), bestemmes CLS af rapportforbrugerens adgangsniveau.
    2. Hvis cloudforbindelsen bruger en fast identitet, bestemmes CLS af adgangsniveauet for den faste identitet.
  3. Hvis den semantiske model bruger Direct Lake på SQL-endpoints, og forespørgslen indeholder en hvilken som helst tabel i SQL-analyseendpointet, der håndhæver RLS, eller der bruges en visning, falder forespørgslen tilbage til DirectQuery-tilstand.
    1. Hvis cloudforbindelsen bruger SSO (standard), bestemmes sikkerhed på rækkeniveau af adgangsniveauet for rapportforbruger.
    2. Hvis cloudforbindelsen bruger en fast identitet, bestemmes sikkerhed på rækkeniveau af adgangsniveauet for den faste identitet.
  4. Hvis forespørgslen overskrider gelænderne for kapaciteten, går den tilbage til DirectQuery-tilstand.
  5. Ellers opfyldes forespørgslen fra cachen i hukommelsen. Kolonnedata indlæses i hukommelsen , når det er nødvendigt.

Vigtigt

Direct Lake på OneLake understøtter ikke fallback til DirectQuery-tilstand. Hvis en tabel i SQL-analyse-endpointet håndhæver RLS, eller forespørgslen overskrider kapacitetens sikkerhedsrammer, returneres et fejlresultat (rapportvisualiseringer kan ikke gengives).

Indstillinger for dataadgangsregel

Du kan konfigurere regler for dataadgang i:

  • Den semantiske model.
  • SQL analytics-endpointet (Direct Lake kun på SQL-endpoints).
  • OneLake sikkerhed.

Regler i den semantiske model

Hvis du skal håndhæve dataadgangsregler, så gør det i OneLake-sikkerhed, så reglerne gælder på tværs af alle compute-motorer og sikrer samlet adgangskontrol for brugerne. Brug semantisk model RLS eller OLS, når rapportforbrugere ikke får tilladelse til at forespørge lakehouse eller warehouse, og cloud-forbindelsen bruger en fast identitet i stedet for SSO. SSO indebærer, at slutbrugere kan få direkte adgang til datakilden og derfor kan omgå sikkerhedsregler i den semantiske model.

Vigtigt

Tilladelser for semantiske modelelement kan angives eksplicit via Power BI-apps eller erhverves implicit via arbejdsområderoller.

Bemærkelsesværdigt håndhæves reglerne for dataadgang til semantiske modeller ikke for brugere, der har skrivetilladelse på den semantiske model. Omvendt gælder regler for dataadgang for brugere, der er tildelt rollen Fremviser i arbejdsområdet. Dog har brugere, der er tildelt rollen som Admin, Medlem eller Bidragyder , implicit Skrive-tilladelse på den semantiske model, og derfor håndhæves dataadgangsregler ikke. For mere information, se Roller i arbejdsområder.

Regler på flere lag

Du kan håndhæve dataadgangsregler på alle lag. Denne tilgang omfatter dog ekstra kompleksitet og administrationsomkostninger. I dette tilfælde skal du bruge en fast identitet til cloud-forbindelsen i stedet for SSO.

Sammenlign dataadgangsregelmuligheder

Følgende tabel sammenligner dataadgangsopsætningsmuligheder for Direct Lake på SQL-endpoints og Direct Lake på OneLake.

Anvend regler for dataadgang på Direct Lake på SQL Direkte sø på OneLake Bemærkning
Kun semantisk model Understøttet Understøttet Brug denne indstilling, når brugerne ikke får tildelt elementtilladelser til at forespørge lakehouse eller warehouse. Konfigurer cloudforbindelsen for at bruge en fast identitet. Opnået høj forespørgselsydelse fra cachen i hukommelsen.
Kun SQL-analyseslutpunkt Understøttet (falder tilbage på DirectQuery) Ikke anvendelig Det afhænger af, at Fabric-dataelementet (som Lakehouse eller Warehouse) bruger delegeret identitetstilstand. Brug denne indstilling, når brugerne har brug for at få adgang til data fra enten lageret eller den semantiske model og med ensartede regler for dataadgang. Sørg for, at SSO er aktiveret for cloudforbindelsen. Forespørgselsydelsen kan være langsom på grund af DirectQuery-fallback.
Kun OneLake sikkerhed Ikke anvendelig Understøttet Brug denne mulighed for samlet adgangskontrol på tværs af alle Fabric-beregningsmotorer. OneLake-sikkerhed håndhæver OLS og RLS konsekvent for alle brugere, der tilgår dataene via enhver sti. Opnået høj forespørgselsydelse fra cachen i hukommelsen.
Flere lag (semantisk model og SQL-endpoint) Understøttet Ikke anvendelig Denne indstilling omfatter ekstra administrationsomkostninger. Konfigurer cloudforbindelsen for at bruge en fast identitet.
Flere lag (semantisk model og OneLake-sikkerhed) Ikke anvendelig Understøttet OneLake-sikkerhedsregler anvendes først, derefter semantiske modelregler. Overvej at konsolidere regler på ét lag for at reducere kompleksiteten.

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 workspace-viewere OneLake-sikkerhedsroller, der giver læseadgang til kilde-Fabric-elementerne. Hvis et kildeelement har genveje til et andet Fabric-item, har brugeren også brug for læseadgang til hver genvejs mål-Fabric-item.
  • Brug en fast identitet til at isolere brugere fra et kilde-Fabric-element. 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å kildeelementet, understøtter ikke backup-operationer.
  • Tovejsrelationer understøttes ikke i en Direct Lake-model, hvis kilde-Fabric-elementet er afhængigt af OneLake-sikkerheds-RLS.
  • OneLake-sikkerhed understøtter ikke dynamiske definitioner eller komplekse rollekonfigurationer, såsom at kombinere 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, for eksempel på grund af genvejsændringer i målobjektet, skal Direct Lake opdateres på OneLake-modeller, der tilgår det pågældende element. Du skal opdatere modellerne manuelt eller ved at bruge opdaterings-API'er.
  • 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.
  • Last updated on