Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
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 is van toepassing op een gedeeld warehouse of lakehouse, omdat de onderliggende gegevensbron niet is gewijzigd.
Predicaatgebaseerde beveiliging op rijniveau
Beveiliging op rijniveau in Fabric Data Warehouse biedt ondersteuning voor beveiliging op basis van predicaat. 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. Elke tabel moet een eigen beveiliging op rijniveau hebben die afzonderlijk is gedefinieerd. Gebruikers die query's uitvoeren op tabellen zonder beveiligingsbeleid op rijniveau, bekijken niet-gefilterde gegevens.
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_ownerrol 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 het predicaat niet verwijst, 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,UPDATEenDELETEbewerkingen. Ook situaties waarin alle rijen worden weggefilterd. De applicatie kanINSERTrijen bevatten, zelfs als die bij 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:
SELECTenREFERENCESmachtigingen voor de functie die wordt gebruikt als predicaat.REFERENCEStoestemming voor de doeltabel waaraan het beleid is gekoppeld.REFERENCEStoestemming voor elke kolom uit de doeltabel die als argument 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 de machtiging SELECT of EXECUTE hebben voor de predicaatfunctie en eventuele extra tabellen, weergaven of functies die in de predicaatfunctie worden gebruikt om een query op de doeltabel uit te voeren. 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 op te merken dat een kwaadwillende beheerder van beveiligingsbeleid, met voldoende machtigingen om een beveiligingsbeleid voor een gevoelige kolom te maken en om inline tabelwaardefuncties te maken of te wijzigen, kan samenspannen met een andere gebruiker die SELECT-machtigingen voor een tabel heeft om data-exfiltratie uit te voeren door kwaadwillig inline tabelwaardefuncties te maken die zijn ontworpen om side-channelaanvallen te gebruiken om gegevens af te leiden. Dergelijke aanvallen zouden samenspanning vereisen (of buitensporige machtigingen die aan een kwaadwillende gebruiker zijn verleend) en zouden waarschijnlijk meerdere rondes vereisen van het wijzigen van het beleid (waarvoor toestemming nodig is om het predicaat te verwijderen en zo de schemabinding te verbreken), het wijzigen van de inline-tabelwaardefuncties en het herhaaldelijk uitvoeren van SELECT-instructies op de doeltabel. 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 geformuleerde zoekopdrachten
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 beveiliging op rijniveau demonstreren in Warehouse en het SQL-analyse-eindpunt 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 u CREATE TABLE niet, maar wel CREATE SCHEMA, CREATE FUNCTION en 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
Als u een beveiligingsfunctie op rijniveau wilt wijzigen, moet u eerst het beveiligingsbeleid verwijderen. In het volgende script verwijderen we de policy SalesFilter voordat we een ALTER FUNCTION-statement voor Security.tvf_securitypredicate uitvoeren. Vervolgens maken we het beleid SalesFilteropnieuw.
-- 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