[z/OS]

SSL-Sicherheit für WebSphere Application Server for z/OS

Dieser Artikel setzt voraus, dass Sie das SSL-Protokoll verstehen und wissen, wie das System der Verschlüsselungsservices unter z/OS funktioniert. SSL wird von vielen Komponenten in WebSphere Application Server zur Gewährleistung von Vertraulichkeit und Geheimhaltung verwendet. Dies sind Komponenten, die den integrierten HTTP-Transport, den ORB (Client und Server) und den sicheren LDAP-Client (Lightweight Directory Access Protocol) umfassen. In WebSphere Application Server muss SSL für den Client und den Server unterschiedlich konfiguriert werden. Falls Sie zusätzliche Sicherheit einer geschützten Kommunikation und die Benutzerauthentifizierung in einem Netz wünschen, können Sie die SSL-Sicherheit verwenden.

SSL (Secure Socket Layer) ist integraler Bestandteil der Sicherheit von WebSphere Application Server for z/OS und wird zusammen mit der Verwaltungssicherheit aktiviert. Wenn die Verwaltungssicherheit aktiviert ist, verwendet das Verwaltungssubsystem immer SSL, um Verwaltungsbefehle, die Administrationskonsole und die Kommunikation zwischen Prozessen von WebSphere Application Server zu schützen.

Die Laufzeit von WebSphere Application Server for z/OS kann SSL in folgenden Fällen optional verwenden, wenn die Serversicherheit aktiviert ist:
  • SSL wird für den Schutz einer Webanwendung verwendet, wenn für die Webanwendung als Sicherheitsvorgabe "Vertraulichkeit" angegeben ist. Die Transportgarantie VERTRAULICH oder INTEGRAL garantiert, dass die Kommunikation zwischen dem Web-Client und dem Web-Server geschützt und über HTTPS (HTTP SSL) transportiert wird. Sie können SSL zusätzlich für die Clientauthentifizierung verwenden, wenn bei der Anwendungsimplementierung die Sicherheitsvorgabe (CLIENT_CERT) angegeben wurde.
  • Mit SSL können IIOP-Anforderungen (Inter-ORB Protocol) geschützt werden, wenn SSL/TLS in den CSIV2-Transporteinstellungen unterstützt wird (oder erforderlich ist). Klicken Sie zum Definieren dieser Einstellungen auf Sicherheit > Globale Sicherheit. Klicken Sie unter "RMI/IIOP-Sicherheit" auf Eingehender CSIv2-Transport oder Abgehender CSIv2-Transport.
  • Mit SSL kann die Kommunikation zwischen einem LDAP-Client und -Server geschützt werden, wenn LDAP die aktive Benutzerregistry ist.
Wenn Sie SSL konfigurieren, stehen in WebSphere Application Server for z/OS zwei Arten von SSL-Repertoires zur Auswahl. Die Art des Repertoires bezieht sich auf die zugrundeliegenden Services für die SSL-Verarbeitung.
  • Für administrative Anforderungen über den HTTP/SOAP-Connector muss JSSE (Java™ Secure Socket Extension) als SSL-Repertoiretyp ausgewählt werden. JSSE-Repertoires können (bei angewendetem APAR PQ77586) einen SAF-Schlüsselring für den Keystore oder Truststore oder eine HFS-Datei (Hierarchical File System) angeben.
Anmerkung: Alle SSL-Konfigurationsrepertoires des Typs SSSL (System Secure Sockets Layer) außer denjenigen, die zum Dämon gehören, werden in den Typ JSSE (Java Secure Socket Extension) konvertiert. System SSL wird jetzt nur vom Dämonadressraum verwendet, weil der Dämon ohne JVM ausgeführt wird und JSSE nur in Java unterstützt wird.

Dieser Artikel enthält eine kurze Erklärung des SSL-Protokolls und beschreibt die Funktionsweise von SSL unter z/OS. Weitere Informationen zum SSL-Protokoll finden Sie auf der folgenden Webseite: http://home.netscape.com/eng/ssl3/ssl-toc.html.

