Miten OneLake-turvallisuus hallitsee tietojen saatavuutta

OneLake-turvallisuus on roolipohjainen järjestelmä, joka määrittää, kuka pääsee käsiksi OneLaken tietoihin ja mitä toimenpiteitä he voivat tehdä niillä datalla. Tietojen käyttöoikeuksien hallintamallin ymmärtäminen auttaa sinua antamaan käyttäjille vain tarvitsemansa pääsyn, jolloin voit suojata arkaluonteisia tietoja ja silti antaa oikeiden ihmisten työskennellä niiden kanssa.

Tässä artikkelissa selitetään, miten OneLaken turvallisuusroolit on rakennettu, miten ne integroituvat työtila- ja kohdeoikeuksiin, miten OneLake soveltaa ja ratkaisee pääsyn tietoihisi, sekä rajat, jotka kannattaa pitää mielessä.

OneLaken käyttöoikeusroolit

OneLake-turvallisuus käyttää roolipohjaista kulunvalvontamallia (RBAC) hallitakseen pääsyä OneLakessa. OneLake-tietoturvakokemuksessa jokaisessa roolissa on seuraavat komponentit:

  • Käyttöoikeudet: Oikeudet, joita rooli antaa datalle, kuten Read tai ReadWrite.
  • Tyyppi: Roolityyppi. OneLaken turvallisuus tukee vain Grant-rooleja, jotka antavat jäsenille pääsyn roolin tietoihin. Se ei tue Deny-rooleja, jotka poistavat pääsyn.
  • Data roolissa: Taulukot, kansiot tai skeemat, joihin rooli antaa pääsyn. Voit myös määritellä datan pääsyn rivi- ja sarakketason turvallisuuden avulla tauluissa.
  • Jäsenet roolissa: Rooliin liitetyt Microsoft Entra -identiteetit, kuten käyttäjät, ryhmät tai ei-käyttäjä-identiteetit. Jos määrität Microsoft Entra -ryhmän, OneLake-turvallisuus myöntää roolin kaikille ryhmän jäsenille.

OneLake-turvallisuus käyttää oletuksena kieltävää mallia, joten käyttäjät aloittavat ilman pääsyä tietoihin, ellei OneLake-turvallisuusrooli nimenomaisesti myönnä pääsyä. Jotkut Fabric-esineet alkavat oletusrooleilla, jotka antavat käyttäjille perusoikeudet työtilan oikeuksien perusteella.

Käyttöoikeudet ja tuetut kohteet

OneLake-tietoturvaroolit tukevat seuraavia käyttöoikeuksia:

  • Lukea: Antaa käyttäjälle mahdollisuuden lukea tietoja taulukosta ja tarkastella niihin liittyviä taulukon ja sarakkeen metatietoja. SQL-termein tämä oikeus vastaa sekä VIEW_DEFINITION että SELECT. Lisätietoja löytyy Metatietojen tietoturvasta.
  • ReadWrite: Antaa käyttäjälle mahdollisuuden lukea ja kirjoittaa dataa taulukkoon tai kansioon sekä tarkastella siihen liittyvää taulukko- ja sarakkemetadataa. SQL-termein tämä oikeus vastaa ALTER, DROP, UPDATE, ja INSERT. Lisätietoja löytyy osoitteesta ReadWrite-lupa.

Voit luoda OneLake-turvallisuusrooleja seuraaville Fabric-kohteille:

Kangas esine Tuetut käyttöoikeudet
Lakehouse Lue, lueKirjoita
Azure Databricks mirrored catalog Read
Peilatut tietokannat Read
Peililuettelot Read

ReadWrite-lupa

Käytä ReadWrite-oikeutta antaaksesi vain luku -käyttäjille kirjoitusoikeudet tiettyihin tietoihin kohteessa.

