Ein erfolgreicher Commit mit einem Entwicklungskonto belegt noch nicht, dass derselbe Änderungsstand den Test- und Produktions-Workspace erreicht. Ab dem 1. Dezember 2026 prüft Fabric für die Git-Integration die Rechte an den betroffenen Elementen genauer. Repository, Netzwerk und Deployment bleiben eigene Kontrollpunkte.
Der riskanteste Teil dieser Umstellung liegt an der Schnittstelle zwischen Workspace-, Element- und Repository-Rechten. Ein grüner Test auf einer Ebene kann fehlende Rechte auf einer anderen verdecken.
Dieses Runbook verknüpft die Berechtigungsprüfung mit dem Netzwerktest, dem Deployment und dem Rollback. Für jeden produktiven Workspace entsteht ein Protokoll, das Identität, Operation, erwartetes Ergebnis und tatsächliches Ergebnis festhält.
Was ändert sich bei der Microsoft Fabric Git-Integration?
Ab dem 1. Dezember 2026 reicht die Contributor-Rolle für die Git-Integration nicht mehr allein aus. Für Commit und Workspace-Update prüft Fabric zusätzlich den Lese- und Schreibzugriff auf jedes betroffene Element. Repository- und Branch-Rechte beim Git-Anbieter bleiben für dieselbe Identität eine separate Voraussetzung.
Eine Workspace-Rolle legt den allgemeinen Zugriff innerhalb eines Workspace fest. Elementberechtigungen steuern dagegen den Zugriff auf einzelne Lakehouses, Notebooks, Pipelines oder Eventstreams. Sensitivity Labels und Protection Policies können eine Git-Operation verhindern, obwohl die Workspace-Rolle und die Rechte beim Git-Anbieter ausreichen.
Nur Personen mit Administratorrolle dürfen ein Repository mit einem Workspace verbinden oder die Verbindung trennen. Mitglieder und Contributors benötigen für Commits und Updates die erforderlichen Rechte an allen betroffenen Elementen. Branch-Operationen setzen zusätzlich die Freigabe im Workspace und die passenden Rechte beim Git-Anbieter voraus.
Berechtigungsmatrix für den Git-Audit
| Identität | Fabric-Rechte | Git-Rechte | Zu testende Operationen |
|---|---|---|---|
| Workspace-Administrator | Administratorrolle sowie Lese- und Schreibzugriff auf alle betroffenen Elemente | Repository- und Branch-Rechte beim Git-Anbieter | Verbindung verwalten, Commits übertragen und Branches bedienen |
| Mitglied | Lese- und Schreibzugriff auf alle betroffenen Elemente | Schreibrecht im Repository und die erforderlichen Branch-Rechte | Commit, Workspace-Update und freigegebene Branch-Operationen |
| Contributor | Lese- und Schreibzugriff auf alle betroffenen Elemente | Schreibrecht im Repository und die erforderlichen Branch-Rechte | Commit, Workspace-Update und freigegebene Branch-Operationen |
| Gastkonto | Kein regulär unterstützter Betriebsweg für die Fabric Git-Integration | Separate Rechte beim Git-Anbieter ändern diese Einschränkung nicht | Negativtest und dokumentierte Ausnahme vom vorgesehenen Betriebsmodell |
| Service Principal | Workspace-Rolle, Elementrechte und aktivierter Zugriff auf die verwendeten Fabric-APIs | Das Authentifizierungsmodell des konkret genutzten API-Endpunkts | Nur die von der API unterstützten und separat getesteten Operationen |
Eine Rollenliste reicht für das Audit daher nicht aus. Das Inventar muss jede Identität mit ihren Elementrechten, Repository-Rechten und vorgesehenen Operationen verknüpfen.
Welche Konten und Workspaces gehören in das Audit?
Relevant sind alle Workspaces mit einer Verbindung zu Azure DevOps, GitHub Cloud oder GitHub Enterprise Cloud. Der Workspace muss einer für die Git-Integration unterstützten Kapazität zugeordnet sein.
Für jeden Workspace erfasst das Protokoll folgende Angaben:
- Der Datensatz nennt die Workspace-ID und die zugeordnete Kapazität
- Er verknüpft den Git-Anbieter mit Repository und Branch
- Er führt alle Personen mit Administrator-, Mitglieds- oder Contributor-Rolle auf
- Er nennt die technischen Identitäten und die verwendeten API-Endpunkte
- Er dokumentiert Sensitivity Labels und Protection Policies
- Er hält Private Link und Outbound Access Protection fest
Folgende Befunde benötigen einen eigenen Testfall:
- Ein Konto besitzt nicht für jedes versionierte Fabric-Element Lese- und Schreibzugriff
- Ein Gastkonto ist noch in einem Git- oder Deployment-Prozess eingetragen
- Eine Automation nutzt einen nicht geprüften Service Principal oder API-Endpunkt
- Ein Freigabe-, Notfall- oder Deployment-Konto wurde längere Zeit nicht getestet
- Ein Element trägt ein Sensitivity Label oder unterliegt einer Protection Policy
Nach den Identitäten und Elementrechten folgt der Netzwerkpfad als nächste unabhängige Kontrollstelle.
Git-Integration mit Netzwerkschutz abstimmen
Outbound Access Protection sperrt die Git-Integration zunächst. Eine Person mit Administratorrolle muss Git für den jeweiligen Workspace ausdrücklich zulassen. Eine allgemeine Tenant- oder Capacity-Einstellung ersetzt diese Workspace-Freigabe nicht.
Private Link verändert zusätzlich den Zugriffsweg auf Fabric. Der Test muss deshalb aus dem Netzwerk erfolgen, über das später auch die Administration und das Deployment arbeiten. Ein erfolgreicher Versuch außerhalb dieses geschützten Pfads belegt nicht, dass der Produktionszugriff funktioniert.
Das Protokoll hält für jede Ausnahme den Workspace, die zugelassene Verbindung, die verantwortliche Person und das nächste Prüfdatum fest. Erst wenn dieser Pfad funktioniert, lässt sich die Trennung der Zielumgebungen prüfen.
Entwicklung, Test und Produktion trennen
Ein mögliches Modell verbindet den Entwicklungs-Workspace mit einem Entwicklungs-Branch, den Test-Workspace mit einem Release-Branch und den Produktions-Workspace mit dem freigegebenen Haupt-Branch. Die Repository-Administration, die Entwicklung, die Deployment-Freigabe und der Produktionszugriff liegen bei getrennten Rollen.
Git überträgt versionierte Elementdefinitionen zwischen Repository und Workspace. Fabric Deployment Pipelines vergleichen und verteilen dagegen die unterstützten Elemente zwischen den Workspaces. Ein Commit sollte deshalb genau einen fachlich zusammengehörigen und rücksetzbaren Änderungsstand enthalten, den ein Pull Request vor dem Deployment prüft.
Branch-Policies, Pull Requests und Freigabeschritte sind auch Gegenstand der DevOps-Schulungen. Umgebungswerte dürfen diese Trennung nicht durch fest codierte IDs umgehen.
Fest codierte IDs durch Variable Libraries ersetzen
Repository-Commits sollten Elementdefinitionen enthalten, aber keine wechselnden IDs oder Verbindungsreferenzen. Eine Fabric Variable Library speichert solche Werte außerhalb der einzelnen Artefakte. Getrennte Value Sets liefern die Werte für Entwicklung, Test und Produktion, ohne den freigegebenen Artefaktstand zu verändern.
Variable Libraries lassen sich unter anderem mit Pipelines, Lakehouse Shortcuts, Notebooks, Dataflows Gen2 und Copy Jobs verwenden. Eine Library unterstützt höchstens 1.000 Variablen und 1.000 Value Sets, insgesamt unter 10.000 Variablenwerte sowie eine Item-Größe von maximal 1 MB. Bei größeren Beständen bietet sich eine Aufteilung nach Domäne oder Deployment-Einheit an.
Vorschaufunktion: Connection-Reference-Variablen befinden sich noch in der Vorschau. Sie speichern die ID einer externen Verbindung, aber weder Anmeldedaten noch Verbindungszeichenfolgen. Die Unterstützung hängt vom verwendeten Fabric-Element ab und muss vor dem produktiven Einsatz gegen die aktuelle Support-Matrix geprüft werden.
Der Test muss neben dem Artefaktstand auch das aktive Value Set und die tatsächlich aufgelösten Zielwerte erfassen. Diese Prüfung gehört deshalb in jeden Deployment- und Rollback-Test.
Wie sieht ein vollständiger Testplan aus?
Die Berechtigungsmatrix bestimmt, welche Operation eine Identität ausführen darf. Ein Administrator testet andere Schritte als ein Contributor. Ein Gastkonto dient nur als Negativtest, während jede produktiv verwendete Automation einen eigenen API-Test benötigt.
- Eine Person mit Administratorrolle testet die Repository-Verbindung und eine erneute Authentifizierung
- Mitglied und Contributor committen jeweils eine zusammengehörige Änderung
- Ein berechtigtes Konto aktualisiert den Workspace aus dem Repository
- Ein freigegebenes Konto erstellt oder wechselt einen Branch
- Ein absichtlich unzureichend berechtigtes Konto scheitert an der erwarteten Kontrollstelle
- Eine freigabeberechtigte Person deployt den Stand nach Test und Produktion
- Ein Git-Revert stellt die versionierte Elementdefinition wieder her und löst ein erneutes Deployment aus
Das Testteam wiederholt die Fälle mit Sensitivity Labels, Protection Policies, Private Link und Outbound Access Protection. Berechtigte Konten müssen alle vorgesehenen Schritte ausführen. Nicht berechtigte Konten müssen an der zuvor festgelegten Kontrollstelle scheitern.
Ein Git-Revert stellt nur versionierte Elementdefinitionen wieder her. Gelöschte oder veränderte Daten, externe Verbindungen, Anmeldedaten und bereits ausgelöste Seiteneffekte setzt Git nicht zurück. Das Rollback endet daher erst nach dem erneuten Deployment, der Zuweisung des vorgesehenen Value Sets und einer fachlichen Prüfung des Zielstands.
Eventstreams unterstützen die Git-Integration und Deployment Pipelines nicht für jede Quelle, jedes Ziel und jede Funktion im gleichen Umfang. Cross-Workspace-Abhängigkeiten und Eventhouse-Ziele mit Direct Ingestion benötigen eigene Tests. Das Microsoft Fabric Real-Time Intelligence Training mit KQL behandelt die Konfiguration von Eventhouses, KQL-Datenbanken und Eventstreams.
Der Zusammenhang zwischen CI/CD, Sicherheit, Governance und Monitoring gehört zum DP-700 Training für Microsoft Fabric Data Engineers. Das Audit-Protokoll sollte für jeden Fehler mindestens die Identität, das Element, die Operation und die betroffene Kontrollstelle enthalten. Diese Angaben führen direkt zur Fehlerdiagnose.
Häufige Fehlerbilder diagnostizieren
Ein abgewiesener Commit oder ein fehlgeschlagenes Workspace-Update weist häufig auf fehlende Elementrechte hin. Das Protokoll muss dann Workspace-Rolle, Elementberechtigung, Sensitivity Label und Protection Policy getrennt ausweisen. Bei Verbindungsfehlern kommen die Git-Authentifizierung, Outbound Access Protection, Private Link oder eine Branch-Policy als Ursache infrage.
Git und Branches
Rate-Limits, unterschiedliche Authentifizierungsverfahren, Branch-Policies und fehlende Freigaben erklären Abweichungen zwischen Testkonten. Das Fehlerprotokoll sollte deshalb auch den Git-Anbieter und den betroffenen Branch nennen.
Variablen und Deployments
Ein nicht gespeichertes Value Set, eine falsche Umgebungszuweisung oder eine vom Element nicht unterstützte Variable führt zu unerwarteten Zielwerten. Der Vergleich muss den erwarteten und den tatsächlich aufgelösten Wert zeigen.
Eventstreams
Nicht unterstützte Komponenten, Cross-Workspace-Abhängigkeiten und Direct Ingestion können nach dem Deployment manuelle Schritte erfordern. Diese Schritte gehören mit verantwortlicher Person und Prüfergebnis in das Runbook.
Rollback
Ein Git-Revert setzt den Quellstand zurück, aber nicht die Daten oder externen Seiteneffekte. Das Protokoll muss deshalb das erneute Deployment, das aktive Value Set und die fachliche Prüfung getrennt bestätigen.
Aus diesen Fehlerklassen ergibt sich eine Checkliste, die für jeden Workspace erneut verwendet werden kann.
Audit-Checkliste
- Alle Workspaces, Repositories und Branches sind im Inventar erfasst
- Die Elementrechte aller vorgesehenen Identitäten sind dokumentiert
- Sensitivity Labels, Protection Policies und Netzwerkausnahmen sind den betroffenen Elementen zugeordnet
- Commits, Updates, Branch-Operationen und Deployments wurden mit Positiv- und Negativtests geprüft
- Das aktive Value Set und die aufgelösten Zielwerte sind je Umgebung protokolliert
- Eventstream-Einschränkungen enthalten die erforderlichen manuellen Schritte
- Der Rollback stellt den freigegebenen Zielstand nachweisbar wieder her
Sind alle Punkte einem Testergebnis und einer verantwortlichen Person zugeordnet, lässt sich der Abschluss des Audits belegen.
Fazit: Berechtigungen als Deployment-Abhängigkeit behandeln
Das Audit endet erst, wenn eine berechtigte Identität den Weg durch Repository, Workspace, Netzwerk und Deployment durchläuft und ein absichtlich unzureichend berechtigtes Konto an der vorgesehenen Kontrollstelle scheitert. Lege als ersten Schritt das Workspace-Inventar an und ordne jedem Eintrag eine verantwortliche Person zu.