Role Based Access Control
Rechte über Rollen vergeben
Die Idee und ihr Nutzen
Frau Meier arbeitet in der Schadenabteilung einer Versicherung. Sie soll Schadenakten lesen und bearbeiten dürfen, aber keine Auszahlungen freigeben. Statt ihr jedes dieser Rechte einzeln zu geben, erhält sie die Rolle „Sachbearbeitung“. Eine Rolle ist eine benannte Sammlung von Rechten, die zu einer bestimmten Tätigkeit gehört. Die Rolle „Sachbearbeitung“ enthält die Rechte „Schaden lesen“ und „Schaden ändern“. Eine andere Rolle, „Auszahlungsfreigabe“, enthält das Recht, Auszahlungen freizugeben. Die Rechte werden so einmal je Rolle gepflegt statt für jede Person einzeln. Diese Art der Rechtevergabe heißt Role Based Access Control, abgekürzt RBAC, auf Deutsch rollenbasierte Zugriffskontrolle.
Wie funktioniert es?
Frau Meier will die Akte zu Fall 4711 lesen und öffnet den Schadenfall im Schadensystem, dem Programm, mit dem die Schadenabteilung ihre Fälle bearbeitet. Die Anfrage geht an den Server des Schadensystems, den Teil des Programms, der im Rechenzentrum läuft und jede Anfrage bearbeitet. Der Server des Schadensystems fragt die Rollenverwaltung, das Verzeichnis der Rollen und ihrer Rechte, ob die Rolle „Sachbearbeitung“ das Lesen erlaubt. Zusätzlich prüft der Server des Schadensystems, ob Frau Meier für Fall 4711 zuständig ist. Die Rollenverwaltung antwortet „ja“, denn die Rolle „Sachbearbeitung“ enthält das Recht „Schaden lesen“. Danach ergänzt Frau Meier eine Notiz in der Akte, denn auch das Recht „Schaden ändern“ gehört zu ihrer Rolle. Die Oberfläche des Schadensystems, mit der Frau Meier arbeitet, zeigt ihr die Schaltfläche „Auszahlung freigeben“ gar nicht erst an. Trotzdem schickt Frau Meier die Freigabe der Auszahlung für Fall 4711 mit einem eigenen Programm direkt an den Server des Schadensystems. Der Server des Schadensystems lehnt ab, weil keine Rolle von Frau Meier das Recht „Auszahlung freigeben“ enthält. Ein Kollege mit der Rolle „Auszahlungsfreigabe“ gibt die Auszahlung für Fall 4711 frei, und der Server des Schadensystems erlaubt die Freigabe, weil die Rolle des Kollegen das Recht enthält.
Die Rechtevergabe hat drei Stufen. Ein Recht ist eine erlaubte Art von Handlung im Schadensystem, etwa „Schaden lesen“, „Schaden ändern“ oder „Auszahlung freigeben“. Eine Rolle fasst die Rechte einer Tätigkeit zusammen. Personen erhalten Rollen, nie einzelne Rechte. Die Zugänge zum Schadensystem richten die Administratoren des Schadensystems ein. Die Administratoren beschreiben die Tätigkeiten zusammen mit der Schadenabteilung als Rollen und legen fest, welche Rechte jede Rolle enthält. Diese Zuordnung speichern die Administratoren in der Rollenverwaltung. Jeder Person weisen die Administratoren die Rollen zu, die sie für ihre aktuelle Tätigkeit braucht. Wechselt eine Person ihre Tätigkeit, entziehen die Administratoren ihr die nicht mehr benötigten Rollen und weisen ihr die neuen zu.
Verbindlich entscheidet der Server des Schadensystems: Bei jeder Anfrage prüft er, ob eine der Rollen der anfragenden Person die gewünschte Handlung erlaubt, auch wenn die Anfrage nicht über die Oberfläche kommt. Die Oberfläche blendet Schaltflächen für nicht erlaubte Handlungen nur aus, damit niemand eine Handlung versucht, die ohnehin abgelehnt würde. Eine ausgeblendete Schaltfläche ist kein Schutz, wie die Freigabe zeigt, die Frau Meier mit einem eigenen Programm direkt an den Server des Schadensystems geschickt hat. Eine Rolle beantwortet die Frage, ob eine Person eine bestimmte Art von Handlung überhaupt ausführen darf. Ob die Person einen ganz bestimmten Fall sehen oder ändern darf, hängt von weiteren Merkmalen ab. Solche Merkmale sind zum Beispiel die Region, der Betrag oder die Zuständigkeit für den Fall. Diese Merkmale prüft der Server des Schadensystems zusätzlich, bei Frau Meier die Zuständigkeit für Fall 4711.
Ist für eine Handlung gar kein Recht festgelegt, etwa für eine neue Handlung „Akte löschen“, für die noch niemand ein Recht angelegt hat, sollte der Server des Schadensystems die Anfrage ablehnen, statt sie im Zweifel zu erlauben.
Rollenbasierte Zugriffskontrolle: Frau Meier darf lesen und ändern, aber nicht auszahlen
Wann ist es sinnvoll und wann nicht?
Role Based Access Control lohnt sich
- Viele Menschen üben dieselbe Tätigkeit aus. Beispiele sind Sachbearbeitung, Freigabe und Buchhaltung. In der Schadenabteilung arbeiten mehrere Hundert Menschen. Vergeben die Administratoren jedes Recht für jede Person einzeln, entstehen Tausende Einzeleinträge. Ändert sich, was die Rolle „Sachbearbeitung“ erlauben soll, ändern die Administratoren die Rolle einmal, und die Änderung gilt für alle Personen mit dieser Rolle.
- Menschen wechseln ihre Tätigkeit, aber die Tätigkeiten selbst und die Rechte, die zu einer Tätigkeit gehören, ändern sich selten. Ohne Rollen müssen die Administratoren bei jeder Neueinstellung und jedem Wechsel herausfinden, welche Einzelrechte hinzukommen und welche wegfallen, und dabei bleiben leicht Rechte stehen. Wechselt der Kollege mit der Rolle „Auszahlungsfreigabe“ in eine andere Abteilung, entziehen ihm die Administratoren diese eine Rolle, statt einzelne Rechte zu suchen.
- Prüfer wollen nachvollziehen, wer welche Handlungen ausführen darf. Mit Rollen sehen die Prüfer eine Liste der Rollen und ihrer Rechte statt Tausender Einzelrechte.
Role Based Access Control ist nicht das Richtige
- Eine Regel hängt von Merkmalen des einzelnen Falls oder der Situation ab. Ein Beispiel ist „darf nur eigene Fälle unter 10.000 Euro freigeben“. Mit Rollen allein müssten die Administratoren für jede Kombination eine eigene Rolle anlegen, etwa „Freigabe bis 10.000 Euro in der Region Nord“. Dann legen die Administratoren Regeln nach Attribute Based Access Control fest, und der Server des Schadensystems wertet bei jeder Anfrage Merkmale wie Betrag, Region und Zuständigkeit aus. Die vielen Rollen für einzelne Kombinationen entfallen. Wer prüfen will, wer welche Fälle freigeben darf, muss dann allerdings jede Regel lesen, statt eine Liste von Rollen durchzusehen.
- Ein sehr kleines Team arbeitet mit einem System, und jede Person braucht andere Rechte. Jede Rolle hätte dann nur ein Mitglied, und die Rollen sparen keinen einzigen Eintrag. Dann weisen die Administratoren jeder Person ihre Rechte direkt zu. Die Rollen in der Rollenverwaltung, die gepflegt und regelmäßig geprüft werden müssten, entfallen.
Nachteile und typische Fehler
Die Administratoren müssen die Rollen laufend pflegen, denn Rollen nützen nur, solange sie zu den Tätigkeiten passen. Eine vergebene Rolle bleibt bestehen, bis die Administratoren sie entziehen. Die Administratoren müssen deshalb in festen Abständen prüfen, ob die vergebenen Rollen noch zur tatsächlichen Arbeit passen. Das braucht Zeit, auch bei Führungskräften, die die Rollen ihrer Mitarbeitenden bestätigen. Alle Anwendungen, die dieselben Rollen nutzen, hängen von der gemeinsamen Rollenverwaltung ab. Ändert sich dort eine Rolle, ändern sich die Rechte in allen diesen Anwendungen zugleich.
Typische Fehler und woran man sie erkennt:
- Zu viele Rollen: Die Administratoren legen für jeden Sonderfall eine eigene Rolle an. Mit der Zeit entstehen Hunderte Rollen, und niemand überblickt mehr, welche Rolle welche Rechte enthält. Erkennbar ist das an Rollen mit nur einem Mitglied und an Rollen, deren Rechte sich kaum unterscheiden.
- Angesammelte Rechte: Rollen werden beim Wechsel der Tätigkeit nicht entzogen, sodass langjährige Mitarbeitende mehr Rechte haben, als sie brauchen. Ein Mitarbeiter, der früher Auszahlungen freigegeben hat und inzwischen in einer anderen Abteilung arbeitet, könnte so weiter Geld auszahlen, ohne dass es jemandem auffällt. Erkennbar ist das an Personen, die Rollen aus früheren Abteilungen behalten haben.
- Schutz nur in der Oberfläche: Die Oberfläche blendet die Schaltfläche aus, der Server des Schadensystems prüft aber nicht selbst. Frau Meier schickt die Freigabe der Auszahlung für Fall 4711 mit einem eigenen Programm direkt an den Server des Schadensystems, und der Server führt die Freigabe aus. Erkennbar ist das, wenn der Server des Schadensystems eine Anfrage erlaubt, die an der Oberfläche vorbei abgeschickt wurde.
- Zuständigkeit nicht geprüft: Der Server des Schadensystems prüft nur die Rolle. Jede Person mit der Rolle „Sachbearbeitung“ kann dann jede Akte ändern, auch fremde Fälle. Erkennbar ist das an Änderungen durch Personen, die für den Fall nicht zuständig sind.
- Unvereinbare Rollen: Eine Person erhält sowohl „Sachbearbeitung“ als auch „Auszahlungsfreigabe“ und kann für denselben Fall den Schaden bearbeiten und die Auszahlung freigeben. Damit entfällt die Trennung, nach der eine zweite Person freigeben soll. Erkennbar ist das an Fällen, in denen dieselbe Person bearbeitet und freigegeben hat.
Weiterführend
Verwandte Ansätze
- Least Privilege: der Grundsatz, jeder Person nur die Rechte zu geben, die sie für ihre Arbeit braucht. Rollen, die nur die Rechte einer einzigen Tätigkeit enthalten, setzen diesen Grundsatz um.
- Audit Logging: hält fest, wer eine Handlung wie eine Auszahlungsfreigabe tatsächlich ausgeführt hat. Die Rollen regeln, wer sie ausführen darf.
- Token Based Authentication: weist bei jeder Anfrage nach, wer anfragt. Der Server des Schadensystems braucht diese Angabe, um die Rollen der Person zu prüfen.
Quellen
- NIST: Role Based Access Control: Projektseite der US-Normungsbehörde NIST; beschreibt Personen, Rollen und Rechte, die Formalisierung durch David Ferraiolo und Rick Kuhn 1992 und den Standard ANSI/INCITS 359.
- OWASP: Authorization Cheat Sheet: Empfehlungen der Sicherheitsorganisation OWASP, Berechtigungen bei jeder Anfrage auf dem Server zu prüfen, im Zweifel abzulehnen und zu viele Rollen zu vermeiden.