Bundesamt für Sicherheit in der Informationstechnik

M 6.93 Notfallvorsorge für z/OS-Systeme

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

Verantwortlich für Umsetzung: Administrator

Zu einem sicheren z/OS-Betrieb gehört es, für verschiedene Notfälle vorbereitet zu sein. Dazu zählen z. B.

  • ein Notuser-Verfahren, das notwendig wird, wenn keine Kennung mehr mit bestimmter Funktionalität verfügbar ist,
  • ein Verfahren zur Wiederherstellung einer funktionierenden RACF-Datenbank,
  • ein z/OS-Backup-System, das sofort aktiviert werden kann und
  • ein Notfall-System, das bei Einzelsystemen u. U. benötigt wird, um Fehlerkorrekturen vornehmen zu können.

Die verschiedenen Handlungsempfehlungen zur Notfallvorsorge sind nachfolgend näher beschrieben:

Notuser-Verfahren

Zur Notfallvorsorge muss ein Notuser-Verfahren eingerichtet werden. Dieser Notuser kann verwendet werden, falls in einer Notsituation kein RACF-Administrator (Resource AccessControl Facility) zur Verfügung steht, bzw. falls alle Kennungen mit SPECIAL-Rechten gesperrt sind. Es können eine oder mehrere Notuser-Kennungen eingerichtet werden.

Es sind folgende Regeln zu beachten:

Zugang zur Notuser-Kennung

Da die Notuser-Kennung sehr hohe Berechtigungen (SPECIAL) im System besitzt, muss die Herausgabe der Notuser-Kennung restriktiv gehandhabt werden.

Der Notuser darf nur vorher festgelegten Personen zugänglich sein. Er sollte nur RACF-Administratoren und Systemprogrammierern mit RACF-Ausbildung zur Verfügung stehen.

Meldung und Dokumentation der Verwendung des Notusers

Bei Verwendung des Notusers sind sobald als möglich die RACF-Administration, der Auditor und das Sicherheitsmanagement zu unterrichten. Folgende Informationen müssen gemeldet werden:

  • Wer hat den Notuser benutzt?
  • Weshalb wurde der Notuser benötigt?
  • Wann erfolgte der Zugriff?
  • Was wurde mit der Berechtigung des Notuser durchgeführt?

Alle Vorgänge zur Notuser-Kennung sind nachvollziehbar zu dokumentieren und zu archivieren.

Passwort der Notuser-Kennung

Beim Login mit der Notuser-Kennung ist das Passwort durch den Benutzer sofort auf ein neues zu ändern. Dies wird durch RACF erzwungen, wenn der Notuser mit einem neuen Initial-Passwort versehen wurde.

Nach dem Gebrauch der Notuser-Kennung muss das zugehörige Passwort durch die RACF-Administration wieder neu gesetzt und hinterlegt werden.

Missbrauch des Notuser-Verfahrens

Das Notuser-Verfahren darf nicht zur Berechtigungserweiterung im Nicht-Notfall missbraucht werden. Es muss verhindert werden, dass der Notuser aus Bequemlichkeit verwendet wird, um definierte Administrations- und Entscheidungswege zu umgehen.

Verhindern der Notuser-Sperrung

Alle Kennungen können nach einer vorgegebenen Zeit wegen Inaktivität gesperrt werden. Die entsprechende Einstellung erfolgt in den SETROPTS-Parametern von RACF. Eine solche Sperrung kann auch Notuser-Kennungen betreffen, wenn diese längere Zeit nicht verwendet werden. Es ist zu überlegen, diese automatische Sperrung durch den Einsatz eines Batch-Jobs zu verhindern. Der Batch-Job sollte regelmäßig die Notuser-Kennungen benutzen (z. B. einmal im Monat). Dadurch werden die Zeitstempel in der RACF-Datenbank aktualisiert. Dieser Batch-Job kann über einen Job-Scheduler initiiert werden. Es muss sichergestellt werden, dass das Passwort des Notusers außer den explizit hierzu autorisierten Mitarbeitern niemandem bekannt wird. Hierfür sollte die RACF-Klasse SURROGAT zum Einsatz kommen, damit kein Passwort in die Job Control Language eingestellt werden muss.

