Bundesamt für Sicherheit in der Informationstechnik

M 4.211 Einsatz des z/OS-Sicherheitssystems RACF

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter IT

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 für allgemeine Resource-Klassen

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 für die Behandlung der Passwörter

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:

Trennung der Gruppenstruktur  
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:

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.

Prüffragen:

  • Ist das z/OS -Sicherheitssystem RACF hinsichtlich seiner Einstellungen und Parameter ausführlich geplant und konzipiert?

  • Wurde das voreingestellte Passwort für das RVARY-Kommando im z/OS -System durch eines neues Passwort ersetzt?

  • Werden geänderte und eigene RACF -Exits unter z/OS dokumentiert?

  • Werden eingesetzte RACF -Exits unter z/OS überwacht?

  • Ist bei den in RACF angelegten Kennungen zum Schutz gegen Brute-Force-Attacken die Anzahl der Anmeldeversuche bei der Authentisierung gegenüber dem z/OS -System begrenzt?

  • Existiert ein Verfahrem zum Anlegen und Freischalten von Kennungen in RACF ?

  • Werden RACF -Kennungen im z/OS -System nach einer festgelegten Zeitspanne der Inaktivität gesperrt?

  • Werden sicherheitskritische Programme des z/OS -Systems mit der RACF -Klasse PROGRAM geschützt?

  • Sind hochautorisierte Dateien ( z. B. APF -, SVC-Dateien, Parmlibs und Proclibs) über voll qualifizierte generische Dateiprofile geschützt?

  • Werden die Daten und Anwendungen der Mandanten durch RACF -Profile im z/OS -System getrennt?

  • Werden Wartungsfenster für das z/OS -System mit allen Kunden abgestimmt, die auf dem betreffenden System arbeiten?

Stand: 13. EL Stand 2013