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

Díky zabezpečení OneLake rozšiřuje Microsoft Fabric možnosti správy a vynucování přístupu k datům napříč úlohami. Tato nová 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 read access se řídí výhradně pravidly zabezpečení definovanými v rámci OneLake. Podporují se oprávnění na úrovni SQL u tabulek a zajišťují konzistentní zásady správného řízení napříč nástroji, jako jsou Power BI, poznámkové bloky 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

Tady je jasná a stručná srovnávací tabulka zaměřená na to, jak a kde nastavíte zabezpečení v režimu identit uživatele a v režimu delegované identity – rozdělené podle typu objektu a dat access zásad:

Cíl zabezpečení Režim identity uživatele Delegovaný režim identity
Tabulky Přístup je řízen rolemi zabezpečení OneLake. 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 Pomocí příkazu SQL GRANT EXECUTE přiřaďte oprávnění. Pomocí příkazu SQL GRANT EXECUTE přiřaďte oprávnění.
Functions Pomocí příkazu SQL GRANT EXECUTE přiřaďte oprávnění. Pomocí příkazu SQL GRANT EXECUTE přiřaďte oprávnění.
Zabezpečení na úrovni řádků (RLS) Definované v uživatelském rozhraní OneLake jako součást rolí zabezpečení OneLake. Definováno pomocí ZÁSAD ZABEZPEČENÍ CREATE SQL.
zabezpečení na úrovni sloupců (CLS) Definované v uživatelském rozhraní OneLake jako součást rolí zabezpečení OneLake. Definováno pomocí příkazu 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.

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 se vyhodnocují pomocí pravidel zabezpečení definovaných v rámci OneLake Lakehouse, ne pomocí příkazů GRANT nebo REVOKE na úrovni SQL.

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 u tabulek 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).

Důležité

Koncový bod SQL Analytics vyžaduje 1:1 mapování mezi oprávněními k položkám a členy role zabezpečení OneLake pro správnou synchronizaci. Pokud udělíte identitě přístup k roli zabezpečení OneLake, musí mít stejná identita také oprávnění Čtení Fabric pro lakehouse. Pokud například uživatel přiřadí "user123@microsoft.com" roli zabezpečení OneLake, musí být k této lakehouse přiřazen také "user123@microsoft.com".

Chování role pracovního prostoru

Uživatelé s rolí správce, člena nebo přispěvatele na úrovni pracovního prostoru nepodléhají vynucení zabezpečení OneLake. Tyto role mají zvýšená oprávnění a zcela obcházejí zásady RLS (Úrovňové zabezpečení řádků), CLS (Zabezpečení datového sloupce) a OLS (Zabezpečení datového objektu). Pokud chcete zajistit dodržování zabezpečení OneLake, postupujte podle těchto požadavků:

  • Přiřaďte uživatelům roli Viewer v pracovním prostoru nebo

  • Sdílejte koncový bod Analýzy Lakehouse nebo SQL s uživateli s oprávněními jen pro čtení . Pouze uživatelé s access jen pro čtení mají své dotazy filtrované podle rolí zabezpečení OneLake.

Priorita role: Vyhrává nejvíce permisivní přístup

Pokud uživatel patří do více rolí OneLake, nejpovolnější role definuje jejich efektivní přístup. Například:

  • Pokud jedna role udělí úplný přístup k tabulce a jiná použije zabezpečení na úrovni řádků, RLS se nevynutí.

  • Širší přístupová role má přednost. Toto chování zajišťuje, že uživatelé nejsou neúmyslně blokovaní, ale vyžaduje pečlivé návrh role, aby se zabránilo konfliktům. Při vynucování přístupových kontrol na úrovni řádků nebo sloupců se doporučuje zachovat omezující a povolené role vzájemně vylučující se.

Pro více informací si prohlédněte model řízení přístupu k datům 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.

  • Pomocí příkazů GRANT nebo EXECUTE můžete stále používat oprávnění SQL pro zobrazení, funkce a uložené procedury.

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 zadává stav chyby, dokud není zásada opravena. Chyba: Neplatný název <>sloupce Aktualizujte nebo odeberte jednu nebo více ovlivněných rolí nebo obnovte chybějící sloupec. Aktualizace bude potřeba provést 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ává stav chyby, dokud zásady nebudou opraveny. Chyba: Neplatný název <>sloupce Aktualizujte nebo odeberte jednu nebo více ovlivněných rolí nebo obnovte chybějící sloupec. Aktualizace bude potřeba provést 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 bude potřeba provést 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 není podporováno 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ásadu DDM v koncovém bodu SQL Analytics.
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ě. Opakujte operaci; pokud problém přetrvává, obraťte se na podporu Microsoft. N/A
Uživatel nemá oprávnění k artefaktu. Chyba: Uživatel nemá oprávnění k artefaktu Chyba: Uživatel nemá oprávnění k artefaktu Zadejte uživateli oprávnění objectID {objectID} k artefaktu. ID objektu musí být přesně shodné mezi členem role zabezpečení OneLake a oprávněními k položce Fabric. Pokud je skupina přidaná do členství v roli, musí mít tato skupina oprávnění Ke čtení Fabric. Přidání člena z této skupiny do položky se nepočítá jako přímá shoda.
Principál uživatele není podporován. Chyba: Uživatelský principal není podporován. Chyba: Uživatelský principal není podporován. Odeberte uživatele {username} z role DefaultReader. K této chybě dochází v případě, že uživatel již není platným ID entra, například pokud uživatel opustil vaši organizaci nebo byl odstraněn. Pokud chcete tuto 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 jedné straně, dotazy selžou s chybou přístupu.

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

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

Delegovaný režim v zabezpečení OneLake

V režimu delegované identity používá koncový bod analýzy SQL stejný bezpečnostní model, který je dnes používán v rámci Microsoft Fabric. Zabezpečení a oprávnění jsou spravovány výhradně ve vrstvě SQL a role OneLake nebo zásady přístupu se nevynucují pro přístup na úrovni tabulky. Když se uživatel připojí ke koncovému bodu analýzy SQL a vydá dotaz:

  • SQL ověřuje access na základě oprávnění SQL (GRANT, REVOKE, RLS, CLS, DDM, role atd.).

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

  • Přístup k datům se provádí pomocí identity vlastníka služby koncového bodu Lakehouse nebo SQL Analytics—označovaného také jako položkový účet.

V tomto modelu:

  • Přihlášený uživatel se do OneLake nepředává.

  • Předpokládá se, že veškeré vynucování přístupu se zpracovává ve vrstvě SQL.

  • Vlastník položky zodpovídá za to, že má v OneLake dostatečná oprávnění ke čtení podkladových souborů jménem úlohy.

Vzhledem k tomu, že se jedná o delegovaný vzor, jakékoli chybné zarovnání mezi oprávněními SQL a oneLake access pro vlastníka vede k selhání dotazů. Tento režim poskytuje úplnou kompatibilitu s:

  • UDĚLENÍ NEBO ODVOLÁNÍ SQL na všech úrovních objektů

  • SQL-definované zabezpečení na úrovni řádků, zabezpečení na úrovni sloupců a dynamické maskování dat

  • Stávající nástroje a postupy T-SQL používané dba nebo aplikacemi

Jak změnit režim access OneLake

Přístupový režim určuje, jak se ověřuje a vynucuje přístup k datům při dotazování OneLake prostřednictvím SQL analytického koncového bodu. 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 Security a vyberte jeden z následujících režimů onelake access:

    • 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

Důležité

Přepínání mezi režimy Identity uživatele a Delegovanými režimy (v obou směrech) v současné době odstraňuje inline objekty metadat, včetně TVF a funkcí se skalárními hodnotami. 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 se vztahuje pouze na uživatele s oprávněními pro čtení nebo s oprávněním ke sdílení, které je pouze 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.

Troubleshooting

V režimu identity uživatele je možné ověřit výsledky synchronizace zabezpečení prostřednictvím uživatelského rozhraní. Otevřete koncový bod SQL Analytics, rozbalte složku Zabezpečení v Průzkumníku a pak vyberte Role databáze (vlastní). Pokud je synchronizace úspěšná, zobrazí se role uvedené s předponou ols_. Například "ols_TestRole". Názvy rolí s "ols_{alphanumericString}_rolename" jsou role z jiných lakehouse objektů, které se propagovaly skrz zkratku.

Opravy běžných chyb synchronizace bezpečnostních opatření

  • Synchronizace zabezpečení selže, pokud některá z rolí odkazuje na tabulku, která byla odstraněna. Odstraňte tyto tabulky z rolí a zkuste synchronizaci zabezpečení znovu.

  • SPNs nemohou být vlastníky lakehouse. Ujistěte se, že nadřazená položka lakehouse vlastní uživatelský účet.

  • Aby bylo možné při synchronizaci zabezpečení rozpoznat uživatele nebo skupinu, musí mít všichni členové role zabezpečení OneLake oprávnění ke čtení v rámci systéme Fabric pro lakehouse.

