vorheriger Artikel
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.
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.
Restriktionen durch die beiden Tenant Settings
Folgende Features für verschiedene Themenbereiche können durch das Aktivieren der Tenant Settings eingeschränkt werden:
Themenbereich | Private Link aktivieren | Block Public Internet Access Setting aktivieren |
Governance | One Lake Regional Endpoint wird nicht unterstützt (wird genutzt, um Data Residency einzuhalten). |
|
| Microsoft Purview Information Protection wird nicht unterstützt, wodurch in Power BI der Sensitivity-Button ausgegraut ist, Label-Informationen nicht verfügbar sind und Decryption von .pbix fehlschlägt. |
|
Migration | Workspaces zu Kapazitäten in anderer Region migrieren ist nicht möglich. |
|
| Tenant-Migrationen werden nicht unterstützt. |
|
| Fabric Trials werden nicht unterstützt. |
|
Data Engineering | Tenant muss in der Home-Region sein, in der Fabric Data Engineering unterstützt wird (unabhängig von Capacity-Region), damit Spark-Jobs genutzt werden können. | Visual Queries im Warehouse |
| Sollen Daten via Pipeline in das Lakehouse geladen werden, ist die Umsetzung möglich. Handelt es sich um ein Data Warehouse, ist aktuell keine Unterstützung vorhanden. |
|
Data Engineering IoT Focus | Shortcuts für Eventhouses sind nicht möglich. | Event Stream Feature nicht nutzbar |
| Eventhouse aus Data Pipeline aufrufen ist nicht möglich. |
|
| Daten einlesen über Queuing sowie Daten-Konnektoren, die auf Queuing angewiesen sind |
|
| Eventhouse via T-SQL abfragen |
|
Data Analysis | Funktion „Publish to Web“ ist nicht möglich. | Power-BI-Semantikmodell, Datamart oder der Dataflow Gen1 kann keine Verbindung mit einem Power-BI-Semantikmodell oder -Dataflow als Datenquelle herstellen. |
| Berichte können weder in PDF noch PowerPoint exportiert werden. | E-Mail-Abonnements von Dashboard und Bereichen sind nicht mehr möglich (Kurzübersicht der Komponente wird regelmäßig an Adressaten verschickt). |
| On-premises Data Gateway funktioniert nicht, hier ist ein Workaround notwendig. |
|
| Bei Aktivierung beider Parameter schlägt das Aktualisieren der Datenbasis für den modern Usage Metrics Report fehl. | |
User Experience | Designs und externe Bilder als Customizing des Fabric Portals nutzen |
|
Service Limits | 450 Kapazitäten unterstützt |
|
Tabelle 1: Auswirkungen der beiden Settings auf verschiedene Themenbereiche
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.
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.
Du brauchst Hilfe bei deinem Fabric-Setup mit Private Endpoints? Du möchtest wissen, ob dieses Feature wirklich notwendig für die Umgebung ist? Sprich uns an und erfahre mehr über unseren b. telligent „Way to Fabric“.
