RACF im Kontext moderner IAM-Architekturen: Nutzen, Grenzen und Zukunft nach 50 Jahren

RACF (Resource Access Control Facility) ist seit 1976 ein zentrales Sicherheitsprodukt von IBM für Mainframe-Systeme und feiert 2026 sein 50-jähriges Bestehen. Es bildet bis heute die Grundlage für Zugriffskontrolle auf z/OS-Systemen und schützt geschäftskritische Anwendungen in Banken, Versicherungen und Behörden. Aus IAM-Sicht ist RACF eines der langlebigsten Beispiele für systemnahe Autorisierung und Identitätsprüfung. Viele heutige Konzepte moderner IAM-Architekturen – insbesondere zentrale Policy-Steuerung und Auditierbarkeit – wurden hier früh etabliert. Genau deshalb ist RACF auch heute noch strategisch relevant, selbst in hybriden IAM-Landschaften.

RACF kontrolliert, welche Benutzer auf welche Ressourcen zugreifen dürfen, und prüft jede Anfrage in Echtzeit gegen definierte Regeln. Es nutzt eine zentrale Sicherheitsdatenbank, in der Benutzer, Gruppen und Berechtigungsprofile gespeichert sind. Zugriffe werden über definierte Policies autorisiert oder abgelehnt. Zusätzlich protokolliert RACF sicherheitsrelevante Ereignisse für Audits. Die Integration erfolgt tief im Betriebssystem über die System Authorization Facility (SAF).

Vor RACF war Security auf dem Mainframe fragmentiert (jede Anwendung regelte den Zugriff selbst), teilweise gar nicht vorhanden oder nur sehr rudimentär, oft über Batch-Jobs, JCL-Parameter oder selbstgeschriebene Checks gelöst. Der Zugriff erfolgt meist über User-IDs ohne starke Kontrolle, Passwörter mit wenig Durchsetzung, Dataset-Attribute (z. B. Schutzbits). Anwendungen (z. B. CICS, IMS) hatten eigene Security-Mechanismen. Security war inkonsistent, schwer kontrollierbar und kaum zu auditieren. 

IBM hat RACF entwickelt, weil mehrere Probleme gleichzeitig entstanden: Mit Mehrbenutzer- und Timesharing-Systeme (TSO) arbeiteten plötzlich viele User gleichzeitig interaktiv auf einem System. Die Sensibilität der Daten nahm zu, denn Mainframes wurden nicht mehr nur technisch, sondern auch für Bankdaten, Versicherungen und Behörden genutzt. Mit wachsender Systemgröße war die Security nicht mehr manuell beherrschbar.

RACF selbst „integriert“ nicht aktiv Anwendungen im modernen Sinn, sondern stellt über SAF (System Authorization Facility) eine zentrale Sicherheitsinstanz bereit, die von Anwendungen genutzt wird, d. h.: RACF ist kein „Plugin pro Anwendung“, sondern Anwendungen rufen SAF auf und SAF delegiert an RACF und RACF entscheidet über den Zugriff. 

Typische Anwendungen/Sub-Systeme sind:

• TSO/E (Time Sharing Option)
• JES2/JES3 (Job Submission & Batch-Verarbeitung)
• Datasets (VSAM, Zugriffsschutz auf Daten)
• DB2 (heute Db2 for z/OS)
• IMS
• CICS (Customer Information Control System) VTAM (heute z/OS Communications Server
• Zugriff auf Netzwerkressourcen, Terminals)

Damit bietet RACF Authentifizierung, Autorisierung und Protokollierung in einem System.

RACF wurde vor DB2 entwickelt. Als DB2 1983 entstand, gab es RACF bereits als etablierte zentrale Sicherheitslösung auf dem Mainframe. Deshalb war es naheliegend, DB2 in diese bestehende Sicherheitsinfrastruktur (SAF/RACF) zu integrieren. Der eigentliche Auslöser für diese Entscheidung war aber kein technischer Zwang von DB2, sondern der Wunsch, Sicherheitsverwaltung zu zentralisieren und sie von den z/OS-Sicherheitsadministratoren statt von den DB2-Administratoren steuern zu lassen. 

Diese Trennung von Zuständigkeiten (SoD) war also schon früh wichtiger als die reine DB2-interne Administration. DB2-eigene GRANT/REVOKE-Mechanismen blieben möglich, denn die DB2-Security wird nicht ersetzt, sondern lediglich ergänzt bzw. integriert. 

Bis heute regelt DB2 die fachlichen Objektberechtigungen innerhalb der Datenbank (z. B. SELECT auf Tabellen), während RACF die Identitäten, Authentifizierung und systemweite Zugriffskontrolle verwaltet und damit die Auditierbarkeit und Governance sicherstellt.

USS (Unix System Services) und OMVS erweitern RACF um Unix-ähnliche Funktionalitäten. Die Verknüpfung zwischen diesem UNIX auf dem Mainframe und RACF ist enger als man denkt, denn im Grunde ist RACF auch das „User- und Rechtesystem“ für UNIX auf z/OS.  RACF ersetzt die dazu üblichen unixoiden Mechanismen /etc/passwd und /etc/group zentral. z/OS UNIX nutzt das POSIX-Berechtigungsmodell, aber die zugrunde liegenden Benutzer und Gruppen werden zentral in RACF verwaltet. Über das OMVS-Segment im RACF-Profil werden UID, GID und UNIX-Attribute definiert, sodass RACF sowohl Authentifizierung als auch Identitätsmanagement für UNIX auf dem Mainframe übernimmt. Die Pflege dieses OMVS-Segments (UID, Home Directory, Default Shell) durch eine übergeordnete IAM-Lösung ist also zwingend erforderlich. Neben POSIX-Rechten kann RACF zusätzlich auch feingranulare Policies erzwingen, Auditing durchführen und den Zugriff auf spezielle Ressourcen kontrollieren.

Aus IAM-Perspektive ist RACF vor allem wegen seiner hohen Integrität und Auditierbarkeit relevant. Jede Berechtigungsentscheidung ist nachvollziehbar, revisionssicher dokumentiert und kann historisch ausgewertet werden. Gerade in stark regulierten Branchen ist das ein entscheidender Vorteil gegenüber verteilten Systemen ohne zentrale Kontrollinstanz. Zudem bietet RACF eine sehr granulare Steuerung von Zugriffen auf Ressourcenebene. Diese Kombination aus Tiefe, Stabilität und Transparenz ist bis heute schwer zu ersetzen – insbesondere im Mainframe-Kontext.

Ja, RACF kann man als IAM-System für z/OS sehen. Es erfüllt alle klassischen IAM-Funktionen wie Identitäts-, Authentifizierungs- und Autorisierungsmanagement sowie Auditing. Es fehlen jedoch wesentliche Merkmale einer modernen IAM-Lösung, z. B.: Systemübergreifende Funktionalität (Cloud, Apps, APIs, SaaS), Single Sign-On (SSO) über viele Plattformen, Federation / Identity Brokering, Self-Service & Lifecycle-Management.

Die Integration erfolgt typischerweise über LDAP (z/OS LDAP Server), RACF Callable Services wie bei Garancy und USS-basierte Schnittstellen. LDAP ermöglicht standardisierte Abfragen und Provisionierung aus IAM-Systemen wie One Identity, Opentext oder Sailpoint. USS und OMVS spielen eine zentrale Rolle für moderne APIs und Skripting. Wichtig ist die korrekte Handhabung von Codepages (EBCDIC vs. ASCII/UTF-8). Moderne IAM-Systeme arbeiten meist mit UTF-8, während RACF intern EBCDIC nutzt. Fehlerhafte Konvertierungen können zu inkonsistenten Userdaten oder Zugriffsproblemen führen. Eine IAM-Lösung muss hier klare Konvertierungsregeln definieren, insbesondere bei Attributen wie Namen, Gruppen und Beschreibungen, die wesentlicher Input für übergeordnete Governance-Aspekte sind.

In heutigen Architekturen ist RACF häufig Teil einer hybriden IAM-Landschaft, in der zentrale IAM-Systeme die Governance übernehmen und RACF weiterhin als durchsetzende Instanz fungiert. Das bedeutet: Identitäten werden zentral verwaltet, aber die Autorisierung auf dem Mainframe bleibt bewusst nahe am System. Diese Trennung ist strategisch sinnvoll, da sie Stabilität und Kontrolle gewährleistet. Gleichzeitig entstehen Herausforderungen bei Transparenz, Rollenmodellierung und Integration. Genau hier setzen moderne IAM- und PAM-Lösungen an.

