28.10.2024
16.6.2025
16.6.2025
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.
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.
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:
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:
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.
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.
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.
Domain Lead Data Platform & Data Management
Domain Lead Data Platform & Data Management
b.telligent – das ist Data Analytics, AI, Customer Engagement und Data Visualisation. Das ist Deutschland, Österreich, die Schweiz und Rumänien. Doch das Entscheidende ist unser Team: Menschen mit echter Leidenschaft für Daten, die gemeinsam innovative Lösungen schaffen und Unternehmen nachhaltig voranbringen
Die Kubernetes SIG Network und das Security Response Committee haben das Supportende für Ingress NGINX angekündigt. Bis März 2026 erhält somit einer der beliebtesten Ingress-Controller für Kubernetes nur noch Best-Effort-Unterstützung. Warum Du jetzt handeln solltest.
Du willst Deine Infrastruktur mit Terraform verwalten, aber dann passiert es doch, dass Änderungen manuell gemacht wurden – und Du eine Lösung dafür finden musst. Der Umgang damit unterscheidet sich von Fall zu Fall.
Es ist eine große Stärke von Terraform, dass es mit Änderungen außerhalb der von ihm verwalteten Ressourcen umgehen kann. Die Stichworte sind: data, import, removed, ignore_changes, lock, variables.
Kein vorheriger Beitrag
Kein nächster Beitrag
