Sicherheitshinweise für die Arbeit in einer Umgebung von WebSphere Application Server WebSphere Application Server Network Deployment mit mehreren Knoten

WebSphere Application Server Network Deployment unterstützt die zentrale Verwaltung verteilter Knoten und Anwendungsserver. Eine solche zentrale Verwaltung zieht naturgemäß eine größere Komplexität nach sich. Dies gilt insbesondere, wenn die Sicherheit ins Spiel gebracht wird. In einer verteilten Umgebung kommt der Sicherheit sogar eine noch größere Bedeutung zu, denn es muss gewährleistet werden, dass die Kommunikation zwischen Anwendungsservern und Node Agents sowie zwischen Node Agents (einem knotenspezifischen Konfigurationsmanager) und dem Deployment Manager (einem zentralen Konfigurationsmanager für die gesamte Domäne) geschützt ist.

Vorbereitende Schritte

[AIX Solaris HP-UX Linux Windows][IBM i]Da die Prozesse verteilt sind, kommt als Authentifizierungsverfahren nur LTPA in Frage. Die LTPA-Token sind verschlüsselt und signiert und können deshalb an ferne Prozesse weitergeleitet werden. Die Token sind jedoch nicht unbegrenzt gültig. Der SOAP-Connector, der gleichzeitig der Standard-Connector ist, wird für die Verwaltungssicherheit verwendet und hat keine Wiederholungslogik für verfallene Token. Da das Protokoll jedoch statusunabhängig ist, wird für jede Anforderung ein neues Token erstellt (sofern die verbleibende Zeit für das Token nicht ausreicht, um die Anforderung zu bearbeiten). Ein alternativer statusabhängiger Connector ist der RMI-Connector, der eine Wiederholungslogik bereitstellt und verfallene Token korrigieren kann, indem er die Anforderungen nach Feststellung des Fehlers erneut übergibt. Da Token eine Verfallszeit haben, ist die Synchronisation der Systemuhren für eine ordnungsgemäße Durchführung der tokenbasierten Validierung von entscheidender Bedeutung. Weichen die Systemuhren zu stark voneinander ab (um ca. 10-15 Minuten), kann es schnell zu nicht behebbaren Validierungsfehlern kommen, die bei einer Synchronisation vermeidbar wären. Stellen Sie sicher, dass auf allen Systemen dieselbe Uhrzeit, dasselbe Datum und dieselbe Zeitzone eingestellt ist. Wenn sich Knoten in verschiedenen Zeitzonen befinden, ist es wichtig, dass die Uhrzeit innerhalb der Zeitzonen korrekt ist (z. B. 17.00 Uhr CST = 18.00 Uhr EST).

[z/OS]Weil die Prozesse verteilt sind, muss ein Authentifizierungsverfahren ausgewählt werden, das Authentifizierungstoken unterstützt, wie z. B. LTPA. Die Token sind verschlüsselt und signiert und können deshalb an ferne Prozesse weitergeleitet werden. Die Token haben jedoch eine Verfallszeit, die in der Administrationskonsole von WebSphere Application Server festgelegt wird. Der SOAP-Connector, der gleichzeitig der Standard-Connector ist, wird für die Verwaltungssicherheit verwendet und hat keine Wiederholungslogik für verfallene Token. Da das Protokoll jedoch statusunabhängig ist, wird für jede Anforderung ein neues Token erstellt (sofern die verbleibende Zeit für das Token nicht ausreicht, um die Anforderung zu bearbeiten). Ein alternativer statusabhängiger Connector ist der RMI-Connector, der eine Wiederholungslogik bereitstellt und verfallene Token korrigieren kann, indem er die Anforderungen nach Feststellung des Fehlers erneut übergibt. Da Token eine Verfallszeit haben, ist die Synchronisation der Systemuhren für eine ordnungsgemäße Durchführung der tokenbasierten Validierung von entscheidender Bedeutung. Weichen die Systemuhren zu stark voneinander ab (um ca. 10-15 Minuten), kann es schnell zu nicht behebbaren Validierungsfehlern kommen, die bei einer Synchronisation vermeidbar wären. Stellen Sie sicher, dass auf allen Systemen dieselbe Uhrzeit, dasselbe Datum und dieselbe Zeitzone eingestellt ist. Wenn sich Knoten in verschiedenen Zeitzonen befinden, ist es wichtig, dass die Uhrzeit innerhalb der Zeitzonen korrekt ist (z. B. 17.00 Uhr CST = 18.00 Uhr EST).

[z/OS]Weitere Überlegungen sind für die Verwendung von Secure Sockets Layer (SSL) in Betracht zu ziehen. WebSphere Application Server for z/OS kann RACF-Schlüsselringe verwenden, um die für SSL verwendeten Schlüssel und Truststores zu speichern, aber intern werden andere SSL-Protokolle verwendet. Sie müssen sicherstellen, dass die folgenden beiden Komponenten konfiguriert werden:
  • Ein SSL-Systemrepertoire für den Web-Container.
  • Ein JSSE-SSL-Repertoire für den SOAP-HTTP-Connector, falls der SOAP-Connector für Verwaltungsanforderungen verwendet wird.
Vergewissern Sie sich, dass die von Ihnen konfigurierten Keystores und Truststores nur die Server anerkennen, mit denen sie kommunizieren müssen. Sie müssen allerdings die nötigen Ausstellerzertifikate für diese Server enthalten, die sich in den Trustdateien aller Server in der Domäne befinden. Wenn die persönlichen Zertifikate von einer CA erstellt werden, lässt sich die gegenseitige Anerkennung der Server leichter realisieren, da alle Server über das CA-Stammzertifikat verfügen.

[z/OS]WebSphere z/OS Profile Management Tool bzw. der Befehl zpmt verwendet dieselbe Zertifizierungsstelle, um Zertifikate für alle Server in einer bestimmten Zelle zu generieren, darunter auch die der Node Agents und des Deployment Manager.

Informationen zu diesem Vorgang

Die folgenden Aspekte sollten Sie bei der Planung einer Network-Deployment-Umgebung und beim Arbeiten in einer Umgebung mit WebSphere Application Server Network Deployment bedenken.

Vorgehensweise

Ergebnisse

Wenn Sie sich gründlich mit den Abhängigkeiten verteilter Server in Fragen der Sicherheit beschäftigt haben, werden kaum Probleme bei der geschützten Datenfernverarbeitung auftreten. Parallel zur Sicherheit steigt auch die Komplexität, da zusätzliche Funktionen verwaltet werden müssen. Ein reibungslos funktionierender Schutz erfordert eine gründliche und detaillierte Planung der Infrastruktur.

Nächste Schritte

Falls Sicherheitsprobleme in der Umgebung mit WebSphere Application Server Network Deployment auftreten, prüfen Sie, ob der Artikel Fehlerbehebung bei Sicherheitskonfigurationen weitere Informationen zu diesen Problemen enthält. Falls Sie zur Behebung eines Fehlers einen Trace durchführen müssen, ist es wegen der verteilten Server oft notwendig, beim Reproduzieren des Fehlers die Tracedaten auf allen Servern gleichzeitig zu erfassen. Dieser Trace kann je nach Fehler dynamisch oder statisch aktiviert werden.

Symbol, das den Typ des Artikels anzeigt. Taskartikel



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