Sikkerhet på radnivå i datalager for stoff

  • Artikkel

Gjelder for: SQL Analytics-endepunkt og Warehouse i Microsoft Fabric

Sikkerhet på radnivå (RLS) gjør det mulig å bruke gruppemedlemskap eller utførelseskontekst til å kontrollere tilgangen til rader i en databasetabell. Du kan for eksempel sikre at arbeidere bare får tilgang til de dataradene som er relevante for avdelingen. Et annet eksempel er å begrense kundenes datatilgang til bare dataene som er relevante for firmaet i en flertenant arkitektur. Funksjonen ligner på sikkerhet på radnivå i SQL Server.

Sikkerhet på radnivå på datanivå

Sikkerhet på radnivå forenkler utformingen og kodingen av sikkerhet i programmet. Sikkerhet på radnivå hjelper deg med å implementere begrensninger for dataradtilgang.

Tilgangsbegrensningslogikken er i databasenivået, ikke i ett enkelt programnivå. Databasen bruker tilgangsbegrensningene hver gang datatilgang forsøkes, fra alle programmer eller rapporteringsplattformer, inkludert Power BI. Dette gjør sikkerhetssystemet mer pålitelig og robust ved å redusere overflatearealet i sikkerhetssystemet. Sikkerhet på radnivå gjelder bare for spørringer på et lager- eller SQL-analyseendepunkt i Fabric. Power BI-spørringer på et lager i Direct Lake-modus vil falle tilbake til Direct Query-modus for å overholde sikkerhet på radnivå.

Begrense tilgangen til bestemte rader til bestemte brukere

Implementer RLS ved hjelp av CREATE SECURITY POLICY Transact-SQL-setningen, og predikater opprettet som innebygde tabellverdifunksjoner.

Sikkerhet på radnivå brukes på delt lager eller lakehouse fordi den underliggende datakilden ikke er endret.

Predikatbasert sikkerhet på radnivå

Sikkerhet på radnivå i Fabric Synapse Data Warehouse støtter predikatbasert sikkerhet. Filterpredikater filtrerer stille radene som er tilgjengelige for leseoperasjoner.

Tilgang til data på radnivå i en tabell er begrenset av et sikkerhetspredikat definert som en innebygd tabellverdifunksjon. Funksjonen aktiveres og håndheves deretter av en sikkerhetspolicy. For filterpredikater er programmet ikke klar over rader som er filtrert fra resultatsettet. Hvis alle rader filtreres, returneres et nullsett.

Filterpredikater brukes når du leser data fra basistabellen. De påvirker alle hent operasjoner: SELECT, DELETEog UPDATE. Brukerne kan ikke merke eller slette rader som er filtrert. Brukeren kan ikke oppdatere rader som er filtrert. Men det er mulig å oppdatere rader på en slik måte at de filtreres etterpå.

Filterpredikat og sikkerhetspolicyer har følgende virkemåte:

  • Du kan definere en predikatfunksjon som slutter seg til en annen tabell og/eller aktiverer en funksjon. Hvis sikkerhetspolicyen opprettes med SCHEMABINDING = ON (standard), er sammenføyningen eller funksjonen tilgjengelig fra spørringen og fungerer som forventet uten ytterligere tillatelseskontroller.

  • Du kan utstede en spørring mot en tabell som har et definert sikkerhetspredikat, men deaktivert. Alle rader som er filtrert eller blokkert, påvirkes ikke.

  • Hvis en dbo-bruker, et medlem av db_owner rollen eller tabelleieren spør etter en tabell som har en sikkerhetspolicy definert og aktivert, filtreres eller blokkeres radene som definert av sikkerhetspolicyen.

  • Forsøk på å endre skjemaet for en tabell som er bundet av en skjemabundet sikkerhetspolicy, vil føre til en feil. Kolonner som ikke er referert til av predikatet, kan imidlertid endres.

  • Forsøk på å legge til et predikat i en tabell som allerede har en definert for den angitte operasjonen, resulterer i en feil. Dette skjer om predikatet er aktivert eller ikke.

  • Forsøk på å endre en funksjon, som brukes som predikat på en tabell i en skjemabundet sikkerhetspolicy, vil resultere i en feil.

  • Definering av flere aktive sikkerhetspolicyer som inneholder ikke-overlappende predikater, lykkes.

Filterpredikater har følgende virkemåte:

  • Definer en sikkerhetspolicy som filtrerer radene i en tabell. Programmet er ikke klar over eventuelle rader som er filtrert for SELECT, UPDATEog DELETE operasjoner. Inkludert situasjoner der alle radene er filtrert ut. Programmet kan INSERT rader, selv om de vil bli filtrert under en annen operasjon.

Tillatelser

Oppretting, endring eller fjerning av sikkerhetspolicyer krever ALTER ANY SECURITY POLICY tillatelse. Oppretting eller fjerning av en sikkerhetspolicy krever ALTER tillatelse for skjemaet.

I tillegg kreves følgende tillatelser for hvert predikat som legges til:

  • SELECT og REFERENCES tillatelser for funksjonen som brukes som predikat.

  • REFERENCES tillatelse på måltabellen som er bundet til policyen.

  • REFERENCES tillatelse på hver kolonne fra måltabellen som brukes som argumenter.

Sikkerhetspolicyer gjelder for alle brukere, inkludert dbo-brukere i databasen. Dbo-brukere kan endre eller droppe sikkerhetspolicyer, men endringene i sikkerhetspolicyene kan overvåkes. Hvis medlemmer av roller som administrator, medlem eller bidragsyter må se alle rader for å feilsøke eller validere data, må sikkerhetspolicyen skrives for å tillate dette.

Hvis en sikkerhetspolicy opprettes med SCHEMABINDING = OFF, må brukerne ha SELECT eller EXECUTE tillatelse til predikatfunksjonen og eventuelle ekstra tabeller, visninger eller funksjoner som brukes i predikatfunksjonen, for å spørre måltabellen. Hvis en sikkerhetspolicy opprettes med SCHEMABINDING = ON (standard), blir disse tillatelseskontrollene forbigått når brukere spør etter måltabellen.

Sikkerhetshensyn: sidekanalangrep

Vurder og klargjør for følgende to scenarier.

Behandling av skadelig sikkerhetspolicy

Det er viktig å se at en ansvarlig for ondsinnet sikkerhetspolicy, med tilstrekkelige tillatelser til å opprette en sikkerhetspolicy oppå en sensitiv kolonne og ha tillatelse til å opprette eller endre innebygde tabellverdifunksjoner, kan samarbeide med en annen bruker som har utvalgte tillatelser i en tabell til å utføre dataeksfiltrering ved å opprette innebygde tabellverdifunksjoner som er utformet for å bruke sidekanalangrep til å utlede data. Slike angrep ville kreve sammensvergelse (eller overflødige tillatelser gitt til en ondsinnet bruker) og ville sannsynligvis kreve flere gjentakelser for å endre policyen (krever tillatelse til å fjerne predikatet for å bryte skjemabindingen), endre de innebygde tabellverdifunksjonene og gjentatte ganger kjøre utvalgte setninger i måltabellen. Vi anbefaler at du begrenser tillatelser etter behov og overvåker for mistenkelig aktivitet. Aktivitet som stadig endring av policyer og innebygde tabellverdifunksjoner relatert til sikkerhet på radnivå, bør overvåkes.

Nøye utformede spørringer

Det er mulig å forårsake informasjonslekkasje ved hjelp av nøye utformede spørringer som bruker feil til å eksfiltrere data. La for eksempel SELECT 1/(SALARY-100000) FROM PAYROLL WHERE NAME='John Doe'; en ondsinnet bruker vite at John Doe lønn er nøyaktig $100,000. Selv om det er et sikkerhetspredikat på plass for å hindre at en ondsinnet bruker spør direkte etter andres lønn, kan brukeren avgjøre når spørringen returnerer et divider-med-null-unntak.

Eksempler

Vi kan demonstrere sikkerhetslager og SQL-analyseendepunkt på radnivå i Microsoft Fabric.

Følgende eksempel oppretter eksempeltabeller som vil fungere med Warehouse in Fabric, men i SQL Analytics bruker du eksisterende tabeller. I endepunktet for SQL-analyse kan du ikke CREATE TABLE, men du kan CREATE SCHEMA, CREATE FUNCTIONog CREATE SECURITY POLICY.

I dette eksemplet må du først opprette et skjema sales, en tabell 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');

Opprett et Security skjema, en funksjon Security.tvf_securitypredicateog en sikkerhetspolicy 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

Relatert innhold

Neste trinn

Implementere sikkerhet på radnivå i Fabric Data Warehousing