SSL wird von vielen Komponenten in WebSphere Application Server zur Gewährleistung von Vertraulichkeit und Geheimhaltung verwendet. Diese Komponenten sind der integrierte HTTP-Transport, der ORB (Client und Server) und der sicheren LDAP-Client. In WebSphere Application Server muss SSL für den Client und den Server unterschiedlich konfiguriert werden. Falls Sie zusätzliche Sicherheit einer geschützten Kommunikation und die Benutzerauthentifizierung in einem Netz wünschen, können Sie die SSL-Sicherheit verwenden. Die SSL-Unterstützung in WebSphere Application Server for z/OS hat verschiedene Zielsetzungen:
  • Bereitstellung anerkannter Methoden zur Gewährleistung der Sicherheit von Nachrichten, die im Netz übertragen werden. Diese Art der Sicherheit wird oft als Sicherheit der Transportschicht bezeichnet. Die Sicherheit der Transportschicht sorgt für die Vertraulichkeit und Datenintegrität zwischen zwei kommunizierenden Anwendungen. Der Schutz erfolgt in einer dem Basistransportprotokoll (z. B. TCP/IP) übergeordneten Softwareschicht.

    SSL gewährleistet die Sicherheit der Kommunikationsverbindung und die Integrität von Nachrichten in einem Netz durch Verschlüsselungstechnologie. Da beide Partner Ihre Kommunikation verschlüsseln, können Nachrichten nicht von Dritten manipuliert werden. SSL gewährleistet außerdem Vertraulichkeit (stellt sicher, dass der Nachrichteninhalt nicht gelesen werden kann), Wiederholungserkennung und Erkennung der falschen Reihenfolge.

  • Bereitstellung eines sicheren Übertragungsmediums, das verschiedene Authentifizierungsprotokolle verwenden kann. Eine SSL-Sitzung kann mehrere Authentifizierungsprotokolle (Methoden für den Nachweis der Identität der Kommunikationspartner) benutzen.
    Die SSL-Unterstützung bietet immer einen Mechanismus an, mit dem der Server seine Identität nachweist. Für den Client bietet die SSL-Unterstützung von WebSphere Application Server for z/OS die folgenden Möglichkeiten zum Nachweis der Identität:
    • Basisauthentifizierung (oder SSL-Authentifizierung Typ 1), bei der der Client dem Server seine Identität nachweist, indem er eine dem Zielserver bekannte Benutzer-ID mit dem zugehörigen Kennwort (oder der zugehörigen Kennwortphrase) angibt.
      Die SSL-Basisauthentifizierung ermöglicht Folgendes:
      • Ein z/OS-Client kann sicher mit WebSphere Application Server for z/OS kommunizieren. Dazu verwendet er eine Benutzer-ID und ein Kennwort gemäß Definition im CSIV2-Mechanismus für Benutzernamen und Kennwörter Generic Security Services Username Password (GSSUP).
      • Ein Client von WebSphere Application Server kann eine sichere Kommunikation mit einem Server von WebSphere Application Server for z/OS führen, indem er eine MVS-Benutzer-ID und ein MVS-Kennwort (oder eine Kennwortphrase) verwendet.
      • Da bei einer Anforderung immer ein Kennwort erforderlich ist, können nur einfache Client-Server-Verbindungen hergestellt werden. Der Server kann somit nicht die Benutzer-ID eines Clients an einen anderen Server senden, um von diesem die Antwort auf eine Anfrage zu erhalten.
    • Unterstützung für Clientzertifikate, bei der Server und Client sich gegenseitig ihre Identität mit digitalen Zertifikaten nachweisen.

      Wenn für die Authentifizierung gegenüber WebSphere Application Server for z/OS Zertifikate vorgelegt werden, wird das entschlüsselte Zertifikat einer gültigen Benutzer-ID im aktivierten Benutzerrepository zugeordnet. Webanwendungen können Tausende von Clients haben. Die Verwaltung der Clientauthentifizierung erfordert somit einen hohen Aufwand. Wenn das lokale Betriebssystem das aktivierte Benutzerrepository in WebSphere Application Server for z/OS ist, können Sie Clientzertifikate mit einem SAF-Zertifikatnamensfilter MVS-Benutzer-IDs zuordnen, ohne die Zertifikate zu speichern. Mit Zertifikatnamensfiltern können Sie Gruppen von Benutzern berechtigen, auf Server zuzugreifen, und dabei den Verwaltungsaufwand für das Erstellen von MVS-Benutzer-IDs und das Verwalten von Clientzertifikaten für alle Benutzer vermeiden.

    • Die SSL-Unterstützung bietet immer einen Mechanismus an, mit dem der Server seine Identität nachweist. Für den Nachweis der Clientidentität können die verschiedensten Mechanismen verwendet werden. Das Protokoll SSL V3 (und TLS) ermöglicht einen optionalen Austausch digitaler Clientzertifikate. Diese Zertifikate können für die Authentifizierung verwendet werden.
    • Es kann auch die CSIV2-Unterstützung für die Zusicherung der Identität verwendet werden, die z/OS-Principals, X501-DNs und digitale X509-Zertifikate umfasst.
    • Bei der Zusicherung der Identität oder Trust Association kann ein zwischengeschalteter Server die Identitäten seiner Clients auf sichere und effiziente Weise an einen Zielserver senden. Diese Unterstützung verwendet Clientzertifikate, um den zwischengeschalteten Server als Eigner einer SSL-Sitzung zu etablieren. Mit RACF (Resource Access Control Facility) kann das System überprüfen, ob der Zwischenserver vertrauenswürdig ist. (Zur Gewährleistung dieser Vertrauenswürdigkeit vergeben Administratoren die CBIND-Berechtigung für RACF-IDs, die geschützten Systemcode exklusiv ausführen.) Sobald die Vertrauenswürdigkeit des zwischengeschalteten Servers anerkannt ist, muss der Zielserver Client-IDs (MVS-Benutzer-IDs) nicht gesondert überprüfen. Diese Client-IDs werden einfach angegeben und müssen nicht authentifiziert werden.
  • Für eine sichere Interoperabilität mit anderen Produkten, wie z. B.
    • Customer Information Control System (CICS) Transaction Server for z/OS
    • Andere Versionen von WebSphere Application Server
    • CORBA-kompatible (Common Object Request Broker Architecture) Broker für Objektanforderungen

