Im Rahmen der Autorisierung wird festgelegt, was eine authentifizierte Identität (Benutzer, Anwendung oder Dienst) tun und auf welche Ressourcen sie innerhalb eines Systems zugreifen darf.

In den meisten Systemen findet die Autorisierung im Anschluss an die Authentifizierung statt. Sobald das System weiß, wer Sie sind, wird im Rahmen der Autorisierung festgelegt, was Sie tun dürfen.

Die Autorisierung stellt sicher, dass jede authentifizierte Identität innerhalb definierter Grenzen agiert. Ohne sie könnte ein Benutzer, der sich erfolgreich anmeldet (Authentifizierung), auf alle sensiblen Daten zugreifen und beliebige Aktionen ausführen (Authentifizierungsfehler). In Zero Trust-Architekturen werden Autorisierungsentscheidungen während einer Session kontinuierlich und nicht nur beim ersten Zugriff evaluiert.

Die Autorisierung verbindet drei Hauptkomponenten miteinander:

• Benutzer (authentifizierte Identitäten)
• Berechtigungen (spezifische Rechte zur Durchführung von Aktionen, z. B. read:Patients)
• Ressourcen (die zu schützenden Assets)

Rollenbasierte Zugriffskontrolle (Role Based Access Control, RBAC)

RBAC ist das zugrunde liegende Autorisierungsmodell. Es vereinfacht die Verwaltung der Berechtigungen, indem den Rollen (z. B. Admin, Editor, Viewer) Berechtigungen und diese Rollen anschließend Benutzern zugewiesen werden.

• Funktionsweise: Das System überprüft die dem Benutzer zugewiesenen Rollen und aggregiert ihre Berechtigungen, um zu bestimmen, ob die angeforderte Aktion zulässig ist.
• Verwendung: Wenn die Benutzerberechtigungen eindeutig zu den statischen Jobfunktionen oder Gruppen passen (z. B. in einer typischen Unternehmens- oder Verwaltungsanwendung).
• Einschränkung: RBAC eignet sich weniger für dynamische oder kontextabhängige Richtlinien, die sich auf bestimmte Geräte, Zeiten oder Orte beziehen, da Rollen meist statisch sind.

IAM-Unternehmenssysteme und große Cloud-Umgebungen implementieren RBAC über ihre Frameworks.

Attributbasierte Zugriffskontrolle (Attribute-Based Access Control, ABAC)

ABAC verwendet dynamische Richtlinien, die Attribute des Benutzers, der Ressourcen und der Umgebung evaluieren, um eine Zugriffsentscheidung zu treffen.

• Funktionsweise: Der Zugriff wird über Richtlinienausdrücke bestimmt, die in Echtzeit evaluiert werden (z. B. user.department == resource.department, oder indem geprüft wird, ob die aktuelle Uhrzeit innerhalb der Geschäftszeiten liegt).
• Verwendung: Wenn Autorisierungsentscheidungen sehr komplex sind oder stark vom Kontext oder von dynamischen Faktoren abhängen (z. B. Zugriff nur von IP-Adressen eines bestimmten Bereichs im Unternehmen, Dokumentenzugriff nur während der Geschäftszeiten oder bestimmte Sicherheitsfreigaben als Voraussetzung für den Zugriff auf sensible Ressourcen).
• Nachteil: Die Komplexität wird erhöht. Richtlinien müssen sorgfältig entworfen und gründlich getestet werden, um Konflikte oder unbeabsichtigte Zugriffe über verschiedene Attributkombinationen hinweg zu vermeiden.

Standardbasierte Richtlinien-Engines (z. B. Open Policy Agent oder XACML) setzen die ABAC-Richtlinien durch, um Konsistenz und Überprüfbarkeit zu gewährleisten.

Beziehungsbasierte Zugriffskontrolle (Relationship-Based Access Control, ReBAC) und feingranulare Autorisierung (Fine-Grained Authorization, FGA)

Bei ReBAC basiert die Autorisierung auf den Beziehungen und Eigentumsverhältnissen zwischen Benutzern und bestimmten Ressourcen.

• Funktionsweise: Das System sucht nach expliziten Beziehungen (z. B. „Besitzer von“, „Freigegeben für“, „Mitglied der Gruppe“), um den Zugriff zuzulassen oder zu verweigern. Aktuelle Implementierungen nutzen graphenbasierte Beziehungsmodelle, um komplexe Berechtigungsketten zu analysieren.
• Verwendung: In kollaborativen Systemen wie Social-Media- oder Dokumentfreigabe-Plattformen (z. B. „Beitrag kann nur vom Besitzer gelöscht werden“, „Benutzer in gemeinsam genutzten Arbeitsbereichen können alle Dokumente anzeigen“).

ReBAC- und FGA-Systeme nutzen eine beziehungsorientierte Infrastruktur und graphenbasierte Autorisierungsmuster, um diese Beziehungen im großen Umfang zu modellieren und abzufragen. Mehrere Open-Source-Implementierungen (wie OpenFGA und SpiceDB) machen diese Technologie für alle Entwickler zugänglich.

Die feingranulare Autorisierung (FGA) erweitert die ReBAC-Prinzipien, um Autorisierungsentscheidungen auf der Grundlage komplexer Beziehungsgraphen in großem Umfang zu ermöglichen. FGA-Systeme können Fragen wie „Kann Benutzer X das Dokument Y bearbeiten?“ beantworten, indem sie Beziehungen über Gruppen, Organisationen und verschachtelte Berechtigungen analysieren. Dieses Modell ermöglicht die Autorisierung auf Plattformen für die kollaborative Dokumentbearbeitung und auf sozialen Plattformen, auf denen der Zugriff über Ordnerhierarchien, Gruppenmitgliedschaften und Freigabebeziehungen vererbt werden kann.

API-gesteuerte Anwendungen setzen die Autorisierung über Access Token durch, die gemäß dem OAuth 2.0-Autorisierungsablauf ausgestellt werden.

1. Autorisierungszuordnung: Nach erfolgreicher Authentifizierung ermittelt der Autorisierungsserver die dem Benutzer gewährten Berechtigungen auf Basis des gewählten Authentifizierungsmodells und aller anwendbaren dynamischen Richtlinien (z. B. RBAC, ABAC).
2. Token-Ausstellung: Der Server stellt ein Access Token aus, üblicherweise ein JSON Web Token (JWT), das Informationen über das Subjekt und dessen autorisierte Berechtigungsbereiche (Scopes) enthält. Alternativ stellt er ein undurchsichtiges Token aus, das über den Introspektions-Endpoint des Autorisierungsservers validiert werden muss. Der Authentifizierungsablauf legt fest, wie Token erworben werden und welche Informationen sie enthalten.
3. API-Durchsetzung: Wenn eine API eine Anfrage empfängt, validiert sie das JWT und setzt die Autorisierungsregeln basierend auf den im Token enthaltenen Claims durch.

Dieser Token-basierte Ansatz ist neutral. Das Token enthält alles, was die API benötigt: den Autorisierungskontext und eine kryptografische Signatur.

Scopes (Berechtigungsbereiche) definieren die Berechtigungen, die eine Client-Anwendung vom Autorisierungsserver anfordert. Der Autorisierungsserver gewährt nur die Scopes, denen der Benutzer zugestimmt hat, und nimmt diese in das ausgestellte Access Token auf.

• Wenn eine Anwendung ein Access Token anfordert, gibt sie die benötigten Scopes an (z. B. read:documents, write:documents).
• Der Autorisierungsserver vergleicht die angeforderten Scopes mit den tatsächlichen Berechtigungen des Benutzers und lässt nur zu, was der Benutzer autorisieren kann.
• Das ausgestellte Access Token enthält die genehmigten Scopes. Die API prüft, ob das Token die erforderlichen Scopes für die angeforderte Operation enthält. Wenn der benötigte Scope im Token fehlt, verweigert die API den Zugriff.

Rollen definieren typischerweise breite Zugriffssätze, während Scopes feingranulare Berechtigungen auf Aktionsebene darstellen. Die Kombination aus Rollen und Scopes bietet viel Flexibilität für APIs.

OpenID Connect (OIDC) erweitert OAuth 2.0, indem die Ausstellung von ID-Token zur Verifizierung der Benutzer-Identity und Profil-Claims zusätzlich zu den Autorisierungs-Scopes ermöglicht wird.

Jeder geschützte API-Endpoint muss das eingehende Access Token validieren. Verifizieren Sie die Signatur (gewährleistet Integrität und Authentizität), das Ablaufdatum (exp-Claim), die Zielgruppe (aud-Claim), den Aussteller (iss-Claim) und die erforderlichen Berechtigungen (Scopes oder Rollen) des Tokens. Zusätzliche Validierungen können die Prüfung des Token-Widerrufstatus, die Validierung des nbf-Claims (nicht vor einem bestimmten Zeitpunkt) und die Durchsetzung der Anzahlbegrenzung pro Client umfassen. Für JWTs veröffentlichen Autorisierungsserver öffentliche Schlüssel über den JSON Web Key Set (JWKS)-Endpoint, um die Signatur zu verifizieren.

APIs müssen spezifische HTTP-Statuscodes zurückgeben, um die Art des Fehlers zu kommunizieren.

• 401 Unauthorized: Bedeutet, dass die Authentifizierung fehlgeschlagen ist oder fehlt. Die Anfrage enthält keine gültigen Anmeldedaten (Token fehlt, ist ungültig oder abgelaufen).
  Beispiele: Fehlender Authorization-Header, abgelaufenes JWT, ungültige Signatur.
• 403 Forbidden: Bedeutet, dass die Autorisierung fehlgeschlagen ist. Die Identität des Benutzers ist bekannt (authentifiziert), aber seine Berechtigungen verhindern den Zugriff auf die angeforderten Ressourcen oder Aktionen.
  Beispiele: Token ist gültig, aber dem Benutzer fehlt die Rolle admin für DELETE /users/:id. Damit reicht der Scope für die angeforderte Operation nicht aus.

Welches Sicherheitsrisiko besteht bei inkonsistenten Autorisierungsprüfungen?

Wenn die Autorisierungslogik über den gesamten Code verteilt ist, können einige Pfade die erforderlichen Prüfungen eventuell nicht durchführen. Dadurch entstehen Sicherheitslücken, die Angreifer ausnutzen können. Best Practice ist daher die zentralisierte Durchsetzung der Autorisierung durch Middleware oder eine Richtlinien-Engine. Neuere Ansätze umfassen Policy-as-Code, das Sprachen wie Rego (Open Policy Agent) nutzt, um die Autorisierungslogik vom Anwendungscode zu trennen und damit zentralisierte Tests und Audits zu ermöglichen.

Was besagt das Least Privilege-Prinzip?

Dieses Prinzip sieht vor, dass Benutzern oder Diensten ausschließlich die Rollen und Berechtigungen zugewiesen werden, die sie unbedingt für ihre jeweilige Aufgabe benötigen. Damit werden potenzielle Schäden durch kompromittierte Identitäten minimiert. In der Praxis bedeutet dies, dass Berechtigungen regelmäßig überprüft, Zugriffsrechte zeitlich begrenzt implementiert und nicht verwendete Rollen oder Bereiche entfernt werden müssen.

Wann sollte ich die Step-up-Authentifizierung verwenden?

Die Step-up-Authentifizierung gewährleistet ein ausgewogenes Verhältnis von Sicherheit und Benutzerfreundlichkeit. Sie fragt zusätzliche Faktoren (z. B. einem biometrischen Scan) von einem bereits authentifizierten Benutzer ab, sobald er risikoreiche Operationen wie Überweisungen oder Änderungen an den Gehaltsabrechnungsdaten vornehmen will. Dieses Verfahren wird auch als adaptive oder kontextabhängige Authentifizierung bezeichnet.

Was ist eine häufige Autorisierungsschwachstelle?

Eine häufige Sicherheitslücke ist Broken Object-Level Autorization (BOLA), auch bekannt als Insecure Direct Object Reference (IDOR). Sie entsteht, wenn eine API die allgemeine Berechtigung prüft (z. B. „Kann ein Dokument lesen“), aber nicht verifiziert, ob der Benutzer Zugriff auf die angeforderte spezifische Ressourcenkennung hat (z. B. „Dokument-ID 12345“). Diese Sicherheitslücke ist in den OWASP API Security Top 10 unter API1:2023 gelistet. Überprüfen Sie daher immer sowohl die Aktionsberechtigung als auch den Zugriff auf Ressourcenebene.

Was ist der Unterschied zwischen Autorisierung und Zugriffskontrolle?

Autorisierung ist ein Bestandteil der Zugriffskontrolle. Zugriffskontrolle ist die umfassendere Sicherheitsdisziplin. Sie umfasst die Authentifizierung (Identitätsprüfung), Autorisierung (Berechtigungserteilung) und Durchsetzung (Anwendung der Richtlinien). Die Autorisierung bezieht sich explizit auf die Entscheidungen und Durchsetzung im Zusammenhang mit den möglichen Aktivitäten einer authentifizierten Identität.

Wie funktioniert die Autorisierung in Microservice-Architekturen?

Verteilte Systeme setzen die Autorisierung auf mehreren Ebenen durch: API-Gateway (grobkörnig), Service Mesh (Netzwerkebene) oder einzelne Dienste (feinkörnig). Die Token-basierte Autorisierung mit JWTs ermöglicht eine dienstübergreifende neutrale Verifizierung. Die Wahrung der Konsistenz ist jedoch nicht unproblematisch: Richtlinienaktualisierungen müssen alle Dienste erreichen und beziehungsbasierte Entscheidungen erfordern eine zentrale Richtlinien-Engine oder verteiltes Caching.

Die Autorisierung ist ein Bestandteil einer umfassenden Strategie für das Identity and Access Management (IAM). Mit modernen Autorisierungsframeworks wie OAuth 2.0 und OpenID Connect sowie feingranularen Modellen wie ABAC, ReBAC und der feingranularen Autorisierung (FGA) können Entwickler sicherere und skalierbarere Anwendungen entsprechend den Zero-Trust-Prinzipien erstellen. Weitere Informationen zur Authentifizierung, zu Modellen für die Zugriffskontrolle und zu Best Practices für die Sicherheit erhalten Sie in der Auth0-Serie „Einführung in IAM“.

Mehr erfahren

Diese Materialien dienen nur zur allgemeinen Information. Es liegt in Ihrer Verantwortung, sich mit Blick auf Sicherheit, Datenschutz, Compliance oder geschäftliche Angelegenheiten beraten zu lassen und sich nicht ausschließlich auf die hierin bereitgestellten Informationen zu verlassen.