Bundesamt für Sicherheit in der Informationstechnik

M 2.293 Wartung von zSeries-Systemen

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

Verantwortlich für Umsetzung: Administrator

Die Maintenance-Konzeption umfasst die Wartung der zSeries-Hardware, des z/OS-Betriebssystems, der verschiedenen Programm-Produkte und die Wartung des zSeries-Microcode (Firmware). Wartung betrifft den kompletten Lebenszyklus eines Produktes, von der Neuinstallation über die permanente Pflege bis hin zum Abbau.

Wartung des zSeries-Hardware

Es ist zu empfehlen, für die Wartung der zSeries-Hardware einen Wartungsvertrag mit dem Hersteller bzw. mit vom Hersteller autorisierten Partnerunternehmen abzuschließen. Wartung kann entweder auf regelmäßiger Basis erfolgen oder wird notwendig, wenn interne Prüfprogramme Fehler entdecken und über RSF (Remote Support Facility) den Hersteller oder seinen Vertreter informieren. Zur Sicherstellung der Funktionsfähigkeit der Hardware (und auch der Basis-Software) ist eine regelmäßige Überprüfung der EREP -Reports (Environmental Record Editing and Printing Program) zu empfehlen. Die im EREP-Report dargestellten Informationen über Hard- und Software-Probleme werden von der Hardware und dem z/OS-Betriebssystem geliefert.

Wartung des z/OS-Betriebssystems

Die Wartung eines z/OS-Systems inklusive aller Subsysteme ist äußerst komplex und bedarf deswegen einer sorgfältigen Planung. Unter den Begriff Wartung fällt:

  • Inbetriebnahme eines neuen Systems
  • Änderungen als Funktionserweiterung oder Nachrüstung von Funktionen
  • Behebung von gemeldeten Fehlern durch sogenannte PTFs (Program Temporary Fixes)
  • Einbau von PTFs als präventive Maßnahme (besonders wichtig sind hier PTFs gegen gemeldete Sicherheitslücken) auf Grund von Herstellerinformationen
  • Abbau von Systemen

Die Wartung von z/OS-Betriebssystemen kann normalerweise nicht ohne Unterbrechung des Betriebs durchgeführt werden.

Bei der Wartung des z/OS-Betriebssystems sind die folgenden Empfehlungen zu berücksichtigen:

Wartungspläne

Es müssen Wartungspläne erstellt werden, in denen festgelegt wird, wann Änderungen am System durchgeführt werden dürfen. Es müssen IPL-Termine (Initial Program Load) festgelegt und Testszenarien erarbeitet werden. Dies muss mit allen Beteiligten abgesprochen werden. Um fehlgeschlagene Änderungen notfalls wieder rückgängig machen zu können, muss ein Rückfall-Konzept erstellt werden.

Change Management

Alle Änderungen an Definitionen des z/OS-Betriebssystems (auch dynamische Änderungen während des produktiven Betriebs) müssen über das Change Management geplant und kontrolliert werden. Dies gilt auch für Neuinstallationen.

Neuinstallation

Eine Neuinstallation wird notwendig, wenn ein z/OS-Betriebssystem erstmalig in Betrieb gehen soll oder wenn eine neue Version (bzw. neues Release) die vorhandene Version ablösen soll. Der Hersteller bietet hier unter dem Begriff CustomPac verschiedene, weitgehend vorbereitete Produkt- und Systemlieferungen an, die teils kostenlos, teils im Rahmen von Wartungsverträgen zur Verfügung stehen.

SystemPac ist ein Teil des CustomPac-Angebotes und erlaubt es, eine weitgehend vorbereitete Lieferung des z/OS-Betriebssystems - gegebenenfalls einschließlich einiger Zusatzprodukte - zu installieren. Zur Neuinstallation ist eine separate Systemumgebung (siehe unten) erforderlich. Durch die Nutzung von SystemPac kann der Aufwand und dadurch auch die Wahrscheinlichkeit von Bedienungsfehlern bei der Neuinstallation erheblich reduziert werden. Es sollte deshalb überlegt werden, bei Neuinstallationen von z/OS auf den SystemPac-Mechanismen zurückzugreifen. Dabei sind auch die Zusatzkosten zu berücksichtigen, die dadurch eventuell anfallen.

Permanente Pflege der Komponenten

