Typische Fehler bei Dataverse-Berechtigungen

Jun 30, 2026

Nick Hoffmann

Das Sicherheitsmodell von Dataverse ist mächtig, aber unintuitiv. Die meisten Probleme entstehen nicht durch fehlende Features, sondern durch Missverständnisse darüber, wie die vorhandenen Mechanismen zusammenwirken. Hier sind die Fehler, die in der Praxis immer wieder auftauchen.

1. Die Admin-Rolle als Allzweck-Lösung

Ein Nutzer kommt nicht an einen Datensatz – also bekommt er die Rolle “Systemadministrator”. Damit ist das Symptom weg, aber das eigentliche Problem nie verstanden. Solche Konten häufen sich an, und irgendwann hat die halbe Organisation Vollzugriff.

Stattdessen: Reproduziere, welches Privileg konkret fehlt, und ergänze genau dieses in einer passenden Rolle. Das Prinzip der minimalen Rechte ist hier kein Dogma, sondern Voraussetzung dafür, dass das System auf Dauer prüfbar bleibt.

2. Sicherheitsrollen sind additiv, nicht restriktiv

Das ist das mit Abstand häufigste Missverständnis. Wenn ein Nutzer mehrere Rollen hat, summieren sich die Rechte – sie werden nie eingeschränkt. Eine zusätzliche, “strengere” Rolle entzieht keine Berechtigung. Das effektive Recht ist immer das großzügigste über alle zugewiesenen Rollen hinweg.

Wer Zugriff einschränken will, muss die zu großzügige Rolle anpassen oder entfernen – nicht eine restriktivere danebenlegen.

3. Zugriffsebenen werden falsch verstanden

Jedes Privileg hat eine Reichweite. Diese fünf Stufen muss man auseinanderhalten:

Kein Zugriff – gar nicht
Benutzer – nur eigene Datensätze
Geschäftseinheit – Datensätze der eigenen Business Unit
Übergeordnete: untergeordnete Geschäftseinheit – eigene BU plus alle darunter
Organisation – alle Datensätze

Ein typischer Fehler: Man vergibt “Organisation” für Lesen, weil “es sonst nicht geht”, obwohl eigentlich “Geschäftseinheit” gemeint war. Die Reichweite gehört bewusst pro Tabelle und pro Operation (Erstellen, Lesen, Schreiben, Löschen, Anhängen, Zuweisen, Freigeben) gewählt.

4. Einzelfreigaben statt Teams

Datensätze einzeln per “Freigeben” (Sharing) an einzelne Nutzer zu verteilen, fühlt sich schnell an, wird aber unwartbar. Niemand weiß nach einem halben Jahr mehr, wer worauf Zugriff hat, und Entzug ist mühsam.

Besser: Zugriff über Teams und Rollen modellieren. Freigaben sind für echte Ad-hoc-Ausnahmen gedacht, nicht als Standardmechanismus.

5. Owner-Teams und Access-Teams werden verwechselt

Beides heißt “Team”, löst aber unterschiedliche Probleme. Ein Owner-Team besitzt Datensätze und hat eigene Sicherheitsrollen. Ein Access-Team besitzt nichts, sondern dient der gezielten Freigabe einzelner Datensätze über Vorlagen – ideal für Muster wie “die am konkreten Fall beteiligten Personen”.

Wer ein Access-Team mit einer Rolle ausstatten will, hat den falschen Team-Typ gewählt.

6. Getestet wird mit dem Admin-Konto

“Bei mir funktioniert es” – weil man als Administrator testet. Berechtigungsfehler zeigen sich aber nur mit einem echten, niedrig privilegierten Konto. Ohne diesen Test geht jede Annahme über Zugriff ins Blaue.

Lege dir Testnutzer mit genau den Rollen an, die später produktiv vergeben werden, und prüfe damit.

7. Spaltensicherheit wird ignoriert oder übertrieben

Sicherheitsrollen wirken auf Tabellenebene. Einzelne sensible Felder (z. B. Gehalt, Sozialversicherungsnummer) lassen sich darüber nicht gezielt schützen – dafür gibt es Field-Level-Security über Spaltensicherheitsprofile.

Zwei Fehler gleichzeitig verbreitet: gar nicht genutzt, obwohl nötig – oder über zu viele Felder gelegt, was die Verwaltung unnötig verkompliziert. Gezielt auf wenige, wirklich schützenswerte Spalten anwenden.

8. Application Users sind überberechtigt

Integrationen, die über einen Application User (Service-Principal) auf Dataverse zugreifen, bekommen oft reflexartig “Systemadministrator”. Damit hat jede kompromittierte Schnittstelle sofort Vollzugriff.

9. Append und AppendTo werden vergessen

Eine Beziehung zwischen zwei Datensätzen scheitert mit kryptischem Fehler – obwohl Lese- und Schreibrechte vorhanden sind. Ursache: Zum Verknüpfen braucht es Anhängen (Append) auf dem einen und Anhängen an (AppendTo) auf dem anderen Datensatz. Fehlt eines davon, geht die Zuordnung nicht.

Das ist kein Bug, sondern ein eigenes Privileg-Paar, das beim Rollendesign gern übersehen wird.

Kurz zusammengefasst

Die meisten Berechtigungsprobleme in Dataverse sind keine technischen Grenzen, sondern Designentscheidungen, die zu früh oder zu unbedacht getroffen wurden. Drei Leitlinien helfen:

Minimal vergeben, gezielt erweitern – nicht umgekehrt.
Über Rollen und Teams modellieren, nicht über Einzelfreigaben.
Mit echten Konten testen, nie als Admin.

Wer diese drei Punkte beherzigt, vermeidet den Großteil der hier genannten Fehler von vornherein.