Warum Berechtigungsmodelle mit der Zeit außer Kontrolle geraten

Es beginnt mit einer gut gemeinten Entscheidung: Ein neuer Kollege braucht Zugriff auf eine bestimmte Funktion, also wird eine zusätzliche Rolle erstellt. Ein externer Dienstleister benötigt temporär eine Sondergenehmigung, also wird eine weitere Rolle hinzugefügt. Später kommt ein Notfallzugriff hinzu – ebenfalls als eigene Rolle. Was als überschaubare Lösung beginnt, wächst sich innerhalb von zwei Jahren zu einem undurchdringlichen Dschungel aus 340 Rollen aus. Plötzlich kann niemand mehr erklären, wer welche Berechtigungen besitzt, geschweige denn, warum.

Doch wie kommt es dazu, dass ein zunächst klares Berechtigungssystem so schnell aus den Fugen gerät?

Vom Rollen-Chaos zur unwartbaren Infrastruktur

Rollenbasierte Zugriffskontrolle (RBAC) klingt auf den ersten Blick elegant: Jede Rolle hat klare Rechte, und die Verwaltung scheint einfach. Doch in der Praxis stoßen selbst gut durchdachte Modelle schnell an ihre Grenzen. Ein Team benötigt Zugriff auf Ressource A, aber nicht auf Ressource B? Neue Rolle. Ein externer Dienstleister hat fast dieselben Berechtigungen wie eine bestehende Rolle, benötigt aber eine zusätzliche Ausnahme? Noch eine Rolle. Eine Notfallrolle, die eigentlich nur vorübergehend gelten sollte, wird nie deaktiviert? Weitere Rolle.

Jede dieser Entscheidungen erscheint im Moment sinnvoll – doch im Zusammenspiel entstehen unzählige Ausnahmen, die das System unwartbar machen. Irgendwann gibt es keine Übersicht mehr, welche Rolle welche Berechtigungen hat. Selbst langjährige Teammitglieder können das System nicht mehr vollständig erklären. Das ist kein Versagen der Disziplin, sondern eine logische Folge eines Modells, das für einfache Fälle entworfen wurde, aber in einer komplexen Realität eingesetzt wird.

Warum RBAC an dynamischen Anforderungen scheitert

RBAC funktioniert gut, solange Zugriffsentscheidungen binär sind: Eine Rolle ist entweder vorhanden oder nicht. Doch die Realität sieht anders aus. Mitarbeiter benötigen möglicherweise nur Zugriff auf ihre eigenen Daten, nicht auf die anderer Kollegen. Projektbezogene Berechtigungen müssen nach Projektende automatisch erlöschen. Oder der Zugriff hängt vom aktuellen Zustand einer Ressource ab – nicht nur davon, wer die Anfrage stellt.

Jede dieser Anforderungen führt entweder zu einer Flut weiterer Rollen – was schnell unüberschaubar wird – oder zu komplexeren Modellen, die kontextabhängige Entscheidungen ermöglichen. Viele Teams entscheiden sich für den ersten Weg, weil er kurzfristig einfacher umsetzbar ist. Doch langfristig führt dies zu einem System, das schwer zu warten und noch schwerer zu auditieren ist. Attribute- oder policybasierte Zugriffskontrolle (ABAC/PBAC) erfordert zwar mehr Aufwand in der Anfangsphase, spart jedoch später immense Zeit und reduziert Fehlerquellen.

Caching von Berechtigungen: Ein gefährliches Kompromiss

Eine weitere Herausforderung ist die Leistung: Bei Millionen von Zugriffsentscheidungen pro Sekunde müssen Berechtigungen effizient geprüft werden. Die naheliegende Lösung ist Caching – die Speicherung der Entscheidungen für eine bestimmte Zeitspanne. Das beschleunigt die Abfrage und entlastet das System. Doch was passiert, wenn einer dieser Entscheidungen widerrufen werden muss?

