Správa autorizace prostřednictvím zabezpečení na úrovni sloupců a řádků

Dokončeno

V tomto tématu si ukážeme, jak v Azure Synapse Analytics spravovat autorizaci prostřednictvím zabezpečení na úrovni sloupců a řádků. Začneme tím, že v Azure Synapse Analytics probereme zabezpečení na úrovni sloupců a dokončíme zabezpečení na úrovni řádků.

Zabezpečení na úrovni sloupců ve službě Azure Synapse Analytics

Obecně řečeno, zabezpečení na úrovni sloupců zjednodušuje návrh a kódování zabezpečení ve vaší aplikaci. Umožňuje omezit přístup ke sloupcům, aby bylo možné chránit citlivá data. Pokud například chcete zajistit, aby konkrétní uživatel Leo měl přístup jenom k určitým sloupcům tabulky, protože je v určitém oddělení. Logika "Leo" pouze pro přístup ke sloupcům zadaným pro oddělení, ve které pracuje, je logika, která se nachází v databázové vrstvě, a ne na datové vrstvě na úrovni aplikace. Pokud potřebuje přistupovat k datům z libovolné vrstvy, měla by databáze použít omezení přístupu při každém pokusu o přístup k datům z jiné vrstvy. Důvodem, proč to udělat, je zajistit, aby vaše zabezpečení bylo spolehlivé a robustní, protože snižujeme plochu celkového systému zabezpečení. Zabezpečení na úrovni sloupců také eliminuje nutnost zavedení zobrazení, ve kterém byste vyfiltrovali sloupce, aby se omezení přístupu na "Leo" omezila.

Způsob implementace zabezpečení na úrovni sloupců je použití příkazu GRANT T-SQL. Pomocí tohoto příkazu podporuje ověřování SQL a Microsoft Entra ID.

Syntaxe

Syntaxe, která se má použít k implementaci zabezpečení na úrovni sloupců, vypadá takto:

GRANT <permission> [ ,...n ] ON
    [ OBJECT :: ][ schema_name ]. object_name [ ( column [ ,...n ] ) ] // specifying the column access
    TO <database_principal> [ ,...n ]
    [ WITH GRANT OPTION ]
    [ AS <database_principal> ]
<permission> ::=
    SELECT
  | UPDATE
<database_principal> ::=
      Database_user // specifying the database user
    | Database_role // specifying the database role 
    | Database_user_mapped_to_Windows_User
    | Database_user_mapped_to_Windows_Group

Kdy byste tedy použili zabezpečení na úrovni sloupců? Řekněme, že jste firma poskytující finanční služby a může mít přístup pouze správce účtu, který může mít přístup k číslu sociálního pojištění zákazníka, telefonnímu číslu nebo jiným identifikovatelným osobním údajům. Je nezbytné rozlišovat roli správce účtů a manažera správců účtů.

Jiný případ použití může souviset se zdravotnictvím. Řekněme, že máte konkrétního poskytovatele zdravotní péče. Tento poskytovatel zdravotní péče chce, aby lékaři a zdravotní sestry měli přístup k lékařským záznamům. Fakturační oddělení by nemělo mít přístup k zobrazení těchto dat. Zabezpečení na úrovni sloupců může být možností použití.

Jak se tedy zabezpečení na úrovni sloupců liší od zabezpečení na úrovni řádků? Pojďme se na to podívat.

Zabezpečení na úrovni řádků ve službě Azure Synapse Analytics

Zabezpečení na úrovni řádků (RLS) vám může pomoct vytvořit členství ve skupině nebo kontext spuštění, aby bylo možné řídit nejen sloupce v tabulce databáze, ale ve skutečnosti řádky. Zabezpečení na úrovni řádků stejně jako zabezpečení na úrovni sloupců vám může jednoduše pomoct a umožnit návrh a kódování zabezpečení aplikace. V porovnání se zabezpečením na úrovni sloupců, kde se zaměřuje na sloupce (parametry), pomáhá zabezpečení na úrovni řádků na úrovni sloupců implementovat omezení přístupu k řádkům dat. Řekněme, že váš zaměstnanec má přístup jenom k řádkům dat, která jsou pro oddělení důležitá, měli byste implementovat zabezpečení na úrovni řádků. Pokud například chcete omezit přístup k zákaznickým datům, který je relevantní jenom pro společnost, můžete implementovat zabezpečení na úrovni řádků. Omezení přístupu k řádkům je logika, která se nachází v databázové vrstvě, a ne na datové vrstvě na úrovni aplikace. Pokud Leo potřebuje přístup k datům z libovolné vrstvy, měla by databáze použít omezení přístupu při každém pokusu o přístup k datům z jiné vrstvy. Důvodem, proč to udělat, je zajistit, aby vaše zabezpečení bylo spolehlivé a robustní, protože snižujeme plochu celkového systému zabezpečení.

Způsob implementace zabezpečení na úrovni řádků je použití ZÁSAD ZABEZPEČENÍ CREATE[! Příkaz INCLUDEtsql]. Predikáty se vytvoří jako vložené funkce hodnotné tabulkou. Je nezbytné pochopit, že v rámci Azure Synapse podporuje pouze predikáty filtru. Pokud potřebujete použít predikát bloku, nebudete v tuto chvíli moct v Azure Synapse najít podporu.

Popis zabezpečení na úrovni řádků ve vztahu k predikátům filtru

Zabezpečení na úrovni řádků v rámci Azure Synapse podporuje jeden typ predikátů zabezpečení, což jsou predikáty filtru, ne blokované predikáty.
Co predikáty filtru dělají, je bezobslužné filtrování řádků, které jsou k dispozici pro operace čtení, jako je SELECT, UPDATE, DELETE.

Přístup k datům na úrovni řádků v tabulce je omezen jako vložená funkce hodnotná tabulkou, což je predikát zabezpečení. Tato funkce s hodnotou tabulky se pak vyvolá a vynucuje zásadami zabezpečení, které potřebujete. Aplikace neví o řádcích filtrovaných ze sady výsledků pro predikáty filtru. Co se tedy stane, když se vyfiltrují všechny řádky, vrátí se sada null.

Pokud používáte predikáty filtru, použije se při čtení dat ze základní tabulky. Predikát filtru ovlivňuje všechny operace získání, jako je SELECT, DELETE, UPDATE. Nemůžete vybrat nebo odstranit filtrované řádky. Není možné aktualizovat řádek, který byl filtrován. To, co můžete udělat, je aktualizovat řádky způsobem, který se následně vyfiltruje.

Případy použití

Už jsme zmínili některé případy použití zabezpečení na úrovni řádků. Jiný případ použití může způsobit, že jste vytvořili aplikaci s více tenanty, kde vytvoříte zásadu, ve které se vynucují logické oddělení řádků dat tenanta od řádků dat jiného tenanta. Pro efektivní implementaci je důrazně doporučeno ukládat data pro mnoho tenantů v jedné tabulce.

Když se podíváme na predikáty filtru RLS, jsou funkčně ekvivalentní připojení klauzule WHERE . Predikát může být stejně sofistikovaný jako obchodní postupy, nebo klauzule může být jednoduchá jako WHERE TenantId = 42.

Když se podíváme na zabezpečení na úrovni řádků formálněji, RLS zavádí řízení přístupu na základě predikátu. Důvodem, proč lze zabezpečení na úrovni řádků použít pro řízení přístupu k predikátům, je, že se jedná o flexibilní, centralizované a predikátové vyhodnocení. Predikát filtru může být založený na metadatech nebo na jakýchkoli jiných kritériích, která byste podle potřeby určili. Predikát se používá jako kritérium k určení, jestli má uživatel odpovídající přístup k datům na základě atributů uživatele. Řízení přístupu na základě popisků je možné implementovat pomocí řízení přístupu na základě predikátu.

Oprávnění

Pokud chcete vytvořit, změnit nebo odstranit zásady zabezpečení, budete muset použít oprávnění ALTER ANY SECURITY POLICY . Důvodem je, že když vytváříte nebo rušíte zásady zabezpečení, vyžaduje oprávnění ALTER pro schéma.

Kromě toho existují další oprávnění požadovaná pro každý predikát, který byste přidali:

• Oprávnění SELECT a REFERENCES pro vloženou funkci s hodnotou tabulky, která se používá jako predikát.

• ODKAZY oprávnění k tabulce, na kterou cílíte, aby byla svázaná se zásadou.

• REFERENCE oprávnění ke každému sloupci z cílové tabulky použité jako argumenty.

Jakmile nastavíte zásady zabezpečení, budou platit pro všechny uživatele (včetně uživatelů dbo v databázi), i když uživatelé DBO můžou měnit nebo odstraňovat zásady zabezpečení, jejich změny zásad zabezpečení je možné auditovat. Pokud máte zvláštní okolnosti, kdy vysoce privilegovaní uživatelé, jako je správce systému nebo db_owner, potřebujete zobrazit všechny řádky pro řešení potíží nebo ověření dat, budete muset zásady zabezpečení zapsat, aby to bylo možné.

Pokud jste vytvořili zásadu zabezpečení, ve SCHEMABINDING = OFFkteré se má dotazovat na cílovou tabulku, musí mít uživatel oprávnění SELECT nebo EXECUTE pro funkci predikátu. Potřebují také oprávnění k jakýmkoli dalším tabulkám, zobrazením nebo funkcím používaným v rámci predikátové funkce. Pokud se vytvoří zásada zabezpečení s SCHEMABINDING = ON (výchozí), tyto kontroly oprávnění se při dotazování na cílovou tabulku uživatelům nepovolí.

Osvědčené postupy

Při implementaci zabezpečení na úrovni řádků je potřeba vzít v úvahu některé osvědčené postupy. Pro objekty RLS doporučujeme vytvořit samostatné schéma. Objekty RLS v tomto kontextu by byly predikátové funkce a zásady zabezpečení. Proč je to osvědčený postup? Pomáhá oddělit oprávnění vyžadovaná u těchto speciálních objektů od cílových tabulek. Kromě toho může být v databázích s více tenanty potřeba oddělení různých zásad a predikátových funkcí. Není to však standard pro každý případ.

Dalším osvědčeným postupem, který je třeba mít na paměti, je, že oprávnění ALTER ANY SECURITY POLICY by mělo být určeno pouze pro vysoce privilegované uživatele (například správce zásad zabezpečení). Správce zásad zabezpečení by neměl u tabulek, které chrání, vyžadovat oprávnění SELECT .

Abyste se vyhnuli potenciálním chybám za běhu, měli byste vzít v úvahu převody typů v predikátech funkcí, které píšete. Měli byste se také pokusit vyhnout rekurzi v predikátových funkcích. Důvodem je vyhnout se snížení výkonu. I když se optimalizátor dotazů pokusí zjistit přímé rekurze, neexistuje žádná záruka nalezení nepřímých rekurzí. Při nepřímé rekurzi znamenáme, že druhá funkce volá predikátovou funkci.

Doporučuje se také zabránit použití nadměrných spojení tabulek v predikátových funkcích. Tím se maximalizuje výkon.

Obecně řečeno, pokud jde o logiku predikátů, měli byste se pokusit vyhnout logikě, která závisí na možnostech SET specifických pro relaci. I když je to velmi nepravděpodobné, že by se používaly v praktických aplikacích, predikát funkce, jejichž logika závisí na určitých možnostech SET specifických pro relaci, může únik informací v případě, že uživatelé mohou provádět libovolné dotazy. Například predikátová funkce, která implicitně převede řetězec na datetime , může filtrovat různé řádky na základě možnosti SET DATEFORMAT pro aktuální relaci.