In der heutigen IT-Landschaft ist „Identity is the new perimeter“ kein blosser Slogan mehr, sondern die Grundlage einer modernen Zero Trust Sicherheitsstrategie. Lesen Sie dazu auch unser Blogpost zum Thema Zero Trust & IAM. Doch während wir die Authentifizierung (SSO, MFA, Passkeys) weitgehend im Griff haben und sich gängige Standards etabliert haben (SAML / OAuth / OpenID Connect), gleicht die darauf folgende Autorisierung oft einem Flickenteppich aus proprietärer Logik und veralteten Modellen.
Authentifizierung (auf engl. Authentication) und Autorisierung (auf engl. Authorization) einfach erklärt
Du besuchst deinen Nachbarn und klopfst an seine Tür.
Er schaut durch den Türspion und erkennt dich (Authentifizierung).
Er öffnet die Tür und bittet dich herein.
Du betrittst die Wohnung und unterhältst dich mit ihm. Langsam fühlst du dich wohl, also setzt du dich auf das Sofa. Er hat nichts dagegen (du bist dazu autorisiert).
Du benutzt sogar seine Toilette (immer noch autorisiert).
Nach einer Weile bekommst du Hunger und versuchst, seinen Kühlschrank zu öffnen, um nachzuschauen was es Leckeres gibt. Er hält dich davon ab und sagt, dass du das nicht darfst (nicht autorisiert).
In diesem ersten Teil unserer Blog Serie gemeinsam mit unserem Partner cidaas analysieren wir, warum herkömmliche IAM-Architekturen ein fundamentales Autorisierungsproblem haben und warum AuthZEN der notwendige Standard ist, um eine echte Zero Trust Architecture (ZTA) nach globalen Standards wie NIST SP 800-207 umzusetzen.
Das Grundproblem: Wenn die Autorisierung zum Flaschenhals wird
Klassische Ansätze wie Role-Based Access Control (RBAC) stossen in dynamischen Cloud-Umgebungen an ihre Grenzen.
Das Problem: Die Autorisierungslogik ist heute oft ein architektonisches Hindernis. In Legacy-Applikationen ist sie meist untrennbar im Quellcode vergraben, während in heterogenen Systemlandschaften versucht wird, moderne Anforderungen in starre, zentralisierte Verzeichnisstrukturen wie das Active Directory (AD) zu pressen.
Selbst bei Lift-and-Shift-Migrationen in die Cloud werden oft monolithische Sicherheitskonzepte unverändert übernommen. Das Ergebnis ist ein starres Zugriffskonzept, welches weder die Dynamik von Microservices noch die granularen Anforderungen moderner API-Ökosysteme und hybrider Cloud-Modelle abbilden kann.
Das führt unweigerlich zu Herausforderungen wie z.B.:
Rollenexplosion: Analysten wie Gartner beobachten seit Jahren, dass Unternehmen unter der Last tausender technischer Rollen zusammenbrechen, die manuell kaum noch zu auditieren sind.
Mangelnde Kontext-Intelligenz: RBAC kennt nur den Zustand „Nutzer hat Rolle X“. Ob der Zugriff von einem unsicheren öffentlichen WLAN oder zu einer ungewöhnlichen Uhrzeit erfolgt, bleibt unberücksichtigt.
Der notwendige Schritt zur Lösung dieser Herausforderungen ist der Übergang zu dynamischer Zugriffskontrolle mittels Attribute-Based Access Control (ABAC) oder Policy-Baced Access Control (PBAC). Hier werden Zugriffsentscheidungen in Echtzeit basierend auf Attributen (Subjekt, Ressource, Aktion, Umgebung, etc.) oder kontextabhängiger Richtlinien (Geschäftsregeln, Identität, Benutzerattribute, Rollen, Unternehmensrichtlinien oder externe Faktoren) getroffen.
Unser Partner cidaas hat zu diesem Thema bereits ein sehr aufschlussreichen Blog Artikel erfasst.
Die Architekturwende: Warum Zero Trust die Entkopplung der Autorisierung erzwingt
In einer klassischen Sicherheitsarchitektur galt die Devise: „Vertraue dem internen Netzwerk“. Einmal authentifiziert, bewegte sich ein Nutzer oft frei innerhalb seiner zugewiesenen Rollen.
Eine moderne Zero Trust Architecture (ZTA), wie sie im NIST SP 800-207 definiert ist, bricht radikal mit diesem Konzept. Das Kernprinzip lautet: Keinem Subjekt und keinem Asset wird implizit vertraut. Jede einzelne Anfrage muss dynamisch und kontextbezogen autorisiert werden.
Um dieses Niveau an Sicherheit zu erreichen, ist eine fundamentale Entkopplung der Autorisierungslogik von der eigentlichen Applikation unumgänglich. Dies erfordert drei wesentliche architektonische Transformationen:
A. Externalisierung: Trennung von Policy und Applikationscode
In herkömmlichen Systemen ist die Logik („Darf Nutzer A die Ressource B bearbeiten?“) oft als Statement hart im Code der Anwendung vergraben. Dies schafft massive Probleme:
Mangelnde Transparenz: Weder die IT-Sicherheit noch Auditoren können sehen, welche Regeln tatsächlich im Code aktiv sind.
Agilitätsbremse: Jede Änderung einer Geschäftsregel (z. B. neue Compliance-Vorgaben) erfordert eine Code-Änderung, Tests und ein neues Deployment der gesamten Applikation.
Inkonsistenz: In einer Microservices-Landschaft führt dies dazu, dass Autorisierungsregeln zwischen verschiedenen Diensten divergieren.
Die Lösung: Die Verlagerung der Entscheidungslogik in eine externe Schicht. Die Applikation wird „dumm“ in Bezug auf die Regeln; sie stellt lediglich die Zugriffsanfrage und führt die erhaltene Entscheidung aus.
B. Einführung des PDP-PEP-Modells
Die Entkopplung wird durch die strikte Trennung von Entscheidung und Durchsetzung operationalisiert, wie sie im NIST Zero Trust Referenzmodell beschrieben ist:
Policy Decision Point (PDP): Das zentrale „Gehirn“. Hier liegen die Policies (Richtlinien). Der PDP bewertet die Anfrage neutral und trifft eine binäre Entscheidung (Permit/Deny) oder gibt zusätzliche Bedingungen zurück.
Policy Enforcement Point (PEP): Der „Wächter“. Er sitzt direkt im Datenpfad (z. B. als API-Gateway, Sidecar in einem Service Mesh oder als Middleware). Der PEP fängt die Anfrage ab, fragt den PDP und erzwingt das Ergebnis.
C. Kontextbasierte Dynamik statt statischer Privilegien
Ein echtes Zero-Trust-Modell nutzt für die Entscheidung nicht nur die Identität, sondern zieht Echtzeit-Daten aus sogenannten Policy Information Points (PIP) hinzu. Eine Autorisierungsentscheidung wird erst durch den Kontext intelligent:
Identität & Gerät: Ist der Nutzer per MFA verifiziert und ist das Gerät richtlinienkonform?
Umgebung: Erfolgt der Zugriff während der üblichen Arbeitszeiten oder aus einem Risikoland?
Bedrohungslage: Hat das SOC aktuell einen erhöhten Risk-Score für diesen Nutzer gemeldet?
Diese Dynamik lässt sich mit statischen Rollen (RBAC) nicht mehr abbilden. Erst durch die Entkopplung und Standardisierung – genau hier setzt AuthZEN an – können diese komplexen Signale in Millisekunden zu einer sicheren Entscheidung verarbeitet werden.
AuthZEN: Die Standardisierung der Autorisierungsschicht
Bisher scheiterte die breite Einführung von PBAC an der fehlenden Interoperabilität. Jede Policy-Engine (wie OPA oder Cedar) sprach ihre eigene Sprache. Hier setzt die OpenID Foundation mit der AuthZEN Working Group an.
AuthZEN ist kein neues IAM-Feature, sondern definiert eine standardisierte Schnittstelle (API) für Autorisierungsentscheidungen in modernen Zero Trust Architekturen. Das vorrangige Ziel dieser Autorisierungs API ist die Interoperabilität. Die Schnittstelle fungiert als das Bindeglied zwischen dem Policy Decision Point (z.B. IAM-System) und dem Policy Enforcement Point (z.B. App/Service) und ermöglicht deren Kommunikation, ohne dass eine der beiden Komponenten die internen Details der anderen kennen muss.
Ein vereinfachter Ablauf einer Autorisierung mit AuthZEN sieht wie folgt aus.
Anfrage: Ihre Anwendung (PEP) erstellt einen JSON-Payload und übermittelt das Subjekt (Wer), die Aktion (Vorgang), die Ressource (Ziel) und den Kontext (Umgebungsdaten).
{ "subject": { "id": "user-99", "attributes": { "risk_score": "low" } }, "action": { "name": "delete_record" }, "resource": { "type": "financial_report", "id": "2026-q1" }, "context": { "mfa_age": 300 }}
Auswertung: Die Anwendung sendet diesen Payload an den PDP. Der PDP bewertet die Anfrage anhand seiner konfigurierten Richtlinien (z. B. OpenFGA, OPA usw.).
Entscheidung: Der PDP gibt eine JSON-Antwort zurück, die eine boolesche Entscheidung (zulassen oder verweigern) und optionale Hinweise (Kontext bezüglich der Verweigerung) enthält.
{ "decision": "allow"}
Durch die Standardisierung dieser Kommunikation über die AuthZEN Authorization API 1.0 wird Autorisierung endlich herstellerübergreifend austauschbar und zentral steuerbar.
Fazit: AuthZEN ist ein strategisches Investment
Wir haben eingangs festgestellt: „Identity is the new perimeter“. Doch ein moderner Schutzwall ist nur so effektiv wie seine lückenlose Durchsetzung. AuthZEN ist der entscheidende Baustein, um die Autorisierung aus den Applikations-Silos zu befreien und sie in eine zentral steuerbare, auditierbare und Zero-Trust-fähige Infrastrukturschicht zu transformieren. Es ist der notwendige Architekturbaustein, um IAM endlich "fertigzubauen" und eine echte Zero-Trust-Architektur als zukunftsfähigen Sicherheitsansatz zu realisieren.
AuthZEN ist jedoch mehr als “nur” eine technische Schnittstellenspezifikation, sondern vielmehr ein strategisches Werkzeug zur Risikosteuerung und Business-Agilität:
Compliance & Auditierbarkeit: In regulierten Branchen (z. B. durch DORA oder NIS2) müssen Unternehmen nachweisen, warum ein Zugriff erlaubt wurde. Durch die Zentralisierung der Policies am PDP ist dies auf Knopfdruck möglich.
Entwickler-Produktivität: Entwickler müssen keine Autorisierungslogik mehr programmieren (Hardcoding). Sie nutzen standardisierte PEPs, was die Time-to-Market für neue Features verkürzt.
Resilienz: Sicherheitsrichtlinien können global und in Echtzeit geändert werden (z. B. bei einem laufenden Angriff), ohne eine einzige Zeile Code in den Applikationen anzupassen.
Ausblick in den zweiten Teil dieser Blog Serie
Wie sieht das in der Praxis aus? Im zweiten Teil dieser Serie beschreibt unser Partner cidaas konkret, wie AuthZEN in bestehende IAM- und Applikationslandschaften integriert wird und welche Integrationsmuster sich in der Praxis bewährt haben.