ReadWrite koskee vain käyttäjiä, joilla on lukuoikeus kohteeseen, kuten käyttäjiä, joilla on Viewer-työtilarooli. ReadWriten määrittäminen työtilan ylläpitäjälle, jäsenelle tai osallistujalle ei vaikuta lainkaan, koska näillä työtilan rooleilla on jo kirjoitusoikeus.

ReadWrite sisältää kaikki lukuluvan myöntämät oikeudet sekä kirjoitusoikeuden valittuun objektiin ja sen sisältöön. Esimerkiksi ReadWrite-oikeus kansiossa antaa kirjoitusoikeuden sekä kansioon että sen sisällä oleviin tietoihin.

Käyttäjät, joilla on ReadWrite-oikeus, voivat suorittaa seuraavat toiminnot:

  • Luo, poista tai nimeä kansio tai taulu uudelleen.
  • Lataa tai muokkaa tiedostoa.
  • Luo, poista tai nimeä pikakuvake uudelleen.

Käyttäjät voivat suorittaa kirjoitustoimintoja Spark-muistikirjojen, OneLake-tiedostonhallinnan tai OneLake-rajapintojen kautta. Koska Fabric tukee vain yksimoottorisia kirjoituksia dataan, ReadWrite-luvan omaavat käyttäjät voivat kirjoittaa kyseiseen dataan vain OneLaken kautta. Kaikki kyselymoottorit jatkavat lukutoimintojen johdonmukaista käyttöönottoa.

OneLake-tietoturvaroolit, jotka myöntävät ReadWrite-luvan, eivät voi sisältää rivitason tietoturvaa (RLS) tai sarakketason tietoturvaa (CLS).

OneLaken suojaus ja työtilan käyttöoikeudet

Työtilaroolit ovat OneLaken ensimmäinen tietoturvaraja datalle. Ne hallinnoivat ohjaustasoa – luoden ja hallinnoiden Fabric-kohteita ja käyttöoikeuksia – ja soveltavat niitä kaikkiin työtilan kohteisiin. Kunkin työtilan roolin tarjoamia OneLake-oikeuksia varten katso Myönnä käyttöoikeus työtilaroolien kanssa. Lisätietoja työtilarooleista löydät kohdasta Roolit työtiloissa Fabric-sivustolla.

Ohjaustason käytön lisäksi työtilan roolit voivat myös tarjota pääsyn datakohteisiin OneLake-tietoturvan oletusroolien kautta. (Oletusroolit koskevat vain katsojia, koska ylläpitäjä-, jäsen- ja osallistujarooleilla on korotettu pääsy kirjoitusluvan kautta.) Oletusrooli on tavallinen OneLake-turvarooli, jonka Fabric luo automaattisesti jokaisen uuden tuotteen yhteydessä. Se antaa käyttäjille, joilla on tietyt työtilan tai kohteen käyttöoikeudet, oletustason käyttöoikeuden kyseisen kohteen tietoihin. Esimerkiksi lakehouse-kohteilla on DefaultReader-rooli, jonka avulla ReadAll-luvan omaavat käyttäjät voivat nähdä lakehousen dataa. Tämä oletuspääsy varmistaa, että käyttäjillä, jotka työskentelevät juuri luodun kohteen parissa, on peruspääsy. Kaikki oletusroolit käyttävät jäsenvirtualisointiominaisuutta, jolloin roolin jäsenet ovat kaikki kyseisen työtilan käyttäjät, joilla on vaadittu käyttöoikeus. Esimerkiksi kaikki käyttäjät, joilla on ReadAll-lupa järvenrakennuksessa.

Seuraava taulukko näyttää vakiooletusroolit. Esineillä voi olla erikoistuneita oletusrooleja, jotka koskevat vain kyseistä esinetyyppiä.

Kangas esine Roolin nimi Lupa myönnetty Nimetyt jäsenet
Lakehouse DefaultReader Read Kaikki käyttäjät, joilla on ReadAll-käyttöoikeus
Azure Databricks mirrored catalog DefaultReader Read Kaikki käyttäjät, joilla on lukuoikeus
Peilattu luettelo DefaultReader Read Kaikki käyttäjät, joilla on lukuoikeus
Peilattu tietokanta DefaultReader Read Kaikki käyttäjät, joilla on ReadAll-käyttöoikeus

