Jak OneLake bezpečnost kontroluje přístup k datům

Bezpečnost OneLake je systém založený na rolích, který určuje, kdo může v OneLake přistupovat k datům a jaké kroky může na těchto datech podniknout. Pochopení modelu řízení přístupu k datům vám pomůže uživatelům udělit pouze ten přístup, který potřebují, takže můžete chránit citlivá data a zároveň umožnit správným lidem s nimi pracovat.

Tento článek vysvětluje, jak jsou bezpečnostní role OneLake strukturovány, jak se integrují s oprávněními pracovních prostor a položek, jak OneLake aplikuje a řeší přístup k vašim datům a jaké limity je třeba mít na paměti.

Role zabezpečení OneLake

Bezpečnost OneLake využívá model řízení přístupu založený na rolích (RBAC) ke správě přístupu k datům v OneLake. V bezpečnostní zkušenosti OneLake má každá role následující složky:

Oprávnění: Oprávnění, která role uděluje k datům, například čtení nebo čtení a zápis.
Typ: Typ role. Bezpečnost OneLake podporuje pouze grantové role, které členům umožňují přístup k datům v dané roli. Nepodporuje role typu Deny, které odebírají přístup.
Data v roli: Tabulky, složky nebo schémata, ke kterým role umožňuje přístup. Přístup k datům můžete také definovat pomocí zabezpečení na úrovni řádků a sloupců u tabulek.
Členové role: Identity Microsoft Entra přiřazené k roli, například uživatelé, skupiny nebo neuživatelské identity. Pokud přiřadíte skupinu Microsoft Entra, bezpečnost OneLake přidělí tuto roli všem členům skupiny.

Zabezpečení OneLake používá model odepření přístupu ve výchozím nastavení, takže uživatelé ve výchozím nastavení nemají k datům přístup, pokud role zabezpečení OneLake přístup explicitně neudělí. Některé položky Fabric začínají s výchozími rolemi, které uživatelům poskytují základní přístup na základě oprávnění pracovního prostoru.

Oprávnění a podporované položky

Bezpečnostní role OneLake podporují následující oprávnění:

Číst: Udělí uživateli možnost číst data z tabulky a zobrazit přidružená metadata tabulek a sloupců. V SQL termínech je toto oprávnění ekvivalentní jak VIEW_DEFINITION , tak .SELECT Pro více informací viz Bezpečnost metadat.
ReadWrite: Umožňuje uživateli číst a zapisovat data v tabulce nebo složce a zobrazit příslušná metadata tabulek a sloupců. V terminologii SQL toto oprávnění odpovídá oprávněním ALTER, DROP, UPDATE a INSERT. Pro více informací viz ReadWrite permission.

Můžete vytvořit bezpečnostní role v OneLake pro následující položky Fabric:

Textilní položka	Podporovaná oprávnění
Dům u jezera	Čtení, Čtení a zápis
Zrcadlený katalog Azure Databricks	Přečtěte
Zrcadlené databáze	Přečtěte
Zrcadlové katalogy	Přečtěte

Oprávnění pro čtení a zápis

Použijte oprávnění ReadWrite k umožnění uživatelům pouze pro čtení přístupu ke zápisu ke specifickým datům v položce.

ReadWrite se vztahuje pouze na uživatele s oprávněním ke čtení položky, například pro uživatele s rolí Viewer workspace. Přiřazení ReadWrite administrátorovi, členovi nebo přispěvateli v pracovním prostoru nemá žádný efekt, protože tyto role v pracovním prostoru již mají přístup k zápisu.

ReadWrite zahrnuje všechna oprávnění udělená oprávněním ke čtení a zároveň umožňuje zápis k vybranému objektu a jeho obsahu. Například oprávnění ReadWrite na složce umožňuje zápis jak do složky, tak k datům v ní.

Uživatelé s oprávněním ReadWrite mohou provádět následující činnosti:

Vytvořte, smažte nebo přejmenujte složku či tabulku.
Nahrajte nebo upravte soubor.
Vytvořte, smažte nebo přejmenujte zkratku.

Uživatelé mohou provádět zápisové operace prostřednictvím Spark notebooků, průzkumníku souborů OneLake nebo API OneLake. Protože Fabric podporuje pouze zápisy do dat jedním enginem, uživatelé s oprávněním ReadWrite mohou zapisovat pouze do těchto dat prostřednictvím OneLake. Všechny dotazovací enginy nadále konzistentně vynucují čtení operací.

Bezpečnostní role OneLake, které udělují oprávnění ReadWrite, nemohou obsahovat bezpečnostní omezení na úrovni řádků (RLS) ani na úrovni sloupců (CLS).

Oprávnění zabezpečení a pracovního prostoru OneLake

Role v pracovním prostoru jsou první bezpečnostní hranicí pro data v OneLake. Spravují řídicí rovinu – vytvářejí a spravují položky a oprávnění Fabric – a aplikují je na všechny položky v pracovním prostoru. Pro konkrétní oprávnění OneLake, která každá role v pracovním prostoru uděluje, viz Udělování přístupu s rolemi v pracovním prostoru. Pro více informací o pracovních místech viz Role v pracovních prostorech ve Fabric.

Kromě přístupu k rovině řízení můžou role pracovního prostoru také poskytovat přístup k datovým položkám prostřednictvím výchozích rolí zabezpečení OneLake. (Výchozí role se vztahují pouze na Viewery, protože role Admin, Člen a Přispěvatel mají zvýšený přístup díky oprávnění Zápisu.) Výchozí role je běžná bezpečnostní role OneLake, kterou Fabric automaticky vytváří s každou novou položkou. Poskytuje uživatelům s určitým pracovním prostorem nebo položkou oprávnění výchozí úroveň přístupu k datům v této položce. Například položky lakehouse mají roli DefaultReader, která uživatelům s oprávněním ReadAll umožňuje zobrazit data v lakehouse. Tento výchozí přístup zajišťuje, že uživatelé pracující s nově vytvořeným předmětem mají základní úroveň přístupu. Všechny výchozí role používají funkci virtualizace členů, takže členy role jsou všichni uživatelé v daném pracovním prostoru s požadovaným oprávněním. Například všichni uživatelé s oprávněním ReadAll pro lakehouse.

Následující tabulka ukazuje standardní výchozí role. Předměty mohou mít specializované výchozí role, které se vztahují pouze na daný typ předmětu.

Textilní položka	Název role	Povolení uděleno	Přidělení členové
Dům u jezera	`DefaultReader`	Přečtěte	Všichni uživatelé s oprávněním ReadAll
Zrcadlený katalog Azure Databricks	`DefaultReader`	Přečtěte	Všichni uživatelé s oprávněním ke čtení
Zrcadlový katalog	`DefaultReader`	Přečtěte	Všichni uživatelé s oprávněním ke čtení
Zrcadlené databáze	`DefaultReader`	Přečtěte	Všichni uživatelé s oprávněním ReadAll

Můžete upravit nebo odstranit výchozí roli z položky Fabric, abyste změnili přístup uživatelů v této skupině.

Stroj a uživatelský přístup k datům

Zabezpečení OneLake je ve výchozím nastavení nastavené na přístup s nejnižšími oprávněními. Některé operace na úrovni úložiště nemohou vynucovat RLS nebo CLS, takže když dotaz nelze bezpečně filtrovat, OneLake jej zcela zablokuje, aby neriskoval vystavení dat, která uživatel nesmí vidět. Zda je dotaz filtrován nebo blokován, závisí na přístupové cestě – podporovaném dotazovacím enginu nebo přímém přístupu uživatele.

Informace o modulech, které podporují filtrování RLS a CLS, a o požadavcích pro každý z nich naleznete v článku Čtení dat zabezpečených zabezpečením OneLake.

Rozsah a vymáhání

Tato část obsahuje podrobnosti o tom, jak role zabezpečení OneLake udělují přístup konkrétním oborům, jak tento přístup funguje a jak se řeší přístup napříč několika rolemi a typy přístupu.

Zabezpečení na úrovni tabulky

OneLake reprezentuje všechny tabulky jako složky, ale z pohledu bezpečnosti a dotazovacích enginů OneLake ve Fabric nejsou všechny složky tabulkami. Aby byla složka platnou tabulkou, musí splňovat následující podmínky:

Složka existuje v adresáři Tables/ položky. U položek s povoleným schématem musí být složka také v platné složce schématu.
Složka obsahuje složku _delta_log s odpovídajícími JSON soubory pro metadata tabulek.
Složka neobsahuje žádné podřazené zástupce.

Pokud nakonfigurujete RLS nebo CLS na tabulce, OneLake přístup odepře, pokud složka tabulky tato kritéria nesplňuje. Bez RLS nebo CLS OneLake považuje složku, která nesplňuje tato kritéria, za složku a aplikuje zabezpečení na úrovni složky.

Zabezpečení na úrovni řádků a sloupců

