Zum Hauptinhalt springen

Viele Security-Überlegungen rund um Azure drehen sich primär um die Netzwerksicherheit. Welche weiteren Security-Säulen im Kontext von Microsoft Fabric betrachtet werden sollten, wird im Folgenden aufgezeigt.

Security im Allgemeinen

In vielen Kundenprojekten gibt es die Anforderung, dass der komplette Netzwerkverkehr über ein internes Firmennetz laufen muss. Des Öfteren wird vergessen, dass Security mehrere Ausprägungen hat. Neben der Sicherheit des Netzwerks ist in der Cloud auch die Identität ein zentraler Gesichtspunkt. Eine weitere zentrale Frage, die sich Security-Abteilungen stellen müssen, ist der Umgang mit Verschlüsselung (Key Management), was auch unmittelbar mit Aspekten der Datensicherheit zusammenhängt. Auch Applikationssicherheit ist ein essentielles Thema.



Häufig wird der primäre Fokus auf die Sicherheit des Netzwerks gelegt, sofern die Organisation einen großen On-premises-Footprint hat und/oder branchentechnischen Regularien unterliegt. Das kann eine sinnvolle Sicherheitsmaßnahme sein, allerdings sind dadurch Services nicht per Definition sicher. Hier knüpft das aktuelle Zero-Trust-Security-Paradigma an: Es wird keiner Connection vertraut – der Aufruf wird immer gegen zentrale Policies geprüft. Dabei spielt es keine Rolle, woher diese kommt.

Somit lässt sich festhalten, dass in der Diskussion über Security mehrere Aspekte beachtet werden sollten.

Die Betrachtung diverser Themenbereiche für ein umfassendes Security-Konzept lässt sich auf das für Microsoft Fabric übertragen.

Fabric-Security-Säulen

Einige Unternehmen haben die Vorgabe, dass der komplette Netzwerkverkehr über ein internes Firmennetz laufen muss. Die Umsetzung dieser Vorgabe kann großen Einfluss auf die Architektur einer Solution und ihre Deployment-Prozesse haben. Darüber hinaus erfordert es im Betrieb mehr Ressourcen, insbesondere Zeit und Expertise. Security-Konzepte sollten sich jedoch nicht nur auf Netzwerksicherheit beschränken. Insbesondere für Fabric sind auch andere Security-Aspekte wichtig:

 

Mögliche Zero-Trust-Maßnahmen für Fabric-Implementierungen

Identitäten und Zugriffe

Zum Schutz der Identitäten und Zugriffe können Conditional Access Policies zum Einsatz kommen. Sie werden auf Entra Tenant konfiguriert und bieten die Möglichkeit, Zugriffe basierend auf Bedingungen abzulehnen oder zu genehmigen. Folgende Conditional-Access-Policy-Bedingungen können einen besonders hohen Mehrwert für die Security bedeuten:

  1. Blockieren des Zugriffs aus gewissen Ländern
  2. Zugriff nur über Devices, die Compliance entsprechen
  3. Multi-Faktor-Authentifizierung
  4. Blockieren von hohen Sign-in-Risiken (z. B. Zugriff über ToR-Browser oder anonymes VPN)
  5. Blockieren von hohen User-Risiken (z. B. bei Credential Leak, ungewöhnlichem User-Verhalten, das dieselben Muster hat wie die eines Hackers)

Die Conditional Access Policies können für die ganze Azure-Umgebung, aber auch nur für Fabric implementiert werden. Für Conditional Access Policies ist je nach Policy eine Entra-Lizenz P1 oder P2 erforderlich.

Governance und Architektur

Für die Autorisierung sollte im Rahmen der Architekturausarbeitung überlegt werden, wie die Workspaces aufgeteilt werden sollen und welche Rollen welche Berechtigungen brauchen. Die Thematik Data Security kann durch den Einsatz von Purview behandelt werden. Microsoft Purview ist eine Lösung für die Verwaltung von Daten und deren Governance in einer Organisation. Es kombiniert Datenkatalogisierung, Data Lineage, Datenklassifizierung und Datenschutzfunktionen, um eine bessere Kontrolle und Transparenz über die Datenlandschaft zu ermöglichen. Es besteht die Möglichkeit, Fabric und Purview gemeinsam zu nutzen und so beispielsweise die Daten in Fabric zu scannen. Die Customer Lockbox bietet die Möglichkeit, die Datensammlung von Microsoft für alle Cloud Services einzuschränken. Durch die Aktivierung des Features muss ein Microsoft Support Engineer einen Just-in-Time Access Request stellen, damit er auf die Umgebung zugreifen darf.

Im Rahmen der Architekturausarbeitung für die Autorisierung sollte sorgfältig überlegt werden, wie die Workspaces aufgeteilt werden sollen und welche Rollen welche Berechtigungen benötigen. Wenn Berechtigungen auf der Ebene von Fabric-Komponenten (Workspaces, Lakehouse etc.) konzipiert werden, kann es sinnvoll sein, im Zuge dessen auch festzulegen, ob bestimmte Nutzergruppen nur bestimmte Daten einsehen dürfen. Dies ist eng mit der Thematik der zeilenbezogenen Sicherheit (Row Level Security) verknüpft.

Power BI Security

Row Level Security (RLS) in Power BI ist eine Funktion, mit welcher der Zugriff auf Daten auf Zeilenebene eingeschränkt werden kann. Somit kann mithilfe von RLS gesteuert werden, welche Usergruppen bestimmte Datenzeilen in Berichten oder Dashboards sehen dürfen.

Die objektbezogene Sicherheit (Object Level Security) bestimmt, welche Tabellen oder Spalten von Usern gelesen werden dürfen. Diese Aspekte sollten alle als Komponenten in ein detailliertes Zugriffskonzept einfließen.

Artifact Security bezieht sich auf Berichte, Dashboards, Datensätze und Arbeitsbereiche. Ziel der Artifact Security ist es, den Zugriff auf diese Elemente zu steuern und sicherzustellen, dass nur autorisierte User entsprechenden Zugriff erhalten.

 

 

Fabric Security ist für deine Implementierung ein zentrales Thema? Dich interessiert, wie die Zero-Trust-Strategie auf Fabric übertragen werden kann?
Sprich uns an, um mehr über unseren b. telligent „Way to Fabric“ zu erfahren.
 

Kontaktiere uns!