Bundesamt für Sicherheit in der Informationstechnik

M 4.209 Sichere Grundkonfiguration von z/OS-Systemen

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

Verantwortlich für Umsetzung: Administrator

Das z/OS-Betriebssystem verwaltet und benutzt verschiedene Autorisierungsmechanismen. Bei fehlerhaftem Einsatz oder Missbrauch dieser Mechanismen kann sich dies auf die Integrität des gesamten Systems auswirken. Sie müssen deshalb in der Grundkonfiguration berücksichtigt werden. Es handelt sich dabei im Wesentlichen um die folgenden Funktionen:

  • APF -autorisierte Dateien (Authorized Program Facility),
  • SVCs (SuperVisor Calls),
  • Ressourcen-Schutz,
  • Parmlib-Definitionen,
  • System Prozeduren (Started Tasks) und
  • JES2-Definitionen.

Empfehlungen für das Sicherheitssystem RACF (Resource Access Control Facility) sind in M 4.211 Einsatz des z/OS-Sicherheitssystems RACF beschrieben. Darüber hinaus ist M 4.220 Absicherung von Unix System Services bei z/OS-Systemen für die Grundkonfiguration zu berücksichtigen.

Um die Integrität des z/OS-Betriebssystems zu schützen, sind die folgenden Empfehlungen zu berücksichtigen:

APF-Autorisierungen

Über APF-autorisierte Dateien ist es möglich, sich Zugriff zu privilegierten Operationen zu verschaffen (z. B. MODESET SVC). In der Folge lassen sich dadurch Funktionen benutzen, für die der Anwender normalerweise nicht autorisiert ist. So ist es jederzeit möglich, sich im Supervisor-Modus Zugriff zu privilegierten Hauptspeicherbereichen zu verschaffen und dort hoch privilegierte Attribute (z. B. SPECIAL im ACEE - Accessor Environment Element) der eigenen Kennung zuzuordnen. Für APF-Dateien ist das Folgende zu beachten:

  • Alle APF-Dateien müssen über vollqualifizierte generische RACF-Profile (wie auch in M 4.211 Einsatz des z/OS-Sicherheitssystems RACF beschrieben) geschützt werden, d. h. trotz der Benutzung von generischen Profilen sollte der komplette Dateiname als Profilname benutzt werden.
  • Alle APF-Dateien werden im Parmlib-Member PROGnn mit Volume-Angaben (bzw. Angabe SMS) definiert. Es dürfen keine Einträge existieren, zu denen es keine Datei gibt, da sonst die Gefahr besteht, dass eine andere Datei untergeschoben wird.
  • Zugriff zu den APF-Dateien dürfen nur Mitarbeiter haben, zu deren Aufgaben die Wartung des Systems gehört. Die Anzahl dieser Mitarbeiter ist auf ein Minimum zu beschränken. Eine Vertreterregelung muss vorgesehen sein.
  • APF-Dateien sind regelmäßig auf Veränderungen zu überprüfen, um Missbrauch und Missbrauchsversuche möglichst frühzeitig zu entdecken. Änderungen an diesen Dateien sollten unter Produktionsbedingungen nur über angemeldete Wartungsfenster erfolgen.
  • Es ist zu überlegen, ob der Einsatz eines Real-Time-Monitors hilft, Missbrauch schneller zu entdecken, und somit zur Erhöhung der Sicherheit beitragen kann (siehe M 2.291 Sicherheits-Berichtswesen und -Audits unter z/OS ). In jedem Fall sollten mindestens manuelle Kontrollen der Zugriffe auf APF-Dateien durchgeführt werden, etwa durch Auswertung von SMF-Sätzen (System Management Facility).
  • Alle APF-Dateien sollten ohne Extents angelegt werden.
  • Es sollte berücksichtigt werden, dass alle in der LINKLIST definierten Dateien bei Benutzung des Parameters LNKAUTH=LNKLST im Member IEASYSxx vom System standardmäßig als APF-Dateien angesehen werden. Auch für diese Dateien müssen deshalb die oben beschriebenen Sicherheitsmechanismen aktiviert werden.

User SVCs (SuperVisor Calls)

