Das neue Sicherheitspaket für OS/400 und die Verbesserungen von V3R2. von Jelan Heidelberg, für den deutschen Markt überarbeitet von Mathias Spateneder
Niemand wird behaupten, Systemsicherheit wäre einfach, geschweige denn ein System wäre in dieser Hinsicht narrensicher. Einige, seit kurzem von IBM zur Verfügung gestellte Funktionen und Informationen, vereinfachen jedoch die Absicherung der AS/400 erheblich. Nachfolgende 19 Tips reichen von der Frage, wie die Verwaltung von Benutzerprofilen einfacher und effektiver gestaltet werden kann, bis hin zur erhöhten Sicherheit des Netzwerkes. Einige dieser Techniken benutzen Tools, die dem neuen Sicherheits-Toolkit für OS/400 entstammen, andere basieren auf den Verbesserungen von OS/400, V3R2. Die wenigen Minuten, die es benötigt, diese Tips zu lesen, können später Stunden sparen. Vielleicht zeigt sich auch eine Sicherheitslücke im System – und wie man diese beheben kann.
Das neue Sicherheitspaket für OS/400 und die Verbesserungen von V3R2
19 Tips
1. Standard-Kennwörter aufspüren
IBM liefert die AS/400 mit allgemein bekannten Kennwörtern für Benutzerprofile mit weitreichenden Berechtigungen aus (das Kennwort für das Benutzerprofil des Sicherheitsbeauftragten, QSECOFR, ist z.B. »QSECOFR«).
Ein Hacker mit AS/400-Kenntnissen wird als Erstes versuchen, mit einem Standard-Kennwort in das System einzudringen. Auch bei der Neuanlage eines Benutzerprofils wird als Standard-Kennwort der Name des Benutzerprofils verwendet. Sollte ein neuer Anwender sich für Tage (oder Wochen) nicht anmelden, öffnet sich ein Tor zum System. Wer das Schema kennt, nach dem die Namen für Benutzerprofile vergeben werden, könnte »nur zum Spaß« einmal das neue Benutzerprofil ausprobieren? Das Sicherheits-Toolkit enthält einen neuen Befehl, CHKDFTPWD (Check Default Password), der Benutzerprofile erkennt, deren Kennwort dem Namen des Benutzerprofils entspricht. Als Ergebnis erscheint entweder eine Liste der entsprechenden Benutzerprofile oder diese werden gesperrt.
2. Entfernung temporärer und hinfälliger Benutzerprofile
Möglicherweise existieren im System noch Benutzerprofile ehemaliger, längst ausgeschiedener Mitarbeiter oder temporäre Benutzerprofile für freie Mitarbeiter oder Servicetechniker. Inaktive Benutzerprofile bieten sich für nicht zu überwachenden Mißbrauch an. WEG DAMIT! Der neue Befehl CHGEXPSCDE (Change Profile Expiration Schedule Entry) aus dem Sicherheits-Toolkit gibt die Möglichkeit, ein bestimmtes Benutzerprofil zu einem bestimmten Datum zu deaktivieren und/oder zu löschen.(Für die Vorversionen von V3R2 lautet der Befehl SCDPRFEXP – Schedule Profile Expiration). Diesen Befehl sollte man sofort verwenden und nicht erst für später in den Kalender eintragen. Sobald bekannt ist, daß ein Mitarbeiter seinen Bereich verläßt, sollte mit dem entsprechenden Befehl der Zeitpunkt des Löschens festgelegt werden. Bei einem temporären Benutzerprofil, kann gleichzeitig auch dessen „Ableben“ bestimmt werden. Eine weitere Verbesserung bietet der Befehl ANZPRFACT (Analyze Profile Activity). Man kann damit erkennen, welche Benutzerprofile lange Zeit nicht mehr aktiv waren (was »lange Zeit« bedeutet, wird individuell definiert.) Man kann diese Benutzerprofile stillegen, solange ist noch nicht entschieden, was damit passieren soll. Für die Vorversionen von V3R2 wird der Befehl PRCINACPRF verwendet.
3. Zeitliche Verfügbarkeit hochrangiger Benutzerprofile einschränken
Hacker surfen meist abends oder an Wochenenden, also zu Zeitpunkten, zu denen Versuche auf der Datenleitung und die dabei produzierten Fehlermeldungen nicht beobachtet werden können. Man kann zwar nicht alles vorhersehen, was ein Hacker versuchen könnte, aber so erreicht man wenigstens, daß sie sich nicht mit einem Benutzerprofil hoher Priorität anmelden können und damit alle Systemresourcen erreichen. Über den neuen Befehl CHGACTSCDE (Change Activation Schedule Entry) können bestimmte Benutzerprofile (z.B. QSECOFR) nur während bestimmter Tageszeiten zur Verfügung gestellt werden. (Für die Version des Sicherheits-Toolkits für Release-Stände vor V3R2 existiert der Befehl SCDPRFACT – Schedule Profile Activation). So lassen sich beispielsweise mit dem jeweiligen Befehl alle Benutzerprofile mit QSECOFR-Berechtigung jeden Morgen (Montag mit Freitag) um 8.00 Uhr aktivieren und automatisch um 17.00 Uhr sperren.
4. Sonderberechtigungen in den Griff bekommen
Sonderberechtigungen sind wie der Schlüssel zum Himmelreich. Ein Benutzer mit Berechtigung *ALLOBJ darf und kann alles im System, ob direkt, oder über ein anderes Benutzerprofil. Ein Benutzer mit Berechtigung *SPLCTL kann jede gespoolte Datei ansehen, kopieren oder löschen, ohne Rücksicht auf deren Wichtigkeit oder Vertraulichkeit. Ein Benutzer mit Berechtigung *SAVSYS hat die Möglichkeit, das komplette System (oder einen beliebigen Teil davon) auf Band abzuziehen, um firmensensible Dateien evtl. auf ein fremdes System zu übertragen.
Zumindest sollte man wissen, welche Benutzerprofile Sonderberechtigungen besitzen. Der neue Befehl PRTUSRPRF (bzw. PRTUSRINF vor V3R2) hilft dabei, alle Benutzerprofile aufzulisten, die eine bestimmte Sonderberechtigung wie z.B. *ALLOBJ besitzen, oder alle Benutzerprofile mit irgendeiner Sonderberechtigung.
5. Systemumgebung der Anwender überwachen
Die Systemumgebung eines Benutzerprofils (wie z.B. Ausgabewarteschlange, Jobwarteschlange, Startprogramm und Abrufprogramm), ist ein wichtiges Werkzeug des Sicherheitsbeauftragten. Mit dem Aufbau der Umgebung wird festgelegt, wie Anforderungen des Benutzers behandelt werden. Mit dem Parameter *ENVINFO des Befehls PRTUSRPRF wird die Benutzerumgebung eines jeden Benutzerprofils ausgedruckt. Dieser Bericht ist für den Sicherheitsbeauftragten ein schnelles und effektives Werkzeug, falls er die Erstellung und Pflege der Benutzerprofile delegiert hat.
6. Arbeit mit Benutzerprofilen überwachen
Wenn auch andere mit der Pflege der Benutzerprofile beauftragt sind, besteht der Bedarf, eventuell getätigte &AUMLnderungen sofort zu erkennen oder bei bestimmten Arbeiten mit Benutzerprofilen benachrichtigt zu werden. Außerdem kann der Sicherheitsbeauftragte festlegen, daß beim Neuanlegen eines Benutzerprofils bestimmte Werte automatisch vom System vergeben werden.
Beginnend ab V3R2 stellt das System Exit Points (Austrittspunkte) für die Befehle zur Verfügung, die mit Benutzerprofilen arbeiten. So können Exit-Programme zur Überwachung, Steuerung und Vereinfachung der administrativen Arbeiten mit Benutzerprofilen eingesetzt werden. Jedem neu erstellten Benutzerprofil können zudem bestimmte Werte zugeordnet werden. Nach Ausführung eines Benutzerprofil-Befehls (oder vor dessen Ausführung im Falle von DLTUSRPRF – Delete User Profile) ruft das System das Exit-Programm auf und übergibt ihm den Namen des Benutzerprofils. Das Exit-Programm kann die Werte des erstellten oder geänderten Benutzerprofils erkennen und, falls nötig, verändern. So kann man z.B. ein Exit-Programm schreiben, das einem neuen Benutzerprofil die Umgebungswerte zuweist, die für das Gruppenprofil gelten, oder das &AUMLnderungen an Benutzerprofilen auf andere Systeme innerhalb Ihres Netzwerkes überträgt. Das Programm kann außerdem alle Objekte erstellen, die der Anwender benötigt, und ihm die Berechtigung für die benötigten Anwendungen erteilen. Exit Points stehen bei folgenden Befehlen zur Verfügung:
Erstellen eines Benutzerprofils – CRTUSRPRF &AUMLndern eines Benutzerprofils – CHGUSRPRF Löschen eines Benutzerprofils – DLTUSRPRF Zurückspeichern eines Benutzerprofils – RSTUSRPRF
7. Systemwerte überprüfen
Sicherheitsbezogene Systemwerte sind ein wichtiges Werkzeug im Sicherheitsrepertoire. Prüfer fragen häufig, inwieweit die Systemwerte den geforderten Werten entsprechen, und Manager könnten wissen wollen, welche Sicherheitsrichtlinien verfolgt werden. Sicherheitsbezogene Systemwerte bilden die erste Verteidigungslinie der AS/400. Es wäre daher keine schlechte Idee, diese Parameter ab und an zu überprüfen, um sicherzugehen, daß sie wirklich das bewirken was sie sollen. Der neue Befehl PRTSYSSECA (Print System Security Attributes) erstellt einen Bericht, der zeigt, inwieweit die sicherheitsrelevanten Systemwerte mit den von IBM empfohlenen übereinstimmen. Diese befinden sich im Handbuch „Tips and Tools for Securing your AS/400“ (siehe auch Tip 19). Zusätzlich kann man den Befehl CFGSYSSEC (Configure System Security) dazu verwenden, um Systemparameter den vorgeschlagenen anzupassen.
8. Objektberechtigungs-Schema analysieren
Objektberechtigungen sind das wichtigste Instrument zum Schutz kritischer Informationen im System. Wer noch kein Objektberechtigungs-Schema hat, sollte eines konzipieren. Wenn das momentane Konzept ein Mischmasch von verschiedenen Ansätzen ist, sollte es überarbeitet werden. Auch wenn ein gutes Objektberechtigungs-Schema eingeführt ist, ist die Aufrechterhaltung nicht einfach. Von Zeit zu Zeit sollte deshalb überprüft werden, ob &AUMLnderungen erforderlich sind. Das Sicherheits-Toolkit hilft beim Verwalten von Objektberechtigungen. Eine Auswahl des Menüs SEC BATCH liefert eine Reihe von Berichten, anhand derer allgemeine und spezielle Berechtigungen für die verschiedenen Objekttypen im System analysiert werden können. So entsteht zum Beispiel eine Liste, die alle Dateien oder Programme in einer bestimmten Bibliothek enthält, deren allgemeine Berechtigung *USE oder höher ist. Durch die Auswahl bestimmter Objekttypen und Bibliotheken finden sich Lücken im Objektberechtigungs-Schema. Es ist empfehlenswert, einen Grundstock zu bilden, in dem man alle Dateien in allen Anwendungsbibliotheken auflistet und dann regelmäßig neue Berichte druckt. Die neuen Berichte geben Aufschluß darüber, was seit dem letzten Bericht im System vor sich ging. Die Berichte helfen auch dabei, herauszufinden, worauf sich die Bemühungen konzentrieren sollten.
9. Übernommene Berechtigungen beobachten
Richtig angewendet sind übernommene Berechtigungen ein wertvolles und legitimes Hilfsmittel. Bei falscher Verwendung können übernommene Berechtigungen unberechtigten und unvorhersehbaren Zugriff auf Systemressourcen ermöglichen. Die am weitesten verbreitete Sicherheitslücke von Programmen mit übernommener Berechtigung ist das Anbieten einer Befehlseingabezeile. Ein weiteres häufiges Problem ist die Übernahme zu hoher Berechtigung (z.B. *ALLOBJ anstelle der Benutzerberechtigung zum Aktualisieren der benötigten Dateien). Zu wissen, wo man nachsehen muß, ist bereits die halbe Miete. Der Befehl PRTADPINF (Angenommene Information drucken), listet alle Programme auf, die Berechtigungen annehmen, und zeigt, um welche Berechtigungen es geht. Der gedruckte Bericht zeigt, welche Sonderberechtigungen das angenommene Profil besitzt und erlaubt damit einen schnellen Überblick, wieviele Rechte angenommen werden. Wie die meisten Befehle des Sicherheits-Toolkits bietet PRTADPINF die Möglichkeit, nur diejenigen Programme aufzulisten, die sich seit der letzten Druckanforderung geändert haben, oder die neu hinzugekommen sind. Wenn einmal alle Programme erfaßt sind, die Berechtigungen annehmen, reicht diese Kurzversion als Kontrollinstrument. (Hinweis: Da die Kurzversion keine &AUMLnderungen an Programmen aufzeigt, die bereits bisher Berechtigungen annahmen, sollte von Zeit zu Zeit der vollständige Bericht gedruckt werden.)
10. Vererbung angenommener Berechtigungen einschränken
Wenn nicht explizit etwas anderes festgelegt ist, »erben« AS/400-Programme die angenommene Berechtigung von vorhergehenden Programmen im Aufrufstapel des Jobs. Diese Übernahme angenommener Berechtigungen könnte einem Programmierer den Zugriff auf Ressourcen ermöglichen, die ihm ansonsten nicht zugänglich wären. Die neuen Sicherheitsfunktionen bieten eine Berechtigungsliste, mit der festgelegt werden kann, welche Benutzer Programme erstellen können, die die angenommene Berechtigung von vorhergehenden Programmen verwenden. Unter V3R2 wird im Systemwert QUSEADPAUT der Name der Berechtigungsliste angegeben. Diese Unterstützung ist für V3R1 und V3R6 über ein PTF verfügbar; bei diesen Versionen existiert eine Berechtigungsliste mit dem Namen QUSEADPAUT.
11. Immer einen Schritt voraus
Hacker haben scheinbar endlos Zeit, um nach Wegen zu suchen, wie sie die Sicherheit eines Systems untergraben können. Man sollte auf Ereignisse im System achten, die darauf hinweisen, daß ein Hacker ins System eindringen will.
Das Sicherheits-Toolkit kann bei der Suche nach Unterwanderungsversuchen helfen. Unter V3R1, V3R2 oder V3R6 kann man mit dem Befehl PRTTGRPGM (Trigger-Programme drucken) eine Liste der installierten Trigger-Programme anfordern. Wie Programme, die Berechtigungen übernehmen, sind auch Trigger-Programme ein nützliches Werkzeug, wenn sie richtig eingesetzt werden. Aber sie können auch als Versteck für trojanische Pferde dienen. Das Sicherheits-Toolkit bietet außerdem die Möglichkeit, &AUMLnderungen an der Kommunikations-Konfiguration und an Subsystem-Beschreibungen aufzuzeichnen. Beide Bereiche können den Zugang zum System ermöglichen und sind beliebte Ziele von Hackern.
12. Sicherheitskritische Ereignisse überwachen
Die AS/400 bietet leistungsstarke und flexible Überwachungsfunktionen, die nicht unbedingt ständig genützt werden sollten, aber doch von Zeit zu Zeit nützlich sind. So kann man zum Beispiel prüfen, ob jemand versucht, auf Objekte zuzugreifen, für die er keine Berechtigung hat, oder versucht, Benutzerprofile oder Systemwerte zu ändern. Das Sicherheits-Toolkit vereinfacht die Anwendung der AS/400-Überwachungsfunktionen. Der neue Befehl CHGSECAUD (Sicherheitsprüfung ändern) ermöglicht das Einrichten von Sicherheitsprüfungen, und mit dem Befehl DSPAUDJRNE (Prüfungs-Journaleintrag anzeigen) können bestimmte Informationen aus dem Prüfungsbericht ausgedruckt werden. Das Sicherheits-Toolkit für Systeme vor V3R2 verwendet den Befehl PRTAUDRPT (Prüfungsbericht drucken) anstelle von DSPAUDJRNE.
13. Schutzmechanismen im Unternehmensnetz
Immer mehr AS/400-Systeme sind mit Netzwerken in anderen Organisationen verbunden. Die unternehmensübergreifende Kommunikation ist aus geschäftlichen Gründen sicher sinnvoll. Aber ein solchermaßen erweitertes System stellt auch ein wesentlich höheres Sicherheitsrisiko dar.
Die neue APPN-Filterunterstützung ermöglicht das Einrichten von Firewalls für bestimmte Teile des APPN-Netzwerks. Diese Möglichkeit ist in V3R2 fest integriert und über PTF für frühere Releases von OS/400 erhältlich (nähere Informationen im Kasten »Bestellinformationen«). Mit zwei neuen Konfigurationslisten erhält man die Kontrolle darüber, wie Systeme im Netzwerk Anforderungen von fremden Systemen handhaben. Der Sitzungs-Endpunkt-Filter (QAPPNSSN) steuert Sitzungen im lokalen System. Der Verzeichnis-Suchfilter (QAPPNDIR) steuert, ob ein Netzwerk-Knoten eine Anforderung an ein anderes System im Netzwerk weierleitet.
14. Nachlässigkeiten der Partner berücksichtigen
Einige Anwendungen, die auf APPC basieren (wie z.B. DDM) machen das System verwundbar durch Sicherheitslücken auf anderen Systemen im Netz. So könnte z.B. ein Benutzer, der es schafft, sich auf einem anderen System als QSECOFR anzumelden, auch auf vernetzten Systemen einen Job mit dieser Berechtigung starten. Ab V3R2 kann man einen neuen Wert für den Parameter SECURELOC bei APPC-Einheiten und Konfigurationslisten eingeben. Mit *VFYENCPWD kann der Benutzer den Job nur starten, wenn sein Benutzerprofil auf beiden Systemen dasselbe Kennwort hat. Bei *VFYENCPWD sendet das lokale System die Benutzer-ID und das verschlüsselte Kennwort zur Überprüfung an das ferne System. *VFYENCPWD gilt für Anwendung wie z.B. DDM, die mit dem Parameter SECURITY(SAME) arbeiten.
15. Netzwerk-Kennwörter vorbereiten
Je komplexer Netzwerke werden, und je mehr Zugang zu anderen Systemen Benutzer haben, umso wichtiger wird eine zentrale Verwaltung für Benutzerprofile und Kennwörter. Mit V3R2 bietet die AS/400 einen Grundstein für die zentrale Verwaltung – eine sichere Methode zum getrennten Speichern dechiffrierbarer und verschlüsselter Kennwörter, wie sie z.B. für AS/400-Benutzerprofile verwendet werden. Diese gespeicherten Kennwörter werden heute schon von bestimmten Netzwerk-Funktionen verwendet, wie z.B. von dem Script, das zum Einrichten einer SLIP-Verbindung (Serial Line Interface Protocol) zu einem anderen System dient. Wer weiß, welche zuküftigen Nutzungen möglich sind? Der neue Systemwert QRETSVRSEC legt fest, ob das System Kennwörter speichert, die entschlüsselt werden können (standardmäßig ist diese Funktion abgeschaltet). Bei richtiger Verwaltung (d.h. wenn sichergestellt ist, daß die Netzwerk-Kennwörter sich von den AS/400-Kennwörtern unterscheiden) kann das Speichern von Kennwörtern für Netzwerk-Funktionen keinen Einfluß auf die Sicherheit und Integrität des normalen AS/400-Kennwort-Schutzes haben.
16. FTP einschränken
Wenn einige Dateien im System so definiert sind, daß sie für alle Benutzer zugänglich sind, dann muß verhindert werden, daß ein Benutzer diese Dateien auf eine PC-Diskette kopiert und zur Tür hinausträgt. Aber genau das kann mit FTP geschehen – die Berechtigung *USE, mit der eine Datei für Anwender einsehbar wird, erlaubt einem FTP-Anwender das Kopieren. Mit Exit-Programmen können FTP-Zugriffe auf das System abgesichert werden. Seit V3R2 sind zwei Ausgangspunkte verfügbar: Einer für die Anmeldung und einer für jede einzelne Benutzeranforderung. Mit dem Anmeldungs-Ausgangspunkt wird eine anonyme FTP-Funktion auf dem System eingerichtet, um Gästen den Zugriff auf bestimmte, öffentliche Informationen zu ermöglichen. Der Ausgangspunkt für Benutzeranforderungen ermöglicht es, spezifische Schutzfunktionen einzusetzen, die genauer definiert sind, als dies mit Objektberechtigungen möglich wäre. Man kann z.B. festlegen, ob das Herunterladen aller oder bestimmter Dateien erlaubt ist. Der Anhang »User Exit« im Handbuch TCP/IP Configuration and Reference (SC41-3420) beschreibt, wie Ausgangspunkte verwendet werden, und stellt einige Beispielprogramme vor.
17. Verschlüsselung
Noch vor einigen Jahren wurden die Begriffe Kryptographie und Verschlüsselung mit der High-Tech-Welt der Spionage assoziiert. Aber mit zunehmendem Netzwerkverkehr und immer ausgefeilteren Methoden zur elektronischen Schnüffelei sollte man sich zumindest die Zeit nehmen, sich etwas mit Verschlüsselungsverfahren vertraut zu machen. Auch wenn zur Zeit keine Notwendigkeit dafür gesehen wird, könnte sich dies in Zukunft schnell ändern. Mit V3R2 wird die Verschlüsselung auf Sitzungsebene (SLE – Session Level Encryption) für Anwendungen mit LU6.2-Kommunikation ermöglicht, ohne die Anwendung ändern zu müssen. Zu den Möglichkeiten von LU6.2 SLE gehören: – Steuern der Verschlüsselung auf Sitzungsebene – Sicherheit für Sitzungen über TCP/IP und Internet, wenn AnyNet zwischen Systemen verwendet wird, die SLE unterstützen – automatisches Generieren und sicherer Austausch von Schlüsseln nach der ersten Konfiguration – Kennwort-Verschlüsselung – Unterstützung von Workstation-Sitzungen mit LU6.2 und Client/Server-Anwendungen – transparente Verschlüsselung für Datenstations-Durchgriff, DDM und SNA Distribution Services (SNADS). Wann immer man eine LU6.2-Sitzung für die Verwendung von SLE einrichtet, verschlüsselt das System automatisch alle Benutzerdaten mit einem Schlüssel, der nur für diese Sitzung gilt. Damit können Benutzerdaten von nicht berechtigten Datenstationen weder angezeigt noch geändert werden. Die Verschlüsselung ist für Anwender und Anwendungen transparent.
Voraussetzung für den Einsatz der SLE-Unterstützung sind das AS/400 Cryptographic Processor Feature (Prozessor-Feature Nummer 2620 oder 2628) und das Lizenzprogramm Common Cryptographic Architecture Services/400 (Lizenzprogramm Nr. 5799-XBY) erforderlich. SLE unterstützt transparente Verschlüsselung für Netzwerk-Kommunikation zwischen der AS/400 und folgenden Systemen, wenn diese entsprechend ausgestattet sind: – einer weiteren AS/400 – einem S/390 – PCs mit IBM Transaction Security System und IBM Communications Server für OS/2 WARP, Version 4 Weitere Informationen über SLE finden sich im Handbuch Common Cryptographic Architecture Services/400 Installation and Operators Guide (SC41-0102).
18. PTFs regelmäßig aktualisieren
Mit dem Einspielen der aktuellen PTFs bleibt man sicherheitstechnisch auf der Höhe der Zeit: – IBM reagiert auf Hinweise über mögliche Sicherheitslücken manchmal mit der Herausgabe von PTFs. – Manchmal schließen PTFs oder ein neues Release eine Sicherheitslücke, indem sie »inkompatible« &AUMLnderungen vornehmen, wie z.B. die &AUMLnderung der Berechtigung, die zur Ausführung eines bestimmten Befehls erforderlich ist. Wer noch nicht mit V3R6 oder V3R2 arbeitet, sollte prüfen, ob das Sicherheits-PTF-Paket angelegt ist, das IBM im Sommer 1995 herausbrachte (nähere Informationen im Kasten »Bestellinformationen«). Die PTF-Informationen des Systems zeigen an, ob die betreffenden PTFs angelegt sind. Nachfolgend die wichtigsten neuen Funktionen, die in V3R2, V3R6 und im Sicherheits-PTF-Paket enthalten sind: – Zusätzliche Kommunikationsbefehle, wie z.B. APPC-Einheitenbefehle und Konfigurationslistenbefehle erfordern jetzt die Sonderberechtigung *IOSYSCFG. – Die allgemeine Berechtigung für alle Befehle zum Zurückspeichern (RSTxxx) wurde von *USE in *EXCLUDE geändert (nur bei V3R2). – Die allgemeine Berechtigung für die Nachrichtendatei QCPFMSG wurde von *CHANGE in *USE geändert. – Zum &AUMLndern einer Einheitenbeschreibung muß sowohl *OBJMGT- als auch *CHANGE-Berechtigung vorliegen. Bisher war nur *CHANGE erforderlich. – Bei neuen Systemen ist der Parameter »Kennwort abgelaufen« für QSECOFR auf *YES gesetzt. Wenn man sich das erste Mal als QSECOFR anmeldet, muß man ein neues Kennwort eingeben (nur bei V3R2). Beim Einspielen zukünftiger PTFs sind die Hinweise für Benutzer“ besonders wichtig, weil hier über sicherheitsrelevante &AUMLnderungen informiert wird, die sich auf die Systembedienung auswirken können. Seit Juni 1996 werden OS/400-PTFs in Kategorien eingeteilt. Jedes PTF hat einen Code, der den PTF-Typ angibt. Mit Hilfe der Legende kann man herausfinden, welche PTFs die Systemsicherheit betreffen.
19. »Bestseller« (Tips and Tools for Securing Your AS/400)
Dieser Artikel kann nur einen ersten kleinen Einblick in die Arbeiten zum AS/400-Systemschutz geben. Diese kurze, leicht zu lesende Einführung, die mit dem Sicherheits-Toolkit geliefert wird, beschreibt die Anwendung der Tools und liefert einen kleinen Leitfaden und zusätzliche Tips zur Sicherheit der AS/400: – Tips zum Absichern der »Türen und Fenster« des Systems, wie z.B. PC-Zugriff, APPC- und TCP/IP-Kommunikation – Tips zum Schutz des Systems vor neugierigen und gedankenlosen Anwendern, mit Vorschlägen zur Ausstattung der Menüzugriffe mit Objektberechtigung (Menüsicherheit) – Tips zum Schutz des Systems vor bösartigen und zielgerichteten Sicherheitsverletzungen, mit Überlegungen zu Viren und trojanischen Pferden Die Bestellnummer der V3R2-Version von Tips and Tools for Securing Your AS/400 ist SC41-3300. Die Bestellnummer für die mit dem Sicherheits-Toolkit-PRPQ gelieferte Version ist GC41-0615. Netzwerke sind ein Eckpfeiler der IBM-Strategie. Die AS/400 spielt bei diesen Plänen eine wichtige Rolle. Und AS/400-Sicherheit ist ein fundamentaler Bestandteil dieser Strategie. Laufende Ergänzungen an den AS/400-Sicherheitsfunktionen sind zu erwarten – einerseits, um die Bedürfnisse der IBM-Kunden zu befriedigen und andererseits, um die anerkannte Führungsrolle der AS/400 in Bezug auf Systemsicherheit zu erhalten. Tips and Tools for Securing Your AS/400 hilft, die verfügbaren Instrumente auch zu nutzen. V3R2 enthält z.B. wesentlich erweiterte TCP/IP-Funktionen (neue Server und FTP-Ausgangspunkte) und APPN-Filter (firewalls), die eine gute Grundlage für die AS/400 als sicheren Internet-Server bilden. Weitere Informationen zur AS/400-Sicherheit im Internet werden in Kürze folgen.
Jelan Heidelberg ist Entwicklerin in der AS/400-Division in Rochester und Verfasserin der Broschüre Tips and Tools for Securing Your AS/400. Sie können sie per e-mail erreichen (jheidelberg@vnet.ibm.com).
Ähnliche Artikel:
