Integrer Direct Lake-sikkerhet

Direct Lake-sikkerhet sikrer at bare autoriserte brukere kan spørre Delta-tabeller i OneLake. Du kan administrere datatilgangstillatelser gjennom arbeidsområderoller. Bidragsytere, medlemmer og administratorer for arbeidsområder kan lese data i OneLake. Du kan også gi tilgang til dataene i OneLake gjennom elementnivå og databehandlingstillatelser. Det tredje alternativet er å utnytte OneLake-sikkerhet for å håndheve detaljert rollebasert sikkerhet på tvers av alle Fabric-databehandlingsmotorer. Denne artikkelen forklarer hvordan du justerer tillatelsesmodeller, velger enkel pålogging (SSO) eller faste identiteter og utnytter sikkerhet på objektnivå (OLS) og sikkerhet på radnivå (RLS). Finn ut mer i Oversikt over OneLake-sikkerhet.

Nøkkelkonsepter og terminologi

Denne artikkelen forutsetter at du er kjent med disse konseptene:

• Direct Lake bruker delte M-uttrykk i metadata for semantisk modell til å referere til datakilder gjennom Power Query-datatilgangsfunksjoner: AzureStorage.DataLake for Direct Lake på OneLake og Sql.Database for Direct Lake på SQL-endepunkter. Direct Lake bruker imidlertid ikke disse funksjonene til å lese Delta-kildetabellene. Den leser Delta-tabellene direkte gjennom OneLake-API-er.
• For å sikre at bare autoriserte brukere spør etter dataene, kontrollerer Direct Lake datatilgangstillatelsene for den effektive identiteten. Den effektive identiteten avhenger av datatilkoblingskonfigurasjonen. Som standard bruker Direct Lake SSO (Microsoft Entra ID) og bruker identiteten til den gjeldende brukeren som spør den semantiske modellen. Du kan også binde en Direct Lake-modell til en eksplisitt skytilkobling for å gi en fast identitet.
• Hvis du gir datatilgangstillatelser gjennom arbeidsområderoller, kan bare medlemmer av bidragsyterrollen (eller høyere) lese data i OneLake. Arbeidsområdevisningsprogrammer har imidlertid ikke lesetillatelse i OneLake. Seere og brukere som ikke er medlemmer av en arbeidsområderolle, kan få lesetilgang gjennom en kombinasjon av elementtillatelser, databehandlingstillatelser eller OneLake-sikkerhetsroller.
• OneLake-sikkerhet lar medlemmer av rollene Administrator for arbeidsområde og Medlem av arbeidsområde definere detaljert rollebasert sikkerhet for brukere i Seer-rollen. Angi tabellene en seer eller bruker med eksplisitt lesetillatelse kan få tilgang til og utelate bestemte rader eller kolonner. Hvis du vil lære mer om OneLake-sikkerhetsroller, kan du se Tabellsikkerhet i OneLake, Sikkerhet på kolonnenivå i OneLake og RLS i OneLake.

Konfigurasjon av tilkobling

Konfigurer datatilkoblinger for en Direct Lake-modell på samme måte som andre semantiske modelltyper. Se Koble til skydatakilder i Power BI-tjenesten hvis du vil ha mer informasjon.

Fordi Direct Lake bare kobler til Fabric-datakilder, fungerer standard SSO-konfigurasjon (Microsoft Entra ID) vanligvis, slik at du ikke trenger å binde semantiske modeller til eksplisitte datatilkoblinger. Denne tilnærmingen reduserer konfigurasjonskompleksiteten og reduserer administrasjonskostnadene.

Med SSO (Microsoft Entra ID) kontrollerer Direct Lake at den gjeldende brukeren som spør den semantiske modellen, har lesetilgang til dataene. Bare brukere med lesetilgang kan spørre etter dataene. Skjermbildet nedenfor viser en Direct Lake-modell som bruker standard SSO-konfigurasjon.

Når du bruker en eksplisitt datatilkobling med en fast identitet i stedet for SSO, krever ikke Direct Lake at alle brukere har lesetillatelse for de underliggende dataene. Hvis Microsoft Entra SSO forblir deaktivert i datatilkoblingen, bestemmer tillatelsene til den faste identiteten hvilke data Direct Lake har tilgang til.

Note