User-SVCs (alle SVC-Nummern ab 200) erhalten die Kontrolle im SuperVisor-Status mit Key 0 (diesentspricht dem Kernel-Modus bei einigen anderen Betriebssystemen), d. h. User-SVCs haben Zugriff auf alleSpeicherbereiche und alle Operationendes z/OS-Betriebssystems. Für User-SVCs ist deshalb das Folgende zu beachten:

  • Alle Dateien, die SVC-Programme bereitstellen, müssen über vollqualifizierte generische RACF-Profile (wie auch in M 4.211 Einsatz des z/OS-Sicherheitssystems RACF beschrieben) geschützt werden.
  • Alle SVCs werden im Parmlib-Member IEASVCxx definiert. Da ein SVC durch die notwendigen internen Sicherheitsmechanismen nicht sehr klein sein kann, deutet ein User-SVC-Modul mit kleiner Länge eventuell auf ein Sicherheitsproblem hin. Solche User-SVCs müssen von der Systemprogrammierung darauf untersucht werden, ob sicherheitskritische Lücken vorhanden sind. In früheren Jahren wurden oft SVCs mit unzureichenden Sicherheitsmechanismen eingesetzt, z.B. sogenannte Autorisierungs-SVCs, um autorisierte Funktionen aus nicht-autorisierten Umgebungen heraus ausführen zu können. Falls solche SVCs noch existieren, sollten sie nach Möglichkeit entfernt oder ersetzt werden.
  • Werden User-SVCs im Rahmen von Produkten mitgeliefert, sollten beim Hersteller die Sicherheitsmechanismen der mitgelieferten SVCs erfragt werden. Dies ist besonders wichtig, wenn das gelieferte SVC-Modul sehr klein ist, denn das ist eventuell ein Hinweis auf fehlende interne Prüfungen.
  • Zugriff auf SVC-Dateien dürfen nur Mitarbeiter haben, zu deren Aufgaben die Wartung des Systems gehört. Die Anzahl dieser Mitarbeiter ist zu minimieren. Dabei muss jedoch sichergestellt werden, dass mindestens ein Vertreter Zugriff hat.

Ressourcen

Ressourcen des z/OS-Betriebssystems (z.B. Dateien, Programme, Funktionen usw.) sind über RACF zu schützen (siehe M 4.211 Einsatz des z/OS-Sicherheitssystems RACF ). Darüber hinaus sollten folgende Empfehlungen beachtet werden:

  • Für die Class Descriptor Table ( CDT ) sollten installationsspezifische Einträge nur im Modul ICHRRCDE vorgenommen werden. Als wichtige Parameter sind DFTUACC (hier wird NONE empfohlen) und OPER (hier wird NO empfohlen) zu beachten. Die Dataset Name Table (DSNT) muss die Dateinamen der RACF-Datenbanken enthalten.
  • Die Authorized Caller Table (AUT) sollte laut Empfehlung von IBM leer sein. Dabei handelt es sich um eine alte Funktion, die heute durch die Klasse Program ersetzt worden ist, aber noch existiert. Ausnahmen müssen begründet sein.
  • Die TSO Authorized command and program table in der Parmlib (IKJTSOxx) darf nur die Kommando- und Programm-Namen enthalten, die für die Ausführung unter TSO (Time Sharing Option) notwendig sind.
  • Die Started Procedure Table (ICHRIN03) sollte nur noch wenige Einträge für Notfälle enthalten, ansonsten sollte für die Definition der autorisierten Started Tasks die RACF Klasse STARTED benutzt werden. Das Attribut PRIVILEGED sollte vermieden, TRUSTED nur eingesetzt werden, wenn erforderlich (z.B. bei JES2). Die Tabelle sollte einen generischen Eintrag für alle Started Tasks enthalten, die nicht definiert sind, um sicherzustellen, dass diese Tasks nicht lauffähig sind.
  • Die RACF Router Table muss synchron zur CDT gepflegt werden.
  • RACF bietet zwei Algorithmen zum Verschlüsseln des Passwortes an, den Masking Algorithm und die DES -Verschlüsselung (Data Encryption Standard). Die RACF-Passwörter sollten DES-verschlüsselt werden, da dies einen besseren Schutz bietet als das Masking. Gesteuert wird dies über den RACF-Exit ICHDEX01. RACF-spezifische Empfehlungen sind in M 4.211 Einsatz des z/OS-Sicherheitssystems RACF zu finden.

IPL-Parameter-Datei

In der IPL-Parameter-Datei (Initial Program Load) stehen die wesentlichen Informationen, die zum Initialisieren des z/OS-Betriebssystems benötigt werden. Diese Datei muss über RACF geschützt werden, die Zahl der für diese Datei autorisierten Mitarbeiter muss klein gehalten werden. Es ist jedoch darauf zu achten, dass Vertretungsregeln eingeführt sind.

Parmlib-Definitionen

