In diesem Artikel befassen wir uns mit Best Practices zur Absicherung des Datenzugriffs bei der Verwendung von Microsoft Fabric Lakehouses. Das Ziel ist es, sicherzustellen, dass eure wertvollen Daten geschützt bleiben, und Personen innerhalb eurer Organisation in die Lage zu versetzen, die Teilmengen der Daten zu sehen, die für ihr Aufgabengebiet relevant sind. Am Ende werfen wir einen Blick auf die gemeinsame Nutzung von Daten mit Benutzern, die Berichte erstellen.

Wichtigste Erkenntnisse

  • Datenzugriffsbeschränkung ist wichtig.
  • Verwendet keine Datenmaskierung als Sicherheitsmaßnahme.
  • Erstellt Berichte auf Basis gemeinsam genutzter semantischer Modelle.

Ausgangspunkt

Stellen wir uns vor, wir betrachten unsere Microsoft Fabric-Plattform. Wir sehen ausgefeilte Datenpipelines, die Daten aus allen erdenklichen Quellen beziehen, die Daten nach Strich und Faden transformieren und uns mit perfekten, goldenen Daten in einem Lakehouse in Form schöner Delta-Tabellen hinterlassen.

Wie können wir nun Personen innerhalb unserer Organisation Datenzugriff gewähren und sicherstellen, dass sie:

  • Nur Tabellen sehen, die für sie relevant sind? (Object Level Security)
  • Nur Spalten sehen, die für sie relevant sind? (Column Level Security)
  • Nur Daten (Zeilen) sehen, die für sie relevant sind? (Row Level Security)

Wie können wir ihnen im Wesentlichen ermöglichen, die Daten, die sie sehen dürfen, abzufragen, das Datenmodell zu verstehen und selbst Berichte zu erstellen? Falls ihr das Schlagwort braucht: Self-Service-Reporting fördern und dabei Daten schützen.

Strategie

Zur Umsetzung dieses Ziels haben wir folgende Strategie gewählt:

Schreibgeschützte SQL-Verbindung: Benutzern wird schreibgeschützter Zugriff auf den SQL-Endpunkt des Lakehouse gewährt. Standardmäßig sind sie vor dem Zugriff auf zugrunde liegende Tabellen geschützt, was das Risiko unbeabsichtigter Änderungen oder unbefugten Zugriffs minimiert.

Row-Level Security (RLS): RLS-Mechanismen werden eingesetzt, um Daten auf Zeilenebene dynamisch basierend auf Benutzeridentitäten oder Mitgliedschaften in Microsoft-365-Gruppen zu filtern. Diese granulare Zugangskontrolle stellt sicher, dass Benutzer nur mit Daten interagieren, die für ihre zugewiesenen Rollen oder Verantwortlichkeiten relevant sind.

Column-Level Security (CLS): Als Ergänzung zu RLS schränken CLS-Konfigurationen den Zugriff auf bestimmte Spalten innerhalb von Tabellen ein und schützen so sensible Informationen vor unbefugter Offenlegung.

Datenmaskierung: Als zusätzliche Verteidigungsschicht werden Datenmaskierungstechniken eingesetzt, um sensible Informationen, die Benutzern angezeigt werden, zu verschleiern. Dieser Ansatz ist primär kosmetischer Natur und darf nicht mit CLS verglichen werden, da das Risiko von Datenlecks durch Brute-Force-Abfragen eine gegebene Tatsache ist. Siehe Beispiel weiter unten.

Semantische Datenmodelle für Self-Service-Reporting: Benutzer mit semantischen Datenmodellen zu befähigen, dient als strukturierte Abstraktionsschicht und ermöglicht ihnen, komplexe Datensätze intuitiv zu navigieren und zu interpretieren. Dieser Ansatz fördert die Selbstständigkeit bei der Berichtserstellung und stellt gleichzeitig die Einhaltung organisatorischer Datenstandards sicher.

SQL-Endpunkt teilen

Das Teilen des SQL-Endpunkts eines Lakehouse mit Empfängern oder Gruppen ist unkompliziert.

Um einem Empfänger eine grundlegende Connect-Berechtigung wie auf einem SQL-Server zu geben, ist darauf zu achten, keine der verfügbaren Freigabeoptionen auszuwählen. Dadurch sind standardmäßig keine Daten lesbar, und GRANT-Berechtigungen müssen explizit definiert werden. Eine Art Vertrau-niemandem-Strategie.

A pop-up window titled Grant people access allows users to enter emails and select permissions for SQL, Apache Spark, or dataset building within a lakehouse environment, with an option to notify recipients by email. Designed with securing data in mind, the window features Grant and Back buttons at the bottom.

Weitere Details unter MS Data Warehouse Sharing.

Row-Level Security

Row-Level Security stellt sicher, dass Benutzer nur auf Zeilen zugreifen können, die sie sehen dürfen.

