In einer B2B-Anwendung beeinflusst die Entscheidung, wer eine Ressource anzeigen, ändern oder freigeben darf, das Produkt, den Betrieb und das Risiko. Ein zu einfaches Modell kann zu weitreichenden Zugriffsrechten führen; ein übermäßig detailliertes Modell kann schwer zu verwalten und zu erklären sein. Bei der Entscheidung zwischen Rollen und kontextabhängigen Berechtigungen geht es nicht darum, ein technisches Etikett auszuwählen. Vielmehr müssen die tatsächlichen Geschäftsregeln verständlich, überprüfbar und nachhaltig abgebildet werden.
Welche Option passt, hängt davon ab, wie stark der Zugriff zwischen Benutzern, Ressourcen und Situationen variiert und wer diese Unterschiede verwalten muss. Beginnen Sie mit realen Anwendungsfällen, nicht mit einer Liste von Steuerelementen. Anschließend können Sie das einfachste Modell wählen, das diese Fälle abdeckt, und konkrete Kriterien für eine spätere Weiterentwicklung festlegen.
Authentifizierung und Autorisierung beantworten unterschiedliche Fragen
Die Authentifizierung prüft, wer ein Benutzer ist, beispielsweise anhand einer Sitzung oder eines Identitätsanbieters. Die Autorisierung legt fest, was diese Identität mit einer bestimmten Ressource tun darf. Eine Anmeldung bedeutet nicht, dass jemand alle Rechnungen, Projekte oder Daten eines Unternehmens einsehen darf.
Beschreiben Sie jede Autorisierungsentscheidung anhand von vier Elementen: Akteur, Aktion, Ressource und geltende Bedingungen. Zum Beispiel: „Eine Person mit Rechnungsberechtigung darf Rechnungen ihrer Organisation herunterladen.“ Dieser Satz zwingt dazu, zu klären, ob die Berechtigung für alle Organisationen gilt, für eine ausgewählte Organisation oder nur für bestimmte Dokumente.
Auch der Geltungsbereich der Daten sollte von Anfang an feststehen. Bei einem Produkt mit mehreren Unternehmenskunden reicht es nicht aus, die Rolle korrekt zu prüfen, wenn eine Abfrage Ressourcen eines anderen Kunden zurückgibt. Die Autorisierung muss sowohl die Aktion als auch den Zugriff auf die Ressource und deren Zugehörigkeit zum richtigen Geltungsbereich berücksichtigen.
Rollenbasierte Berechtigungen: Klarheit bei wiederkehrenden Mustern
Bei der rollenbasierten Zugriffskontrolle, kurz RBAC, werden Berechtigungen in Rollen zusammengefasst und Benutzern zugewiesen. Eine Rolle wie „Organisationsadministrator“ könnte die Verwaltung von Mitgliedern und Einstellungen erlauben; eine andere Rolle wie „Analyst“ könnte Lesezugriff auf Berichte gewähren. Die Anwendung prüft, ob die Rolle des Benutzers die für die Aktion erforderliche Berechtigung enthält.
Dieser Ansatz eignet sich gut, wenn sich Positionen oder Verantwortlichkeiten im Produkt wiederholen und die Unterschiede zwischen Benutzern relativ stabil sind. Er erleichtert es, den Zugriff in der Benutzeroberfläche zu erklären, gängige Profile anzulegen und Zuweisungen zu überprüfen. Außerdem schafft er eine gemeinsame Sprache für Produkt, Support und Technik: Über „Bearbeiter“ lässt sich leichter sprechen als über eine unübersichtliche Liste einzelner Berechtigungen.
Rollen sollten jedoch nicht automatisch als Berufsbezeichnungen verstanden werden. Eine Person kann in jeder Organisation andere Verantwortlichkeiten haben, und eine globale Rolle kann zu weitreichende Rechte gewähren. Häufig gilt eine Rolle nur innerhalb eines bestimmten Geltungsbereichs: etwa „Administrator“ innerhalb einer Organisation, nicht auf der gesamten Plattform. Legen Sie genau fest, wer Rollen zuweisen darf, auf welche Ressourcen sie sich beziehen und ob eine Person mehrere Rollen haben kann.
Wählen Sie Rollen, wenn Berechtigungen erkennbare Gruppen bilden, sich nur selten ändern und verwaltet werden können, ohne für jede Ausnahme eine neue Rolle anzulegen. Wenn sich die Kombinationen häufen („Bearbeiter mit Zugriff auf nur zwei Projekte, außer während einer Freigabe“), versucht die Rolle möglicherweise, zu viele Dimensionen abzubilden.
Kontextabhängige Regeln: Zugriff je nach Benutzer, Ressource oder Situation
Eine kontextabhängige Regel berücksichtigt neben der Identität oder Rolle weitere Attribute. Der Zugriff kann davon abhängen, wer die Aktion anfordert, welche Ressource verwendet werden soll und unter welchen Bedingungen dies geschieht. Beispielsweise könnte die Bearbeitung eines Projekts nur dann erlaubt sein, wenn die Person zum zugewiesenen Team gehört und sich das Projekt im Entwurfsstatus befindet. Dieser Ansatz wird häufig mit der attributbasierten Zugriffskontrolle, kurz ABAC, in Verbindung gebracht.
Kontextabhängige Regeln sind hilfreich, wenn dieselben Benutzer unterschiedliche Berechtigungen für verschiedene Ressourcen haben oder wenn der Geschäftsstatus beeinflusst, was erlaubt ist. Sie können die Teamzugehörigkeit, den Eigentümer eines Datensatzes, die Datenklassifizierung oder eine Freigabephase abbilden. So lässt sich vermeiden, für jede Kombination aus Benutzer und Ressource eine eigene Rolle anzulegen.
Die Flexibilität hat ihren Preis: Entscheidungen sind weniger transparent, wenn sie von verstreuten Attributen oder schwer erklärbaren Bedingungen abhängen. Eine Regel kann fehlschlagen, weil der Status der Ressource veraltet ist, eine Angabe fehlt oder der Umgang mit einem unbekannten Wert nicht festgelegt wurde. Ermitteln Sie für jede Bedingung ihre Quelle, die verantwortliche Stelle, den Aktualisierungsrhythmus und den Umgang mit Fehlern. Fehlt eine Angabe, die für die Gewährung des Zugriffs erforderlich ist, muss die Richtlinie die Aktion sicher ablehnen.
„Kontextabhängige Berechtigungen“ bedeuten nicht zwangsläufig, dass eine komplexe Regel-Engine eingeführt werden muss. In einer kleinen Anwendung kann es sich um eine explizite Prüfung von Zugehörigkeit und Status handeln. Entscheidend ist, dass die Regel konsistent, zentral verwaltbar und überprüfbar ist – nicht, dass eine bestimmte Architektur verwendet wird.
Ansätze anhand realer Anwendungsfälle vergleichen
Erstellen Sie eine kleine Matrix mit repräsentativen Benutzern, Aktionen und Ressourcen. Nehmen Sie sowohl typische Fälle als auch Ausnahmen auf: einen Benutzer, der zu zwei Organisationen gehört, eine gemeinsam genutzte Ressource, eine Person, die das Team wechselt, und eine Freigabeaktion. Notieren Sie für jede Zeile das erwartete Ergebnis und den Grund dafür. Vergleichen Sie anschließend, wie aufwendig sich die Regeln mit den jeweiligen Ansätzen ausdrücken und verwalten lassen.
- Variabilität: Hängen Berechtigungen hauptsächlich von stabilen Verantwortlichkeiten ab oder ändern sie sich je nach Ressource und Status?
- Verwaltung: Kann ein Administrator des Kunden die Zuweisungen verstehen und pflegen, ohne ständig technische Unterstützung zu benötigen?
- Ausnahmen: Sind sie selten und kontrollierbar oder treten sie so häufig auf, dass informell ein zweites Rollensystem entsteht?
- Auditierbarkeit: Können Sie erklären, warum eine Operation erlaubt oder abgelehnt wurde, und nachvollziehen, welche Regel angewendet wurde?
- Auswirkungen von Fehlern: Welche Daten könnten offengelegt oder welche Vorgänge blockiert werden, wenn eine Bedingung falsch konfiguriert ist?
Vergleichen Sie nicht nur die Anzahl der Rollen oder Regeln. Ein Modell mit wenigen Elementen kann schwer verständlich sein, wenn sich die Auswirkungen implizit kombinieren. Berücksichtigen Sie auch die Erfahrung der Person, die Zugriffe konfiguriert, und wie einfach sich eine Supportfrage beantworten lässt: „Warum kann diese Person dieses Dokument nicht öffnen?“
Anzeichen für übermäßige oder verfrühte Komplexität
Rollen wachsen wahrscheinlich übermäßig an, wenn es nahezu identische Namen für geringfügige Unterschiede gibt, jeder Kunde eine eigene Rolle anfordert oder ressourcenbezogene Bedingungen als Ausnahmen in Rollen codiert werden. Ein weiteres Anzeichen: Niemand kann den Unterschied zwischen zwei Profilen erklären, ohne den Code nachzuschlagen.
Umgekehrt können kontextabhängige Regeln verfrüht sein, wenn fast alle Benutzer dieselben Berechtigungen haben, kein Bedarf für ressourcenbezogenen Zugriff besteht und dem Team keine verlässlichen Daten zur Auswertung von Attributen vorliegen. In diesem Fall verursacht ein allgemeines Richtliniensystem zusätzliche Fehlerquellen und Wartungskosten, ohne ein tatsächliches Problem zu lösen.
Nutzen Sie diese Anzeichen als Anlass, das Modell zu überprüfen, nicht als automatische Aufforderung zur Migration. Es kann ausreichen, Rollen zusammenzufassen, Geltungsbereiche zu klären oder Zuweisungen zu korrigieren. Wenn Ausnahmen legitime und wiederkehrende Unterschiede abbilden, lohnt es sich, explizitere Regeln zu entwerfen.
Weiterentwicklung ohne bestehende Berechtigungen zu beeinträchtigen
Eine schrittweise Weiterentwicklung reduziert Überraschungen. Erfassen Sie zunächst die aktuellen Berechtigungen und beschreiben Sie die erwarteten Fälle anhand von Beispielen. Trennen Sie Autorisierungsrichtlinien von der Darstellung der Benutzeroberfläche: Einen Button auszublenden verbessert die Bedienbarkeit, ersetzt aber nicht die serverseitige Prüfung bei jeder Ausführung der Aktion.
- Eine zentrale Entscheidung definieren: Legen Sie fest, wie geprüft wird, ob ein Akteur eine Aktion an einer Ressource ausführen darf. Vermeiden Sie widersprüchliche Prüfungen an verschiedenen Stellen der Anwendung.
- Zugriffstests schreiben: Decken Sie erlaubte und abgelehnte Fälle, Grenzen zwischen Organisationen, Statusänderungen und fehlende Attribute ab. Prüfen Sie außerdem Lese- und Schreibvorgänge.
- Vor dem Austausch vergleichen: Bewerten Sie während einer Übergangsphase das neue Modell parallel zum bisherigen und protokollieren Sie Abweichungen, ohne aufgrund dieses Vergleichs zusätzlichen Zugriff zu gewähren.
- Begrenzte Anwendungsfälle migrieren: Übertragen Sie eine Aktion oder einen Ressourcentyp, überprüfen Sie die Ergebnisse mit den fachlich Verantwortlichen und halten Sie eine kontrollierte Möglichkeit zur Rücknahme bereit.
- Wichtige Entscheidungen protokollieren: Bewahren Sie hilfreiche Informationen auf, um abgelehnte oder sensible Zugriffe untersuchen zu können. Vermeiden Sie dabei unnötige personenbezogene Daten in den Protokollen.
Fragen Sie vor der Einführung: Wer darf Zugriff gewähren und in welchem Umfang? Was geschieht, wenn eine Person aus einem Team entfernt wird? Wie verhält sich das System, wenn ein Attribut fehlt? Kann eine Organisation auf Ressourcen einer anderen zugreifen? Lassen sich alle Ausnahmen erklären und testen? Wenn die Antworten nicht klar sind, sollten zunächst die Regeln konkretisiert werden, statt weitere Rollen oder Bedingungen hinzuzufügen.
Als praktische Faustregel gilt: Beginnen Sie mit Rollen, wenn Verantwortlichkeiten stabil und verständlich sind. Ergänzen Sie kontextabhängige Regeln, wenn ein wiederkehrender Bedarf von Ressourcen oder Umständen abhängt, die sich mit Rollen nicht gut abbilden lassen. Priorisieren Sie in beiden Fällen klar definierte Geltungsbereiche, sichere Ablehnung, Tests und eine verständliche Verwaltung. Das beste Modell ist das einfachste, das die tatsächlichen Geschäftsentscheidungen abbildet und bei Veränderungen überprüft werden kann.