Teil 17: Autorisierung

Die Architektur der Autorisierung

Gion Manetsch, Daniel Takai

© Shutterstock / Sergey Nivens

Die Autorisierung meint in der Softwarearchitektur die Berechtigung zur Nutzung einer Ressource und ist ein elementarer Bestandteil des Informationsschutzes. Sie umfasst sowohl die Vergabe von Rechten als auch die Prüfung derselben, also zwei verschiedene Prozesse. Wir nehmen die Autorisierung unter die Lupe.

Die Autorisierung ist ein Synonym für die Zugriffskontrolle. Eng mit der Autorisierung verknüpft ist die Auditierbarkeit, mit deren Hilfe die Nutzung einer Ressource im Nachhinein überprüft werden kann. Eine Ressource kann im Kontext der Softwarearchitektur Daten meinen, wie etwa ein Dokument. Es kann sich aber auch um eine Geschäftsfunktion handeln, die geschützt werden soll. Es gibt hierfür zwei verschiedene Ansätze: den klassischen rollenbasierten Ansatz sowie die neuere, attributbasierte Autorisierung, deren Vor- und Nachteile wir besprechen werden. Ein gängiges Dokument im Zusammenhang mit der Autorisierung ist das so genannte Berechtigungskonzept, in dem sowohl die zu schützenden Ressourcen als auch die technische Strategie des Schutzes beschrieben stehen. Das Berechtigungskonzept heißt manchmal auch Rechte- und Rollenkonzept oder Access Control Policy. Die verschiedenen Konzepte und Prozesse rund um die Autorisierung sehen Sie in Abbildung 1.

Abb. 1: Prozesse der Autorisierung

Abb. 1: Prozesse der Autorisierung

Ein wesentlicher Aspekt der Autorisierung sind die Kosten, die in der Verwaltung der Rechte entstehen. Hierfür gibt es eine einfache Faustregel: Je umfangreicher das Berechtigungskonzept, desto höher ist der Wartungsaufwand und der Betrieb. Das umfasst die Vergabe, die Veränderung und den Entzug von Rechten. Das Konzept muss die vorgegebenen Sicherheits- oder Compliance-Anforderungen erfüllen. Das heißt, dass diese Compliance-Vorgaben die Kosten der Bewirtschaftung effektiv steuern. Während früher häufig ein striktes Need-to-know-Prinzip gefordert wurde, wird heute sehr hoher Wert auf die Automatisierbarkeit und Wartbarkeit der Rechte gelegt, um die Kosten zu drücken. Das Risiko, dass nun jemand auf mehr Daten und Funktionen Zugriffe hat, als notwendig wäre, kann mit der Auditierbarkeit der Zugriffe kompensiert werden. Nehmen Sie als Beispiel ein Wiki: Anstatt Gruppen mit Schreibrechten zu pflegen, kann man auch allen Schreibrechte geben, wenn nachvollziehbar ist, wer eine Änderung vorgenommen hat.

Lesen Sie auch: „Auch bei Microservices kann man Security zentral abbilden“

Role-Based Access Control: ein Standard wird geboren

Erst seit den 70er-Jahren vergeben Organisationen in Abhängigkeit von der Rolle eines Benutzers Privilegien für den Zugriff auf ein System. Die damals eingesetzten Mechanismen waren jedoch simpel und stets spezifisch für ein bestimmtes System. Allgemeine Zugangskonzepte oder Rollendefinitionen fehlten. Auch gab es damals nur sehr wenig strukturierte Sicherheitsanalysen, und jeder Hersteller kochte sein eigenes Süppchen: Absprachen oder Standards gab es keine.

Erst 1992 wurde ein allgemeines rollenbasiertes Modell der Zugriffskontrolle vorgeschlagen: Role-Based Access Control (RBAC) [1]. Hier werden Benutzern Rollen zugewiesen, die den Zugriff auf Ressourcen regeln. Die Rolle ist dabei nur ein semantisches Konstrukt, um das die Zugriffsrechte formuliert werden können. Die grundlegende Idee ist, dass Rollen innerhalb einer Organisation relativ stabil sind, sich aber Benutzer und Berechtigungen schnell ändern. Die Zugangskontrolle über Rollen vereinfacht also die Verwaltung und spart dadurch Geld. Nicht verwechseln sollte man Rollen mit Gruppen. Gruppen sind nur Sammlungen von Benutzern, Rollen hingegen dienen der Vergabe von Rechten.

1996 hat man das RBAC-Modell verbessert [2], im Jahre 2000 verfeinert [3] und 2004 wurde es schließlich vom ANSI standardisiert [4]. Im RBAC-Level-1-Modell (Flat RBAC) gibt es vier verschiedene Mengen: Benutzer (User: U), Rollen (Roles: R), Berechtigungen (Permissions: P) und Sessions (S). Benutzer haben eine oder mehrere Rollen (Relation UA: User Assignment), und an den Rollen hängen die Berechtigungen (Relation PA: Permission Assignment). Außerdem kann ein Benutzer eine oder mehrere Sessions haben, die jeweils eine Verknüpfung zwischen ihm und einer Rolle darstellen. Berechtigungen beziehen sich jeweils auf Ressourcen, aber nicht auf die Elemente des RBAC-Modells selbst: Die Modifikation der Mengen U, R und P sowie der Relationen UA und PA sind so genannte administrative Permissions. Die Mengen und Relationen von RBAC sind in Abbildung 2 dargestellt.

Abb. 2: Das flache RBAC-Modell

Abb. 2: Das flache RBAC-Modell

Das flache RBAC-Modell kann um Hierarchien von Rollen erweitert werden und heißt dann hierarchisches RBAC-Modell oder RBAC Level 2. Diese Hierarchien folgen oft den Strukturen einer Linienorganisation, beispielsweise, um einem Arzt mehr Rechte in einem System zuweisen zu können als einer Krankenschwester. Zusätzlich zu den Mengen und Relationen des Basismodells enthält das hierarchische RBAC also eine neue Halbordnung RH. Halbordnungen sind reflexiv, transitiv und antisymmetrisch, was in diesem Fall bedeutet, dass Mehrfachvererbung unterstützt werden sollte. De facto bieten die Hersteller aber nur einfache Vererbung an, d. h. die Rollen werden als Baum geführt.

Eine weitere mögliche Erweiterung ist das so genannte Constrained RBAC. Dieses Modell heißt auch RBAC Level 3. Eine Einschränkung ist ein einfaches Prädikat auf UA und PA, um Kombinationen von Rollen oder Berechtigungen zu untersagen. Beispielsweise sollte der Einkauf nicht gleichzeitig die Rechnungen bezahlen, weil das Betrug ermöglicht. Prädikate auf den Relationen können solche Kombinationen unmöglich machen und sichern so die Organisation ab. Dieses Prinzip heißt im Englischen Separation of Duties (SOD). Ein weiteres, häufig vorkommendes Prädikat ist eine Beschränkung der Anzahl von Benutzern in einer Rolle. So kann es auf einer Station nur einen Chefarzt und seinen Stellvertreter geben.

Der höchste RBAC Level 4 heißt symmetrisches RBAC, bei dem der Administrator das System befragen kann, welche Rechte ein Benutzer auf einem bestimmten System hat. Diese Abfrage stellt den Architekten vor ganz besondere Herausforderungen. Man muss sich nur überlegen, wie verschieden die Berechtigungsmodelle auf den eingesetzten Services eines Unternehmens sind, und kommt dann von alleine drauf, wie komplex die übergeordnete Abfrage der Berechtigungen sein wird. Symmetrisches RBAC ist auch nicht Teil des ANSI-Standards geworden.

In der Praxis wird heute meistens ein hierarchisches System von Rollen verwendet (RBAC Level 2). Dies wird in speziellen Fällen um Constraints erweitert, die allerdings herstellerspezifisch sind. Der Dell Identity Manager erlaubt beispielsweise eine Risikokalkulation über einen Risk-Index, der pro Nutzer errechnet wird. Andere Systeme sind komplementär zum bestehenden IDM-System, wie SAP Governance sowie Risk- und Compliance-Lösung.

Ein Rollenmodell entwickeln

Bei der Entwicklung des Rollenmodells ist es empfehlenswert, nicht zu granular zu beginnen, sondern das Modell so einfach wie möglich zu halten. Eine spätere Erweiterung oder Spezialisierung ist immer möglich, der Weg zurück aber ungemein schwieriger. Hersteller von IDM-Systemen und Directories bieten auch Grundmodelle an, die für viele Organisationen und Applikationen passen und die sich auch anpassen lassen. In der Praxis kann sich eine geschichtete Typisierung von Rollen lohnen, um der Komplexität in einer größeren IT-Landschaft Herr zu werden. Wir empfehlen eine Unterteilung in die Typen, die in Abbildung 3 dargestellt sind. Die Beziehungen zwischen den Rollen über die Schichten hinweg kann 1:1 oder 1:n sein.

Die Geschäftsrolle (GR) hat verschiedene Ausprägungen, die auch gleichzeitig einer Person zugeordnet werden können. Die naheliegendste ist die Organisationsrolle, die zu Berechtigungen nach Organisationszugehörigkeit verhilft, etwa die Angehörigkeit zur Finanzabteilung. Des Weiteren ist die Funktion der Person im Unternehmen eine Geschäftsrolle, beispielsweise Controller oder Teamleiter. Darüber hinaus gibt es auch temporäre Rollen, beispielsweise durch die Mitarbeit an einem Projekt, wie die des Projektleiters.

Ein weiterer Typ ist die Systemrolle (SR), die bestehende Systeme einer Unternehmung grobgranular kapselt und den Geschäftsrollen zugeordnet wird. Die Definition eines Systems ist offen, so ist es möglich, die Zuordnung nach Anwendungsfällen vorzunehmen. Da wir hier die Geschäftssicht abbilden möchten, sollte an dieser Stelle noch kein konkreter Bezug auf Services vorgenommen werden. Beispiele für Systemrollen sind Service-Desk-Mitarbeiter, Zeugwart oder Fahrzeugtechniker.

Geschäfts- und Systemrollen werden nun Anwendungsrollen (AR) zugeordnet, die im konkreten Service konfiguriert werden. Selbstverständlich sind die Anwendungsrollen spezifisch für den Service, im JIRA-System wäre eine Anwendungsrolle der Systemadministrator. Anwendungsrollen dienen der konkreten Zuweisung von Rechten, die durch die Rollen im Service häufig vorgegeben sind. Die Rechte und Ressourcen sind in der Abbildung 3 als unterste Schicht dargestellt. Rechte können einzelne Operationen sein, Ressourcen stehen etwa für einzelne Ordner in einem Dateisystem.

Abb. 3: Typen von Rollen im Rollenmodell

Abb. 3: Typen von Rollen im Rollenmodell

Der große Vorteil von RBAC ist der Determinismus: Man kann jederzeit leicht feststellen, wer auf welchen Ressourcen welche Berechtigungen besitzt. Dadurch ist das Berechtigungskonzept einfach anzupassen und auch transparenter, da sich die Zusammenhänge leicht visualisieren lassen. Der Vorteil, die Auswirkungen von Änderungen im Vorfeld erkennen zu können, darf nicht unterschätzt werden. Daraus ergibt sich eine gute Auditierbarkeit des Systems, auch für Business Owner. Für sie ist es einfach nachvollziehbar, welche Berechtigungen vergeben wurden und attestiert werden sollen, da die Rollen klare Namen haben, die leicht verständlich sind.

Der Nachteil von RBAC ist, dass die Rollen und Ressourcen bekannt sein müssen, um Entscheidungen im Kontext fällen zu können. Das ist insbesondere für einen Administrator bei der Verwaltung schwierig, aber auch für einen Business Owner, der nur seine Ressourcen kennt, aber nicht die Rollen. Zudem kann die Anzahl der Rollen schnell explodieren, wenn zu feingranular berechtigt werden soll. Es besteht hier insbesondere das substanzielle Risiko, dass Servicesemantik in das Rollenkonzept auf Geschäftsebene schwappt und dieses komplizierter als nötig macht.

Häufig wird bei RBAC die Verwaltung von Subbäumen delegiert. Die Delegation ist für Stellvertreterregelungen im IAM zwar sehr wichtig, aber das Rollenmodell läuft dann Gefahr, sich nach der Delegationsstruktur zu orientieren und nicht nach dem Geschäft. Wenn viele Rollen im Einsatz sind, muss auch eine große Anzahl von Delegationen in der Rollenverwaltung erstellt und gewartet werden. Das bedeutet schlicht Overhead und kostet Geld. Es gibt zu RBAC diverse Zusätze, die die Delegation erleichtern – wie PBDM oder CRBAC.

Sehen Sie im JAX TV: Single Sign-on für Microservices bzw. verteilte (Java-EE-)Anwendungen

Attribut-Based Access Control

ABAC erlaubt den Zugriff auf Ressourcen über domänenspezifische Attribute, beispielsweise die Funktion im Unternehmen oder das Alter. Diese können dann für die Autorisierung verwendet werden. Wichtig bei diesem Konzept ist, dass nicht nur der Nutzer diese Attribute hat, sondern auch die Ressource, auf die zugegriffen werden soll. Mittels einfacher mathematischer Funktionen kann ein ABAC-System dann entscheiden, ob der Zugriff erlaubt ist oder nicht. Bei diesem Verfahren kann etwa ein Dokument mit dem Attribut Finance versehen werden. Hat ein Benutzer dann das Attribute Controller, greift eine Regel, die den Zugriff erlaubt.

Eine Sammlung solcher Regeln zu Gunsten der Autorisierung heißt Policy, die wiederum zu Policy Sets zusammengefasst werden können. Um das Management von Policies und Policy Sets zu vereinfachen und die verschiedenen Konzepte aus der Disziplin der Zugriffskontrolle formal auszudrücken, wurde die Extensible Access Control Markup Language (XACML) geschaffen. XACML definiert deklarative XML-basierte Regeln und Protokolle zur Entscheidung, ob ein Zugang gewährt werden soll. 2013 wurde die Version 3.0 des Standards verabschiedet, der im Wesentlichen die folgenden Schritte umfasst (Abb. 4):

  1. Der Policy Administration Point (PAP) legt Policies und Policy Sets fest.
  2. Der Access Requestor sendet eine Anfrage zum Zugriff.
  3. Der Policy Enforcement Point (PEP) schickt die Anfrage verbatim im nativen Format an den Context Handler.
  4. Der Context Handler übersetzt die Anfrage nach XACML und schickt sie an den Policy Decision Point (PDP).
  5. Der PDP fragt nach weiteren Attributen beim Policy Information Point (PIP) nach, beispielsweise für weitere Kontextinformationen über die konkrete Umgebung oder das Subject, also den Access Requestor. Der Grund, warum die Informationen erst an dieser Stelle nachgefragt werden, ist die Sicherheit: Attribute aus dem PIP sind gegen Manipulationen besser geschützt als Eingaben gegen den PEP über den initialen Request. Die Nachfrage des PDP läuft über den Context Handler.
  6. Der PDP wertet die Anfrage mit allen Attributen gegen die Policies aus und gibt die Entscheidung an den Context Handler zurück.
  7. Der Context Handler übersetzt die Antwort in das native Format für den PEP.
  8. Der PEP gibt nun den Zugriff auf die gewünschte Ressource frei und erfüllt außerdem die in den Policies festgelegten Obligations für den Zugriff. Beispielsweise erlaubt XACML den Versand einer E-Mail beim Zugriff auf ein bestimmtes Dokument oder die Ausführung einer konkreten Funktion.
Abb. 4: Funktionsweise von XACML

Abb. 4: Funktionsweise von XACML

Der größte Vorteil der attributbasierten Zugriffskontrolle ist, dass einfache Regeln definiert werden können. Diese können sehr feingranular und kontextbezogen sein, was bei RBAC schwierig ist. Zudem können die Regeln durch die Architektur auch Attribute von Ressourcen und Benutzern auswerten, die gar nicht im IDM-System vorhanden sind, sondern über den PIP provisioniert werden. Es hat sich außerdem gezeigt, dass die Regeln wenig Pflege benötigen, da sie keine Struktur brauchen. Das ist bei RBAC anders, da sich die Struktur durch die Rollen auch ändern kann, wenn sich die Organisation verändert.

ABAC kann auch zu einer Regelexplosion führen, ähnlich wie die Rollenexplosion beim RBAC, da ein System mit n Attributen, 2n mögliche Kombinationen von Regeln hat. Hierdurch ist es auch schwierig, die Symmetrie herzustellen und so herauszufinden, welche Berechtigungen ein Benutzer hat. Hier muss gegebenenfalls eine große Anzahl von Regeln ausgeführt werden, und dies in der exakt gleichen Reihenfolge, wie es für den Benutzer selbst erfolgt. In der Folge kann es unmöglich sein, Risiken bei Zugriffen festzustellen.

ABAC-Systeme können auch langsam in der Durchführung von Autorisationen sein, weil Daten von mehreren anderen Services zur Berechnung benötigt werden. Da diese Berechnungen durch das ABAC-System nicht kontrolliert werden können, können sie auch nicht vorberechnet oder zwischengespeichert werden.

RBAC oder ABAC, das ist hier die Frage

In Securitykreisen findet seit einiger Zeit ein Disput statt, ob RBAC oder ABAC eingesetzt werden sollte. Beide Systeme haben ihre Vor- und Nachteile. RBAC hat den Nachteil, dass initial eine Berechtigungsstruktur mit Rollen definiert werden muss, während ABAC zwar mit einfacheren Strukturen punktet, dafür aber bei der Revision und Anpassung von Benutzerberechtigungen einen hohen Aufwand verlangt. Als Experten empfehlen wir einen Hybridansatz zwischen RBAC und ABAC. Dieser Ansatz wird heute bereits von vielen IDM-Systemen als Möglichkeit angeboten. Die folgenden Verfahren kommen dabei zum Einsatz: attributbasiert, rollenbasiert und dynamische Rollen.

  • Attributbasiert: Rollen werden als Attribute behandelt, allerdings flach und ohne Hierarchie. Da die Attribute am Benutzer hängen, geht die Beziehung zwischen Rolle und Berechtigung verloren.
  • Rollenbasiert: Hier werden die Berechtigungen nach RBAC den Rollen zugewiesen, aber als Attribute im Rahmen der Auswertung von Regeln verwendet. Die Regeln können hier Berechtigungen nur einschränken, aber nicht erweitern. Die Flexibilität von ABAC geht so teilweise verloren, da Berechtigungen durch die Rollen erzwungen werden. Dafür ist die bei RBAC vorhandene Nachvollziehbarkeit besser gewährleistet.
  • Dynamische Rollen: Hierbei werden Rollen den Benutzern aufgrund von attributbasierten Regeln zugeordnet. Die Berechtigungen hängen dann an den Rollen und lassen sich auswerten.

In der Praxis ist eine Mischung der letzten beiden häufig anzutreffen, die wir RABAC nennen.

RABAC in einer SOA

In einer SOA oder Microservices-Architektur integrieren wir häufig Legacy-Systeme und können einen ESB als Proxy zur Transformation der Kommunikation mit diesen Systemen nutzen. Abbildung 5 zeigt das Vorgehen schematisch. Der Policy Enforcement Point wird in diesem Beispiel durch den Bouncer Service im ESB ersetzt, der eingehende Requests mit dem PDP verhandelt. Diese Architektur ist einfacher als das vollumfängliche XACML und lässt sich je nach Anzahl der Features sogar selber entwickeln. Beispielsweise kann auf die Programmierung der optionalen Obligations verzichtet werden. Es gibt auch Open-Source-Implementierungen des XACML-Standards, deren Komponenten eingebunden werden können, beispielsweise OpenAz oder das XACML Framework von AT&T auf GitHub.

Abb. 5: Bouncer-Pattern für die RABAC-Autorisierung

Abb. 5: Bouncer-Pattern für die RABAC-Autorisierung

Je nachdem, welches IDM-System eingesetzt wird, kann der PDP auf unterschiedlich viele Informationen zugreifen. Der Regelfall ist, dass dem Bouncer und damit dem PDP nur der Benutzername präsentiert werden kann. Im Fall von SAML können über die so genannten Claims auch weitere Attribute gereicht werden, was im Rahmen einer Unternehmensarchitektur sinnvoll ist, wenn es sich um eine begrenzte Anzahl von Attributen handelt.

Möchte man ein hierarchisches Rollenmodell abbilden, kommt in dieser Architektur dem PIP die Aufgabe zu, die Rollen aus einem Directory Service zu lesen, der in der Abbildung 5 als LDAP notiert ist. Hier können auch allfällige andere Attribute gespeichert werden. Man beachte, dass dies die Autorisierungen im System verlangsamen kann und Last auf dem LDAP-Service erzeugt. Dieses Problem kann durch Zwischenspeicherung gelöst werden, beispielsweise durch einen Rollen-Cache im LDAP Connector. Wie immer macht die Zwischenspeicherung in der Architektur eine Dose Würmer auf und erzeugt zusätzliche Komplexität.

Fazit

Die Zugriffsbeschränkung auf Ressourcen im Unternehmen ist eine Basisanforderung an die Architektur. Das ist angesichts der vielen verschiedenen zu integrierenden Systeme eine große Herausforderung. Es ist fahrlässig, kritische Daten nicht zu schützen. Nach der Datenschutzgesetzgebung ist das in Europa auch nicht erlaubt. Architekten und Manager, die die Informationssicherheit vernachlässigen, machen sich der Verletzung ihrer Aufsichtspflicht schuldig. Dabei generiert die Autorisierung substanzielle Kosten, die im Vorfeld mit eingeplant werden müssen.

Aus Gründen der konzeptionellen Integrität empfehlen wir den Einsatz eines Rollenmodells. Dieses spiegelt die einsetzende Organisation wider und kann deswegen gut verstanden werden. Allerdings sollte das mit attributbasierter Autorisierung kombiniert werden, um komplexere und kontextsensitive Autorisierungen zu ermöglichen und gleichzeitig den Pflegeaufwand niedrig zu halten. In beiden Fällen ist die Komplexität möglichst gering zu halten, um Aufwände und damit Kosten zu minimieren. Dabei kann es hilfreich sein, die strenge Zugangskontrolle durch Auditierbarkeit zu kompensieren.

Geschrieben von
Gion Manetsch
Gion Manetsch
Gion Manetsch ist Security-Architekt und arbeitet in Bern. Seine Aufgabe ist es, die Sicherheit im Aufbau von IT-Lösungen sicherzustellen, unter der Berücksichtigung von Businessanforderungen und Wirtschaftlichkeit. Dabei sollen keine Insellösungen gebaut werden, sondern immer die Gesamtsicht im Vordergrund stehen.
Daniel Takai
Daniel Takai
Daniel Takai ist Enterprise-Architekt, arbeitet in der Schweiz und ist auf die digitale Transformation spezialisiert. Er berichtet regelmäßig im Java Magazin über seine Erfahrungen und Erkenntnisse. Im Frühling 2016 erscheint sein Buch über Methoden der Entwicklung von Cloud-basierten und serviceorientierten Websystemen.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.