Diese Einschränkungen werden direkt in der Datenschicht (Datenbank) angewendet, jedes Mal wenn auf Daten zugegriffen wird. Das macht sie zuverlässiger, robuster und weniger fehleranfällig als Einschränkungen, die in einer Anwendungsschicht angewendet werden.

Um Row-Level Security zu aktivieren, werden zwei Dinge benötigt:

  • ein Schema mit einer Inline-Tabellenwertfunktion
  • eine Sicherheitsrichtlinie, die die erstellte Funktion als Prädikat verwendet

Schauen wir uns ein einfaches Beispiel an.

Zunächst wird ein neues Schema mit einer Funktion erstellt, die 1 zurückgibt, wenn der Wert der E-Mail-Adresse mit dem des die Abfrage ausführenden Benutzers übereinstimmt. Der Benutzerwert wird über USER_NAME() ausgelesen. Um es robuster zu machen, werden alle Werte in Kleinbuchstaben konvertiert.

CREATE SCHEMA sec;
GO
CREATE FUNCTION sec.customers_validate_rlssecurity(@email as VARCHAR(500))
    RETURNS TABLE
WITH SCHEMABINDING
AS
    RETURN SELECT 1 AS validate_rlssecurity_result
    WHERE LOWER(@email) = LOWER(USER_NAME())
GO

Nun muss nur noch eine Sicherheitsrichtlinie erstellt, die Verbindung zur entsprechenden Tabelle (dbo.customers) hergestellt und der STATE auf ON gesetzt werden.

CREATE SECURITY POLICY CustomersFilter
ADD FILTER PREDICATE sec.customers_validate_rlssecurity(Email)
ON dbo.customers
WITH (STATE=ON);
GO

Während der Entwicklung kann es nützlich sein, die Richtlinie vorübergehend zu deaktivieren. Einfach den STATE auf OFF setzen.

ALTER SECURITY POLICY CustomersFilter
WITH (STATE = OFF);

Die Performance von RLS zu untersuchen ist wahrscheinlich ein eigener Blogbeitrag. Grob gesagt wird der Einfluss vergleichbar mit der Verwendung einer View sein. Zwei einfache, grundlegende Empfehlungen, die man im Hinterkopf behalten sollte:

  • Die Prädikatfunktion einfach halten. Je mehr Joins, desto schlechter die Performance.
  • Sicherstellen, dass auf referenzierten Tabellen Indizes vorhanden sind.

Column-Level Security

Nichts Besonderes hier. Zugriff für Benutzer und Gruppen nach Bedarf gewähren.

GRANT SELECT ON customers(FirstName, LastName, Email) TO [restricted.robert@cloudflight.dev];

Es ist wichtig zu wissen, dass CLS eingeschränkte Benutzer daran hindert, SELECT *-Anweisungen wie die folgende auszuführen, da diese mit einer Fehlermeldung fehlschlagen. Gewünschte Spalten müssen explizit in der SELECT-Anweisung angegeben werden.

SELECT * from customers;
Msg 230, Level 14, State 1, Line 12
The SELECT permission was denied on the column 'Age' of the object 'customers', database '****', schema 'dbo'.

In gewisser Weise kann das als eine Art Informationsleck angesehen werden, da es dem Benutzer mitteilt, dass weitere Spalten vorhanden sind und wie sie benannt sind – aber zumindest sind sie nicht zugänglich.

Es hat jedoch zur Folge, dass der direkte SQL-Endpunkt nicht nutzbar ist, wenn ein Power-BI-Bericht erstellt wird. Er schlägt bei der Verbindung zum Endpunkt mit denselben Ausnahmen wie oben fehl.

A table selection window with an error message stating SELECT permission was denied on columns in the tblcustomers table in the Tryout_CLS_RLS_MASKING database. The message, highlighted in yellow, underscores the importance of securing data access when working with Lakehouse environments.

Dieses Problem kann gelöst werden, indem ein semantisches Modell des Lakehouse erstellt und als Basis für die Berichtserstellung verwendet wird. Darauf kommen wir später zurück. Außerdem ist es der empfohlene Ansatz hinsichtlich der Performance.

Weitere Details unter MS Column-Level-Security.

Datenmaskierung

Der Hauptanwendungsfall der Datenmaskierung ist das Verbergen sensibler Daten im Ergebnis einer Abfrage.

Sie kann einfach auf Spalten angewendet werden mit einem Befehl wie:

ALTER TABLE dbo.customers;
ALTER COLUMN City ADD MASKED WITH (FUNCTION = 'default()');
GO

Das führt – wie erwartet – dazu, dass abgefragte Daten maskiert werden.

A SQL query result displaying the top 10 customers with their last names and email addresses—leveraging lakehouse architecture to streamline data access. Email addresses are shown for each customer in the query results grid.

ABER es gibt eine – aus unserer Sicht – eher alarmierende Tatsache. Datenmaskierung sollte niemals als Ersatz für Column-Level Security verwendet werden. Datenmaskierung wird angewendet, nachdem die Daten abgefragt wurden. Das macht es möglich, (automatisierte) Brute-Force-Abfragen durchzuführen, um Einblicke in die maskierten Daten zu gewinnen.

So kann man – obwohl Datenmaskierung aktiv ist – herausfinden, welche Benutzer aus der wunderbaren, imaginären Stadt Burnsmouth stammen:

Screenshot of a SQL query selecting the top 10 last names, emails, and cities where the city is Burnsmouth. The results table displays sample data with masked email and city values, demonstrating data security best practices in securing data access within a Lakehouse environment.

Mit ordnungsgemäßer Column-Level Security wäre es dem Benutzer nicht möglich, solche Einblicke zu gewinnen, da der Zugriff auf die Stadtspalte vollständig verweigert würde.

Weitere Details unter MS Dynamic Data Masking.

Berichte mit semantischen Modellen erstellen

Nachdem nun alles gesichert ist: Wie können wir Daten – einschließlich eines leicht verständlichen Datenmodells – am besten mit jemandem teilen, der Berichte erstellen möchte?

Der beste Weg, das zu erreichen, ist das Teilen semantischer Modelle.

Schauen wir uns einige der Gründe dafür an.

✔️ Erstens haben wir oben gesehen, dass Power BI bei aktivierter Column-Level Security beim Zugriff auf Daten von einem SQL-Endpunkt fehlschlägt, da es die Struktur der Tabellen nicht abfragen kann. Höchstwahrscheinlich führt Power BI ein SELECT * FROM table durch, um alle verfügbaren Spalten zu erhalten, was bei ordnungsgemäßer Column-Level Security fehlschlägt.

✔️ Zweitens ist ein semantisches Modell eine logische Beschreibung eines Auszugs aus eurem Lakehouse, meistens aus einer bestimmten Domäne (z. B. Vertrieb, Personal). Meistens wird es ein Sternschema sein und kann Benutzern, die Berichte erstellen, helfen, das Datenmodell leicht zu verstehen.

✔️ Drittens ist der Standard-Verbindungstyp bei der Verwendung semantischer Modelle der sogenannte Direct-Lake-Modus. Er kombiniert die bestehenden Verbindungstypen – Direct Query und Import – indem er ihre Vorteile vereint. Das bedeutet, dass er schnell ist und keine periodischen Aktualisierungen eures Berichtsdatensatzes erforderlich sind, um die neuesten Datenänderungen widerzuspiegeln. Darauf im Detail einzugehen wäre ein eigener Blogbeitrag. Mehr Details findet ihr hier.

Jedes Lakehouse erstellt ein Standard-semantisches Modell, aber die Empfehlung ist, spezifische für individuelle Anwendungsfälle zu erstellen, die auf die Tabellen, Beziehungen und Spalten zugeschnitten sind, die Benutzer benötigen und auf die sie Zugriff haben (kombiniert mit Column-Level Security).

Lassen wir diesen Prozess veranschaulichen.

  • Ein semantisches Modell für ein Lakehouse erstellen
  • Benötigte Tabellen einbeziehen und ihre Beziehungen modellieren
  • Alle Spalten ausblenden, die für den Benutzer aufgrund von Column-Level Security nicht sichtbar sind (alles außer dem Mitarbeiternamen aus der Dimensionstabelle)
A Power BI desktop screen shows a data model with three tables: dimension_employee, fact_sale, and one calendar table, seamlessly integrating data access from a Lakehouse environment. Table relationships are partially visible. The Properties pane is open on the right, highlighting options for securing data within the model.
  • Das semantische Modell mit einer Benutzergruppe teilen
  • Diese das semantische Modell in Power BI importieren lassen, um darauf Berichte zu erstellen
Power BI Desktop interface showing the Home tab with the Data sources menu open, displaying various options like Excel, Power BI semantic models, SQL Server, lakehouse, and web. A tooltip explains semantic model connections and highlights best practices for securing data access.

Nach der Verbindung sehen wir das erwartete Ergebnis. Die Mitarbeitertabelle zeigt nur die Mitarbeiterspalte. Aufgabe erledigt.

A Power BI Desktop screen shows a table visual with filters and data fields in the visualization pane on the right, and report tools in the top ribbon, illustrating how data security is maintained while interacting with Lakehouse data sources.

Zur Erinnerung: Bei aktivierter Column-Level Security würde die Verbindung zum SQL-Endpunkt beim Import fehlschlagen.

A screenshot of a Navigator window showing a list of database tables. An error message highlights that SELECT permissions were denied on several columns in the dimension_employee table within the SemanticModelDemo database, emphasizing the importance of data security and securing data access.

Das war’s für jetzt.

Bleibt dran für weitere Beiträge im Bereich Data Engineering mit Microsoft Fabric. Insbesondere das wichtige Thema, wie man erteilte Berechtigungen und Sicherheit im Allgemeinen automatisch testet, könnte eine interessante nächste Lektüre sein.