ist SSL standardmäßig inaktiviert. Die SSL-Unterstützung ist optional. Wenn Sie WebSphere Application Server for z/OS mit aktivierter Sicherheit ausführen, ist SSL für die Administrationskonsole erforderlich. Java Secure Socket Extension (JSSE) ist der verwendete SSL-Repertoiretyp.

Tabelle 1. SSL-Verbindungsfolge.

In der folgenden Tabelle ist die Funktionsweise einer SSL-Verbindung beschrieben.

Schritt Beschreibung
Verhandlung Wenn der Client den Server lokalisiert hat, handeln Client und Server den Sicherheitstyp für die Kommunikation aus. Falls SSL verwendet werden soll, wird der Client aufgefordert, eine Verbindung zu einem bestimmten SSL-Port herzustellen.
Handshake Der Client stellt die Verbindung zum SSL-Port her, wo das SSL-Handshake ausgeführt wird. Nach erfolgreichem Handshake beginnt die verschlüsselte Übertragung. Der Client überprüft das digitale Zertifikat des Servers, um diesen zu authentifizieren.

Falls beim Handshake Clientzertifikate verwendet werden, authentifiziert der Server den Client durch Überprüfung des digitalen Zertifikats des Clients.

Datenübertragung Beim SSL-Handshake handeln Client und Server die für die Verschlüsselung der Übertragung zu verwendende Verschlüsselungsspezifikation aus.
Erste Clientanforderung Die Bestimmung der Client-ID hängt vom gewählten Clientauthentifizierungsmechanismus ab. Dies kann einer der folgenden Mechanismen sein:
  • Benutzer-ID und Kennwort gemäß CSIV2 (GSSUP)
  • Zugesicherte Identität gemäß CSIV2