Du kan konfigurere en datatilkobling til å bruke både SSO og en fast identitet. Direct Lake kontrollerer gjeldende brukers tillatelser på spørringstidspunktet og bruker den faste identiteten for innramming og omkoding på oppdateringstidspunktet. Hvis du vil bruke en fast identitet for både spørringer og oppdateringer, må du kontrollere at SSO er deaktivert i datatilkoblingskonfigurasjonen.

Krav til godkjenning

Direct Lake-modeller bruker Microsoft Entra ID-godkjenning. I datatilkoblingskonfigurasjonen velger du OAuth 2.0, Tjenestekontohaver eller Arbeidsområdeidentitet som godkjenningsmetode. Andre metoder, for eksempel nøkkel- eller SAS-godkjenning, kan vises i konfigurasjonsgrensesnittet, men støttes ikke for Direct Lake-modeller.

Tillatelseskrav

Tillatelseskravene varierer mellom Direct Lake på SQL-endepunkter og Direct Lake på OneLake. Dette er fordi Direct Lake på SQL-endepunkter er avhengige av SQL Analytics-endepunktet for måldatakilden, mens Direct Lake på OneLake bruker OneLake-API-ene for tillatelseskontroller.

Direct Lake på SQL-endepunkter

Direct Lake på SQL-endepunkter utfører tillatelseskontroller via SQL Analytics-endepunktet for å finne ut om den effektive identiteten som prøver å få tilgang til dataene, har de nødvendige datatilgangstillatelsene. Spesielt trenger ikke den effektive identiteten tillatelse til å lese Delta-tabeller direkte i OneLake. Det er nok å ha lesetilgang til Fabric-artefakten, for eksempel et lakehouse, og SELECT-tillatelse på en tabell gjennom SQL-analyseendepunktet. Det er fordi Fabric gir de nødvendige tillatelsene til den semantiske modellen for å lese Delta-tabellene og tilknyttede Parquet-filer (for å laste kolonnedata inn i minnet). Den semantiske modellen har tillatelse til å lese SQL-analyseendepunktet med jevne mellomrom for å kontrollere hvilke data spørringsbrukeren (eller den faste identiteten) har tilgang til.

Direct Lake på OneLake

Direct Lake på OneLake bruker ikke et SQL-analyseendepunkt for tillatelseskontroller. Den bruker OneLake Security. Når OneLake-sikkerhet er aktivert, bruker Direct Lake på OneLake gjeldende bruker (eller fast identitet) til å løse OneLake-sikkerhetsroller og håndheve OLS og RLS på målstrukturartefakten. Hvis OneLake-sikkerhet ikke er aktivert, krever Direct Lake på OneLake at den effektive identiteten har lese- og ReadAll-tillatelser på målstrukturartefakten for å få tilgang til Delta-tabellene i OneLake. Hvis du vil ha mer informasjon om lese- og ReadAll-tillatelser, kan du se delen Elementtillatelser i artikkelen Oversikt over OneLake-sikkerhet.

Note

Bidragsytere (eller høyere) har lese- og lesealletillatelser i OneLake. Seere og brukere som ikke er medlemmer av en arbeidsområderolle, må gis lese- og lesetillatelser eller legges til i en OneLake-sikkerhetsgruppe. Hvis du vil ha mer informasjon om hvordan du administrerer OneLake-sikkerhetsgrupper, kan du se OneLake-modell for datatilgangskontroll.

Direkte Lake-brukere

Scenariene nedenfor viser minimumskrav for tillatelser.