Das z/OS-Betriebssystem und seine Programm-Produkte müssen permanent gepflegt werden. Fast alle Hersteller stellen für ihre Programme Patches (im Mainframe-System als PTFs bekannt) zur Verfügung, die Fehler beheben sollen. IBM stellt diese PTFs für das z/OS-Betriebssystem über verschiedene Kanäle zur Verfügung:

  • als Einzellieferung auf Anforderung des Kunden (z. B. auf Grund einer Fehlersituation): hier muss der Anwender die Rahmenbedingungen selbst überprüfen, z. B. die Abhängigkeiten
  • als RefreshPac im Rahmen präventiver Wartung, angepasst an das Kundensystem (von IBM vorgeprüft) oder
  • als OMIS-Lieferung (Online Maintenance Information System). OMIS basiert auf den Daten des Kundensystems und ist ebenfalls von IBM vorgeprüft.

Es ist zu überlegen, ob präventive Wartung zur Erhöhung der Betriebssicherheit notwendig ist, oder ob PTFs nur bei aktuellen Fehlern eingespielt werden sollen. Sicherheitsrelevante Patches sollten in jedem Fall präventiv und zeitnah nach dem Erscheinen eingespielt werden. Dies gilt besonders für Systeme mit Internetzugang. Informationen über sicherheitsrelevante Patches können von IBM angefordert werden.

SMP/E-Wartung

Als zentrales Wartungs-Tool ist SMP/E einzusetzen, das System ModifikationProgram/Extended. Durch die Bestandsführung der Software-Stände im CSI (Consolidated Software Inventory) wird sichergestellt, dass alle Informationen über Module, Versionen und Zusammenhänge des z/OS-Betriebssystems zur Verfügung stehen und damit Fehler bei der Installation der Patches möglichst vermieden werden.

Independent Software Vendors

Software-Produkte von ISVs (Independent Software Vendors) sollten möglichst ebenfalls über SMP/E installiert und gepflegt werden. Es ist zu überlegen, ob ISV-Produkte separat oder im Rahmen des SystemPac-Mechanismus installiert werden sollen.

Consolidated Software Inventory

Es sollte ein CSI für das z/OS-Betriebssystem existieren, bzw. im Falle einer SystemPac-Installation gemäß der Lieferung durch IBM sollte das (die) CSI(s), wie im Ablauf vorgesehen, angelegt werden. Pro Hersteller wird ein separates CSI empfohlen, um Problemen mit Namensgleichheit bei PTFs vorzubeugen.

USERMODS

Eigene Änderungen durch Anwender sollten nur mittels SMP/E installiert werden (als USERMODS). Dies stellt sicher, dass die eigenen Änderungen nicht durch Herstelleränderungen überspielt werden, ohne dass eine Information darüber vorliegt. Sie müssen nach jedem Releasewechsel des Systems bzw. der Module, auf denen die Änderungen aufsetzen, neu installiert und eventuell auch angepasst werden. USERMODS sollten auf ein Minimum begrenzt werden, da sie permanenten Pflegeaufwand nach sich ziehen.

ACCEPT-Läufe

Durch einen ACCEPT-Lauf wird ein PTF permanent im System abgelegt, d. h. es ist nicht mehr entfernbar. Ein ACCEPT-Lauf sollte daher erst stattfinden, wenn sichergestellt ist, dass die PTFs die festgestellten Probleme beseitigen und keine neuen erkennbaren Fehler hervorrufen.

APPLY CHECK

Es ist zu empfehlen, dass vor dem Einbau von PTFs über einen APPLY CHECK SMP/E-Lauf sichergestellt wird, dass die PTFs auch zur aktuell installierten Betriebssystem-Umgebung passen und keine zusätzlichen PTFserforderlich sind (sogenannte Prerequisites oder Corequisites).

Test vor Produktion

Die betriebliche Zuverlässigkeit der gelieferten PTFs sollte erst auf einem Testsystem überprüft werden, bevor die PTFs in ein Produktionssystem eingebaut werden. Bei größeren Wartungsarbeiten (z. B. ein sogenannter Refresh mit hunderten von PTFs) muss dieser Ablauf in jedem Fall vorgesehen werden.

Kumulative Betriebssystemdateien

Es sollten keine Betriebssystemdateien an SMP/E vorbei kopiert werden, da hierdurch die Sicherheit der Wartung beeinträchtigt werden kann. Kumulierte Dateien sind solche, die aus mehreren Dateien zusammengesetzt worden sind. Sollen kumulierte Dateien verwendet werden, muss entweder die Bestandsführung in SMP/E angepasst oder ein separates Verfahren eingesetzt werden, um die Bestandskontrolle gewährleisten zu können. Es ist daher zu überlegen, ob der Mehraufwand gerechtfertigt ist.

