Entscheidungen¶
Diese Seite fasst die Architekturentscheidungen der Base Fabric Data Platform zusammen: das geschriebene ADR zum RBAC-Modell und die Designentscheidungen, die im HLD und in den Runbooks der Lösung festgehalten sind.
ADR: RBAC-Modell für Datenverarbeitungsressourcen¶
Status: vorgeschlagen. Teile davon sind im Code umgesetzt, siehe Was der Code heute tut.
Kontext¶
Die Lösung deployt mehrere Ressourcen, die an der Datenverarbeitung beteiligt sind: Fabric capacities, Workspaces, Storage Accounts, Key Vaults, Virtual Networks und Log-Analytics-Workspaces. Ein RBAC-Modell mit minimalen Rechten muss Folgendes ermöglichen:
- automatisiertes Deployment durch einen Service Principal,
- Data Engineers entwickeln und testen pipelines,
- Plattform-Engineers verwalten Capacity und Infrastruktur,
- Observability ohne überprivilegierten Zugriff.
Entscheidung¶
| Rolle | Scope | Zweck | Zugewiesen an |
|---|---|---|---|
| Fabric Capacity Operator (benutzerdefiniert) | Gemeinsame Resource group | Capacities pausieren und fortsetzen | Managed Identity der Logic App, Gruppe der Plattform-Engineers |
| Fabric Workspace Admin | Workspace | Volle Verwaltung des Workspaces | Deployment-Service-Principal, Gruppe der Plattform-Engineers |
| Fabric Workspace Contributor | Workspace | pipelines, Notebooks, Dataflows entwickeln | Gruppe der Data Engineers |
| Fabric Workspace Member | Workspace | pipelines ausführen, Items ansehen | Gruppe der Data Analysts |
| Fabric Workspace Viewer | Workspace | Nur Lesezugriff auf Berichte und Dashboards | Gruppe der Business-Benutzer |
| Storage Blob Data Contributor | Storage Account | Lakehouse-Daten lesen und schreiben | Deployment-Service-Principal, Gruppe der Data Engineers |
| Key Vault Secrets User | Key Vault | Secrets für Connections lesen | Deployment-Service-Principal, Managed Identity des Workspaces |
| Key Vault Administrator | Key Vault | Lebenszyklus der Secrets verwalten | Nur Deployment-Service-Principal |
| Log Analytics Reader | Log-Analytics-Workspace | pipeline-Logs abfragen | Data Engineers, Plattform-Engineers |
Die benutzerdefinierte Rolle Fabric Capacity Operator gewährt nur Microsoft.Fabric/capacities/read, write, suspend/action und
resume/action. Sie ist benutzerdefiniert, weil keine eingebaute Rolle Pause und Resume ohne die weitergehenden Contributor-Rechte erlaubt, die
auch das Löschen einer Capacity oder das Ändern ihrer SKU zulassen würden. Das ist für eine Automatisierungs-Identity nicht akzeptabel.
Prinzipien der Zuweisung:
- Deployment-Service-Principal: das Minimum für Infrastructure as Code (Secrets erstellen, Storage konfigurieren, Workspaces erstellen und konfigurieren).
- Managed Identity der Logic App: nur die benutzerdefinierte Rolle. Sie kann keine Secrets lesen, kein Storage ändern und nicht auf Workspace-Inhalte zugreifen.
- Plattform-Engineers (Entra-Gruppe): Fabric Capacity Operator für manuelles Pausieren und Fortsetzen sowie Log Analytics Reader. Kein direkter Zugriff auf Daten in Lakehouses oder Warehouses.
- Data Engineers (Entra-Gruppe): Workspace Contributor, Storage Blob Data Contributor und Key Vault Secrets User, damit sie pipelines durchgängig entwickeln und testen können.
- Data Analysts und Business-Benutzer: nur Workspace Member oder Viewer. Kein Infrastrukturzugriff.
Workspace-Rollen werden innerhalb von Fabric zugewiesen, nicht mit Azure RBAC, über die Ressource fabric_workspace_role_assignment.
Konsequenzen¶
- Alle Rollenzuweisungen sind Code. Keine Ad-hoc-Zuweisungen im Portal.
- Die benutzerdefinierte Rolle begrenzt den Schadensradius von Automatisierungs-Identities.
- Entra-ID-Gruppen sind die Einheit der Zuweisung. Einzelne Benutzer erhalten nie direkte Rollen.
- Die Produktion verwendet dasselbe Modell, braucht aber für jede Gruppenzuweisung ein explizites Opt-in.
- Eine neue Persona (zum Beispiel ein Data Steward) bedeutet, das ADR und die Terraform-Variablen zu aktualisieren.
Zukunft: Conditions auf Rollenzuweisungen¶
Wenn eine Automatisierungs-Identity Zugriff delegieren muss (zum Beispiel eine Workspace Identity, die pipeline-Läufen Storage-Zugriff gewährt), können Conditions auf Azure-Rollenzuweisungen begrenzen, welche Rollen sie zuweisen darf. Das sollte geprüft werden, sobald der Bedarf entsteht.
Was der Code heute tut¶
| Punkt | Im Code |
|---|---|
| Benutzerdefinierte Rolle Fabric Capacity Operator | Im Shared Tier umgesetzt, auf die gemeinsame Resource group begrenzt. Zugewiesen an die Logic-App-Identities und an capacity_operator_group_ids. |
| Workspace-Rollen | Umgesetzt für die Gruppen Admin, Contributor, Member und Viewer, pro Workspace |
| Storage-Rollen | Die Deployment-Identity erhält Storage Account Contributor und Storage Blob Data Contributor auf dem Data Lake. Der Code weist Data Engineers keine Storage-Rollen zu. |
| Key-Vault-Rollen | Die Storage-Identity erhält Key Vault Crypto Service Encryption User. Der Code weist Gruppen keine Key-Vault-Rollen zu. |
| Log Analytics Reader für Gruppen | Wird von diesem Code nicht zugewiesen. Die Grafana-Identity erhält Log Analytics Reader und Monitoring Reader. |
Wo ADR und Code abweichen, ist der Code das, was deployt ist. Behandle die obige Rollentabelle als Zielmodell.
Designentscheidungen¶
| Entscheidung | Grund |
|---|---|
| Capacities in einer gemeinsamen subscription | Eine Capacity kann eine oder mehrere Umgebungen bedienen, was die Kosten senkt. Eine eigene Capacity pro Umgebung bleibt möglich, weil jeder Workspace seine Capacity benennt. |
| Eine subscription pro Umgebung, auf dem spoke canvas | Isolation pro Umgebung, wobei die Plattform-Baseline (Netzwerk, DNS, Policy) vom spoke geerbt wird |
| Ausgehender Verkehr standardmäßig verweigert, erlaubt über das Gateway oder Managed Private Endpoints | Verhindert Datenabfluss |
| Ein VNet Data Gateway pro Capacity, pro Workspace eingeschränkt | Workspaces können nur das vorgesehene Gateway verwenden |
| Git nur auf Entwicklungs-Workspaces im Basis-Setup | Die Produktion wird über CI/CD deployt, was kontrollierter ist als eine direkte Git-Integration |
| Customer-managed Key plus Infrastructure Encryption auf dem Data Lake | Kontrolle über den Schlüssel und doppelte Verschlüsselung im Ruhezustand |
| Zugangsdaten nur im Key Vault | Nie in Code oder Konfiguration. Connections verweisen per Name auf Secrets. |
| Optionale Admin-Gruppe pro Workspace | Das Workload-Team verwaltet Workspace-Benutzer und -Einstellungen ohne Ticket, während Network Policy und Capacity beim Plattform-Team bleiben |
| Terraform als Single Source of Truth | Reproduzierbar, nachvollziehbar, konsistent. Manuelle Änderungen werden zurückgenommen. |
| Auto-Pause ist Opt-in, manuelles Resume ist der Default | Spart Kosten bei Nicht-Produktions-Capacities, ohne die Produktion zu gefährden oder Benutzer zu überraschen |
| Auto-Pause verwendet eine benutzerdefinierte Rolle mit minimalen Rechten | Siehe das ADR oben |
| Purview als Shared Infrastructure, automatische Fabric-Registrierung | Ein Katalog für alle Workspaces, keine manuelle Registrierung von Quellen |
| Grafana-Gruppen getrennt von Fabric-Gruppen | Anderer Schadensradius |
| Grafana wird als eigener Tier mit eigenem State deployt | Unabhängiger Lebenszyklus. Dashboards sind Code im Konfigurations-Repository. |