Row-Level-Security richtig: ein Report, viele Abteilungen
Sobald ein Bericht über eine Abteilung hinaus geteilt wird, kommt die Frage: „Sieht der Bereich Nord auch die Zahlen von Süd?" Die schlechte Antwort ist, für jede Abteilung eine eigene Kopie des Berichts zu pflegen. Die gute Antwort heißt Row-Level-Security. Ein Bericht, in dem die Datenzeilen pro Nutzer gefiltert werden.
Die Ausgangslage
Ein Reporting sollte von mehreren Bereichsleitungen genutzt werden. Jede sollte denselben Bericht öffnen, aber nur die eigenen Wirtschaftseinheiten sehen. Die Geschäftsführung sollte alles sehen. Drei Kopien zu pflegen war keine Option. Jede Modelländerung hätte sich verdreifacht.
Das Problem: Filtern, ohne zu duplizieren
Row-Level-Security (RLS) schränkt die sichtbaren Zeilen abhängig vom angemeldeten Nutzer ein. Zwei Entwurfsentscheidungen bestimmen, ob das sauber funktioniert oder zur Wartungslast wird: wo gefiltert wird und wie die Zuordnung Nutzer → Daten gepflegt wird.
Die Lösung: auf Dimensionen filtern, dynamisch zuordnen
Regel 1. Auf Dimensionen filtern, nie auf Fakten. Die RLS-Regel setzt auf einer Dimension an (z. B. Wirtschaftseinheit oder Organisationseinheit). Über das Star-Schema propagiert der Filter automatisch in die Faktentabellen. Ein Filter direkt auf den Fakten wäre langsamer und müsste pro Faktentabelle wiederholt werden.
Regel 2. Dynamische statt statischer Rollen. Statt je Bereich eine eigene Rolle anzulegen, gibt es eine Regel, die den angemeldeten Nutzer (USERPRINCIPALNAME()) gegen eine Zuordnungstabelle abgleicht:
| Rolle | Filter auf | Beispiel |
|---|---|---|
| Bereichsleitung | Wirtschaftseinheit | Region = „Nord" |
| Fachbereichs-Partner | Organisationseinheit | Bereich = „Technik" |
| Geschäftsführung | kein Filter | Vollzugriff |
Neue Nutzer oder Zuständigkeiten ändert man dann in der Mapping-Tabelle. Nicht im Modell und nicht in den Rollen. Statische Rollen bleiben Prototypen und sehr kleinen Nutzergruppen vorbehalten.
Die Stolperfallen
- Auf Fakten filtern. Verlockend, weil „da stehen ja die Zahlen". Aber es bremst und skaliert nicht über mehrere Faktentabellen. Immer auf der Dimension ansetzen und den Filter fließen lassen.
- Ungetestete Regeln. Eine RLS-Regel, die nicht mit mindestens zwei Testnutzern geprüft wurde, ist eine Vermutung. „Als Rolle anzeigen" deckt auf, ob jemand zu viel oder zu wenig sieht.
- Mapping als Wildwuchs. Die Zuordnungstabelle ist sicherheitsrelevant. Sie gehört dokumentiert und gepflegt wie eine Berechtigung. Nicht als loses Beiblatt.
Das Takeaway
Ein Bericht für viele Abteilungen braucht keine Kopien, sondern eine Filterstrategie: RLS auf Dimensionsebene, dynamisch über USERPRINCIPALNAME() und eine gepflegte Mapping-Tabelle. So bleibt das Modell einfach, die Berechtigung nachvollziehbar. Und der Datenschutz, etwa bei personenbezogenen Detaildaten, durchsetzbar. Pflichtprogramm bleibt das Testen mit mehreren Nutzern, bevor der Bericht in die Breite geht.