Bundesamt für Sicherheit in der Informationstechnik

M 2.296 Grundsätzliche Überlegungen zu z/OS-Transaktionsmonitoren

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

Verantwortlich für Umsetzung: Administrator

Der Einsatz von Transaktionsmonitoren muss detailliert geplant und durch geeignete Mechanismen abgesichert werden. Als Hilfestellung werden in dieser Maßnahme einige Empfehlungen im Überblick beschrieben, die sich aus Sicht der Informationssicherheit beim Betrieb von Transaktionsmonitoren bewährt haben. Je nach Einsatzszenario sind in der Regel weitere spezifische Planungen und Sicherheitsmechanismen erforderlich, die hier nicht dargestellt werden können. Insbesondere wird in dieser Maßnahme nicht der Datenbankteil von IMS betrachtet.

Transaktionsmonitore werden auf Mainframe-Systemen für den Online-Betrieb eingesetzt. Sie ermöglichen den Anwendern, im Dialogbetrieb auf die gewünschten Daten über nachgeschaltete Datenbanksysteme zuzugreifen. Dabei gehört es zu den Kernaufgaben des Transaktionsmonitors sicherzustellen, dass die folgenden Bedingungen erfüllt werden:

  • Eine Transaktion muss immer komplett durchgeführt werden. Ist das nicht realisierbar, muss das System auf den vorherigen Stand zurückgesetzt werden (Roll-Back).
  • Das System sollte sich vor und nach der Transaktion in einem konsistenten Zustand befinden, ansonsten muss das System zurückgesetzt werden.
  • Jeder Anwender soll nur Zugriff auf seine Daten erhalten und sollte isoliert sein von allen anderen Daten.
  • Nach Durchführung der Transaktion muss sichergestellt werden, dass der veränderte Zustand gespeichert wird und später in der gleichen Form zur Verfügung steht. Im Falle eines Systemausfalls müssen die noch nicht gespeicherten Transaktionen notfalls automatisch wiederholt werden.

Diese Bedingungen gelten sowohl für den Online-Betrieb, als auch für Transaktionen, die im Batch-Betrieb durchgeführt werden.

Transaktionsmonitore werden heute üblicherweise in einer sogenannten Drei-Tier-Konfiguration (Tier = Stufen) eingesetzt (Präsentation, Anwendungslogik, Datenhaltung) und decken normalerweise die folgenden Kernfunktionen ab:

  • Message Queuing (Verwalten des Nachrichten-Flusses)
  • Lock-Verwaltung (Verwaltung der Zugriffe und gegenseitige Absicherung)
  • Logging (Verwaltung der Log-Funktionen)
  • Roll-Back Funktionen (Zurückspringen auf den vorherigen Zustand)
  • Laststeuerung (Load Balancing)
  • Two-Phase Commit-Synchronisation (stellt sicher, dass eine Transaktion komplett durchgeführt wird oder ein Roll-Back erfolgt)

Als Transaktionsmonitor wird u. a. IMS TM (Information Management System Transaction Monitor) oder CICS (Customer Information Control System) eingesetzt. Als Datenbanksystem steht für IMS der IMS-eigene DB-Teil, VSAM-Datenbanken (Virtual System Access Method) oder DB2 (Database 2) zur Verfügung. Für CICS können VSAM, IMS DB oder DB2 als Datenbanksysteme eingesetzt werden.

Auch wenn die Transaktionsmonitore und Datenbanksysteme aus historischen Gründen eigene interne Schutzsysteme zum Teil noch anbieten, wird in der heutigen Zeit meistens ergänzend ein Sicherheitssystem wie RACF (Resource AccessControl Facility) eingesetzt. Mit RACF können die Authentisierung des Benutzers, der Schutz der Transaktionen und der Zugriffsschutz auf Datenelemente realisiert werden.

Allgemeine Überlegungen

Die Transaktionsmonitore IMS TM und CICS sind von der historischen Entwicklung her reine VTAM-Applikationen. Sie waren zu Beginn der Entwicklung für interne Netze konzipiert. Im Laufe der letzten Jahre sind jedoch durch die steigende Bedeutung des Internets erweiterte Schnittstellen bereitgestellt worden. Diese ermöglichen es, Zugriffe auf Anwendungen dieser Transaktionsmonitore auch vom Internet aus zu erlauben.

Die folgenden Empfehlungen gelten für den gesamten Bereich der Transaktionsmonitore und schließen die Datenbanken mit ein:

  • Alle Sicherheitsmechanismen sollten möglichst durch RACF gesteuert werden. Die internen Sicherheitsmechanismen sind nur dort zu benutzen, wo es keine adäquaten RACF-Funktionen gibt.
  • Es sollten vor Inbetriebnahme eines Transaktionsmonitors, wie IMS oder CICS, oder eines Datenbanksystems, wie DB2, Standards für alle relevanten Definitionen entwickelt werden. Die Standards sollten Transaktionsnamen, Tabellennamen, Resource Classes, etc. betreffen. Solche Standards helfen dabei, Fehler bei RACF-Definitionen zu vermeiden (siehe M 2.285 Festlegung von Standards für z/OS-Systemdefinitionen ).
  • Sicherheitsmechanismen sollten bei Transaktionsmonitoren immer so aktiviert werden, dass das entsprechende Regelwerk extern definiert werden kann. Der Einsatz externer Sicherheitsfunktionen, wie RACF-Definitionen, sollte immer eventuell vorhandenen internen Funktionen vorgezogen werden.

IMS TM (Transaction Monitor, vorher DC genannt)

Die folgenden Empfehlungen gelten für den IMS Transaktionsmonitor. Je nach Einsatzszenario sind in der Regel weitere Sicherheitsmechanismen erforderlich.

  • IMS sollte über die Definition im IMS Security Makro so eingestellt werden, dass IMS RACF verwendet (Parameter TYPE = RACFAGN / RACFTERM / RACFCOM). Das IMS System muss durch die RCLASS Definition so definiert werden, dass dieser Name (die IMS-ID) in RACF als Resource Class geführt werden kann. Ist mehr als ein IMS im z/OS-System in Betrieb, sollte überlegt werden, ob die standardmäßig in RACF vorhandenen Namen benutzt werden sollen (z. B. AIMS, TIMS usw.) oder ob eigene (unterschiedliche) Namen vergeben werden sollten. Bei der Benutzung von eigenen Namen müssen diese als Resource Classes in RACF eingetragen werden.
    Über das IMS Security Makro können u. a. die folgenden Prüfungen aktiviert werden (Benutzung der Default IMS-ID IMS):
    • AGN Prüfung über RACF (über Klasse AIMS), Ablegen der gültigen User-IDs für IMS in RACF (RDEFINE)
    • Transaktions-Autorisierung (über Klasse TIMS oder GIMS und SECLVL=TRANAUTH im Security Makro)
    • Terminal Security (SECLVL=SIGNON / FORCSIGN im Security Macro und Resource Class TERMINAL in RACF)
    • Kommando Autorisierung (über Klasse CIMS oder DIMS)
    Existiert ein Parallel Sysplex mit Datasharing, sollte als RCLASS Wert die IMS-ID des Master-IMS benutzt werden.
  • Es sollte überlegt werden, ob zur Signon Verifizierung ein Exit (DFSSGNX0) eingesetzt werden sollte (falls die RACF Prüfung nicht ausreichend granular ist).
  • Es müssen in RACF Standard Profile für die einzelnen Resource Classes eingerichtet werden, zu denen die Applikations-Anwender zugelassen werden können. Es ist empfehlenswert, vor Beginn der Definitionen Standards zu entwickeln, die die Definitionen erleichtern.
  • Es sollte überlegt werden, ob die Sicherheitsanforderungen eine Terminal-Security über RACF notwendig machen (Class Terminal). Vorsicht ist geboten bei Einführung eines restriktiven Schutzes gegen nicht definierte Terminals, z. B. mit dem RACF Kommando SETROPTS TERMINAL(NONE): Es müssen mindestens einige Terminals für die Benutzung von RACF unter TSO freigeschaltet sein, da sich sonst niemand mehr auf dem System anmelden kann!
  • Das Mapping von RACF-Resource Classes auf die internen IMS Security Regeln erfolgt über Definitionen, die über den SMU-Prozess (Security Management Utility) verarbeitet werden. Aus der Definitionsdatei wird über einen Preprocessor und nachfolgendem Assembly und Link ein Loadmodule erzeugt, das auf dem IMS Matrix Dataset gestellt wird und in dem u. a. die IMS Security Definitionen in Kontrollblockform zur Verfügung stehen. Die Datei des Quellcodes darf nur von Mitarbeitern zugreifbar sein, die diese Datei im Rahmen ihrer Tätigkeit benötigen.
  • Zugriffe auf IMS aus dem TCP/IP-Netz (z. B. aus dem Internet) erfolgen über die OTMA-Schnittstelle (OpenTransaction ManagerAccess). Zur Absicherung dieser Verbindung muss über den Parameter OTMASE=xxx mindestens CHECK (besser FULL) sichergestellt werden, dass RACF zur Verifizierung eingesetzt wird. IMS Kommandos werden dabei gegen die Klasse CIMS, Transaktionen gegen TIMS geprüft. Die Gültigkeit der Verbindung sollte über Profile in der FACILITY Klasse in RACF sichergestellt werden.
  • Es ist zu überlegen, ob die IMS Programme (Control Region, Message Processing Region, Utilities) zur Erhöhung der Sicherheit über die RACF Klasse Program geschützt werden sollen.
  • Die IMS Dateien müssen über RACF Dataset Profile so geschützt werden, dass nur Mitarbeiter Zugriff zu den Dateien haben, die sie im Rahmen ihrer Tätigkeit auch benötigen. Anwender von IMS benötigen keinen Zugriff auf die IMS Dateien. Zu schützende Dateien sind z. B.
    • APF -Dateien (Authorized Programming Facility)
    • System-Dateien
    • Anwender-Dateien wie z. B. PSB-, DBD-, ACB- und PGM-LIB
    Der Zugriff auf APF- und System-Dateien darf nur für die STC-User-IDs (Started Task Control) und autorisierte Mitarbeiter freigegeben werden. Normale Anwender benötigen keinen Zugriff auf diese Dateien (siehe auch M 4.209 Sichere Grundkonfiguration von z/OS-Systemen ).
    Der Zugriffsschutz von Anwender-Dateien muss durch RACF Definitionen erfolgen (siehe M 4.211 Einsatz des z/OS-Sicherheitssystems RACF ).
  • MVS Kommandos für IMS sollten über RACF geschützt werden (siehe M 4.211 Einsatz des z/OS-Sicherheitssystems RACF ).
  • Die Started Tasks sollten über die RACF Klasse STARTED abgesichert werden (siehe M 4.211 Einsatz des z/OS-Sicherheitssystems RACF ).
  • Bei besonders hohen Sicherheitsanforderungen an IMS kann auch der Zugang zur IMS Kontroll-Region generell durch die RACF Resource Class APPL auf der Basis des VTAM LU-Namens abgesichert werden. Da jeder Anwender hierbei entweder als einzelner User oder in Gruppen definiert werden muss, ist zu beachten, dass dadurch ein erhöhter Administrationsaufwand entsteht. Dies gilt besonders für Installationen mit vielen Anwendern.

CICS

Die folgenden Empfehlungen gelten für den CICS Transaktionsmonitor. Je nach Einsatzszenario sind in der Regel zusätzliche Sicherheitsmechanismen erforderlich. Weitere Informationen sind in der IBM Dokumentation CICS RACF Security Guide zu finden:

  • Sollen die CICS-Regions im Modus Non-Swappable laufen (PPT-Eintrag im SCHEDnn Parmlib-Member), muss sichergestellt werden, dass die Option NOPASS für das Modul DFHSIP im PPT-Eintrag (Program Property Table) nicht gesetzt wird. Die Option NOPASS umgeht Passwort- und RACF-Prüfungen.
  • Die Started Task User-IDs müssen so definiert werden, wie M 4.211 Einsatz des z/OS-Sicherheitssystems RACF beschrieben ist. Die User-IDs von CICS Started Tasks dürfen nicht das Attribut OPERATIONS besitzen.
  • Die CICS Dateien müssen über RACF Dataset Profile so geschützt werden, dass nur Mitarbeiter Zugriff auf die Dateien haben, die sie im Rahmen ihrer Tätigkeit auch benötigen. Zu schützende Dateien sind z. B.
    • APF-Dateien (Authorized Programming Facility)
    • System-Dateien
    • Anwender-Dateien wie z. B. PSB-, DBD-, ACB- und PGM-LIB
  • Der Zugriff auf APF- und System-Dateien darf nur für die STC-User-IDs (Started Task Control) und autorisierte Mitarbeiter freigegeben werden. Normale Anwender benötigen keinen Zugriff auf diese Dateien (siehe auch in M 4.209 Sichere Grundkonfiguration von z/OS-Systemen ).
    Der Zugriff auf Anwender-Dateien muss im Rahmen der RACF Regeln erfolgen (siehe M 4.211 Einsatz des z/OS-Sicherheitssystems RACF ).
  • MVS Kommandos für CICS sollten über RACF geschützt werden (siehe M 4.211 Einsatz des z/OS-Sicherheitssystems RACF ).
  • Die Aktivierung von RACF für die CICS-Security erfolgt in der SIT (System Initialization Table) durch Setzen des Parameters SEC=YES. In der SIT kann auch definiert werden, ob Transaktionsschutz, Programmschutz oder Feldschutz von Eingabemasken über RACF aktiviert werden soll. Es muss sichergestellt werden, dass diese Modifikationen nur von autorisierten Mitarbeitern durchgeführt werden können. Dabei ist zu beachten, dass die Auswahl der SIT sowohl über SYSIN Eingabe als auch über einen Parameter im EXEC Statement der Prozedur (in der Job Control Language) definiert werden kann. Das SIT-Modul muss in eine APF-Bibliothek eingestellt und über RACF Profile so geschützt werden, dass nur die für diesen Bereich zuständigen Mitarbeiter Zugriff haben (siehe M 4.211 Einsatz des z/OS-Sicherheitssystems RACF ). Auch die Quell-Datei der SIT darf nur zugreifbar sein für die dazu befugten Mitarbeiter und muss mit entsprechenden RACF Dateiprofilen geschützt werden.
  • Die Kommando Security muss bei der Definition der Transaktionen eingeschaltet sein (CMDSEC Parameter). Es ist zu überlegen, ob durch SECPRFX=YES die Systeme voneinander unterschieden werden sollen. Dies ist empfehlenswert bei verschiedenen CICS-Jobs in einem System.
  • Die Prozeduren der CICS Regions stehen auf einer (oder mehreren) Prozedur-Bibliothek(en). Diese müssen durch RACF so geschützt werden, dass nur Mitarbeiter diese Prozeduren verändern können, die im Rahmen ihrer Tätigkeit darauf Zugriff haben müssen. Es ist zu überlegen, ob eine separate PROCLIB (mit entsprechender Verknüpfung zu den anderen PROCLIBs) das Sicherheitsniveau erhöht und das Missbrauchsrisiko durch getrennte Zugriffsdefinitionen dadurch verringert werden kann.
  • Die Anmeldung an CICS muss über die Eingabe von RACF User-ID und Passwort erfolgen. Es ist zu empfehlen, eine Signon-Maske für die Anmeldung an CICS vorzusehen. Für jede CICS Region muss daher ein Default-User in RACF definiert sein. Die in der Default-User-ID im CICS-Segment definierten Vorgaben werden von CICS für alle Terminal Sessions verwendet, bis ein Signon mit der persönlichen User-ID durchgeführt wurde. Es wird empfohlen, die Default-User-ID nur mit sehr geringen Rechten auszustatten.
  • Die General Resource Classes Txxxxxxx (Member Class) und Gxxxxxxx (Group Class) sollten für Transaktionssicherheit, die Klassen Cxxxxxxx (Member Class) und Vxxxxxxx (Group Class) für Kommando Sicherheit aktiviert werden (über das Kommando SETROPTS).
  • Sicherheitsmechanismen in der Anwendung (Applikation) sollten nur dort implementiert werden, wo keine adäquaten Sicherheitsfunktionen von RACF oder anderen Sicherheitssystemen zur Verfügung stehen.
  • Es ist zu überlegen, ob ein Terminalschutz auf Basis der VTAM-LU (Logical Unit) aktiviert werden soll. Diese Maßnahme erhöht den Schutz, bedeutet jedoch mehr Verwaltungsaufwand.
  • Der Zugang zu der CICS Region kann über den VTAM ACB-Namen (Access Control Block) über RACF kontrolliert werden. Sollte diese Kontrolle eingesetzt werden, empfiehlt es sich, ein Gruppenkonzept aufzubauen, um den Verwaltungsaufwand möglichst gering zu halten.
  • Für die CICS Transaktionen und System Kommandos sind unterschiedliche Gruppen zu bilden. Alle CICS Administrations-Transaktionen und alle kritischen CICS Kommandos sollten so geschützt werden, dass nur die Mitarbeiter Zugriff zu diesen Transaktionen haben, die sie im Rahmen von Administrationstätigkeiten auch benötigen. Eine Vertretungsregelung sollte vorhanden sein. Es ist zu überlegen, ob es erforderlich ist, weitere CICS Resource Classes einzusetzen (siehe CICS RACF Security Guide).
  • CICS Systemdefinitionen können entweder über die RCT (Resource ControlTable) oder über die CSD (CICS System Definitions) vorgenommen werden. Während die ältere RCT noch als Loadmodule via Assembly und Link erstellt wird, wird die CSD durch den RDO Dialog (Resource Definition Online) über die Transaktionen CEDA, CEDB und CEDC als VSAM-Datei erstellt und von CICS eingelesen. In beiden Fällen müssen sowohl die relevanten Dateien als auch die Transaktionen durch RACF Profile so geschützt werden, dass nur CICS-Administratoren Zugriff auf diese Definitionen haben. Hier wird u. a. auch das CICS-DB2 Attachment über das Makro DB2CONN definiert, in dem z. B. der Name des DB2 Subsystems, die Berechtigungen auf bestimmte Kennungen oder Relationen zwischen Transaktion, DB2 Plan und Programm festgelegt werden.
    Es ist zu überlegen, ob CEDC (die nur lesende Aktionen durchführt) auch geschützt werden soll. Dies hängt vom Inhalt der Daten ab.

DB2

Die folgenden Empfehlungen gelten für das DB2-Datenbanksystem. Je nach Einsatzszenario sind in der Regel zusätzliche Sicherheitsmechanismen erforderlich. Weitere Informationen sind in der IBM Dokumentation DB2 UDB Administration Guide zu finden:

  • Für jedes DB2-Subsystem muss ein Eintrag in der RACF Router Table vorgenommen werden, da diese Einträge standardmäßig nicht mit ausgeliefert werden.
  • Die General Resource Class DSNR muss über das Kommando SETROPTS aktiviert werden. Die Profile müssen gemäß DB2 Dokumentation definiert und Zugriffe dazu über PERMIT Kommandos eingerichtet werden. Vorher sollte ein Gruppenkonzept entwickelt werden, wie es beispielhaft in der IBM Dokumentation DB2 UDB Administration Guide beschrieben ist. Ist eine VTAM LU 6.2 Verbindung (Virtual Telecommunication AccessManagement) im Einsatz, sollte überlegt werden, ob ein zusätzlicher Schutz über die Klasse APPCLU zweckmäßig ist.
  • Die DB2 Dateien müssen über RACF Dataset Profile so geschützt werden, dass nur Mitarbeiter Zugriff auf die Dateien haben, die sie im Rahmen ihrer Tätigkeit auch benötigen. Zu schützende Dateien sind z. B
    • System-Dateien
    • Anwender-Dateien als Datenbanken
    • APF-Dateien (Authorized Programming Facility)
    Der Zugriff auf APF- und System-Dateien darf nur für die STC-User-IDs (Started Task Control) und autorisierte Mitarbeiter freigegeben werden. Andere Anwender benötigen keinen Zugriff auf diese Dateien (siehe auch M 4.209 Sichere Grundkonfiguration von z/OS-Systemen ).
    Der Zugriff auf Anwender-Dateien muss im Rahmen der RACF Regeln erfolgen (siehe M 4.211 Einsatz des z/OS-Sicherheitssystems RACF ).
  • Der Zugriff auf die Prozedurbibliotheken der DB2 Started Tasks ist durch RACF Dateiprofile zu schützen (siehe M 4.209 Sichere Grundkonfiguration von z/OS-Systemen ).
  • MVS Kommandos für DB2 sollten über RACF geschützt werden (siehe M 4.211 Einsatz des z/OS-Sicherheitssystems RACF ).
  • Die DB2 Started Task User-IDs müssen in der RACF Klasse STARTED als Protected User definiert werden. Die User-IDs benötigen Zugriffe auf die Dateien der Started Task Prozeduren.
  • Alle DB2 Dateien sollten über RACF Dataset Profile abgesichert werden, wobei normale Benutzer keinen direkten Zugriff auf die Datenbank haben sollten. Direkte Zugriffe sollten auf die Administratoren beschränkt bleiben.
  • Es ist zu empfehlen, keine DB2 GRANT PUBLIC Genehmigung auf DB2-Katalog-Tabellen zu erteilen. Statt dessen sollten Zugriffsrechte auf der Ebene von Benutzergruppen vergeben werden.
  • Es wird empfohlen, die internen System-Tabellen nur über DB2-Admin Kommandos (GRANT in DB2) zu schützen. Zugriffsrechte auf User-Tabellen sollten über RACF Gruppen vergeben werden. Dabei muss die RACF Gruppe in DB2 durch entsprechende GRANTs autorisiert werden. Die Autorisierung einzelner User-IDs oder (besser) ganzer Gruppen lässt sich durch das RACF Kommando Permit realisieren. Alle Sicherheitsdefinitionen sollten möglichst zu RACF verlegt werden.

Prüffragen:

  • Wird bei den z/OS-Transaktionsmonitoren ergänzend ein Sicherheitssystem eingesetzt (z. B. RACF )?

  • Werden alle Sicherheitsmechanismen für z/OS-Transaktionsmonitore möglichst durch RACF gesteuert und die internen Sicherheitsmechanismen nur dort genutzt, wo es keine adäquaten RACF-Funktionen gibt?

  • Werden vor der Inbetriebnahme eines z/OS-Transaktionsmonitors oder eines Datenbanksystems Standards für alle relevanten Definitionen entwickelt?

  • Sind die MVS Kommandos für z/OS-Transaktionsmonitore und Datenbanken über RACF geschützt?

  • Werden alle DB2 Dateien unter z/OS über RACF Dataset Profile abgesichert?

  • Haben nur die Administratoren einen direkten Zugriff auf die DB2-Datenbanken unter z/OS?

Stand: 13. EL Stand 2013