Integroi Direct Lake -suojaus

Direct Lake -suojaus varmistaa, että vain valtuutetut käyttäjät voivat tehdä kyselyjä Delta-taulukoista OneLakessa. Voit hallita tietojen käyttöoikeuksia työtilaroolien kautta. Työtilan osallistujat, jäsenet ja järjestelmänvalvojat voivat lukea tietoja OneLakessa. Voit myös myöntää pääsyn OneLaken tietoihin kohdetason ja laskentaoikeuksien kautta. Kolmas vaihtoehto on hyödyntää OneLake-suojausta yksityiskohtaisen roolipohjaisen suojauksen pakottamiseksi kaikissa Fabric-laskentamoottoreissa. Tässä artikkelissa kerrotaan, miten voit kohdistaa käyttöoikeusmalleja, valita kertakirjautumisen (SSO) tai kiinteät käyttäjätiedot sekä hyödyntää objektitason suojausta (OLS) ja rivitason suojausta (RLS). Lue lisää OneLaken suojauksen yleiskatsauksesta.

Avainkäsitteet ja terminologia

Tässä artikkelissa oletetaan, että tunnet seuraavat käsitteet:

  • Direct Lake käyttää jaettuja M-lausekkeita semanttisen mallin metatiedoissa viittaamaan tietolähteisiin Power Query tietojen käyttöoikeusfunktioiden kautta: AzureStorage.DataLake OneLaken Direct Lakelle ja Sql.Database Direct Lakelle SQL-päätepisteissä. Direct Lake ei kuitenkaan käytä näitä funktioita lähteen Delta-taulukoiden lukemiseen. Se lukee Delta-taulukot suoraan OneLake-ohjelmointirajapintojen kautta.
  • Varmistaakseen, että vain valtuutetut käyttäjät tekevät kyselyjä tiedoista, Direct Lake tarkistaa voimassa olevien käyttäjätietojen käyttöoikeudet. Voimassa olevat käyttäjätiedot määräytyvät tietoyhteyden kokoonpanon mukaan. Direct Lake käyttää oletusarvoisesti kertakirjautumista (Microsoft Entra ID) ja käyttää semanttista mallia kyselevän nykyisen käyttäjän käyttäjätietoja. Voit myös sitoa Direct Lake -mallin eksplisiittiseen pilviyhteyteen kiinteän käyttäjätiedon tarjoamiseksi.
  • Jos myönnät tietojen käyttöoikeuksia työtilaroolien kautta, vain Osallistujat-roolin (tai sitä korkeamman) jäsenet voivat lukea tietoja OneLakessa. Työtilan katselijoilla ei kuitenkaan ole lukuoikeutta OneLakessa. Katselijat ja käyttäjät, jotka eivät ole työtilaroolin jäseniä, voivat saada lukuoikeuden kohteen käyttöoikeuksien, laskentaoikeuksien tai OneLake-käyttöoikeusroolien yhdistelmän kautta.
  • OneLake-suojauksen avulla työtilan järjestelmänvalvoja- ja työtilan jäsenen roolien jäsenet voivat määrittää yksityiskohtaisen roolipohjaisen suojauksen käyttäjille, joilla on katselijarooli. Määritä taulukot, joita katselija tai käyttäjä, jolla on eksplisiittinen lukuoikeus , voi käyttää ja jättää pois tiettyjä rivejä tai sarakkeita. Lisätietoja OneLaken käyttöoikeusrooleista on artikkelissa Taulukon suojaus OneLakessa, Saraketason suojaus OneLakessa ja rivitason suojaus OneLakessa.

Yhteyden konfigurointi

Määritä Direct Lake -mallin tietoyhteydet samalla tavalla kuin muut semanttiset mallityypit. Katso lisätietoja kohdasta Yhteyden muodostaminen pilvitietolähteisiin Power BI -palvelussa .

Koska Direct Lake muodostaa yhteyden vain Fabric-tietolähteisiin, oletusarvoinen kertakirjautuminen (Microsoft Entra ID) toimii yleensä, joten sinun ei tarvitse sitoa semanttisia malleja eksplisiittisiin tietoyhteyksiin. Tämä lähestymistapa vähentää määritysten monimutkaisuutta ja vähentää hallinnan yleiskustannuksia.

SSO:n (Microsoft Entra ID) avulla Direct Lake tarkistaa, että semanttista mallia kyselevällä nykyisellä käyttäjällä on lukuoikeus tietoihin. Vain käyttäjät, joilla on lukuoikeus , voivat tehdä kyselyjä tiedoista. Seuraavassa näyttökuvassa näkyy Direct Lake -malli, jossa käytetään oletusarvoista SSO-määritystä.

Näyttökuva Direct Lake -mallin yhteysasetuksista, joissa näkyy oletusarvoinen Microsoft Entra ID -kertakirjautuminen käytössä tietojen käyttöä varten.

Kun käytät eksplisiittistä tietoyhteyttä kiinteän käyttäjätiedon kanssa kertakirjautumisen sijaan, Direct Lake ei edellytä, että jokaisella käyttäjällä on lukuoikeus pohjana oleviin tietoihin. Jos Microsoft Entra SSO pysyy poissa käytöstä tietoyhteydessä, kiinteän käyttäjätiedon käyttöoikeudet määrittävät, mitä tietoja Direct Lake voi käyttää.

Näyttökuva Direct Lake -mallin yhteysasetuksista, joissa Microsoft Entra ID -kertakirjautuminen on poistettu käytöstä ja kiinteä käyttäjätieto valittuna.

Note

Voit määrittää tietoyhteyden käyttämään sekä kertakirjautumista että kiinteää käyttäjätietoa. Direct Lake tarkistaa nykyisen käyttäjän käyttöoikeudet kyselyn aikana ja käyttää kiinteää käyttäjätietoa kehystykseen ja transkoodaukseen päivityksen aikana. Jos haluat käyttää kiinteää käyttäjätietoa sekä kyselyissä että päivityksissä, varmista, että kertakirjautuminen on poistettu käytöstä tietoyhteyden määrityksissä.

Vinkki

Käytä kertakirjautumista vuorovaikutteisissa skenaarioissa, joissa vaaditaan käyttäjäkohtainen valtuutus. Käytä kiinteän identiteetin pilviyhteyttä sulautetuissa tai vain luku -käyttötilanteissa, joissa lähdetasoinen pääsy on rajattu yhdelle palvelutilille. Soveltaa vähiten oikeuksien periaatteita sekä lähde- että työtilatasolla, ja testata sekä validoida käyttäytymistä molemmissa todennusmuodoissa ennen tuotannon käyttöönottoa.

Todentamisen vaatimukset

Direct Lake -mallit käyttävät Microsoft Entra ID -todennusta. Valitse tietoyhteyden määrityksessä todennusmenetelmäksi OAuth 2.0, Palvelun päänimi tai Työtilan käyttäjätiedot . Muut menetelmät, kuten avaimen tai SAS-todennuksen, saattavat näkyä määrityskäyttöliittymässä, mutta niitä ei tueta Direct Lake -malleissa.

Käyttöoikeusvaatimukset

Käyttöoikeusvaatimukset vaihtelevat SQL-päätepisteiden Direct Laken ja OneLaken Direct Laken välillä. Tämä ero johtuu siitä, että Direct Lake SQL-päätepisteillä perustuu kohdetietolähteen SQL Analytics Endpointiin, kun taas OneLake käyttää OneLake-rajapintoja käyttöoikeustarkistuksiin.

Direct Lake SQL-päätepisteissä

Direct Lake on SQL endpoints tarkistaa käyttöoikeudet SQL-analytiikan päätepisteen kautta nähdäkseen, onko tehokkaalla identiteettillä, joka yrittää päästä käsiksi dataan, oikeat oikeudet. Tehokas identiteetti ei tarvitse lupaa lukea Delta-taulukoita suoraan OneLakessa. Se tarvitsee vain lukuoikeuden Fabric-kohteeseen, kuten lakehouseen, ja SELECT-luvan taulukossa SQL-analytiikkapäätepisteen kautta. Fabric myöntää semanttiselle mallille oikeudet, joita se tarvitsee Delta-taulukoiden ja niihin liittyvien Parquet-tiedostojen lukemiseen sarakkeen lataamiseksi muistiin. Semanttinen malli voi lukea SQL-analytiikan päätepistettä säännöllisesti tarkistaakseen, mitä dataa kyselykäyttäjä (tai kiinteä identiteetti) voi käyttää.

Direct Lake OneLakella

Direct Lake OneLakessa ei käytä SQL-analytiikkapäätepistettä käyttöoikeuksien tarkistamiseen. Se käyttää OneLake-turvajärjestelmää. Kun OneLake-turvallisuus on päällä, Direct Lake OneLakella käyttää nykyistä käyttäjää (tai kiinteää identiteettiä) selvittääkseen OneLake-turvallisuusroolit ja valvoakseen OLS- ja RLS-toimintoja kohde-Fabric-tuotteessa. Jos OneLake-turvallisuus ei ole päällä, Direct Lake on OneLake tarvitsee tehokkaan identiteetin, jolla on Read ja ReadAll -oikeudet kohde-Fabric-kohteeseen päästäkseen Delta-tauluihin OneLakessa. Lisätietoja Read- ja ReadAll-oikeuksista löytyy kohdasta Jaa kohteet ja esinetason käyttöoikeudet.

Note

Osallistujilla (tai sitä korkeammalla) on luku- ja lukuoikeudet OneLakessa. Katsojien ja käyttäjien, jotka eivät kuulu työtilan rooliin, on saatava ReadAll- ja ReadAll-oikeudet tai heidät on lisättävä OneLake-turvaryhmään. Lisätietoja OneLaken käyttöoikeusryhmien hallinnasta on kohdassa OneLake-tietojen käyttöoikeuksien hallintamalli.

Suorat Laken käyttäjät

Seuraavissa skenaarioissa on lueteltu käyttöoikeuksien vähimmäisvaatimukset.

Skenaario Direct Lake SQL-päätepisteissä Direct Lake OneLakella Comments
Käyttäjät voivat tarkastella raportteja - Myönnä raporttien lukuoikeus ja semanttisen mallin lukuoikeus .
- Jos Direct Lake käyttää SSO:ta, myönnä käyttäjille vähintään lukuoikeudet kohde-Fabric-kohteelle ja SELECT-oikeudet tauluille.		 - Myönnä raporttien lukuoikeus ja semanttisen mallin lukuoikeus .
- Jos Direct Lake käyttää SSO:ta, anna käyttäjille vähintään lukulupa kohde-Fabric-kohteelle ja lisää heidät OneLake-turvallisuusrooliin tai ReadAll-lupa.		 Raporttien ei tarvitse kuulua samaan työtilaan kuin semanttisen mallin. Lisätietoja on artikkelissa Vain luku -kuluttajien strategia.
Käyttäjät voivat luoda raportteja - Myönnä semanttisen mallin muodostamisoikeus .
- Jos Direct Lake käyttää SSO:ta, myönnä käyttäjille vähintään lukuoikeudet kohde-Fabric-kohteelle ja SELECT-oikeudet tauluille.		 - Myönnä semanttisen mallin muodostamisoikeus .
- Jos Direct Lake käyttää SSO:ta, anna käyttäjille vähintään lukulupa kohde-Fabric-kohteelle ja lisää heidät OneLake-turvallisuusrooliin tai ReadAll-lupa.		 Käyttäjät voivat luoda raportteja vain niistä taulukoista ja sarakkeista, joihin heillä on käyttöoikeus. Tämä ehto voi olla mallin koko taulukoiden ja sarakkeiden joukon osajoukko. Lisätietoja on artikkelissa Sisällöntekijöille tarkoitettu strategia.
Käyttäjät voivat tehdä kyselyn semanttisesta mallista, mutta heitä ei evätä kysely lakehouse- tai SQL-analytiikan päätepisteestä - Sido Direct Lake -malli pilviyhteyteen, jolla on kiinteät käyttäjätiedot, ja jätä kertakirjautuminen pois käytöstä.
- Myönnä kiinteälle identiteetille vähintään lukuoikeudet kohde-Fabric-kohteelle ja SELECT-oikeudet tauluille.
- Älä anna käyttäjille mitään oikeutta kohde-Fabric-kohteelle.		 - Sido Direct Lake -malli pilviyhteyteen, jolla on kiinteät käyttäjätiedot, ja jätä kertakirjautuminen pois käytöstä.
- Myönnä kiinteälle identiteetille vähintään lukulupa kohde-Fabric-kohteelle ja lisätä se OneLake-turvallisuusrooliin tai myöntää sille ReadAll-lupa.
- Älä anna käyttäjille mitään oikeutta kohde-Fabric-kohteelle.		 Sopii vain, kun pilviyhteys käyttää kiinteää identiteettiä.
Käyttäjät voivat tehdä kyselyjä semanttisesta mallista ja SQL-analytiikan päätepisteestä, mutta heiltä evätään kysely lakehousesta - Myönnä kohde-Fabric-kohteelle luku- ja ReadData-oikeudet. Ei käytettävissä. Tärkeää: SQL-analytiikkapäätepisteelle lähetetyt kyselyt ohittavat semanttisen mallin vaatimat datan käyttöoikeudet.
Semanttisen mallin hallinta, mukaan lukien päivitysasetukset - Edellyttää semanttisen mallin omistajuutta. - Edellyttää semanttisen mallin omistajuutta. Lisätietoja on artikkelissa Semanttisen mallin omistajuus.