Voit muokata tai poistaa oletusroolin Fabric-esineestä muuttaaksesi käyttäjien pääsyä kyseisessä jäsenryhmässä.

Moottorin ja käyttäjän pääsy tietoihin

OneLake-turvallisuus käyttää oletuksena vähiten etuoikeutettua pääsyä. Jotkut tallennustasoiset toiminnot eivät pysty valvomaan RLS:ää tai CLS:ää, joten kun kyselyä ei voida turvallisesti suodata, OneLake estää sen kokonaan sen sijaan, että riski paljastaa käyttäjälle kiellettyä dataa. Se, suodatetaanko kysely vai estetäänkö, riippuu pääsypolusta – tuetusta kyselymoottorista vai suorasta käyttäjän pääsystä.

Moottorit, jotka tukevat RLS- ja CLS-suodatusta, sekä niiden vaatimuksista, katso Read data secureed by OneLake security.

Soveltamisalueet ja valvonta

Tässä osiossa on tietoja siitä, miten OneLaken käyttöoikeusroolit myöntävät käyttöoikeuden tiettyihin vaikutusalueisiin, miten tämä käyttöoikeus toimii ja miten käyttöoikeudet ratkaistaan useissa rooleissa ja käyttöoikeustyypeissä.

Taulukkotason turvallisuus

OneLake esittää kaikki taulut kansioina, mutta OneLake-tietoturvan ja Fabric-kyselymoottoreiden näkökulmasta kaikki kansiot eivät ole tauluja. Jotta kansio olisi kelvollinen taulu, sen on täytettävä seuraavat ehdot:

  • Kansio sijaitsee Tables/ tuotteen hakemistossa. Skeema-yhteensopivien kohteiden kohdalla kansion on myös oltava voimassa olevassa skeemakansiossa.
  • Kansio sisältää kansion _delta_log , jossa on vastaavat JSON-tiedostot taulukon metatietoja varten.
  • Kansiossa ei ole lapsipikakuvakkeita.

Jos konfiguroit RLS:n tai CLS:n taululle, OneLake kieltää pääsyn, jos taulun kansio ei täytä näitä kriteerejä. Ilman RLS:ää tai CLS:ää OneLake käsittelee kansiota, joka ei täytä näitä kriteerejä, kansiona ja soveltaa kansiotason turvallisuutta.

Rivi- ja sarakketason turvallisuus

Roolin sisällä voit rajoittaa pääsyä tiettyihin riveihin ja sarakkeihin taulukossa käyttämällä rivitason turvallisuutta ja sarakketason turvallisuutta. Lisätietoja siitä, mitä kukin ohjaus tekee ja miten OneLake valvoo sitä, löydät OneLaken taulu-, sarakke- ja rivitason tietoturvasta. Lisätietoja siitä, miten RLS ja CLS ratkaisevat, kun käyttäjä kuuluu useampaan rooliin, löydät kohdasta Arvioi useita OneLake-turvallisuusrooleja.

Metatietojen suojaus

OneLake-tietoturvan lukulupa antaa täyden pääsyn taulukon tietoihin ja metatietoihin. Käyttäjille, joilla ei ole pääsyä taulukkoon, data ei koskaan paljasteta. Tämä sääntö koskee myös sarakketason turvallisuutta ja käyttäjän kykyä nähdä tai olla näkemättä saraketta kyseisessä taulukossa. Kuitenkin OneLaken turvallisuus ei takaa, etteikö taulukon metatiedot olisi saatavilla. Tietyt virheilmoitukset ja kokemukset saattavat näyttää sarakkeen nimiä.

Kansion käyttöoikeuksien periytyminen ja läpikäynti

Kansiooikeudet vaikuttavat hierarkiaan kahteen suuntaan:

  • Perintö: Kansiolle myönnetyt oikeudet koskevat sen tiedostoja ja alikansioita.
  • Läpikäynti ja listautuminen: Kun käyttäjillä on oikeus lapsituotteeseen, OneLaken turvallisuus antaa heidän listata ja selata sen vanhemmat kansiot, jotta he voivat löytää ja navigoida niihin tietoihin, joihin pääsevät käsiksi. Traversal ei anna pääsyä sisarustiedostoihin tai kansioihin.

Tarkastellaan seuraavaa järvimajan hierarkiaa OneLakessa:

Tables/
──── (empty folder)
Files/
────folder1
│   │   file11.txt
│   │
│   └───subfolder11
│       │   file111.txt
│       │
│       └───subfolder111
│            │   file1111.txt
│   
└───folder2
    │   file21.txt

Luot roolin, Role1, joka antaa lukuluvan .subfolder11 Perinnön kautta tämän roolin jäsenet voivat lukea file111.txt ja kaiken .subfolder111 Jäsenet voivat nähdä ja liikkua folder1 päästäkseen subfolder11, mutta he eivät näe file11.txt , koska se on sisar, subfolder11 eivätkä he näe Tables , koska se on sisarus Files.

Files/
│
└───folder1
│   │
│   └───subfolder11 <-- READ
│       │   file111.txt
│       │
│       └───subfolder111
│            │   file1111.txt

Luot toisen roolin, Role2, joka antaa lukuluvan .folder2 Perinnön kautta jäsenet voivat lukea file21.txt. Jäsenet voivat kulkea folder2 sen läpi ja Files päästä siihen, mutta he eivät näe folder1 tai sen lapsia.

Files/
│
└───folder2 <-- READ
    │   file21.txt

Oikoteissä käyttäytyminen on hieman erilaista. Pikakuvakkeet ulkoisiin tietolähteisiin käyttäytyvät samalla tavalla kuin kansiot. Kuitenkin oikoteillä muihin OneLake-toimipisteisiin on erikoistunutta käyttäytymistä. Pikakuvakkeen kohdekäyttöoikeudet määrittävät OneLake-pikakuvakkeen käytön. Oikoteitä listattaessa OneLake ei soita tarkistaakseen kohdepääsyä. Tämän seurauksena, kun listaat hakemiston, OneLake palauttaa kaikki sisäiset pikakuvakkeet riippumatta siitä, käytänkö kohdetta. Pääsytarkistus arvioi, kun yrität avata pikakuvakkeen, ja näet vain ne tiedot, joihin sinulla on tarvittavat oikeudet.

Shortcuts

OneLake-turvallisuus integroituu pikakuvakkeisiin suojatakseen dataa OneLaken sisällä ja ulkopuolella. Pikakuvakkeet käyttävät kahta todennustapaa:

  • Läpikulku: Pikakuvake käyttää kyselyn tekijän identiteettiä päästäkseen kohteeseen. Passthrough on oletus OneLake-to-OneLake -oikoteille.
  • Delegoitu: Pikakuvake käyttää konfiguroitua yhteyshenkilöllisyyttä tai tunnistetta kohteen avaamiseen. OneLake-OneLake-pikakuvakkeet voivat käyttää delegoitua tunnistautumista, ja ulkoisten järjestelmien pikakuvakkeet käyttävät aina delegoitua tunnistautumista.

Pikakuvakkeen luominen vaatii oikeudet sekä sille polulle, jolle pikakuvake luodaan, että kohdepolulle. Jokaisen pikakuvaketyypin luomisen ja pääsyn vaatimukset löytyvät OneLake-pikakuvakeiden tietoturvasta.

OneLaken suojaus läpivientipikanäppäimissä

Kun käyttäjä käyttää dataa OneLake-to-OneLake -pikakuvakkeen kautta, OneLake käyttää kutsuvan käyttäjän identiteettiä valtuuttaakseen pääsyn kohdepolulle. Käyttäjän tehokas pääsy on rajoitettu hänen oikeuksillaan sekä pikapolun että kohdepolun osalta.

