Delen via


Beveiliging op rijniveau in Fabric-datawarehousing

Van toepassing op: SQL Analytics-eindpunt en -magazijn in Microsoft Fabric

Met beveiliging op rijniveau (RLS) kunt u groepslidmaatschap of uitvoeringscontext gebruiken om de toegang tot rijen in een databasetabel te beheren. U kunt er bijvoorbeeld voor zorgen dat werknemers alleen toegang hebben tot de gegevensrijen die relevant zijn voor hun afdeling. Een ander voorbeeld is om de gegevenstoegang van klanten te beperken tot alleen de gegevens die relevant zijn voor hun bedrijf in een architectuur met meerdere tenants. De functie is vergelijkbaar met beveiliging op rijniveau in SQL Server.

Beveiliging op rijniveau op gegevensniveau

Beveiliging op rijniveau vereenvoudigt het ontwerpen en coderen van beveiliging in uw toepassing. Beveiliging op rijniveau helpt u bij het implementeren van beperkingen voor toegang tot gegevensrijen.

De toegangsbeperkingslogica bevindt zich in de databaselaag, niet in één toepassingslaag. De database past de toegangsbeperkingen toe telkens wanneer gegevenstoegang wordt geprobeerd, vanuit elk toepassings- of rapportageplatform, inclusief Power BI. Hierdoor is uw beveiligingssysteem betrouwbaarder en robuuster door het oppervlak van uw beveiligingssysteem te verminderen. Beveiliging op rijniveau is alleen van toepassing op query's op een warehouse- of SQL-analyse-eindpunt in Fabric. Power BI-query's in een magazijn in de Direct Lake-modus vallen terug op de modus Direct Query om zich te houden aan beveiliging op rijniveau.

Toegang tot bepaalde rijen beperken tot bepaalde gebruikers

Implementeer RLS met behulp van de Transact-SQL-instructie CREATE SECURITY POLICY en predicaten die zijn gemaakt als inline tabelwaardefuncties.

Beveiliging op rijniveau wordt toegepast op gedeelde warehouses of Lakehouse, omdat de onderliggende gegevensbron niet is gewijzigd.

Beveiliging op basis van predicaat op rijniveau

Beveiliging op rijniveau in Fabric Synapse Data Warehouse biedt ondersteuning voor op predicaat gebaseerde beveiliging. Filterpredicaten filteren op de achtergrond de rijen die beschikbaar zijn voor leesbewerkingen.

Toegang tot gegevens op rijniveau in een tabel wordt beperkt door een beveiligingspredicaat dat is gedefinieerd als een inline-tabelwaardefunctie. De functie wordt vervolgens aangeroepen en afgedwongen door een beveiligingsbeleid. Voor filterpredicaten is de toepassing niet op de hoogte van rijen die zijn gefilterd uit de resultatenset. Als alle rijen worden gefilterd, wordt er een null-set geretourneerd.

Filterpredicaten worden toegepast tijdens het lezen van gegevens uit de basistabel. Ze zijn van invloed op alle get-bewerkingen: SELECT, DELETEen UPDATE. De gebruikers kunnen geen rijen selecteren of verwijderen die zijn gefilterd. De gebruiker kan geen rijen bijwerken die zijn gefilterd. Maar het is mogelijk om rijen zo bij te werken dat ze later worden gefilterd.

Filterpredicaat en beveiligingsbeleid hebben het volgende gedrag:

  • U kunt een predicaatfunctie definiëren die wordt samengevoegd met een andere tabel en/of een functie aanroept. Als het beveiligingsbeleid wordt gemaakt met SCHEMABINDING = ON (de standaardinstelling), is de join of functie toegankelijk vanuit de query en werkt het zoals verwacht zonder extra machtigingscontroles.

  • U kunt een query uitvoeren voor een tabel waarvoor een beveiligingspredicaat is gedefinieerd, maar uitgeschakeld. Rijen die worden gefilterd of geblokkeerd, worden niet beïnvloed.

  • Als een dbo-gebruiker, lid van de db_owner rol of de eigenaar van de tabel een query op een tabel met een beveiligingsbeleid heeft gedefinieerd en ingeschakeld, worden de rijen gefilterd of geblokkeerd zoals gedefinieerd door het beveiligingsbeleid.

  • Pogingen om het schema van een tabel te wijzigen die afhankelijk is van een schemagebonden beveiligingsbeleid, leiden tot een fout. Kolommen waarnaar niet wordt verwezen door het predicaat kunnen echter worden gewijzigd.

  • Pogingen om een predicaat toe te voegen aan een tabel waarvoor al een predicaat is gedefinieerd voor de opgegeven bewerking, resulteert in een fout. Dit gebeurt ongeacht of het predicaat al dan niet is ingeschakeld.

  • Pogingen om een functie te wijzigen, die wordt gebruikt als predicaat voor een tabel binnen een schemagebonden beveiligingsbeleid, resulteert in een fout.

  • Het definiëren van meerdere actieve beveiligingsbeleidsregels die niet-overlappende predicaten bevatten, slaagt.

