Sikkerhed på rækkeniveau i Fabric-datawarehousing

  • Artikel

Gælder for: SQL Analytics-slutpunkt og warehouse i Microsoft Fabric

Sikkerhed på rækkeniveau giver dig mulighed for at bruge gruppemedlemskab eller udførelseskontekst til at styre adgangen til rækker i en databasetabel. Du kan f.eks. sikre, at arbejdere kun får adgang til de datarækker, der er relevante for deres afdeling. Et andet eksempel er at begrænse kundernes dataadgang til de data, der er relevante for deres virksomhed i en multitenantarkitektur. Funktionen svarer til sikkerhed på rækkeniveau i SQL Server.

Sikkerhed på rækkeniveau på dataniveau

Sikkerhed på rækkeniveau forenkler sikkerhedens design og kodning i dit program. Sikkerhed på rækkeniveau hjælper dig med at implementere begrænsninger for adgang til datarækker.

Logikken for adgangsbegrænsning findes på databaseniveauet og ikke på et enkelt programniveau. Databasen anvender adgangsbegrænsningerne, hver gang dataadgang forsøges, fra alle programmer eller rapporteringsplatforme, herunder Power BI. Dette gør dit sikkerhedssystem mere pålideligt og robust ved at reducere overfladeområdet i dit sikkerhedssystem. Sikkerhed på rækkeniveau gælder kun for forespørgsler på et lager- eller SQL-analyseslutpunkt i Fabric. Power BI-forespørgsler på et lager i Direct Lake-tilstand vender tilbage til Direct Query-tilstand for at overholde sikkerhed på rækkeniveau.

Begræns adgang til bestemte rækker til bestemte brugere

Implementer sikkerhed på rækkeniveau ved hjælp af sætningen CREATE SECURITY POLICY Transact-SQL, og prædikater, der er oprettet som indbyggede tabelværdifunktioner.

Sikkerhed på rækkeniveau anvendes på delt lager eller lakehouse, fordi den underliggende datakilde ikke er ændret.

Prædikatbaseret sikkerhed på rækkeniveau

Sikkerhed på rækkeniveau i Fabric Synapse Data Warehouse understøtter prædikatbaseret sikkerhed. Filtrer prædikater filtrerer automatisk de rækker, der er tilgængelige for læsehandlinger.

Adgang til data på rækkeniveau i en tabel er begrænset af et sikkerheds prædikat, der er defineret som en indbygget tabelværdifunktion. Funktionen aktiveres derefter og gennemtvinges af en sikkerhedspolitik. For filter prædikater er programmet ikke opmærksom på rækker, der er filtreret fra resultatsættet. Hvis alle rækker filtreres, returneres der et null-sæt.

Filter prædikater anvendes, mens der læses data fra basistabellen. De påvirker alle hentningshandlinger: SELECT, DELETEog UPDATE. Brugerne kan ikke markere eller slette rækker, der er filtreret. Brugeren kan ikke opdatere rækker, der er filtreret. Men det er muligt at opdatere rækker på en sådan måde, at de filtreres bagefter.

Prædikat- og sikkerhedspolitikker for filtre har følgende funktionsmåde:

  • Du kan definere en prædikatfunktion, der joinforbinder med en anden tabel og/eller aktiverer en funktion. Hvis sikkerhedspolitik oprettes med SCHEMABINDING = ON (standarden), er joinforbindelsen eller funktionen tilgængelig fra forespørgslen og fungerer som forventet uden yderligere kontrol af tilladelser.

  • Du kan udstede en forespørgsel i forhold til en tabel, der har et sikkerhedsforord, der er defineret, men deaktiveret. Alle rækker, der er filtreret eller blokeret, påvirkes ikke.

  • Hvis en dbo-bruger, et medlem af db_owner rollen eller tabelejeren forespørger en tabel, der har en sikkerhedspolitik defineret og aktiveret, filtreres eller blokeres rækkerne som defineret af sikkerhedspolitik.

  • Forsøg på at ændre skemaet for en tabel, der er bundet af en skemabundet sikkerhedspolitik, vil resultere i en fejl. Kolonner, der ikke refereres til af prædikatet, kan dog ændres.

  • Forsøg på at tilføje et prædikat i en tabel, der allerede har en defineret for den angivne handling, resulterer i en fejl. Dette sker, uanset om prædikatet er aktiveret eller ej.

  • Forsøg på at ændre en funktion, der bruges som prædikat i en tabel i en skemabundet sikkerhedspolitik, vil resultere i en fejl.

  • Definition af flere aktive sikkerhedspolitikker, der indeholder prædikater, der ikke overlapper hinanden, lykkes.

