Microsoft Fabric: Compliance und Sicherheit

Sensible Informationen zu speichern, zu verarbeiten und zu schützen, alles auf einer zertifizierten Cloudumgebung, ist mit Fabric aus dem Hause Microsoft möglich. Mit einem klaren Fokus auf Sicherheit, Compliance und modernste Datenverwaltung ist Fabric besonders für Branchen geeignet, in denen der Schutz sensibler Daten von grösster Bedeutung ist. In diesem Blog-Beitrag erfahren Sie, wie Microsoft Fabric strenge regulatorische Vorgaben erfüllt, kritische Daten schützt und Werkzeuge zur sicheren Handhabung personenbezogener Daten (persönlich identifizierbarer Informationen, PII) bereitstellt.

Compliance im Gesundheitswesen

«Healthcare data solutions in Microsoft Fabric», eine branchenspezifische Lösung von Microsoft Fabric, biete viele Möglichkeiten, Daten im klinischen Umfeld vertraulich zu speichern, zu kombinieren, zu verarbeiten und Erkenntnisse daraus zu gewinnen. Dabei bietet die Lösung die Möglichkeit zur Multi-Modalen Datenverarbeitung inklusive Text, Bild und natürlich (semi-)strukturierten Daten. Hierbei werden verschiedenste Standards wie FHIR, DICOM und viele weitere, sowie eine direkte Anbindung von Microsoft Dynamics 356 Customer Insights, unterstützt. Obwohl Microsoft bei seiner Fabric-Lösung für das Gesundheitswesen strenge Vorschriften wie den HIPAA (Health Insurance Portability and Accountability Act) sowie HITRUST einhält und zusätzlich zahlreiche internationale Standards wie ISO 27001, 27018, 27017, 27701, 9001 und 22301 erfüllt und die Daten ausschliesslich innerhalb der Schweizer Grenzen speichert, verbieten die Schweizer Behörden den Spitälern (noch), solche Cloud-Lösungen in ihre Datenverarbeitungs-Pipelines einzubinden.

Absichern des Datenverkehrs in Microsoft Fabric

Microsoft bietet verschiedene Möglichkeiten, um eine Netzwerkverbindung zwischen Datenquellen und Fabric herzustellen. Die Verantwortlichen wählen die Verbindung abhängig vom Standort der Datenquelle (On-Premises oder in der Azure Cloud), den Sicherheitsanforderungen und der Fabric-Komponente, die sie für die Datenerfassung einsetzen. Für On-Premises Datenquellen ist es möglich, ein On-Premises Data Gateway auf einer lokalen Maschine zu installieren. Um zu verhindern, dass die Daten über das öffentliche Internet nach Azure gelangen, kann das On-Premises Data Gateway auch in Azure bereitgestellt und eine VPN-Verbindung zur On-Premises Datenquelle hergestellt werden. Alternativ kann eine sichere ExpressRoute-Verbindung von einer On-Premises Datenquelle zu Fabric eingerichtet werden.

Für Datenquellen in der Azure Cloud können Nutzer entweder ein VNet Data Gateway oder Private Managed Endpoints einsetzen. Microsoft verwaltet das VNet Gateway, wodurch kein zusätzlicher Verwaltungsaufwand im Vergleich zum On-Premises Data Gateway entsteht. Nutzer können es allerdings nur mit Power-Platform-Ressourcen wie Dataflow Gen2 oder Semantic Models verwenden. Wer Fabric Notebooks nutzt, kann dafür Managed Private Endpoints einsetzen. Wenn andere Fabric-Komponenten für die Datenerfassung zum Einsatz kommen, empfehlen wir, das On-Premises Data Gateway auf einer Azure-VM zu installieren.

In allen drei Fällen stellen die jeweiligen Komponenten eine sichere Verbindung von Azure zu Fabric über das Microsoft-Netzwerk her.

Zwischenfazit: Wer Datenquellen – sei es On-Premises oder aus der Cloud – in Fabric einbinden möchte, hat dafür verschiedene Möglichkeiten. Je nach Anwendungsfall sollten die Verantwortlichen individuell entscheiden, welche Verbindungstechnologie am besten passt. Die folgende Tabelle zeigt die unterschiedlichen Verbindungsmöglichkeiten, ihre bevorzugten Einsatzszenarien und zugehörigen Anwendungsfälle auf:

Fabric: Präferenz der Verbindungstechnologie für bestimmte Anwendungsfälle
Abbildung 1: Präferenz der Verbindungstechnologie für bestimmte Anwendungsfälle