Filterpredicaten hebben het volgende gedrag:

  • Definieer een beveiligingsbeleid waarmee de rijen van een tabel worden gefilterd. De toepassing is niet op de hoogte van rijen die zijn gefilterd op SELECT, UPDATEen DELETE bewerkingen. Inclusief situaties waarin alle rijen worden uitgefilterd. De toepassing kan rijen maken INSERT , zelfs als ze tijdens een andere bewerking worden gefilterd.

Machtigingen

Voor het maken, wijzigen of verwijderen van beveiligingsbeleid is de ALTER ANY SECURITY POLICY machtiging vereist. Voor het maken of verwijderen van een beveiligingsbeleid is een machtiging voor het schema vereist ALTER .

Daarnaast zijn de volgende machtigingen vereist voor elk predicaat dat wordt toegevoegd:

  • SELECT en REFERENCES machtigingen voor de functie die wordt gebruikt als predicaat.

  • REFERENCES machtiging voor de doeltabel die is gebonden aan het beleid.

  • REFERENCES machtiging voor elke kolom uit de doeltabel die als argumenten wordt gebruikt.

Beveiligingsbeleid is van toepassing op alle gebruikers, inclusief dbo-gebruikers in de database. Dbo-gebruikers kunnen beveiligingsbeleid wijzigen of verwijderen, maar hun wijzigingen in beveiligingsbeleid kunnen worden gecontroleerd. Als leden van rollen zoals Beheerder, Lid of Inzender alle rijen moeten zien om problemen met gegevens op te lossen of te valideren, moet het beveiligingsbeleid worden geschreven om dat toe te staan.

Als er een beveiligingsbeleid wordt gemaakt met SCHEMABINDING = OFF, moeten gebruikers over de SELECT EXECUTE of machtiging beschikken voor de predicaatfunctie en eventuele extra tabellen, weergaven of functies die worden gebruikt in de predicaatfunctie om een query uit te voeren op de doeltabel. Als er een beveiligingsbeleid wordt gemaakt met SCHEMABINDING = ON (de standaardinstelling), worden deze machtigingscontroles overgeslagen wanneer gebruikers query's uitvoeren op de doeltabel.

Beveiligingsoverwegingen: side channel-aanvallen

Overweeg en bereid u voor op de volgende twee scenario's.

Kwaadwillende beveiligingsbeleidsmanager

Het is belangrijk om te zien dat een kwaadwillende beveiligingsbeleidsmanager, met voldoende machtigingen voor het maken van een beveiligingsbeleid boven op een gevoelige kolom en gemachtigd is om inline-tabelwaardefuncties te maken of te wijzigen, kan sorteren met een andere gebruiker die machtigingen voor een tabel heeft geselecteerd om gegevensexfiltratie uit te voeren door kwaadwillig inline tabelwaardefuncties te maken die zijn ontworpen om side channel-aanvallen te gebruiken om gegevens af te afleiden. Dergelijke aanvallen vereisen sortering (of overmatige machtigingen die zijn verleend aan een kwaadwillende gebruiker) en vereisen waarschijnlijk verschillende iteraties voor het wijzigen van het beleid (waarvoor toestemming is vereist om het predicaat te verwijderen om de schemabinding te verbreken), de inline-tabelwaardefuncties te wijzigen en herhaaldelijk selectie-instructies in de doeltabel uit te voeren. U wordt aangeraden de machtigingen zo nodig te beperken en te controleren op verdachte activiteiten. Activiteiten zoals voortdurend veranderende beleidsregels en inline-tabelwaardefuncties met betrekking tot beveiliging op rijniveau moeten worden bewaakt.

Zorgvuldig samengestelde query's

Het is mogelijk om gegevenslekken te veroorzaken met behulp van zorgvuldig samengestelde query's die fouten gebruiken om gegevens te exfiltreren. Laat een kwaadwillende gebruiker bijvoorbeeld SELECT 1/(SALARY-100000) FROM PAYROLL WHERE NAME='John Doe'; weten dat John Doe's salaris precies $ 100.000 is. Hoewel er een beveiligingspredicaat is ingesteld om te voorkomen dat een kwaadwillende gebruiker rechtstreeks een query uitvoert op het salaris van andere personen, kan de gebruiker bepalen wanneer de query een uitzondering voor delen door nul retourneert.

Voorbeelden

We kunnen het eindpunt voor beveiliging op rijniveau en SQL-analyse demonstreren in Microsoft Fabric.

In het volgende voorbeeld worden voorbeeldtabellen gemaakt die werken met Warehouse in Fabric, maar in sql Analytics-eindpunten worden bestaande tabellen gebruikt. In het SQL-analyse-eindpunt kunt CREATE SCHEMAu dat nietCREATE TABLE, maar wel , CREATE FUNCTIONen CREATE SECURITY POLICY.

In dit voorbeeld maakt u eerst een schema sales, een 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');

Maak een Security schema, een functie Security.tvf_securitypredicateen een beveiligingsbeleid 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

Volgende stap