Filter prædikater har følgende funktionsmåde:

  • Definer en sikkerhedspolitik, der filtrerer rækkerne i en tabel. Programmet er ikke opmærksom på nogen rækker, der er filtreret efter SELECThandlingerne , UPDATEog DELETE . Herunder situationer, hvor alle rækkerne er filtreret ud. Programmet kan INSERT rækker, selvom de filtreres under en anden handling.

Tilladelser

Oprettelse, ændring eller sletning af sikkerhedspolitikker kræver tilladelse ALTER ANY SECURITY POLICY . Oprettelse eller sletning af en sikkerhedspolitik kræver ALTER tilladelse til skemaet.

Derudover kræves følgende tilladelser for hvert prædikat, der tilføjes:

  • SELECT og REFERENCES tilladelser til den funktion, der bruges som prædikat.

  • REFERENCES tilladelse til den destinationstabel, der bindes til politikken.

  • REFERENCES tilladelse til hver kolonne fra destinationstabellen, der bruges som argumenter.

Sikkerhedspolitikker gælder for alle brugere, herunder dbo-brugere i databasen. Dbo-brugere kan ændre eller slippe sikkerhedspolitikker, men deres ændringer af sikkerhedspolitikker kan overvåges. Hvis medlemmer af roller som Administration istrator, Member eller Contributor skal se alle rækker for at foretage fejlfinding eller validere data, skal sikkerhedspolitik skrives for at tillade det.

Hvis der oprettes en sikkerhedspolitik med SCHEMABINDING = OFF, skal brugerne have SELECT tilladelsen eller EXECUTE for prædikatfunktionen og eventuelle yderligere tabeller, visninger eller funktioner, der bruges i prædikatfunktionen, for at forespørge på destinationstabellen. Hvis der oprettes en sikkerhedspolitik med SCHEMABINDING = ON (standarden), tilsidesættes disse kontrol af tilladelser, når brugerne forespørger måltabellen.

Sikkerhedsovervejelser: angreb på sidekanaler

Overvej og forbered dig på følgende to scenarier.

Styring af skadelig sikkerhedspolitik

Det er vigtigt at bemærke, at en ondsindet sikkerhedspolitikstyring med tilstrækkelige tilladelser til at oprette en sikkerhedspolitik oven på en følsom kolonne og have tilladelse til at oprette eller ændre indbyggede tabelværdifunktioner kan kollidere med en anden bruger, der har valgt tilladelser til en tabel for at udføre dataudfiltrering ved at oprette indbyggede tabelværdifunktioner, der er designet til at bruge sidekanalangreb til at udlede data. Sådanne angreb kræver aftalt spil (eller overdrevne tilladelser til en ondsindet bruger) og kræver sandsynligvis flere gentagelser af at ændre politikken (kræver tilladelse til at fjerne prædikatet for at bryde skemabindingen), ændre de indbyggede tabelværdifunktioner og gentagne gange køre select-sætninger i måltabellen. Vi anbefaler, at du begrænser tilladelser efter behov og overvåger for enhver mistænkelig aktivitet. Aktiviteter, f.eks. konstant ændring af politikker og indbyggede tabelværdifunktioner, der er relateret til sikkerhed på rækkeniveau, skal overvåges.

Omhyggeligt udformede forespørgsler

Det er muligt at forårsage lækage af oplysninger ved hjælp af omhyggeligt udformede forespørgsler, der bruger fejl til at exfiltrate data. Lad f.eks. en ondsindet bruger vide, SELECT 1/(SALARY-100000) FROM PAYROLL WHERE NAME='John Doe'; at John Does løn er nøjagtigt $100.000. Selvom der er et sikkerhedsforlæg på plads for at forhindre en ondsindet bruger i direkte at forespørge andres løn, kan brugeren bestemme, hvornår forespørgslen returnerer en undtagelse på divide-by-zero.

Eksempler

Vi kan demonstrere slutpunktet for sikkerhed på rækkeniveau Warehouse og SQL Analytics i Microsoft Fabric.

I følgende eksempel oprettes eksempeltabeller, der fungerer sammen med Warehouse i Fabric, men i SQL Analytics-slutpunktet bruges eksisterende tabeller. I SQL Analytics-slutpunktet kan du ikke CREATE TABLE, men du kan CREATE SCHEMA, CREATE FUNCTIONog CREATE SECURITY POLICY.

I dette eksempel skal du først oprette et skema sales, en tabel 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');

Opret et Security skema, en funktion Security.tvf_securitypredicateog en sikkerhedspolitik 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

Relateret indhold

Næste trin

Implementer sikkerhed på rækkeniveau i Fabric Data Warehousing