Säkerhet på radnivå i fabric-datalager
Gäller för:✅ SQL-analysslutpunkt och lager i Microsoft Fabric
Med säkerhet på radnivå (RLS) kan du använda gruppmedlemskap eller körningskontext för att styra åtkomsten till rader i en databastabell. Du kan till exempel se till att arbetare endast kommer åt de datarader som är relevanta för deras avdelning. Ett annat exempel är att begränsa kundernas dataåtkomst till endast de data som är relevanta för deras företag i en arkitektur med flera klientorganisationer. Funktionen liknar säkerhet på radnivå i SQL Server.
Säkerhet på radnivå på datanivå
Säkerhet på radnivå förenklar utformningen och kodningen av säkerhet i ditt program. Säkerhet på radnivå hjälper dig att implementera begränsningar för dataradsåtkomst.
Logiken för åtkomstbegränsning finns på databasnivån, inte på någon enskild programnivå. Databasen tillämpar åtkomstbegränsningarna varje gång dataåtkomst görs, från alla program eller rapporteringsplattformar, inklusive Power BI. Detta gör ditt säkerhetssystem mer tillförlitligt och robust genom att minska säkerhetssystemets yta. Säkerhet på radnivå gäller endast för frågor på en slutpunkt för lager- eller SQL-analys i Infrastrukturresurser. Power BI-frågor på ett lager i Direct Lake-läge återgår till Direct Query-läge för att följa säkerhet på radnivå.
Begränsa åtkomsten till vissa rader till vissa användare
Implementera RLS med hjälp av transact-SQL-instruktionen CREATE SECURITY POLICY och predikat som skapats som infogade tabellvärdesfunktioner.
Säkerhet på radnivå tillämpas på delat lager eller lakehouse eftersom den underliggande datakällan inte har ändrats.
Predikatbaserad säkerhet på radnivå
Säkerhet på radnivå i Fabric Data Warehouse stöder predikatbaserad säkerhet. Filtrera predikat tyst filtrera raderna som är tillgängliga för läsåtgärder.
Åtkomst till data på radnivå i en tabell begränsas av en säkerhetspredikat som definieras som en infogad tabellvärdesfunktion. Funktionen anropas och framtvingas sedan av en säkerhetsprincip. För filterpredikat är programmet omedvetet om rader som filtreras från resultatuppsättningen. Om alla rader filtreras returneras en null-uppsättning.
Filterpredikat tillämpas vid läsning av data från bastabellen. De påverkar alla get-åtgärder: SELECT, DELETEoch UPDATE. Varje tabell måste ha sin egen säkerhet på radnivå definierad separat. Användare som kör frågor mot tabeller utan en säkerhetsprincip på radnivå visar ofiltrerade data.
Användare kan inte välja eller ta bort rader som filtreras. Användaren kan inte uppdatera rader som filtreras. Men det går att uppdatera rader på ett sådant sätt att de filtreras efteråt.
Filterpredikat och säkerhetsprinciper har följande beteende:
Du kan definiera en predikatfunktion som ansluter till en annan tabell och/eller anropar en funktion. Om säkerhetsprincipen skapas med
SCHEMABINDING = ON(standardvärdet) är kopplingen eller funktionen tillgänglig från frågan och fungerar som förväntat utan ytterligare behörighetskontroller.Du kan utfärda en fråga mot en tabell som har ett definierat säkerhetspredikat men inaktiverat. Alla rader som filtreras eller blockeras påverkas inte.
Om en dbo-användare, en medlem av
db_ownerrollen eller tabellägaren frågar en tabell som har en definierad och aktiverad säkerhetsprincip filtreras eller blockeras raderna enligt säkerhetsprincipens definition.Försök att ändra schemat för en tabell som är bunden av en schemabunden säkerhetsprincip resulterar i ett fel. Kolumner som inte refereras till av predikatet kan dock ändras.
Försök att lägga till ett predikat i en tabell som redan har definierats för den angivna åtgärden resulterar i ett fel. Detta inträffar oavsett om predikatet är aktiverat eller inte.
Försök att ändra en funktion som används som predikat i en tabell i en schemabunden säkerhetsprincip resulterar i ett fel.
Det går att definiera flera aktiva säkerhetsprinciper som innehåller icke-överlappande predikat.
Filterpredikat har följande beteende:
- Definiera en säkerhetsprincip som filtrerar raderna i en tabell. Programmet känner inte till några rader som filtreras för
SELECT,UPDATEochDELETEåtgärder. Inklusive situationer där alla rader filtreras bort. Programmet kanINSERTrader, även om de filtreras under någon annan åtgärd.
Behörigheter
För att skapa, ändra eller ta bort säkerhetsprinciper krävs behörigheten ALTER ANY SECURITY POLICY . För att skapa eller ta bort en säkerhetsprincip krävs ALTER behörighet för schemat.
Dessutom krävs följande behörigheter för varje predikat som läggs till:
SELECTochREFERENCESbehörigheter för funktionen som används som predikat.REFERENCESbehörighet på måltabellen som är bunden till principen.REFERENCESbehörighet för varje kolumn från måltabellen som används som argument.
Säkerhetsprinciper gäller för alla användare, inklusive dbo-användare i databasen. Dbo-användare kan ändra eller släppa säkerhetsprinciper, men deras ändringar i säkerhetsprinciper kan granskas. Om medlemmar i roller som Administratör, Medlem eller Deltagare behöver se alla rader för att felsöka eller verifiera data måste säkerhetsprincipen skrivas för att tillåta det.
Om en säkerhetsprincip skapas med SCHEMABINDING = OFFmåste användarna ha behörigheten SELECT eller EXECUTE för predikatfunktionen och eventuella ytterligare tabeller, vyer eller funktioner som används i predikatfunktionen för att köra frågor mot måltabellen. Om en säkerhetsprincip skapas med SCHEMABINDING = ON (standardinställningen) kringgås dessa behörighetskontroller när användare kör frågor mot måltabellen.
Säkerhetsöverväganden: sidokanalattacker
Överväg och förbered dig för följande två scenarier.
Ansvarig för skadlig säkerhetsprincip
Det är viktigt att observera att en ansvarig för skadlig säkerhetsprincip, med tillräcklig behörighet för att skapa en säkerhetsprincip ovanpå en känslig kolumn och har behörighet att skapa eller ändra infogade tabellvärdesfunktioner, kan samverka med en annan användare som har valt behörigheter i en tabell för att utföra dataexfiltrering genom att skadligt skapa infogade tabellvärdesfunktioner som är utformade för att använda sidokanalattacker för att härleda data. Sådana attacker skulle kräva samverkan (eller överdriven behörighet som beviljats en obehörig användare) och skulle sannolikt kräva flera iterationer av att ändra principen (kräver behörighet att ta bort predikatet för att bryta schemabindningen), ändra de infogade tabellvärdesfunktionerna och upprepade gånger köra select-instruktioner i måltabellen. Vi rekommenderar att du begränsar behörigheter efter behov och övervakar misstänkt aktivitet. Aktiviteter som ständigt föränderliga principer och infogade tabellvärdesfunktioner relaterade till säkerhet på radnivå bör övervakas.
Noggrant utformade frågor
Det är möjligt att orsaka informationsläckage med hjälp av noggrant utformade frågor som använder fel för att exfiltera data. Till exempel SELECT 1/(SALARY-100000) FROM PAYROLL WHERE NAME='John Doe'; skulle låta en obehörig användare veta att John Doe lön är exakt $ 100,000. Även om det finns en säkerhetspredikat på plats för att förhindra att en obehörig användare direkt frågar andra personers lön, kan användaren avgöra när frågan returnerar ett divide-by-zero-undantag.
Exempel
Vi kan demonstrera säkerhetslager på radnivå och SQL-analysslutpunkt i Microsoft Fabric.
I följande exempel skapas exempeltabeller som fungerar med Warehouse i Fabric, men i SQL-analysslutpunkten används befintliga tabeller. I SQL Analytics-slutpunkten kan du inte CREATE TABLE, men du kan CREATE SCHEMA, CREATE FUNCTIONoch CREATE SECURITY POLICY.
I det här exemplet skapar du först ett schema 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');
Skapa ett Security schema, en funktion Security.tvf_securitypredicateoch en säkerhetsprincip 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
Om du vill ändra en säkerhetsfunktion på radnivå måste du först släppa säkerhetsprincipen. I följande skript släpper vi principen SalesFilter innan vi utfärdar en ALTER FUNCTION -instruktion på Security.tvf_securitypredicate. Sedan återskapar vi principen SalesFilter.
-- 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