Hogyan szabályozza a OneLake biztonsága az adathozzáférést

A OneLake biztonság egy szerepalapú rendszer, amely meghatározza, ki férhet hozzá az adatokhoz a OneLake-ben, és milyen lépéseket tehet azokkal az adatokkal. Az adathozzáférés-ellenőrzési modell megértése segít abban, hogy a felhasználóknak csak a szükséges hozzáférést biztosítsd, így védheted az érzékeny adatokat, miközben a megfelelő emberek dolgozhatnak velük.

Ez a cikk bemutatja, hogyan strukturálódnak a OneLake biztonsági szerepek, hogyan integrálódnak a munkaterületi és elemengedélyekhez, hogyan alkalmazza és oldja meg a OneLake az adataihoz való hozzáférést, valamint milyen korlátokat érdemes szem előtt tartani.

OneLake biztonsági szerepkörök

A OneLake biztonsága szerepalapú hozzáférés-vezérlési (RBAC) modellt használ az adatok elérésének kezelésére a OneLake-ben. A OneLake biztonsági tapasztalatában minden szerep a következő komponenseket tartalmazza:

  • Jogosultságok: A szerepkör által az adatokhoz biztosított jogosultságok, például az Olvasás vagy az Olvasás/Írás.
  • Típus: A szereptípus. A OneLake biztonsága csak a Grant szerepeket támogatja, amelyek hozzáférést biztosítanak a tagoknak a szerep adataihoz. Nem támogatja a „Deny” szerepköröket, amelyek megszüntetik a hozzáférést.
  • Adatok a szerepben: A tábla, mappák vagy sémák, amelyekhez a szerep hozzáférést biztosít. Táblázatokon sor- és oszlopszintű biztonsággal is definiálhatod az adathozzáférést.
  • Tagok szerepben: A szerephez hozzárendelt Microsoft Entra identitások, például felhasználók, csoportok vagy nem felhasználói identitások. Ha Microsoft Entra csoportot rendelsz hozzá, a OneLake biztonság a csoport minden tagjának adja át a szerepet.

A OneLake biztonsága alapértelmezés szerint elutasító modellt használ, így a felhasználók nem rendelkeznek hozzáféréssel az adatokhoz, hacsak egy OneLake biztonsági szerep kifejezetten hozzáférést nem ad. Néhány Fabric elem alapértelmezett szerepekkel indul, amelyek a felhasználóknak alapvető hozzáférést biztosítanak a munkaterületi jogosultságaik alapján.

Engedélyek és támogatott elemek

A OneLake biztonsági szerepkörei az alábbi jogosultságokat támogatják:

  • Olvas: Lehetővé teszi a felhasználó számára, hogy adatokat olvasson egy táblából, és megtekintse a kapcsolódó táblát és oszlop metaadatait. SQL szempontjából ez az engedély egyenértékű mind a VIEW_DEFINITION, mind a SELECT elemmel. További információért lásd: Metadata biztonság.
  • ReadWrite: Lehetővé teszi a felhasználó számára, hogy adatokat olvasson és írjon egy táblában vagy mappában, valamint megtekintse a hozzájuk tartozó tábla- és oszlopmetaadatokat. SQL szempontjából ez az engedély egyenértékű a következőkkel: ALTER, DROP, UPDATE és INSERT. További információért lásd: ReadWrite engedély.

OneLake biztonsági szerepköreket hozhatsz létre az alábbi Fabric elemekhez:

Textília cikk Támogatott engedélyek
Lakehouse Olvasás, OlvasásÍrás
Azure Databricks tükrözött katalógus Olvasás
Tükrözött adatbázisok Olvasás
Tükrözött katalógusok Olvasás

OlvasásÍrás engedély

A ReadWrite engedéllyel írási hozzáférést adhat a csak olvasási jogosultsággal rendelkező felhasználóknak egy elemen belüli adott adatokhoz.

A ReadWrite csak azokra a felhasználókra vonatkozik, akiknek egy tárgy olvasási joga van, például a Viewer munkaterület szerepével rendelkező felhasználókra. A ReadWrite hozzárendelése egy munkaterület Adminisztrátor, Tag vagy Közreműködő szerepköréhez nincs hatással, mert ezek a munkaterületi szerepkörök már eleve írási hozzáféréssel rendelkeznek.

A ReadWrite tartalmazza az olvasási engedély által biztosított összes jogosultságot, valamint írási hozzáférést ad a kiválasztott objektumhoz és annak tartalmához. Például egy mappára vonatkozó ReadWrite engedély írási hozzáférést biztosít mind a mappához, mind az abban található adatokhoz.

A ReadWrite jogosult felhasználók a következő műveleteket hajthatják végre:

  • Hozz létre, töröld vagy nevezz át egy mappát vagy táblát.
  • Tölts fel vagy szerkesszek egy fájlt.
  • Hozz létre, töröld vagy nevezd át egy gyorsítványt.

A felhasználók írási műveleteket végezhetnek Spark jegyzetfüzeteken, OneLake fájlkezelőn vagy OneLake API-kon. Mivel a Fabric az adatok írását csak egyetlen motorral támogatja, a ReadWrite jogosultsággal rendelkező felhasználók ezeket az adatokat csak a OneLake-en keresztül írhatják. Minden lekérdezési motor továbbra is következetesen kényszeríti az olvasási műveleteket.

A OneLake biztonsági szerepek, amelyek ReadWrite engedélyt adnak, nem tartalmazhatnak sorszintű biztonsági (RLS) vagy oszlopszintű biztonsági (CLS) korlátozásokat.

OneLake biztonsági és munkaterületi engedélyek

A munkaterületi szerepek jelentik az első biztonsági határt az adatokra a OneLake-ben. Ők kezelik a vezérlősíkot – létrehozzák és kezelik a Fabric elemeket és jogosultságokat –, és alkalmazzák a munkaterület összes elemére. Az egyes munkaterületi szerepek által adott konkrét OneLake-jogosultságokról lásd: Hozzáférés engedélyezése munkaterületi szerepekkel együtt. További információért a munkaterületi szerepekről lásd: Szerepek a munkaterületeken a Fabric-ben.

A vezérlősík hozzáférésén túl a munkaterületi szerepek hozzáférést biztosíthatnak az adatelemekhez a OneLake biztonsági alapértelmezett szerepeken keresztül. (Az alapértelmezett szerepek csak a Nézőkre vonatkoznak, mivel az Admin, Tag és Hozzájáruló szerepek magasabb hozzáféréssel rendelkeznek a Írás engedélyen keresztül.) Az alapértelmezett szerep egy normál OneLake biztonsági szerep, amelyet a Fabric automatikusan létrehoz minden új elemmel. A bizonyos munkaterület- vagy elemengedélyekkel rendelkező felhasználók számára alapértelmezett szintű hozzáférést biztosít az adott elem adataihoz. A lakehouse-elemek például DefaultReader szerepkörrel rendelkeznek, amely lehetővé teszi a ReadAll engedéllyel rendelkező felhasználók számára a tóházban lévő adatok megtekintését. Ez az alapértelmezett hozzáférés biztosítja, hogy az újonnan létrehozott elemmel dolgozó felhasználók alapvető hozzáférést kapjanak. Minden alapértelmezett szerep tag virtualizációs funkciót használ, így a szerep tagjai bármely olyan felhasználó legyen abban a munkatérben, akiknek a szükséges engedélyük van. Például az összes felhasználó rendelkezik ReadAll engedéllyel a lakehouse-on.

Az alábbi táblázat a szokásos alapértelmezett szerepeket mutatja. Az elemeknek lehetnek speciális alapértelmezett szerepek, amelyek csak az adott tárgytípusra vonatkoznak.

Textília cikk Szerepkör neve Engedély megadása Hozzárendelt tagok
Lakehouse DefaultReader Olvasás Minden felhasználó "ReadAll" engedéllyel
Azure Databricks tükrözött katalógus DefaultReader Olvasás Minden olvasási engedéllyel rendelkező felhasználó
Tükrözött katalógus DefaultReader Olvasás Minden olvasási engedéllyel rendelkező felhasználó
Tükrözött adatbázis DefaultReader Olvasás Minden felhasználó "ReadAll" engedéllyel

Módosíthatod vagy eltávolíthatod az alapértelmezett szerepet egy Fabric elemből, hogy megváltoztasd a hozzáférést a tagcsoport felhasználói számára.

Motor- és felhasználóhozzáférés az adatokhoz

A OneLake biztonsága alapértelmezett legkevésbé jogosult hozzáférést használ. Néhány tárolószintű művelet nem tudja érvényesíteni az RLS-t vagy a CLS-t, így ha egy lekérdezést nem lehet biztonságosan szűrni, a OneLake teljesen blokkolja, ahelyett, hogy kockáztatná, hogy olyan adatot tárjon fel, amit a felhasználó nem láthat. Az, hogy egy lekérdezést szűrnek vagy blokkolnak, az hozzáférési útvonaltól függ – támogatott lekérdezési motorról vagy közvetlen felhasználói hozzáférésről.

Az RLS- és CLS-szűrést támogató motorokról, valamint az egyes motorokra vonatkozó követelményekről lásd a következőt: OneLake biztonsággal védett adatok olvasása.

Hatókör és végrehajtás

Ez a szakasz részletesen bemutatja, hogy a OneLake biztonsági szerepkörök hogyan biztosítanak hozzáférést adott hatókörökhöz, hogyan működik a hozzáférés, és hogyan oldhatók fel a hozzáférés több szerepkör és hozzáférési típus között.

Táblaszintű biztonság

A OneLake minden táblát mappáként ábrázol, de a Fabric OneLake biztonsági és lekérdezési motorjai szempontjából nem minden mappa tábla. Ahhoz, hogy érvényes tábla legyen, egy mappának a következő feltételeknek kell megfelelnie:

  • A mappa egy Tables/ tárgy könyvtárában található. Olyan elemek esetén, amelyek támogatják a sémát, a mappának érvényes séma mappában kell lennie.
  • A mappa tartalmaz egy _delta_log mappát, amely tartalmazza a tábla metaadataihoz tartozó JSON fájlokat.
  • A mappában nincsenek gyermek gyorsítetek.

Ha az RLS-t vagy a CLS-t konfigurálod egy táblán, a OneLake megtagadja a hozzáférést, ha a tábla mappa nem felel meg ezeknek a kritériumoknak. RLS vagy CLS nélkül a OneLake olyan mappákat kezel, amelyek nem felelnek meg ezeknek a kritériumoknak, és mappászintű biztonságot alkalmaz.

Sorszintű és oszlopszintű biztonság

Egy szerepkörön belül korlátozhatod a hozzáférést egy táblázat konkrét soraihoz és oszlopaihoz sorszintű biztonsággal és oszlopszintű biztonsággal. További információkért arról, hogy mit csinál az egyes vezérlők, és hogyan érvényesíti a OneLake-et, lásd a OneLake táblázat-, oszlop- és sorszintű biztonságát. Amikor információt szeretne arról, hogy az RLS és a CLS hogyan érvényesül, ha egy felhasználó több szerepkörhöz tartozik, lásd: Több OneLake-biztonsági szerepkör kiértékelése.

Metaadatok biztonsága

A OneLake biztonsági olvasási engedélye teljes hozzáférést biztosít a táblák adataihoz és metaadataihoz. A táblákhoz hozzáféréssel nem rendelkező felhasználók számára az adatok soha nem lesznek közzétéve. Ez a szabály az oszlopszintű biztonságra és arra is, hogy a felhasználó képes legyen lássa vagy nem látni egy oszlopot abban a táblázatban. Azonban a OneLake biztonsága nem garantálja, hogy egy tábla metaadatai ne legyenek elérhetők. Bizonyos hibaüzenetek és esetek oszlopneveket jeleníthetnek meg.

Mappaengedély öröklése és átjárása

A mappák jogosultságai két irányban hatnak egy hierarchiára:

  • Öröklődés: A mappán megadott jogosultságok annak fájljaira és almappáira is érvényesek.
  • Bejárás és listázás: Ha a felhasználók rendelkeznek engedéllyel egy gyermekelemen, a OneLake biztonsági rendszere lehetővé teszi számukra, hogy listázzák és bejárják annak szülőmappáit, így megtalálhatják és eljuthatnak az általuk elérhető adatokhoz. A Traversal nem biztosít hozzáférést testvér fájlokhoz vagy mappákhoz.

Vegyük figyelembe a OneLake-ben található tóház következő hierarchiáját:

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

Létrehozol egy szerepet, Role1, amely olvasási engedélyt ad .subfolder11 Az öröklés útján a szerepkör tagjai olvashatják a file111.txt elemet és a subfolder111 alatti összes elemet. A tagok megtekinthetik és bejárhatják a(z) folder1 elemet, hogy elérjék a(z) subfolder11 elemet, de nem tekinthetik meg a(z) file11.txt elemet, mert az a(z) subfolder11 testvére, és nem tekinthetik meg a(z) Tables elemet, mert az a(z) Files testvére.

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

Létrehozol egy másik szerepet, Role2, amely olvasási engedélyt ad .folder2 Öröklés révén a tagok olvashatják file21.txt. A tagok bejárhatják a folder2-t és a Files-t, hogy elérjék azt, de a folder1-t vagy annak egyik gyermekét sem láthatják.

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

A rövidítéseknél a viselkedés kissé eltérő. A külső adatforrásokhoz vezető gyorsítványok ugyanúgy viselkednek, mint a mappák. Azonban a OneLake más helyszíneihez vezető rövidítések speciális viselkedéssel rendelkeznek. A parancsikon célengedélyei határozzák meg a OneLake-parancsikonhoz való hozzáférést. A parancsikonok listázásakor a OneLake nem indít hívást a célhoz való hozzáférés ellenőrzésére. Ennek eredményeként, amikor egy könyvtárat listelsz, a OneLake minden belső gyorsbillentyűt visszaad, függetlenül attól, hogy hozzáférsz a célhoz. A hozzáférési ellenőrzés akkor értékeli, amikor megpróbálod megnyitni a gyorsítványt, és akkor csak azokat az adatokat látod, amelyekhez a szükséges jogosultságaid vannak.

Gyorsbillentyűk

A OneLake biztonsága integrálódik a gyorsbillentyűkkel, hogy az adatokat a OneLake-en belül és kívül is biztonságossá tegyék. A gyorsítványok két hitelesítési mód egyikét használják:

  • Átpasszolás: A gyorsítvány a kérdező felhasználó személyazonosságát használja a célpont eléréséhez. A passthrough alapértelmezett a OneLake-to-OneLake rövidítéseknél.
  • Delegált: A gyorsítvány konfigurált kapcsolati identitást vagy jogosultságot használ a célpont eléréséhez. A OneLake-to-OneLake gyorsítványok használhatnak delegált hitelesítést, míg a külső rendszerekhez vezető rövidítetek mindig delegált hitelesítést használnak.

A parancsikon létrehozásához jogosultságok szükségesek mind azon az elérési úton, ahol a parancsikon létrejön, mind a cél elérési úton. Az egyes gyorsbillentyűtípusok létrehozásához és eléréséhez szükséges követelményekért lásd: OneLake gyorsítványbiztonság.

OneLake biztonság az átvitel útvonalainak használatakor

Amikor egy felhasználó egy átvezető OneLake–OneLake parancsikonon keresztül fér hozzá az adatokhoz, a OneLake a hívó felhasználó identitása alapján engedélyezi a hozzáférést a célútvonalhoz. A felhasználó hatékony hozzáférése korlátozott a gyorsút és a cél út engedélyeivel egyaránt.

Megjegyzés:

A lekérdezés-motor identitás és a gyorsítványhitelesítés külön beállítások. A passthrough gyorsítvány általában a hívó felhasználó identitását használja a cél eléréséhez. Azonban a Power BI szemantikai modellek, amelyek Direct Lake-et használnak SQL és SQL analitikai végpontokon delegált identitás módban, a fogyasztói termék vagy adatforrás tulajdonosi identitását használják. Ez a viselkedés nem változtatja meg a gyorsbillentyű konfigurált hitelesítési módját. A végponttól végpontig felhasználói identitás átadásához használd a Direct Lake-et OneLake-en keresztül, vagy konfiguráld az SQL analitikai végpontot a felhasználó identitás-hozzáférési módjára.

A OneLake–OneLake parancsikonon nem lehet közvetlenül OneLake-biztonsági engedélyeket meghatározni. A gyorsbillentyűt tartalmazó mappán lévő jogosultságok egyesülnek a célút jogosultságaival. Ha a célelem támogatja a OneLake-biztonságot, a felhasználónak hozzáféréssel kell rendelkeznie egy OneLake-biztonsági szerepkörön keresztül. Ha a célpont nem támogatja a OneLake biztonságot, a felhasználónak szüksége van a Fabric ReadAll engedélyre a céltárgyhoz. A felhasználónak nincs szüksége Fabric Read engedélyre a céltárgyhoz, kizárólag ahhoz, hogy a gyorsítványon keresztül hozzáférhessen az adataihoz.

OneLake-biztonság delegált gyorselérési útvonalakban

A delegált gyorsítékok konfigurált kapcsolati identitást vagy hitelesítő adatokat használnak a hívó felhasználó identitása helyett a célpont eléréséhez. A OneLake biztonsága korlátozza, hogy a hívó felhasználó mit érhet hozzá ezen a kapcsolaton keresztül.

Delegált OneLake-billentyűparancsok

Delegált OneLake–OneLake parancsikon esetén a hívást kezdeményező felhasználó a parancsikon elérési útján meglévő hozzáférése és a kapcsolathoz beállított identitás cél elérési útján meglévő hozzáférése közötti metszetnek megfelelő hozzáférést látja. Az oszlopszintű biztonság (CLS) mindkét elérési úton támogatott. A sorszintű biztonság (RLS) támogatott a célútvonalon, de az RLS nem határozható meg a parancsikon útvonalán.

Delegált külső rövidítések

A külső rendszerekhez vezető rövidítések, mint az ADLS, Amazon S3 és Dataverse, konfigurált csatlakozási igazolványt használnak a külső forráshoz való hozzáféréshez. Az OneLake-biztonság a hitelesítő adat által biztosított hozzáférésre épül rá.

Például, tegyük fel, hogy a user1 létrehoz egy tóház gyorsbillentyűt egy mappához egy Amazon S3 vödörben, és a user2 a lakehouse-ból éri el a gyorsbillentyűt. A User2 csak akkor férhet hozzá az S3-adatokhoz, ha a konfigurált S3-kapcsolat hitelesítő adata hozzáfér a forráshoz, és a OneLake biztonsági beállításai engedélyezik a User2 számára a parancsikon elérési útjának elérését.

Biztonsági hozzáférést biztosíthatsz a OneLake számára a teljes külső parancsikonhoz vagy a kijelölt részútvonalakhoz. A mappára vonatkozó jogosultságok rekurzívan öröklődnek az összes almappára, beleértve a parancsikonon belüli mappákat is. Az a felhasználó, aki egy másik OneLake-parancsikonon keresztül ér el egy külső parancsikont, továbbra is csak akkor férhet hozzá, ha rendelkezik az eredeti külső parancsikonra alkalmazott OneLake-biztonság szerinti jogosultsággal.

A Sparkon keresztül vagy közvetlen OneLake API híváson keresztül történő külső gyorsbillentyűhöz is szükség van Fabric Read engedélyre azon az elemen, amely tartalmazza a külső gyorsítványt. Ez az engedély szükséges a külső rendszerhez való csatlakozás biztonságos megoldásához.

Több OneLake biztonsági szerepkör értékelése

Egy felhasználó több OneLake biztonsági szerephez is tartozhat. A OneLake egyesíti az ezekhez a szerepekhez tartozó hozzáférést egy hatékony szerepké, amely meghatározza, hogy a felhasználó milyen adatokat érhet el. A OneLake fokozatosan értékeli a hatékony szerepet.

A hozzáférés feloldása az egyes szerepkörökön belül

A OneLake először az egyes szerepeket egymástól függetlenül oldja fel. Egy szerepkörön belül a felhasználó csak mindhárom biztonsági komponens által engedélyezett adatokhoz férhet hozzá:

  • Az objektumszintű biztonság (OLS) határozza meg, hogy a szerep mely táblákhoz vagy mappákhoz férhet hozzá.
  • A sorszintű biztonság (RLS) korlátozza, hogy egy adott tábla melyik sorához férhet hozzá a szerep.
  • Az oszlopszintű biztonság (CLS) korlátozza, hogy egy adott tábla melyik oszlopaihoz férhet hozzá a szerep.

Mivel mindhárom összetevő érvényes, a OneLake a kereszteződést foglalja el. Például, ha a Role1 hozzáférést ad az 1-es táblázathoz, és korlátozza annak sorait és oszlopait, akkor a Role1 feloldott hozzáférése a következő:

Role1 = R1_OLS ∩ R1_RLS ∩ R1_CLS

A metszésszimbólum (∩) azt jelenti, hogy a felhasználó csak az OLS, RLS és CLS által engedélyezett hozzáférést kapja ebben a szerepben.

A hozzáférés kombinálása különböző szerepkörökben

Minden szerep megoldása után a OneLake egyesíti a szerepeket egy szakszervezeti, vagy legkevésbé korlátozó modell segítségével. A szakszervezeti szimbólum (∪) azt jelenti, hogy bármely szerep által biztosított hozzáférés a tényleges szerep részévé válik. Ha a Role1 hozzáférést biztosít a TableA-hoz, a Role2 pedig hozzáférést biztosít a TableB-hez, akkor az a felhasználó, aki mindkét szerepkörhöz tartozik, mindkét táblához hozzáférhet.

Két szerep esetén az érvényes szerep:

Effective role = Role1 ∪ Role2

Ha több szerep is hozzáférést ad ugyanahhoz a táblához, a sorszintű biztonsági szabályok egy OR operátorral kombinálódnak. Például az olyan predikátumok, amelyek megengedik a city = 'Redmond' és a city = 'New York' elemet, city = 'Redmond' OR city = 'New York' formában kombinálódnak.

Az oszlopszintű biztonsági szabályok is egyesülnek, kivéve az SQL analitikai végpontot. Az SQL analitikai végpontban a CLS szigorúbb elutasító szemantikát alkalmaz. Ha bármely szerep elrejt egy oszlopot, a végpont blokkolja az adott oszlophoz való hozzáférést. Ennek eredményeként a végpont metszi a CLS engedélyezett listákat az összes felhasználó szerepében, ahelyett, hogy egyesítené őket.

Fontos

Tartsd meg az RLS és a CLS szabályait, amelyeknek együtt kell érvényesülniük ugyanabban a szerepben. A OneLake nem támogatja olyan szerepkombinációt, amelyben két szerep lehetővé teszi a táblázat különböző oszlophalmazát, és bármelyik szerep RLS-t is alkalmaz arra a táblára. Például egy felhasználó nem lehet a Role1-hez tartozni, amely lehetővé teszi a c1 és c2 oszlopokat, valamint a sorok egy részhalmazát, illetve a Role2-hez, amely lehetővé teszi a c2 és c3 oszlopokat.

Kombináld a rövidítést és a cél elérését

Rövidítés esetén a OneLake külön értékeli a szerepeket a rövidítés helyén és a gyorsút célpontján. A célszerepkörök a parancsikon helyén kikövetkeztetett szerepkörökké válnak. Ezután a OneLake a parancsikon-szerepkörökből származó egyesített hozzáférés és a kikövetkeztetett célszerepkörökből származó egyesített hozzáférés metszetét veszi. Ez a lépés megakadályozza, hogy a parancsikon helyén örökölt hozzáférési jogosultságok felülbírálják a célon érvényes korlátozásokat.

Két rövidítő szerep és két feltételezett célszerep esetén a hatékony hozzáférés a következő:

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

Ebben a kifejezésben ShortcutRole1 és ShortcutRole2 szerepek a rövidítés helyén. InferredRole1 és InferredRole2 a rövidítéscél megfelelő kikövetkeztetett szerepek. Minden szerep az OLS-, RLS- és CLS-összetevői alapján kerül feloldásra, mielőtt a OneLake egyesíti a szerepeket.

OneLake biztonsági korlátozások

  • Ha OneLake biztonsági szerepkört rendel egy B2B-vendégfelhasználóhoz, konfigurálnia kell a B2B külső együttműködési beállításait a Microsoft Entra Külső ID-ben. Állítsd a Vendég felhasználói hozzáférés beállítást erre: A vendég felhasználók ugyanazzal a hozzáféréssel rendelkeznek, mint a tagok (a leginkább befogadó).

  • Ha terjesztési listát ad hozzá egy szerepkörhöz a OneLake-biztonságban, az SQL Analytics-végpont nem tudja feloldani a lista tagjait a hozzáférés kényszerítése érdekében. Ennek eredményeként a felhasználók nem tűnnek a szerep tagjainak, amikor elérik az SQL analitikai végpontot. A Direct Lake az SQL szemantikai modelleken szintén alá van tartva ennek a korlátozásnak.

  • A Spark-notebookokhoz a környezetnek 3.5-ös vagy újabb verziójúnak kell lennie, és a Fabric runtime 1.3-at kell használnia.

  • A séma nélküli lakehouse-ok nem támogatják az adatok előnézetét az RLS- és CLS-védelemmel ellátott táblák esetében. Használjon sémakezelést támogató lakehouse-okat OneLake-biztonsággal.

  • Az OneLake biztonsága nem működik az Azure Data Share-szel vagy a Purview Data Share-szel. További információ: Azure Data Share.

  • Az alábbi táblázat a OneLake biztonsági szerepköreinek korlátait sorolja fel.

    Forgatókönyv Korlátozás
    A OneLake biztonsági szerepkörök maximális száma hálóelemenként 250 szerep tételenként (lásd megjegyzést)
    Tagok maximális száma OneLake biztonsági szerepkörenként Szerepkörenként 500 felhasználó vagy felhasználói csoport
    Az engedélyek maximális száma OneLake biztonsági szerepkörenként Szerepkörenként 500 hozzáférési jog

    Megjegyzés:

    Kérheti az elemenkénti szerepkörszám 1 000-re emelését. Az emelés kéréséhez forduljon a Azure ügyfélszolgálatához.

Késések

A szerepkör-definíciók módosításainak alkalmazása körülbelül 5 percet vesz igénybe.

A OneLake biztonsági szerepkör felhasználói csoportjának módosítása körülbelül egy órát vesz igénybe ahhoz, hogy a OneLake alkalmazza a szerepkör engedélyeit a frissített felhasználói csoportban. Egyes Fabric-motoroknak saját gyorsítótárazási rétegük van, ezért minden rendszer hozzáféréseinek frissítéséhez további egy órára lehet szükség.

Kapcsolódó tartalom

  • Last updated on