Fabric Security: Chancen und Grenzen des Netzwerksetups

Einkommenden Datenverkehr absichern

Wenn man Netzwerksicherheit betrachtet, so muss zum einen der eingehende und zum anderen der ausgehende Datentransfer betrachtet werden.

Der eingehende Datenverkehr beschreibt den Zugriff auf Fabric selbst (z. B. das Aufrufen von app.fabric.microsoft.com). Es besteht die Möglichkeit, Fabric via Private Link in ein Netzwerk einzubinden. Dadurch ist Fabric nur noch über das interne Netzwerk verfügbar. Netzwerke aus dem Internet werden blockiert.

Dafür werden zwei Parameter im Admin Portal genutzt: Azure Private Links und Block Public Internet Access.

Private Links ermöglichen das Bereitstellen von Services über private virtuelle Netzwerke (Vnet) hinweg, ohne dass diese über ein Peering verbunden werden müssen.

Durch „Block Public Internet Access“ wird der komplette Verkehr über das Internet deaktiviert. Es ist wichtig sicherzustellen, dass der Private Link richtig konfiguriert ist, bevor das Setting aktiviert wird. Ansonsten besteht das Risiko, dass man sich selbst aus Fabric aussperrt.

Ausgehender Datenverkehr für Ziele in Azure mit Netzwerksicherheit

Bei dem ausgehenden Datenverkehr ist der Zugriff aus Fabric auf externe Datenquellen von zentraler Bedeutung. Dabei kann zwischen den verschiedenen Szenarien unterschieden werden:

Szenario 1: Azure Storage / Data Lake Gen 2 hinter Firewall

‍

Es besteht die Möglichkeit des Whitelistings aller oder einzelner Fabric Workspaces des Tenants. Es ist möglich, alle Workspaces des Tenants anzugeben, davon wird jedoch abgeraten, da das Feature zukünftig ggf. eingestellt wird.

"resourceAccessRules": [

      { "tenantId": " df96360b-9e69-4951-92da-f418a97a85eb",

         "resourceId": "/subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/Fabric/providers/Microsoft.Fabric/workspaces/b2788a72-eef5-4258-a609-9b1c3e454624"

      }

]

Hier ist allerdings nur „b2788a72-eef5-4258-a609-9b1c3e454624“ mit der eigenen Workspace ID zu ersetzen. Diese ist im Fabric Portal beim Aufrufen des Workspace zu finden und ist als Teil der URL abgebildet.

https://app.fabric.microsoft.com/groups/b2788a72-eef5-4258-a609-9b1c3e454624/list?experience=data-factory

Neben dem Netzwerk gibt es noch die Identität als Security-Parameter. Deshalb müssen noch die entsprechenden Berechtigungen gesetzt werden: Es kommen zwei Zugriffsmodelle dafür in Frage: zum einen Access Control Lists und zum anderen Role Based Access Control Assignments (RBAC). Bei RBAC Assignments ist zu bedenken, dass es für Data Lakes und Storage Accounts dedizierte Rollen gibt (z. B. Storage Blob Data Reader).

Einschränkungen auf einen Blick:

• aktuell nur von Azure Data Lake Gen 2 unterstützt
• Whitelisting auf Ebene einzelner Instance erfordert ARM-Template-Know-how
• F-Capacity notwendig

Szenario 2: Azure-PaaS-Ressourcen sind mittels Private Endpoint im Netzwerk integriert und Fabric möchte auf dieses zugreifen.

Dem ist nicht der Fall, wenn Anonymus Blob Access aktiviert ist (nur für weniger Use Cases zu empfehlen, da die Authentifizierung somit umgangen wird).

In diesem Fall ist es möglich, über Managed Private Endpoints und die Managed Vnets in Fabric zu arbeiten:

Dieser muss dann im Azure Portal approved werden:

Danach ist es möglich, mit Notebooks und Spark Job Definition über die Private Endpoints auf die Datenquellen zuzugreifen. Aktuell ist der Zugriff via Pipelines jedoch nicht möglich. Spark Notebooks benötigen CPU-Leistung, wofür im Hintergrund ein Cluster aus virtuellen Maschinen erstellt wird. Im Default teilen sich die Maschinen ein Standardnetzwerk. In diesem Szenario wird bei der erstmaligen Ausführung ein isoliertes, verwaltetes Netzwerk erstellt.

Einschränkungen auf einen Blick:

• Spark Jobs in On-demand-Cluster sind weniger schnell verfügbar als Default-Pools.
• Fabric Data Engineering Workloads müssen für Tenant- und Capacity-Region unterstützt sein: Hier kann es für die Switzerland West zu Einschränkungen kommen.
• F-Capacity notwendig
• OneLake Shortcuts werden nicht unterstützt, wenn sie auf Verbindungen auf einen Data Lake mit Private Endpoint zeigen.

Ein weiteres Szenario, das an dieser Stelle der Vollständigkeit halber erwähnt wird, ist die Konnektivität zu On-premises-Datenquellen. Um direkt auf diese Datenquellen zuzugreifen, kann das On-premises Data Gateway genutzt werden.

Abschließend lässt sich festhalten, dass das Private Endpoints Feature, über das aktuell häufig gesprochen wird, nur relevant ist, wenn eine Azure-Datenquelle angebunden werden soll, die in Azure vorhanden ist. Wenn dies der Fall ist, sollte ein Bewusstsein dafür vorhanden sein, dass die Datenquelle über Notebooks / Spark Job Definitions geladen werden muss. Zugriff via Pipeline ist nicht möglich.

Fabric selbst oder die Capacity kann nicht über einen einfachen Private Endpoint in ein Netzwerk eingebunden werden. Für diese Anforderung ist ein komplexeres Setup notwendig. Der Einsatz von einem Private Link ist notwendig, und die Tenant Settings für den Private Link und/oder Block Public Internet Access Settings müssen aktiviert werden.

Unternehmen, die keine Netzwerkintegration nutzen möchten, können allerdings auch andere Security-Maßnahmen einsetzen, wie am Anfang des Artikels beschrieben. Denn: Fabric Security ist mehr als der Einsatz von Private Endpoints.