Jaa

Rivitason suojaus Fabric-tietovarastossa

  • Artikkeli

Koskee:✅ SQL-analytiikan päätepiste ja Microsoft Fabric -varasto

Rivitason suojauksen (RLS) avulla voit hallita tietokantataulukon rivien käyttöä ryhmän jäsenyyden tai suorituskontekstin avulla. Voit esimerkiksi varmistaa, että työntekijät käyttävät vain niitä tietorivejä, jotka liittyvät heidän osastoonsa. Toinen esimerkki on asiakkaiden tietojen käytön rajoittaminen vain tietoihin, jotka ovat olennaisia hänen yritykselleen, useassa arkkitehtuurissa. Ominaisuus muistuttaa rivitason suojausta SQL Serverissä.

Rivitason suojaus tietotasolla

Rivitason suojaus yksinkertaistaa sovelluksesi suojauksen suunnittelua ja koodausta. Rivitason suojauksen avulla voit ottaa käyttöön tietorivin käyttöoikeuksia koskevia rajoituksia.

Käyttörajoituksen logiikka on tietokantatasolla, ei yhdelläkään sovellustasolla. Tietokanta käyttää käyttöoikeuksia rajoituksia aina, kun tietojen käyttöä yritetään, mistä tahansa sovelluksesta tai raportointiympäristöstä, mukaan lukien Power BI. Tämä tekee suojausjärjestelmästäsi luotettavamman ja luotettavamman pienentämällä suojausjärjestelmäsi pinta-alaa. Rivitason suojaus koskee vain Fabricin Warehouse- tai SQL-analytiikan päätepisteisiin kohdistettuja kyselyjä. Direct Lake -tilassa olevan varaston Power BI -kyselyt palaavat DirectQuery-tilaan rivitason suojauksen noudattamiseksi.

Rajoita tiettyjen rivien käyttöä tietyille käyttäjille

Ota rivitason suojaus käyttöön käyttämällä CREATE SECURITY POLICY Transact-SQL -lauseketta ja predikaatteja, jotka on luotu rivin sisäisenä taulukkoarvoisena funktiona.

Rivitason suojausta käytetään jaettuun varastoon tai lakehouseen, koska pohjana oleva tietolähde ei ole muuttunut.

Predikaattipohjainen rivitason suojaus

Fabric-tietovaraston rivitason suojaus tukee predikaattipohjaista suojausta. Suodatinpredikaatit suodattavat automaattisesti lukutoimintojen käytettävissä olevat rivit.

Taulukon rivitason tietojen käyttöä rajoittaa suojauspredikaatti, joka on määritetty sisäiseksi taulukkoarvoiseksi funktioksi. Tämän jälkeen suojauskäytäntö käynnistää ja pakottaa funktion. Suodatinpredikaattien osalta sovellus ei tiedä riveistä, jotka on suodatettu tulosjoukosta. Jos kaikki rivit suodatetaan, palautetaan tyhjäarvoinen joukko.

Suodatinpredikaatteja käytetään, kun tietoja luetaan perustaulukosta. Ne vaikuttavat kaikkiin get-toimintoihin: SELECT, DELETEja UPDATE. Jokaisella taulukolla on oltava oma rivitason suojauksensa määritettynä erikseen. Käyttäjät, jotka tekevät kyselyjä taulukoista ilman rivitason suojauskäytäntöä, tarkastelevat suodattamattomia tietoja.

Käyttäjät eivät voi valita tai poistaa suodatettuja rivejä. Käyttäjä ei voi päivittää suodatettuja rivejä. Rivit voi kuitenkin päivittää siten, että ne suodatetaan jälkeenpäin.

Suodatinpredikaatti- ja suojauskäytännöt toimivat seuraavasti:

  • Voit määrittää predikaattifunktion, joka liittyy toiseen taulukkoon ja/tai käynnistää funktion. Jos suojauskäytäntö luodaan -toiminnolla (oletus), liitosta tai funktiota voi käyttää kyselyssä ja se toimii odotetulla SCHEMABINDING = ON tavalla ilman muita käyttöoikeustarkistuksia.

  • Voit tehdä kyselyn taulukolle, jolle on määritetty suojauspredikaatti, mutta joka on poistettu käytöstä. Tämä ei vaikuta mihinkään suodatettuihin tai estettyihin riveihin.

  • Jos dbo-käyttäjä, roolin jäsen db_owner tai taulukon omistaja tekee kyselyn taulukkoon, jossa on määritetty ja käytössä oleva suojauskäytäntö, rivit suodatetaan tai estetään suojauskäytännön määrittämän mukaisesti.

  • Jos yrität muuttaa skeemaan sidotun suojauskäytännön avulla sidotun taulukon rakennetta, tämä aiheuttaa virheen. Sarakkeita, joihin predikaatti ei viittaa, voidaan kuitenkin muuttaa.

  • Jos yritetään lisätä predikaatti taulukkoon, jolla on jo määritetty predikaatti määritetylle toiminnolle, tuloksena on virhe. Näin tapahtuu riippumatta siitä, onko predikaatti käytössä vai ei.

  • Jos yritetään muokata funktiota, jota käytetään predikaattina taulukolle, joka sijaitsee skeemaan sidotussa suojauskäytännössä, tuloksena on virhe.

  • Useiden aktiivisten suojauskäytäntöjen määrittäminen, jotka sisältävät ei-päällekkäisiä predikaatteja, onnistuu.

Suodatinpredikaattien toiminta on seuraavanlainen:

  • Määritä suojauskäytäntö, joka suodattaa taulukon rivit. Sovellus ei tiedä mitään riveistä, jotka on suodatettu -, UPDATE- ja DELETE -toiminnoilleSELECT. Mukaan lukien tilanteet, joissa kaikki rivit on suodatettu pois. Sovellus voi INSERT rivejä, vaikka ne suodatetaan minkä tahansa muun toiminnon aikana.

Oikeudet

Suojauskäytäntöjen luominen, muuttaminen tai poistaminen edellyttää ALTER ANY SECURITY POLICY käyttöoikeutta. Suojauskäytännön luominen tai pudottaminen edellyttää ALTER rakenteen käyttöoikeutta.

Lisäksi seuraavat käyttöoikeudet tarvitaan kullekin lisättävälle predikaatille:

  • SELECT ja REFERENCES käyttöoikeudet funktiolle, jota käytetään predikaattina.

  • REFERENCES käyttöoikeus siihen kohdetaulukkoon, joka on sidottu käytäntöön.

  • REFERENCES oikeus argumentteina käytetyn kohdetaulukon jokaiseen sarakkeeseen.

Suojauskäytännöt koskevat kaikkia käyttäjiä, myös tietokannan dbo-käyttäjiä. Dbo-käyttäjät voivat muuttaa tai pudottaa suojauskäytäntöjä, mutta heidän muutoksiaan suojauskäytäntöihin voidaan valvoa. Jos roolien, kuten järjestelmänvalvojan, jäsenen tai osallistujan, täytyy nähdä kaikki rivit tietojen vianmääritystä tai vahvistamista varten, suojauskäytäntö on kirjoitettava, jotta se voidaan sallia.

Jos -sovelluksen avulla luodaan suojauskäytäntö, jotta kohdetaulukosta voidaan tehdä kysely, käyttäjillä SCHEMABINDING = OFFon oltava SELECT predikaattifunktiolla tai EXECUTE -käyttöoikeus sekä predikaattifunktiossa käytetyt lisätaulukot, näkymät tai funktiot. Jos suojauskäytäntö luodaan kohteella SCHEMABINDING = ON (oletus), nämä käyttöoikeustarkistukset ohitetaan, kun käyttäjät tekevät kyselyn kohdetaulukkoon.

Huomioon otettavat suojaustoimet: sivukanavan hyökkäykset

Harkitse ja valmistaudu seuraaviin kahteen skenaarioon.

Haitallisten suojauskäytäntöjen hallinta

On tärkeää huomioida, että pahantahtoinen suojauskäytäntöjen hallinta, jolla on riittävät oikeudet luoda suojauskäytäntö arkaluontoisen sarakkeen päälle ja jolla on oikeus luoda tai muuttaa rivin sisäisesti arvoisia funktioita, voi tehdä yhteistyötä toisen käyttäjän kanssa, jolla on valikoituja taulukon käyttöoikeuksia tietojen täyttämiseksi luomalla haitallisesti tekstiin sidotut taulukkoarvoiset funktiot, jotka on suunniteltu käyttämään sivukanavan hyökkäyksiä tietojen päättelemiseen. Tällaiset hyökkäykset edellyttäisivät yhteistoimintaa (tai liiallisia käyttöoikeuksia, jotka on myönnetty haitalliselle käyttäjälle) ja edellyttäisivät todennäköisesti useita toistoja käytännön muokkaamiseen (predikaatin poistamiseen rakenteen sidonnan rikkomista varten), sisäisen taulukkoarvoisen funktion muokkaamiseen ja valittujen lausekkeiden toistuvaan suorittamiseen kohdetaulukossa. Suosittelemme, että rajoitat käyttöoikeuksia tarpeen mukaan ja valvot epäilyttävää toimintaa. Toimia, kuten jatkuvasti muuttuvia käytäntöjä ja rivitason suojaukseen liittyviä sisäiset taulukkoarvoiset funktiot, on valvottava.

Huolellisesti muodostetut kyselyt

Tietovuotoja voi aiheuttaa käyttämällä huolellisesti laadittuja kyselyitä, jotka käyttävät virheitä tietojen täyttämiseen. Esimerkiksi pahantahtoinen käyttäjä saisi tietää, SELECT 1/(SALARY-100000) FROM PAYROLL WHERE NAME='John Doe'; että John Doen palkka on tasan 100 000 $. Vaikka käytössä on suojauspredikaatti, joka estää pahantahtoista käyttäjää kyselemästä suoraan muiden henkilöiden palkkaa, käyttäjä voi selvittää, milloin kysely palauttaa poikkeuksen nollalla.

Esimerkit

Voimme esitellä rivitason suojauksen Warehousen ja SQL-analytiikan päätepisteen Microsoft Fabricissa.

Seuraava esimerkki luo mallitaulukoita, jotka toimivat Warehousen kanssa Fabricissa, mutta SQL-analytiikan päätepisteessä käytetään olemassa olevia taulukoita. SQL-analytiikan päätepisteessä et voi , CREATE TABLEmutta voit CREATE SCHEMA, CREATE FUNCTIONja CREATE SECURITY POLICY.

Tässä esimerkissä luodaan ensin rakenne sales, taulukko 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');

Luo rakenne Security , funktio Security.tvf_securitypredicateja suojauskäytäntö SalesFilter.

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

Jos haluat muokata rivitason suojaustoimintoa, sinun on ensin poistettava suojauskäytäntö. Seuraavassa komentosarjassa pudotamme käytännön SalesFilter ennen lausekkeen ALTER FUNCTION antamista ön Security.tvf_securitypredicate. Sitten luomme käytännön SalesFilteruudelleen.

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

Seuraava vaihe

Rivitason suojauksen käyttöönotto Fabric-tietovarastoissa

Liittyvä sisältö