Zdieľať cez

Zabezpečenie na úrovni riadkov v sklade údajov služby Fabric

  • Článok

Vzťahuje sa na:✅ koncový bod analýzy SQL a sklad v službe Microsoft Fabric

Zabezpečenie na úrovni riadkov umožňuje použiť členstvo v skupine alebo kontext vykonávania na ovládanie prístupu k riadkom v tabuľke databázy. Môžete napríklad zabezpečiť, aby pracovníci získali prístup len k tým údajovým riadkom, ktoré sú relevantné pre ich oddelenie. Ďalším príkladom je obmedzenie prístupu zákazníkov k údajom len na údaje relevantné pre ich spoločnosť v multitenantnej architektúre. Táto funkcia je podobná ako zabezpečenie na úrovni riadkov na SQL Serveri.

Zabezpečenie na úrovni riadkov na úrovni údajov

Zabezpečenie na úrovni riadkov zjednodušuje návrh a kódovanie zabezpečenia vo vašej aplikácii. Zabezpečenie na úrovni riadkov pomáha implementovať obmedzenia prístupu k riadkom údajov.

Logika obmedzenia prístupu sa nachádza v databázovej úrovni, nie v žiadnej úrovni jednej aplikácie. Databáza uplatňuje obmedzenia prístupu pri každom pokuse o prístup k údajom z akejkoľvek aplikácie alebo platformy vytvárania zostáv vrátane služby Power BI. Vďaka tomu je váš bezpečnostný systém spoľahlivejší a robustnejší zredukovaním povrchu bezpečnostného systému. Zabezpečenie na úrovni riadkov sa vzťahuje len na dotazy na koncovom bode analýzy Warehouse alebo SQL v službe Fabric. Dotazy Power BI v sklade v režime Direct Lake sa vrátia späť do režimu Direct Query, aby dodržiavali zabezpečenie na úrovni riadkov.

Obmedzenie prístupu k určitým riadkom na určitých používateľov

Implementovať zabezpečenie na úrovni riadkov pomocou príkazu CREATE SECURITY POLICY Transact-SQL a predikátov vytvorených ako funkcie s vnorenou tabuľkou.

Zabezpečenie na úrovni riadkov sa použije na zdieľaný sklad alebo lakehouse, pretože základný zdroj údajov sa nezmenil.

Zabezpečenie na úrovni riadkov na úrovni predikátu

Zabezpečenie na úrovni riadkov v sklade údajov služby Fabric podporuje zabezpečenie na základe prediktov. Filtrovať predikáty ticho filtrovať riadky k dispozícii na čítanie operácií.

Prístup k údajom na úrovni riadkov v tabuľke je obmedzený predikátom zabezpečenia definovaným ako vnorená funkcia s hodnotou tabuľky. Funkcia sa potom vyvolá a vynucuje politikou zabezpečenia. V prípade predikátov filtrov aplikácia nevie o riadkoch, ktoré sú filtrované z množiny výsledkov. Ak sú všetky riadky filtrované, vráti sa množina null.

Predikáty filtrov sa používajú pri čítaní údajov zo základnej tabuľky. Ovplyvňujú všetky operácie získania: SELECT, DELETE, a UPDATE. Každá tabuľka musí mať vlastné zabezpečenie na úrovni riadkov definované samostatne. Používatelia, ktorí dotazujú tabuľky bez politiky zabezpečenia na úrovni riadkov, zobrazia nefiltrované údaje.

Používatelia nemôžu vybrať ani odstrániť riadky, ktoré sú filtrované. Používateľ nemôže aktualizovať riadky, ktoré sú filtrované. Riadky je však možné aktualizovať tak, aby sa potom filtrovať.

Predikát filtra a politiky zabezpečenia sa správajú takto:

  • Môžete definovať funkciu predikátu, ktorá sa spojí s inou tabuľkou a/alebo vyvolá funkciu. Ak je politika zabezpečenia vytvorená pomocou SCHEMABINDING = ON funkcie (predvolené), pripojenie alebo funkcia je dostupná z dotazu a funguje podľa očakávania bez akýchkoľvek ďalších kontrol povolení.

  • Môžete vytvoriť dotaz na tabuľku, ktorá má definovaný, ale zakázaný predikát zabezpečenia. Všetky riadky, ktoré sú filtrované alebo blokované, nie sú ovplyvnené.

  • Ak používateľ služby dbo, člen db_owner roly alebo vlastník tabuľky dotazuje tabuľku, ktorá má definovanú a povolenú politiku zabezpečenia, riadky sa filtrujú alebo blokujú podľa definície politiky zabezpečenia.

  • Pokusy o zmenu schémy tabuľky viazanej politikou zabezpečenia viazanou na schému budú mať za následok chybu. Stĺpce, na ktoré sa nevzťahuje predikát, sa však môžu zmeniť.

  • Pokusy o pridanie predikátu do tabuľky, ktorá už má definovanú pre zadanú operáciu, majú za následok chybu. To sa stane, či je predikát povolený alebo nie.

  • Pokusy o úpravu funkcie, ktorá sa používa ako predikát v tabuľke v rámci politiky zabezpečenia viazaného na schému, budú mať za následok chybu.

  • Definovanie viacerých aktívnych politík zabezpečenia, ktoré obsahujú neprekrytie predikátov, je úspešné.

Predikáty filtrov majú nasledujúce správanie:

  • Definujte politiku zabezpečenia, ktorá filtruje riadky tabuľky. Aplikácia nevie o žiadnych riadkoch, ktoré sú filtrované pre SELECToperácie , UPDATEa DELETE . Zahrnutie situácií, v ktorých sú všetky riadky odfiltrované. Aplikácia môže INSERT riadky použiť, dokonca aj vtedy, ak budú filtrované počas akejkoľvek inej operácie.

Povolenia

Vytváranie, zmena alebo zrušenie politík zabezpečenia vyžaduje ALTER ANY SECURITY POLICY povolenie. Vytvorenie alebo zvrhnutie politiky zabezpečenia vyžaduje ALTER povolenie na schému.

Okrem toho sa pre každý pridaný predikát vyžadujú nasledujúce povolenia:

  • SELECT a REFERENCES povolenia týkajúce sa funkcie, ktorá sa používa ako predikát.

  • REFERENCES povolenia pre cieľovú tabuľku, ktorá je viazaná na politiku.

  • REFERENCES povolenie pre každý stĺpec z cieľovej tabuľky, ktorá sa používa ako argumenty.

Politiky zabezpečenia sa vzťahujú na všetkých používateľov vrátane používateľov platformy dbo v databáze. Používatelia služby Dbo môžu meniť alebo zrušiť politiky zabezpečenia, ich zmeny politík zabezpečenia však môžu byť auditované. Ak členovia rolí, ako napríklad správca, člen alebo prispievateľ, potrebujú zobraziť všetky riadky na riešenie problémov s údajmi alebo ich overenie, musí byť zapísané politika zabezpečenia, aby to bolo možné.

Ak sa pomocou politiky zabezpečenia vytvorí SCHEMABINDING = OFFdotaz na cieľovú tabuľku, používatelia musia mať SELECT povolenie alebo EXECUTE pre funkciu predikátu a všetky ďalšie tabuľky, zobrazenia alebo funkcie použité v rámci funkcie predikátu. Ak je politika zabezpečenia vytvorená pomocou SCHEMABINDING = ON funkcie (predvolené), tieto kontroly povolení sa obídu, keď používatelia dotazujú cieľovú tabuľku.

Dôležité informácie týkajúce sa zabezpečenia: útoky na bočnom kanáli

Zvážte a pripravte nasledujúce dva scenáre.

Správca politiky škodlivého zabezpečenia

Je dôležité poznamenať, že škodlivý manažér politiky zabezpečenia s dostatočnými povoleniami na vytvorenie politiky zabezpečenia nad citlivým stĺpcom a povolenie na vytváranie alebo zmenu funkcií s vnorenými tabuľkami sa môže dohadovať s iným používateľom, ktorý má vybrané povolenia pre tabuľku na vykonávanie exfiltrácie údajov škodlivým spôsobom vytvorením funkcií s hodnotami vnorených tabuliek určených na použitie útokov bočného kanála na odvodenie údajov. Takéto útoky by si vyžadovali tajnú dohodu (alebo nadmerné povolenia udelené škodlivému používateľovi) a pravdepodobne by vyžadovali niekoľko iterácií úpravy politiky (vyžadujúc povolenie na odstránenie predikátu, aby sa prerušila väzba schémy), úprava funkcií vnorenej tabuľky a opakované spúšťanie vybraných príkazov v cieľovej tabuľke. Odporúčame obmedziť povolenia podľa potreby a monitorovať akúkoľvek podozrivú aktivitu. Aktivity, ako sú neustále sa meniace politiky a vnorené funkcie s hodnotami z tabuliek súvisiace so zabezpečením na úrovni riadkov, by sa mali monitorovať.

Starostlivo vytvorené dotazy

Je možné spôsobiť únik informácií pomocou starostlivo vytvorených dotazov, ktoré používajú chyby na exfiltrovanie údajov. Napríklad SELECT 1/(SALARY-100000) FROM PAYROLL WHERE NAME='John Doe'; by zlomyseľný používateľ vedel, že plat Johna Doea je presne 100 000 dolárov. Napriek tomu, že existuje predikát zabezpečenia, ktorý má zabrániť škodlivému používateľovi priamo dotazovať plat iných ľudí, používateľ môže určiť, kedy dotaz vráti výnimku delenia nulou.

Príklady

V službe Microsoft Fabric môžeme preukázať sklad zabezpečenia na úrovni riadkov a koncový bod analýzy SQL.

V nasledujúcom príklade sa vytvoria vzorové tabuľky, ktoré budú fungovať so skladom v službe Fabric, ale v koncovom bode analýzy SQL sa použijú existujúce tabuľky. V koncovom bode analýzy SQL nemôžete CREATE TABLE, ale môžete CREATE SCHEMA, CREATE FUNCTIONa CREATE SECURITY POLICY.

V tomto príklade najprv vytvorte schému sales, tabuľku 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');

Vytvorte schému Security , funkciu Security.tvf_securitypredicatea politiku SalesFilterzabezpečenia .

-- 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

Ak chcete upraviť funkciu zabezpečenia na úrovni riadkov, najprv musíte politiku zabezpečenia zrušiť. V nasledujúcom skripte politiku SalesFilter pred vydaním ALTER FUNCTION príkazu Security.tvf_securitypredicatedo . Potom znova vytvoríme politiku SalesFilter.

-- 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

Ďalší krok

Implementácia zabezpečenia na úrovni riadkov v sklade údajov služby Fabric

Súvisiaci obsah