Die andere Möglichkeit auf Fabric zuzugreifen ist via Authentifizierungsregeln. Entscheidet man sich dazu, eignet sich Microsoft Entra Conditional Access. Bei dieser Methode wird der Zugriff auf Fabric, wie der Name bereits vermuten lässt, über die Entra ID authentifiziert, ggf. mit zusätzlichen Sicherheitsanforderungen wie Multi-Faktor-Authentifizierung, gerätespezifische Compliance oder geografische Einschränkungen. Nebst Private Links können Fabric Workspaces ihre eigene Identität haben, wodurch ein Workspace, wie jeder andere Entra-Nutzer, Zugriff auf zugewiesene Azure Ressourcen hat. Diese Art von Sicherheitsfeature nennt sich Trusted Workspace Access und ergänzt Dienste wie die privaten Endpoints oder Data Gateways, indem der Zugriff auf externe Ressourcen lediglich auf eine Workspace-Identität beschränkt ist. Bei jeder Art von Datenverkehr gilt: der Datenverkehr zwischen Microsoft Diensten ist mindestens TSL 1.2 verschlüsselt, bei ausgehendem Datenverkehr muss zusätzlich die vorhandene Zielinfrastruktur berücksichtig werden.

Absichern der gespeicherten Daten in Fabric

Im vorherigen Abschnitt haben wir gezeigt, wie sich der Datenaustausch mit Fabric absichern lässt. Jetzt betrachten wir, wie man Daten in Fabric sicher speichert. Fabric speichert Daten niemals dauerhaft ohne Verschlüsselung. Standardmässig verschlüsselt Microsoft die Daten automatisch und ohne Zusatzkosten mit sogenannten Microsoft-managed Keys (MMK). Alternativ können Anwender in bestimmten Szenarien eigene Schlüssel einsetzen – sogenannte Customer-managed Keys (CMK) – anstelle der MMKs.

Aktuell können Nutzer CMKs verwenden, um semantische Modelle sowie Cloud-Speicher wie ADLS Gen2, AWS S3 oder GCS zu verschlüsseln. Über sogenannte Shortcuts binden sie diese Speicher nahtlos in Fabric ein. Sowohl bei der Verschlüsselung mit MMK als auch mit CMKs gilt es zu beachten: Daten, die sich im Arbeitsspeicher befinden, bleiben unverschlüsselt.

Um Daten während der Verarbeitung (in Spark Clustern) möglichst von anderen VNets und externen Zugriffen zu isolieren kann Fabric ein managed VNet verwenden. Auf diese Weise ist es zum Beispiel unmöglich vom öffentlichen Internet auf unverschlüsselte Daten während der Verarbeitungsphase zuzugreifen.

Zugriff auf Daten

Rollen in Fabric

In Fabric werden 4 verschiedene Rollen verwendet, um den Zugriff auf Workspaces zu regeln. Diese sind:

  • Admin: können Workspaces und deren Artefakte erstellen, konfigurieren und verwalten sowie Benutzer und deren Zugriffsrechte zuweisen
  • Member: können Artefakte im Workspace erstellen, ändern, teilen und löschen
  • Contributor: können Artefakte im Workspace erstellen, ändern, teilen (nur wenn Erlaubnis erteilt wurde) aber nicht löschen
  • Viewer: können Artefakte im Workspace einsehen

An wen sollte welche Rolle vergeben werden? Die Administrator-Rolle sollte IT-Administratoren oder Team-Leads zugeteilt werden, welche die Gesamtumgebung oder Workspaces managen sollen. Die Member-Rolle ist ideal geeignet für Analysten dessen Aufgaben ausschliesslich das Arbeiten mit Daten, also das Erstellen von Datasets, Reports und Dashboards ist. Die Contributor-Rolle eignet sich für Entwickler die gelegentlich oder isoliert zu Artefakten in einem Workspace beitragen und die Viewer-Rolle ist für Business-Users gedacht, die keine Veränderungen an Workspace Artefakten vornehmen sollen.
Für das Vergeben der Rollen empfehlen wir das Nutzen von Entra-Gruppen. Dieser Ansatz gewährleistet einen transparenten Überblick über die Berechtigungen und macht es überflüssig, einzelnen Benutzern den Zugriff zu gewähren. Stattdessen verwalten Sie die Berechtigungen auf Gruppenebene, was die Administration vereinfacht und für Klarheit sorgt. Hierbei sollte beachtet werden, dass bei verschachtelten Gruppen die Rollenzuweisungen vererbt werden.

Detaillierter Datenzugriff

Reicht die Viewer-Rolle in einem Workspace – etwa dort, wo sich der Gold-Layer einer Medallion-Architektur befindet – nicht aus, um den Datenzugriff ausreichend einzuschränken, können Verantwortliche den Zugriff noch fein-granularer steuern. Sie setzen dazu Object-, Row- und Column-Level Security sowie Masking ein und wenden diese über den SQL-Endpoint auf ein Data Warehouse oder Lakehouse an. Aktuell unterstützt Fabric allerdings Row- und Column-Level Security nur eingeschränkt im Lakehouse.

Derzeit gibt es keine grafische Benutzeroberfläche, die es ermöglicht, diese Einstellungen zu konfigurieren oder die verteilten Rechte anzuzeigen. Daher empfehlen wir eine individuell entwickelte Lösung, die aus folgenden Komponenten besteht:

  • Eine Liste – beispielsweise eine Excel-Liste, in der alle Rechte gepflegt werden:
    • Group: Name der Entra-Gruppe
    • Type: Art der Sicherheit, zum Beispiel Objekt-Ebene / Zeilen-Ebene etc.
    • Location: Name des Lakehouse / Warehouse
    • Object: Name des Objekts und, falls erforderlich, der Spaltenname
  • Eine Data Pipeline / ein Notebook, das diese Daten synchronisiert und sicherstellt, dass auch eventuell „entzogene“ Rechte erfasst werden.
  • Eine Data Pipeline / ein Notebook, das die Rechte auf die aufgeführten Objekte anwendet.

Data Masking

Der Schutz persönlich identifizierbarer Informationen (PII) spielt für jedes Unternehmen eine zentrale Rolle. Wenn sich ein Unternehmen dafür entscheidet, Daten in der Cloud zu verwalten, kann es Dynamic Data Masking einsetzen, um PII-Daten gezielt zu schützen. Dabei wendet das System Masken auf das Result-Set einer SQL-Abfrage an, ohne die zugrunde liegenden Daten zu verändern – so bleiben vollumfängliche Analysen weiterhin möglich.

Auf diese Weise lassen sich sensible Informationen wie Löhne, E-Mail-Adressen, Telefonnummern, Namen oder Datumsangaben mithilfe von Standardberechtigungen (z. B. CREATE TABLE und ALTER) einfach maskieren. Nutzende mit ausschliesslich SELECT-Berechtigungen sehen diese Daten in maskierter Form. Wer hingegen ALTER– und UNMASK-Berechtigungen besitzt, kann entweder die Maskierung entfernen oder bei Abfragen direkt die unmaskierten Daten einsehen.

Grundsätzlich zeigt Fabric allen Nutzenden, die auf Workspace-Ebene der Rolle VIEWER zugewiesen sind, die Daten in maskierter Form.

Doch wie lässt sich überhaupt herausfinden, welche Daten besonders schützenswert sind und welche Tabellenfelder PII enthalten? Mit einigen Azure- bzw. Microsoft-Komponenten und etwas Programmieraufwand lässt sich dieser Prozess automatisieren. Dafür braucht man ein Notebook, das folgende Aufgaben übernimmt:

  • repräsentative Daten per SQL-Abfrage abholt
  • Daten in Textform, z.B. als JSON-Format, dem Azure AI-Dienst für das Erkennen von PII-Entitäten übergibt oder Microsoft Presidio verwendet, um PIIs zu erkennen
  • durch das Erkennen des Masken-Patterns aus dem AI-Dienst oder der Presidio-Bibliothek erkennt, welche Felder der Tabellen PIIs enthalten
  • die Felder mit PIIs maskiert

Sollen PIIs gar nicht erst in die Cloud übertragen werden, können diese von der Übertragung ausgeschlossen oder On-Premises verschlüsselt werden. Hierauf gehen wir aber nicht weiter ein, weil dies keine Dienste von Fabric in Anspruch nimmt.

Fazit zu Compliance und Sicherheit in Microsoft Fabric

Eine sichere und konforme Analyseumgebung erfordert einen ganzheitlichen Ansatz, der mehrere Schutzschichten integriert. Fabric verbindet moderne Verschlüsselungstechniken, Netzwerksicherheit, Methoden für Governance und diverse Techniken zum Handhaben von PII. Dies ermöglicht vielen Schweizer Unternehmen, sensible Daten sicher zu verwalten und gleichzeitig regulatorische Anforderungen zu erfüllen. Wenn Sie Ihre Daten mit mehr Sicherheit in Fabric einbinden, speichern, bearbeiten und analysieren möchten, stehen wir Ihnen mit unserer Expertise gerne zur Verfügung.

Sie wollen mehr zu Microsoft Fabric erfahren?

Buchen Sie eine Fabric in an Hour. Dies ist unser kostenloser und unverbindlicher 1:1 Experten-Call, wo wir all Ihre Fragen rund um Microsoft Fabric beantworten.

Oder erfahren Sie hier mehr über die Angebote von IT-Logix rund um Microsoft Fabric.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert