Freigeben über

Sicherheit auf Zeilenebene beim Data Warehousing in Fabric

  • Artikel

Gilt für:✅ SQL-Analyseendpunkt und Warehouse in Microsoft Fabric

Mithilfe der Sicherheit auf Zeilenebene (Row-Level Security, RLS) können Sie den Zugriff auf Zeilen in einer Datenbanktabelle anhand der Gruppenmitgliedschaft oder des Ausführungskontexts steuern. Beispielsweise können Sie sicherstellen, dass Mitarbeiter nur auf Datenzeilen zugreifen können, die für ihre Abteilung relevant sind. Ein weiteres Beispiel: Sie können den Zugriff von Kunden in einer mehrinstanzenfähigen Architektur auf Daten beschränken, die für ihr Unternehmen von Bedeutung sind. Das Feature ähnelt der Sicherheit auf Zeilenebene in SQL Server.

Sicherheit auf Zeilenebene für die Datenebene

Die Sicherheit auf Zeilenebene vereinfacht das Entwerfen und Programmieren der Sicherheit in Ihrer Anwendung. Mithilfe der Sicherheit auf Zeilenebene können Sie Einschränkungen für den Datenzeilenzugriff implementieren.

Die Zugriffseinschränkungslogik befindet sich auf der Datenbankebene, nicht auf den einzelnen Anwendungsebenen. Die Datenbank wendet die Zugriffsbeschränkungen jedes Mal an, wenn ein Datenzugriff von einer beliebigen Anwendung oder Berichtsplattform (einschließlich Power BI) aus versucht wird. Dadurch bietet Ihr Sicherheitssystem eine geringere Angriffsfläche und ist zuverlässiger und robuster. Die Sicherheit auf Zeilenebene gilt nur für Abfragen für ein Warehouse oder einen SQL-Analyseendpunkt in Fabric. Bei Power BI-Abfragen für ein Warehouse im Direct Lake-Modus wird auf den Direktabfragemodus zurückgegriffen, um die Sicherheit auf Zeilenebene einzuhalten.

Einschränken des Zugriffs auf bestimmte Zeilen für bestimmte Benutzer*innen

Implementieren Sie RLS, indem Sie die Transact-SQL-Anweisung CREATE SECURITY POLICY und Prädikate verwenden, die als Inline-Tabellenwertfunktionen erstellt werden.

Sicherheit auf Zeilenebene wird auf freigegebene Warehouses oder Lakehouses angewendet, da sich die zugrunde liegende Datenquelle nicht geändert hat.

Prädikatbasierte die Sicherheit auf Zeilenebene

Die Sicherheit auf Zeilenebene in Fabric Data Warehouse unterstützt prädikatbasierte Sicherheit. Filterprädikate filtern automatisch die Zeilen, die für Lesevorgänge zur Verfügung stehen.

Der Zugriff auf Daten auf Zeilenebene in einer Tabelle wird durch ein Sicherheitsprädikat beschränkt, das als Inline-Tabellenwertfunktion definiert ist. Die Funktion wird dann aufgerufen und durch eine Sicherheitsrichtlinie erzwungen. Für Filterprädikate gilt: Der Anwendung ist nicht „bewusst“, dass Zeilen aus dem Resultset herausgefiltert wurden. Wenn alle Zeilen gefiltert wurden, wird eine NULL-Menge zurückgegeben.

Filterprädikate werden beim Lesen von Daten aus der Basistabelle angewendet. Sie betreffen alle GET-Vorgänge: SELECT, DELETE und UPDATE. Für jede Tabelle muss die eigene Sicherheit auf Zeilenebene separat definiert sein. Benutzern, die Tabellen ohne Richtlinie für die Sicherheit auf Zeilenebene abfragen, werden ungefilterte Daten angezeigt.

Benutzer können gefilterte Zeilen weder auswählen noch löschen. Der Benutzer kann gefilterte Zeilen nicht aktualisieren. Zeilen können jedoch so aktualisiert werden, dass sie im Anschluss gefiltert werden.

