Ein mittelständisches Unternehmen hat den KI-Assistenten bereits eingeführt. Er kann E-Mails zusammenfassen, Bestellungen prüfen und Vorschläge für die Finanzabteilung erstellen. Sobald er jedoch eine Bestellung im ERP anlegen, einen Kundendatensatz im CRM ändern oder eine Rechnung zur Freigabe weiterleiten soll, endet die Automatisierung. Ein Mensch muss übernehmen, weil niemand sauber definiert hat, wer unter welchen Bedingungen welche Aktion ausführen darf.
Genau dort beginnt das Problem eines fehlenden Authorization Frameworks. Authentifizierung allein zeigt, wer angemeldet ist. Sie beantwortet aber nicht, ob diese Person oder ein KI-Agent eine bestimmte Rechnung freigeben, Kundendaten lesen oder einen Produktionsauftrag auslösen darf. In einer heterogenen Systemlandschaft wird Autorisierung deshalb zur betriebsfähigen Steuerungsschicht, die ERP, CRM, Finanzsysteme, Legacy-Anwendungen und KI-Workflows zusammenhält.
Inhaltsverzeichnis
- Warum Autorisierung heute über Erfolg oder Stillstand entscheidet
- Was ein Authorization Framework wirklich leistet
- Architekturmuster im Überblick und wie sie zusammenspielen
- Policy Modelle verstehen und richtig wählen
- Integrationspunkte sicher verbinden von SSO bis OPA
- Das passende Framework bewerten und erfolgreich einführen
- Governance und Best Practices für den sicheren Betrieb
Warum Autorisierung heute über Erfolg oder Stillstand entscheidet
Der Engpass wirkt zunächst unspektakulär. Ein Sachbearbeiter kopiert Informationen aus dem CRM in das ERP, wartet auf eine manuelle Freigabe und prüft anschließend, ob die zuständige Person überhaupt Zugriff auf den Vorgang hatte. Die KI hätte den Ablauf vorbereiten können, doch sie darf den entscheidenden Schritt nicht durchführen. Das Team gewinnt zwar einen Assistenten, aber keinen durchgängigen Prozess.
In vielen Unternehmen liegen die Regeln außerdem verteilt. Das ERP kennt Rollen, das CRM verwaltet eigene Gruppen, ein Fileserver arbeitet mit Ordnerrechten und ein KI-Agent erhält über einen Connector einen anderen Ausschnitt der Daten. Jede Einzelanbindung kann funktionieren. Zusammen entsteht trotzdem eine Landschaft, in der niemand schnell und sicher beantworten kann, warum ein Zugriff erlaubt oder abgelehnt wurde.
Der operative Schmerz
Ein gutes Authorization Framework ersetzt nicht die fachliche Verantwortung. Es macht sie ausführbar. Die Organisation legt fest, welche Rolle eine Aktion durchführen darf, welche Eigenschaften des Vorgangs zählen und welche Nachweise gespeichert werden. Danach setzen die angeschlossenen Systeme diese Entscheidung konsistent um.
Das verändert den Nutzen von KI grundlegend:
- Durchgängige Abläufe: Ein Agent kann einen Vorgang nicht nur analysieren, sondern einen erlaubten nächsten Schritt in einem Zielsystem ausführen.
- Weniger manuelle Übergaben: Mitarbeitende bearbeiten Ausnahmen, statt jede Standardaktion selbst anzustoßen.
- Sichere Automatisierung: Der Agent erhält nur den Zugriff, den der konkrete Prozess rechtfertigt.
- Bessere Nachvollziehbarkeit: Entscheidungen lassen sich mit Identität, Ressource, Aktion und Regel dokumentieren.
Praktische Regel: Automatisieren Sie nicht zuerst die Aktion. Automatisieren Sie zuerst die Entscheidung, unter welchen Bedingungen die Aktion zulässig ist.
Für österreichische Unternehmen kommt eine weitere Ebene hinzu. Österreich ist laut dem österreichischen Digital-Decade-Fahrplan beim digitalen Identitätsnachweis weit fortgeschritten. 100 % der Bürger:innen haben Zugang zu einem sicheren digitalen Identitätsnachweis über ID Austria, der in der gesamten EU anerkannt ist. Damit steht eine Identitätsbasis zur Verfügung. Der nächste Schritt besteht darin, diese Identität mit belastbaren Prozessregeln zu verbinden.
Was ein Authorization Framework wirklich leistet
Stellen Sie sich ein Gebäude vor. Die Authentifizierung ist die Kontrolle am Eingang. Der Ausweis zeigt dem Türsteher, wer Sie sind. Die Autorisierung ist die Hausordnung, die danach entscheidet, welche Räume Sie betreten, welche Tätigkeiten Sie ausführen und ob die Entscheidung für diesen konkreten Besuch gilt.
Ein Authorization Framework beantwortet deshalb mindestens vier Fragen:
- Wer handelt?
- Was soll geschehen?
- Woran soll gehandelt werden?
- Unter welchen Bedingungen ist die Aktion erlaubt?
Authentifizierung ist nicht Autorisierung
Die Unterscheidung ist einfach, wird aber in Projekten oft vermischt. Authentifizierung bestätigt eine Identität. Das kann über ein Login, SSO, eine digitale Identität oder einen anderen Identitätsdienst geschehen. Autorisierung entscheidet anschließend, ob diese Identität eine bestimmte Operation durchführen darf.
Ein angemeldeter Buchhalter darf beispielsweise Rechnungsdaten lesen, muss aber nicht automatisch Lieferantenstammdaten ändern dürfen. Ein KI-Agent kann den Auftrag erhalten, eine Rechnung zu klassifizieren, darf aber nicht ohne weitere Bedingung eine Zahlung freigeben. Die Identität bleibt gleich. Die erlaubte Handlung hängt vom Kontext ab.
Die drei Grundbausteine
Ein verständliches Framework trennt drei Aufgaben:
- Policy: Die Regel beschreibt, welche Kombination aus Identität, Rolle, Ressource, Aktion und Kontext zulässig ist.
- Entscheidung: Eine Policy-Komponente wertet die Anfrage aus und gibt etwa „erlaubt“ oder „abgelehnt“ zurück.
- Durchsetzung: Das Zielsystem oder ein vorgeschalteter Dienst verhindert die Aktion, wenn die Entscheidung negativ ausfällt.
Statische Benutzerrechte reichen dafür nicht aus. Sie bilden oft nur den Zustand eines Kontos ab. Prozesse brauchen dagegen laufende Prüfung: Ist die Person noch zuständig? Gehört der Datensatz zur richtigen Organisationseinheit? Ist der Vorgang freigegeben? Arbeitet der Agent mit einem gültigen Auftrag oder versucht er, eine Regel zu umgehen?
Die österreichische eID-Austria-Architektur nutzt eine eIDAS-Domain mit Schnittstelle zur Frontend-Domain. Ein technischer Überblick der RTR zum eIDAS-Rechtsrahmen beschreibt außerdem ein zentrales Identitätsmanagement mit zentralem Rechte- und Zugriffsmanagement für Service-Provider. Das ist die wichtige Trennung: Identität wird festgestellt, Berechtigung wird separat verwaltet und geprüft.
Architekturmuster im Überblick und wie sie zusammenspielen
Die Blackbox eines Authorization Frameworks wird verständlich, wenn man einen einzelnen Request verfolgt. Eine Person oder ein KI-Agent möchte im ERP eine Rechnung ändern. Der Request enthält eine Identität, eine Aktion, eine Ressource und relevante Kontextinformationen. Danach arbeiten mehrere Komponenten zusammen.
Die vier Funktionen im Request-Flow
Policy Enforcement Point, PEP: Der PEP sitzt dort, wo die Aktion ankommt. Das kann eine API, ein Service, ein Gateway oder ein Connector sein. Er nimmt den Request entgegen, fragt die Entscheidung ab und lässt die Änderung nur bei einer erlaubten Antwort durch.
Policy Decision Point, PDP: Der PDP bewertet die Anfrage. Er liest die geltenden Regeln und liefert eine Entscheidung. Der PDP sollte nicht selbst die fachliche Aktion ausführen. Diese Trennung verhindert, dass jede Anwendung ihre eigene, leicht abweichende Berechtigungslogik entwickelt.
Policy Information Point, PIP: Der PIP liefert die Informationen, die für eine Entscheidung fehlen. Dazu gehören etwa Abteilung, Standort, Eigentümer eines Datensatzes, Status eines Vorgangs oder die Beziehung zwischen einem Nutzer und einem Kundenkonto.
Policy Administration Point, PAP: Im PAP werden Policies erstellt, geprüft, versioniert und veröffentlicht. Fachverantwortliche und technische Teams müssen gemeinsam festlegen, wer Regeln ändern darf und wie eine Änderung freigegeben wird.
Zentral entscheiden, verteilt durchsetzen
Ein zentraler PDP kann Entscheidungen über mehrere Systeme hinweg konsistent treffen. Die Durchsetzung bleibt trotzdem nahe am Zielsystem. Ein ERP-Connector blockiert eine unzulässige Änderung, während ein CRM-Service eine andere Ressource nach derselben Governance-Logik schützt.
Das Muster ist besonders hilfreich, wenn Anwendungen nicht dieselben Rollenmodelle unterstützen. Statt jede proprietäre Berechtigungsfunktion vollständig zu vereinheitlichen, wird eine gemeinsame Entscheidungsschicht eingeführt. Dabei sollte die Integration nicht zum neuen isolierten Spezialfall werden. Prinzipien der Systeminteroperabilität in vernetzten Unternehmenslandschaften helfen, Identitäten, Daten und Entscheidungen sauber über Systemgrenzen hinweg zu verbinden.
Ein typischer Ablauf sieht so aus:
- Der PEP empfängt den Request aus ERP, CRM oder einem Agenten.
- Der Request enthält Principal, Aktion und Zielressource.
- Der PDP fragt beim PIP zusätzliche Attribute oder Beziehungen ab.
- Der PDP wertet die Policy aus.
- Der PEP erlaubt oder verweigert die konkrete Aktion.
- Das Ergebnis wird mit ausreichendem Kontext protokolliert.
Der Vorteil liegt nicht in einer bestimmten Produktwahl. Er liegt in der klaren Verantwortungsverteilung. Authentifizierung liefert die Identität. Policies beschreiben die Regeln. Der PDP entscheidet. Der PEP setzt durch. Der PAP verwaltet Änderungen.
Policy Modelle verstehen und richtig wählen
Die Wahl des Policy-Modells entscheidet darüber, ob ein Framework im Alltag übersichtlich bleibt oder zu einem schwer wartbaren Sonderfall wird. Drei Modelle begegnen Teams besonders häufig: RBAC, ABAC und ReBAC. Sie beantworten dieselbe Grundfrage, verwenden aber unterschiedliche Entscheidungsgrundlagen.
Rollen, Eigenschaften und Beziehungen
RBAC, Role-Based Access Control, ordnet Berechtigungen Rollen zu. Ein ERP-Buchhalter darf bestimmte Finanzaktionen ausführen, eine Vertriebsrolle erhält andere Rechte. Das Modell ist leicht zu erklären und eignet sich für klar abgegrenzte Verantwortlichkeiten. Es wird unübersichtlich, wenn Teams für jede Ausnahme neue Rollen anlegen.
ABAC, Attribute-Based Access Control, bezieht Eigenschaften ein. Der Zugriff auf einen CRM-Datensatz kann von Standort, Organisationseinheit, Datenklassifikation, Prozessstatus oder Arbeitszeit abhängen. ABAC bildet den Kontext präziser ab, verlangt aber verlässliche und aktuelle Attribute.
ReBAC, Relationship-Based Access Control, entscheidet anhand von Beziehungen. Ein Nutzer darf einen Datensatz bearbeiten, weil er als Eigentümer eingetragen ist, einem Kundenkonto zugeordnet wurde oder Teil eines verantwortlichen Projekts ist. Dieses Modell passt gut zu geteilten Objekten und komplexen Organisationsstrukturen.
| Modell | Steuerungslogik | Stärke | Typischer Einsatz |
|---|---|---|---|
| RBAC | Berechtigung über eine Rolle | Einfach verständlich und zentral verwaltbar | ERP-Aktionen nach Funktion |
| ABAC | Entscheidung über Eigenschaften und Kontext | Präzise Regeln für variable Bedingungen | CRM-Zugriff nach Standort oder Datenklasse |
| ReBAC | Entscheidung über Beziehungen zwischen Subjekten und Objekten | Geeignet für Eigentum und geteilte Ressourcen | Dateien, Projekte und Kundenbeziehungen |
Eine vernünftige Auswahl
Beginnen Sie mit dem stabilsten Merkmal. Wenn die Funktion klar entscheidet, starten Sie mit RBAC. Wenn der Kontext ausschlaggebend ist, ergänzen Sie ABAC. Wenn die Frage lautet „In welcher Beziehung steht diese Person zu diesem Objekt?“, ist ReBAC meist die passendere Grundlage.
In der Praxis ist eine Kombination häufig sinnvoll. Eine Finanzrolle kann grundsätzlich Rechnungen lesen. Ein Attribut beschränkt den Zugriff auf eine Organisationseinheit. Eine Beziehung entscheidet zusätzlich, ob die Person für diesen konkreten Vorgang verantwortlich ist. So vermeiden Teams zwei typische Fehler: übergroße Sammelrollen und eine unüberschaubare Zahl einzelner Ausnahmen.
Entscheidungsfrage: Welche Information würde ein Prüfer benötigen, um die Entscheidung für genau diesen Zugriff nachzuvollziehen?
Diese Frage verhindert, dass Policies nur aus Rollenbezeichnungen bestehen. Sie lenkt den Blick auf Ressource, Aktion, Kontext und Nachweis.
Integrationspunkte sicher verbinden von SSO bis OPA
Ein Authorization Framework verbindet Identitätsanbieter, APIs, Fachanwendungen und Automatisierungsplattformen. SSO, OAuth und eine Policy-Engine wie OPA lösen dabei verschiedene Aufgaben. Erst ihr Zusammenspiel bildet eine betriebsfähige Steuerungsschicht über ERP, CRM und KI-Agenten.
SSO ermöglicht die Anmeldung über einen etablierten Identitätsdienst und reduziert separate Logins. Die Anmeldung allein entscheidet jedoch nicht, welche fachliche Aktion erlaubt ist. OAuth regelt den delegierten Zugriff einer Anwendung auf eine Ressource. Ein Agent erhält dadurch begrenzte Berechtigungen, ohne das Passwort eines Menschen zu benötigen. OPA kann als zentrale Policy-Engine die Entscheidung auswerten. Die jeweilige Anwendung oder ein Connector setzt sie durch.
Ein Beispiel mit ERP, CRM und MCP
Ein Agent prüft einen Kundenauftrag. Er liest im CRM den Kundenstatus, holt aus dem ERP offene Positionen und erstellt einen Vorschlag für die Finanzabteilung. Dafür braucht er keine pauschale ERP-Berechtigung, sondern klar beschriebene Aktionen auf bestimmten Ressourcen.
Die Anfrage kann so durch das System laufen:
- SSO und Identität: Der Nutzer meldet sich an. Der Agent erhält einen nachvollziehbaren Auftraggeber und eine technische Identität.
- OAuth und Delegation: Der Agent bekommt nur die Scopes, die dieser Workflow benötigt.
- MCP-Schicht: Ein standardisierter Connector vermittelt zwischen Agent und Zielsystem.
- PIP-Daten: Der PDP bezieht Kundenzuordnung, Prozessstatus oder Datenklassifikation.
- OPA oder anderer PDP: Die Policy-Engine entscheidet über die konkrete Aktion.
- PEP im Connector: Der Connector blockiert nicht erlaubte Änderungen im Zielsystem.
Damit jede Entscheidung nachvollziehbar bleibt, sollte der PEP jeden erlaubten und verweigerten Aufruf protokollieren. Eine Anleitung bietet das Audit-Log-Management.
BMD, DATEV oder Navision müssen kein identisches Rollenmodell verwenden. Eine MCP-Schicht kann ihre unterschiedlichen Schnittstellen hinter einem kontrollierten Zugriffsmuster verbinden. Der Connector darf Berechtigungen nicht erraten, sondern muss den vollständigen Request an die Policy-Entscheidung übergeben.
Österreich und Europa als Architekturkontext
Österreichs ID Austria unterstützt sichere Authentifizierung und elektronische Signatur für Online-Behördendienste. Die App e-Ausweise speichert und zeigt digitale Nachweise wie den Führerschein vor. Der österreichische Digital-Identity-Fahrplan beschreibt diese Identitätsbasis.
Die EU-Verordnung 2024/1183 trat am 20. Mai 2024 in Kraft und verpflichtet Mitgliedstaaten, bis Ende 2026 EU-Digital-Identity-Wallets bereitzustellen. Für Österreich ist relevant, dass die nationale eIDAS-notifizierte Infrastruktur mit dem Vertrauensniveau „High“ bewertet wurde und der Peer-Review-Bericht der Europäischen Kommission ihre Konformität mit der eIDAS-Verordnung 910/2014 bestätigt.
Identität, delegierter Zugriff und Prozessautorisierung sollten deshalb getrennt, aber zusammenwirkend entworfen werden. Ein angemeldeter Agent braucht weiterhin klare Grenzen für seine konkreten Handlungen.
Das passende Framework bewerten und erfolgreich einführen
Die Auswahl sollte nicht mit einer Tool-Demonstration beginnen. Starten Sie mit einem realen Prozess, bei dem eine Aktion heute manuell stoppt. Eine Rechnung, eine Kundendatenänderung oder ein Produktionsauftrag eignet sich besser als ein abstrakter Architektur-Workshop, weil sich Ressourcen, Rollen, Ausnahmen und Nachweise daran konkret beschreiben lassen.
Bewertungskriterien für die Entscheidung
Prüfen Sie ein Framework anhand der Arbeit, die es im Betrieb leisten muss:
- Skalierbarkeit: Kann die Entscheidungsschicht weitere Anwendungen, Mandanten und Agenten aufnehmen, ohne Policies zu duplizieren?
- Auditierbarkeit: Speichert sie die Entscheidungsgrundlage, nicht nur das Ergebnis?
- Latenz: Bleibt die Prüfung für interaktive APIs und schnelle Agenten-Workflows praktikabel?
- Entwicklerfreundlichkeit: Können Teams Requests, Policies und Tests verständlich erstellen?
- Betrieb: Sind Versionierung, Rollback, Monitoring und Ausfallverhalten klar geregelt?
- Legacy-Tauglichkeit: Lassen sich BMD, DATEV, Navision und andere Systeme über Adapter schützen, auch wenn sie keine moderne Policy-Schnittstelle besitzen?
Besonders wichtig ist das Verhalten bei fehlenden Informationen. Ein System sollte nicht stillschweigend erlauben, wenn ein Attribut nicht verfügbar ist. Die Policy muss definieren, ob der Request abgelehnt, zur manuellen Prüfung weitergeleitet oder mit eingeschränktem Zugriff ausgeführt wird.
Schlank vom Pilot zum Rollout
- Prozess abgrenzen: Wählen Sie einen Prozess mit klarer Ressource und einer überschaubaren Zahl erlaubter Aktionen.
- Entscheidungen sammeln: Dokumentieren Sie, welche Identität, Rolle, Attribute und Beziehungen heute tatsächlich verwendet werden.
- PEP integrieren: Setzen Sie die Durchsetzung an einer API oder einem Connector um, nicht gleichzeitig in allen Systemen.
- Policies testen: Prüfen Sie erlaubte, verbotene und unvollständige Requests. Testen Sie auch Rollenwechsel und Entzug.
- Nachweise definieren: Legen Sie fest, welche Daten ein Audit oder eine fachliche Rekonstruktion benötigt.
- Ausnahmen kontrollieren: Jede manuelle Freigabe braucht einen Grund, eine verantwortliche Person und einen nachvollziehbaren Abschluss.
Für Finanzdienstleistungen ist die Governance besonders formalisiert. Die FMA autorisiert Finanzdienstleister, während Banklizenzen für CRR-Kreditinstitute unter der direkten Verantwortung der EZB im SSM liegen. Der Österreich-Praxisführer zur Finanzdienstleistungsregulierung nennt Gebühren von EUR 10.000 für eine Banklizenz und EUR 8.000 für eine Lizenz als Investment Firm oder Payment Institution. Das zeigt, wie wichtig klare Zuständigkeiten, Dokumentation und Lizenzabgrenzung auch für technische Autorisierungsprozesse sind.
Governance und Best Practices für den sicheren Betrieb
Ein Authorization Framework ist kein Projekt, das nach dem Go-live abgeschlossen ist. Rollen ändern sich, Teams werden neu organisiert, Daten wandern in Cloud-Dienste und KI-Agenten erhalten neue Werkzeuge. Die Regeln müssen deshalb wie produktiver Code behandelt werden, mit Versionierung, Tests, Freigaben und kontrollierter Veröffentlichung.
Die Betriebsroutine
Policy-Änderungen gehören in einen geregelten Lebenszyklus. Jede Änderung braucht einen fachlichen Zweck, eine verantwortliche Person und einen nachvollziehbaren Vergleich zur vorherigen Version. Tests sollten sowohl erlaubte als auch verweigerte Entscheidungen abdecken.
Reviews müssen an Prozessen ausgerichtet sein. Prüfen Sie nicht nur, ob ein Benutzer noch aktiv ist. Prüfen Sie, ob die Berechtigung noch zur Aufgabe, zur Ressource und zur Zweckbindung passt. Der österreichische Rechtsrahmen macht gerade im Gesundheits- und Datenschutzkontext deutlich, dass Berechtigungen aufgabenbezogen vergeben und dokumentiert werden müssen. Die österreichische Rechtsgrundlage zur Verarbeitung und Zugriffskontrolle unterstreicht damit die Lücke zwischen formaler Regel und laufender betrieblicher Prüfung.
Nachweise müssen exportierbar sein. Protokollieren Sie mindestens handelnde Identität, Aktion, Ressource, Entscheidung, Policy-Version und relevante Kontextdaten. Eine Governance-Struktur für Security und Autorisierung sollte außerdem festlegen, wer Logs prüft, wer Entzüge auslöst und wie Ausnahmen ablaufen.
Neue Nachweispflichten
Die eIDAS-2.0-Darstellung für Österreich beschreibt Wallets als zertifizierte und regelmäßig überwachte Vertrauenskomponenten. Die Zertifizierung gilt für 5 Jahre, eine Schwachstellenbeurteilung ist alle 2 Jahre vorgesehen, wie die österreichische Einordnung von eIDAS 2.0 erläutert.
Auch das NISG 2026 rückt Identity- und Access-Management mit Multi-Faktor-Authentifizierung in den Mittelpunkt. Wesentliche Einrichtungen müssen die Umsetzung ihrer Risikomanagementmaßnahmen auf Anfrage innerhalb von zwei Monaten belegen, wichtige Einrichtungen innerhalb von zwei Jahren; Sicherheitsvorfälle sind mit Frühwarnungen binnen 24 Stunden und vollständigen Meldungen binnen 72 Stunden verbunden, wie die Übersicht zu Security-Trust-Frameworks ausführt.
Für KI-Workflows kommt Datenschutz hinzu. Die DSB veröffentlichte am 25. April 2024 FAQs zu KI und Datenschutz. Autorisierung muss deshalb auch Zweckbindung, personenbezogene Daten und den Zugriff von Agenten auf Werkzeuge und Quellen abbilden. Wer diese Nachweise von Anfang an mitführt, macht Automatisierung nicht nur sicherer, sondern im Audit überhaupt erst erklärbar.
Specialty Tokens verbindet Senior Engineering mit konkreter Umsetzung von Autorisierung, sicheren MCP-Integrationen und KI-Agenten für ERP-, CRM-, Finanz- und Legacy-Systeme. Wenn Sie herausfinden möchten, wie ein kontrollierter Pilot in Ihrer Systemlandschaft aussehen kann, besuchen Sie Specialty Tokens und starten Sie den Austausch über Ihren wichtigsten blockierten Prozess.