Antwort.

Geschichte der Frage:

Mit der steigenden Anzahl von Benutzern und Modulen in IT-Systemen wurde die Verteilung der Rollen und die Festlegung der Rechte zu einer kritischen Aufgabe. Fehler bei der Gestaltung des Zugriffsmodells führen zu Schwachstellen, nicht funktionierenden Funktionen und dem Risiko von Datenlecks.

Problem:

Das Fehlen einer einheitlichen Methodologie zur Erstellung einer Berechtigungsmatrix, Inkonsistenzen zwischen verschiedenen Modulen und ungenaue Beschreibungen von Zugriffszenarien führen letztendlich zu Unannehmlichkeiten für die Benutzer und Konflikten, manchmal auch zu rechtlichen Konsequenzen.

Lösung:

Es wird die Methode der Zugriffs-Matrix (Access Matrix) angewendet, bei der für jedes Modul des Systems Rollen (Role-Based Access Control, RBAC), Arten von Operationen und entsprechende Nutzungsszenarien beschrieben werden. Dokumentiert wird:

Liste der Rollen mit ihren Beschreibungen: Administrator, Operator, Benutzer, Gast usw.
Aufstellung von Operationen (CRUD, Prozessstart, Datenexport usw.), die jeder Rolle zur Verfügung stehen
Einschränkungen und Ausnahmen für Sonderfälle
Beispiele für Benutzer-Szenarien: wer und wann was macht, was die Ergebnisse sind

All dies wird in einer zusammenfassenden Tabelle "Rollen und Rechte" festgehalten, normalerweise unter Verwendung von Tabellenkalkulationen, Diagrammerstellern oder über spezielle UML-Diagramme (z. B. Use Case).

Schlüsselmerkmale:

Formalisierung der Rollen unabhängig von der organisatorischen Struktur
Prüfung der Konsistenz zwischen den Modulen
Bearbeitung nicht nur der Vergabe, sondern auch des Widerrufs/Änderungen von Rechten

Tückische Fragen.

Reicht es aus, nur die grundlegenden Rollen (Admin, Benutzer) für das gesamte System zu beschreiben?

Nein, es sollten die Rollen auf der Ebene von Aufgaben und Modulen detailliert werden, da sonst Grauzonen und Sicherheitslücken entstehen.

Kann der Zugriff ausschließlich auf Basis der vorhandenen Organisationsstruktur aufgebaut werden?

Nein, die Organisationsstruktur ändert sich schnell, während die Geschäftsprozesse länger bestehen. Rollen sollten basierend auf Geschäftsszenarien und Verantwortungsbereichen abgeleitet werden.

Muss man nur die erlaubten Zugriffsrechte festhalten?

Nein, es ist zwingend notwendig, nicht nur die Erlaubnisse, sondern auch die Verbote (deny rules) zu beschreiben, und Verfahren für Eskalation und vorübergehende Rechtevergabe vorzusehen.

Typische Fehler und Anti-Pattern

"Flache" Berechtigungsstruktur im gesamten System, fehlende Detailgenauigkeit auf Modulebene
Übertragung der organisatorischen Hierarchie auf IT-Rollen ohne Berücksichtigung der Besonderheiten
Dokumentation nur der positiven (erlaubenden) Rechte ohne Widerrufsszenarien oder temporären Zugriff

Beispiel aus der Praxis

Negativer Fall:

In einem großen CRM-System wurden alle Rechte nur auf der Ebene von zwei grundlegenden Rollen beschrieben. In der Praxis traten viele Konflikte auf: Normale Manager löschten versehentlich wichtige Daten, und die Operatoren hatten keinen Zugriff auf ihre Funktionen.

Vorteile:

Vereinfachung der Inbetriebnahme

Nachteile:

Erhöhte Risiken beim Zugriff auf kritische Daten, Anzahl der Fehler aufgrund von Inkonsistenzen

Positiver Fall:

Der Analyst hat die Rechte nach Rollen und Modulen aufgeteilt, einen Design-Workshop mit Benutzern durchgeführt, Delegations- und Widerrufsfristen beschrieben. Erstellte eine zusammenfassende Zugriffs-Matrix, stimmte User-Journey-Vorlagen für verschiedene Mitarbeitertypen ab.