Ein Einkäufer in einem österreichischen Industrieunternehmen braucht dringend Zugriff auf Lieferantenstammdaten einer übernommenen Tochterfirma. Seine Rolle im ERP heißt „Einkäufer“, doch sie gilt nur für die Konzernmutter. Der Antrag landet beim IAM-Team, die Fachabteilung wartet, und jemand überlegt, eine Sonderrolle zu bauen, die nach dem Projekt wieder entfernt werden soll.
Genau an solchen Alltagssituationen zeigt sich, warum Attribute Based Access Control, kurz ABAC, für den österreichischen Mittelstand interessant wird. Es geht nicht darum, Rollen vollständig abzuschaffen. Es geht darum, Zugriffsentscheidungen mit aktuellen Informationen über Person, Ressource, Handlung und Kontext zu treffen, statt jede Ausnahme in eine neue statische Rolle zu pressen. Für ERP-, CRM- und Legacy-Landschaften kann dieser Ansatz Sicherheit erhöhen und gleichzeitig manuelle Freigabeschleifen verkürzen. Er funktioniert aber nur, wenn Unternehmen die zugrunde liegenden Attribute ebenso ernst nehmen wie die Policies.
Inhaltsverzeichnis
- Warum klassische Rollen im Mittelstand an Grenzen stoßen
- Attribute Based Access Control im Kern erklärt
- ABAC im Vergleich zu RBAC
- Architektur und Datenmodell eines ABAC-Systems
- Policy-Explosion und Attribut-Pflege als Praxisrisiken
- Praxisbeispiele für ERP- und CRM-Integration
- ABAC mit MCP und internen Agenten verbinden
- Governance, Audit und 90-Tage-Roadmap
Warum klassische Rollen im Mittelstand an Grenzen stoßen
Im beschriebenen ERP-Fall ist die Rolle „Einkäufer“ nicht falsch. Sie ist nur zu grob für die konkrete Situation. Sie sagt, welche Aufgaben eine Person grundsätzlich erledigen darf, aber nicht, für welche Gesellschaft, welches Werk, welches Projekt oder welchen Zeitraum der Zugriff gelten soll.
In einer wachsenden Organisation entstehen dadurch mehrere Probleme:
- Rollen werden immer zahlreicher: Für Tochtergesellschaften, Werke, Projekte und Vertretungen entstehen Varianten derselben Grundrolle.
- Verantwortung bleibt in Matrixstrukturen unklar: Eine Person kann fachlich dem Einkauf, organisatorisch aber einer anderen Gesellschaft oder einem gemeinsamen Projektteam zugeordnet sein.
- Ausnahmen werden zu Workarounds: Kurzfristiger Zugriff führt zu manuellen Änderungen, temporären Rollen oder direkten Berechtigungen.
- Trennungen werden unscharf: Im CRM kann ein Vertriebsmitarbeiter Kundendaten sehen, die zwar regional passen, aber für Finance oder Compliance nicht freigegeben sind.
Gerade in gemischten Landschaften aus Legacy-SAP, Dynamics 365, proAlpha, Verzeichnisdiensten und selbst entwickelten Anwendungen wächst die Zahl der Sonderfälle schneller als das Rollenmodell sauber gepflegt werden kann. Eine Übernahme verändert Organisationseinheiten, Eigentümer und Datenflüsse. Die Rollen im alten System bleiben jedoch oft unverändert, bis jemand einen Fehler bemerkt.
Praktische Regel: Eine Rolle beschreibt eine dauerhafte Funktion. Eine Policy sollte zusätzlich prüfen, ob die konkrete Person, Ressource und Situation zusammenpassen.
ABAC setzt genau an dieser Lücke an. Der Einkäufer könnte Zugriff erhalten, wenn seine Abteilung, die Gesellschaft der Stammdaten, das Projekt und eine zeitliche Befristung zusammenpassen. Die Entscheidung richtet sich dann nicht nur nach dem Etikett „Einkäufer“, sondern nach den Informationen, die für diesen Zugriff tatsächlich relevant sind.
Attribute Based Access Control im Kern erklärt
ABAC lässt sich am einfachsten mit einem Werksgebäude erklären. Der Zutritt zu einer Tür hängt nicht allein davon ab, ob jemand „Mitarbeiter“ ist. Der Sicherheitsdienst prüft mehrere Merkmale und entscheidet daraus, ob die gewünschte Handlung in diesem Moment erlaubt ist.
Die vier Bausteine der Entscheidung
Subjektattribute beschreiben die anfragende Person oder einen technischen Akteur. Dazu gehören etwa Abteilung, Sicherheitsstufe, Standort, Vorgesetzter oder eine organisatorische Zuordnung. Im Werksbeispiel stehen diese Informationen auf dem Mitarbeiterausweis.
Ressourcenattribute beschreiben das Ziel des Zugriffs. Die Ressource ist nicht nur „das Gebäude“, sondern vielleicht ein Labor, ein Lagerbereich oder ein Serverraum. Relevante Merkmale können Bereich, Stockwerk, Zugangsklasse oder eine Tagesfreigabe sein.
Aktionsattribute nennen die gewünschte Handlung. Zutritt, Lesen, Schreiben, Freigeben und Löschen sind unterschiedliche Aktionen. Eine Person kann also berechtigt sein, einen Datensatz zu lesen, aber nicht, ihn zu ändern oder zu exportieren.
Umgebungsattribute liefern den situativen Kontext. Dazu gehören Uhrzeit, Wochentag, Feiertag, Begleitstatus, Gerätezustand oder Standort. Ein Zugriff kann während einer genehmigten Schicht erlaubt und ausserhalb dieses Zeitfensters abgelehnt werden.
Eine ABAC-Policy verbindet diese Werte. Sie könnte sinngemäss lauten: Eine Person mit ausreichender Sicherheitsstufe darf einen bestimmten Werksbereich betreten, wenn die Tagesfreigabe aktiv ist, die Uhrzeit im erlaubten Fenster liegt und eine vorgeschriebene Begleitung vorhanden ist. Die Regeln sind nicht für jede Person und jede Tür einzeln fest verdrahtet. Sie werden bei der Anfrage aus den aktuellen Attributwerten ausgewertet.
Die technische Einordnung der TU Wien und die NIST-nahe Definition beschreiben ABAC entsprechend als flexible, dynamische Zugriffskontrolle auf Basis von Subjekt, Ressource, Aktion und Umweltbedingungen. Das erklärt auch die Stärke des Modells: Die Policy bleibt vergleichsweise stabil, während sich Attribute wie Abteilung, Standort oder Gerätezustand ändern können.
ABAC im Vergleich zu RBAC
RBAC und ABAC lösen nicht exakt dasselbe Problem auf derselben Ebene. RBAC ordnet Berechtigungen Rollen zu, während ABAC Bedingungen über mehrere Attribute auswertet. In der Praxis nutzen viele Unternehmen zunächst Rollen aus dem bestehenden Identity Provider und ergänzen sie später um attributbasierte Bedingungen.
| Kriterium | RBAC | ABAC |
|---|---|---|
| Granularität | Einfach verständliche, meist gröbere Berechtigungen | Feinere Entscheidungen für Personen, Ressourcen und Situationen |
| Ausdrucksfähigkeit | Stark bei stabilen Funktionen und klaren Organisationseinheiten | Stark bei Beziehungen, Zuständen, Befristungen und Kontext |
| Betriebsaufwand | Niedrige Einstiegshürde, aber mögliche Rollenvielfalt bei Ausnahmen | Höherer Modellierungsaufwand, dafür weniger Bedarf an Sonderrollen |
| Performance | Häufig direkt aus Rollenmitgliedschaften ableitbar | Benötigt Policy-Auswertung und aktuelle Attributquellen |
| Audit-Tauglichkeit | Rollen sind leicht zu inventarisieren | Bedingungen können den konkreten Entscheidungsgrund besser sichtbar machen |
| Zero-Trust-Eignung | Grundsätzlich nutzbar, aber kontextabhängig zu erweitern | Passt gut zu laufender Prüfung von Identität, Ressource und Umgebung |
| Externe Identitäten | Funktioniert gut bei stabilen Partnerrollen | Geeignet, wenn Organisation, Vertrag, Region oder Gerätezustand relevant sind |
RBAC punktet dort, wo die Organisation überschaubar und die Berechtigungslogik dauerhaft ist. Ein Lagerteam erhält Zugriff auf definierte Funktionen, ein Finance-Team auf bestimmte Buchungsprozesse. Die Regeln sind leicht zu erklären und oft bereits in ERP-Systemen eingebaut.
Schwierig wird RBAC bei Fragen wie: Darf diese Person nur für das übernommene Unternehmen, nur während des Projekts oder nur bis zu einem bestimmten Bestellwert handeln? Wer solche Bedingungen mit Rollen abbildet, braucht immer neue Kombinationen. Auch die Trennung von Aufgaben und Verantwortlichkeiten bleibt eine fachliche Anforderung, die weder RBAC noch ABAC automatisch korrekt löst.
ABAC verlangt im Gegenzug gereifte Attributquellen und klare Policy-Governance. Ein veraltetes Abteilungsfeld produziert eine veraltete Entscheidung. Die faire Schlussfolgerung lautet deshalb: RBAC ist ein solides Fundament, ABAC ist eine Erweiterung für dynamische und feinere Regeln. Ein hybrides Modell passt häufig besser als ein vollständiger Austausch. Rollen liefern die Grundberechtigung, Attribute begrenzen sie auf den passenden Kontext.
Architektur und Datenmodell eines ABAC-Systems
Ein ABAC-System besteht nicht aus einer einzelnen Berechtigungsmaske. Es verteilt Verantwortlichkeiten auf mehrere Bausteine, damit das Zielsystem nicht jede Policy selbst implementieren muss.
Die funktionalen Punkte
Der Policy Enforcement Point, PEP, sitzt am Zielsystem. Im ERP, CRM oder API-Gateway nimmt er die Anfrage entgegen, übergibt die relevanten Informationen und setzt die Entscheidung anschliessend technisch durch.
Der Policy Decision Point, PDP, wertet die Policy aus. Er erhält die Attribute und die gewünschte Aktion, prüft Bedingungen und gibt eine Entscheidung wie „erlaubt“ oder „abgelehnt“ zurück. Der PDP sollte nicht selbst zum unkontrollierten Sammelbecken aller Unternehmensdaten werden.
Der Policy Information Point, PIP, liefert Attribute. Typische Quellen sind:
- HR-System: Abteilung, Standort, Vorgesetzter und organisatorische Zuordnung
- IAM-Verzeichnis: Identität, Clearance-Level und Gruppen
- ERP: Bestellwert, Werk, Gesellschaft und Belegstatus
- CRM: Kundenregion, Klassifizierung und Vertragstyp
- Geräte- oder Sicherheitsplattform: Gerätezustand und Vertrauenssignale
Der Policy Administration Point, PAP, dient zur Erstellung, Prüfung und Pflege der Regeln. In einem professionellen Betrieb gehören Versionsverwaltung, Freigabeprozesse und Tests dazu. Die Interoperabilität zwischen diesen Systemen entscheidet oft darüber, ob ABAC im Alltag tragfähig bleibt.
XACML und die Herkunft der Werte
Das XACML-Modell ordnet Attribute den Bereichen Subject, Resource, Action und Environment zu. Die JKU Linz beschreibt XACML als etablierten OASIS-Standard, der seit seiner ersten Version aus 2003 kontinuierlich weiterentwickelt wird und als Architektur- sowie Verarbeitungsmodell für ABAC dient. Diese Einordnung ist in der JKU-Arbeit zu ABAC und XACML dokumentiert.
Eine Entscheidung kann zusätzlich Obligations und Advice enthalten. Eine Obligation muss das Zielsystem durchsetzen, etwa eine zusätzliche Freigabe. Advice liefert eine Einschränkung oder Empfehlung, beispielsweise die Rückgabe nur pseudonymisierter Felder.
Attribute brauchen ausserdem Herkunft, Aktualität und Vertrauensstufe. Ein HR-Attribut sollte nicht unkommentiert denselben Stellenwert wie ein manuell gepflegtes Freitextfeld erhalten. REST-Schnittstellen, SCIM, OIDC Claims und Datenbank-Views verbinden solche Quellen mit österreichischen ERP-Landschaften. Entscheidend ist nicht die Zahl der Schnittstellen, sondern die klare Antwort auf die Frage: Wer garantiert, dass dieser Wert korrekt und aktuell ist?
Policy-Explosion und Attribut-Pflege als Praxisrisiken
ABAC scheitert in produktiven Umgebungen selten daran, dass eine einzelne Bedingung zu schwer zu formulieren wäre. Die grösseren Risiken entstehen im Betrieb: Policies wachsen unkontrolliert, und Attribute veralten.
Wenn jede Ausnahme eine eigene Regel wird
Die Analyse zu den vier Kernproblemen von ABAC beschreibt die Policy-Explosion als zentrales Problem. Schon wenige zusätzliche Attribute oder Anwendungsfälle können Hunderte bis Tausende überlappende oder widersprüchliche Regeln erzeugen. Die Fehlersuche dauert dann nicht mehr Minuten, sondern oft Stunden.
Die Ursache liegt meist in Copy-and-paste-Governance. Eine Fachabteilung beantragt eine Ausnahme, ein Administrator kopiert eine bestehende Regel und verändert ein Detail. Nach mehreren Organisationsänderungen ist nicht mehr klar, welche Policy gilt und welche nur noch aus historischen Gründen existiert.
Gegenmassnahmen müssen operativ überprüfbar sein:
- Modulare Regelbibliotheken: Gemeinsame Bedingungen werden zentral gepflegt, statt für jede Ausnahme kopiert zu werden.
- Negativtests: Tests prüfen nicht nur erlaubte, sondern auch ausdrücklich verbotene Kombinationen.
- Policy-Hygiene: Nicht mehr benötigte Regeln, Attribute und Ausnahmen werden regelmässig entfernt.
- Entscheidungstraces: Jede Entscheidung zeigt Policy-Version, verwendete Attribute und Ergebnis.
Attribute brauchen Eigentümer
Ein veraltetes HR-Feld kann eine ganze Entscheidungskette kippen. Wenn ein Mitarbeiter nach einer Umstrukturierung weiterhin dem alten Werk zugeordnet ist, kann ABAC technisch korrekt arbeiten und trotzdem die falsche Freigabe erteilen.
Ein belastbares Attribut-Owner-Modell dokumentiert für jedes kritische Attribut die Quelle, den fachlich verantwortlichen Owner, die zulässige Verzögerung und den erwarteten Aktualisierungsrhythmus. Monitoring sollte mindestens Policy-Coverage, Attribut-Freshness und PDP-Fehlerraten sichtbar machen. Damit wird aus einer abstrakten Sicherheitsidee eine betreibbare Kontrolle.
Praxisbeispiele für ERP- und CRM-Integration
ERP-Bestellfreigabe im Werk Linz
Ein Einkäufer im Werk Linz möchte einen Rahmenvertrag über 480.000 Euro anlegen. Diese konkrete Summe stammt aus dem Szenario und ist keine allgemeine Schwelle für jede Organisation.
Der PEP am ERP, beispielsweise an einer SAP-S/4HANA-Schnittstelle, ruft den ABAC-Service auf. Die Anfrage enthält ein Subjekt-Token sowie Bestellwert, Werk und Lieferant. Der PDP wertet Rolle, persönliches Limit, Vier-Augen-Regel und Embargo-Status aus.
Für fehlende Werte fragt der PIP passende Quellen ab. Das Limit kommt aus dem HR- oder Berechtigungssystem, Embargo-Daten aus einer Compliance-Datenbank. Die Policy kann erlauben, dass der Vorgang angelegt wird, aber eine Obligation zur Einkaufsleiter-Freigabe zurückgeben. Das ERP setzt diese Verpflichtung durch, bevor der Vertrag endgültig freigegeben wird.
Der Vorteil liegt in der Beziehung zwischen den Attributen. Nicht die Rolle „Einkäufer“ allein entscheidet, sondern das Zusammenspiel von Rolle, Werk, Wert, Lieferant und Kontrollregel.
CRM-Export mit begrenzter Datensicht
Ein Vertriebsmitarbeiter möchte 50.000 Datensätze für eine Region exportieren. Der PEP am CRM übergibt Region, Kundenklassifizierung, Datenschutzfreigabe und Vertragstyp an den PDP.
Die Policy kann den Export nicht nur erlauben oder ablehnen. Sie kann zusätzlich ein Advice liefern, das die Ausgabe auf pseudonymisierte Felder begrenzt. Ein Vertriebsmitarbeiter erhält dann beispielsweise eine nutzbare regionale Arbeitsliste, aber keine unnötigen Kontakt- oder Finanzdetails.
Dieses Muster ist für hybride Landschaften wichtig. Der PDP bleibt zentral, während PEPs in SAP, Dynamics 365, einem Legacy-CRM oder einer eigenen API jeweils ihre lokalen Durchsetzungsmechanismen verwenden. Die Entscheidung bleibt nachvollziehbar, auch wenn die Zielsysteme unterschiedliche Berechtigungsmodelle sprechen.
ABAC mit MCP und internen Agenten verbinden
Interne Agenten verändern den Zugriffspfad. Ein Mitarbeiter klickt nicht mehr selbst im ERP, sondern beauftragt einen Agenten, Belege zu suchen, Daten zusammenzufassen oder einen Workflow vorzubereiten. Dadurch braucht nicht nur der Mitarbeiter eine Identität. Auch der Agent, der konkrete Tool-Aufruf und der Zweck müssen prüfbar sein.
Ein praktikables Muster exponiert den PDP als MCP-Server oder als Policy-Wrapper. Jeder Agenten-Aufruf durchläuft eine Prüfung für Subjekt, Aktion, Ressource und Kontext. Ein Buchhaltungs-Agent ruft SAP-Belege ab. Der PDP bewertet Mandant, Rolle, Gerätezustand, Datumsfenster und Datenklassifizierung, bevor der PEP am ERP die Transaktion freigibt.
Die Architektur sollte dabei mehrere Grenzen einhalten:
- Zentrale Policies: Der PDP verwaltet versionierte Regeln für alle Agenten.
- Dezentrale Durchsetzung: Jedes ERP, CRM und Legacy-System hat einen eigenen PEP.
- Eindeutige Tool-Identitäten: Der Aufruf muss zeigen, welcher Agent welche Handlung im Auftrag welcher Person ausführt.
- Separates Telemetriesystem: Anfrage, Policy-Version, Attribute und Ergebnis werden unabhängig vom Agenten protokolliert.
Typische Fehler entstehen, wenn Agenten keine eigene Identität besitzen oder Tokens zwischen Agents ungeprüft weitergereicht werden. Auch indirekte Aufrufe können Audit-Lücken erzeugen: Der Agent ruft ein Tool auf, das wiederum ein weiteres System anspricht, doch der ursprüngliche Zweck geht verloren.
ABAC passt zu MCP nicht, weil es eine bestimmte Plattform voraussetzt, sondern weil es jede einzelne Aktion kontextabhängig bewerten kann. Der MCP-Layer bleibt die Integrationsschicht. Die Policy-Entscheidung bleibt von der jeweiligen Agentenlogik getrennt. So vermeidet das Unternehmen Tool-Lock-in und kann Modelle, Agenten und Backoffice-Systeme unabhängig voneinander weiterentwickeln.
Governance, Audit und 90-Tage-Roadmap
ABAC braucht einen klaren Betriebsplan. Ohne Verantwortliche für Attribute und Policies entsteht nur eine neue technische Schicht über alten Datenproblemen.
Tag 1 bis 14
Das Team inventarisiert alle relevanten Attributquellen und klärt die Datenhoheit. Für jede Policy-Domäne wird ein Owner benannt. Gleichzeitig wird geprüft, wie ID Austria als vertrauenswürdige Identitäts- und Attributquelle eingebunden werden kann. Der Bund beschreibt ID Austria als smartphone-basierte Lösung mit drei Authentifizierungsfaktoren aus unterschiedlichen Kategorien: Besitz durch das Mobilgerät, Wissen durch ein Passwort und Biometrie. Diese Einordnung ist im europäischen Benachrichtigungsformular zu ID Austria dokumentiert.
Als Nachweis entstehen ein Quellenkatalog, ein Attribut-Owner-Verzeichnis und eine Liste der kritischen Datenflüsse.
Tag 15 bis 45
Das Team baut eine zentrale Policy-Bibliothek auf und startet mit Pilotregeln für zwei ERP-Module. Für jede Entscheidung werden Logging und ein nachvollziehbarer Decision Trace verpflichtend. Ein Audit-Dashboard zeigt, welche Policies aktiv sind, welche Attribute fehlen und warum Entscheidungen abgelehnt werden.
Die Protokollierung sollte nicht nur erfolgreiche Zugriffe erfassen. Auch Ablehnungen, Obligationen, Advice, Policy-Versionen und technische Fehler gehören in eine belastbare Strategie für Audit-Log-Management.
Tag 46 bis 90
Danach folgt der Rollout auf CRM und Legacy-Systeme. Attributqualität wird mit Data-Owner-SLAs verbunden, Policy-Reviews werden regelmässig eingeplant. Das KPI-Set enthält beispielsweise Policy-Erfolgsquote und mittlere Entscheidungszeit, ohne diese Werte vorab mit unrealistischen Zielzahlen zu versehen.
Jede Phase endet mit einem Audit-Nachweis: Quellen und Owner sind dokumentiert, Policies haben Tests, Entscheidungen lassen sich reproduzieren und offene Risiken besitzen einen Verantwortlichen. Die wichtigste Roadmap-Regel lautet: Keine neue Policy ohne klare Datenquelle, fachlichen Owner und überprüfbaren Testfall.
Specialty Tokens unterstützt Unternehmen dabei, ABAC in ERP-, CRM- und Legacy-Prozesse einzubetten, interne Agenten sicher über eine MCP-Schicht anzubinden und Policies mit nachvollziehbarer Governance produktionsfähig zu machen. Besuchen Sie Specialty Tokens, wenn Sie Ihre Attributquellen, Agenten-Integrationen oder eine konkrete IAM-Roadmap gemeinsam mit erfahrenen Ingenieuren prüfen möchten.