Megjegyzés
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhat bejelentkezni vagy módosítani a címtárat.
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhatja módosítani a címtárat.
A OneLake biztonság használatával az adminisztrátorok választhatnak a OneLake-en keresztüli központosított irányítás vagy az SQL analitikai végponton belüli részletes SQL-alapú vezérlé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: Biztonságot érvényesít OneLake szerepek és szabályzatok alkalmazásával. 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. Ez a mód támogatja az SQL szintű jogosultságokat nem adatobjektumokhoz, például nézetekhez, tárolt eljárásokhoz és függvényekhez, biztosítva a következetes irányítást olyan eszközök között, mint a Power BI, notebookok és 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 analitikai végpont a munkaterület vagy az elem tulajdonosának identitásával kapcsolódik a OneLake-hez, és a biztonságot kizárólag az adatbázisban definiált SQL jogosultságok szabályozzák. Ez a modell támogatja a hagyományos biztonsági megközelítéseket, beleértve a GRANT-t, REVOKE-t, egyedi szerepeket, sorszintű biztonságot és Dinamikus adatmaszkolást.
Minden mód különböző szabályozási modelleket támogat. Értsd meg ezek következményeit, hogy a Fabric környezetedhez megfelelő megközelítést válassz.
Fontos
Az SQL analitikai végpont használatához szükséges tárgy-hozzáférés. Az SQL analitikai végponthoz való csatlakozáshoz és lekérdezéshez a felhasználóknak olvasási engedélyt kell biztosítaniuk a végponthoz tartozó elemre. Ha egy felhasználónak nincs vezérlősík-hozzáférése az elemhez (például munkaterületi szerep-hozzáférés vagy explicit item engedély), az SQL analitikai végponthoz való csatlakozás elutasításra kerül, függetlenül attól, hogy létezhet-e az adott felhasználó számára SQL jogosultságok.
Hozzáférési 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 | OneLake biztonsági szerepek szabályozzák a hozzáférést. 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. |
| Sorszintű biztonság (RLS) | A OneLake biztonsági szerepköreinek részeként definiálva. | Sql CREATE SECURITY POLICYhasználatával definiálva. |
| Oszlopszintű biztonság (CLS) | A OneLake biztonsági szerepköreinek 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. |
Változtasd meg a OneLake hozzáférési módot
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. Az újonnan létrehozott SQL analitikai végpontok alapértelmezés szerint delegált identitás-hozzáférési módban indulnak. Mielőtt OneLake biztonságot használhatna egy végponttal, egy adminisztrátornak vagy tagnak át kell váltania a felhasználói identitás-hozzáférési módra.
Megjegyzés:
A OneLake biztonság használatához SQL analitikai végpontonként csak egyszer kell váltani a Felhasználó identitás-hozzáférési módjára . Azok a végpontok, amelyeket nem váltasz Felhasználói identitás-hozzáférési módra, továbbra is delegált identitást használnak a jogosultságok értékelésére.
Menj az SQL analitikai végponthoz.
Az SQL Analytics végponti felületén válassza a Biztonság lapot.
Válassza az Adatelérési mód>adatelérési mód beállításainak megtekintése lehetőséget.
Válassza ki a Felhasználó identitás-hozzáférési módját , hogy használja a bejelentkezett felhasználó identitását és érvényesítse a OneLake biztonsági szerepeket, vagy válassza az Delegált identitáshozzáférési módot , hogy az item tulajdonosának identitását használja és csak SQL jogosultságokat érvényesítsen. Ezután válassza a Alkalmaz lehetőséget.
Válassza a Folytatás lehetőséget a választás megerősítéséhez.
Fontos
A biztonsági mód megváltoztatása az SQL analitikai végpontokat ideiglenesen elérhetetlenné teszi az egész 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.
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/REVOKEfigyelmen kívül lesznek hagyva.A OneLake élmény az RLS-t (sorszintű biztonság), a CLS-t (oszlopszintű biztonságot) és az objektumszintű biztonságot határozza meg.
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.
Fontos
Egy-az-egyhez azonosság-leképezés a gyártó és a fogyasztó között (központ-küllő). Ha a OneLake biztonsági szabályzatait egy forráselemtől (a szerepkört definiáló forráselemtől) egy célelemhez (amely egy parancsikonon keresztül éri el az adatokat) viszik át, a OneLake biztonsági szerepkörökhöz rendelt identitásokat pontosan 1:1-re kell megfeleltetni a célelemen. Ugyanannak a felhasználónak vagy csoportnak kell Fabric Read engedéllyel rendelkeznie a felhasználói összetevőhöz, amelyre az előállító biztonsági szerepköre hivatkozik. A beágyazott vagy a tényleges csoporttagság nem oldódik fel ezen a határon.
Például, ha az előállító OneLake biztonsági szerepköre user123@microsoft.com-re hivatkozik, akkor user123@microsoft.com (a pontos objektumazonosító) Fabric Read engedéllyel is rendelkeznie kell a fogyasztói lakehouse-ban. Hasonlóképpen, ha az előállítói szerepkör Group A-ra hivatkozik, akkor magának a Group A-nek is meg kell kapnia a Fabric Read jogosultságot a felhasználón; ha ezt a jogosultságot csak a Group A egyik tagja kapja meg, az nem felel meg ennek a megfeleltetésnek.
További információért a felhasználói identitásmód jogosultsági modelljéről lásd: Hogyan irányítja a OneLake biztonsága az adathozzáférést.
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
GRANTvagyEXECUTEutasí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. Az SQL motor rétegén definiálod és érvényesíted a biztonságot, és a OneLake biztonsági szerepek és hozzáférési szabályzatok nem kerülnek át a táblázatszintű hozzáférésre. Minden szűrést és hozzáférés-vezérlést meg kell határoznod – beleértve a sémákhoz és táblákhoz való hozzáférést, sorszintű biztonságot (RLS), oszlopszintű biztonságot (CLS) és a dinamikus adatmaszkolást (DDM) – SQL konstrukciók (GRANT/REVOKE, biztonsági irányelvek stb.) használatával.
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 a tulajdonos identitásával csatlakozik OneLake-hez, a rövidítések csak akkor működnek, ha a tulajdonosnak korlátlan hozzáférése van az egész forrástáblához. Ha a forrástáblán van bármilyen OneLake-szintű biztonsági szabály alkalmazása – például sorszintű biztonság (RLS) vagy oszlopszintű biztonság (CLS) –, az SQL analitikai végpont blokkolja a hozzáférést ehhez a gyorsítványhoz.
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.
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.
Oszlopszintű biztonság (CLS) tervezés: A CLS szigorú engedélyezett oszloplistát tart fenn.
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 láthatják az oszlopokat az Object Explorer-ben, vagy
sys.columnsakár akkor is, ha az oszlopszintű biztonság miatt nem tudják olvasni azokat. 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.
Raktári SQL biztonság és rövidítések: A raktárban SQL konstrukciókkal definiált biztonsági irányelvek – mint például sorszintű biztonság (RLS), oszlopszintű biztonság (CLS) vagy objektumszintű biztonság (OLS) – csak a raktár SQL végrehajtási kontextusában (TDS végpont) érvényesülnek.
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: Amikor sorszintű biztonságot (RLS) konfigurálnak felhasználói identitás módban, a meghatározott biztonsági szabályokat minden felhasználó számára érvényesítik, beleértve az Admin, Tag és Hozzájáruló szerepeket 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.
- 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
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.
Sorszintű 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óiOLS_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.