Note

Kyselymoottorin identiteetti ja pikakuvakeiden tunnistautuminen ovat erillisiä asetuksia. Läpioikotie käyttää yleensä kutsuvan käyttäjän identiteettiä päästäkseen kohteeseen. Kuitenkin Power BI:n semanttiset mallit, joissa käytetään Direct Lake over SQL- ja SQL-analytiikkapäätepisteitä delegoidussa identiteettitilassa, käyttävät kuluttajatuotteen tai tietolähteen omistaja-identiteettiä. Tämä käyttäytyminen ei muuta pikakuvakkeen määritettyä tunnistautumistilaa. Käyttäjäidentiteetin läpikulkua varten käytä Direct Lakea OneLaken kautta tai konfiguroi SQL-analytiikkapäätepiste käyttämään käyttäjän identiteetin käyttötilaa.

OneLake-turvallisuusoikeuksia ei voi määritellä suoraan OneLake-OneLake-pikapolvekkeellä. Pikakuvakkeen sisältävän kansion oikeudet yhdistyvät kohdepolun käyttöoikeuksiin. Jos kohdekohde tukee OneLake-tietoturvaa, käyttäjän täytyy saada pääsy OneLake-turvaroolin kautta. Jos kohdekohde ei tue OneLake-turvallisuutta, käyttäjä tarvitsee Fabric ReadAll -luvan kohdekohteeseen. Käyttäjä ei tarvitse Fabric Read -oikeutta kohdekohteeseen pelkästään päästäkseen käsiksi sen dataan pikakuvakkeen kautta.

OneLaken suojaus delegoiduissa pikakomennoissa

Delegoidut pikakuvakkeet käyttävät konfiguroitua yhteyshenkilöllisyyttä tai tunnistetta kutsuvan käyttäjän henkilöllisyyden sijaan päästäkseen kohteeseen. OneLaken turvallisuus rajoittaa, mitä soittava käyttäjä voi käyttää kyseisen yhteyden kautta.

Delegoidut OneLake-oikotiet

Delegoidussa OneLake-OneLake-pikakuvakkeessa kutsuva käyttäjä näkee oikotien käyttöoikeuden ja konfiguroidun yhteyshenkilöllisyyden pääsyn kohdepolulla risteyskohdan. Sarakkeen tason suojaus (CLS) on tuettu molemmilla poluilla. Rivitason turvallisuus (RLS) on tuettu kohdepolulla, mutta et voi määritellä RLS:ää pikapolulla.

Delegoidut ulkoiset pikanäppäimet

Pikakuvakkeet ulkoisiin järjestelmiin, kuten ADLS, Amazon S3 ja Dataverse, käyttävät konfiguroitua yhteystunnistetta päästäkseen ulkoiseen lähteeseen. OneLake-turvallisuus lisätään kyseisen tunnisteen myöntämän pääsyn päälle.

Esimerkiksi, oletetaan, että käyttäjä1 luo järvitalo-pikakuvakkeen kansioon Amazon S3:n ämpärissä, ja käyttäjä2 käyttää pikakuvaketta järvenrakennuksesta. User2 voi käyttää S3-dataa vain, jos konfiguroitu S3-yhteyden tunnistetiedot pääsevät lähteelle ja OneLake-turvallisuus valtuuttaa käyttäjä2:n pääsemään pikakuvakkeen polulle.

Voit myöntää OneLake-tietoturvalle pääsyn koko ulkoiseen pikakuvakkeeseen tai valittuihin alipolkuihin. Kansion oikeudet periytyvät rekursiivisesti kaikkiin sen alikansioihin, mukaan lukien pikakuvakkeen kansiot. Käyttäjän, joka pääsee ulkoiseen pikakuvakkeeseen toisen OneLake-pikakuvakkeen kautta, on silti oltava alkuperäisen ulkoisen pikakuvakkeen OneLake-turvajärjestelmän hyväksymä.

Ulkoisen pikakuvakkeen käyttäminen Sparkin kautta tai suoran OneLake-API-kutsun kautta vaatii myös Fabric Read -luvan sille kohteelle, joka sisältää ulkoisen pikakuvakkeen. Tämä lupa vaaditaan, jotta yhteys ulkoiseen järjestelmään voidaan turvallisesti ratkaista.

Arvioi useita OneLake-turvallisuusrooleja

Käyttäjä voi kuulua useisiin OneLake-turvallisuusrooleihin. OneLake yhdistää näiden roolien antamat pääsyt tehokkaaksi rooliksi, joka määrittää, mitä dataa käyttäjä voi käyttää. OneLake arvioi tehokasta roolia vaiheittain.

Ratkaise pääsy kussakin roolissa

OneLake ratkaisee ensin jokaisen roolin itsenäisesti. Roolissa käyttäjä voi käyttää vain kaikkia kolmea turvallisuuskomponenttia sallimiin tietoihin:

  • Oliotason turvallisuus (OLS) määrittää, mihin tauluihin tai kansioihin rooli pääsee käsiksi.
  • Rivitason turvallisuus (RLS) rajoittaa, mihin riveihin tietyssä taulukossa rooli pääsee käsiksi.
  • Saraketason turvallisuus (CLS) rajoittaa, mihin sarakkeisiin rooli voi käyttää tietyn taulukon sarakkeita.

Koska kaikki kolme osaa pätevät, OneLake ottaa risteyksensä. Esimerkiksi, jos Role1 myöntää pääsyn Table1:een ja rajoittaa sen rivejä ja sarakkeita, Role1:n ratkaistu käyttöoikeus on:

Role1 = R1_OLS ∩ R1_RLS ∩ R1_CLS

Leikkaussymboli (∩) tarkoittaa, että käyttäjä saa vain sen pääsyn, jonka OLS, RLS ja CLS sallivat kyseisessä roolissa.

Yhdistä pääsy eri rooleihin

Kun jokainen rooli on ratkaistu, OneLake yhdistää roolit liittomallin eli vähiten rajoittavan mallin avulla. Ammattiliiton symboli (∪) tarkoittaa, että minkä tahansa roolin myöntämä pääsy tulee osaksi tehokasta roolia. Jos Role1 myöntää pääsyn TableA:lle ja Role2 TableB:lle, käyttäjä, joka kuuluu molempiin rooleihin, voi käyttää molempia tauluja.

Kahdessa roolissa tehokas rooli on:

Effective role = Role1 ∪ Role2

Kun useat roolit antavat pääsyn samaan taulukkoon, rivitason turvallisuussäännöt yhdistyvät OR operaattorin kanssa. Esimerkiksi predikaatit, jotka sallivat city = 'Redmond' ja city = 'New York' yhdistävät .city = 'Redmond' OR city = 'New York'

Saraketason tietoturvasäännöt yhdistyvät myös unioniksi, paitsi SQL-analytiikan päätepisteessä. SQL-analytiikan päätepisteessä CLS käyttää tiukempaa kieltämissemantiikkaa. Jos jokin rooli piilottaa sarakkeen, päätepiste estää pääsyn kyseiseen sarakkeeseen. Tämän seurauksena päätepiste leikkaa CLS:n sallimislistat kaikkien käyttäjien roolien välillä sen sijaan, että ne yhdistettäisiin yhtenäiseksi.

Important

Pidä RLS- ja CLS-säännöt, jotka täytyy soveltaa yhdessä samassa roolissa. OneLake ei tue rooliyhdistelmää, jossa kaksi roolia sallivat erilaisen joukon sarakkeita taululle, ja kumpikin rooli soveltaa myös RLS:ää kyseiseen taulukkoon. Esimerkiksi käyttäjä ei voi kuulua Role1:een, joka sallii sarakkeet c1 ja c2 sekä osan riveistä, sekä Role2:een, joka sallii sarakkeet c2 ja c3.