Omezení

  • Platí jenom pro čtenáře: Zabezpečení OneLake řídí uživatele, kteří přistupují k datům jako čtenáři. Uživatelé v jiných rolích pracovního prostoru (správce, člen nebo přispěvatel) obcházejí zabezpečení OneLake a zachovají si úplný přístup.

  • Objekty SQL nedědí vlastnictví: Zkratky jsou v koncovém bodu analytiky SQL zobrazeny jako tabulky. Při přístupu k těmto tabulkám, ať už přímo nebo prostřednictvím zobrazení, uložených procedur a dalších odvozených objektů SQL, tyto objekty nemají vlastnictví na úrovni objektů; všechna oprávnění se kontrolují za běhu, aby se zabránilo obcházení zabezpečení.

  • Při změně zástupce dojde k výpadku ověření: Když se změní cíl zástupce (například přejmenování, 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í jsou dotazy blokované, tyto operace jsou poměrně rychlé, ale někdy v závislosti na jiném interním procesu může synchronizace 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.

  • Zpožděné šíření oprávnění: Změny oprávnění nejsou okamžité. Přepnutí mezi režimy zabezpečení (identita uživatele vs. delegovaná) může vyžadovat určitý čas na propagaci, než se projeví, ale mělo by to trvat méně než 1 minutu.

  • Závislost roviny řízení: Oprávnění nelze použít pro uživatele nebo skupiny, které ještě neexistují v řídicí rovině pracovního prostoru. Musíte buď sdílet zdrojnou položku, nebo uživatel musí být členem role pracovního prostoru Prohlížeče. Všimněte si, že stejné ID objektu musí být na obou místech. Skupina a člen té skupiny se nepočítají jako shoda.

  • Nejvíce přístupné oprávnění převládá: Pokud uživatelé patří do více skupin nebo rolí, je dodrženo nejvíce povolené efektivní oprávnění. Příklad: Pokud má uživatel jedno oprávnění zamítnuto v jedné roli a povoleno v jiné, má povolení přednost.

  • omezení režimu delegovaný: Synchronizace metadat v zkratek tabulkách může selhat, pokud zdrojová položka obsahuje zásady zabezpečení OneLake, které neudělují úplný přístup tabulce vlastníkovi položky.

  • CHOVÁNÍ DENY: Pokud se u jedné zástupné tabulky použije více rolí, průsečík oprávnění se řídí pravidly SQL Serveru: DENY přepisuje GRANT. To může vést k neočekávaným výsledkům přístupu.

  • Očekávané chybové stavy: Uživatelé mohou narazit na chyby ve scénářích, jako jsou:

    • Cíl zástupce je přejmenován nebo neplatný

      • Příklad: Pokud byl zdroj tabulky odstraněn.

    • Nesprávná konfigurace zabezpečení na úrovni řádků (RLS)

      • Některé výrazy pro RLS filtrování (zabezpečení na úrovni řádků) nejsou v OneLake podporované a může umožnit neautorizovaný přístup k datům.

      • Vyřazení sloupce použitého ve výrazu filtru zneplatní RLS, a tím zastará Metadata Sync, dokud nebude RLS opraveno na panelu zabezpečení OneLake.

      • Ve verzi Public Preview podporujeme pouze tabulky s jedním výrazem. Dynamické RLS a Multi-Table RLS nejsou v tuto chvíli podporovány.

    • Omezení zabezpečení na úrovni sloupce (CLS)

      • CLS funguje tak, že udržuje seznam povolených sloupců. Pokud se povolený sloupec odebere nebo přejmenuje, stane se zásada CLS neplatná.

      • Pokud je CLS neplatný, synchronizace metadat se zablokuje, dokud se pravidlo CLS nespraví na panelu zabezpečení OneLake.

    • Selhání synchronizace metadat nebo oprávnění

      • Pokud dojde ke změnám tabulky, například přejmenování sloupce, zabezpečení se na nový objekt nereplikuje a zobrazí se chyby uživatelského rozhraní, které ukazují, že sloupec neexistuje.

  • Přejmenování tabulky nezachovávají zásady zabezpečení: Pokud jsou role zabezpečení OneLake (OLS) definované na úrovni schématu, zůstanou tyto role účinné pouze za předpokladu, že název tabulky zůstane beze změny. Přejmenování tabulky přeruší přidružení a zásady zabezpečení se nebudou migrovat automaticky. To může vést k neúmyslnému vystavení dat, dokud se zásady znovu neaplikují.

  • Zabezpečovací role OneLake nemohou mít názvy delší než 124 znaků; jinak neproběhne synchronizace.

  • Změny uživatelů v rolích OLS_ se nepodporují a můžou způsobit neočekávané chování.

  • Skupiny zabezpečení povolené pro e-mail a distribuční seznamy nejsou podporovány.

  • Vlastník lakehouse musí patřit do rolí pracovního prostoru jako správce, člen nebo přispěvatel; v opačném případě se zabezpečení nepoužije na koncový bod SQL Analytics.

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

Související obsah

  • Last updated on