Bezpieczeństwo na poziomie rzędów w Fabric Data Warehouse

Dotyczy:✅ punkt końcowy analizy SQL i magazyn w usłudze Microsoft Fabric

Zabezpieczenia na poziomie wiersza umożliwiają kontrolowanie dostępu do wierszy w tabeli bazy danych za pomocą członkostwa w grupie lub kontekstu wykonywania. Można na przykład upewnić się, że pracownicy uzyskują dostęp tylko do tych wierszy danych, które są odpowiednie dla ich działu. Innym przykładem jest ograniczenie klientom dostępu do danych wyłącznie do danych istotnych dla ich firmy w architekturze wielodzierżawnej. Funkcja jest podobna do zabezpieczeń na poziomie wiersza w programie SQL Server.

Zabezpieczenia na poziomie wierszy danych

Zabezpieczenia na poziomie wiersza upraszczają projektowanie i kodowanie zabezpieczeń w aplikacji. Zabezpieczenia na poziomie wiersza ułatwiają implementowanie ograniczeń dostępu do wierszy danych.

Logika ograniczeń dostępu znajduje się w warstwie bazy danych, a nie w żadnej warstwie aplikacji. Baza danych stosuje ograniczenia dostępu za każdym razem, gdy jest podejmowana próba dostępu do danych, z dowolnej aplikacji lub platformy raportowania, w tym usługi Power BI. Dzięki temu system zabezpieczeń jest bardziej niezawodny i niezawodny, zmniejszając obszar powierzchni systemu zabezpieczeń. Zabezpieczenia na poziomie wiersza dotyczą tylko zapytań dotyczących punktu końcowego usługi Warehouse lub analizy SQL w usłudze Fabric. Zapytania usługi Power BI dotyczące magazynu w trybie Direct Lake przełączą się na tryb DirectQuery, aby zachować zgodność z zabezpieczeniami na poziomie wierszy.

Ogranicz dostęp do określonych wierszy dla określonych użytkowników

Zaimplementuj zabezpieczenia na poziomie wiersza (RLS), używając instrukcji języka Transact-SQL CREATE SECURITY POLICY oraz predykatów utworzonych jako wbudowane funkcje tabelaryczne.

Zabezpieczenia na poziomie wiersza są stosowane do magazynu udostępnionego lub magazynu typu lakehouse, ponieważ bazowe źródło danych nie uległo zmianie.

Zabezpieczenie na poziomie wiersza oparte na predykacie

Zabezpieczenia na poziomie wierszy w usłudze Fabric Data Warehouse obsługują zabezpieczenia oparte na predykatach. Predykaty filtru niejawnie filtrują wiersze dostępne operacjom odczytu.

Dostęp do danych na poziomie wiersza w tabeli jest ograniczony przez predykat zabezpieczeń zdefiniowany jako wbudowana funkcja wartości tabeli. Funkcja jest następnie wywoływana i wymuszana przez zasady zabezpieczeń. W przypadku predykatów filtru aplikacja nie zna wierszy filtrowanych z zestawu wyników. Jeśli wszystkie wiersze są filtrowane, zostanie zwrócony zestaw wartości null.

Predykaty filtru są stosowane podczas odczytywania danych z tabeli podstawowej. Mają wpływ na wszystkie operacje pobierania: SELECT, DELETE, i UPDATE. Każda tabela musi mieć własne zabezpieczenia na poziomie wiersza zdefiniowane oddzielnie. Użytkownicy, którzy odpytują tabele bez zasad zabezpieczeń na poziomie wiersza, będą wyświetlać niefiltrowane dane.

Użytkownicy nie mogą wybierać ani usuwać wierszy, które są filtrowane. Użytkownik nie może zaktualizować wierszy, które są filtrowane. Można jednak zaktualizować wiersze w taki sposób, aby były filtrowane później.

Predykat filtru oraz zasady zabezpieczeń działają w następujący sposób:

  • Można zdefiniować funkcję predykatu, która łączy się z inną tabelą i/lub wywołuje funkcję. Jeśli zasada zabezpieczeń jest tworzona z użyciem SCHEMABINDING = ON (ustawienie domyślne), złączenie lub funkcja są dostępne z poziomu zapytania i działają zgodnie z oczekiwaniami bez żadnego dodatkowego sprawdzania uprawnień.

  • Możesz wydać zapytanie względem tabeli, która ma zdefiniowany predykat zabezpieczeń, ale wyłączony. Nie ma to wpływu na wszystkie wiersze, które są filtrowane lub blokowane.

  • Jeśli użytkownik dbo, członek db_owner roli lub właściciel tabeli wysyła zapytanie do tabeli, która ma zdefiniowane i włączone zasady zabezpieczeń, wiersze są filtrowane lub blokowane zgodnie z definicją zasad zabezpieczeń.

  • Próby zmiany schematu tabeli powiązanej przez powiązane ze schematem zasady zabezpieczeń spowodują błąd. Jednak kolumny, do których nie odwołuje się predykat, mogą być zmieniane.

  • Próba dodania predykatu do tabeli, która ma już jedną zdefiniowaną dla określonej operacji, powoduje wystąpienie błędu. Stanie się tak, czy predykat jest włączony, czy nie.

  • Próba zmodyfikowania funkcji, która jest używana jako predykat w tabeli w ramach zasad zabezpieczeń powiązanych ze schematem, spowoduje błąd.

  • Definiowanie wielu aktywnych zasad zabezpieczeń, które zawierają nienakładujące się predykaty, kończy się powodzeniem.