Tärkeää

Testaa käyttöoikeudet aina ennen semanttisen mallin ja raporttien julkaisemista tuotantoon.

Lisätietoja on artikkelissa Semanttisen mallin käyttöoikeudet.

Suorat järven omistajat

Tehokkaan identiteetin (nykyinen käyttäjä tai kiinteä identiteetti) lisäksi Direct Lake vaatii, että semanttisen mallin omistajalla on lukuoikeudet lähdetauluihin, jotta Direct Lake voi kehystää semanttisen mallin osana tietojen päivitystä. Riippumatta siitä, kuka päivittää Direct Lake -mallin, Direct Lake tarkistaa omistajan luvan varmistaakseen, että malli voi käyttää tietoja. Omistajan tietojen käyttöoikeusvaatimukset ovat samat kuin mallia kyselyä tekeville käyttäjille.

Jos semanttisen mallin omistajalla ei ole tarvittavia tietojen käyttöoikeuksia, Direct Lake aiheuttaa seuraavan virheen kehystyksen aikana: 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\>'.

Lähdetaulukoiden pikakuvakkeet

Pikakuvakkeet ovat OneLake-objekteja, jotka lisäät Fabric-järvenrakennukseen tai muuhun Fabric-kohteeseen osoittaaksesi sisäisiin tai ulkoisiin tallennuspaikkoihin. Direct Lake -mallissa pikanäppäimillä lisätyt Delta-taulukot näkyvät natiivina yhdistetyssä Fabric-alkiossa, koska pikakuvakkeet ovat läpinäkyviä, kun dataa käytetään OneLake-rajapinnan kautta.

Kun käytät pikakuvakkeita Direct Laken kautta SQL-päätepisteiden kautta, Direct Lake tarkistaa ensin, että voimassa oleva käyttäjätieto (nykyinen käyttäjä tai kiinteä käyttäjätieto) voi käyttää semanttisen mallin tietolähteen taulukkoa. Sisäisissä pikakuvakkeissa, kun tarkistus on suoritettu, Direct Lake käyttää tietolähteen omistajan identiteettiä lukeakseen Delta-taulukon pikakuvakkeen kautta taulun Fabric-kohteessa. Tietolähteen omistajalla on oltava käyttöoikeus OneLake-kohdesijaintiin. Ulkoisia pikakuvakkeita varten tietolähteen omistajalla on myös oltava käyttöoikeus pilviyhteyteen ulkoiseen järjestelmään, joka isännöi Delta-taulukkoa. Lisätietoja on kohdassa OneLake-pikakuvakkeet.

Näyttökuva kaaviosta, jossa Direct Lake vahvistaa voimassa olevat käyttäjätiedot ja käyttää sitten tietolähteen omistajan käyttäjätietoja sisäisen tai ulkoisen pikakuvakkeen kohteen käyttämiseen.

Direct Lake over OneLakella on erilaiset käyttöoikeusvaatimukset, koska SQL Analytics -päätepiste ei ole mukana. Kun käyttäjä käyttää tietoja sisäisen pikakuvakkeen kautta toiseen OneLake-sijaintiin, voimassa olevalla käyttäjätiedolla (nykyinen käyttäjä tai kiinteä käyttäjätieto) on oltava käyttöoikeus kohdesijaintiin. Voimassa olevan käyttäjätiedon on oltava osallistuja (tai uudempi), sillä on oltava luku- ja lukuoikeudet tai oltava OneLake-käyttöoikeusroolissa, joka myöntää lukuoikeudet .

Objektitason suojaus (OLS) ja rivitason suojaus (RLS)

Sekä OneLake- että Direct Lake -mallit tukevat OLS:ää ja RLS:ää. OLS mahdollistaa kohteiden omistajien ja ylläpitäjien suojata tiettyjä taulukoita tai sarakkeita. Rivitason suojausta voidaan käyttää rajoittamaan tietojen käyttöä rivitasolla suodattimien perusteella. Voit määritellä OLS:n ja RLS:n OneLake-turvallisuudessa, Direct Lake -mallissa tai molemmissa paikoissa.

Tärkeää

Direct Lake ei tue SQL-analytiikan päätepisteitä OLS/RLS:ää muistissa. Direct Lake over SQL -päätelaitteet käsittelevät näitä rajoituksia eri tavoin tyypin mukaan. Jos kysely koskettaa taulukkoa tai saraketta, jota rajoittaa SQL-analytiikkapäätepiste OLS tai saraketason tietoturva (CLS), kysely palauttaa virheen. Jos kysely viittaa taulukkoon, joka valvoo RLS:ää, tai näkymään SQL-analytiikan päätepisteessä, kysely palaa DirectQuery-tilaan. Jos DirectQuery-varajärjestelmä on poistettu käytöstä, RLS:stä tai SQL-päätepisteiden näkymäistä riippuvat kyselyt epäonnistuvat. Direct Lake over OneLake välttää nämä rajoitukset. Lisätietoja löytyy kohdasta Miten kyselyt arvioidaan Direct Lakessa SQL:llä.

Direct Lake OneLake OLS/RLS:ssä OneLake-turvajärjestelmällä OLS/RLS

Direct Lake OneLakessa arvioi pääsyn OLS/RLS-suojattuihin objekteihin ratkaisemalla tehokkaan identiteetin OneLake-turvallisuusroolit ja soveltamalla määriteltyjä OLS/RLS-sääntöjä. OneLake-turvallisuusroolit hoidetaan samalla tavalla kuin Direct Lake -roolit. Jos tehokas identiteetti kuuluu useisiin rooleihin OneLake-tietoturvassa ja Direct Lakessa, Direct Lake yhdistää ensin OneLake-turvallisuusroolit ja leikkaa tuloksen Direct Lake -roolien kanssa.

Tämä taulukko listaa yleisiä vianetsintätilanteita, jotka johtuvat ristiriidasta OneLake-turvallisuuden ja Direct Lake -sääntöjen välillä.

Skenaario Comments
Rivejä ei palautettu rivitason suojauksen suodatuksen vuoksi Jos voimassa olevilla käyttäjätiedoilla ei ole rivitason käyttöoikeuksia, kyselyt voivat palauttaa tyhjiä tuloksia. Tämä toiminta on odotettavissa, kun rivitason suojauksen suodattimet sulkevat pois kaikki nykyisen käyttäjän rivit.
Taulukkoa ei löydy
Saraketta ei löydy
Nimen selvittäminen epäonnistui
Ei kelvollinen taulukon, muuttujan tai funktion nimi		 Nämä virheet ilmenevät yleensä, kun olioiden käyttöoikeudet puuttuvat OneLake-turvaroolien käytön jälkeen.

OLS/RLS-vaikutusalueen erot

OLS:n ja RLS:n valvonta OneLake-turvallisuudessa soveltaa sääntöjä kaikissa laskentamoottoreissa ja varmistaa käyttäjille yhtenäisen käyttöoikeuksien hallinnan. Tämä tarkoittaa, että riippumatta laskentamoottorista—lakehouse, varasto, semanttinen malli tai muu tuote—OneLake-turvasäännöt ohjaavat käyttäjän tietojen käyttöä. Sitä vastoin Direct Lake -semanttisessa mallissa määritetty OLS/RLS koskee vain kyseisen mallin soveltamisalaa. Muut laskentamoduulit eivät käytä näitä Direct Lake -suojaussääntöjä, jotka voivat tuottaa erilaisia tuloksia, kun käyttäjät käyttävät tietoja muiden polkujen kautta.

Tärkeää

Kun käytät sekä OneLake-tietoturvaa OLS/RLS:ää että Direct Lake OLS/RLS:ää, käyttäjät, joilla on OneLake-pääsy, voivat silti hakea ja käsitellä dataa – vaikka Direct Lake -mallin säännöt rajoittaisivat dataa entisestään – koska mallitason säännöt eivät ulotu mallin ulkopuolelle. Käytä OneLake-turvallisuutta kattavaan käyttöoikeuksien hallintaan kaikissa laskentamoottoreissa.

OneLake OLS ja semanttisen mallin metatiedot

Semanttisen mallin metatiedot sisältävät taulukoiden, sarakkeiden, yhteyksien ja muiden rakenneelementtien määritykset. Käyttäjät, joilla on koonti- tai korkeammat käyttöoikeudet, voivat tarkastella mallin metatietoja XML for Analysis (XMLA) ja REST-ohjelmointirajapintojen kautta. Lisätietoja on artikkelissa Semanttisen mallin käyttöoikeudet.

Suojataksesi arkaluontoiset taulujen ja sarakkeiden nimet OneLakessa OneLake OLS:n kanssa, muista, että OneLake-turvallisuus koskee vain työtilan Viewer-roolin jäseniä. OneLake OLS ei estä Contributorin (tai ylemmän) työtilan jäseniä löytämästä suojattuja tauluja tai sarakkeita, koska heillä on jo kirjoitusoikeus kaikkiin työtilan kohteisiin. Katselija-roolin jäsenet, joilla on Direct Lake -mallin koonti- tai korkeammat käyttöoikeudet, voivat löytää luottamuksellisia rakennetietoja semanttisen mallin metatietojen avulla. Näillä etuoikeutetuilla katselijoilla ei vieläkään ole pääsyä tietoihin, mutta he näkevät, että suojatut taulukot ja sarakkeet ovat olemassa.

Direct Lake -malli voi sijaita samassa työtilassa lähdealkion kanssa tai erillisessä työtilassa. Myönnä saman työtilan koontiversion (tai uudemman) katselijalle Direct Lake -mallin käyttöoikeus kohteen käyttöoikeuksien avulla. Erillisessä työtilassa käyttäjä voi olla osallistuja (tai uudempi) tai hänellä voi olla koontiversion (tai korkeamman) kohteen käyttöoikeudet mallin metatietojen käyttämiseen.

OneLake OLS- ja Git-integrointi

Git-integraation avulla kehittäjät voivat integroida sovellusten elinkaaren hallintaprosessit (ALM) Fabric-ympäristöön. Git-repositorio säilyttää työtilan rakenteen, mukaan lukien kaikki tuetut kohteet. Kehittäjillä on täysi näkyvyys kaikkien Git-arkistossa olevien kohteidensa metatietoihin. Direct Lake -mallin metatietojen avulla he näkevät, että suojattuja taulukoita tai sarakkeita on olemassa, vaikka heillä ei olisi kohdetietolähteen käyttöoikeutta toisessa työtilassa. Jos haluat lisätietoja, katso Mikä on Microsoft Fabric Git -integrointi?

Miten kyselyt arvioidaan Direct Lake on SQL:ssä

Semanttisten Direct Lake -mallien kehittäminen johtuu siitä, että OneLakessa voidaan tehdä hyvin suorituskykyisiä kyselyjä suurille tietomäärille. Siksi sinun on pyrittävä suunnittelemaan ratkaisu, joka maksimoi mahdollisuudet kyselyn muodostamiseen muistissa.

Seuraavat vaiheet arvioivat, miten Direct Lake on SQL -kyselyt arvioidaan (ja epäonnistuvatko ne). Direct Lake -tallennustilan tilan edut ovat mahdollisia vain, kun viides vaihe on saavutettu.

  1. Jos kysely sisältää taulukon tai sarakkeen, jota semanttisen mallin OLS rajoittaa, palautetaan virhetulos (raportin visualisoinnit eivät pysty hahmontamaan).
  2. Jos kysely sisältää sarakkeen, jota SQL-analytiikan päätepisteen CLS rajoittaa (tai taulukko on estetty), palautetaan virhetulos (raportin visualisoinnit eivät onnistu hahmontamaan).
    1. Jos pilvipalveluyhteys käyttää kertakirjautumista (oletus), raportin kuluttajan käyttöoikeustaso määrittää CLS:n.
    2. Jos pilviyhteys käyttää kiinteitä käyttäjätietoja, CLS määräytyy kiinteiden käyttäjätietojen käyttöoikeustason mukaan.
  3. Jos semanttinen malli käyttää Direct Lakea SQL-päätepisteissä ja kysely sisältää minkä tahansa taulukon SQL-analytiikan päätepisteessä, joka valvoo RLS:ää tai käyttää näkymää, kysely palaa DirectQuery-tilaan.
    1. Jos pilviyhteys käyttää kertakirjautumista (oletus), rivitason suojaus määräytyy raportin kuluttajan käyttöoikeustason mukaan.
    2. Jos pilviyhteys käyttää kiinteitä käyttäjätietoja, RLS määräytyy kiinteiden käyttäjätietojen käyttöoikeustason mukaan.
  4. Jos kysely ylittää kapasiteetin suojakaiteet, se palaa DirectQuery-tilaan.
  5. Muussa tapauksessa kysely täyttyy välimuistista. Sarakedata ladataan muistiin tarvittaessa.

