Udostępnij za pośrednictwem

Zabezpieczenia na poziomie wiersza w magazynowaniu danych sieci szkieletowej

  • Artykuł

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 dostępu do danych klientów tylko do danych istotnych dla firmy w architekturze wielodostępnej. Funkcja jest podobna do zabezpieczeń na poziomie wiersza w programie SQL Server.

Zabezpieczenia na poziomie wiersza na poziomie 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 w magazynie w trybie Direct Lake powrócą do trybu Direct Query w celu przestrzegania zabezpieczeń na poziomie wiersza.

Ograniczanie dostępu do niektórych wierszy do niektórych użytkowników

Zaimplementuj zabezpieczenia na poziomie wiersza przy użyciu instrukcji CREATE SECURITY POLICY Języka Transact-SQL i predykatów utworzonych jako wbudowane funkcje wartości tabeli.

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

Zabezpieczenia na poziomie wiersza oparte na predykacie

Zabezpieczenia na poziomie wiersza w usłudze Fabric Synapse Data Warehouse obsługują zabezpieczenia oparte na predykacie. Filtruj predykaty dyskretnie filtruj wiersze dostępne do odczytu operacji.

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.

Zasady predykatu filtru i zabezpieczeń mają następujące zachowanie:

  • Można zdefiniować funkcję predykatu, która łączy się z inną tabelą i/lub wywołuje funkcję. Jeśli zasady zabezpieczeń są tworzone przy SCHEMABINDING = ON użyciu (ustawienie domyślne), sprzężenie lub funkcja jest dostępna z zapytania i działa zgodnie z oczekiwaniami bez żadnych dodatkowych kontroli 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 zna żadnych wierszy filtrowanych dla SELECToperacji , UPDATEi 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 każdej kolumny z tabeli docelowej używanej 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 zasady zabezpieczeń są tworzone za pomocą SCHEMABINDING = OFFpolecenia , a następnie wysyłać zapytania do tabeli docelowej, użytkownicy muszą mieć SELECT uprawnienia lub EXECUTE dla funkcji predykatu i wszelkich dodatkowych tabel, widoków lub funkcji używanych w funkcji predykatu. Jeśli zasady zabezpieczeń są tworzone przy SCHEMABINDING = ON użyciu (ustawienie domyślne), te kontrole uprawnień są pomijane, gdy użytkownicy wysyłają zapytania do 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ń

Ważne jest, aby zauważyć, że menedżer złośliwych zasad zabezpieczeń z wystarczającymi uprawnieniami do tworzenia zasad zabezpieczeń na podstawie poufnej kolumny i uprawnienia do tworzenia lub modyfikowania wbudowanych funkcji wartości tabeli może zderzyć się z innym użytkownikiem, który ma uprawnienia do wykonywania eksfiltracji danych przez złośliwe tworzenie wbudowanych funkcji wartości tabeli zaprojektowanych do używania ataków kanału bocznego w celu wnioskowania 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ą współdziałać z usługą Warehouse w sieci szkieletowej, ale w punkcie końcowym analizy SQL używają istniejących tabel. W punkcie końcowym analizy SQL nie można wykonać CREATE TABLEinstrukcji , ale możesz elementy CREATE SCHEMA, CREATE FUNCTIONi 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 skry skrycie usuwamy zasady SalesFilter przed wydaniem ALTER FUNCTION instrukcji w pliku Security.tvf_securitypredicate. Następnie ponownie utworzymy zasady 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

Implementowanie zabezpieczeń na poziomie wiersza w usłudze Fabric Magazyn danych

Powiązana zawartość