Predykaty filtrów mają następujące zachowanie:

  • Zdefiniuj zasady zabezpieczeń, które filtrują wiersze tabeli. Aplikacja nie uwzględnia żadnych wierszy przefiltrowanych dla operacji SELECT, UPDATE i DELETE. Uwzględnianie sytuacji, w których wszystkie wiersze są odfiltrowane. Aplikacja może wyświetlać INSERT wiersze, nawet jeśli będą filtrowane podczas dowolnej innej operacji.

Uprawnienia

Tworzenie, zmienianie lub usuwanie zasad zabezpieczeń wymaga ALTER ANY SECURITY POLICY uprawnień. Tworzenie lub usuwanie zasad zabezpieczeń wymaga ALTER uprawnień do schematu.

Ponadto dla każdego dodanego predykatu wymagane są następujące uprawnienia:

  • SELECT i REFERENCES uprawnienia do funkcji używanej jako predykat.

  • REFERENCES uprawnienie do tabeli docelowej powiązanej z zasadami.

  • REFERENCES uprawnienia do wszystkich kolumn z tabeli docelowej używanych jako argumenty.

Zasady zabezpieczeń dotyczą wszystkich użytkowników, w tym użytkowników dbo w bazie danych. Użytkownicy dbo mogą zmieniać lub usuwać zasady zabezpieczeń, jednak zmiany zasad zabezpieczeń mogą być poddawane inspekcji. Jeśli członkowie ról, takich jak Administrator, Członek lub Współautor, muszą zobaczyć wszystkie wiersze w celu rozwiązywania problemów lub weryfikowania danych, należy zapisać zasady zabezpieczeń, aby zezwolić na to.

Jeśli zasada zabezpieczeń została utworzona przy użyciu SCHEMABINDING = OFF, wówczas, aby wykonywać zapytania względem tabeli docelowej, użytkownicy muszą mieć uprawnienie SELECT lub EXECUTE do funkcji predykatu oraz wszelkich dodatkowych tabel, widoków lub funkcji używanych w tej funkcji predykatu. Jeśli zasada zabezpieczeń jest tworzona z użyciem SCHEMABINDING = ON (ustawienie domyślne), wówczas te sprawdzenia uprawnień są pomijane, gdy użytkownicy wykonują zapytania względem tabeli docelowej.

Zagadnienia dotyczące zabezpieczeń: ataki kanału bocznego

Rozważ i przygotuj się do następujących dwóch scenariuszy.

Menedżer złośliwych zasad zabezpieczeń

Należy pamiętać, że złośliwy administrator zasad zabezpieczeń, mający wystarczające uprawnienia do utworzenia zasady zabezpieczeń dla kolumny zawierającej dane wrażliwe oraz uprawnienia do tworzenia lub modyfikowania wbudowanych funkcji zwracających wartości tabelaryczne, może wejść w zmowę z innym użytkownikiem, który ma uprawnienia SELECT do tabeli, aby dokonać eksfiltracji danych poprzez złośliwe tworzenie wbudowanych funkcji zwracających wartości tabelaryczne zaprojektowanych tak, aby wykorzystywały ataki bocznym kanałem do wywnioskowania danych. Takie ataki wymagają zmowy (lub nadmiernych uprawnień przyznanych złośliwemu użytkownikowi) i prawdopodobnie będą wymagały kilku iteracji modyfikowania zasad (wymagając uprawnień do usunięcia predykatu w celu przerwania powiązania schematu), modyfikowania wbudowanych funkcji tabel wartościowych i wielokrotnego uruchamiania instrukcji select w tabeli docelowej. Zalecamy ograniczenie uprawnień zgodnie z potrzebami i monitorowanie pod kątem wszelkich podejrzanych działań. Należy monitorować działania, takie jak stale zmieniające się zasady i wbudowane funkcje tabel związane z zabezpieczeniami na poziomie wiersza.

Starannie spreparowane zapytania

Istnieje możliwość spowodowania wycieku informacji przy użyciu starannie spreparowanych zapytań, które używają błędów do eksfiltracji danych. Na przykład może poinformować złośliwego użytkownika, SELECT 1/(SALARY-100000) FROM PAYROLL WHERE NAME='John Doe'; że wynagrodzenie Johna Doe'a wynosi dokładnie 100 000 USD. Mimo że istnieje predykat zabezpieczeń, aby uniemożliwić złośliwemu użytkownikowi bezpośrednie wykonywanie zapytań dotyczących wynagrodzenia innych osób, użytkownik może określić, kiedy zapytanie zwraca wyjątek dzielenia przez zero.

Przykłady

Możemy zademonstrować magazyn zabezpieczeń na poziomie wiersza i punkt końcowy analizy SQL w usłudze Microsoft Fabric.

Poniższy przykład tworzy przykładowe tabele, które będą działać z usługą Warehouse w usłudze Fabric, ale w punkcie końcowym analizy SQL należy użyć istniejących tabel. W punkcie końcowym analizy SQL nie można CREATE TABLE, ale można CREATE SCHEMA, CREATE FUNCTION i CREATE SECURITY POLICY.

W tym przykładzie najpierw utwórz schemat sales, 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');

Security Utwórz schemat, funkcję Security.tvf_securitypredicatei zasady SalesFilterzabezpieczeń .

-- 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

Aby zmodyfikować funkcję zabezpieczeń na poziomie wiersza, należy najpierw usunąć zasady zabezpieczeń. W poniższym skrypcie usuwamy zasadę SalesFilter przed wykonaniem instrukcji ALTER FUNCTION na Security.tvf_securitypredicate. Następnie ponownie tworzymy zasadę 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

Następny krok

Wprowadź bezpieczeństwo na poziomie wiersza w Fabric Data Warehouse

Powiązana zawartość

  • Last updated on