Tärkeää

Direct Lake OneLakella ei tue takaisin DirectQuery-tilaan. Jos jokin SQL-analytiikan päätepisteen taulu pakottaa RLS:n tai kysely ylittää kapasiteetin suojat, palautetaan virhetulos (raportin visuaalit eivät renderöidy).

Tietojen käyttösäännön asetukset

Voit määrittää tietojen käyttösääntöjä seuraavissa säännöissä:

  • Semanttinen malli.
  • SQL-analytiikan päätepiste (Direct Lake vain SQL-päätelaitteissa).
  • OneLake-turvallisuus.

Semanttisen mallin säännöt

Jos sinun täytyy valvoa datan käyttöoikeuksia, tee se OneLake-tietoturvassa, jotta säännöt koskevat kaikkia laskentamoottoreita ja varmistavat yhtenäisen käyttöoikeuksien hallinnan käyttäjille. Käytä semanttista mallia, RLS:ää tai OLS:ää, kun raportointikuluttajille ei myönnetä lupaa kysyä lakehousea tai varastoa ja pilviyhteys käyttää kiinteää identiteettiä SSO:n sijaan. SSO tarkoittaa, että loppukäyttäjät voivat käyttää tietolähdettä suoraan ja voivat siten ohittaa semanttisen mallin turvallisuussäännöt.

Tärkeää

Semanttisen mallikohteen käyttöoikeudet voidaan määrittää eksplisiittisestiPower BI -sovellusten kautta, tai ne voidaan hankkia implisiittisesti työtilaroolien kautta.

Huomionarvoista on, että semanttisen mallin datan käyttöoikeuksia ei valvota käyttäjiltä, joilla on kirjoitusoikeus semanttiseen malliin. Toisaalta tietojen käyttösääntöjä sovelletaan käyttäjiin, joille on määritetty Katselija-työtilarooli. Kuitenkin käyttäjillä, jotka on määritetty Admin-, Jäsen- tai Contributor-työtilan rooliin , on epäsuorasti kirjoitusoikeus semanttisessa mallissa, joten datan käyttöoikeuksia ei valvota. Lisätietoja löytyy kohdasta Roolit työtiloissa.

Säännöt useilla kerroksilla

Voit valvoa tietojen käyttösääntöjä kaikilla kerroksilla. Tähän lähestymistapaan liittyy kuitenkin enemmän monimutkaisuutta ja hallinnan yleiskustannuksia. Tässä tapauksessa käytä kiinteää identiteettiä pilviyhteydelle SSO:n sijaan.

Vertaa datan käyttöoikeussääntöjä

Seuraava taulukko vertaa Direct Laken data-access-asetusvaihtoehtoja SQL-päätelaitteilla ja Direct Lakelle OneLakella.

