Wie kann ich Datenquellen, die über Private Endpoints abgesichert sind, in Fabric einbinden? Wie gehe ich mit Azure Data Lakes hinter einer Firewall um? Der Blog-Beitrag zeigt auf, welche Möglichkeiten Fabric nativ bietet.
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.
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.
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:
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:
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.
Du willst den IoT Core durch eine Multi-Cloud-Lösung ersetzen und die Vorteile weiterer IoT-Services von Azure oder Amazon Web Services nutzen? Dann melde Dich bei uns und wir unterstützen Dich bei der Umsetzung mit unserer Expertise und dem b.telligent Partnernetzwerk.
Geschäftsführer
Viele Nutzer:innen des Google IoT Core sind aktuell auf der Suche nach einer Nachfolgelösung für den im August 2023 auslaufenden Google-Service. In diesem Blogbeitrag zeigen wir Dir, wie sich mit Hilfe der Stackable-Datenplattform eine hochskalierbare Open-Source-Alternative zum Google IoT Core realisieren lässt.
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.
Fehlende Ressourcen oder technische Herausforderungen sind häufig Blockaden, wenn es darum geht, den Wertbeitrag und die Machbarkeit eines IoT Use Cases zu ermitteln und späteren Projektsponsoren vorzustellen. Selbst simple IoT Use Cases benötigen teils Wochen anstatt Tage, um greifbare Ergebnisse hervorzubringen. Wir möchten im Rahmen dieses Blockbeitrags unsere IoT-Kickstarter-Plattform aufzeigen, die es ermöglicht, „einfache“ IoT Analytics Use Cases innerhalb weniger Tage unter technischen Gesichtspunkten zu verproben.
Kein vorheriger Beitrag
Kein nächster Beitrag
