Zabezpečení na úrovni řádků v datových skladech Fabric
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 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. Každá tabulka musí mít vlastní zabezpečení na úrovni řádků definované samostatně. Uživatelé, kteří se dotazují na tabulky bez zásad zabezpečení na úrovni řádků, zobrazí nefiltrovaná data.
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_ownerrole 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,UPDATEaDELETEoperace. Zahrnutí situací, kdy se vyfiltrují všechny řádky. Aplikace můžeINSERTřá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í:
SELECTaREFERENCESoprávnění k funkci, která se používá jako predikát.REFERENCESoprávnění k cílové tabulce, která je svázaná se zásadou.REFERENCESoprá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ávce, č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 tak, aby to umožňovaly.
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
Pokud chcete upravit funkci zabezpečení na úrovni řádků, musíte nejprve odstranit zásady zabezpečení. V následujícím skriptu před SalesFilter vydáním ALTER FUNCTION příkazu Security.tvf_securitypredicatepro . Pak zásadu SalesFilterznovu vytvoříme .
-- Drop policy so we can change the predicate function.
DROP SECURITY POLICY SalesFilter;
GO
-- Alter the function for the SalesRep evaluation
ALTER 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() = 'president@contoso.com';
GO
-- Re-create a Security Policy
CREATE SECURITY POLICY SalesFilter
ADD FILTER PREDICATE Security.tvf_securitypredicate(SalesRep)
ON sales.Orders
WITH (STATE = ON);
GO