von Thomas Barlen
Dies ist auch begründet, denn das Labor in Rochester, MN. legt sehr großen Wert auf Sicherheit bei der Entwicklung von neuen Funktionen. Jedoch ist hierbei darauf zu achten, dass bei falscher Konfiguration ein iSeries Server seiner Umwelt gegenüber sehr offen sein kann. Grundsätzlich sollte darauf geachtet werden, dass Sicherheit auf mehreren Ebenen implementiert werden sollte. Nur durch eine Kombination von verschiedenen Schutzfunktionen an verschiedenen Orten in einer Organisation läßt sich ein hohes Maß an Sicherheit erreichen. Dies fängt bei unternehmensweiten Sicherheitsrichtlinien an und reicht bis hin zur Anwendungssicherheit wie in der folgenden Abbildung dargestellt ist.
In diesem Artikel konzentriere ich mich auf die wesentlichen Funktionen im Bereich System- und Netzwerksicherheit, die seit OS/400 V5R1 neu hinzugekommen sind, bzw. erweitert wurden. OS/400 stellt viele Funktionen und Services zur Verfügung, die es erlauben die Grundanforderungen von Sicherheit zu gewährleisten. Die wichtigsten Anforderungen sind:
- Authentisiering
- Autorisierung
- Integrität
- Vertraulichkeit
- Audit und Monitoring
Systemsicherheit
Leider gibt es immer noch zu viele Benutzerprofile mit Sonderrechten wie *ALLOBJ, *SECADM, *AUDIT, etc. Grundsätzlich gilt, dass OS/400 mit seinen Objekt-Berechtigungsmöglichkeiten es erlaubt, Systemadministration wie auch Programmierung ohne die o.a. Rechte zu betreiben. Sollte der IT Betrieb dies trotzdem erfordern, gibt es seit V5R2 eine Möglichkeit, sicherheitsbezogene Systemeinstellungen „einzufrieren“, so dass Benutzer mit der *SECOFR Benutzerklasse und den dazugehörigen Sonderrechten (dies schließt das OS/400 Profil QSECOFR mit ein) keine Möglichkeit mehr haben, die eingerichteten Sicherheitswerte zu verändern. Diese Sperrung geschieht über die System Service Tools (SST) wie folgt:
- 1.Von der OS/400 Befehlszeile den Befehl STRSST aufrufen. Mit dem QSECOFR DST Profil anmelden. Dieses Profil ist unabhängig von dem OS/400 Profil QSECOFR.
- 2. Auf dem System Service Tools Menü die Auswahl 7 (Work with System Security) auswählen.
- 3. Nun den Wert für Allow System Value Security Changes auf 2 setzen. Von nun an sind alle sicherheitsbezogenen Systemwerte von niemand mehr änderbar. Über die F1 (Hilfe) Taste bekommen Sie alle betroffenen Werte angezeigt.
- 4. System Service Tools verlassen.
Um weitere Änderungen vornehmen zu können, muss der Wert über SST wieder zurückgesetzt werden. Da kaum jemand Zugang zum SST hat, ist mit dieser Funktion gewährleistet, dass alle Sicherheitseinstellungen, die in den Sicherheitsrichtlinien festgelegt sind, auch ihre Wirksamkeit beibehalten. Es sollte auch daran gedacht werden, nur ausgewählte DST Benutzer für die sicherheitsrelevanten SST Funktionen zu berechtigen. Die DST/SST Berechtigungen können ab V5R2 auch über SST definiert werden.
Integrität von Objekten
Stellen Sie sich folgendes Szenario vor. Ein Software Hersteller informiert Sie darüber, dass er für seine Anwendung eine Programmkorrektur zur Verfügung stellt. Diese wird über ein Sicherungsmedium versandt. Sie erhalten die Sendung und speichern die Programmkorrektur auf Ihr System zurück. Nach einiger Zeit stellen Sie Unregelmäßigkeiten auf dem System fest, kennen aber nicht die Ursache. Nach längerem Suchen stellt sich das zurückgespeicherte Objekt als Ursache heraus. Weitere Untersuchungen ergeben, dass sich das Objekt von dem ursprünglich versendeten Objekt unterscheidet und es sich um ein Trojanisches Pferd handelt.
Vor OS/400 V5R1 gab es kaum eine Chance sicherzustellen, dass eine dritte Person den Datenträger unbemerkt abfängt und die darauf gesicherten Objekte gegen eigene Objekte ersetzt. Mit V5R1 wurden digitale Objektsignaturen eingeführt. Alle Betriebssystemobjekte, Lizenzprogramme und PTFs sind seitdem von IBM elektronisch signiert. Damit nun das Zielsystem beim Rückspeichern die Signatur überprüfen kann, wird der öffentliche Schlüssel des bei der Signierung verwendeten Zertifikates benötigt. Für IBM Objekte befindet sich dieser Schlüssel in einem internen Systemobjekt, welches beim System License Internal Code (SLIC) Installieren auf das System zurückgespeichert wird.
Selbstverständlich können auch eigene Objekte signiert werden. Die benötigten Zertifikatsspeicher und Einstellungen werden über den Digital Certificate Manager (DCM) vorgenommen.
Im *OBJECTSIGNING Zertifikatsspeicher werden die Zertifikate gespeichert, die zum Signieren von Objekten benutzt werden. Das Signieren geschieht immer über sogenannte Anwendungen, die auch über DCM erstellt werden. Der *SIGNATURE VERIFICATION Zertifikatsspeicher beinhaltet Zertifikate mit den öffentlichen Schlüsseln, die zur Verifizierung von Signaturen benötigt werden. Folgende Objekte können im OS/400 elektronisch signiert werden:
- Programmobjekte (*PGM, *SVRPGM, *SQLPKG, *JVAPGM, *MODULE)
- IFS Objekte
- Befehle (*CMD ab V5R2)
- Sicherungsdateien (*SAVF)
Objekte können über DCM, Management Central (V5R2) und über APIs signiert werden. Die Signaturüberprüfung kann über DCM, APIs und über den Systembefehl Check Object Integrity (CHKOBJITG) durchgeführt werden. Der Befehl CHKOBJITG kann nicht nur elektronische Signaturen überprüfen. Er kann auch dazu benutzt werden, um Integritätsverletzungen an nicht signierten Programmobjekten und Befehlen sowie Bibliotheken und Objektdomänen festzustellen. Weitere Informationen zur Einrichtung und Nutzung von Object Signing finden Sie im Redbook IBM eServer iSeries Wired Network Security, SG24-6168 auf der Seite http://www.redbooks.ibm.com/
Im zweiten Teil des Artikels, der demnächst veröffentlicht wird, werden einige Funktionen aus dem Bereich Netzwerksicherheit vorgestellt.
Thomas Barlen, IBM Technical Sales Support iSeries, ist zu erreichen unter barlen@de.ibm.com
Ähnliche Artikel:
