Zabezpečení OneLake pro koncové body analýzy SQL

Díky využití OneLake Security si administrátoři mohou vybrat mezi centralizovanou správou přes OneLake nebo mezi detailní SQL kontrolou v SQL analytickém koncovém bodu.

Přístupové režimy v koncovém bodu SQL analýzy

Při použití koncového bodu analýzy SQL určuje vybraný režim access způsob vynucení zabezpečení dat. Síťová infrastruktura podporuje dva různé přístupové modely, z nichž každý nabízí různé výhody v závislosti na vašich provozních potřebách a potřebách dodržování předpisů.

• Režim identity uživatele: Zajišťuje bezpečnost pomocí rolí a politik OneLake. V tomto režimu koncový bod analýzy SQL předává identitu přihlášeného uživatele do OneLake a přístup pro čtení se řídí výhradně pravidly zabezpečení definovanými v rámci OneLake. Tento režim podporuje oprávnění na úrovni SQL na nedatových objektech, jako jsou pohledy, uložené procedury a funkce, což zajišťuje konzistentní správu napříč nástroji jako Power BI, notebooky a lakehouse.

• Delegovaný režim identity: Poskytuje úplnou kontrolu prostřednictvím SQL. V tomto režimu se SQL analytický endpoint připojuje k OneLake pomocí identity pracovního prostoru nebo vlastníka položky a bezpečnost je řízena výhradně SQL oprávněními definovanými v databázi. Tento model podporuje tradiční bezpečnostní přístupy, včetně GRANT, REVOKE, vlastních rolí, bezpečnosti na úrovni řádků a dynamického maskování dat.

Každý režim podporuje různé modely zásad správného řízení. Pochopte jejich dopady, abyste mohli zvolit správný přístup pro své Fabric prostředí.

Důležité

Pro použití koncového bodu analýz SQL je vyžadován přístup k této položce. Aby se uživatelé mohli připojit k datům a dotazovat je prostřednictvím koncového bodu pro analýzy SQL, musí mít u položky přidružené ke koncovému bodu oprávnění Číst. Pokud uživatel nemá přístup k danému bodu v řídicí rovině (například přístup k roli pracovního prostoru nebo explicitní oprávnění k položce), je spojení s SQL analytics endpointem zamítnuto, bez ohledu na jakákoli SQL oprávnění, která pro daného uživatele existují.

Porovnání režimů přístupu

Následující tabulka porovnává, jak a kde nastavíte zabezpečení v režimu identity uživatele a v režimu delegované identity rozdělené podle typu objektu a zásad přístupu k datům:

Cíl zabezpečení	Režim identity uživatele	Delegovaný režim identity
Tabulky	Bezpečnostní role OneLake kontrolují přístup. SQL GRANT/REVOKE není povolený.	Úplné řízení pomocí SQL GRANT/REVOKE.
zobrazení	K přiřazení oprávnění použijte SQL GRANT/REVOKE .	K přiřazení oprávnění použijte SQL GRANT/REVOKE .
Uložené procedury	K přiřazení oprávnění použijte SQL GRANT EXECUTE .	K přiřazení oprávnění použijte SQL GRANT EXECUTE .
Functions	K přiřazení oprávnění použijte SQL GRANT EXECUTE .	K přiřazení oprávnění použijte SQL GRANT EXECUTE .
Zabezpečení na úrovni řádků (RLS)	Definováno jako součást bezpečnostních rolí OneLake.	Definováno pomocí SQL CREATE SECURITY POLICY.
Bezpečnost na úrovni sloupců (CLS)	Definováno jako součást bezpečnostních rolí OneLake.	Definované pomocí SQL GRANT SELECT se seznamem sloupců
Dynamické maskování dat (DDM)	Zabezpečení OneLake toto nepodporuje.	Definované pomocí SQL ALTER TABLE s možností MASKED.

Změňte režim přístupu k OneLake

Režim přístupu určuje, jak se přístup k datům ověřuje a vynucuje při dotazování OneLake prostřednictvím koncového bodu analýzy SQL. Nově vytvořené SQL analytické endpointy začínají ve výchozím nastavení v režimu delegovaného přístupu k identitě. Než můžete používat OneLake Security s koncovým zařízením, musí administrátor nebo člen přepnout na režim přístupu k identitě uživatele.

Note

Pro použití OneLake Security stačí přepnout do režimu přístupu k identitě uživatele pouze jednou na SQL analytics endpoint. Koncové body, u kterých nepřepnete do režimu přístupu k identitě uživatele, nadále používají delegovanou identitu k vyhodnocení oprávnění.

1. Přejděte na SQL analytics endpoint.

2. V prostředí koncového bodu analýzy SQL vyberte kartu Zabezpečení .

3. Vyberte Zobrazitnastavení režimu přístupu k>datům.

   

4. Vyberte režim přístupu k identitě uživatele pro použití identity přihlášeného uživatele a vynucení bezpečnostních rolí OneLake, nebo zvolte režim Delegovaný přístup k identitě pro použití identity vlastníka položky a vynucení pouze SQL oprávnění. Pak vyberte Použít.

   

5. Výběrem možnosti Pokračovat potvrďte svoji volbu.

Důležité

Změna režimu zabezpečení způsobí, že koncové body SQL Analytics budou v celém pracovním prostoru dočasně nedostupné. Tato akce zruší všechny spuštěné a čekající dotazy na všech koncových bodech SQL analýzy v tomto pracovním prostoru. Režimy můžete měnit pouze v případě potřeby a nejlépe během mimopracovní doby, abyste se vyhnuli výpadkům.

Režim identity uživatele v zabezpečení OneLake

V režimu identity uživatele koncový bod analýzy SQL používá mechanismus průchozího ověřování k vynucení přístupu k datům. Když se uživatel připojí ke koncovému bodu analýzy SQL, předá se jeho identita ID Entra do OneLake, která provede kontrolu oprávnění. Všechny operace čtení s tabulkami jsou vyhodnocovány na základě bezpečnostních pravidel definovaných v rámci OneLake Lakehouse, nikoli pomocí jakýchkoli příkazů na úrovni SQL GRANT nebo REVOKE.

Tento režim umožňuje centrálně spravovat zabezpečení a zajistit konzistentní vynucování napříč všemi prostředími Fabric, včetně Power BI, notebooků, lakehouse a koncového bodu analýzy SQL. Je navržena pro modely řízení, kde má být přístup definován jednou v prostředí OneLake a automaticky dodržován všude.

V režimu identity uživatele:

• Přístup k tabulce se řídí výhradně zabezpečením OneLake. Příkazy SQL GRANT/REVOKE v tabulkách se ignorují.

• Zkušenost OneLake definuje RLS (bezpečnost na úrovni řádků), CLS (bezpečnost na úrovni sloupců) a bezpečnost na úrovni objektů.

• Oprávnění SQL jsou povolena pro objekty bez dat, jako jsou zobrazení, uložené procedury a funkce, což umožňuje flexibilitu při definování vlastních logiky nebo uživatelských vstupních bodů dat.

• Operace zápisu nejsou podporované v koncovém bodu analýzy SQL. Všechny zápisy musí probíhat prostřednictvím stránky Lakehouse na portálu Fabric a řídí se rolemi pracovního prostoru (správce, člen, přispěvatel).

Důležité

Mapování identit 1:1 napříč producentem a spotřebitelem (hub-and-spoke). Při přenosu zásad zabezpečení OneLake od producenta (zdrojová položka, ve které je role definovaná) příjemci (cílová položka, která přistupuje k datům prostřednictvím zástupce), musí být identity přiřazené rolím zabezpečení OneLake u producenta namapovány přesně 1:1 na příjemce. Stejný princip – ať už uživatel nebo skupina – musí mít povolení Fabric Read na uživatelském artefaktu jako ten, na který se odkazuje v bezpečnostní roli producenta. Vnořené nebo efektivní členství ve skupině není řešeno přes tuto hranici.

Například pokud role zabezpečení OneLake u producenta odkazuje na user123@microsoft.com, pak user123@microsoft.com (přesně tento ID objektu) musí mít také oprávnění ke čtení v rámci fabric na consumer lakehouse. Stejně tak, pokud role producenta odkazuje na Group A, pak samotnému Group A musí být u příjemce uděleno oprávnění Fabric Read — udělení tohoto oprávnění pouze členovi skupiny A ke splnění shody nepostačuje.

Pro více informací o modelu oprávnění v režimu identity uživatele viz Jak OneLake bezpečnost řídí přístup k datům.

Synchronizace zabezpečení mezi OneLake a SQL analytickým koncovým bodem

Důležitou součástí režimu identity uživatele je synchronizační služba zabezpečení. Tato služba na pozadí monitoruje změny rolí zabezpečení ve OneLake a zajišťuje, aby se tyto změny projevily v koncovém bodu analýzy SQL.

Služba synchronizace zabezpečení zodpovídá za následující:

• Detekce změn rolí OneLake, včetně nových rolí, aktualizací, přiřazení uživatelů a změn tabulek

• Překlad zásad definovaných onelakem (RLS, CLS, OLS) do ekvivalentních databázových struktur kompatibilních s SQL.

• Zajištění, že zástupcové objekty (tabulky pocházející z jiných lakehousů) jsou správně ověřeny tak, aby původní nastavení zabezpečení OneLake byla zachována i při vzdáleném přístupu.

Tato synchronizace zajišťuje, aby definice zabezpečení OneLake zůstaly autoritativní a eliminují potřebu ručního zásahu na úrovni SQL k replikaci chování zabezpečení. Protože se zabezpečení centrálně vynucuje:

• V tomto režimu nemůžete definovat RLS, CLS ani OLS přímo pomocí T-SQL.

• Stále můžete použít oprávnění SQL k zobrazením, funkcím a uloženým procedurám pomocí GRANT příkazů nebo EXECUTE příkazů.

Opakování opakování synchronizace zabezpečení

Synchronizace zabezpečení zahrnuje mechanismus opakování pro ochranu stability systému a zabránění zbytečné spotřebě výpočetních prostředků:

• Pokud při použití rolí zabezpečení OneLake na koncový bod analýzy SQL dojde k opakovaným chybám, může systém dočasně pozastavit pokusy o automatickou synchronizaci.

• Synchronizace se obnoví automaticky, když se změní existující role zabezpečení OneLake nebo se vytvoří nová role.

Chyby synchronizace zabezpečení a jejich řešení

Scenario	Chování v režimu identity uživatele	Chování v delegovaném režimu	Nápravná akce	Poznámky
RLS zásady odkazují na odstraněný nebo přejmenovaný sloupec	Chyba: Zásady zabezpečení na úrovni řádků odkazují na sloupec, který již neexistuje. Databáze přechází do chybového stavu, dokud se zásada nenapraví.	Chyba: Neplatný název <>sloupce	Aktualizujte nebo odeberte jednu nebo více ovlivněných rolí nebo obnovte chybějící sloupec.	Aktualizace musí být provedena v jezeře, ve které byla role vytvořena.
Zásady CLS odkazují na odstraněný nebo přejmenovaný sloupec	Chyba: Zásady zabezpečení na úrovni sloupců odkazují na sloupec, který již neexistuje. Databáze zadá stav chyby, dokud se zásada nepraví.	Chyba: Neplatný název <>sloupce	Aktualizujte nebo odeberte jednu nebo více ovlivněných rolí nebo obnovte chybějící sloupec.	Aktualizace musí být provedena v jezeře, ve které byla role vytvořena.
Zásady RLS/CLS odkazují na odstraněnou nebo přejmenovanou tabulku	Chyba: Zásady zabezpečení odkazují na tabulku, která již neexistuje.	Nedošlo k žádné chybě; dotaz selže bezobslužně, pokud chybí tabulka.	Aktualizujte nebo odeberte jednu nebo více ovlivněných rolí nebo obnovte chybějící tabulku.	Aktualizace musí být provedena v jezeře, ve které byla role vytvořena.
Zásady DDM (dynamické maskování dat) odkazují na odstraněný nebo přejmenovaný sloupec.	DDM se nepodporuje ze zabezpečení OneLake; musí být implementováno prostřednictvím SQL.	Chyba: Neplatný název <>sloupce	Aktualizujte nebo odeberte jedno nebo více ovlivněných pravidel DDM nebo obnovte chybějící sloupec.	Aktualizujte zásady DDM v koncovém bodu analýzy SQL.
Systémová chyba (neočekávané selhání)	Chyba: Došlo k neočekávané systémové chybě. Zkuste to znovu nebo se obraťte na podporu.	Chyba: Při použití změn tabulky v SQL došlo k vnitřní chybě.	Zkuste operaci zopakovat; pokud problém přetrvává, obraťte se na podpora Microsoftu.	N/A
Hlavní uživatelský subjekt není podporován	Chyba: Uživatelský principal není podporován.	Chyba: Uživatelský principal není podporován.	Odebrat uživatele {username} z role DefaultReader.	K této chybě dochází v případě, že uživatel již není platný Entra ID (například uživatel opustil organizaci nebo byl odstraněn). Pokud chcete chybu vyřešit, odeberte je z role.

Chování klávesových zkratek při synchronizaci zabezpečení

Zabezpečení OneLake se vynucuje ve zdroji dat, takže synchronizace zabezpečení zakáže řetězení vlastnictví pro tabulky a zobrazení zahrnující zkratky. Tím zajistíte, že se budou vždy vyhodnocovat a respektovat oprávnění zdrojového systému, a to i pro dotazy z jiné databáze.

Výsledek:

• Uživatelé musí mít platný přístup k oběma zástupcům zdroje (aktuálního Lakehouse nebo koncového bodu analýzy SQL) acíli, kde se data fyzicky nacházejí.

• Pokud uživatel nemá oprávnění na obou stranách, dotazy selžou s chybou přístupu.

Tento návrh zachovává bezpečnostní integritu napříč hranicemi lakehouse a zároveň snižuje potřebu duplicitně přiřazovat identity napříč položkami producenta a konzumenta.

Delegovaný režim v zabezpečení OneLake

V režimu delegovaných identit zachová koncový bod analýzy SQL zpětnou kompatibilitu s tradičním modelem zabezpečení SQL. Na vrstvě SQL engine definujete a vynucujete bezpečnost a bezpečnostní role a přístupové politiky OneLake se nepřenášejí na přístup na úrovni tabulky. Musíte definovat veškeré filtrování a řízení přístupu – včetně přístupu ke schématům a tabulkám, bezpečnosti na úrovni řádků (RLS), bezpečnosti na úrovni sloupců (CLS) a dynamického maskování dat (DDM) – pomocí SQL konstrukcí (GRANT/REVOKE, bezpečnostní politiky a podobně).

Vzhledem k tomu, že role zabezpečení OneLake pro koncového uživatele nejsou přímo vynucovány, nebudou platit žádná pravidla zabezpečení definovaná ve OneLake (například pravidla vynucená Sparkem nebo jinými moduly, které čtou OneLake) při dotazování stejných dat prostřednictvím koncového bodu analýzy SQL. Tento režim zvolte, když úloha závisí na sémantice zabezpečení nativní pro SQL nebo v případě, že stávající nástroje T-SQL vyžadují úplnou kompatibilitu.

Když se uživatel připojí ke koncovému bodu analýzy SQL a vydá dotaz:

• SQL ověří dotaz na oprávnění definovaná ve vrstvě SQL.

• Pokud je dotaz autorizován, systém pokračuje v přístupu k datům uloženým v OneLake.

• Tento přístup k datům se provádí pomocí identity vlastníka koncového bodu Lakehouse nebo SQL Analytics, označovaného také jako účet položky , nikoli přihlášeného uživatele.

Vlastník položky je proto zodpovědný za to, že má ve OneLake dostatečná oprávnění ke čtení podkladových souborů jménem úlohy. Jakékoli nesprávné zarovnání mezi oprávněními SQL udělenými koncovým uživatelům a přístupem vlastníka položky OneLake způsobí selhání dotazů.

Tento režim podporuje stávající nástroje a postupy T-SQL používané DBA nebo aplikacemi s plnou kompatibilitou pro SQL GRANT/REVOKE na všech úrovních objektů a SQL-definované RLS, CLS a DDM.

Chování klávesových zkratek v delegovaném režimu

Protože režim delegovaného režimu se připojuje k OneLake pomocí identity vlastníka položky, zkratky fungují pouze tehdy, když má vlastník neomezený přístup k celé zdrojové tabulce. Pokud je na zdrojové tabulce aplikováno nějaké bezpečnostní pravidlo na úrovni OneLake – například bezpečnost na úrovni řádku (RLS) nebo bezpečnost na úrovni sloupců (CLS) – koncový bod SQL analytics blokuje přístup k této zkratce.

Výsledek:

• Klávesové zkratky odkazující na zdrojové tabulky bez pravidel zabezpečení na úrovni dat fungují normálně v delegovaném režimu.

• Klávesové zkratky odkazující na zdrojové tabulky se zabezpečením RLS nebo CLS v zabezpečení OneLake na producentovi nejsou přístupné prostřednictvím koncového bodu analýzy SQL v delegovaném režimu, i když má koncový uživatel oprávnění SQL k objektu zástupce.

• Pokud chcete využívat klávesové zkratky, jejichž zdroj má zásady zabezpečení OneLake, použijte v koncovém bodu příjemce režim identity uživatele , aby se identita koncového uživatele vyhodnotila proti pravidlům zabezpečení OneLake zdroje.

Důležité informace o přepínání mezi režimy

Důležité

Přepínání mezi identitou uživatele a delegovanými režimy (v obou směrech) v současné době odebere vložené objekty metadat, včetně funkcí s hodnotami tabulek (TVF) a skalárních funkcí. Toto chování ovlivňuje pouze definice metadat; podkladová data ve OneLake nejsou ovlivněna.

Přepnutí do režimu identity uživatele

• Oprávnění SQL RLS, CLS a na úrovni tabulek se ignorují.

• Role OneLake musí být nakonfigurované tak, aby uživatelé udržovali access.

• Zabezpečení OneLake řídí pouze uživatele s oprávněními prohlížeče nebo sdíleným přístupem jen pro čtení.

• Existující role SQL se odstraní a nejde je obnovit.

Přepnutí do režimu delegovaných identit

• Role a zásady zabezpečení OneLake se už nepoužívají.

• Role SQL a zásady zabezpečení se stanou aktivními.

• Vlastník položky musí mít platný access OneLake nebo všechny dotazy můžou selhat.

Poznámky

• Objekty SQL nedědí vlastnictví: Klávesové zkratky fungují jako tabulky v koncovém bodu analýzy SQL, ale záměrně se odchylují od standardního řetězení vlastnictví SQL, aby zachovaly jednotný stav zabezpečení.

  • Pravidlo bez dědičnosti: Odvozené objekty SQL (zobrazení, uložené procedury nebo funkce) nedědí oprávnění od vlastníka objektu.

  • Validace za běhu: Oprávnění se ověřují ve vztahu k identitě volajícího v době provádění, což zajišťuje, že abstrakce SQL nemohou obejít zásady na úrovni OneLake.

• Závislost na řídicí vrstvě a vyhodnocování efektivní identity: Uživatelé musí mít požadované oprávnění k artefaktu Fabric, než se budou moct připojit ke koncovému bodu SQL Analytics. Autorizace dat pak hodnotí přihlášeného uživatele a jeho efektivní členství v podporovaných skupinách Microsoft Entra vůči bezpečnostním politikám OneLake ve zdroji.

• Chování vyhodnocení oprávnění: Vyhodnocení oprávnění se liší podle typu tabulky s ohledem na současný model vynucování.

  • Tabulky zkratek: Přístup může být odepřen, pokud nejsou splněny požadované podmínky autorizace. Jedná se o omezující výsledek vynucení, nikoli schopnost odepření na základě role v zabezpečení OneLake.

  • Obecné pravidlo: Pokud vynucení nemůže jasně ověřit přístup, systém použije nejvíce omezující výsledek.

• Návrh bezpečnosti na úrovni sloupců (CLS): CLS udržuje přísný seznam povolených sloupců.

  • Přejmenování nebo odebrání povoleného sloupce zneplatní pravidlo zabezpečení. I když pravidlo přetrvává v systému, zůstane neaktivní – odepře veškerý přístup k prostředku – dokud se neobnoví pojmenování původního sloupce.

  • Ochrana synchronizace: Pokud je zásada neplatná, synchronizace metadat se záměrně zablokuje, dokud se pravidlo nenapraví na panelu zabezpečení OneLake.

  • Ověřování schématu: Přejmenování sloupců bez aktualizace zásad zabezpečení aktivuje chyby uživatelského rozhraní, které uvádějí, že sloupec neexistuje, dokud se konfigurace nesynchronizuje.

  Note

  V koncovém bodu analýzy SQL se pro přístup k datům vynucuje zabezpečení OneLake, zatímco metadata schématu nadále sledují chování modulu SQL. Uživatelé mohou vidět sloupce v Průzkumník objektů nebo sys.columns dokonce tehdy, když jim zabezpečení na úrovni sloupců brání tyto sloupce číst. Toto chování je očekávané a podle návrhu.