Käytä tietojen käyttösääntöjä Direct Lake SQL:llä Direct Lake OneLakella Kommentti
Vain semanttinen malli Tuettu Tuettu Käytä tätä vaihtoehtoa, kun käyttäjille ei myönnetä kohteen käyttöoikeuksia lakehouse-kyselyssä tai varastossa. Määritä pilviyhteys käyttämään kiinteitä käyttäjätietoja. Saavuta korkea kyselysuorituskyky muistin välimuistista.
Vain SQL-analytiikan päätepiste Tuettu (palaa DirectQueryyn) Ei sovellu Riippuu Fabric-datan kohteesta (kuten Lakehouse tai Warehouse), jossa käytetään delegoitua identiteettitilaa. Käytä tätä asetusta, kun käyttäjien on käytettävä tietoja joko varastosta tai semanttisesta mallista sekä yhdenmukaisia tietojen käyttösääntöjä. Varmista, että kertakirjautuminen on käytössä pilviyhteydessä. Kyselyjen suorituskyky voi olla hidas DirectQueryn varajärjestelmän vuoksi.
Vain OneLake-turvallisuus Ei sovellu Tuettu Käytä tätä vaihtoehtoa yhtenäiseen käyttöoikeuksien hallintaan kaikissa Fabric-laskentamoottoreissa. OneLake-turvallisuus valvoo OLS:ää ja RLS:ää johdonmukaisesti kaikille käyttäjille, jotka käyttävät dataa millä tahansa reitillä. Saavuta korkea kyselysuorituskyky muistin välimuistista.
Useat kerrokset (semanttinen malli ja SQL-päätepiste) Tuettu Ei sovellu Tämä vaihtoehto aiheuttaa lisäkustannuksia hallinnan kuormitukseen. Määritä pilviyhteys käyttämään kiinteitä käyttäjätietoja.
Useat kerrokset (semanttinen malli ja OneLake-turvallisuus) Ei sovellu Tuettu Ensin sovelletaan OneLake-turvallisuussääntöjä, sitten semanttisia mallisääntöjä. Harkitse sääntöjen yhdistämistä yhteen kerrokseen monimutkaisuuden vähentämiseksi.

Huomioitavat asiat ja rajoitukset

Harkitse näitä Direct Lake -suojausrajoituksia.

Note

Direct Laken semanttisten mallien ja OneLaken tietoturvan ominaisuudet ja ominaisuudet kehittyvät nopeasti. Tarkista päivitykset säännöllisesti.

  • Määritä työtilan näkymät OneLake-turvaroolit, jotka antavat lukuoikeuden lähde-Fabric-kohteisiin. Jos lähdekohteella on pikakuvakkeet toiseen Fabric-kohteeseen, käyttäjän täytyy myös lukea kunkin pikakuvakkeen kohde-Fabric-kohde.
  • Käytä kiinteää identiteettiä eristääksesi käyttäjät lähde-Fabric-kohteesta. Sido Direct Lake -malli pilviyhteyteen. Pidä kertakirjautuminen poissa käytöstä pilviyhteydessä, jotta voit käyttää kiinteitä käyttäjätietoja päivityksissä ja kyselyissä.
  • Direct Lake -semanttiset mallit, jotka perustuvat Fabric OneLake -turvallisuuteen lähdekohteessa, eivät tue varmuuskopiointitoimintoja.
  • Kaksisuuntaisia suhteita ei tueta Direct Lake -mallissa, jos lähde-Fabric-tuote perustuu OneLake-tietoturvan RLS:ään.
  • OneLake-turvallisuus ei tue dynaamisia määritelmiä tai monimutkaisia roolikonfiguraatioita, kuten useiden OLS- ja RLS-roolien yhdistämistä toisiinsa liittyvissä tauluissa.
  • Yhdistä OneLaken suojauksen RLS- ja OLS-käyttöoikeudet yhdeksi rooliksi käyttäjää kohden useiden roolien määrittämisen sijaan.
  • Jos OneLake-tietoturvakonfiguraatio muuttuu, esimerkiksi kohdekohteen pikakuvakeiden muutosten vuoksi, päivitä Direct Lake on OneLake -mallit, jotka pääsevät kyseiseen kohteeseen. Mallit täytyy päivittää manuaalisesti tai käyttämällä päivitysrajapintoja.
  • Jos Lakehousessa on OneLake-suojaus:
    • SQL-analytiikan päätepiste on oletusarvoisesti kiinteä identiteetti Lakehousen omistajalle, joten SQL-analytiikan päätepisteen OneLake-suojaus on sama kuin omistaja (ei rajoituksia). SQL:n Direct Lake käyttää edelleen Direct Lakea, ellei SQL:n yksityiskohtaisia käyttöoikeusrooleja lisätä.
    • SQL-analytiikan päätepiste voidaan muuttaa kertakirjautumiseksi. Kun näin tapahtuu, OneLake-käyttöoikeusroolit lisätään SQL:n yksityiskohtaisina käyttöoikeussääntöinä, ja käyttäjää estetään muokkaamasta niitä suoraan SQL-analytiikan päätepisteessä. Tässä vaiheessa Direct Lake on SQL palaa DirectQuery 100:aan% ajasta.
  • Last updated on