Verfahren zur Wiederherstellung von z/OS-RACF-Datenbanken

Die RACF-Datenbank ist der wichtigste und zentrale Speicherort für die Sicherheitseinstellungen eines z/OS-Systems. Soll ein sicherer Betrieb gewährleistet werden, muss die RACF-Datenbank korrekt funktionieren. Um Problemen durch nicht zur Verfügung stehende oder defekte RACF-Datenbanken zu begegnen, sind die folgenden Empfehlungen zu beachten:

Sicherung der RACF-Datenbanken

Es ist wichtig, dass die Synchronisierung der RACF-Datenbanken einwandfrei funktioniert. Deshalb muss zur Sicherung aktiver Datenbanken (die Datenbanken, die beim RVARY-Display als aktiv gekennzeichnet sind) immer entweder das RACF-Utility IRRUT200 (von IBM empfohlen) oder IRRUT400 eingesetzt werden.

Während der Sicherung werden zahlreiche LOCK-Funktionen ausgeführt. Deshalb sollte der Batch-Job, der die Sicherung durchführt, in ein Zeitfenster mit möglichst geringer Auslastung gelegt werden.

Die Sicherungen dürfen nicht auf der gleichen Festplatte gespeichert werden, auf der die RACF-Datenbanken im Betrieb liegen.

Es sollte überlegt werden, mehrere Generationen der Sicherungen aufzubewahren. Dabei ist das Wochenende mit zu berücksichtigen.

Die Sicherungskopien der Datenbanken sind - ebenso wie die RACF-Datenbanken selbst - über entsprechende RACF-Profile zu schützen (siehe M 4.211 Einsatz des z/OS-Sicherheitssystems RACF ).

RACF-Datenbankwiederherstellung

Im z/OS-System gibt es eine Primary und eine Backup RACF-Datenbank. Diese können im Betrieb umgeschaltet werden. Aus Sicherheitsgründen sind die beiden Datenbanken auf verschiedenen Platten zu speichern. Treten Fehler in der Primary Datenbank auf, so kann durch ein RVARY SWITCH Kommando die Backup zur Primary und die Primary zur Backup RACF-Datenbank gemacht werden. Die defekte Backup RACF-Datenbank kann daraufhin in der Regel gelöscht und durch eine neue ersetzt werden.

Sind beide RACF-Datenbanken fehlerhaft, so ist es in diesem Notfall möglich, die defekte RACF-Datenbank durch eine gültige Sicherungskopie zu ersetzen und hierdurch den Systembetrieb wieder herzustellen (u. U. von einem anderen System aus). Bei Einzelsystemen ist hierfür eventuell ein Notfallsystem notwendig (siehe unten: Erstellung eines z/OS-Notfallsystems).

Nachvollziehbarkeit im Fehlerfall

Es ist ein Verfahren zur Sicherung und zum Zurückspielen der RACF-Datenbank einzurichten.

Es ist ein Verfahren einzurichten, so dass Änderungen in der RACF-Datenbank in der Zeit zwischen der letzten Sicherung der RACF-Datenbank und dem Zeitpunkt des eingetretenen Notfalls nachvollzogen werden können. Eine Möglichkeit hierfür ist beispielsweise, dass RACF-Änderungen nur durch dokumentierte Batch-Jobs durchgeführt werden dürfen. Eine andere Möglichkeit ist, dass direkt nach RACF-Änderungen die SMF-Datensätze ausgewertet werden. Beide Verfahren müssen nachvollziehbar dokumentiert sein. Die Dokumentation muss den Administratoren vorliegen.

z/OS-Backup-System

Bei Systemfehlern, bei denen das z/OS-System (oder auch ein kompletter Parallel Sysplex Cluster) nicht mehr gestartet werden kann, ist es wichtig, möglichst schnell das System bzw. die Systeme wieder in einen betriebsbereiten Zustand zu bringen. Solche Ausfälle können beispielsweise auf Grund eines technischen Fehlers oder auch auf Grund fehlerhafter manueller Eingaben vorkommen. Deshalb sollte ein separater Satz von Festplatten vorgehalten werden, der eine Kopie des aktuellen Betriebssystems enthält. Durch einfache Änderung der IPL-Adresse (Initial Program Load) kann auf diese Weise ein z/OS-Betriebssystem in den meisten Fällen schnell reaktiviert werden. Die folgenden Empfehlungen sind dabei zu beachten:

Festplatten-Konzept

Das Festplatten-Konzept für das z/OS-Betriebssystem und die dazugehörenden Programmprodukte (wie Scheduler, Output-Manager und weitere) muss logisch aufgebaut und klar erkennbar sein. Zusammengehörende Dateien, z. B. des Betriebssystems, dürfen nicht verteilt auf viele unterschiedliche Festplatten gespeichert werden. Es sollten möglichst wenig Festplatten verwendet werden, damit relativ einfach vollständige Sicherungen erstellt werden können.

Cloning-Prozess

Für das Erstellen der Backup-Festplatten sollte ein Cloning-Prozess entwickelt werden, der mindestens die folgenden Aktionen durchführt:

  • Kopieren der System-Residenzen,
  • Kopieren der Programmprodukt-Festplatten,
  • Kopieren der HFS-Festplatten (Hierarchical File System),
  • Kopieren der SMP/E-Festplatten (System Modification Program),
  • Verändern der Volume-Angaben in SMP/E durch die ZONEEDIT-Funktion (alte Volume-Angabe durch neue ersetzen) und
  • Anpassen der Volume-Angabe im Member IEASYMnn der Parmlib.

Wartungskonzeption

Um den laufenden Betrieb nicht zu gefährden, wird zur Pflege des z/OS-Betriebssystems in der Regel ein separater Festplattensatz verwendet. Es ist zu überlegen, diesen nach erfolgter Wartung als neuen aktiven Plattensatz und die vorherigen Platten als Backup-Satz zu benutzen.

Einsatz von System-Variablen

Zur Erleichterung der Definitionen sollten, wo immer technisch möglich und sinnvoll, symbolische Variablen benutzt werden (ab z/OS 1.4 sind bis zu 800 solcher Variablen definierbar). Es sollte überlegt werden, die Katalogeinträge des Masterkatalogs und dessen ALIAS-Einträge über solche Techniken variabel zu gestalten, damit ein Wechsel ohne zusätzliche Eingriffe jederzeit möglich ist. Die Benutzung symbolischer Variablen ist in vielen Definitionen möglich, es sollte jedoch berücksichtigt werden, dass einige Definitionen die Variablen noch nicht unterstützen.

Führung von Arbeitsdateien

Um unnötigen Wartungsaufwand zu vermeiden, sollten Arbeitsdateien, wie Kataloge, Parmlibs, Proclibs und Datenbanken von Programmprodukten, nicht doppelt oder sogar mehrfach geführt werden.

Erstellung eines z/OS-Notfallsystems

Durch Fehler in maßgeblichen Software-Komponenten, z. B. RACF (Resource Access Control Facility) oder Master-Katalog, kann es vorkommen, dass das gesamte System ausfällt. Bei Einzelsystemen muss für diesen Fall kurzfristig ein Notfallsystem zur Verfügung stehen, das ohne große Probleme gestartet werden kann und eine Reparatur des defekten Systems ermöglicht.

Im Gegensatz zu Backup-Systemen ist das Notfallsystem nicht für den Produktivbetrieb gedacht. Bei der Erstellung von Notfallsystemen sind die folgenden Hinweise zu berücksichtigen:

Unabhängigkeit

Das Notfallsystem muss komplett unabhängig von den Dateien und Definitionen der Produktionssysteme eingerichtet werden.

Reduktion auf das Wesentliche

Das Notfallsystem sollte nicht mehr Software-Funktionen enthalten, als unbedingt für eine Reparatur notwendig sind, damit für das System nicht mehr als eine Festplatte benötigt wird. Dazu gehören die Programme JESx (Job EntrySubsystem), VTAM (Virtual Telecommunication Access Method) und TSO (Time Sharing Option) mit den dazugehörenden ISPF-Dateien (Interactive Support Programming Facility). Es ist zu überlegen, ob ein System ohne JES ausreicht. Dann können jedoch keine Batch-Jobs eingesetzt werden.

Volume-Angaben

Alle Prozeduren sind mit Volume-Angaben zu versehen, um Abhängigkeiten von Katalogen zu vermeiden. Es sollten deshalb auch keine SMS-Dateien (System Managed Storage) verwendet werden.

VTAM-Terminals

Es muss eine möglichst einfache VTAM-Prozedur angelegt werden, bei der mindestens ein VTAM Local Node vorgesehen ist, der die Adresse einer MCS-Konsole (Multiple ConsoleSupport) beinhaltet. Damit ist es möglich, eine VTAM-Verbindung aufzubauen und sich an dem defekten System anzumelden. Bei Änderungen in den VTAM-Konfigurationen ist die Definition des VTAM Local Node entsprechend zu aktualisieren.

Komponenten des Notfall-Systems

Das Notfallsystem sollte auf einer Festplatte liegen, die mindestens die folgenden Dateien und Komponenten enthält:

  • IPL-Text,
  • Master-Katalog,
  • JESx-Checkpoint und Spool-Datei,
  • Page-Dataset,
  • System-Dateien (MANx, STGINDEX, LOGREC, DAE),
  • Parmlib, Proclib (Logon-Prozedur nicht vergessen),
  • SMF-Dateien (SYS1.MANx),
  • BROADCAST- und UADS-Dateien und
  • RACF-Datenbank.

User-IDs für den Notfall

Es müssen mindestens zwei User-IDs auf dem Notfallsystem vorhanden sein, die wie die Notuser behandelt werden.

Permanente Pflege

Der Zutritt und der Zugang zum Notfallsystem müssen geschützt werden. Änderungen im normalen System müssen zeitnah auf dem Notfallsystem nachvollzogen werden, falls sie für das Notfallsystem relevant sind. Die Funktionsfähigkeit des Notfallsystems ist in periodischen Zeitabständen zu überprüfen.

Prüffragen:

  • Ist für das z/OS -System ein Notuser-Verfahren eingerichtet?

  • Werden bei der Notfallvorsorge für das z/OS -System alle Vorgänge zur Notuser-Kennung nachvollziehbar dokumetiert und archiviert?

  • Werden Sicherungskopien der Datenbanken ebenso wie die RACF -Datenbanken selbst über entsprechende RACF -Profile geschützt?

  • Ist ein Verfahren zur Sicherung und zum Zurückspielen der RACF -Datenbank eingerichtet?

  • Wird ein z/OS -Backup-System auf einem separaten Satz von Festplatten vorgehalten, der eine Kopie des aktuellen Betriebssystem enthält?

  • Wird bei Einzelsystemen ein z/OS -Notfallsystem eingerichtet?

Stand: 13. EL Stand 2013

Hinweis zur Verwendung von Cookies

Um unsere Webseite für Sie optimal zu gestalten und fortlaufend verbessern zu können, verwenden wir Cookies. Durch die weitere Nutzung der Webseite stimmen Sie der Verwendung von Cookies zu. Weitere Informationen hierzu erhalten Sie in unserer Datenschutzerklärung.

OK