Muistiinpano
Tämän sivun käyttö edellyttää valtuutusta. Voit yrittää kirjautua sisään tai vaihtaa hakemistoa.
Tämän sivun käyttö edellyttää valtuutusta. Voit yrittää vaihtaa hakemistoa.
OneLake-suojauksen avulla Microsoft Fabric laajentaa tapaa, jolla organisaatiot voivat hallita ja pakottaa tietojen käyttöä eri kuormituksissa. Tämä uusi suojauskehys antaa järjestelmänvalvojille enemmän joustavuutta käyttöoikeuksien määrittämiseen. Järjestelmänvalvojat voivat valita keskitetyn hallinnan OneLaken kautta tai yksityiskohtaisen SQL-pohjaisen hallinnan SQL-analytiikan päätepisteessä.
SQL-analytiikan päätepisteen käyttötilat
Kun käytät SQL-analytiikan päätepistettä, valittu käyttöoikeustila määrittää, miten tietoturvaa valvotaan. Fabric tukee kahta erillistä pääsymallia, joista kumpikin tarjoaa erilaisia etuja toiminnallisten ja vaatimustenmukaisuustarpeidesi mukaan:
Käyttäjän käyttäjätietotila: Valvoo suojausta OneLake-roolien ja -käytäntöjen avulla. Tässä tilassa SQL-analytiikan päätepiste välittää kirjautuneen käyttäjän käyttäjätiedot OneLakeen, ja lukuoikeuksia säätelevät kokonaan OneLakessa määritetyt suojaussäännöt. Taulukoiden SQL-tason käyttöoikeuksia tuetaan, mikä varmistaa työkalujen, kuten Power BI:n, muistikirjojen ja lakehousen, yhdenmukaisen hallinnan.
Delegoitu käyttäjätietotila: Tarjoaa täyden hallinnan SQL:n kautta. Tässä tilassa SQL-analytiikan päätepiste muodostaa yhteyden OneLakeen käyttämällä työtilan tai kohteen omistajan käyttäjätietoja, ja suojausta säätelevät yksinomaan tietokannassa määritetyt SQL-käyttöoikeudet . Tämä malli tukee perinteisiä suojausmenetelmiä, kuten GRANT, REVOKE, mukautetut roolit, Row-Level Security ja Dynamic Data Masking.
Kukin tila tukee erilaisia hallintomalleja. Niiden vaikutusten ymmärtäminen on välttämätöntä, jotta voit valita oikean lähestymistavan Fabric-ympäristössäsi.
Käyttötilojen vertailu
Tässä on selkeä ja ytimekäs vertailutaulukko, jossa keskitytään siihen, miten ja missä määrität suojauksen käyttäjän käyttäjätietotilassa verrattuna delegoituun käyttäjätietotilaan – eriteltynä objektityypin ja tietojen käyttökäytäntöjen mukaan:
| Turvallisuuskohde | Käyttäjän identiteettitila | Delegoidun henkilöllisyyden tila |
|---|---|---|
| Taulukot | Pääsyä hallitsevat OneLaken käyttöoikeusroolit.
GRANT
/
REVOKE SQL ei ole sallittu. |
Täysi hallinta SQL:n GRANT/REVOKEavulla. |
| Näkymät | Käytä SQL GRANT/REVOKE -toimintoa käyttöoikeuksien määrittämiseen. | Käytä SQL GRANT/REVOKE -toimintoa käyttöoikeuksien määrittämiseen. |
| Tallennetut menettelyt | Käytä SQL GRANT EXECUTE -toimintoa käyttöoikeuksien määrittämiseen. | Käytä SQL GRANT EXECUTE -toimintoa käyttöoikeuksien määrittämiseen. |
| Funktiot | Käytä SQL GRANT EXECUTE -toimintoa käyttöoikeuksien määrittämiseen. | Käytä SQL GRANT EXECUTE -toimintoa käyttöoikeuksien määrittämiseen. |
| Row-Level suojaus (RLS) | Määritetty OneLake-käyttöliittymässä osana OneLaken käyttöoikeusrooleja. | Määritetty käyttämällä SQL CREATE SECURITY POLICY. |
| Column-Level Turvallisuus (CLS) | Määritetty OneLake-käyttöliittymässä osana OneLaken käyttöoikeusrooleja. | Määritetty SQL GRANT SELECT -toiminnolla sarakeluettelon kanssa. |
| Dynaaminen tietojen peittäminen (DDM) | Ei tueta OneLaken suojauksessa. | Määritetty käyttämällä SQL:ää ALTER TABLE ja MASKED vaihtoehtoa. |
Käyttäjän käyttäjätietotila OneLaken suojauksessa
Käyttäjätietojen tilassa SQL-analytiikan päätepiste käyttää läpivientitodennusmekanismia tietojen käytön pakottamiseen. Kun käyttäjä muodostaa yhteyden SQL-analytiikan päätepisteeseen, hänen Entra ID -identiteettinsä välitetään OneLakeen, joka suorittaa käyttöoikeuksien tarkistuksen. Kaikki taulukoiden lukutoiminnot arvioidaan OneLake Lakehousessa määritettyjen suojaussääntöjen avulla, ei SQL-tason GRANT- tai REVOKE-lausekkeilla.
Tämän tilan avulla voit hallita suojausta keskitetysti ja varmistaa yhdenmukaisen täytäntöönpanon kaikissa Fabric-kokemuksissa, mukaan lukien Power BI, muistikirjat, lakehouse ja SQL-analytiikan päätepiste. Se on suunniteltu hallintomalleihin, joissa käyttöoikeus on määritettävä kerran OneLakessa ja sitä tulee kunnioittaa automaattisesti kaikkialla.
Käyttäjän identiteettitilassa:
Taulukoiden käyttöä säätelee kokonaan OneLaken suojaus. Taulukoiden SQL GRANT/REVOKE -lausekkeet ohitetaan.
RLS (Row-Level Security), CLS (Column-Level Security) ja Object-Level Security on kaikki määritetty OneLake-kokemuksessa.
SQL-käyttöoikeudet sallitaan muille kuin tietoobjekteille, kuten näkymille, tallennetuille toimintosarjoille ja funktioille, mikä mahdollistaa joustavuuden mukautetun logiikan tai käyttäjälle suunnattujen tietojen aloituskohtien määrittämisessä.
Kirjoitustoimintoja ei tueta SQL-analytiikan päätepisteessä. Kaikkien kirjoitusten on tapahduttava Lakehouse-käyttöliittymän kautta, ja niitä hallitsevat työtilan roolit (järjestelmänvalvoja, jäsen, osallistuja).
Tärkeää
SQL Analytics -päätepiste edellyttää OneLake-käyttöoikeusroolin kohteiden käyttöoikeuksien ja jäsenten välistä yksi-yhteen-määritystä, jotta se voidaan synkronoida oikein. Jos myönnät käyttäjätietojen käyttöoikeuden OneLake-käyttöoikeusrooliin, samalla käyttäjätiedolla on oltava myös Fabric Read -oikeus lakehouseen. Jos käyttäjä esimerkiksi määrittää "user123@microsoft.com" OneLake-käyttöoikeusrooliin, myös "user123@microsoft.com" on määritettävä kyseiselle lakehouselle.
Työtilan roolin toiminta
Käyttäjät, joilla on järjestelmänvalvojan, jäsenen tai osallistujan rooli työtilatasolla, eivät ole OneLaken suojauksen valvonnan alaisia. Näillä rooleilla on laajennetut oikeudet, ja ne ohittavat rivitason suojauksen (rivitason suojaus), CLS- ja OLS-käytännöt kokonaan. Noudata näitä vaatimuksia varmistaaksesi, että OneLaken suojausta noudatetaan:
Määritä käyttäjille Katselija-rooli työtilassa tai
Jaa Lakehouse- tai SQL-analytiikan päätepiste käyttäjien kanssa, joilla on vain luku -käyttöoikeudet. Vain niiden käyttäjien, joilla on vain luku -käyttöoikeus, kyselyt suodatetaan OneLaken käyttöoikeusroolien mukaan.
Roolien etuoikeus: Sallivin käyttöoikeus voittaa
Jos käyttäjä kuuluu useisiin OneLake-rooleihin, sallivin rooli määrittää hänen tehokkaan käyttöoikeutensa. Esimerkkejä:
Jos yksi rooli myöntää taulukon täydet käyttöoikeudet ja toinen käyttää rivitason suojausta rivien rajauksen rajoittamiseen, rivitason suojausta ei pakoteta.
Laajempi käyttöoikeusrooli on etusijalla. Tämä toiminta varmistaa, että käyttäjiä ei estetä tahattomasti, mutta se vaatii huolellista roolisuunnittelua ristiriitojen välttämiseksi. On suositeltavaa pitää rajoittavat ja sallivat roolit toisensa poissulkevina , kun pakotat rivi- tai saraketason käyttöoikeuksia.
Lisätietoja on OneLaken suojauksen tietojen käyttöoikeuksien hallintamallissa .
Suojauksen synkronointi OneLaken ja SQL-analytiikan päätepisteen välillä
Käyttäjän käyttäjätietotilan kriittinen osa on suojauksen synkronointipalvelu. Tämä taustapalvelu valvoo OneLaken käyttöoikeusrooleihin tehtyjä muutoksia ja varmistaa, että muutokset näkyvät SQL-analytiikan päätepisteessä.
Suojauksen synkronointipalvelu vastaa seuraavista:
OneLake-roolien muutosten havaitseminen, mukaan lukien uudet roolit, päivitykset, käyttäjämääritykset ja taulukoiden muutokset.
OneLaken määrittämien käytäntöjen (RLS, CLS, OLS) kääntäminen vastaaviksi SQL-yhteensopiviksi tietokantaroolirakenteiksi.
Varmista, että pikakuvakeobjektit (muista lakehouseista hankitut taulukot) on validoitu oikein, jotta alkuperäisiä OneLaken suojausasetuksia noudatetaan, vaikka niitä käytettäisiin etänä.
Tämä synkronointi varmistaa, että OneLaken suojausmääritykset pysyvät hallitsevina, jolloin manuaalisia SQL-tason toimenpiteitä ei tarvita suojauskäyttäytymisen replikoimiseksi. Koska suojausta valvotaan keskitetysti:
Et voi määrittää rivitason suojausta, CLS:ää tai OLS:ää suoraan T-SQL:n avulla tässä tilassa.
Voit edelleen käyttää SQL-käyttöoikeuksia näkymiin, funktioihin ja tallennettuihin toimintosarjoihin käyttämällä GRANT- tai EXECUTE-lausekkeita.
Suojauksen synkronointivirheet ja ratkaisu
| Skenaario | Käyttäytyminen käyttäjätietotilassa | Käyttäytyminen delegoidussa tilassa | Korjaavat toimet | Muistiinpanot |
|---|---|---|---|---|
| RLS-käytäntö viittaa poistettuun tai uudelleen nimettyyn sarakkeeseen | Virhe: *Rivitason suojauskäytäntö viittaa sarakkeeseen, jota ei enää ole.*Tietokanta siirtyy virhetilaan, kunnes käytäntö on korjattu. | Virhe: Virheellinen sarakkeen nimi <sarakkeen nimi> | Päivitä tai poista yksi tai useampi rooli, jota ongelma koskee, tai palauta puuttuva sarake. | Päivitys on tehtävä järvitalossa, jossa rooli luotiin. |
| CLS-käytäntö viittaa poistettuun tai uudelleen nimettyyn sarakkeeseen | Virhe: *Saraketason suojauskäytäntö viittaa sarakkeeseen, jota ei enää ole.*Tietokanta siirtyy virhetilaan, kunnes käytäntö on korjattu. | Virhe: Virheellinen sarakkeen nimi <sarakkeen nimi> | Päivitä tai poista yksi tai useampi rooli, jota ongelma koskee, tai palauta puuttuva sarake. | Päivitys on tehtävä järvitalossa, jossa rooli luotiin. |
| RLS/CLS-käytäntö viittaa poistettuun tai uudelleennimettyyn taulukkoon | Virhe: Suojauskäytäntö viittaa taulukkoon, jota ei enää ole olemassa. | Virhettä ei tullut esiin; Kysely epäonnistuu äänettömästi, jos taulukko puuttuu. | Päivitä tai poista yksi tai useampi rooli, jota ongelma koskee, tai palauta puuttuva taulukko. | Päivitys on tehtävä järvitalossa, jossa rooli luotiin. |
| DDM (Dynamic Data Masking) -käytäntö viittaa poistettuun tai uudelleen nimettyyn sarakkeeseen | DDM, jota OneLake Security ei tue, on toteutettava SQL:n kautta. | Virhe: Virheellinen sarakkeen nimi <sarakkeen nimi> | Päivitä tai poista yksi tai useampi DDM-sääntö, jota ongelma koskee, tai palauta puuttuva sarake. | Päivitä DDM-käytäntö SQL Analytics -päätepisteessä. |
| Järjestelmävirhe (odottamaton vika) | Virhe: Tapahtui odottamaton järjestelmävirhe. Yritä uudelleen tai ota yhteyttä tukeen. | Virhe: Sisäinen virhe on tapahtunut käytettäessä taulukon muutoksia SQL:ään. | Yritä toimintoa uudelleen; Jos ongelma jatkuu, ota yhteyttä Microsoft-tukeen. | – |
| Käyttäjällä ei ole artefaktin käyttöoikeutta | Virhe: Käyttäjällä ei ole artefaktin käyttöoikeutta | Virhe: Käyttäjällä ei ole artefaktin käyttöoikeutta | Anna käyttäjälle objectID {objectID} -käyttöoikeus artefaktiin. | Objektitunnuksen on vastattava tarkasti OneLake-käyttöoikeusroolin jäsentä ja Fabric-kohteen käyttöoikeuksia. Jos ryhmä lisätään roolijäsenyyteen, samalle ryhmälle on annettava kankaan lukuoikeus. Kyseisen ryhmän jäsenen lisäämistä kohteeseen ei lasketa suoraksi vastaavuudeksi. |
| Käyttäjän päänimeä ei tueta. | Virhe: Käyttäjän päänimeä ei tueta. | Virhe: Käyttäjän päänimeä ei tueta. | Poista käyttäjä {käyttäjänimi} roolista DefaultReader | Tämä virhe ilmenee, jos käyttäjällä ei ole enää kelvollista Entra-tunnusta, esimerkiksi jos käyttäjä on poistunut organisaatiostasi tai poistettu. Poista heidät roolista tämän virheen ratkaisemiseksi. |
Pikakomentojen toiminta suojauksen synkronoinnin kanssa
OneLaken suojausta valvotaan totuuden lähteellä, joten suojauksen synkronointi poistaa käytöstä oikopolkuja sisältävien taulukoiden ja näkymien omistajuuden ketjuttamisen. Näin varmistetaan, että lähdejärjestelmän käyttöoikeudet arvioidaan ja niitä kunnioitetaan aina, myös toisesta tietokannasta tulevissa kyselyissä.
Tämän seurauksena:
Käyttäjillä on oltava kelvolliset käyttöoikeudet sekä pikakuvakkeen lähteeseen (nykyinen Lakehouse- tai SQL-analytiikkapäätepiste) ettäkohteeseen , jossa tiedot fyysisesti sijaitsevat.
Jos käyttäjällä ei ole oikeuksia kummallakaan puolella, kyselyt epäonnistuvat käyttövirheen vuoksi.
Kun suunnittelet pikakuvakkeisiin viittaavia sovelluksia tai näkymiä, varmista, että roolimääritykset on määritetty oikein pikakuvakesuhteen molemmissa päissä .
Tämä rakenne säilyttää suojauksen eheyden Lakehousen rajojen yli, mutta se esittelee skenaarioita, joissa käyttövirheitä saattaa tapahtua, jos Lakehousen välisiä rooleja ei ole kohdistettu.
Delegoitu tila OneLaken suojauksessa
Delegoidun käyttäjätiedon tilassa SQL-analytiikan päätepiste käyttää samaa suojausmallia, joka on tällä hetkellä olemassa Microsoft Fabricissa. Suojausta ja käyttöoikeuksia hallitaan kokonaan SQL-kerroksessa, eikä OneLake-rooleja tai käyttöoikeuskäytäntöjä pakoteta taulukkotason käyttöoikeuksiin. Kun käyttäjä muodostaa yhteyden SQL-analytiikan päätepisteeseen ja lähettää kyselyn:
SQL vahvistaa käyttöoikeuden SQL-käyttöoikeuksien perusteella (GRANT, REVOKE, RLS, CLS, DDM, roolit jne.).
Jos kysely on valtuutettu, järjestelmä pääsee käsiksi OneLakeen tallennettuihin tietoihin.
Tämä tietojen käyttö suoritetaan käyttämällä Lakehouse- tai SQL-analytiikan päätepisteen omistajan käyttäjätietoja, joita kutsutaan myös kohdetiliksi.
Tässä mallissa:
Kirjautunutta käyttäjää ei välitetä OneLakeen.
Kaikki käyttöoikeuksien pakottamisen oletetaan tapahtuvan SQL-tasolla.
Kohteen omistaja on vastuussa siitä, että hänellä on riittävät oikeudet OneLakessa lukea pohjana olevia tiedostoja kuormituksen puolesta.
Koska tämä on delegoitu malli, SQL-käyttöoikeuksien ja omistajan OneLake-käyttöoikeuksien väliset epäkohdistamiset johtavat kyselyn epäonnistumiseen. Tämä tila tarjoaa täyden yhteensopivuuden seuraavien kanssa:
SQL GRANT/REVOKE kaikilla objektitasoilla
SQL:n määrittämät Row-Level suojaus, Column-Level suojaus ja dynaaminen tietojen peittäminen
Nykyiset T-SQL-työkalut ja DBA:iden tai sovellusten käyttämät käytännöt
OneLake-käyttötilan vaihtaminen
Käyttöoikeustila määrittää, miten tietojen käyttö todennetaan ja valvotaan, kun OneLakea tehdään kysely SQL-analytiikan päätepisteen kautta. Voit vaihtaa käyttäjätietotilan ja delegoidun käyttäjätietotilan välillä seuraavasti:
Siirry Fabric-työtilaan ja avaa lakehouse. Siirry oikeasta yläkulmasta lakehousesta SQL-analytiikan päätepisteeseen.
Siirry ylänavigaatiossa Suojaus-välilehteen ja valitse jokin seuraavista OneLake-käyttötiloista:
Käyttäjätiedot – Käyttää kirjautuneen käyttäjän käyttäjätietoja. Se pakottaa OneLake-roolit.
Delegoitu käyttäjätieto – Käyttää kohteen omistajan käyttäjätietoja; pakottaa vain SQL-käyttöoikeudet.
Ponnahdusikkuna avautuu valintasi vahvistamiseksi. Vahvista muutos valitsemalla Kyllä .
Huomioitavaa tilojen välillä vaihdettaessa
Siirtyminen käyttäjän identiteettitilaan
SQL RLS-, CLS- ja taulukkotason käyttöoikeudet ohitetaan.
OneLake-roolit on määritettävä, jotta käyttäjät voivat ylläpitää käyttöoikeuksia.
OneLaken suojaus hallitsee vain käyttäjiä, joilla on katseluoikeudet tai jaettu vain luku -käyttöoikeus.
Aiemmin luodut SQL-roolit poistetaan, eikä niitä voi palauttaa.
Siirtyminen delegoidun henkilöllisyyden tilaan
OneLake-rooleja ja suojauskäytäntöjä ei enää käytetä.
SQL-roolit ja suojauskäytännöt aktivoituvat.
Kohteen omistajalla on oltava kelvollinen OneLake-käyttöoikeus, muuten kaikki kyselyt voivat epäonnistua.
Rajoitukset
Koskee vain lukijoita: OneLake Security hallitsee käyttäjiä, jotka käyttävät tietoja katselijoina. Muiden työtilaroolien käyttäjät (järjestelmänvalvoja, jäsen tai osallistuja) ohittavat OneLake Securityn ja säilyttävät täydet käyttöoikeudet.
SQL-objektit eivät peri omistajuutta: Pikakomennot näkyvät SQL-analytiikan päätepisteessä taulukoina. Kun näitä taulukoita käytetään suoraan tai näkymien kautta, tallennetuilla toimintosarjoilla ja muilla johdetuilla SQL-objekteilla ei ole objektitason omistajuutta. Kaikki käyttöoikeudet tarkistetaan suorituksen aikana suojauksen ohittamisen estämiseksi.
Pikakomentojen muutokset käynnistävät vahvistuksen käyttökatkon: Kun pikakomennon kohde muuttuu (esimerkiksi nimeä uudelleen, URL-osoitteen päivitys), tietokanta siirtyy hetkeksi yhden käyttäjän tilaan , kun järjestelmä vahvistaa uuden kohteen. Tänä aikana kyselyt estetään, nämä toiminnot ovat melko nopeita, mutta joskus eri sisäisistä prosesseista riippuen synkronointi voi kestää jopa 5 minuuttia.
- Rakenteen pikakuvakkeiden luominen saattaa aiheuttaa tunnetun virheen, joka vaikuttaa vahvistukseen ja viivästyttää metatietojen synkronointia.
Viivästynyt käyttöoikeuksien levittäminen: Käyttöoikeuksien muutokset eivät tapahdu välittömästi. Suojaustilojen välillä vaihtaminen (User Identity vs. Deleged) saattaa viedä aikaa ennen kuin se tulee voimaan, mutta sen pitäisi kestää alle 1 minuutti.
Ohjaustason riippuvuus: Käyttöoikeuksia ei voi käyttää käyttäjille tai ryhmille, joita ei vielä ole työtilan ohjaustasossa. Sinun on joko jaettava lähdekohde tai käyttäjän on oltava Katselija-työtilan roolin jäsen. Huomaa, että täsmälleen saman objektitunnuksen on oltava molemmissa paikoissa. Ryhmää ja ryhmän jäsentä ei lasketa vastaavuudeksi.
Sallivin käyttöoikeus on voimassa: Kun käyttäjät kuuluvat useisiin ryhmiin tai rooleihin, sallivinta voimassa olevaa käyttöoikeutta kunnioitetaan Esimerkki: Jos käyttäjällä on sekä ESTÄ yhden roolin kautta että GRANT toisen roolin kautta, GRANT on etusijalla.
Delegoidun tilan rajoitukset: Delegoidussa tilassa pikakuvaketaulukoiden metatietojen synkronointi voi epäonnistua, jos lähdekohteella on OneLake Security -käytäntöjä, jotka eivät myönnä kohteen omistajalle täyttä taulukon käyttöoikeutta.
ESTÄ toiminta: Kun useita rooleja käytetään yhdessä pikakuvaketaulukossa, käyttöoikeuksien leikkauspiste noudattaa SQL Server semantiikkaa: ESTÄ ohittaa GRANT-toiminnon. Tämä voi tuottaa odottamattomia käyttötuloksia.
Odotetut virhetilanteet: Käyttäjät voivat kohdata virheitä esimerkiksi seuraavissa tilanteissa:
Pikakuvakkeen kohde on nimetty uudelleen tai virheellinen
- Esimerkki: Jos taulukon lähde on poistettu.
RLS (Row-Level Security) virheellinen määritys
Joitakin RLS-suodatuksen lausekkeita ei tueta OneLakessa, ja se saattaa sallia luvattoman tietojen käytön.
Suodatinlausekkeessa käytetyn sarakkeen poistaminen mitätöi rivitason suojauksen ja metatietojen synkronointi on vanhentunut, kunnes rivitason suojaus on korjattu OneLaken suojauspaneelissa.
Julkisessa esikatselussa tuemme vain yhden lausekkeen taulukoita. Dynaamista rivitason suojausta ja usean taulukon rivitason suojausta ei tueta tällä hetkellä.
Column-Level Security (CLS) -rajoitukset
CLS toimii ylläpitämällä sallittujen sarakkeiden luetteloa. Jos sallittu sarake poistetaan tai nimetään uudelleen, CLS-käytäntö muuttuu virheelliseksi.
Kun CLS on virheellinen, metatietojen synkronointi estetään, kunnes CLS-sääntö on korjattu OneLaken suojauspaneelissa.
Metatietojen tai käyttöoikeuksien synkronointivirhe
- Jos taulukkoon tehdään muutoksia, kuten sarake nimetään uudelleen, suojausta ei replikoida uuteen objektiin ja näyttöön tulee käyttöliittymävirheitä, jotka osoittavat, että saraketta ei ole olemassa.
Taulukon uudelleennimeämiset eivät säilytä suojauskäytäntöjä: Jos OneLake Security (OLS) -roolit on määritetty rakennetasolla, nämä roolit pysyvät voimassa vain niin kauan kuin taulukon nimi on muuttumaton. Taulukon uudelleennimeäminen katkaisee liitoksen, eikä suojauskäytäntöjä siirretä automaattisesti. Tämä voi johtaa tahattomaan tietojen altistumiseen, kunnes käytäntöjä käytetään uudelleen.
OneLaken käyttöoikeusrooleilla ei voi olla yli 124 merkkiä pitkiä nimiä. Muussa tapauksessa suojauksen synkronointi ei voi synkronoida rooleja.
OneLake-käyttöoikeusrooleja levitetään SQL-analytiikan päätepisteessä OLS_-etuliitteellä.
OLS_ roolien käyttäjämuutoksia ei tueta, ja ne voivat aiheuttaa odottamatonta toimintaa.
Sähköpostia käyttäviä käyttöoikeusryhmiä ja jakeluluetteloita ei tueta.
Lakehousen omistajan on oltava järjestelmänvalvojan, jäsenen tai osallistujan työtilan roolien jäsen. Muussa tapauksessa suojausta ei käytetä SQL-analytiikan päätepisteessä.
Lakehousen omistaja ei voi olla palvelun päänimi, jotta suojauksen synkronointi toimii.