Scenario	Direct Lake på SQL-endepunkter	Direct Lake på OneLake	Comments
Brukere kan se rapporter	- Gi lesetillatelse for rapportene og lesetillatelse for den semantiske modellen. - Hvis Direct Lake bruker SSO, gir du brukerne minst lesetillatelse for målstrukturartefakten og SELECT-tillatelser for tabellene.	- Gi lesetillatelse for rapportene og lesetillatelse for den semantiske modellen. - Hvis Direct Lake bruker SSO, gir du brukere minst lesetillatelse for mål-Fabric-artefakten og legger dem til i en OneLake-sikkerhetsrolle eller gir dem ReadAll-tillatelse .	Rapporter trenger ikke å tilhøre samme arbeidsområde som den semantiske modellen. Hvis du vil ha mer informasjon, kan du se Strategi for skrivebeskyttede forbrukere.
Brukere kan opprette rapporter	- Gi kompileringstillatelse for den semantiske modellen. - Hvis Direct Lake bruker SSO, gir du brukerne minst lesetillatelse for målstrukturartefakten og SELECT-tillatelser for tabellene.	- Gi kompileringstillatelse for den semantiske modellen. - Hvis Direct Lake bruker SSO, gir du brukere minst lesetillatelse for mål-Fabric-artefakten og legger dem til i en OneLake-sikkerhetsrolle eller gir dem ReadAll-tillatelse .	Brukere kan bare bygge rapporter på tabellene og kolonnene de har tilgang til. Dette kan være et delsett av hele settet med tabeller og kolonner i modellen. Hvis du vil ha mer informasjon, kan du se Strategi for innholdsopprettere.
Brukere kan spørre den semantiske modellen, men nektes spørring av lakehouse- eller SQL Analytics-endepunktet	- Bind Direct Lake-modellen til en skytilkobling med en fast identitet, og la SSO være deaktivert. - Gi den faste identiteten minst lesetillatelse for målstrukturartefakten og SELECT-tillatelser for tabellene. - Ikke gi brukerne tillatelse til mål-Fabric-artefakten.	- Bind Direct Lake-modellen til en skytilkobling med en fast identitet, og la SSO være deaktivert. - Gi den faste identiteten minst lesetillatelse for mål-Fabric-artefakten, og legg den til i en OneLake-sikkerhetsrolle, eller gi den ReadAll-tillatelse . - Ikke gi brukerne tillatelse til mål-Fabric-artefakten.	Kun egnet når skytilkoblingen bruker en fast identitet.
Brukere kan spørre den semantiske modellen og SQL-analyseendepunktet, men nektes å spørre innsjøen	- Gi lese- og lesedatatillatelser for målstrukturartefakten.	Ikke aktuelt.	Viktig!: Spørringer som sendes til SQL Analytics-endepunktet, omgår datatilgangstillatelser som håndheves av den semantiske modellen.
Administrer den semantiske modellen, inkludert oppdateringsinnstillinger	- Krever eierskap av semantisk modell.	- Krever eierskap av semantisk modell.	Hvis du vil ha mer informasjon, kan du se Semantic-modelleierskap.

Viktig!

Test alltid tillatelser før du frigir den semantiske modellen og rapporterer til produksjon.

Hvis du vil ha mer informasjon, kan du se semantiske modelltillatelser.

Direkte eiere av innsjøen

I tillegg til den effektive identiteten (gjeldende bruker eller fast identitet), krever Direct Lake også at eieren av den semantiske modellen har lesetilgang til kildetabellene, slik at Direct Lake kan ramme inn den semantiske modellen som en del av dataoppdateringen. Uansett hvem som oppdaterer en Direct Lake-modell, kontrollerer Direct Lake eierens tillatelse for å sikre at modellen får tilgang til dataene. Eierens krav til datatilgangstillatelser er de samme som for brukere som spør modellen.

Hvis eieren av den semantiske modellen ikke har de nødvendige datatilgangstillatelsene, utløser Direct Lake følgende feil under innramming: 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\>'.

Snarveier til kildetabeller

Snarveier er OneLake-objekter som du legger til i en Fabric lakehouse eller en annen Fabric-artefakt for å peke til interne eller eksterne lagringssteder. I en Direct Lake-modell vises Delta-tabeller som legges til via snarveier, som opprinnelige i den tilkoblede Fabric-artefakten fordi snarveier er gjennomsiktige når du får tilgang til data via OneLake-API-en.

Når du får tilgang til snarveier via Direct Lake over SQL-endepunkter, validerer Direct Lake først at den effektive identiteten (gjeldende bruker eller fast identitet) har tilgang til tabellen i datakilden for den semantiske modellen. For interne snarveier, etter at kontrollen er bestått, bruker Direct Lake datakildeeierens identitet til å lese Delta-tabellen gjennom snarveien på tabellens Fabric-artefakt. Eieren av datakilden må ha tilgangstillatelse på OneLake-målplasseringen. For eksterne snarveier trenger eieren av datakilden også Bruk-tillatelse på skytilkoblingen til det eksterne systemet som er vert for Delta-tabellen. Hvis du vil ha mer informasjon, kan du se OneLake-snarveier.

Direct Lake over OneLake har forskjellige tillatelseskrav fordi SQL Analytics-endepunktet ikke er involvert. Når en bruker får tilgang til data via en intern snarvei til en annen OneLake-plassering, må den effektive identiteten (gjeldende bruker eller fast identitet) ha tillatelse på målplasseringen. Den effektive identiteten må være en bidragsyter (eller høyere), ha lese- og lesetillatelser, eller være i en OneLake-sikkerhetsrolle som gir lesetilgang .

Sikkerhet på objektnivå (OLS) og sikkerhet på radnivå (RLS)

Både OneLake Security- og Direct Lake-modellene støtter OLS og RLS. OLS gjør det mulig for artefakteiere og administratorer å sikre bestemte tabeller eller kolonner. RLS kan brukes til å begrense datatilgang på radnivå basert på filtre. Du kan definere OLS og RLS i OneLake Security, i en Direct Lake-modell eller på begge steder.

Viktig!

Direct Lake støtter ikke SQL Analytics-endepunkt OLS/RLS. Hvis du vil returnere riktige data, faller Direct Lake over SQL-endepunkter tilbake til DirectQuery-modus hvis en strukturartefakt bruker OLS eller RLS. Hvis DirectQuery-fallback er deaktivert, mislykkes spørringer over SQL-endepunkter når OLS/RLS er definert på SQL Analytics-endepunktet. Direct Lake over OneLake unngår denne begrensningen.

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

Direct Lake på OneLake evaluerer tilgang til OLS/RLS-sikrede objekter ved å løse den effektive identitetens OneLake-sikkerhetsroller og bruke de definerte OLS/RLS-reglene. OneLake Security-rollene håndteres på samme måte som Direct Lake-roller. Hvis den effektive identiteten tilhører flere roller i OneLake Security og Direct Lake, forener Direct Lake først OneLake Security-rollene, og krysser deretter resultatet med Direct Lake-rollene.

Denne tabellen viser vanlige feilsøkingssituasjoner forårsaket av motstridende OneLake-sikkerhets- og Direct Lake-regler.

Scenario	Comments
Ingen rader returnert på grunn av RLS-filtrering	Hvis den effektive identiteten mangler tilgangstillatelser på radnivå, kan spørringer returnere tomme resultater. Denne virkemåten forventes når RLS-filtre utelater alle rader for gjeldende bruker.
Finner ikke tabellen Finner ikke kolonnen Kan ikke løse navn Ikke et gyldig tabell-, variabel- eller funksjonsnavn	Disse feilene oppstår vanligvis når objekttillatelser mangler etter bruk av OneLake Security-roller.

Forskjeller mellom OLS/RLS-omfang

Håndheving av OLS og RLS i OneLake Security bruker reglene på tvers av alle databehandlingsmotorer og sikrer enhetlig tilgangskontroll for brukere. Dette betyr at uavhengig av databehandlingsmotoren – lakehouse, lager, semantisk modell eller annen artefakt – kontrollerer OneLake Security-regler brukerens datatilgang. OLS/RLS definert i en Direct Lake-semantisk modell gjelder derimot bare innenfor rammen av denne modellen. Andre databehandlingsmotorer bruker ikke disse Direct Lake-sikkerhetsreglene, noe som kan gi forskjellige resultater når brukere får tilgang til dataene via andre baner.

Viktig!

Når du bruker både OneLake Security OLS/RLS og Direct Lake OLS/RLS, kan brukere som har OneLake-tilgang, fremdeles hente og arbeide med dataene – selv om Direct Lake-modellregler begrenser dataene ytterligere – fordi regler på modellnivå ikke strekker seg utover modellen. Bruk OneLake Security for omfattende tilgangskontroll på tvers av alle databehandlingsmotorer.

OneLake OLS og metadata for semantisk modell

Metadata for semantisk modell inkluderer definisjoner av tabeller, kolonner, relasjoner og andre skjemaelementer. Brukere med kompileringstillatelser eller høyere tillatelser kan vise modellmetadataene via XML for Analysis (XMLA) og REST-API-er. Hvis du vil ha mer informasjon, kan du se semantiske modelltillatelser.

Hvis du vil beskytte sensitive tabell- og kolonnenavn i OneLake med OneLake OLS, må du huske at OneLake-sikkerhet bare gjelder for medlemmer av visningsprogramrollen for arbeidsområdet. OneLake OLS hindrer ikke medlemmer av arbeidsområderollen Bidragsyter (eller høyere) i å oppdage sikrede tabeller eller kolonner fordi de allerede har skrivetillatelse til alle arbeidsområdeartefakter. Medlemmer av Seer-rollen med kompileringstillatelser eller høyere tillatelser på en Direct Lake-modell kan oppdage sensitiv skjemainformasjon gjennom metadataene for semantisk modell. Disse høyere privilegerte seerne har fortsatt ikke datatilgang, men de kan se at de sikrede tabellene og kolonnene finnes.

En Direct Lake-modell kan finnes i samme arbeidsområde som kildeartefakten eller i et eget arbeidsområde. Gi en seer i samme arbeidsområdebygg (eller høyere) tilgang til en Direct Lake-modell gjennom elementtillatelser. I et eget arbeidsområde kan en bruker være bidragsyter (eller høyere) eller ha kompileringselementtillatelser (eller høyere) for å få tilgang til modellmetadataene.

OneLake OLS- og Git-integrasjon

Git-integrering gjør det mulig for utviklere å integrere ALM-prosessene (Application Lifecycle Management) i Fabric-plattformen. Git-repositoriet bevarer arbeidsområdestrukturen, inkludert alle støttede artefakter. Utviklere har full oversikt over metadataene til alle elementene i Git-repositoriet. Direct Lake-modellmetadata lar dem se at sikrede tabeller eller kolonner finnes selv om de ikke har tilgang til måldatakilden i et annet arbeidsområde. Hvis du vil ha mer informasjon, kan du se Hva er Microsoft Fabric Git-integrering?

Hensyn og begrensninger

Vurder disse sikkerhetsbegrensningene for Direct Lake.

Note

Egenskapene og funksjonene til Direct Lake-semantiske modeller og OneLake-sikkerhet utvikler seg raskt. Kom tilbake med jevne mellomrom for oppdateringer.

• Tilordne arbeidsområdelesere OneLake-sikkerhetsroller som gir lesetilgang til Fabric-kildeartefaktene. Hvis en kildeartefakt har snarveier til en annen Fabric-artefakt, må brukeren også ha lesetilgang til hver snarveis mål-Fabric-artefakt.
• Bruk en fast identitet til å isolere brukere fra en Fabric-kildeartefakt. Bind Direct Lake-modellen til en skytilkobling. Hold SSO deaktivert på skytilkoblingen for å bruke den faste identiteten for oppdateringer og spørringer.
• Direct Lake-semantiske modeller som er avhengige av Fabric OneLake-sikkerhet på kildeartefakten, støtter ikke sikkerhetskopieringsoperasjoner.
• Toveis relasjoner støttes ikke i en Direct Lake-modell hvis kildestrukturartefakten er avhengig av OneLake-sikkerhets-RLS.
• I offentlig forhåndsversjon støtter OneLake-sikkerhet bare statisk RLS på én enkelt tabell.
• I offentlig forhåndsversjon støtter ikke OneLake-sikkerhet dynamiske definisjoner eller komplekse rollekonfigurasjoner, for eksempel å kombinere flere OLS- og RLS-roller på tvers av relaterte tabeller.
• Konsolider OneLake-sikkerhet RLS- og OLS-tillatelser i én rolle per bruker i stedet for å tilordne flere roller.
• Hvis OneLake-sikkerhetskonfigurasjonen endres, for eksempel på grunn av snarveisendringer i målartefakten, oppdaterer du Direct Lake på OneLake-modeller som har tilgang til denne artefakten. Hvis automatisk synkronisering er aktivert, oppdaterer tjenesten dem vanligvis automatisk. Ellers oppdaterer du modellene manuelt.
• Hvis et Lakehouse har OneLake-sikkerhet:
  • SQL-analyseendepunktet er som standard fast identitet til eieren av Lakehouse, så OneLake-sikkerheten for SQL-analyseendepunktet er den samme som eieren (ingen begrensninger). Direct Lake på SQL fortsetter å bruke Direct Lake, med mindre ekstra SQL-detaljerte tilgangsroller legges til.
  • SQL-analyseendepunktet kan endres til SSO. Når dette skjer, legges OneLake-sikkerhetsroller til som detaljerte SQL-tilgangskontrollregler, og brukeren blokkeres fra å redigere dem direkte på SQL-analyseendepunktet. På dette tidspunktet faller Direct Lake på SQL tilbake til DirectQuery 100% av tiden.