Filterprädikate und Sicherheitsrichtlinien weisen folgendes Verhalten auf:

  • Sie können eine Prädikatfunktion definieren, die mit einer anderen Tabelle verknüpft wird und/oder eine Funktion aufruft. Wenn die Sicherheitsrichtlinie mit SCHEMABINDING = ON (Standardeinstellung) erstellt wird, ist die Verknüpfung oder Funktion über die Abfrage erreichbar und funktioniert wie erwartet, ohne dass zusätzliche Berechtigungsüberprüfungen durchgeführt werden zu müssen.

  • Sie können eine Abfrage auf eine Tabelle anwenden, für die ein Sicherheitsprädikat zwar definiert, jedoch deaktiviert ist. Zeilen, die gefiltert oder gesperrt wurden, sind nicht betroffen.

  • Wenn DBO-Benutzer*innen, Mitglieder der db_owner-Rolle oder Tabellenbesitzer*innen eine Tabelle abfragen, für die eine Sicherheitsrichtlinie definiert und aktiviert ist, werden die Zeilen gemäß der definierten Sicherheitsrichtlinie gefiltert oder gesperrt.

  • Versuche, das Schema einer Tabelle zu ändern, die durch eine Sicherheitsrichtlinie an ein Schema gebunden ist, führen zu einem Fehler. Allerdings können vom Prädikat nicht referenzierte Spalten geändert werden.

  • Wenn einer Tabelle ein Prädikat hinzugefügt wird, in der für den angegebenen Vorgang bereits ein Prädikat definiert ist, wird ein Fehler verursacht. Dies geschieht unabhängig davon, ob das Prädikat aktiviert ist oder nicht.

  • Beim Versuch eine Funktion zu ändern, die innerhalb einer schemagebundenen Sicherheitsrichtlinie als Prädikat für eine Tabelle verwendet wird, wird ein Fehler verursacht.

  • Das Definieren mehrerer aktiver Sicherheitsrichtlinien, die nicht überlappende Prädikate enthalten, kann erfolgreich ausgeführt werden.

FILTER-Prädikate weisen folgendes Verhalten auf:

  • Definieren Sie eine Sicherheitsrichtlinie, die die Zeilen einer Tabelle filtert. Die Anwendung beachtet keine Zeilen, die nach SELECT-, UPDATE- und DELETE-Vorgängen gefiltert wurden. Dies gilt selbst dann, wenn alle Zeilen gefiltert wurden. Die Anwendung kann mit INSERT selbst dann Zeilen einfügen, wenn sie bei einem anderen Vorgang gefiltert werden.

Berechtigungen

Das Erstellen, Ändern oder Löschen von Sicherheitsrichtlinien erfordert die ALTER ANY SECURITY POLICY-Berechtigung. Das Erstellen oder Löschen einer Sicherheitsrichtlinie erfordert die ALTER-Berechtigung für das Schema.

Darüber hinaus sind die folgenden Berechtigungen für jedes hinzugefügte Prädikat erforderlich:

  • SELECT- und REFERENCES-Berechtigungen für die als Prädikat verwendete Funktion.

  • REFERENCES-Berechtigung für die Zieltabelle, die an die Richtlinie gebunden wird.

  • REFERENCES-Berechtigung für jede Spalte in der Zieltabelle, die als Argument verwendet wird.

Sicherheitsrichtlinien gelten für alle Benutzer, einschließlich der Dbo-Benutzer in der Datenbank. Dbo-Benutzer können Sicherheitsrichtlinien ändern oder löschen, ihre Änderungen an Sicherheitsrichtlinien können jedoch überwacht werden. Wenn Mitglieder von Rollen wie „Administrator“, „Mitglied“ oder „Mitwirkender“ alle Zeilen sehen müssen, um Datenprobleme zu beheben oder Daten zu überprüfen, muss die Sicherheitsrichtlinie entsprechend definiert werden.

Wenn eine Sicherheitsrichtlinie mit SCHEMABINDING = OFF erstellt wird, benötigen die Benutzer*innen zum Abfragen der Zieltabelle die SELECT- oder EXECUTE-Berechtigung für die Prädikatfunktion und alle weiteren Tabellen, Sichten oder Funktionen, die innerhalb der Prädikatfunktion verwendet werden. Wenn eine Sicherheitsrichtlinie mit SCHEMABINDING = ON erstellt wird (Standard), werden diese Berechtigungsprüfungen umgangen, wenn Benutzer die Zieltabelle abfragen.

