Bundesamt für Sicherheit in der Informationstechnik

M 4.207 Einsatz und Sicherung systemnaher z/OS-Terminals

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

Verantwortlich für Umsetzung: Administrator, Leiter IT

Die Steuerung und Kontrolle eines z/OS-Betriebssystems erfolgt über die HMC-Konsole (Hardware Management Konsole), über verschiedene MCS-Konsolen (Multiple ConsoleSupport), eventuell über Extended MCS-Konsolen und darüber hinaus, falls erforderlich, über Monitor-Konsolen. Weitere Informationen zu den Konsolen finden sich in der Maßnahme M 3.39 Einführung in die zSeries-Plattform .

HMC-Konsolen

HMC-Konsolen sind über ein LAN mit den Support Elements (SEs) des zSeries-Systems verbunden. Sie erlauben sicherheitskritische Eingriffe in die Hardware, den Microcode und die Konfiguration des gesamten z/OS-Systems. Die folgenden Hinweise sind zu beachten:

Voreingestellte IBM-Kennungen

Die mitgelieferten Passwörter der voreingestellten IBM-Kennungen müssen gegen neue Passwörter ausgetauscht werden (dies gilt auch für alle Kennungen von Nicht-IBM-Produkten). Hierbei ist M 2.11 Regelung des Passwortgebrauchs zu beachten.

Schutz der HMC-Konsole

Die HMC-Konsole sollte in einem Raum betrieben werden, der gegen unbefugten Zutritt geschützt ist.

Der Zugang zur HMC-Konsole muss logisch geschützt werden. Für den logischen Schutz sollte die Login-Funktion durch personenbezogene Kennungen mit Passwort gesichert werden.

Der IBM Product Engineering Zugriff ist während der normalen Produktion zu deaktivieren.

Verbindung mit den Support Elements

Die HMC-Konsole sollte über ein dediziertes LAN mit den Support Elements verbunden sein. Wenn ein anderes LAN mitbenutzt wird, sollte eine feste Zuordnung zwischen Support Element und HMC-Konsole definiert werden, z. B. durch entsprechende Einstellung in der Domain-Security-Funktion.

Remote-Anbindung

Wenn die HMC-Konsolen über eine Remote-Anbindung betrieben werden sollen, müssen entsprechende Schutzmaßnahmen für den Remote Access-Zugang vorgesehen werden. In diesem Fall ist Baustein B 4.4 VPN anzuwenden.

Autorisierungs-Modi

Das Personal sollte verschiedenen Autorisierungs-Modi zugeordnet werden. Diese Modi sollten wie folgt eingesetzt werden:

  • Access Administrator
    Dieser Modus ist nur an die Administratoren der HMC-Konsolen zu vergeben. Er darf nicht für normale Benutzer vergeben werden. Dieser Modus sollte nur wenigen Mitarbeitern zur Verfügung stehen.
  • Operator
    Dieser Modus ist den normalen Bedienern zuzuordnen, die z. B. ein zSeries-Betriebssystem starten oder stoppen sollen (Initial Microcode Load oder Initial Program Load).
  • Advanced Operator
    Dieser Modus wird normalerweise nicht benötigt, da die wesentlichen Betriebs-Funktionen in Operator enthalten sind und die anderen Funktionen, wie z. B. Customization, normalerweise unter System Programmer angesiedelt werden.
  • System Programmer
    Dieser Modus sollte nur den Bedienern zugeordnet werden, die als System-Programmierer tätig sind und in dieser Funktion Anpassungen in der HMC-Konsole vornehmen.
  • Service Representative
    Dieser Modus ist nur dem Service-Techniker vorbehalten und darf nicht anderweitig vergeben werden.

Web-Server

Die HMC-Konsole besitzt einen eigenen Web-Server, der einen eingeschränkten Funktionsumfang der HMC-Konsole für den Zugang über einen Web-Browser anbietet. Auf Netzebene sollten alle nicht autorisierten Zugänge zum Web-Server der HMC-Konsole gesperrt werden. Der Web-Server der HMC-Konsole sollte deaktiviert werden, wenn die Web-Schnittstelle zur HMC-Konsole nicht genutzt wird.

Standard-Einstellungen

Die vom Hersteller mitgelieferten Standard-Einstellungen der HMC-Konsole sollten geändert werden, so dass Benutzern nur die Darstellungen zugeordnet werden, die sie für ihre Arbeit auch benötigen (Customize User Control Process in der HMC-Konsole).

Wartungsarbeiten

Es ist eine Vorgehensweise für die Benutzung der HMC-Konsole, bzw. der Support Elements, durch Techniker für Wartungszwecke einzurichten. Es ist sicherzustellen, dass nach Beendigung der Wartungsarbeiten die HMC-Konsole mit einer Betriebskennung aktiviert wird und nicht weiter mit der hoch autorisierten Technikerkennung betrieben wird.