Alternative Systemumgebung

Zum Einbau von PTFs sollte eine zweite (alternative) Systemumgebung benutzt werden. Hierfür sollten separate Festplatten mit einer Kopie des Originalsystems verwendet werden. Dies ermöglicht ein problemloses Einbauen während der Betriebszeiten und erlaubt ein schnelles IPL (Initial Program Load) von der veränderten System Residence (der Festplatte, von der der Boot-Vorgang eingeleitet wird). Darüber hinaus unterstützt diese Vorgehensweise (Flip-Flop-Verfahren) den schnellen Fallback, da die Festplatten der vorher aktiven Betriebssystemkomponenten noch zur Verfügung stehen.

System-Cloning

Unter System-Cloning versteht man das Kopieren der Betriebssystem-Komponenten auf einen neuen Festplatten-Satz unter Berücksichtigung der zu ändernden Definitionen. Es ist zu überlegen, ob ein Verfahren zum System-Cloning etabliert wird, um alternative System-Umgebungen schnell und sicher aufbauen zu können.

Ein solches Verfahren muss eigenständig erstellt werden, z. B. in Form eines Batch-Jobs mit mehreren Schritten. Die Benutzung von System-Variablen hilft hier wesentlich.

Einsatz symbolischer System-Variablen

Bei den z/OS-Parameter-Dateien sollte, soweit möglich, mit symbolischen Variablen gearbeitet werden. Dies vereinfacht das System-Cloning erheblich und vermeidet vielfach auch Fehldefinitionen. Ab dem z/OS-Betriebssystem V1R4 stehen bis zu 800 Variablen zur Verfügung.

Dokumentation

Es ist zu überlegen, ob ein Berichtswesen, basierend auf SMP/E, aufgebaut werden sollte, um jederzeit den aktuellen Stand der gesamten Software des Betriebssystems darstellen zu können.

Wartung des zSeries-Microcode (Firmware)

Zur Behebung von Code-Fehlern in der Firmware, zum Firmware-Update auf neue Versionen und zur Aktivierung oder Deaktivierung von Hardware-Komponenten (z. B. Prozessoren, Krypto-Hardware) werden von den Herstellern Microcode-Updates durchgeführt. Hierfür müssen folgende Hinweise beachtet werden:

Betreiberkontrolle

Updates durch den Hersteller dürfen nur nach Absprache mit dem Betreiber der zSeries-Systeme und nur unter Kontrolle von Mitarbeitern des Betreibers durchgeführt werden.

Hersteller-Erklärung

Der Hersteller der Betriebssystem-Software sollte eine Vertraulichkeits-Erklärung ausstellen.

Remote Wartung

Der externe Zugang (Remote Access) ist, wie in Baustein B 4.4 VPN und speziell in Maßnahme M 4.207 Einsatz und Sicherung systemnaher z/OS-Terminals beschrieben, zu schützen. Es muss sichergestellt werden, dass Änderungen an Firmware-Komponenten nur nach Abstimmung mit dem zSeries-Systembetreiber erfolgen.

Abbau des z/OS-Betriebssystems

Weiterführende Informationen zu dem Abbau eines z/OS-Betriebssystems sind unter M 2.297 Deinstallation von z/OS-Systemen zu finden.

Prüffragen:

  • Existieren Wartungspläne mit festgelegten Zeitfenstern für Änderungen an zSeries-Systemen?

  • Sind für die z/OS-Systeme IPL-Termine festgelegt und Testszenarien erarbeitet, die mit allen Beteiligten abgestimmt sind?

  • Existiert ein Rückfall-Konzept, um fehlgeschlagene Änderungen des z/OS-Systems wieder rückgängig machen zu können?

  • Werden alle, auch die dynamischen, Änderungen an Definitionen des z/OS-Betriebssystems über das Change Management geplant und kontrolliert?

  • Wird SMP/E als zentrales Wartungs-Tool für z/OS-Systeme eingesetzt?

  • Bei Nutzung des System-Cloning: Wird bei den z/OS-Parameter-Dateien, soweit möglich, mit symbolischen Variablen gearbeitet?

  • Ist sichergestellt, dass Updates durch den Hersteller nur nach Absprache mit dem Betreiber der zSeries-Systeme und nur unter Kontrolle von Mitarbeitern des Betreibers durchgeführt werden?

Stand: 13. EL Stand 2013