Sicherheitsaspekte: Seitenkanalangriffe

Berücksichtigen Sie die folgenden beiden Szenarien, und bereiten Sie sich darauf vor:

Schädliche Sicherheitsrichtlinien-Manager

Es ist wichtig zu beachten, dass ein schädlicher Sicherheitsrichtlinien-Manager mit ausreichenden Berechtigungen zum Erstellen einer Sicherheitsrichtlinie auf eine vertrauliche Spalte und der Berechtigung zum Erstellen oder Ändern von Inline-Tabellenwertfunktionen mit einem anderen Benutzer zusammenwirken kann, der über ausgewählte Berechtigungen für eine Tabelle verfügt, um eine Datenexfiltration durchzuführen, indem schädliche Inline-Tabellenwertfunktionen erstellt werden, die dazu dienen sollen, Seitenkanalangriffe zu verwenden, um Daten abzuleiten. Solche Angriffe sind möglich, wenn sich Benutzer abgesprochen haben, oder wenn einem böswilligen Benutzer zu hohe Berechtigungen erteilt wurden. Zudem sind vermutlich mehrere Iterationen zum Anpassen der Richtlinie vonnöten. Dazu sind Berechtigungen zum Entfernen das Prädikats erforderlich, um die Schemabindung aufheben zu können. Gleichzeitig müssen die Inline-Tabellenwertfunktionen angepasst und SELECT-Anweisungen wiederholt für die Zieltabelle ausgeführt werden. Es wird empfohlen, Berechtigungen nach Bedarf zu beschränken und das System auf verdächtige Aktivitäten zu überwachen. Aktivitäten wie das ständige Ändern von Richtlinien und Inline-Tabellenwertfunktionen im Zusammenhang mit der Sicherheit auf Zeilenebene sollten überwacht werden.

Sorgfältig erstellte Abfragen

Durch sorgfältig erstellte Abfragen, die Fehler für die Datenexfiltration verwenden, können u. U. Informationsverluste verursacht werden. Beispiel: SELECT 1/(SALARY-100000) FROM PAYROLL WHERE NAME='John Doe'; würde einen schädlichen Benutzer oder eine schädliche Benutzerin wissen lassen, dass das Gehalt von John Doe genau 100.000 USD beträgt. Auch wenn ein Sicherheitsprädikat eingerichtet ist, um zu verhindern, dass ein schädlicher Benutzer die Gehälter anderer Personen direkt abfragen kann, kann der Benutzer bestimmen, wann die Abfrage eine Division-durch-Null-Ausnahme zurückgibt.

Beispiele

Wir können die Sicherheit auf Zeilenebene für Warehouses und SQL-Analyseendpunkte in Microsoft Fabric veranschaulichen.

Im folgenden Beispiel werden Beispieltabellen erstellt, die mit Warehouse in Fabric funktionieren, aber in SQL-Analyseendpunkten vorhandene Tabellen verwenden. Im SQL-Analyseendpunkt können Sie nicht CREATE TABLE, aber CREATE SCHEMA, CREATE FUNCTION und CREATE SECURITY POLICY verwenden.

Erstellen Sie in diesem Beispiel zunächst das Schema sales und die Tabelle 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');

Erstellen Sie das Schema Security, die Funktion Security.tvf_securitypredicate und die Sicherheitsrichtlinie 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

Um eine Sicherheitsfunktion auf Zeilenebene zu ändern, müssen Sie zuerst die Sicherheitsrichtlinie aufheben. Im folgenden Skript heben wir die Richtlinie SalesFilter auf, bevor wir eine ALTER FUNCTION-Anweisung in Security.tvf_securitypredicate erteilen. Anschließend erstellen wir die Richtlinie SalesFilter neu.

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

Nächster Schritt

Implementieren von Sicherheit auf Zeilenebene beim Data Warehousing in Fabric

Zugehöriger Inhalt