Zabezpečení na úrovni řádků v datových skladech Fabric

  • Článek

Platí pro: Koncový bod sql Analytics a sklad v Microsoft Fabric

Zabezpečení na úrovni řádků (RLS) umožňuje řídit přístup k řádkům v tabulce databáze pomocí členství ve skupině nebo kontextu spuštění. Můžete například zajistit, aby pracovníci přistupovali pouze k těmto datovým řádkům, které jsou relevantní pro jejich oddělení. Dalším příkladem je omezení přístupu zákazníků k datům relevantním pro jejich společnost v architektuře s více tenanty. Tato funkce se podobá zabezpečení na úrovni řádků na SQL Serveru.

Zabezpečení na úrovni řádků na úrovni dat

Zabezpečení na úrovni řádků zjednodušuje návrh a kódování zabezpečení ve vaší aplikaci. Zabezpečení na úrovni řádků pomáhá implementovat omezení přístupu k datovým řádkům.

Logika omezení přístupu je v databázové vrstvě, ne v žádné jedné aplikační vrstvě. Databáze použije omezení přístupu při každém pokusu o přístup k datům z libovolné aplikace nebo platformy pro vytváření sestav, včetně Power BI. Díky tomu je systém zabezpečení spolehlivější a robustnější tím, že sníží plochu systému zabezpečení. Zabezpečení na úrovni řádků se vztahuje pouze na dotazy na koncový bod služby Warehouse nebo SQL Analytics v prostředcích infrastruktury. Dotazy Power BI na sklad v režimu Direct Lake se vrátí do režimu Direct Query, aby se dodržovaly zabezpečení na úrovni řádků.

Omezení přístupu k určitým řádkům určitým uživatelům

Implementujte zabezpečení na úrovni řádků pomocí příkazu CREATE SECURITY POLICY Transact-SQL a predikáty vytvořené jako vložené funkce hodnotné tabulkou.

Zabezpečení na úrovni řádků se použije u sdíleného skladu nebo u jezera, protože se podkladový zdroj dat nezměnil.

Zabezpečení na úrovni řádků založené na predikátech

Zabezpečení na úrovni řádků ve službě Fabric Synapse Data Warehouse podporuje zabezpečení založené na predikátech. Predikáty filtru bezobslužně filtruje řádky dostupné pro operace čtení.

Přístup k datům na úrovni řádků v tabulce je omezený predikátem zabezpečení definovaným jako vložená funkce s hodnotou tabulky. Funkce se pak vyvolá a vynucuje zásadami zabezpečení. U predikátů filtru aplikace neví o řádcích filtrovaných ze sady výsledků. Pokud jsou všechny řádky filtrované, vrátí se sada null.

Predikáty filtru se použijí při čtení dat ze základní tabulky. Ovlivňují všechny operace získání: SELECT, DELETEa UPDATE. Uživatelé nemůžou vybrat nebo odstranit filtrované řádky. Uživatel nemůže aktualizovat řádky filtrované. Je ale možné aktualizovat řádky takovým způsobem, aby se následně vyfiltrovaly.

Predikát filtru a zásady zabezpečení mají následující chování:

  • Můžete definovat predikátovou funkci, která se spojí s jinou tabulkou nebo vyvolá funkci. Pokud se zásady zabezpečení vytvoří pomocí SCHEMABINDING = ON (výchozí), pak je spojení nebo funkce přístupné z dotazu a funguje podle očekávání bez jakýchkoli dalších kontrol oprávnění.

  • Můžete vydat dotaz na tabulku, která má definovaný predikát zabezpečení, ale zakázaný. Všechny řádky filtrované nebo blokované nejsou ovlivněny.

  • Pokud uživatel dbo, člen db_owner role nebo vlastník tabulky dotazuje tabulku s definovanou a povolenou zásadou zabezpečení, řádky se filtrují nebo blokují podle definice zásad zabezpečení.

  • Pokusy o změnu schématu tabulky vázané zásadou zabezpečení vázané na schéma způsobí chybu. Sloupce, na které predikát neodkazuje, se ale dají změnit.

  • Pokusy o přidání predikátu v tabulce, která už má definovaný predikát pro zadanou operaci, způsobí chybu. K tomu dojde bez ohledu na to, jestli je predikát povolený nebo ne.

  • Pokusy o úpravu funkce, která se používá jako predikát v tabulce v rámci zásad zabezpečení vázaného na schéma, způsobí chybu.

  • Definování několika aktivních zásad zabezpečení, které obsahují nepřekrývající se predikáty, je úspěšné.

Predikáty filtru mají následující chování:

  • Definujte zásady zabezpečení, které filtruje řádky tabulky. Aplikace nezná žádné řádky, které jsou filtrovány pro SELECT, UPDATEa DELETE operace. Zahrnutí situací, kdy se vyfiltrují všechny řádky. Aplikace může INSERT řádky filtrovat i v případě, že budou filtrovány během jakékoli jiné operace.

Oprávnění

Vytvoření, změna nebo vyřazení zásad zabezpečení vyžaduje ALTER ANY SECURITY POLICY oprávnění. Vytvoření nebo vyřazení zásad zabezpečení vyžaduje ALTER oprávnění ke schématu.

Kromě toho jsou pro každý přidaný predikát vyžadována následující oprávnění:

  • SELECT a REFERENCES oprávnění k funkci, která se používá jako predikát.

  • REFERENCES oprávnění k cílové tabulce, která je svázaná se zásadou.

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

