OneLake-biztonság SQL Analytics-végpontokhoz

A OneLake biztonságával Fabric bővíti, hogy a szervezetek hogyan kezelhetik és kényszeríthetik ki az adathozzáférést a számítási feladatok között. Ez a biztonsági keretrendszer nagyobb rugalmasságot biztosít a rendszergazdáknak az engedélyek konfigurálásához. A rendszergazdák a OneLake vagy az SQL Analytics-végponton belüli részletes SQL-alapú vezérlők segítségével választhatnak a központosított irányítás között.

Access módok az SQL Analytics-végpontban

A SQL-elemzési végpont használatakor a kiválasztott access mód határozza meg az adatbiztonság kényszerítési módját. A Fabric két különböző access modellt támogat, amelyek mindegyike a működési és megfelelőségi igényektől függően különböző előnyöket kínál:

  • Felhasználói identitás mód: A OneLake-szerepkörök és -szabályzatok használatával kényszeríti ki a biztonságot. Ebben a módban az SQL Analytics-végpont átadja a bejelentkezett felhasználó identitását a OneLake-nek, és az olvasási hozzáférést teljes egészében a OneLake-ben meghatározott biztonsági szabályok szabályozzák. A nem adatobjektumokra (nézetekre, tárolt eljárásokra, függvényekre) vonatkozó SQL-szintű engedélyek támogatottak, amelyek biztosítják a konzisztens szabályozást olyan eszközök között, mint a Power BI, a jegyzetfüzetek és a lakehouse.

  • Delegált identitás mód: Teljes körű vezérlést biztosít az SQL-en keresztül. Ebben a módban az SQL Analytics-végpont a munkaterület vagy az elemtulajdonos identitásával csatlakozik a OneLake-hez, a biztonságot pedig kizárólag az adatbázisban meghatározott SQL-engedélyek szabályozzák . Ez a modell támogatja a hagyományos biztonsági megközelítéseket, például a GRANT, a REVOKE, az egyéni szerepkörök, a Row-Level Biztonság és a Dinamikus adatmaszkolást.

Minden mód különböző szabályozási modelleket támogat. A következmények megértése elengedhetetlen a megfelelő megközelítés kiválasztásához a Fabric-környezetben.

Fontos

Az SQL Analytics-végpont használatához szükséges összetevő-hozzáférés. Ha sql analytics-végponton keresztül szeretne csatlakozni és adatokat lekérdezni, a felhasználóknak olvasási engedéllyel kell rendelkezniük a végponthoz társított összetevőre. Ha egy felhasználó nem rendelkezik vezérlősík-hozzáféréssel az összetevőhöz (például munkaterületi szerepkör-hozzáférés vagy explicit elemengedély), a rendszer elutasítja az SQL Analytics-végponthoz való kapcsolatot, függetlenül az adott felhasználóhoz esetleg létező SQL-engedélyektől.

Access módok összehasonlítása

Az alábbi táblázat összehasonlítja, hogyan és hol állítja be a biztonságot felhasználói identitás módban a delegált identitásmóddal szemben, objektumtípus és adathozzáférési szabályzatok szerint lebontva:

Biztonsági cél Felhasználói identitás mód Delegált identitás mód
Táblázatok A hozzáférést a OneLake biztonsági szerepkörei vezérlik. Az SQL GRANT/REVOKE nem engedélyezett. Teljes hozzáférés az SQL GRANT/REVOKEhasználatával.
Views Engedélyek hozzárendelése az SQL GRANT/REVOKE használatával. Engedélyek hozzárendelése az SQL GRANT/REVOKE használatával.
Tárolt eljárások Engedélyek hozzárendelése az SQL GRANT EXECUTE használatával. Engedélyek hozzárendelése az SQL GRANT EXECUTE használatával.
Funkciók Engedélyek hozzárendelése az SQL GRANT EXECUTE használatával. Engedélyek hozzárendelése az SQL GRANT EXECUTE használatával.
Row-Level Biztonság (RLS) A OneLake felhasználói felületén a OneLake biztonsági szerepkörök részeként definiálva. Sql CREATE SECURITY POLICYhasználatával definiálva.
Oszlopszintű biztonság (CLS) A OneLake felhasználói felületén a OneLake biztonsági szerepkörök részeként definiálva. SQL-lel definiálva, oszloplistával.
Dinamikus adatmaszkolás (DDM) Nincs támogatva a OneLake biztonsági rendszereiben. Az SQL ALTER TABLE opcióval definiálva MASKED.

Felhasználói identitás mód a OneLake biztonságában

Felhasználói identitás módban az SQL Analytics-végpont egy átengedéses hitelesítési mechanizmust használ az adatokhoz való hozzáférés kényszerítésére. Amikor egy felhasználó csatlakozik az SQL Analytics-végponthoz, az Entra-azonosítójuk át lesz adva a OneLake-nek, amely elvégzi az engedélyellenőrzést. A táblákon végzett összes olvasási művelet kiértékelése a OneLake Lakehouse-ben meghatározott biztonsági szabályok alapján történik, nem sql-szinten GRANT vagy REVOKE utasításokban.

Ezzel a móddal központilag felügyelheti a biztonságot, és konzisztens kényszerítéseket biztosít minden Fabric-szolgáltatásban, beleértve a Power BI-t, a notebookokat, a lakehouse-t és az SQL Analytics-végpontokat. Olyan szabályozási modellekhez készült, ahol a hozzáférést egyszer kell definiálni a OneLake-ben, és automatikusan érvényesüljön mindenhol.

Felhasználói identitás módban:

  • A hozzáférési táblázatot teljes egészében a OneLake biztonság szabályozza. A táblákON lévő SQL-utasítások GRANT/REVOKE figyelmen kívül lesznek hagyva.

  • Az RLS (Row-Level Security), a CLS (Column-Level Security) és a Object-Level Security mind a OneLake-élményben van definiálva.

  • Az SQL-engedélyek nem adatobjektumokhoz, például nézetekhez, tárolt eljárásokhoz és függvényekhez engedélyezettek, így rugalmasan definiálhatók az egyéni logika vagy a felhasználói belépési pontok az adatokhoz.

  • Az SQL Analytics-végpont nem támogatja az írási műveleteket. Minden írásnak a Fabric portál Lakehouse oldalán kell történnie, és a munkaterületi szerepkörök (Rendszergazda, Tag, Közreműködő) szabályozzák.

A felhasználó identitásmódjával rendelkező engedélymodellről további információt a OneLake biztonsági adathozzáférés-vezérlési modelljében talál.

Biztonsági szinkronizálás a OneLake és az SQL Analytics-végpont között

A felhasználói identitás mód kritikus összetevője a biztonsági szinkronizálási szolgáltatás. Ez a háttérszolgáltatás figyeli a OneLake biztonsági szerepköreinek módosításait, és gondoskodik arról, hogy ezek a módosítások megjelenjenek az SQL Analytics-végponton.

A biztonsági szinkronizálási szolgáltatás a következőkért felelős:

  • A OneLake-szerepkörök változásainak észlelése, beleértve az új szerepköröket, a frissítéseket, a felhasználói hozzárendeléseket és a táblák módosításait.

  • OneLake-definíciós szabályzatok (RLS, CLS, OLS) fordítása egyenértékű SQL-kompatibilis adatbázisszerepkör-struktúrákká.

  • A hivatkozási objektumok (más lakehouse-okból származó táblák) megfelelően ellenőrzésre kerülnek annak érdekében, hogy az eredeti OneLake biztonsági beállítások érvényesüljenek, még távoli hozzáférés esetén is.

