Attribute Based Access Control
Rechte anhand von Eigenschaften entscheiden
Die Idee und ihr Nutzen
Frau Berg arbeitet in der Schadenabteilung einer Versicherung und darf Schäden aus ihrer Region Nord freigeben, aber nur bis zu einem Betrag von 10.000 Euro. Höhere Schäden gibt die Teamleitung frei, damit über große Zahlungen eine erfahrenere Person entscheidet. Für die Schadenanwendung, in der Frau Berg Schäden bearbeitet, genügt die Angabe „Frau Berg ist Sachbearbeiterin“ deshalb nicht, um zu entscheiden, ob Frau Berg einen bestimmten Schaden freigeben darf. Vor jeder Freigabe vergleicht die Schadenanwendung zusätzlich Frau Bergs Region und Betragsgrenze mit der Region und dem Betrag des Schadens. Dieses Vorgehen heißt Attribute Based Access Control, kurz ABAC, auf Deutsch Zugriffssteuerung anhand von Eigenschaften. Die Eigenschaften sind hier Region und Betragsgrenze von Frau Berg sowie Region und Betrag des Schadens.
Wie funktioniert es?
Frau Berg klickt bei einem Hagelschaden über 8.500 Euro auf „Freigeben“. Der Schaden ist in Hamburg entstanden, also in der Region Nord. Die Schadenanwendung liest zuerst Frau Bergs aktuelle Eigenschaften aus den Personendaten, die zu jeder Person Region und Betragsgrenze liefern. Für Frau Berg sind das Region Nord und Betragsgrenze 10.000 Euro. Vor der Freigabe fragt die Schadenanwendung die Entscheidungsstelle, einen Programmteil, der nur Regeln auswertet und mit „erlaubt“ oder „verboten“ antwortet. Die Schadenanwendung übergibt der Entscheidungsstelle Frau Bergs Eigenschaften, die Eigenschaften des Schadens und die Aktion „freigeben“. Der Schaden hat die Region Nord und den Betrag 8.500 Euro. Die Regionen stimmen überein, und 8.500 Euro liegen unter der Grenze. Die Entscheidungsstelle antwortet „erlaubt“, und die Schadenanwendung führt die Freigabe aus. Danach will Frau Berg einen weiteren Hagelschaden aus Region Nord über 14.000 Euro freigeben. Die Schadenanwendung übergibt der Entscheidungsstelle dieselben Angaben zu Frau Berg, aber den Betrag 14.000 Euro. Weil 14.000 Euro über Frau Bergs Grenze liegen, antwortet die Entscheidungsstelle „verboten“. Die Schadenanwendung führt die Freigabe nicht aus und bietet stattdessen an, den Schaden an die Teamleitung weiterzugeben. Wird Frau Bergs Grenze nächsten Monat auf 15.000 Euro erhöht, genügt es, die Eigenschaft „Betragsgrenze“ in ihren Personendaten anzupassen.
Viele Anwendungen vergeben Rechte über Rollen: Wer die Rolle „Sachbearbeitung“ hat, darf Schäden freigeben. Die tatsächliche Regel der Versicherung ist feiner. Eine Sachbearbeiterin darf nur Schäden ihrer eigenen Region freigeben, nur bis zu ihrer persönlichen Betragsgrenze und nie einen Schaden, bei dem sie selbst die Versicherte ist. Statt fester Rollen verwendet die Schadenanwendung deshalb Attribute, also Eigenschaften, die zum Zeitpunkt der Anfrage bekannt sind:
- Eigenschaften der Person sind zum Beispiel Region, persönliche Betragsgrenze und Abteilung.
- Eigenschaften des Schadens sind seine Region, sein Betrag und die versicherte Person.
- Die gewünschte Aktion ist zum Beispiel lesen, ändern oder freigeben.
- Umstände der Anfrage sind zum Beispiel die Uhrzeit oder ob die Anfrage aus dem Firmennetz kommt.
Eine Regel verknüpft diese Eigenschaften: „Freigeben ist erlaubt, wenn die Region der Person gleich der Region des Schadens ist, der Betrag die Betragsgrenze der Person nicht übersteigt und die Person nicht die Versicherte des Schadens ist.“ Die Regeln für Freigaben legt der Fachbereich fest, hier die Leitung der Schadenabteilung. Region, Abteilung und Betragsgrenze einer Person pflegt nicht das Team der Schadenanwendung, sondern die Personalverwaltung oder die Abteilung, die das Benutzerverzeichnis des Unternehmens führt. Die Entscheidungsstelle heißt auf Englisch Policy Decision Point. Sie kann ein eigener Dienst, eine eingebundene Programmbibliothek oder Code in der Schadenanwendung sein. Werden die Regeln getrennt vom übrigen Code verwaltet, kann das Team der Schadenanwendung die Regeln ändern und prüfen lassen, ohne die ganze Schadenanwendung neu auszuliefern. Die Entscheidungsstelle entscheidet nur. Die Entscheidung durchsetzen muss die Schadenanwendung selbst, und zwar bei der eigentlichen Freigabe, nicht nur durch Ausblenden eines Knopfes. Sonst könnte jemand die Freigabe ohne den Knopf auslösen, etwa mit einer selbst zusammengestellten Anfrage an die Schadenanwendung. Der Teil der Schadenanwendung, der eine Entscheidung durchsetzt, heißt auf Englisch Policy Enforcement Point.
Ist die Entscheidungsstelle ein eigener Dienst, kann sie ausfallen und nicht mehr antworten. Für diesen Fall muss das Team der Schadenanwendung vorher festlegen, was die Schadenanwendung tut. Die sichere Wahl ist, ohne Antwort „verboten“ anzunehmen.
ABAC: Frau Berg darf 8.500 Euro freigeben, 14.000 Euro nicht
Wann ist es sinnvoll und wann nicht?
ABAC lohnt sich
- Rechte hängen von Inhalten, Beträgen, Orten oder Zeiten ab, und Rollen sind dafür zu grob. Mit Rollen allein müsste die Versicherung für jede Kombination eine eigene Rolle anlegen, etwa „Sachbearbeitung Nord bis 10.000 Euro“ und „Sachbearbeitung Süd bis 25.000 Euro“. Bei zehn Regionen und fünf Betragsgrenzen sind das schon 50 Rollen, und jede weitere Bedingung vervielfacht die Zahl. Niemand kann dann noch sicher sagen, wer was darf. Mit ABAC gibt es stattdessen eine einzige Regel, die Region und Betrag von Person und Schaden vergleicht.
- Mitarbeiterinnen wechseln häufig die Region. Mit Rollen müsste bei jedem Wechsel jemand zusätzlich zur neuen Region in den Personendaten auch die Rollen neu vergeben. Mit ABAC genügt die neue Region in den Personendaten.
- Eine Regel hängt vom einzelnen Datensatz ab. Ein Beispiel ist die Vorgabe, dass niemand einen Schaden freigibt, bei dem er selbst der Versicherte ist. Mit Rollen lässt sich diese Vorgabe gar nicht ausdrücken. Mit ABAC geht es, weil die Entscheidungsstelle die versicherte Person des einzelnen Schadens kennt.
- Regeln werden häufig geändert oder müssen vom Fachbereich und von der internen Revision geprüft werden. Die interne Revision ist die Prüfabteilung des Unternehmens und muss nachvollziehen können, wer welchen Schaden freigeben darf. Ohne eigene Regeln stehen Bedingungen wie Region und Betragsgrenze als einzelne Abfragen verstreut im Code der Schadenanwendung, und jede Änderung heißt, die ganze Schadenanwendung neu auszuliefern. Werden die Freigaberegeln getrennt vom übrigen Code verwaltet, können Fachbereich und interne Revision die Freigaberegeln lesen, ohne den übrigen Code zu durchsuchen.
- Rollen legen bereits fest, wer überhaupt Schäden bearbeitet, etwa die Rolle „Sachbearbeitung“, und es fehlen nur Bedingungen wie Region und Betragsgrenze. Ohne ABAC müsste die Versicherung die Rolle „Sachbearbeitung“ in eine eigene Rolle je Region und Betragsgrenze aufteilen. Mit ABAC bleibt die Rolle „Sachbearbeitung“, und eine Regel prüft zusätzlich Region und Betragsgrenze. In der Praxis werden Rollen und ABAC oft so kombiniert.
ABAC ist nicht das Richtige
- Was eine Person darf, hängt nur von ihrer Aufgabe ab, nicht von Region, Betrag oder dem einzelnen Schaden. Jede Sachbearbeiterin darf zum Beispiel jeden Schaden freigeben, und nur die Teamleitung darf Schäden löschen. Die Entscheidungsstelle hätte dann keine Eigenschaften zu vergleichen. Stattdessen legt das Team der Schadenanwendung fest, welche Aktionen zu jeder Rolle gehören, und jede Person erhält eine Rolle. Das heißt Role Based Access Control. Die Schadenanwendung prüft dann bei jeder Freigabe selbst, ob die Person die Rolle „Sachbearbeitung“ hat. Regeln, die getestet werden müssen, und der Aufruf der Entscheidungsstelle bei jeder geschützten Aktion entfallen.
- Die Eigenschaften, auf denen die Regel beruht, werden nicht verlässlich und zeitnah gepflegt. Eine Regel, die mit veralteten Regionen rechnet, entscheidet dann falsch: Eine Mitarbeiterin, die in die Region Süd gewechselt ist, darf weiter Schäden aus Region Nord freigeben. Die Versicherung klärt deshalb zuerst, wer Region und Betragsgrenze jeder Person bei einem Wechsel sofort in die Personendaten einträgt. Bis dahin vergibt sie die Rechte weiter über Rollen, und die Teamleitung ändert die Rolle einer Mitarbeiterin selbst, sobald die Mitarbeiterin die Region wechselt.
- Die Versicherung muss der internen Revision jederzeit eine vollständige Liste vorlegen können, wer welche Daten sehen darf, und hat kein Werkzeug, das diese Liste aus Regeln und Eigenschaften erzeugt. Mit ABAC müsste dafür jemand alle Regeln mit den Eigenschaften aller Personen durchrechnen. Die Versicherung vergibt die Rechte deshalb über Rollen. Die Liste ergibt sich dann direkt aus der Zuordnung, welche Person welche Rolle hat.
Nachteile und typische Fehler
Die Regeln sind im Grunde Programmcode und brauchen Tests. Ein Fehler in einer einzigen Regel kann viele Zugriffe auf einmal falsch erlauben oder sperren. Die Frage „Wer darf diesen Schaden sehen?“ ist schwerer zu beantworten als bei Rollen, weil das Ergebnis erst bei der Auswertung der Regel mit den aktuellen Eigenschaften entsteht. Außerdem müssen Region und Betragsgrenze in den Personendaten stimmen, und diese Angaben pflegt nicht das Team der Schadenanwendung, sondern die Personalverwaltung. Ist die Entscheidungsstelle ein eigener Dienst, kommt bei jeder geschützten Aktion ein zusätzlicher Aufruf hinzu, und dieser Dienst muss so zuverlässig betrieben werden wie die Schadenanwendung selbst. Gilt bei einem Ausfall der Entscheidungsstelle die sichere Antwort „verboten“, bleiben während des Ausfalls Freigaben liegen.
Typische Fehler und woran man sie erkennt:
- Fehlerhafte Regel: Ein Vergleichszeichen in der Regel ist vertauscht. Die Entscheidungsstelle antwortet dann beim Schaden über 14.000 Euro „erlaubt“ und beim Schaden über 8.500 Euro „verboten“. Erkennbar ist das an Freigaben, deren Betrag über der Betragsgrenze der freigebenden Person liegt, oder an einer plötzlichen Häufung abgelehnter Freigaben nach einer Regeländerung.
- Falsche Eigenschaft: Bei einer Mitarbeiterin aus Region Nord ist in den Personendaten die Region Süd eingetragen. Die Personendaten liefern der Schadenanwendung deshalb die Region Süd. Die Entscheidungsstelle erlaubt der Mitarbeiterin dann Freigaben für Schäden aus Region Süd. Erkennbar ist das meist erst bei einem Abgleich der Freigaben mit der tatsächlichen Zuständigkeit, etwa wenn die Teamleitung Süd Freigaben einer Mitarbeiterin aus Region Nord findet.
- Durchsetzung nur in der Oberfläche: Die Schadenanwendung blendet bei „verboten“ nur den Knopf aus, prüft aber bei der Freigabe selbst nicht. Jemand schickt die Freigabe des Schadens über 14.000 Euro ohne den Knopf als selbst zusammengestellte Anfrage an die Schadenanwendung. Die Schadenanwendung fragt die Entscheidungsstelle nicht und gibt den Schaden frei. Erkennbar ist das an Freigaben, zu denen im Protokoll der Entscheidungsstelle kein „erlaubt“ steht.
- Erlauben bei Ausfall: Die Schadenanwendung behandelt eine ausbleibende Antwort der Entscheidungsstelle als „erlaubt“. Fällt die Entscheidungsstelle aus, führt die Schadenanwendung jede angeforderte Freigabe aus, auch die des Schadens über 14.000 Euro durch Frau Berg. Erkennbar ist das an Freigaben in einem Zeitraum, in dem die Entscheidungsstelle keine Anfragen beantwortet hat.
Weiterführend
Verwandte Ansätze
- Least Privilege: der Grundsatz, jeder Person nur die Rechte zu geben, die sie braucht; feine Regeln mit Attributen helfen, diesen Grundsatz umzusetzen.
- Zero Trust: prüft jeden einzelnen Zugriff, statt einem Netz pauschal zu vertrauen, und nutzt dafür oft Eigenschaften wie Gerät und Standort.
- Audit Logging: hält fest, wer wann was freigegeben hat und welche Entscheidung die Regel getroffen hat.
Werkzeuge und Umsetzungen
- Open Policy Agent: allgemeine Entscheidungsstelle, die als eigener Dienst oder als Bibliothek laufen kann. Regeln werden in der Sprache Rego geschrieben.
- Cedar: Regelsprache mit einer Bibliothek, die die Regeln auswertet. Regelsätze lassen sich mit Werkzeugen automatisch auf bestimmte Fehler und Widersprüche untersuchen.
- Casbin: Bibliothek für viele Programmiersprachen, mit der sich sowohl rollenbasierte als auch attributbasierte Regeln umsetzen lassen.
Quellen
- NIST SP 800-162: Guide to Attribute Based Access Control: Leitfaden der US-Normungsbehörde NIST, der ABAC und die Aufgabe der Entscheidungsstelle definiert.
- OASIS: eXtensible Access Control Markup Language (XACML) Version 3.0: Standard von 2013 mit einer Regelsprache für Zugriffsregeln. Der Standard beschreibt die Entscheidungsstelle (Policy Decision Point), den durchsetzenden Programmteil (Policy Enforcement Point) und die Quellen, die Eigenschaften liefern.