V rámci role můžete omezit přístup ke konkrétním řádkům a sloupcům tabulky pomocí zabezpečení na úrovni řádků a sloupců. Pro více informací o tom, co každá kontrola dělá a jak ji OneLake vynucuje, viz Bezpečnost na úrovni tabulek, sloupců a řádků v OneLake. Pro informace o tom, jak RLS a CLS řeší, když uživatel patří do více rolí, viz Vyhodnocení více bezpečnostních rolí OneLake.

Zabezpečení metadat

Oprávnění ke čtení zabezpečení OneLake uděluje úplný přístup k datům a metadatům v tabulce. Pro uživatele bez přístupu k tabulce se data nikdy nezpřístupní. Toto pravidlo platí také pro bezpečnost na úrovni sloupců a schopnost uživatele vidět nebo nevidět sloupec v dané tabulce. Bezpečnost OneLake však nezaručuje, že metadata tabulky nejsou přístupná. Některé chybové zprávy a zkušenosti mohou zobrazovat názvy sloupců.

Dědění a procházení oprávnění složky

Oprávnění složek ovlivňují hierarchii ve dvou směrech:

Dědičnost: Oprávnění udělená složce platí níže na její soubory a podsložky.
Procházení a výpis: Když mají uživatelé oprávnění k podřízené položce, zabezpečení OneLake jim umožňuje zobrazit a procházet její nadřazené složky, aby mohli najít a přejít k datům, ke kterým mají přístup. Procházení neumožňuje přístup k souborům nebo složkám sourozenců.

Zvažte následující hierarchii jezerního domu v OneLake:

Tables/
──── (empty folder)
Files/
────folder1
│   │   file11.txt
│   │
│   └───subfolder11
│       │   file111.txt
│       │
│       └───subfolder111
│            │   file1111.txt
│   
└───folder2
    │   file21.txt

Vytvoříte roli, Role1, která uděluje oprávnění ke čtení na subfolder11. Díky dědičnosti mohou členové této role číst file111.txt a vše v subfolder111. Členové mohou zobrazit a procházet folder1, aby se dostali k subfolder11, ale nemohou vidět file11.txt, protože je sourozencem subfolder11, a nemohou vidět Tables, protože je sourozencem Files.

Files/
│
└───folder1
│   │
│   └───subfolder11 <-- READ
│       │   file111.txt
│       │
│       └───subfolder111
│            │   file1111.txt

Vytvoříte další roli, Role2, která uděluje oprávnění ke čtení na folder2. Prostřednictvím dědičnosti mohou členové číst file21.txt. Členové se k ní mohou dostat přes folder2 a Files, ale nemohou vidět folder1 ani žádný z jejích podřízených prvků.

Files/
│
└───folder2 <-- READ
    │   file21.txt

U zkratek je chování trochu jiné. Zkratky k externím datovým zdrojům se chovají stejně jako složky. Zkratky do jiných lokalit OneLake však mají specializované chování. Cílová oprávnění odkazu určují přístup ke zkratce OneLake. Při vypisování zkratek OneLake nevyzývá k ověření přístupu k cíli. Výsledkem je, že když vypíšete obsah adresáře, OneLake vrátí všechny interní zkratky bez ohledu na to, zda máte přístup k cíli. Kontrola přístupu se vyhodnocuje, jakmile se pokusíte otevřít zkratku, a pak vidíte jen ta data, ke kterým máte požadovaná oprávnění.

Zkratky

Bezpečnost OneLake se integruje pomocí zkratek pro zabezpečení dat uvnitř i vně OneLake. Zkratky používají jeden ze dvou autentizačních režimů:

Průchod: Zkratka využívá identitu dotazujícího uživatele k přístupu k cíli. Přechod je výchozí pro zkratky OneLake-to-OneLake.
Delegováno: Zkratka používá konfigurovanou identitu spojení nebo přihlašovací údaje k přístupu k cíli. Zkratky OneLake-to-OneLake mohou využívat delegovanou autentizaci a zkratky k externím systémům vždy využívají delegovanou autentizaci.

Vytvoření zkratky vyžaduje oprávnění jak na cestě, kde je zkratka vytvořena, tak na cílové cestě. Požadavky na vytvoření a přístup ke každému typu zkratek najdete v článku OneLake shortcut security.

Zabezpečení OneLake v předávacích klávesových zkratkách

Když uživatel přistupuje k datům prostřednictvím zkratky OneLake-to-OneLake, OneLake použije identitu volajícího uživatele k autorizaci přístupu k cílové cestě. Efektivní přístup uživatele je omezen jeho oprávněními jak na zkratce, tak na cílové cestě.

Poznámka:

Identita dotazovacího motoru a ověřování pomocí zkratek jsou samostatná nastavení. Zkratka pro přechod obvykle využívá identitu volajícího uživatele k přístupu k cíli. Nicméně sémantické modely Power BI využívající Direct Lake přes SQL a SQL analytické koncové body v režimu delegované identity používají identitu vlastníka spotřebitelské položky nebo datového zdroje. Toto chování nemění konfigurovaný autentizační režim zkratky. Pro end-to-end user identity passthrough použijte Direct Lake místo OneLake nebo nastavte SQL analytics endpoint tak, aby používal režim přístupu k identitě uživatele.

Nemůžete definovat bezpečnostní oprávnění OneLake přímo pomocí zkratky OneLake-to-OneLake. Oprávnění ve složce, která obsahuje zkratku, se spojují s oprávněními na cílové cestě. Pokud cílová položka podporuje zabezpečení OneLake, uživatel potřebuje přístup prostřednictvím bezpečnostní role OneLake. Pokud cílová položka nepodporuje zabezpečení OneLake, uživatel potřebuje oprávnění Fabric ReadAll na cílové položce. Uživatel nepotřebuje povolení Fabric Read na cílové položce pouze proto, aby mohl přistupovat k jejím datům přes zkratku.

Zabezpečení OneLake v delegovaných zkratkách

Delegované zkratky používají nakonfigurovanou identitu spojení nebo přihlašovací údaje místo identity volajícího uživatele pro přístup k cíli. Bezpečnost OneLake omezuje, k čemu může volající uživatel přistupovat přes toto připojení.

Delegovaní zástupci OneLake

Pro delegovanou zkratku OneLake-to-OneLake vidí volající uživatel průsečík svého přístupu na cestě zkratky a přístupu konfigurované identity připojení na cílové cestě. Bezpečnost na úrovni sloupců (CLS) je podporována na obou cestách. Bezpečnost na úrovni řádků (RLS) je podporována na cílové cestě, ale RLS nelze definovat na cestě zkratek.

Delegované vnější zkratky

Zkratky k externím systémům, jako jsou ADLS, Amazon S3 a Dataverse, využívají konfigurované přihlašovací údaje k připojení k externímu zdroji. Zabezpečení OneLake se uplatňuje nad rámec přístupu uděleného tímto přihlašovacím údajem.

Například předpokládejme, že uživatel1 vytvoří zkratku pro jezerní dům do složky v Amazon S3 kbelíku a uživatel2 přistupuje ke zkratce z jezerního domu. Uživatel 2 může přistupovat k datům S3 pouze tehdy, pokud konfigurované přihlašovací údaje S3 umožňují přístup ke zdroji a zabezpečení OneLake povolí uživateli 2 přístup ke zkratce.

OneLake můžete poskytnout přístup k bezpečnosti celé externí zkratce nebo k vybraným podcestám. Oprávnění u složky se rekurzivně vztahují na všechny její podsložky, včetně složek uvnitř zástupce. Uživatel, který se dostane na externí zkratku přes jinou zkratku OneLake, musí být stále autorizován bezpečností OneLake aplikovanou na původní externí zkratku.

Přístup k externí zkratce přes Spark nebo přímé volání API OneLake také vyžaduje povolení Fabric Read na položce, která obsahuje externí zkratku. Toto oprávnění je nutné k bezpečnému vyřešení spojení s externím systémem.

Zhodnoťte více bezpečnostních rolí v OneLake

Uživatel může patřit do více bezpečnostních rolí OneLake. OneLake kombinuje přístup udělený těmito rolemi do efektivní role, která určuje, ke kterým datům má uživatel přístup. OneLake vyhodnocuje výslednou roli po etapách.

Vyřešit přístup v rámci každé role

OneLake nejprve vyřeší každou roli samostatně. V rámci role může uživatel přistupovat pouze k datům povoleným všemi třemi bezpečnostními komponentami:

Objektová bezpečnost (OLS) určuje, ke kterým tabulkám nebo složkám může role přistupovat.
Bezpečnost na úrovni řádků (RLS) omezuje, ke kterým řádkům dané tabulky může role přistupovat.
Bezpečnost na úrovni sloupců (CLS) omezuje, ke kterým sloupcům dané tabulky může role přistupovat.

Protože se uplatňují všechny tři komponenty, OneLake bere jejich průnik. Například pokud Role1 uděluje přístup k Tabulce 1 a omezí její řádky a sloupce, vyřešený přístup pro Role1 je:

Role1 = R1_OLS ∩ R1_RLS ∩ R1_CLS

Symbol průniku (∩) znamená, že uživatel získá pouze přístup povolený OLS, RLS a CLS v dané roli.

Kombinujte přístup napříč rolemi

Po vyřešení každé role OneLake kombinuje role pomocí modelu sjednocení, tedy nejméně restriktivního. Symbol svazu (∪) znamená, že přístup udělený jakoukoli rolí se stává součástí efektivní role. Pokud Role1 uděluje přístup k TableA a Role2 k TableB, uživatel patřící do obou rolí může přistupovat k oběma tabulkám.

Pro dvě role je efektivní role:

Effective role = Role1 ∪ Role2

Když více rolí umožňuje přístup ke stejné tabulce, bezpečnostní pravidla na úrovni řádků se kombinují s operátorem OR . Například predikáty, které umožňují city = 'Redmond' a city = 'New York', se kombinují jako city = 'Redmond' OR city = 'New York'.

Bezpečnostní pravidla na úrovni sloupce se také uplatňují jako sjednocení, s výjimkou koncového bodu pro analýzy SQL. V koncovém bodu SQL Analytics používá CLS přísnější princip zamítnutí. Pokud nějaká role skryje sloupec, endpoint zablokuje přístup k tomuto sloupci. Výsledkem je, že koncový bod protíná seznamy povolení CLS napříč všemi rolemi uživatele místo toho, aby je spojoval do sjednocení.

Důležité

Ponechte pravidla RLS a CLS, která se musí uplatňovat společně, ve stejné roli. OneLake nepodporuje kombinaci rolí, kde dvě role umožňují různé sloupce pro tabulku a každá z nich také aplikuje RLS na tuto tabulku. Například uživatel nemůže patřit do Role1, která umožňuje sloupce c1 a c2 a podmnožinu řádků, a Role2, která umožňuje sloupce c2 a c3.

Sloučit zkratku a cílový přístup

Pro zkratku OneLake vyhodnocuje role na místě zkratky a na cíli zkratky zvlášť. Cílové role se na místě zkratky stávají odvozenými rolemi . OneLake pak protíná kombinovaný přístup z rolí zkratek s kombinovaným přístupem z odvozených cílových rolí. Tento krok zabrání tomu, aby přístupová oprávnění zděděná v umístění zástupce přepsala omezení u cílového objektu.

Pro dvě zkratkové role a dvě odvozené cílové role je efektivní přístup:

Effective shortcut access = (ShortcutRole1 ∪ ShortcutRole2) ∩ (InferredRole1 ∪ InferredRole2)

V tomto výrazu jsou ShortcutRole1 a ShortcutRole2 role v umístění zástupce. InferredRole1 a InferredRole2 jsou odpovídající odvozené role z cílové zkratky. Každá role se předtím, než OneLake role zkombinuje, vyhodnocuje na základě svých komponent OLS, RLS a CLS.

Omezení zabezpečení OneLake

Pokud přiřadíte roli zabezpečení OneLake B2B uživateli typu host, musíte nakonfigurovat nastavení externí spolupráce pro B2B v Microsoft Entra Externí ID. Nastavte nastavení Přístup uživatelů typu Host na Uživatelé typu Host mají stejný přístup jako členové (nejotevřenější).
Pokud v zabezpečení OneLake přidáte do role distribuční seznam, koncový bod analýz SQL nedokáže vyhodnotit členy tohoto seznamu, a proto nemůže vynucovat řízení přístupu. Výsledkem je, že uživatelé při přístupu k SQL analytics endpointu nejsou členy této role. Direct Lake pro sémantické modely SQL také podléhá tomuto omezení.
Spark notebooky vyžadují, aby prostředí bylo 3.5 nebo vyšší a používaly runtime Fabric 1.3.
Lakehousy bez schématu nepodporují náhled dat u tabulek zabezpečených pomocí RLS a CLS. Používejte lakehouse s podporou schémat a zabezpečením OneLake.
Bezpečnost OneLake nefunguje s Azure Data Share nebo Purview Data Share. Další informace najdete v tématu Azure Data Share.

Následující tabulka uvádí omezení bezpečnostních rolí OneLake.

Scénář	Omezení
Maximální počet rolí zabezpečení OneLake na položku Fabric	250 rolí na položku (viz poznámka)
Maximální počet členů na roli zabezpečení OneLake	500 uživatelů nebo skupin uživatelů na roli
Maximální počet oprávnění na roli zabezpečení OneLake	500 oprávnění na roli