Yhdistä pikakuvake ja kohdepääsy

Oikotiekkeen osalta OneLake arvioi roolit pikakuvakkeen sijainnissa ja pikakuvakkeen kohteessa erikseen. Kohderoolit muuttuvat oikotien sijainnissa pääteltyiksi . OneLake risteää sitten yhdistettyjen pääsyn oikotie-rooleista ja yhdistetyn pääsyn päätellyistä kohderooleista. Tämä vaihe estää pikakuvakkeen perityn pääsyn ohittamasta kohteen rajoituksia.

Kahdelle oikoteroolille ja kahdelle päätellylle kohderoolille tehokas pääsy on:

Effective shortcut access = (ShortcutRole1 ∪ ShortcutRole2) ∩ (InferredRole1 ∪ InferredRole2)

Tässä lausekkeessa ShortcutRole1 ja ShortcutRole2 ovat rooleja pikakuvakkeen sijainnissa. InferredRole1 ja InferredRole2 ovat vastaavat oikotien kohteesta päätellyt roolit. Jokainen rooli ratkaistaan sen OLS-, RLS- ja CLS-komponenteista ennen kuin OneLake yhdistää roolit.

OneLake-suojauksen rajoitukset

  • Jos määrität B2B-vieraskäyttäjälle OneLake-käyttöoikeusroolin, sinun on määritettävä ulkoisen yhteistyön asetukset B2B:lle Microsoft Entran ulkoisen tunnuksen. Aseta Vieraskäyttäjän käyttöoikeusasetukseksiVieraskäyttäjien käyttöoikeus on sama käyttöoikeus kuin jäsenillä (kaikkein mukaan lukien).

  • Jos lisäät jakelulistan OneLake-tietoturvan rooliin, SQL-analytiikan päätepiste ei pysty ratkaisemaan listan jäseniä pakottamaan pääsyä. Tämän seurauksena käyttäjät eivät näytä kuuluvan rooliin, kun he käyttävät SQL-analytiikkapäätepistettä. Direct Lake SQL-semanttisissa malleissa on myös tämän rajoituksen alainen.

  • Spark-muistikirjat vaativat ympäristön olevan vähintään 3.5 ja käyttämään Fabric Runtime 1.3:ta.

  • Ei-skeema-lakehouset eivät tue datan esikatselua RLS- ja CLS-suojatuille tauluille. Käytä skeemapohjaisia järvitaloja OneLake-turvalla.

  • OneLake-turvallisuus ei toimi Azuren dataresurssi- tai Purview Data Share-järjestelmien kanssa. Lisätietoja löytyy Azuren dataresurssi -sivusta.

  • Seuraava taulukko listaa OneLake-turvallisuusroolien rajoitukset.

    Scenario Limit
    OneLake-käyttöoikeusroolien enimmäismäärä Fabric-kohdetta kohden 250 roolia per tuote (ks. huomautus)
    Jäsenten enimmäismäärä OneLake-käyttöoikeusroolia kohden 500 käyttäjää tai käyttäjäryhmää roolia kohden
    Käyttöoikeuksien enimmäismäärä OneLake-käyttöoikeusroolia kohden 500 käyttöoikeutta roolia kohden

    Note

    Voit pyytää roolien määrän korotusta per esine 1 000:een. Jos haluat pyytää korotusta, ota yhteyttä Azure-tukeen.

Viiveet

Roolimääritysten käyttöön ottaminen kestää noin viisi minuuttia.

OneLake-käyttöoikeusroolin käyttäjäryhmän muutokset kestävät noin tunnin, ennen kuin OneLake ottaa roolin käyttöoikeudet käyttöön päivitetyssä käyttäjäryhmässä. Joillakin Fabric-moottoreilla on oma välimuistikerros, joten käyttöoikeuksien päivittäminen saattaa vaatia ylimääräisen tunnin kaikissa järjestelmissä.

Liittyvä sisältö

  • Last updated on