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

Díky zabezpečení OneLake se Fabric rozšiřuje způsob správy a vynucování přístupu k datům napříč úlohami. Tato architektura zabezpečení poskytuje správcům větší flexibilitu při konfiguraci oprávnění. Správci si můžou vybrat mezi centralizovanými zásadami správného řízení prostřednictvím OneLake nebo podrobného řízení založeného na SQL v rámci koncového bodu analýzy SQL.

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: Vynucuje zabezpečení pomocí rolí a zásad 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. Podporují se oprávnění na úrovni SQL pro ne-datové objekty (zobrazení, uložené procedury, funkce), a umožňují konzistentní řízení přístupu napříč nástroji, jako jsou Power BI, notebooky a lakehouse.

• Delegovaný režim identity: Poskytuje úplnou kontrolu prostřednictvím SQL. V tomto režimu se koncový bod analýzy SQL připojí k OneLake pomocí identity vlastníka pracovního prostoru nebo položky a zabezpečení se řídí výhradně oprávněními SQL definovanými uvnitř databáze. Tento model podporuje tradiční přístupy zabezpečení, včetně GRANT, REVOKE, vlastních rolí, Row-Level Zabezpečení a dynamického maskování dat.

Každý režim podporuje různé modely zásad správného řízení. Pochopení jejich dopadů je nezbytné pro volbu správného přístupu ve vašem prostředí Fabric.

Porovnání mezi přístupovými režimy

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:

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í.

• Zabezpečení na úrovni řádků (Row-Level Security), zabezpečení na úrovni sloupců (Column-Level Security) a zabezpečení na úrovni objektů (Object-Level Security) jsou definovány v prostředí OneLake.

• 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).

Další informace o modelu oprávnění s režimem identity uživatele najdete v modelu řízení přístupu k datům pro zabezpečení OneLake.

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í

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.

• Při navrhování aplikací nebo zobrazení, která odkazují na zástupce, se ujistěte, že jsou přiřazení rolí správně nakonfigurovaná na obou koncích vztahu zástupce.

Tento návrh zachovává integritu zabezpečení napříč hranicemi lakehouse, ale zavádí scénáře, v nichž může dojít k selhání přístupu, pokud role napříč lakehouse nejsou vzájemně sladěny.

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. Zabezpečení se definuje a vynucuje na vrstvě modulu SQL a role zabezpečení a zásady přístupu OneLake se nepřenesou do přístupu na úrovni tabulky. Veškeré filtrování a řízení přístupu, včetně přístupu ke schématům a tabulkám, zabezpečení na úrovni řádků (RLS), zabezpečení na úrovni sloupců (CLS) a dynamického maskování dat (DDM), musí být definované pomocí konstrukcí SQL (GRANT/REVOKE, zásad zabezpečení apod.).

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

Vzhledem k tomu, že se delegovaný režim připojuje k OneLake pomocí identity vlastníka položky, fungují klávesové zkratky jenom v případě, že má vlastník neomezený přístup k celé zdrojové tabulce. Pokud má zdrojová tabulka použité nějaké pravidlo zabezpečení na úrovni OneLake, například Row-Level Zabezpečení (RLS), Column-Level Zabezpečení (CLS) – koncový bod analýzy SQL zablokuje 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.

Jak změnit režim access 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. Mezi režimem identity uživatele a delegovaným režimem identity můžete přepínat pomocí následujících kroků:

1. Přejděte do pracovního prostoru Fabric a otevřete svůj lakehouse. V pravém horním rohu přejděte z lakehouse na koncový bod analýzy SQL.

2. V horní navigaci přejděte na kartu Zabezpečení a vyberte jeden z následujících režimů přístupu OneLake:

   • Identita uživatele – používá identitu přihlášeného uživatele. Vynucuje role OneLake.

   • Delegovaná identita – používá identitu vlastníka položky. Vynucuje pouze oprávnění SQL.

3. Otevře se automaticky otevírané okno, které potvrdí výběr. Výběrem možnosti Ano potvrďte změnu.

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

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.

  • Zabezpečení od návrhu: Zásady zabezpečení zůstávají konzistentní bez ohledu na to, jestli se k datům přistupuje prostřednictvím SQL, Spark nebo Power BI.

• Závislost na řídicí rovině (přísné porovnávání identit):: Zabezpečení OneLake vyžaduje, aby identita s přístupem uděleným na straně producenta byla stejná jako identita uznaná během vyhodnocení přístupu v rovině dat příjemce. Systém ověří konkrétní subjekt, kterému byl udělen přístup ve zdroji, a nerozšiřuje vnořené členství ve skupině ani neodvozuje efektivní přístup prostřednictvím nepřímého členství.

  • Shoda na základě literálu: Přístup se vyhodnotí podle přesného ID objektu poskytnutého producentem.

  • Žádné vnořené/efektivní řešení: Členství v vnořené skupiny nebo nepřímá dědičnost nejsou považovány za dostatečné pro vynucení. Podívejte se na vysvětlení v režimu uživatelské identity v zabezpečení OneLake pro podrobný příklad.

• 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 zabezpečení na úrovni sloupců (CLS): CLS udržuje striktní povolení seznam 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é můžou vidět sloupce v Průzkumník objektů nebo sys.columns i v případě, že Column-Level Security jim brání ve čtení těchto sloupců. 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.

• Zabezpečení SQL skladu a klávesové zkratky: Zásady zabezpečení definované pomocí konstrukcí SQL ve skladu Warehouse, jako je zabezpečení na úrovni řádků (Row-Level Security, RLS), zabezpečení na úrovni sloupců (Column-Level Security, CLS) nebo zabezpečení na úrovni objektů (Object-Level Security, OLS), jsou vynucovány pouze v kontextu provádění SQL v rámci skladu (koncový bod TDS).

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.

    • Zabezpečení na úrovni řádků v režimu identity uživatele: Pokud je v režimu identity uživatele nakonfigurované zabezpečení Row-Level (RLS), vynucují se definovaná pravidla zabezpečení pro všechny uživatele, včetně těch, které jsou v rolích Správce, Člen a Přispěvatel.

• 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 se role zabezpečení OneLake synchronizují do koncového bodu analýzy SQL prostřednictvím procesu synchronizace zabezpečení. Dokud synchronizace neskončí, sql může dočasně vyhodnotit přístup pomocí existujícího stavu oprávnění SQL. Po dokončení synchronizace koncový bod SQL odráží konfiguraci zabezpečení OneLake.

• Povědomí o hranicích zkratek: Koncový bod analýzy SQL může zpočátku vyhodnotit tabulky využívající zkratky pomocí standardní sémantiky objektů SQL. Po synchronizaci zabezpečení se použijí zásady zabezpečení OneLake, aby se zajistilo, že vynucení přístupu odpovídá hranicím artefaktů a pracovních prostorů.

• Načasování vynucování přístupu mezi artefakty: Přístup k tabulkám založeným na zkratkách OneLake, které odkazují na data z jiných artefaktů, se vynucují prostřednictvím synchronizovaných rolí zabezpečení OneLake. Dokud nedojde k synchronizaci, může autorizace SQL dočasně odrážet předchozí stav oprávnění.

• 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.

  • Vlastníkem lakehouse nemůže být service principal, aby synchronizace zabezpečení fungovala.

Související obsah

• Osvědčené postupy pro zabezpečení dat ve OneLake
• Model řízení přístupu k zabezpečení OneLake