RLS, OLS und Tool-Reduktion-Maps
Ein Matrix-Schlüssel, N Durchsetzung-Adapter — Power BI RLS/OLS, Tableau User Filter, Qlik Section Access, Looker access grants; Mapping in SQL oder Skript, nicht in Excel.
Begriffe vor dem Lesen
- A11y — Accessibility / Barrierefreiheit: Gestaltung, damit Inhalte auch mit Einschränkungen zuverlässig nutzbar bleiben.
- Publish — Freigabe und Bereitstellung eines BI-Produkts für Nutzung.
- Workspace / Stage — Arbeits- oder Veröffentlichungsbereich für Entwicklung, Test und produktive Nutzung.
- Refresh — Aktualisierung von Datenmodell, Kennzahlenmodell oder Reportdaten.
- Berechtigung — Berechtigung, welche Person welche Daten oder Flächen nutzen darf.
- RLS / OLS — Row-Level- und Object-Level-Security; Zugriff auf Zeilen oder Objekte im BI-Modell.
Dataset-lokale RLS- oder OLS-Rollen driften von der Warehouse-Policy, sobald jedes Tool seine eigenen Feldnamen pflegt. Ein Business Key, mehrere Consumer-Views — Mapping in versioniertem SQL oder Skript, nicht in einer stillen Excel-Formel.
In der Praxis zeigt sich das so: Dieselbe Person sieht in Power BI Region Nord und in Qlik REGION=N — Nettoumsatz 12,4 Mio. gegen 9,1 Mio. RLS filtert Zeilen; OLS blendet Objekte aus; beides ist kein zweites führende Berechtigungsmatrix.
Dieser Teil ist keine Microsoft-Learn-Anleitung. Er mappt Adapter auf denselben Vertrag aus Teil 4 und Control-Data Teil 9.
Vorher: BI erzwingt die Berechtigungsmatrix. Fläche vor Promotion: Dashboard- und Report-Design Deep Dive. Dashboard-Betrieb danach: Dashboard Design Operating Checklist.
Entscheidung
Bauen Sie eine Adapter-Karte, keine zweite Policy.
| Adapter | Durchsetzung | Mappt von |
|---|---|---|
| Power BI / Fabric | RLS / OLS auf dem Semantic | v_pbi_rls_bridge (principal, dimension_key) |
| Tableau | User Filter / row-level security | dieselbe Key-Spalte, nicht ein Workbook-Parameter als führendes System |
| Qlik | Section Access Load | v_qlik_section_access (ACCESS, USERID, KEY) |
| Looker | access_grants / access filters |
LookML bindet den Grant an denselben Key, nicht an Explore-Namen |
OLS blendet Tabellen oder Measures aus. Das ist Objekt-Sichtbarkeit, keine Regionen-Reduktion. Beide dürfen existieren; sie dürfen nicht dieselbe Entscheidung tragen.
Transformation kanonisch → Engine gehört in versioniertes SQL oder geskriptete Loads. Template-Upload nur mit Reject-Report und Freigabe vor Publish — nie ungesteuertes Excel als Leader. Identity-Map (IdP → USERID) bleibt owned.
Dual-Run: neue View gegen die kanonische Matrix, nicht gegen das Nachbar-Tool. Warehouse-Row-Policies und BI-Adapter müssen denselben Key meinen, sonst ist „die Datenbank ist sicher“ ein anderer Filter als das Dashboard.
Adapter-Workflow
1. Key einfrieren
Architect und Control Owner nennen den Business Key. Tool-Feldnamen sind Aliase.
2. Eine View je Engine
Custodian veröffentlicht die Consumer-View. Builder verdrahten Durchsetzung daran. Wer im Dataset eine zweite Rollentabelle anlegt, öffnet Drift.
3. OLS und RLS nicht mischen
Steward dokumentiert: welche Entscheidung Zeile vs. Objekt ist. Ein verstecktes Measure ist keine Company-Reduktion.
4. Test je Adapter
Negativtest: User ohne Key sieht nichts. Positivtest: User mit Key sieht genau die Matrix-Zeile. Screenshot der RLS-UI ohne Key-Nachweis ist keine Evidence.
5. Sunset lokaler Rollen
Dataset-Rollen, Workbook-Filter und Inline-SA, die nicht aus der View kommen, bekommen Expiry oder Incident.
Handoffs
| Von | An | Artefakt |
|---|---|---|
| Architect | Custodian | Kanonischer Key + View-Vertrag |
| Custodian | Builder | Engine-View / Skript-Anschluss |
| Builder | Steward | Adapter-Test (Negativ + Positiv) |
| Steward | Control Owner | Drift: Tool-Rolle ≠ Matrix |
| Custodian | Steward | Inventory lokaler Rollen ohne View |
Anti-Patterns
- Pro Dataset eine eigene RLS-Rollentabelle
- Tableau-Parameter als führende Reduktion
- LookML-Grant am Explore-Namen statt am Key
- OLS als Ersatz für Zeilen-Berechtigung
- Mapping in Excel mit Partial Commit
- Warehouse-Richtlinie und BI-Filter auf unterschiedlichen Keys
Umsetzung im Alltag
Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.
- Arbeitsplan — BI-Publish Deep Dive
- Lernpfad — BI-Publish Deep Dive
- Weiter Operating: Dashboard Design Operating Checklist
- führende Berechtigungsmatrix: Kontrollregel-Data Deep Dive
- Key für die Board-App nennen und die existierenden Tool-Feldnamen als Aliase listen.
- Eine Engine-View (oder ein Skript) an die kanonische Matrix hängen.
- Einen Negativtest fail-closed fahren.
- Eine lokale Rollentabelle zum Sunset markieren.
Exit-Kriterien
- Produktion-Apps laden Reduktion aus einer benannten View, nicht aus Inline-Listen.
- Adapter-Karte existiert für die tatsächlich genutzten Tools — ohne Tutorial-Klon.
- Warehouse-Key und BI-Key sind derselbe Business Key.
- OLS und RLS sind getrennte Entscheidungen.
Weiterlesen
- Berechtigungsmatrizen und Section Access
- Access Security Governance
- Fabric / Power BI Metric Certification
- Dashboard Design Operating Checklist
- Dashboard- und Report-Design Deep Dive
- Microsoft Fabric als Governance-Einstieg
BI publish deep dive
Part 5 of 5
View series