RACF ist technisch stabil, aber schwer in moderne Prozesse zu integrieren. Rollenmodelle sind oft historisch gewachsen und komplex. Transparenz über effektive Berechtigungen ist eingeschränkt. Automatisierung und Self-Service sind nur begrenzt möglich. Dadurch entstehen Governance- und Compliance-Risiken.

RACF bietet eine außergewöhnlich hohe Nachvollziehbarkeit aller Zugriffe und Änderungen. Jede sicherheitsrelevante Aktion wird protokolliert und kann ausgewertet werden. Diese zentrale Auditierbarkeit ist besonders für Compliance-Anforderungen entscheidend. Sie ermöglicht es, regulatorische Vorgaben effizient zu erfüllen. In vielen Organisationen ist genau das der Hauptgrund, warum RACF weiterhin eingesetzt wird.

RACF ist robust, genau deshalb liegen kritischen Sicherheitsaspekte weniger in „offensichtlichen Lücken“, sondern in Fehlkonfiguration, Berechtigungsdesign und Betrieb. Zu den wichtigsten Punkten zählen

• überprivilegierte Benutzer (SPECIAL(System/Group), OPERATIONS, AUDITOR)
• Unbeabsichtigter Zugriff auf sensible Daten über generische Regeln (DATASET.**)
• Falsch konfigurierte kritische Klassen (z.B. SURROGAT (erlaubt Impersonation).

IPG unterstützt Unternehmen dabei, RACF in moderne IAM-Architekturen einzubetten oder – beim Umzug einer von RACF verwalteten Anwendung vom Mainframe auf die dezentrale Welt – strategisch und technisch zu beraten. Dazu gehören Analyse bestehender Berechtigungsstrukturen, Integration in zentrale Governance-Prozesse und Entwicklung von Zielarchitekturen. Besonders relevant ist die Verbindung von Mainframe-Sicherheit mit modernen IAM- und PAM-Lösungen. Ziel ist es, Transparenz, Steuerbarkeit und Auditierbarkeit zu erhöhen, ohne die Stabilität der bestehenden Systeme zu gefährden.

Unternehmen stehen heute vor drei typischen Optionen im Umgang mit RACF:

1. Weiterbetrieb
2. Integration
3. Ablösung

Der Weiterbetrieb ist sinnvoll, wenn Stabilität und regulatorische Sicherheit im Vordergrund stehen. Die Integration in ein zentrales IAM-System ist der häufigste Ansatz, um Governance und Transparenz zu verbessern. Eine vollständige Ablösung ist selten und nur bei tiefgreifender Modernisierung der Mainframe-Landschaft realistisch. Entscheidend ist eine klare Zielarchitektur, die sowohl technische als auch regulatorische Anforderungen berücksichtigt.

Ein direkter Ersatz für RACF existiert kaum, da es fest in z/OS integriert ist. Stattdessen werden Zugriffe häufig über Active Directory, Cloud-Identitätsdienste und Föderation (z. B. SAML, OIDC) gesteuert. RACF bleibt dabei oft als technische Kontrollinstanz im Hintergrund bestehen. Eine vollständige Ablösung erfolgt meist nur bei der Migration von Fachanwendungen weg vom Mainframe.

Die klassische IT-Sicherheit basierte lange auf klaren Systemgrenzen und physischen Perimetern. RACF war in diesem Modell ein zentraler Baustein und setzte früh auf identitätsbasierte Zugriffskontrolle direkt im System – für viele Jahrzehnte State of the Art. Mit Cloud, Remote Work und hybriden Architekturen lösen sich diese festen Grenzen jedoch zunehmend auf. Identität wird damit zum übergreifenden Steuerungsfaktor für Sicherheit über Systemgrenzen hinweg. Moderne Sicherheitsmodelle verlagern den Fokus konsequent auf Benutzer, Rollen und Kontexte und führen das Prinzip, das RACF früh etabliert hat, in eine neue, vernetzte Architektur über.

Dieser Bericht beruht auf Expertenwissen, für die Ausformulierung wurde Hilfe von KI in Anspruch genommen.