In den Parameter-Dateien des z/OS-Betriebssystems (SYSn.PARMLIBs, es können mehrere vorhanden sein) werden wesentliche Definitionen des Betriebssystems abgelegt. Alle Parmlib-Dateien sind mittels RACF-Profil zu schützen. Der Zugriff darf nur den Mitarbeitern erlaubt sein, die im Rahmen ihrer Tätigkeit diese Dateien bearbeiten. Es ist zu überlegen, ob verschiedene Parameter-Dateien mit unterschiedlichem RACF-Schutz eingesetzt werden sollen, da in der Parmlib Definitionen mit unterschiedlichem Schutzbedarf existieren. Sicherheitskritische Member der Parmlib sind zum Beispiel (ohne Sortierung):

  • BPXPRMxx
  • CLOCKxx
  • COMMNDxx
  • CSVLLA00
  • IEASYSxx
  • IEFSSNxx
  • IKJTSOxx
  • MSTJCLxx
  • PROGxx
  • SCHEDxx
  • SMFPRMxx

Der Zugriff auf diese Definitionen muss auf die notwendigen Mitarbeiter beschränkt werden. Vertretungsregeln müssen in Kraft sein.

System-Prozeduren

Alle wichtigen Prozeduren der Started Tasks stehen in speziellen Bibliotheken, die entweder über die MSTJCLxx-Definitionen, oder über die JES2/3-Definitionen dem System bekannt gegeben werden. Diese Dateien, z. B. SYS1.PROCLIB, müssen über RACF-Profile geschützt werden, die nur autorisierten Mitarbeitern Zugriff auf die Definitionen gewähren.

Besonders wichtig ist der Schutz von allgemeinen, d. h. von allen Mitarbeitern benutzten Login-Prozeduren, da hier die Gefahr des Missbrauchs besonders groß ist (siehe Maßnahme M 4.213 Absichern des Login-Vorgangs unter z/OS ). Der schreibende/ändernde Zugriff sollte auf die Systemadministratoren beschränkt werden, darüber hinaus benötigt nur JES2/3 einen lesenden Zugriff.

Diese Schutzvorkehrungen gelten auch für alle in allgemeinen Login-Prozeduren verwendeten Script-Dateien (TSO CLISTs oder REXX EXECs), da auch hier die Gefahr des Missbrauchs besonders groß ist.

JESx Definitionen (Job Entry Subsystem)

Zum Schutz der Job Entry Subsysteme JES2 und JES3 müssen hauptsächlich die folgenden Ressourcen durch RACF abgesichert werden:

  • JES-eigene Dateien,
  • Input von anderen Quellen (z. B. anderen Knoten),
  • Jobnamen,
  • System Input/Output auf der JES-Spool und
  • Output für andere Knoten oder Remote Workstations.

Die folgenden RACF-Funktionen sollten eingesetzt werden, um die Sicherheit von JES2/3 zu erhöhen:

  • BATCHALLRACF
    (Erzwingen der Kennung bei Batch-Jobs)
  • EARLYVERIFY
    (nur noch Early Verify möglich)
  • XBMALLRACF
    (Unterstützung des Execution Batch Monitors)
  • NJEUSERID
    (Zuordnung der Default Userid bei Network Job Entry Funktionen)
  • UNDEFINEDUSER
    (Zuordnung der Undefined Userid bei Network Job Entry Funktionen)

Darüber hinaus stellt RACF eine Reihe von General Resource Classes für JES2/3 zur Verfügung, die zum Schutz von JES-Funktionen eingesetzt werden sollten:

  • OPERCMDS
  • JESSPOOL
  • SURROGAT
  • NODES
  • WRITER

Prüffragen:

  • Ist sichergestellt, dass nur Mitarbeiter, zu deren Aufgaben die Wartung des z/OS -Systems gehört, Zugriff zu den APF - und SVC-Dateien haben?

  • Existiert eine Vertreterregelung für die Grundkonfiguration der z/OS -Systeme?

  • Werden im z/OS -System die APF -Dateien regelmäßig auf Veränderungen überprüft?

  • Sind alle APF -Dateien im z/OS -System ohne Extents angelegt?

  • Sind die Ressourcen des z/OS -Betriebssystems über RACF geschützt?

  • Sind die IPL -Parameter-Datei und alle Parmlib-Dateien über RACF im z/OS -System geschützt?

  • Ist der Zugriff auf Parmlib-Dateien im z/OS -System auf die Mitarbeiter begrenzt, die diese Dateien regulär bearbeiten müssen?

  • Sind alle wichtigen System-Prozeduren über RACF -Profile im z/OS -System so geschützt, dass nur autorisierten Mitarbeitern der Zugriff auf die Definitionen möglich ist?

  • Sind die Job Entry Subsysteme JES 2 bzw. JES3 durch RACF geschützt?

Stand: 13. EL Stand 2013