M 4.211 Einsatz des z/OS-Sicherheitssystems RACF
Verantwortlich für Initiierung: Leiter IT, IT-Sicherheitsmanagement
Verantwortlich für Umsetzung: Administrator
Die sichere Konfiguration eines z/OS-Systems erfolgt durch Definitionen von Betriebssystem-Komponenten und zentral über das Sicherheitssystem RACF (Resource Access Control Facility). In dieser Maßnahme werden Empfehlungen für den Einsatz von RACF erläutert. Informationen für die Sicherung der z/OS-Definitionen können der Maßnahme M 4.209 Sichere Grundkonfiguration von z/OS-Systemen entnommen werden.
In RACF werden die Kennungen der Anwender und die Zugriffsmöglichkeiten auf unterschiedliche Ressourcen in Form von Profilen verwaltet. Diese stehen als Dataset Profile, General Resource Profile, Group Profile und deren Verbindungen sowie als User Profile zur Verfügung.
Für die Verwaltung von RACF sind die folgenden Regeln zu berücksichtigen:
Wesentliche RACF-Einstellungen
SETROPTS Definitionen
Die zentrale Konfiguration des RACF erfolgt in den SETROPTS Einstellungen. Hier werden allgemeingültige systemweite Einstellungen für das RACF vorgenommen. Da hier sehr viele Parameter veränderbar sind und sich teilweise gegenseitig beeinflussen, müssen die Einstellungen gut konzipiert und durchdacht sein. Nachfolgend eine Aufzählung der wichtigsten Parameter, die über das Kommando SETROPTS gesetzt werden müssen.
- Resource Access Policies für allgemeine Resource-Klassen
CLASSACT | Access Authorization Checking |
AUDIT | schaltet Protokollfunktion für Klassen an |
RACLIST | definiert, welche Profile in den Speicher geladen werden |
GENERIC | aktiviert Generic Profile Checking |
NOADSP | verhindert diskrete Profile |
PROTECTALL | stellt sicher, dass RACF-Profile erstellt werden |
WHEN | erlaubt konditionalen Schutz für Programme |
CMDVIOL | protokolliert alle RACF-Verstöße |
OPERAUDIT | kontrolliert Kennungen mit Attribut OPERATIONS |
ERASE | löscht Dateninhalt nach Löschen einer Datei |
u. a. |
Tabelle: Resource Access Policies
- Password Policies für die Behandlung der Passwörter
INTERVAL | Gültigkeitsdauer des aktuellen Passworts |
REVOKE | Anzahl ungültiger Anmelde-Versuche vor dem Sperren |
RULE | definiert Passwort-Regeln |
u. a. |
Tabelle: Password Policies
Die RACF-Grundeinstellung ist wesentlich für die Sicherheit des z/OS-Betriebssystems und relativ komplex. Da hier u. U. mehr als 30 Parameter definiert oder aktiviert werden müssen, ist eine ausführliche Planung notwendig. Diese stellt sicher, dass die Parameter richtig gesetzt werden und vermeidet so potentielle Sicherheitslücken. Zur Unterstützung des Planungsvorgangs bietet der Hersteller einen RACF Security Planner an (auch im Internet). Der RACF Security Planner gibt auch Empfehlungen für die RACF-Grundeinstellung.
Voreingestelltes RVARY-Passwort
Das voreingestellte Passwort für das RVARY-Kommando, z. B. für den SWITCH der RACF-Datenbanken, muss verändert werden und darf nicht auf dem voreingestellten Wert stehen.
Einsatz von RACF-Exits
Es ist zu untersuchen, ob RACF-Exits benötigt werden. Durch verschiedene Exits lässt sich erreichen, dass RACF Sicherheitsprüfungen übergeht oder zusätzliche Sicherheitsprüfungen durchführt. Geänderte und eigene Exits sind zu dokumentieren. Dabei sind Funktion und Grund für den Einsatz anzugeben. Werden Exits eingesetzt, sind sie zu überwachen (siehe M 2.291 Sicherheits-Berichtswesen und -Audits unter z/OS).
RACF-Kennungen
Begrenzung der Anmeldeversuche
Eine in RACF angelegte Kennung erlaubt dem Anwender die Authentisierung gegenüber dem z/OS-System. Zum Schutz gegen Brute-Force-Attacken ist die Anzahl der Anmeldeversuche zu begrenzen, damit die Kennung automatisch gesperrt werden kann (maximal 3 bis 5 Versuche).
Anlegen einer Kennung
Für das Anlegen einer Kennung muss ein Verfahren existieren. Das Verfahren muss sicherstellen, dass nur Personen, die den Zugang zu dem jeweiligen System für ihre Arbeit benötigen, und deren Vertreter eine Kennung erhalten. Das Verfahren kann z. B. über ein Formblatt oder automatisiert ablaufen. In jedem Fall muss der Systemverantwortliche den Antrag genehmigen.
Segmente einer Kennung
Es sind nur die Segmente einer Kennung im RACF zu aktivieren, die der Anwender für seine Tätigkeit auch benötigt (z. B. TSO, Netview, DCE oder OMVS).
Freischaltung einer Kennung
Zum Freischalten einer gesperrten Kennung ist ein Verfahren einzuführen. Der Anwender muss sich gegenüber der freischaltenden Stelle, wie Call Center oder User Helpdesk, eindeutig identifizieren und seinen Anspruch nachweisen. Erst daraufhin darf die Kennung des Anwenders freigeschaltet werden.
TSO-Segment Daten
Die Daten aus dem TSO-Segment (Time Sharing Option), wie z. B. Name der Logon-Prozedur, Account-Nummer oder Speicherplatz, sollten durch RACF-Profile vor dem Überschreiben durch den Anwender geschützt werden. Dadurch kann der Anwender nur mit der vorgeschriebenen Umgebung arbeiten. Ausnahmefälle müssen begründet und dokumentiert werden.
Sperren wegen Inaktivität
Die Kennung eines Anwenders sollte aus Sicherheitsgründen nach einer bestimmten Zeitspanne der Inaktivität gesperrt werden, z. B. nach 90 Tagen. Von dieser Regelung auszunehmen sind Verfahrens-Kennungen, beispielsweise Notfall-Kennungen und STC-Kennungen. Es ist zu überlegen, nach einem noch längeren Zeitraum, z. B. 180 Tagen, die gesperrten Kennungen daraufhin zu überprüfen, ob sie gelöscht werden können. Wird ein solcher Löschvorgang durchgeführt, muss sichergestellt werden, dass die Ergebnisse des Löschvorgangs protokolliert werden und die RACF-Administration darüber informiert ist. Die Protokolle müssen gesichert abgespeichert werden und dienen der Nachvollziehbarkeit durch die RACF-Administration.
Löschen einer Kennung
Die Kennungen von Anwendern werden entweder auf Antrag gelöscht oder als Ergebnis von internen Überprüfungen. Beim Löschen einer Kennung muss darauf geachtet werden, dass neben der Kennung in RACF alle entsprechenden Zuordnungen und auch der ALIAS-Eintrag dieser Kennung im Masterkatalog gelöscht werden. Die Dateien dieser Kennung müssen entweder ebenfalls gelöscht oder einer anderen Kennung zugeordnet werden.
Limitierung restriktiver Kennungen
Kennungen mit hohen Rechten sollten nur dann vergeben werden, wenn die Mitarbeiter diese Berechtigungen tatsächlich für ihre Arbeit benötigen. Weitere Informationen hierzu finden sich in der Maßnahme M 2.289 Einsatz restriktiver z/OS-Kennungen.
RACF-Gruppen und -Gruppenstruktur
Berechtigungen sollten nicht direkt an eine Kennung vergeben werden. Anwender mit gleichen Aufgaben sollten in Gruppen zusammengefasst werden und über diese Gruppen die Berechtigungen erhalten. Eine Trennung der Gruppenstruktur ist zu empfehlen, z. B. nach dem folgenden Schema:
Organisationsgruppen | Zuordnung der Kennungen zu Organisationseinheiten der Behörde bzw. des Unternehmens, beispielsweise ORGA |
Funktionsgruppen | Über diese Gruppen erhalten die Anwender ihre Rechte anhand der Aufgaben (Funktion) im System, beispielsweise FUNKT. |
Ressourcen-Gruppen | zur Verwaltung der Datei-Ressourcen. Für jedes angelegte Dateiprofil im RACF muss eine Gruppe oder eine Kennung existieren. Gruppen sind zu empfehlen, da diese nicht zum Einstieg in das System missbraucht werden können, z. B. RES. |
Tabelle: Trennung der Gruppenstruktur
Nachfolgend eine beispielhafte Darstellung der Gruppenstruktur:

Abbildung: Prinzipaufbau der empfohlenen Gruppenstruktur im RACF
Der Name der Gruppe SYS1 ist fest vorgegeben. Sie ist immer die oberste Gruppe. In dieser Gruppe befindet sich nur der IBMUSER, der bei einer Neuinstallation benötigt wird. Zum Umgang mit dem IBMUSER siehe Maßnahme M 2.289 Einsatz restriktiver z/OS-Kennungen.
Die Owner-Struktur der Gruppen im RACF ist durchgängig anzulegen. In diesem Beispiel ist SYS1 der Owner der Gruppen ORGA, FUNKT und RES. Für weitere Untergruppen sollte als Owner der jeweilige Gruppenname der übergeordneten Gruppe gewählt werden. Der hierarchische Aufbau vereinfacht die Übersicht beim Einsatz der Berechtigungen Group-Special, Group-Operations und Group-Auditor.
Schutz durch RACF-Definitionen
Schutz von Started Tasks
Started Tasks sind mit einer Kennung im RACF mit dem Attribut PROTECTED anzulegen. Das Attribut PROTECTED verhindert dabei den Missbrauch der Kennung zum normalen Login. Started Tasks sind in der RACF-Klasse STARTED zu definieren und zu schützen. Weitere Informationen über Started Tasks finden sich in der Maßnahme M 4.209 Sichere Grundkonfiguration von z/OS-Systemen.
Schutz von sicherheitskritischen Programmen
Sicherheitskritische Programme sind mit der RACF-Klasse PROGRAM zu schützen. Der Zugang zu diesen Programmen ist nur Anwendern zu gewähren, die diese Programme für ihre Tätigkeit benötigen, sowie deren Vertretern. Weitere Informationen zum Umgang mit sicherheitskritischen Programmen sind in M 4.215 Absicherung sicherheitskritischer z/OS-Dienstprogramme zu finden.
Schutz von Dateien
Dateien werden im RACF über Dateiprofile geschützt. Dies betrifft sämtliche Systemdateien sowie alle Dateien der produktiven Anwendungen. Für den Schutz von Dateien sollten die folgenden Regeln beachtet werden:
- Dateien müssen generell über generische Dateiprofile im RACF geschützt werden. Diskrete Dateiprofile sind zu vermeiden.
- Kein Dateiprofil sollte mit Universal Access (UACC) größer NONE angelegt werden. Es sollte durch organisatorische oder technische Mechanismen verhindert werden, dass Anwender für die eigenen Dateiprofile den UACC-Wert verändern können.
- General Resource-Profile sollten nur dann mit UACC größer NONE angelegt werden, wenn dies unbedingt erforderlich ist. Dies sollte nachvollziehbar dokumentiert werden.
- In einem Produktions-System dürfen Dateiprofile und General Resource-Profile nicht im Warning-Modus laufen, da sonst kein echter Schutz der Ressourcen gewährleistet ist, denen diese Profile zugeordnet sind. Beim Einsatz des Warning-Modus auf einem Test-System ist darauf zu achten, dass die Performance des Systems nicht gravierend negativ beeinflusst wird (durch das Generieren von MVS-Nachrichten und SMF-Records).
- Um den Aufwand der RACF-Pflege zu begrenzen, sind Standards für die Erstellung und Benutzung von Dateinamen und RACF-General Resources notwendig (siehe M 2.285 Festlegung von Standards für z/OS-Systemdefinitionen).
- Hochautorisierte Dateien, wie z. B. APF-, SVC-Dateien, Parmlibs und Proclibs, dürfen nur über voll qualifizierte generische Dateiprofile geschützt werden. Weitere Informationen zum Schutz dieser Dateien sind in M 4.209 Sichere Grundkonfiguration von z/OS-Systemen zu finden.
- Die RACF-Datenbank, die Backup-RACF-Datenbank und deren Sicherheitskopien sind mit UACC (NONE) zu schützen. Zugriffsrechte auf diese Dateien (selbst nur lesend) sind auf ein Minimum zu beschränken, um Brute-Force-Attacken auf die in der Datenbank gespeicherten Passwörter soweit wie möglich zu verhindern.
HFS-Dateien
Die HFS-Dateien (Hierarchical File System) des USS-Subsystems (Unix System Services) müssen im z/OS wie normale MVS-Datasets über RACF geschützt werden. Informationen zum Schutz der Files im USS sind in M 4.220 Absicherung von Unix System Services bei z/OS-Systemen enthalten.
Mandantenfähigkeit unter z/OS
In vielen Installationen ist es üblich, dass sich mehrere Kunden (Mandanten) ein z/OS-System teilen. Da sie somit auf dem gleichen System arbeiten, muss das z/OS-System mandantenfähig sein. Dies bedeutet unter anderem, dass ein Kunde nicht auf die Daten eines anderen Kunden zugreifen und somit auch nicht deren Vertraulichkeit, Integrität oder Verfügbarkeit beeinträchtigen kann.
Für die Mandantenfähigkeit sind folgende Hinweise zu beachten:
Trennung durch RACF-Profile
Die Daten und Anwendungen der Mandanten müssen durch RACF-Profile getrennt werden. Hierzu ist ein RACF-Konzept zur Mandantentrennung zu erstellen.
Absicherung der Betriebssysteme
Keiner der Mandanten darf ändernden Zugriff auf Dateien des z/OS-Betriebssystems haben. Solche Änderungen dürfen nur durch den Betreiber des z/OS-Systems erfolgen.
Kennungen mit hohen Berechtigungen
Hohe Berechtigungen im RACF (SPECIAL, OPERATIONS, AUDITOR) dürfen nur von Mitarbeitern des System-Betreibers verwendet werden. Es sollte überlegt werden, dem Kunden auf Wunsch die Berechtigungen Group-Special, Group-Operations und Group-Auditor zur Verfügung zu stellen. Hierzu muss ein Gruppenkonzept (Owner-Konzept) speziell für jeden Kunden erstellt werden.
Einsatz von RACF-Security-Labels
Es ist zu überlegen, RACF-Security-Labels für die Trennung der Kundenumgebungen zu verwenden, um die Mandantentrennung genauer durchsetzen zu können.
Abstimmung Wartungsfenster
Die Wartungsfenster, in denen das z/OS-System nicht zur Verfügung steht, sind mit allen Kunden, die auf dem betroffenen System arbeiten, abzustimmen.
Ergänzende Kontrollfragen:
- Sind die wichtigsten SETROPTS-Werte geeignet gesetzt?
- Ist das RVARY-Passwort neu gesetzt?
- Ist die Anzahl der ungültigen Login-Versuche begrenzt?
- Gibt es ein Verfahren zum Freischalten gesperrter Kennungen?
- Werden Kennungen ohne Aktivitäten nach Ablauf einer festgelegten Frist im System gesperrt?
- Sind die eingesetzten RACF-Exits dokumentiert?
- Sind die Wartungsfenster mit allen Kunden abgestimmt?
- Sind die Daten der unterschiedlichen Kunden ausreichend über RACF geschützt?