Zásady zabezpečení platí pro všechny uživatele, včetně uživatelů dbo v databázi. Uživatelé Dbo můžou měnit nebo odstraňovat zásady zabezpečení, ale jejich změny zásad zabezpečení je možné auditovat. Pokud členové rolí, jako je Správa istrator, Člen nebo Přispěvatel, potřebují zobrazit všechny řádky pro řešení potíží nebo ověření dat, musí být zásady zabezpečení zapsány, aby to bylo možné.

Pokud se vytvoří zásada zabezpečení s dotazem SCHEMABINDING = OFFna cílovou tabulku, musí mít SELECT uživatelé k predikátové funkci nebo EXECUTE oprávnění a všechny další tabulky, zobrazení nebo funkce používané v predikátové funkci. 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í.

Aspekty zabezpečení: Útoky na boční kanál

Zvažte a připravte se na následující dva scénáře.

Správce zásad zabezpečení se zlými úmysly

Je důležité si uvědomit, že správce zásad zabezpečení se zlými úmysly s dostatečnými oprávněními k vytvoření zásady zabezpečení nad citlivým sloupcem a s oprávněním vytvářet nebo měnit vložené funkce hodnotné tabulky, může sloučit s jiným uživatelem, který má oprávnění k výběru oprávnění k tabulce, aby provedl exfiltraci dat škodlivým vytvořením vložených funkcí hodnot tabulky navržených tak, aby používal útoky na vedlejší kanál k odvození dat. Takové útoky by vyžadovaly kolaci (nebo nadměrná oprávnění udělená uživateli se zlými úmysly) a pravděpodobně by vyžadovaly několik iterací úprav zásad (vyžadujících oprávnění k odebrání predikátu, aby bylo možné přerušit vazbu schématu), úpravu vložených funkcí s hodnotami tabulky a opakované spuštění výběrových příkazů v cílové tabulce. Doporučujeme podle potřeby omezit oprávnění a monitorovat případné podezřelé aktivity. Je třeba monitorovat aktivity, jako jsou neustálé změny zásad a vložené funkce hodnotné tabulkou související se zabezpečením na úrovni řádků.

Pečlivě vytvořené dotazy

Únik informací je možné způsobit pomocí pečlivě vytvořených dotazů, které používají chyby k exfiltraci dat. Dejte například uživateli se zlými úmysly vědět, SELECT 1/(SALARY-100000) FROM PAYROLL WHERE NAME='John Doe'; že plat Johna Doea je přesně 100 000 Kč. I když existuje bezpečnostní predikát, který brání škodlivému uživateli v přímém dotazování platu jiných lidí, může uživatel určit, kdy dotaz vrátí výjimku dělicí nulou.

Příklady

Můžeme si předvést koncový bod zabezpečení na úrovni řádků a koncový bod analýzy SQL v Microsoft Fabric.

Následující příklad vytvoří ukázkové tabulky, které budou fungovat se skladem v prostředcích infrastruktury, ale v koncovém bodu analýzy SQL používají existující tabulky. V koncovém bodu analýzy SQL nemůžete CREATE TABLE, ale můžete CREATE SCHEMACREATE FUNCTION, a CREATE SECURITY POLICY.

V tomto příkladu nejprve vytvořte schéma sales, tabulku sales.Orders.

CREATE SCHEMA sales;
GO

-- Create a table to store sales data
CREATE TABLE sales.Orders (
    SaleID INT,
    SalesRep VARCHAR(100),
    ProductName VARCHAR(50),
    SaleAmount DECIMAL(10, 2),
    SaleDate DATE
);

-- Insert sample data
INSERT INTO sales.Orders (SaleID, SalesRep, ProductName, SaleAmount, SaleDate)
VALUES
    (1, 'Sales1@contoso.com', 'Smartphone', 500.00, '2023-08-01'),
    (2, 'Sales2@contoso.com', 'Laptop', 1000.00, '2023-08-02'),
    (3, 'Sales1@contoso.com', 'Headphones', 120.00, '2023-08-03'),
    (4, 'Sales2@contoso.com', 'Tablet', 800.00, '2023-08-04'),
    (5, 'Sales1@contoso.com', 'Smartwatch', 300.00, '2023-08-05'),
    (6, 'Sales2@contoso.com', 'Gaming Console', 400.00, '2023-08-06'),
    (7, 'Sales1@contoso.com', 'TV', 700.00, '2023-08-07'),
    (8, 'Sales2@contoso.com', 'Wireless Earbuds', 150.00, '2023-08-08'),
    (9, 'Sales1@contoso.com', 'Fitness Tracker', 80.00, '2023-08-09'),
    (10, 'Sales2@contoso.com', 'Camera', 600.00, '2023-08-10');

Vytvoření schématu Security , funkce Security.tvf_securitypredicatea zásad SalesFilterzabezpečení

-- Creating schema for Security
CREATE SCHEMA Security;
GO
 
-- Creating a function for the SalesRep evaluation
CREATE FUNCTION Security.tvf_securitypredicate(@SalesRep AS nvarchar(50))
    RETURNS TABLE
WITH SCHEMABINDING
AS
    RETURN SELECT 1 AS tvf_securitypredicate_result
WHERE @SalesRep = USER_NAME() OR USER_NAME() = 'manager@contoso.com';
GO
 
-- Using the function to create a Security Policy
CREATE SECURITY POLICY SalesFilter
ADD FILTER PREDICATE Security.tvf_securitypredicate(SalesRep)
ON sales.Orders
WITH (STATE = ON);
GO

Související obsah

Další krok

Implementace zabezpečení na úrovni řádků v prostředcích infrastruktury Skladování Dat