Sie befinden sich hier: Themen IT-Grundschutz-Kataloge. Inhalt. Dokumententitel: M 4.211 Einsatz des z/OS-Sicherheitssystems RACF - IT-Grundschutz-Kataloge - Stand 2006
direkt zu der Navigation Servicebereich. direkt zu der Hauptnavigation. direkt zur Themennavigation. direkt zum Seiteninhalt.

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.

 
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

 
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:

 Prinzipaufbau der empfohlenen Gruppenstruktur im RACF

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:

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: