Wenn ein Dataverse-Projekt nach dem Go-Live in Aufruhr gerät, geht es in den meisten Fällen um Berechtigungen. Entweder sieht jemand etwas, das er nicht sehen darf — der seltenere, aber heiklere Fall. Oder, viel häufiger, jemand sieht etwas nicht, das er dringend braucht, und niemand im Team kann erklären, warum.
Das Sicherheitsmodell von Dataverse ist mächtig, aber es hat eine steile Lernkurve, weil mehrere Konzepte gleichzeitig greifen und ihre Logik nicht intuitiv ist. Dieser Beitrag erklärt das Modell so, dass du es vor dem Go-Live richtig aufsetzt — statt es danach unter Druck zu reparieren. Die Gesamteinordnung steht im Dataverse-Leitfaden; hier geht es nur um Sicherheit.
Das Modell besteht aus vier Konzepten, die ineinandergreifen. Du musst alle vier zusammen denken — einzeln betrachtet führt jedes in die Irre.
Der entscheidende und meistübersehene Punkt: Berechtigungen sind additiv. Hat ein Nutzer mehrere Rollen, gilt pro Privileg die jeweils großzügigere Einstellung. Es gibt kein „Verbieten gewinnt". Eine restriktive Rolle bewirkt nichts, wenn eine zweite, locker konfigurierte Rolle dasselbe Recht weiter aufmacht. Wer das nicht verinnerlicht hat, baut Rollenchaos und wundert sich, warum die „enge" Rolle nichts begrenzt.
Das folgende Schaubild zeigt, welche Schichten eine Leseanfrage durchläuft und wo „additiv" konkret zuschlägt.
Dieses eine Schaubild erklärt die Mehrheit der „Warum sieht der das?"-Tickets nach dem Go-Live. Fast nie ist es ein Plattformfehler — fast immer eine zweite Rolle, die still alles wieder aufmacht.
Jeder Datensatz in einer Standardtabelle hat einen Owner — einen Nutzer oder ein Team. Das Access Level „eigene" bezieht sich genau darauf: Sieht ein Nutzer nur „eigene" Datensätze, sieht er die, deren Owner er ist (oder das Team, dem er angehört).
Daraus folgt eine Designentscheidung, die früh fallen muss: Owner-Team oder Sharing? Soll ein Datensatz für eine Gruppe sichtbar sein, gibt es zwei Wege. Owner-Teams sind sauber und skalieren — der Datensatz gehört dem Team, alle Teammitglieder sehen ihn über ihr normales Access Level. Manuelles Sharing pro Datensatz funktioniert auch, skaliert aber miserabel und wird in gewachsenen Umgebungen zur unwartbaren Schicht, die niemand mehr nachvollzieht. Die Praxisregel: Gruppensichtbarkeit über Owner-Teams modellieren, Sharing nur für echte Einzelfall-Ausnahmen.
Manchmal soll ein Nutzer einen Datensatz sehen — aber nicht ein bestimmtes Feld darin (Gehalt, Marge, eine sensible Notiz). Dafür gibt es Column/Field-Level Security: ein einzelnes Feld wird gesichert und nur über ein Field Security Profile freigegeben.
Das funktioniert sauber, kostet aber Übersicht. Jedes gesicherte Feld ist eine zusätzliche Verwaltungsachse neben den Rollen. Unsere Praxisempfehlung: sparsam einsetzen, nur für echt sensible Felder, und dokumentieren, welches Profil welches Feld öffnet. Wer Field-Level Security großflächig streut, baut ein Modell, das formal korrekt und praktisch nicht mehr wartbar ist.
Aus Security-Sanierungen destilliert, nach Häufigkeit:
Auffällig wie bei der Datenmodellierung: keiner dieser Fehler ist ein Plattformfehler. Es sind Disziplin- und Designfehler — und alle sind am Anfang fast kostenlos vermeidbar. Wie eng Sicherheit und Datenmodell zusammenhängen, zeigt sich besonders bei der Frage, ob ein Konzept eine eigene Tabelle bekommt — ausführlich in unseren Best Practices zur Datenmodellierung. Und ob Dataverse für deinen Fall überhaupt das richtige Werkzeug ist, klärt unsere Gegenüberstellung Dataverse vs. SQL vs. SharePoint — gerade weil ein zeilengenaues Sicherheitsmodell oft das eigentliche Argument für Dataverse ist.
Wenn du ein Security-Modell von Grund auf baust, in dieser Reihenfolge:
Das folgende Schaubild zeigt diese Reihenfolge als Treppe — jede Stufe baut auf der vorigen auf, und die teuerste Korrektur sitzt ganz unten.
Schritt sechs ist der, der am häufigsten ausgelassen wird — und der, der die meisten Post-Go-Live-Tickets verhindert hätte.
Das Dataverse-Sicherheitsmodell ist nicht kompliziert, weil die Plattform schlecht ist — es ist kompliziert, weil Sicherheit kompliziert ist. Vier Bausteine, additive Logik, kein „Deny": Wer diese drei Wahrheiten verinnerlicht, baut ein Modell, das hält. Wer sie übergeht, baut eines, das nach dem Go-Live im Ticketsystem explodiert.
Die ehrlichste Empfehlung: Wenige aufgabenbezogene Rollen, Owner-Teams statt Sharing, und jede Rolle mit einem echten Testnutzer prüfen, bevor produktiv jemand davon abhängt. Vertrauen, das nach dem Go-Live verloren geht, weil jemand das Falsche sah, gewinnst du nicht mit einer Korrektur-Rolle zurück.
Wir entwerfen dein Security-Modell entlang der echten Sichtbarkeitsgrenzen — oder reviewen ein bestehendes ehrlich und finden die Stelle, an der die „enge" Rolle still ausgehebelt wird. Bevor es ein Datenschutzthema wird.
