Als wir kürzlich in unserem Procurement-System vor der Herausforderung standen, Berechtigungen für Belege zu implementieren, wurde mir wieder einmal bewusst, wie komplex moderne Zugriffskontrolle sein kann. In diesem Artikel möchte ich meine Erfahrungen mit verschiedenen Zugriffskontrollmodellen teilen und erklären, warum wir uns letztendlich für ABAC entschieden haben.
Die Grenzen klassischer ACLs
Wer kennt sie nicht – die guten alten Access Control Lists (ACLs)? Sie sind wie eine einfache Türliste am Eingang eines exklusiven Clubs: Entweder du stehst auf der Liste, oder eben nicht. In unserem Procurement-Kontext bedeutete das ursprünglich: Beleg XY – Zugriff für Nutzer A, B und C.
Anfangs erschien das ausreichend, aber schnell wurde klar: So einfach ist unsere Geschäftswelt nicht mehr. Was ist, wenn ein Mitarbeiter nur Belege seiner Abteilung sehen darf? Oder nur Belege unter 10.000€? Mit ACLs würde das bedeuten, für jeden Beleg einzeln festzulegen, wer Zugriff hat – ein administrativer Alptraum.
Der Zwischenschritt: RBAC
Role-Based Access Control (RBAC) war der logische nächste Schritt. Statt einzelnen Nutzern direkt Rechte zuzuweisen, definierten wir Rollen wie “Einkäufer”, “Abteilungsleiter” oder “Finanz-Controller”. Das vereinfachte die Administration erheblich – neue Mitarbeiter bekamen einfach die passende Rolle zugewiesen.
Aber auch RBAC stieß an seine Grenzen. Ein Beispiel: Ein Abteilungsleiter sollte nur Belege seiner eigenen Abteilung freigeben können, aber gleichzeitig alle Belege unter 1.000€ sehen dürfen. Mit RBAC müssten wir dafür mehrere spezifische Rollen erstellen – “Abteilungsleiter-IT”, “Abteilungsleiter-HR” etc. – oder komplexe Rollenhierarchien aufbauen.
ABAC: Die flexible Lösung
Attribute-Based Access Control (ABAC) war für uns die Erleuchtung. ABAC berücksichtigt nicht nur den Nutzer und seine Rollen, sondern auch:
- Attribute des Objekts (z.B. Belegwert, Abteilung, Status)
- Attribute des Nutzers (z.B. Position, Kostenstelle, Standort)
- Umgebungsbedingungen (z.B. Uhrzeit, Netzwerk)
- Aktionen (Lesen, Schreiben, Freigeben)
Ein Beispiel aus unserer Implementierung: “Ein Abteilungsleiter kann Belege freigeben, wenn:
- der Beleg seiner Abteilung zugeordnet ist
- der Belegwert unter seinem Freigabelimit liegt
- der Beleg den Status ‘Zur Freigabe’ hat
- es innerhalb der Geschäftszeiten ist”
Fazit: Komplexität vs. Flexibilität
Die Implementierung von ABAC war definitiv aufwändiger als die vorherigen Ansätze. Wir mussten:
- Eine Policy-Engine einführen
- Attribute-Verwaltung implementieren
- Regelwerk sorgfältig definieren
Aber die gewonnene Flexibilität war den Aufwand wert. Änderungen an Zugriffsregeln können nun zentral in Policies verwaltet werden, ohne den Code anzufassen. Neue Geschäftsanforderungen lassen sich durch das Hinzufügen neuer Attribute und Regeln umsetzen, statt neue Rollen oder ACLs zu erstellen.
Für komplexe Enterprise-Anwendungen wie unser Procurement-System ist ABAC meiner Meinung nach alternativlos. Die anfängliche Komplexität wird durch die langfristige Flexibilität mehr als aufgewogen.