Sicherheitsrollen in Dynamics 365 prüfen

Sicherheitsrollen sind die Stelle, an der in Dynamics 365 tatsächlich entschieden wird, wer welche Daten sieht. Sie sind auch die Stelle, an der über Jahre am meisten Unordnung entsteht. Rechte werden im Projektverlauf immer nur erweitert und praktisch nie zurückgenommen.

Das Modell in zwei Sätzen

Eine Rolle besteht aus Rechten pro Tabelle, jeweils für Anlegen, Lesen, Schreiben, Löschen, Anfügen, Anfügen an, Zuweisen und Freigeben. Jedes dieser Rechte hat eine Zugriffsebene: nur eigene Datensätze, die eigene Geschäftseinheit, Geschäftseinheit samt untergeordneter, oder die gesamte Organisation.

Wichtig für jede Prüfung: Rollen addieren sich. Hat jemand zwei Rollen, gilt jeweils das weitergehende Recht. Eine restriktive Rolle kann eine großzügige also nie einschränken. Wer nur einzelne Rollen betrachtet, der übersieht deshalb regelmäßig, was in der Kombination herauskommt.

Die vier Muster, nach denen ich zuerst suche

Organisationsweite Rechte, wo Geschäftseinheit gereicht hätte. Das ist der häufigste Fund. Besonders beim Lesen wird großzügig verteilt, weil irgendetwas nicht funktionierte und die Erweiterung das Problem sofort löste.

Löschrechte in ungewöhnlicher Breite. Löschen ist das einzige Recht, dessen Folgen sich nicht rückgängig machen lassen. In Kombination mit kaskadierenden Beziehungen wird daraus schnell ein Datenverlust. Der reicht dann weit über den einen Datensatz hinaus, den jemand entfernen wollte. Was dabei zusammenhängt, steht unter Sicherheitsprobleme in Dynamics 365 Solutions.

Rechte zum Exportieren und Massenabruf. Wer sensible Daten schützt, aber dennoch jeder Rolle den Excel-Export erlaubt, hat die Kontrolle über Kopien außerhalb des Systems abgegeben. Diese Rechte stehen nicht bei den Tabellen, sondern unter den sonstigen Berechtigungen. Deshalb werden sie gern übersehen.

Rollen ohne erkennbaren Zweck. Namen wie „Test", „Neu" oder eine Rolle, die exakt einer anderen entspricht: Solche Duplikate machen jede spätere Änderung doppelt teuer, weil niemand mehr weiß, welche die maßgebliche ist.

Das Vorgehen, das sich bewährt hat

Beginnen Sie nicht bei den Rollen, sondern bei den Daten. Welche Tabellen enthalten etwas, das nicht jeder sehen soll? Für diese Tabellen prüfen Sie anschließend jede Rolle, statt umgekehrt vierzig Rollen vollständig durchzugehen.

Zweitens: Fragen Sie zu jedem Recht nach der Begründung, nicht nach der Funktion. „Funktioniert" ist kein Argument für eine Zugriffsebene, denn organisationsweit funktioniert immer. Die Frage lautet, warum die nächstkleinere Ebene nicht reicht.

Drittens: Prüfen Sie die Kombinationen, die real vorkommen. Eine Liste der tatsächlich vergebenen Rollenkombinationen ist aussagekräftiger als jede Einzelbetrachtung.

Was der Solution-Export zeigt und was nicht

Im Export liegen die Rollen mit jedem einzelnen Recht und dessen Zugriffsebene, und zwar als Gesamtbestand. Das macht Auswertungen möglich, die in der Oberfläche mühsam sind: alle organisationsweiten Löschrechte über sämtliche Rollen hinweg, oder alle Rollen mit Export-Berechtigung, in einer Liste.

Was nicht im Export steht, ist die Zuweisung: Welcher Benutzer oder welches Team hat welche Rolle? Das sind Daten der Umgebung. Ein Audit besteht deshalb aus zwei Teilen, und der zweite braucht Zugriff auf das System. Für die Frage „ist dieses Rechtemodell sauber gebaut?" reicht der Export, für „wer hat gerade zu viel?" nicht.

Der Rhythmus

Einmal jährlich, dazu bei jedem größeren Rollout und bei jeder organisatorischen Änderung. Und eine Regel für den Alltag, die mehr bringt als jede Prüfung: Wenn während der Fehlersuche ein Recht erweitert wird, gehört ein Vermerk dazu, warum. Ohne diesen Vermerk traut sich später niemand mehr, die Erweiterung zurückzunehmen.