• Šíření a synchronizace rolí (SLA):

  • Synchronizace zabezpečení OneLake: Když se role zabezpečení OneLake změní v režimu identity uživatele, aktualizace není okamžitá. I když je obvykle rychlý, synchronizace s koncovým bodem analýzy SQL může trvat až 5 minut .

  • Automatické předpony: Role zabezpečení OneLake se rozšíří do koncového bodu analýzy SQL s předponou OLS_ .

  • Priorita synchronizace: Proces synchronizace zabezpečení pravidelně aktualizuje stav OLS_ rolí. Ruční změny těchto rolí nejsou podporovány a během dalšího cyklu synchronizace se přepíší. Pokud synchronizace neobsahuje žádné změny, synchronizace zabezpečení nepřepíše ruční změny.

• Bezpečnost SQL skladu a zkratky: Bezpečnostní politiky definované pomocí SQL konstrukcí ve skladu – například bezpečnost na úrovni řádků (RLS), bezpečnost na úrovni sloupců (CLS) nebo bezpečnost na úrovni objektů (OLS) – jsou vynucovány pouze v kontextu SQL vykonávání skladu (TDS endpoint).

Důležité

Když přistupujete k datům ze skladu pomocí zkratek v OneLake, tyto SQL bezpečnostní sémantiky nejsou převedeny do bezpečnostních politik OneLake. Díky tomu mohou uživatelé přistupující k datům pomocí zkratky vidět kompletní data skladu, bez ohledu na SQL bezpečnostní politiky nakonfigurované ve skladu producenta.

Omezení

• Platí jenom pro čtenáře: Zabezpečení OneLake se primárně vynucuje pro uživatele, kteří přistupují k datům prostřednictvím přístupu k pracovnímu prostoru nebo položce na úrovni prohlížeče. Uživatelé s širšími rolemi pracovního prostoru, jako je správce, člen nebo přispěvatel , si zachovají zvýšený přístup a nejsou primárním cílem vynucování zabezpečení OneLake.

  • Výjimky:

    • Chování při odepření zkratek: U tabulek založených na zkratkách může vynucení v určitých případech odepřít přístup správcům, členům nebo přispěvatelům.

    • Případy selhání synchronizace zabezpečení: Pokud se synchronizaci zabezpečení nepodaří správně použít zabezpečení u určitých tabulek nebo rolí, můžou mít uživatelé v rolích správce, člena nebo přispěvatele, kteří jsou členy těchto ovlivněných rolí, také omezený přístup.

    • RLS v režimu uživatelské identity: Když je v režimu uživatelské identity (RLS) nakonfigurována bezpečnost na úrovni řádku, jsou definována bezpečnostní pravidla vynucována pro všechny uživatele, včetně těch v rolích administrátora, člena a přispěvatele.

• Viditelnost schématu v metadatech objektu: Koncový bod sql Analytics vždy vrací všechny názvy schémat v metadatech objektu bez ohledu na oprávnění uživatele na úrovni tabulky. Tabulky, pro které uživatel nemá žádné oprávnění, se odfiltrují a nezobrazují se ve výpisu.

  • V důsledku toho se uživatelům mohou zobrazit schémata, která neobsahují žádné viditelné tabulky v Průzkumníku objektů nebo v dotazech katalogu INFORMATION_SCHEMA/sys .

• Závislost synchronizace zabezpečení: V režimu identity uživatele proces synchronizace zabezpečení synchronizuje role zabezpečení OneLake do koncového bodu analýzy SQL. Dokud synchronizace nebude dokončena, může SQL dočasně vyhodnocovat přístup použitím stávajícího SQL oprávnění pro všechny tabulky, včetně tabulk zkratek z jiných položek. Po dokončení synchronizace koncový bod SQL odráží konfiguraci zabezpečení OneLake.

• Změny vlastnictví u tabulek se zástupci: Tabulky se zástupci jsou reprezentovány jako SQL objekty na analytickém koncovém bodu SQL, proto podporují standardní operace vlastnictví SQL. Příkazy pro správu, například ALTER AUTHORIZATION, mohou změnit vlastníka tabulky založené na zástupci. V některých scénářích může toto umožnit chování řetězení vlastnictví, které obchází zásady zabezpečení OneLake a uděluje nezamýšlený přístup k podkladovým datům. Dokud nebudou zavedeny další mechanismy vynucení, správci by se měli vyhnout úpravám vlastnictví u místních tabulek.

• Výpadek ověření cíle: Když se změní cíl zástupce (například přejmenování nebo aktualizace adresy URL), databáze krátce přejde do režimu jednoho uživatele , zatímco systém ověří nový cíl. Během tohoto období se dotazy zablokují. Tyto operace jsou obvykle rychlé, ale synchronizace může v závislosti na interních procesech trvat až 5 minut.

  • Vytváření zástupců schématu může způsobit známou chybu, která ovlivňuje ověřování a způsobuje zpoždění synchronizace metadat.

• Ukládání tokenů delegovaného režimu do mezipaměti: V delegovaném režimu ukládá koncový bod SQL Analytics do mezipaměti přístupový token úložiště použitý k načtení dat z OneLake jménem identity vlastníka. Pokud se změní oprávnění vlastníka, může dříve vydaný token zůstat platný, dokud nevyprší jeho platnost. V důsledku toho se změny přístupu spojené s identitou vlastníka nemusí projevit okamžitě a mohou se zachovat až do vypršení platnosti tokenu, obvykle až 30–60 minut.

• Změny zásad GRANT/DENY zabezpečení OneLake se vynucují okamžitě a nejsou zpožděné ukládáním tokenů úložiště do mezipaměti.

• Zrušení aktivního dotazu: Chcete-li zachovat integritu a zabezpečení dat, mohou být aktivní dotazy automaticky zrušeny, pokud se během provádění změní konfigurace zástupce.

• Omezení zabezpečení na úrovni řádků (RLS):

  • Podporují se pouze tabulky s jedním výrazem. Dynamické RLS a RLS pro více tabulek nejsou k dispozici.

  • Vyřazení sloupce použitého ve výrazu filtru zastaví synchronizaci metadat, dokud nebude na panelu zabezpečení OneLake opraveno zabezpečení na úrovni řádků (RLS).

• Složitost rolí a synchronizace metadat: Vysoká složitost v bezpečnostních rolích, konkrétně těch, které zahrnují řadu průniků a sémantiky sjednocení pomocí RLS (Řízení na úrovni řádků), mohou způsobit selhání synchronizace zabezpečení. Neúspěšná synchronizace zabezpečení zabraňuje použití zásad zabezpečení a blokuje možnost synchronizace metadat.

• Omezení schématu a rolí:

  • Přejmenování: Role zabezpečení OneLake jsou svázané s názvem tabulky. Přejmenování tabulky přeruší propojení a zásady se nemigrují automaticky. To může vést k neúmyslnému vystavení dat, dokud se zásady znovu neaplikují.

  • Omezení znaků: Názvy rolí zabezpečení OneLake nesmí překročit 124 znaků; v opačném případě se vytvoření nebo synchronizace role v koncovém bodu analýzy SQL nezdaří.

  • OLS_ změny rolí: Změny uživatele v OLS_ rolích nejsou podporovány a můžou způsobit neočekávané chování.

• Nepodporované identity: Zabezpečovací skupiny s povolenou poštou a distribuční seznamy nejsou aktuálně podporovány.

• Požadavky vlastníka Lakehouse:

  • Vlastník lakehouse musí být členem rolí pracovního prostoru: správce, člena nebo přispěvatele; jinak nebude zabezpečení aplikováno na koncový bod SQL analytiky.

Související obsah

• Osvědčené postupy pro zabezpečení dat ve OneLake
• Jak OneLake bezpečnost kontroluje přístup k datům