Regeln

  • Mit einem WebSphere Application Server for z/OS oder Workstation Application Server kann ein Java- oder C++-Client unter z/OS verwendet werden und SSL benutzen. Die CSIV2-Sicherheit unterstützt nur Java-Clients unter z/OS.
  • Zum Handshake gehört das Aushandeln der Verschlüsselungsspezifikation, die SSL für den Schutz von Nachrichten verwenden soll. Die Verschlüsselungsspezifikation und die verwendete Schlüsselgröße werden von zwei Faktoren bestimmt:
    • Die Sicherheitsstufe der auf dem System installierten Cryptographic Services bestimmt, welche Verschlüsselungsspezifikationen und Schlüsselgrößen WebSphere Application Server for z/OS zur Verfügung stehen.
    • Wenn Sie den Server in der Administrationskonsole konfigurieren, können Sie SSL Cipher Suites angeben.
    Weitere Informationen finden Sie unter z/OS System Secure Sockets Layer Programming.
  • Für z/OS-System-SSL-Sockets müssen Sie zum Speichern von digitalen Zertifikaten und Schlüsseln RACF oder eine äquivalente Einrichtung verwenden. Das Ablegen von digitalen Zertifikaten und Schlüsseln in einer Schlüsseldatenbank im HFS ist keine Option.
Tipp: Wenn Sie die SSL-Basisauthentifizierung definieren möchten, müssen Sie zunächst ein signiertes Zertifikat für Ihren Server und ein CA-Zertifikat von der Zertifizierungsstelle, die das Serverzertifikat signiert hat, anfordern. Wenn Sie die Zertifikate von der Zertifizierungsstelle erhalten haben, müssen Sie mit RACF die Verwendung digitaler Zertifikate autorisieren, die Serverzertifikate und Serverschlüsselringe in RACF speichern, einen Aliasnamen für das SSL-Repertoire erstellen und in der Administrationskonsole SSL-Sicherheitseigenschaften für Ihren Server definieren.

Für Clients müssen Sie einen Schlüsselring erstellen und diesen an das CA-Zertifikat der Zertifizierungsstelle, die das Serverzertifikat ausgestellt hat, anhängen. Für einen z/OS-Client müssen Sie in RACF einen Clientschlüsselring erstellen und das CA-Zertifikat an diesen Schlüsselring anhängen. Der Client kann den Server (d. h. eigentlich die Controllerbenutzer-ID) nur authentifizieren, wenn der Server ein signiertes Zertifikat von einer Zertifizierungsstelle besitzt. Der Server übergibt das signierte Zertifikat, um dem Client seine Identität zu beweisen. Das CA-Zertifikat des Clients muss von der Zertifizierungsstelle stammen, die das Serverzertifikat ausgestellt hat. Mit dem CA-Zertifikat überprüft der Client, ob das Serverzertifikat authentisch ist. Nach dieser Überprüfung kann der Client sicher sein, dass Nachrichten wirklich von diesem Server stammen. Der Client übergibt kein Clientzertifikat an den Server, um dem Server seine Identität zu beweisen. Beim Sicherheitsschema der SSL-Basisauthentifizierung authentifiziert der Server den Client, indem er vom Client eine Benutzer-ID und ein Kennwort (oder eine Kennwortphrase) anfordert.

Im Artikel Einen Schlüsselring für Dämon-SSL definieren finden Sie Informationen zum Erstellen eines Schlüsselrings für die MVS-Benutzer-ID des Dämons.


Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=csec_settingupssl
Dateiname:csec_settingupssl.html