Schulung

Das für den Betrieb der HMC-Konsolen eingesetzte Personal ist für die Benutzung der Konsole zu schulen, besonders in Bezug auf die komplexeren Funktionen. Dadurch sollen gravierende Fehlbedienungen vermieden werden.

Es sollte überlegt werden, ob Übungen an der HMC-Konsole die Sicherheit erhöhen, da die Konsole im Betrieb nur selten benötigt wird.

Support Elements (SEs)

Die Support Elements (zwei IBM Laptops) befinden sich im Gehäuse der zSeries-Hardware und sind mit den Ressourcen der Hardware fest verbunden. Von diesen Support Elements aus können die gleichen Kommandos wie von der HMC-Konsole ausgeführt werden.

Zugang

Der Zugang zu den Support Elements muss physisch geschützt werden. Dies ist in der Regel dadurch gewährleistet, dass die zSeries-Systeme in einem Rechenzentrum betrieben werden, das gegen unbefugten Zutritt geschützt ist. Das Hardware-Schloss der zSeries-Hardware bietet keinen ausreichenden Schutz.

Wartung

Die Support Elements werden auch von den Hardware-Technikern des Herstellers zu Wartungszwecken genutzt. Nach Beendigung der Wartungstätigkeiten sollten die Türen der zSeries-Hardware abgeschlossen und ggf. weitere Sicherheitsmechanismen wieder aktiviert werden.

MCS-Konsolen (Multiple Console Support)

Die MCS-Konsolen (aus historischen Gründen auch immer noch MVS-Konsolen genannt) bieten direkten Zugriff auf das Betriebssystem (MCS mit eigenem Input/Output-Protokoll, SMCS via VTAM seit z/OS V1R1). Die folgenden Sicherheitsmechanismen sind für MCS- und SMCS-Konsolen vorzusehen:

Login

Es ist zu prüfen, ob der Schutz über AUTH-Definition im Member CONSOL00 ausreicht oder ob MCS-Konsolen so definiert werden, dass ein Login mit Kennung und Passwort erforderlich ist, bevor die Konsole benutzt werden kann. Für SMCS-Konsolen, die auch Remote eingesetzt werden, ist ein Login-Vorgang in jedem Fall notwendig.

Physischer Schutz

Wenn kein Login mit Kennung und Passwort für die MCS-Konsole eingerichtet wird, muss sie in einem Raum betrieben werden, der vor unbefugtem Zutritt geschützt ist. Ausgenommen hiervon sind Konsolen, die so definiert sind, dass nur unkritische Display-Funktionen möglich sind.

Da die MCS-Masterkonsole nicht über Kennung und Passwort geschützt werden kann, muss diese Konsole in jedem Fall in einem Raum betrieben werden, der vor unbefugtem Zutritt geschützt ist.

Das z/OS-Betriebssystem macht die erste verfügbare Konsole zur Masterkonsole, soweit keine anderen Definitionen vorliegen. Die Zuordnung der Masterkonsole ist im Member CONSOL00 sovorzunehmen, dass eine physisch geschützte Konsole zur Masterkonsole wird. Eine zweite MCS-Konsole, die durch das automatische Umschalten der primären MCS-Masterkonsole im Fehlerfall zum Master wird, ist auf die gleiche Weise wie die primäre MCS-Masterkonsole zu schützen.

Logischer Schutz

Es muss durch entsprechende Definitionen sichergestellt werden, dass MCS-Konsolen, die in nicht zutrittsgeschützten Räumen betrieben werden, nur von autorisierten Benutzern verwendet werden können. Dies kann über die Konfigurations-Parameter AUTH=xxx oder LOGON=REQUIRED im Member CONSOL00 vorgenommen werden.

Sind die MCS-Konsolen auf andere Weise ausreichend geschützt und wird ein Audit der Operatoren nicht gefordert, kann statt LOGON=REQUIRED auch die Definition LOGON=OPTIONAL im Member CONSOL00 verwendet werden.

Individuelle Autorisierungen

Für MCS-Konsolen mit Login-Prozess sollte überlegt werden, jeder Kennung individuelle Autorisierungen zuzuordnen. Dies ermöglicht die Einteilung in unterschiedliche Operator-Gruppen (siehe M 4.211 Einsatz des z/OS-Sicherheitssystems RACF), was bei der Vorgehensweise ohne Authentisierung nicht möglich ist. Ansonsten stehen die Funktionen der Konsole für jeden offen, der physischen Zugang zur MCS-Konsole hat.

Extended MCS-Konsolen

Über die Extended MCS-Konsole stehen zum Beispiel MCS-Konsolen unter TSO (Time Sharing Option) via System Display and Search Facility (für JES2) oder Flasher (für JES3) zur Verfügung. Für diese Konsolen sollten die folgenden Hinweise beachtet werden:

RACF-Definitionen

Zum Schutz der MVS-Kommandos sind entsprechende RACF-Definitionen (Klasse OPERCMDS) einzusetzen. Ob die Extended MCS-Konsole benutzt werden darf, welche Kennung die Extended MCS-Konsole benutzen darf und welche Kommandos verfügbar sind, muss separat in RACF definiert werden (siehe M 4.211 Einsatz des z/OS-Sicherheitssystems RACF ). In jedem Fall muss sichergestellt sein, dass die Konsol-Services und die dabei verwendeten z/OS-Kommandos nur von Anwendern benutzt werden können, die in RACF entsprechend autorisiert worden sind. Dies gilt für alle Applikationen, die mit Extended MCS-Konsolen arbeiten.

RSF-Konsole (Remote Support Facility)

RSF (Remote Support Facility) ermöglicht es dem zSeries-System, automatisch mit dem Hersteller Verbindung aufzunehmen und den dortigen Technikern Fehler des laufenden Systems zu melden (Hard- und Software). Darüber hinaus erlaubt es die RSF-Funktion prinzipiell auch, dass der Hersteller Microcode-Modifikationen in das System laden kann. RSF ist eine zusätzliche Funktion der HMC-Konsole (Host Management Console) und ist über eine Wählverbindung an das Telefonnetz angeschlossen.

Für die RSF-Funktion sind die folgenden Hinweise zu berücksichtigen:

Grundsätzliche RSF-Überlegung

Es ist zu überlegen, ob eine Funktion wie RSF überhaupt gewünscht wird und welche Teilfunktionen davon benötigt werden. Der Einsatz der Funktion muss mit dem für die Systeme zuständigen Hardware-Support über den Wartungsvertrag abgestimmt werden. RSF (und ähnliche Funktionen bei Festplatten von anderen Herstellern) wird normalerweise für die Fehlererkennung von Hard- und Firmware eingesetzt und erhöht deutlich die Reaktionsfähigkeit auf auftretende Fehler. Ob die Fernwartung durch RSF aktiviert werden soll, muss der Betreiber des Rechenzentrums entscheiden.

Wählverbindung zum Hersteller

Fehlermeldungen werden von der HMC-Seite aus initiiert, dabei wird eine Wählverbindung zum Hersteller aufgebaut. Es ist im Rahmen der Anpassung der HMC-Definitionen sicherzustellen, dass die eingetragene Telefonnummer korrekt ist und nur von autorisiertem Personal geändert werden darf.

Microcode-Anpassung

Wird eine Microcode-Anpassung (oder sonstige Modifikation der Firmware) durch den Hersteller angefordert, so ist der IBM Product Engineering Zugriff für den vereinbarten Zeitraum zu aktivieren. Die Verbindung wird dabei durch Dial-In hergestellt. Nach Ablauf der Wartungsarbeiten ist er wieder zu deaktivieren, um das Missbrauchsrisiko zu minimieren.

Dokumentation

Die RSF-Installation und deren Einsatz ist nachvollziehbar zu dokumentieren.

Prüffragen:

  • Wurden die mitgelieferten Passwörter der voreingestellten IBM-Kennungen des z/OS -Systems gegen neue Passwörter ausgetauscht?

  • Ist der Zutritt und Zugang zur HMC -Konsole, zur MCS-Masterkonsole, zu den (Extended) MCS -Konsolen und zu den Support Elements der zSeries-Systeme angemessen geschützt?

  • Falls ein Remote Access-Zugang zu den HMC -Konsolen im z/OS -System existiert: Ist der Fernzugang angemessen geschützt?

  • Wurde dem Personal für die z/OS -Systeme die Autorisierungs-Modi zugewiesen, die für ihre jeweiligen Aufgaben geeignet sind?

  • Sind auf Netzebene alle nicht autorisierten Zugänge zum Web-Server der HMC -Konsole im z/OS -System gesperrt?

  • Wenn die Web-Schnittstelle zur HMC -Konsole nicht genutzt wird: Wird der Web-Server der HMC-Konsole deaktiviert?

  • Sind den Benutzern für die HMC -Konsole im z/OS -System nur die Darstellungen zugeordnet, die sie für ihre Arbeit auch benötigen?

  • Ist eine Vorgehensweise für die Benutzung der HMC -Konsole bzw. der Support Elements für Wartungszwecke festgelegt?

  • Ist das für den Betrieb der HMC -Konsolen zum z/OS -Systems eingesetzte Personal für die Benutzung der Konsole geschult?

  • Entsprechen die RSF -Einstellungen der zSeries-Systeme den Vorgaben der Institution?

  • Ist die RSF -Installation und deren Einsatz zum zSeries-System nachvollziehbar dokumentiert?

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