Ez a szinkronizálás biztosítja, hogy a OneLake biztonsági definíciói mérvadóak maradjanak, így nincs szükség manuális SQL-szintű beavatkozásra a biztonsági viselkedés replikálásához. Mivel a biztonság központilag van kényszerítve:

  • Ebben a módban nem definiálhat RLS-t, CLS-t vagy OLS-t közvetlenül a T-SQL használatával.

  • Az SQL-engedélyeket továbbra is alkalmazhatja a nézetekre, függvényekre és tárolt eljárásokra a GRANT vagy EXECUTE utasítások használatával.

Biztonsági szinkronizálás újrapróbálkozási visszalépése

A biztonsági szinkronizálás tartalmaz egy újrapróbálkozási visszalépési mechanizmust a rendszer stabilitásának védelme és a szükségtelen számítási felhasználás elkerülése érdekében:

  • Ha a OneLake biztonsági szerepköreinek SQL Analytics-végpontra történő alkalmazása során ismétlődő hibák lépnek fel, a rendszer ideiglenesen szüneteltetheti az automatikus szinkronizálási kísérleteket.

  • A szinkronizálás automatikusan folytatódik egy meglévő OneLake biztonsági szerepkör módosításakor vagy egy új létrehozásakor.

Biztonsági szinkronizálási hibák és megoldás

Scenario Viselkedés felhasználói identitás módban Viselkedés delegált módban Helyesbítő intézkedés Jegyzetek
Az RLS-szabályzat törölt vagy átnevezett oszlopra hivatkozik Hiba: A sorszintű biztonsági szabályzat egy már nem létező oszlopra hivatkozik. Az adatbázis hibaállapotot ad meg a szabályzat kijavításáig. Hiba: Érvénytelen oszlopnév <oszlopnév> Frissítse vagy távolítsa el egy vagy több érintett szerepkört, vagy állítsa vissza a hiányzó oszlopot. A frissítést abban a tóházban kell végrehajtani, ahol a szerepkör létrejött.
A CLS-szabályzat törölt vagy átnevezett oszlopra hivatkozik Hiba: Az oszlopszintű biztonsági szabályzat egy már nem létező oszlopra hivatkozik. Az adatbázis hibaállapotot ad meg a szabályzat kijavításáig. Hiba: Érvénytelen oszlopnév <oszlopnév> Frissítse vagy távolítsa el egy vagy több érintett szerepkört, vagy állítsa vissza a hiányzó oszlopot. A frissítést abban a tóházban kell végrehajtani, ahol a szerepkör létrejött.
Az RLS/CLS-szabályzat törölt vagy átnevezett táblára hivatkozik Hiba: A biztonsági szabályzat egy már nem létező táblára hivatkozik. Nem jelenik meg hiba; a lekérdezés csendesen meghiúsul, ha a tábla hiányzik. Frissítse vagy távolítsa el egy vagy több érintett szerepkört, vagy állítsa vissza a hiányzó táblát. A frissítést abban a tóházban kell végrehajtani, ahol a szerepkör létrejött.
A DDM -házirend egy törölt vagy átnevezett oszlopra hivatkozik A DDM nem támogatott a OneLake-biztonságból; SQL-en keresztül kell implementálnia. Hiba: Érvénytelen oszlopnév <oszlopnév> Frissítse vagy távolítsa el egy vagy több érintett DDM-szabályt, vagy állítsa vissza a hiányzó oszlopot. Frissítse a DDM-szabályzatot az SQL Analytics-végponton.
Rendszerhiba (váratlan hiba) Hiba: Váratlan rendszerhiba történt. Próbálkozzon újra, vagy lépjen kapcsolatba az ügyfélszolgálattal. Hiba: Belső hiba történt a táblamódosítások SQL-ben való alkalmazása során. Próbálkozzon újra a művelettel; ha a probléma továbbra is fennáll, forduljon Microsoft ügyfélszolgálata. N/A
A felhasználói főazonosító nem támogatott Hiba: A felhasználónév nem támogatott. Hiba: A felhasználónév nem támogatott. Felhasználó {username} eltávolítása a szerepkörből DefaultReader. Ez a hiba akkor fordul elő, ha a felhasználó már nem érvényes Entra ID (például a felhasználó elhagyta a szervezetet, vagy törölték). Távolítsa el őket a szerepkörből a hiba megoldásához.

Billentyűparancsok viselkedése biztonsági szinkronizálással

A OneLake-biztonság a valódi adatforrásnál van érvényesítve, így a biztonsági szinkronizáció letiltja a táblák és a hivatkozásokat tartalmazó nézetek tulajdonjogok láncolását. Ez biztosítja, hogy a forrásrendszer engedélyeit mindig kiértékelje és betartsa, még egy másik adatbázisból származó lekérdezések esetén is.

Ennek eredménye:

  • A felhasználóknak érvényes hozzáféréssel kell rendelkezniük mind a kettőn a hivatkozásforrás (jelenlegi Lakehouse vagy SQL Analytics-végpont) és a rendeltetési hely, ahol az adatok fizikailag találhatók.

  • Ha a felhasználó egyik oldalon sem rendelkezik engedéllyel, a lekérdezések hozzáférési hibával hiúsulnak meg .

Ez a kialakítás megőrzi a biztonsági integritást a tóház határain át, miközben csökkenti a gyártó és fogyasztói termékek közötti identitáskiosztások duplikálásának szükségességét.

Delegált mód a OneLake biztonságában

Delegált identitás módban az SQL Analytics-végpont megőrzi a hagyományos SQL biztonsági modellel való visszamenőleges kompatibilitást. A biztonság az SQL-motorrétegen van definiálva és érvényesítve, a OneLake biztonsági szerepkörei és hozzáférési szabályzatai pedig nem kerülnek át a táblaszintű hozzáférésre. Minden szűrést és hozzáférés-vezérlést – beleértve a sémákhoz és táblákhoz való hozzáférést, a Row-Level Security (RLS), a Column-Level Security (CLS) és a dinamikus adatmaszkolást (DDM) – SQL-szerkezetekkel (GRANT/REVOKEbiztonsági szabályzatokkal stb.) kell definiálni.

Mivel a végfelhasználó oneLake biztonsági szerepkörei nincsenek közvetlenül kényszerítve, a OneLake-ben definiált biztonsági szabályok (például a Spark vagy más, a OneLake-en keresztül beolvasott motorok által kikényszerített szabályok) nem lesznek érvényesek, ha ugyanazokat az adatokat lekérdezik az SQL Analytics-végponton keresztül. Ezt a módot akkor válassza, ha a számítási feladat az SQL-natív biztonsági szemantikától függ, vagy ha a meglévő T-SQL-eszközök teljes kompatibilitást igényelnek.

Amikor egy felhasználó csatlakozik az SQL Analytics-végponthoz, és lekérdezést ad ki:

  • Az SQL ellenőrzi a lekérdezést az SQL-rétegben meghatározott engedélyek alapján.

  • Ha a lekérdezés engedélyezve van, a rendszer hozzáfér a OneLake-ben tárolt adatokhoz.

  • Ez az adathozzáférés a Lakehouse vagy az SQL Analytics végpont tulajdonosának azonosítójával történik, ami az elemfiók néven is ismert, nem pedig a bejelentkezett felhasználóval.

Ezért az elem tulajdonosa felelős azért, hogy elegendő engedélyekkel rendelkezik a OneLake-ben a mögöttes fájloknak a számítási feladat nevében való olvasásához. A végfelhasználóknak adott SQL-engedélyek és az elemtulajdonos OneLake-hozzáférése közötti esetleges eltérés lekérdezési hibákhoz vezet.

Ez a mód támogatja a dbA-k vagy alkalmazások által használt meglévő T-SQL-eszközöket és eljárásokat, és minden objektumszinten teljes kompatibilitást biztosít az SQL-hez GRANT/REVOKE , valamint az SQL által definiált RLS-hez, CLS-hez és DDM-hez.

Parancsikonok viselkedése delegált üzemmódban

Mivel a delegált mód az elemtulajdonos identitásával csatlakozik a OneLake-hez, a parancsikonok csak akkor működnek, ha a tulajdonos korlátlan hozzáféréssel rendelkezik a teljes forrástáblához. Ha a forrástábla oneLake szintű biztonsági szabályt alkalmaz (például Row-Level Security (RLS), Column-Level Security (CLS)), az SQL Analytics-végpont letiltja a parancsikonhoz való hozzáférést.

Ennek eredménye:

  • Az adatszintű biztonsági szabályok nélküli forrástáblákra mutató billentyűparancsok általában delegált módban működnek.

  • Az RLS-t vagy CLS-t tartalmazó forrástáblákra mutató parancsikonok a gyártó OneLake-biztonságában nem érhetők el delegált módban az SQL Analytics-végponton keresztül, még akkor sem, ha a végfelhasználó sql-engedélyekkel rendelkezik a parancsikonobjektumon.

  • Ha olyan parancsikonokat szeretne használni, amelyeknek a forrása OneLake biztonsági szabályzatokkal rendelkezik, használjon felhasználói identitás módot a fogyasztói végponton, hogy a végfelhasználó identitását a rendszer kiértékelje a forrás OneLake biztonsági szabályai alapján.

A OneLake access mód módosítása

A hozzáférési mód határozza meg az adathozzáférés hitelesítésének és érvényesítésének módját a OneLake SQL Analytics-végponton keresztüli lekérdezésekor. A felhasználói identitás mód és a delegált identitás mód között az alábbi lépések végrehajtásával válthat:

  1. Lépjen a Fabric-munkaterületre, és nyissa meg a lakehouse-t. A jobb felső sarokban váltson a lakehouse-ról az SQL Analytics-végpontra.

  2. A felső navigációs sávon lépjen a Biztonság lapra, és válassza ki a következő OneLake-hozzáférési módok egyikét:

    • Felhasználói identitás – A bejelentkezett felhasználó identitását használja. Érvényesíti a OneLake szerepköröket.

    • Delegált identitás – Az elem tulajdonosának identitását használja. Csak SQL-engedélyeket kényszerít ki.

  3. Megjelenik egy előugró ablak, amely megerősíti a kijelölést. A módosítás megerősítéséhez válassza az Igen lehetőséget.

Fontos

A biztonsági mód módosítása ideiglenesen elérhetetlenné teszi az SQL Analytics-végpontokat a teljes munkaterületen. Ez a művelet megszakítja az összes futó és várólistára helyezett lekérdezést a munkaterület összes SQL Analytics-végpontján. Az állásidő elkerülése érdekében csak szükség esetén és lehetőleg munkaidőn kívüli időszakokban módosítsa a módokat.

Szempontok a módok közötti váltáskor

Fontos

A felhasználói identitás és a delegált módok közötti váltás (mindkét irányban) jelenleg eltávolítja a beágyazott metaadat-objektumokat, beleértve a táblaértékű függvényeket (TVF-eket) és a skaláris értékű függvényeket. Ez a viselkedés csak a metaadat-definíciókat érinti; a OneLake-ben lévő mögöttes adatokra nincs hatással.

Váltás felhasználói identitás módra

  • Az SQL RLS, a CLS és a táblaszintű engedélyek figyelmen kívül lesznek hagyva.

  • A OneLake-szerepköröket úgy kell konfigurálni, hogy a felhasználók hozzáférést fenntartsanak.

  • Csak a Megtekintői jogosultságokkal vagy megosztott, csak olvasható hozzáféréssel rendelkező felhasználókra vonatkozik a OneLake biztonsága.

  • A meglévő SQL-szerepkörök törlődnek, és nem állíthatók helyre.

Váltás delegált identitás módra

  • A OneLake-szerepkörök és biztonsági szabályzatok már nem lesznek alkalmazva.

  • Az SQL-szerepkörök és a biztonsági szabályzatok aktívvá válnak.

  • Az elem tulajdonosának érvényes OneLake access kell rendelkeznie, vagy az összes lekérdezés sikertelen lehet.

Megjegyzések

  • Az SQL-objektumok nem öröklik a tulajdonjogot: A parancsikonok táblákként működnek az SQL Analytics-végponton, de szándékosan eltérnek a standard SQL-tulajdonjogi láncolástól az egységes biztonsági helyzet fenntartása érdekében.

    • Öröklés nélküli szabály: A származtatott SQL-objektumok (nézetek, tárolt eljárások vagy függvények) nem öröklik az engedélyeket az objektum tulajdonosától.

    • Futtatókörnyezet ellenőrzése: Az engedélyeket a rendszer ellenőrzi a hívó identitásán a végrehajtáskor, biztosítva, hogy az SQL-absztrakciók ne megkerüljék a OneLake-szintű szabályzatokat.

  • Vezérlősík-függőség és hatékony identitásértékelés: A felhasználóknak rendelkezniük kell a szükséges Fabric artefakt engedélyével, mielőtt csatlakozhatnának az SQL analitikai végponthoz. Az adatengedélyezés ezután értékeli a bejelentkezett felhasználót és a felhasználó hatékony tagságát a támogatott Microsoft Entra csoportokban a forrás OneLake biztonsági szabályzatai alapján.

  • Engedély-kiértékelési viselkedés: Az engedélyek kiértékelése az aktuális kényszerítési modelltől függően táblázattípusonként változik.

    • Gyorselérési táblák: A hozzáférés megtagadható, ha a szükséges jóváhagyási feltételek nem teljesülnek. Ez egy korlátozó érvényesítési eredmény, nem pedig egy szerepköralapú „DENY” képesség a OneLake biztonságában.

    • Általános szabály: Ha a kényszerítés nem tudja egyértelműen ellenőrizni a hozzáférést, a rendszer a legszigorúbb eredményt alkalmazza.

  • Oszlop-szintű biztonsági (CLS) kialakítás: A CLS szigorú engedélyezési listát tart fenn az oszlopok számára.

    • Az engedélyezett oszlopok átnevezése vagy eltávolítása érvényteleníti a biztonsági szabályt. Bár a szabály továbbra is megmarad a rendszerben, inaktív marad – megtagadva az erőforráshoz való hozzáférést –, amíg vissza nem állítja az eredeti oszlopelnevezést.

    • Szinkronizálási védelem: Ha egy szabályzat érvénytelen, a metaadatok szinkronizálását a rendszer mindaddig letiltja, amíg a szabályt ki nem javítják a OneLake biztonsági panelen.

    • Sémaérvényesítés: Az oszlopok biztonsági szabályzatok frissítése nélkül történő átnevezése felhasználói felületi hibákat vált ki, amelyek azt jelzik, hogy az oszlop "nem létezik" a konfiguráció szinkronizálásáig.

    Megjegyzés:

    Az SQL Analytics-végponton a OneLake-biztonság az adathozzáféréshez van kényszerítve, míg a séma metaadatai továbbra is az SQL-motor viselkedését követik. A felhasználók akkor is láthatják az oszlopokat az Object Explorerben vagy a sys.columns elemben, ha az oszlopszintű biztonság megakadályozza, hogy beolvassák ezeket az oszlopokat. Ez a viselkedés várható és szándékos.

  • Szerepkör propagálása és szinkronizálása (SLA):

    • OneLake biztonsági szinkronizálás: Ha egy OneLake biztonsági szerepkör megváltozik felhasználói identitás módban, a frissítés nem azonnal történik meg. Bár általában gyors, az SQL Analytics-végponttal való szinkronizálás akár 5 percet is igénybe vehet.

    • Automatikus előtagolás: A OneLake biztonsági szerepkörök propagálása az SQL Analytics-végpontra az OLS_ előtaggal együtt megtörténik.

    • Szinkronizálási prioritás: A biztonsági szinkronizálási folyamat rendszeresen frissíti a szerepkörök OLS_ állapotát. Ezeknek a szerepköröknek a manuális módosításai nem támogatottak, és a következő szinkronizálási ciklus során felülíródnak. Ha nincs módosítás a szinkronizálásban, a biztonsági szinkronizálás nem bírálja felül a manuális módosításokat.

Fontos

Amikor a OneLake-ben parancsikonokon keresztül hozzáfér egy adattárház adataihoz, ezek az SQL-biztonsági szemantikák nem képeződnek le a OneLake biztonsági szabályzataira. Ennek eredményeként azok a felhasználók, akik gyorsítványon keresztül érnek el az adatokat, láthatják a teljes raktári adatokat, függetlenül attól, hogy a gyártó raktárban konfigurált SQL biztonsági szabályzatokat alkalmazzák.

Korlátozások

  • Csak az olvasókra vonatkozik: A OneLake biztonsága elsősorban a Megtekintő szintű munkaterületen vagy elemhozzáférésen keresztül hozzáférő felhasználók számára van kényszerítve. Az olyan szélesebb munkaterületi szerepkörökkel rendelkező felhasználók, mint a rendszergazda, a tag vagy a közreműködő , emelt szintű hozzáférést tartanak fenn, és nem a OneLake biztonsági kikényszerítésének elsődleges célja.

    • Kivételek:

      • Parancsikon megtagadási viselkedése: A parancsikonalapú táblák esetében a kényszerítés bizonyos esetekben továbbra is megtagadhatja a hozzáférést a rendszergazdákhoz, tagokhoz vagy közreműködőkhöz.

      • Biztonsági szinkronizálási hibák esetei: Ha a biztonsági szinkronizálás bizonyos táblákra vagy szerepkörökre nem megfelelően alkalmazza a biztonságot, a rendszergazdai, tagi vagy közreműködői szerepkörök azon felhasználói is korlátozott hozzáférést tapasztalhatnak, akik az érintett szerepkörök tagjai.

      • RLS felhasználói identitás módban: Ha Row-Level biztonság (RLS) felhasználói identitás módban van konfigurálva, a megadott biztonsági szabályok minden felhasználóra vonatkoznak, beleértve a rendszergazdai, tagi és közreműködői szerepköröket is.

  • Séma láthatósága az objektum metaadataiban: Az SQL Analytics-végpont mindig visszaadja az objektum metaadatainak összes sémanevét , függetlenül a felhasználó táblaszintű engedélyétől. A rendszer kiszűri azokat a táblákat, amelyekhez a felhasználó nem rendelkezik engedéllyel, és nem jelennek meg a listából.

    • Ennek eredményeképpen a felhasználók olyan sémákat láthatnak, amelyek nem tartalmaznak látható táblákat az objektumkezelőben vagy a katalógus lekérdezéseiben INFORMATION_SCHEMA/sys .
  • Biztonsági szinkronizációs függőség: Felhasználói identitás módban a biztonsági szinkronizációs folyamat szinkronizálja a OneLake biztonsági szerepeket az SQL analitikai végponttal. Amíg a szinkronizáció befejeződik, az SQL ideiglenesen értékelheti a hozzáférést a meglévő SQL engedély állapotával minden táblához, beleértve más elemek gyorsbillentyűtábláit is. A szinkronizálás befejezése után az SQL-végpont a OneLake biztonsági konfigurációját tükrözi.

  • Tulajdonosi változások a parancsikonalapú táblákon: A parancsikonalapú táblák SQL-objektumokként jelennek meg az SQL Analytics-végponton, ezért támogatják a standard SQL-tulajdonosi műveleteket. Az olyan rendszergazdai parancsok, mint például ALTER AUTHORIZATION, megváltoztathatják egy parancsikon által támogatott tábla tulajdonosát. Bizonyos esetekben ez lehetővé teheti a tulajdonjogi láncolás viselkedését, amely áthalad a OneLake biztonsági szabályzatán, és nem szándékos hozzáférést biztosít az alapul szolgáló adatokhoz. A további kényszerítési mechanizmusok bevezetéséig a rendszergazdáknak el kell kerülniük a parancsikon-alapú táblák tulajdonjogának módosítását.

  • Célérvényesítés állásideje: Ha egy parancsikon-cél megváltozik (például átnevezés vagy URL-frissítés), az adatbázis rövid ideig egyfelhasználós üzemmódba lép, miközben a rendszer ellenőrzi az új célértéket. Ebben az időszakban a lekérdezések le lesznek tiltva. Ezek a műveletek általában gyorsak, de a belső folyamatoktól függően akár 5 percet is igénybe vehet a szinkronizálás.

    • A sémaparancsok létrehozása ismert hibát okozhat, amely hatással van az ellenőrzésre, és késlelteti a metaadatok szinkronizálását.
  • Delegált módú jogkivonat gyorsítótárazása: Delegált módban az SQL Analytics-végpont gyorsítótárazza azt a tárelérési jogkivonatot, amellyel adatokat kér le a OneLake-ből a tulajdonosi identitás nevében. Ha a tulajdonos engedélyei megváltoznak, a korábban kiadott jogkivonat érvényes maradhat, amíg lejár. Ennek eredményeképpen előfordulhat, hogy a tulajdonosi identitáshoz kapcsolódó hozzáférési változások nem lépnek érvénybe azonnal, és a jogkivonat lejáratáig, általában 30–60 percig is megmaradhatnak.

  • A OneLake biztonsági GRANT/DENY házirendjeinek módosításait a rendszer azonnal kikényszeríti, és a tárolási token gyorsítótárazása nem késlelteti.

  • Aktív lekérdezés-törlés: Az adatintegritás és a biztonság fenntartása érdekében előfordulhat, hogy az aktív lekérdezések automatikusan megszakadnak, ha egy parancsikon-konfiguráció megváltozik a végrehajtás során.

  • Sor szintű biztonsági (RLS-) korlátozások:

    • Csak egykifejezéses táblák támogatottak. A dinamikus RLS és a többtáblás RLS nem érhető el.

    • A szűrőkifejezésekben használt oszlop elvetése a metaadatok szinkronizálását leálltatja, amíg az RLS nincs javítva a OneLake biztonsági panelen.

  • Szerepkörök összetettsége és metaadatok szinkronizálása: A biztonsági szerepkörök nagy összetettsége – különösen a számos metszetet és az RLS-t használó egyesítő szemantikát is magában foglaló – biztonsági szinkronizálás meghiúsulását okozhatja. A sikertelen biztonsági szinkronizálás megakadályozza a biztonsági szabályzatok alkalmazását, és letiltja a metaadatok szinkronizálását.

  • Séma- és szerepkörkorlátozások:

    • Átnevezés: A OneLake biztonsági szerepkörök a tábla nevéhez vannak kötve. A táblák átnevezése megszakítja a társítást, és a szabályzatok nem migrálódnak automatikusan. Ez nem szándékos adatexpozíciót eredményezhet, amíg a szabályzatok újra nem lesznek alkalmazva.

    • Karakterkorlátok: A OneLake biztonsági szerepköreinek neve nem haladhatja meg a 124 karaktert; ellenkező esetben a szerepkör létrehozása vagy szinkronizálása meghiúsul az SQL Analytics-végponton.

    • OLS_ szerepkör-módosítások: A szerepkörök felhasználói OLS_ módosításai nem támogatottak, és váratlan viselkedést okozhatnak.

  • Nem támogatott identitások: A levelezésre képes biztonsági csoportok és terjesztési listák jelenleg nem támogatottak.

  • A Lakehouse tulajdonosi követelményei:

    • A tóház tulajdonosának a rendszergazdai, tagi vagy közreműködői munkaterületi szerepkörök tagjának kell lennie; ellenkező esetben a rendszer nem alkalmazza a biztonságot az SQL Analytics-végpontra.