Multi-Mandanten Power BI sicher umsetzen

Definition

Multi-Mandanten Power BI beschreibt eine Architektur, in der mehrere organisatorisch getrennte Mandanten über eine gemeinsame Power-BI-Plattform Berichte nutzen, ohne gegenseitige Dateneinsicht. Es ist nicht nur ein gemeinsamer Bericht mit Filter, sondern eine Kombination aus Datensegmentierung, Zugriffskontrollen, Workspace-Struktur und Betriebs-Logging.

Einleitung

Wenn Kommunen Kennzahlen im Portal abrufen, darf jede nur die eigenen Daten sehen und ihr müsst das später auch nachweisen können. Genau hier scheitern viele Prototypen: technisch läuft’s, aber Datentrennung, Betrieb und Compliance sind wackelig. Dieser Überblick zeigt dir, wie du „multi mandanten power bi“ so aufsetzt, dass es sicher und skalierbar bleibt.

Marktüberblick: Die gängigen Multi-Tenant-Modelle

In der Praxis gibt es drei Muster, die sich vor allem in Risiko und Betriebsaufwand unterscheiden. Wichtig: Die Entscheidung ist weniger „Tool-Frage“, sondern „Sicherheitsgrenze und Betrieb“.

• Gemeinsames Modell mit RLS: Ein semantisches Modell für alle, Trennung per Row-Level Security. Schnell im Start, aber erfordert disziplinierte Rollenpflege und harte Kontrollen gegen Datenabfluss.

• Workspace pro Mandant: Berichte/Modelle sind je Kommune getrennt, optional zusätzlich RLS innerhalb der Kommune. Klarere Isolation, dafür mehr Automatisierung für Anlage und Betrieb nötig.

• Separate Kapazität/Umgebung für Sonderfälle: Für sehr große Mandanten oder besondere Anforderungen (z. B. eigene Leistungszusagen) kann eine getrennte Kapazität sinnvoll sein. Das ist teurer im Betrieb, senkt aber Konflikte und Lärm zwischen Mandanten.

Datensegmentierung mit Row-Level Security (RLS)

RLS ist der Kern der Datentrennung im gemeinsamen Modell: Benutzer sehen nur die Zeilen, die zu ihrem Mandanten passen. Der praktische Nutzen: Du kannst ein einheitliches Datenmodell für alle bauen und trotzdem kommunenscharf ausspielen, ohne Berichte zu duplizieren.

Typische Fehler, die RLS entwerten: Mandantenfilter nur „im Bericht“ (änderbar), zu breite Rollen („alle Kommunen“), oder unklare Zuordnung zwischen Portal-Identität und Power-BI-Identität. RLS muss an einer stabilen Mandanten-ID hängen und über Rollen/Mapping sauber ausgerollt werden.

Arbeitsbereiche (App Workspaces) als Sicherheits- und Betriebsstruktur

Workspaces sind nicht nur Ablage, sondern dein Ordnungsprinzip für Berechtigungen, Deployment und Mandantenbetrieb. Ein Workspace pro Kommune macht Verantwortlichkeiten und Zugriffe greifbar: Wer darf veröffentlichen, wer nur konsumieren, wer verwaltet?

Für Embedded-Szenarien helfen Service-Principal-Profile, Mandanten organisatorisch zu trennen und die Token-Erzeugung kontrolliert zu halten. Das zahlt direkt auf den Betrieb ein: Neue Kommune anlegen heißt dann nicht mehr „händisch klicken“, sondern standardisiert provisionieren.

Audit Logs, Monitoring & Compliance: Nachweise statt Bauchgefühl

Wenn rechtliche Vorgaben Trennung verlangen, brauchst du Belege: Wer hat wann welchen Bericht aufgerufen, geändert oder geteilt? Power BI Audit Logs liefern diese Spuren. Der Nutzen ist sehr praktisch: Bei Rückfragen kannst du erklären, was passiert ist, statt wochenlang zu rekonstruieren.

Monitoring gehört genauso dazu: Kapazitätsauslastung, Refresh-Dauer je Mandant, Anzahl Aufrufe und Fehlerquoten. Damit erkennst du, welche Kommunen stark ziehen, ob dein Refresh-Fenster kippt und ob Provisioning-Skripte wirklich schneller werden.

Zugriffskontrollen: MFA, Rollen, Export- und Sharing-Regeln

Multi-Tenant heißt auch: Du schützt nicht nur den Zugriff, sondern den Abfluss. Dazu gehören Tenant Settings im Power BI Admin Portal, saubere Rollenmodelle und klare Regeln für externe Freigaben.

• MFA und minimale Rechte: Multi-Factor Authentication reduziert Kontoübernahmen; Rollen sollten nach dem Prinzip „so wenig wie möglich“ vergeben werden.

• Export- und Sharing-Beschränkungen: Wenn Nutzer Daten nach Excel/PDF exportieren oder Inhalte teilen können, verlässt die Kontrolle schnell die Plattform. Definiere pro Sensitivitätsstufe, was erlaubt ist.

• Embedding sicher aufsetzen: Embed-Token müssen stets mandantenspezifisch erzeugt werden; ein „generischer“ Token ist ein typischer Hebel für Datenlecks.

Datenklassifikation und Sensitivitätskennzeichnungen

Sensitivitätskennzeichnungen (Microsoft Information Protection / Purview) machen klar, wie vertraulich Bericht, semantisches Modell oder Export sind. Der Nutzen: Anwender sehen auf einen Blick, was sie weitergeben dürfen, und du kannst Regeln technisch durchsetzen (z. B. Export einschränken oder Wasserzeichen/Schutzmechaniken anstoßen).

Gateway-Sicherheit und On-Prem-Datenverschlüsselung

Wenn Daten aus On-Premises-Datenbanken kommen, ist das Gateway Teil der Sicherheitskette. Praktisch heißt das: ein gehärtetes Gateway-Setup, klar getrennte Dienstkonten, kontrollierte Datenquellen und abgesicherte Verbindungen. Sonst ist die Power-BI-Sicherheit sauber, aber der Datenweg drumherum offen.

Mini-Story: Vom PDF-Team zur Mandantenplattform

Ein IT-Dienstleister ersetzt PDF-Reports durch ein Portal mit Power BI Embedded. Im Prototyp wird per Bericht-Filter zwischen Kommunen gewechselt; nach dem ersten Audit ist klar: Das ist keine Datentrennung. Mit RLS plus Workspace-Struktur pro Kommune, Audit Logs und klaren Exportregeln wird daraus eine Plattform, die neue Mandanten per Skript anlegt und Zugriffe nachvollziehbar dokumentiert.

Kosten, Nutzen, Voraussetzungen: die entscheidende Einordnung

Kosten? Multi-Tenant wird teuer, wenn man versucht, fehlende Struktur mit manuellen Prozessen zu kompensieren. Investitionen lohnen sich vor allem in Automatisierung (Provisioning), Monitoring und klare Governance, weil das den Betrieb planbar macht.

Lohnt sich das? Ja, wenn viele Mandanten ähnliche Kennzahlen brauchen und du „einmal bauen, vielfach ausrollen“ willst, ohne Sicherheitsrisiko. Für sehr große Mandanten mit Sonderanforderungen kann eine getrennte Kapazität/Umgebung trotzdem wirtschaftlicher sein als ständige Konflikte in einer gemeinsamen.

Voraussetzungen? Eindeutige Mandanten-ID in den Daten, ein sauberes Rollen-/Berechtigungskonzept, zentrale Identitäten (Entra ID bzw. kontrollierte Portal-Anmeldung) und definierte Betriebsprozesse für Anlage, Änderungen und Offboarding.

Wann externe Unterstützung sinnvoll wird

Externe Unterstützung lohnt sich, wenn du Embedded, Multi-Tenant, Compliance-Nachweise und Betrieb gleichzeitig sauber verzahnen musst. Genau in dieser Schnittstelle entstehen die typischen Lücken: RLS ist vorhanden, aber Token/Workspace/Exportregeln passen nicht zusammen, und niemand kann später belegen, wer was gesehen hat. Ein strukturiertes Assessment klärt Sicherheitsgrenzen, Betriebsmodell und die nächsten Schritte, bevor der Rollout auf viele Kommunen geht.