Ein Beispiel aus der Praxis: Ein Sicherheitsteam bemerkte, dass ein kompromittiertes Konto Zugriff auf sensible Daten hatte. Die Berechtigungen wurden umgehend widerrufen, doch aufgrund eines 10-minütigen Cache-Zeitfensters blieb der Zugriff für weitere acht Minuten bestehen. In einer Live-Situation vor dem Sicherheitsteam zu erklären, warum die Deaktivierung nicht sofort wirkt, ist eine unangenehme Erfahrung – die sich tief ins Gedächtnis einprägt. Seit diesem Vorfall wird keine Berechtigungsentscheidung mehr ohne explizite Abwägung zwischen Performance und Sicherheitsanforderungen gecacht.

Audit-Trails: Compliance oder Albtraum?

Jede Zugriffsentscheidung muss dokumentiert werden: Wer hat angefragt? Welche Berechtigungen lagen vor? Was wurde entschieden? Bei hohen Durchsatzraten bedeutet das enorme Schreiboperationen in das Audit-System. Synchrones Schreiben erhöht die Latenz, asynchrones Schreiben birgt das Risiko, dass Entscheidungen ohne Protokollierung getroffen werden – ein Compliance-Albtraum.

In einem Projekt lautete die Vorgabe: „Logge erst, dann führe aus.“ Diese Anforderung prägte die gesamte Architektur: Die Latenzgrenzen mussten neu definiert, die Fehlerbehandlung angepasst und die Speicherinfrastruktur komplett überarbeitet werden. Nachträglich solche Anforderungen umzusetzen, ist extrem aufwendig und gelingt selten ohne Probleme. Die Lehre daraus: Compliance-Anforderungen müssen von Anfang an in die Systemarchitektur einfließen.

Die wahre Prüfung: Schnelle und zuverlässige Deaktivierung

Die Gewährung von Zugriffen ist einfach – eine Zeile in der Datenbank, ein Klick in der Oberfläche. Doch die Deaktivierung ist der Lackmustest für ein gut durchdachtes System. Was passiert, wenn ein Konto gesperrt werden muss?

• Ein Batch-Job, der vor der Deaktivierung gestartet wurde, könnte noch Stunden später mit veralteten Berechtigungen arbeiten.
• Gecachte Entscheidungen bleiben möglicherweise länger aktiv, als sie sollten.
• Jeder Replikationsknoten im System muss konsistent aktualisiert werden, um sicherzustellen, dass keine veralteten Berechtigungen mehr verwendet werden.

Erklärungen wie „Technisch gesehen war jede einzelne Entscheidung zum Zeitpunkt der Prüfung gültig“ helfen in einem Compliance-Gespräch nicht weiter. Die Realität sieht anders aus: Das System hat weiterhin falsche Entscheidungen getroffen, und das Vertrauen in die Sicherheit ist erschüttert. Eine zuverlässige Deaktivierung erfordert klare Definitionen – was bedeutet „sofort“ in diesem Kontext? – und eine Infrastruktur, die diese Anforderungen erfüllt. Annahmen wie „das sortiert sich schon von allein“ führen unweigerlich zu Problemen.

Ein klarer Pfad nach vorn

Die Herausforderungen von Berechtigungssystemen im großen Maßstab sind real, aber nicht unlösbar. Der Schlüssel liegt darin, von Anfang an die richtigen Entscheidungen zu treffen:

• Vermeide Rollen-Explosion durch ABAC/PBAC: Statt hunderter Rollen zu verwalten, sollten Attribute oder Richtlinien genutzt werden, um dynamische Zugriffsentscheidungen zu treffen. Das reduziert die Komplexität und macht das System wartbarer.
• Denke an die Deaktivierung: Berechtigungen müssen schnell und zuverlässig deaktiviert werden können. Cache-Zeitfenster sollten bewusst gewählt und dokumentiert werden.
• Baue Compliance von Anfang an ein: Audit-Trails sind kein nachträgliches Add-on, sondern müssen integraler Bestandteil der Architektur sein.
• Teste in der Realität: Simulationen von Notfällen helfen, Schwachstellen zu identifizieren, bevor sie im Ernstfall auftreten.

Berechtigungssysteme sind kein technisches Nischenthema – sie sind das Fundament jeder sicheren und skalierbaren Infrastruktur. Wer hier spart, zahlt später den Preis – in Form von Sicherheitslücken, Compliance-Verstößen oder einem System, das niemand mehr versteht.