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]](../images/dist.gif)
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).
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]](../images/ngzos.gif)
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.
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
- Wenn Sie versuchen, Systemverwaltungsbefehl wie stopNode auszuführen,
müssen Sie explizit Ihre Administratorberechtigung nachweisen, um die Operation ausführen zu können. Die meisten Befehle akzeptieren die Parameter
–user und –password, mit denen
die Benutzer-ID und das Kennwort angegeben werden können. Die angegebene Benutzer-ID und das angegebene Kennwort
sollten zu einem Benutzer mit Administrationsaufgaben gehören; z. B. einem Konsolbenutzer mit den Zugriffsrechten
Operator oder Administrator. Sie können aber auch die in der Benutzerregistry konfigurierte
Administrator-ID verwenden. Es folgt ein Beispiel für den Befehl stopNode:
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
stopNode -username Benutzer -password Kennwort
stopNode.sh -username Benutzer -password Kennwort
- Stellen Sie sicher, dass die Konfiguration auf den Node Agents stets mit dem Deployment Manager
synchronisiert ist, bevor Sie einen Knoten starten oder erneut starten. Manuell können Sie die
Konfigurationen synchronisieren, indem Sie auf jedem nicht synchronisierten Knoten den Befehl
syncNode absetzen. Klicken Sie zum Synchronisieren der Konfiguration für gestartete Node Agents auf
Systemverwaltung > Knoten. Wählen Sie alle gestarteten Knoten aus, und klicken Sie anschließend auf Synchronisieren.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
Vergewissern Sie sich, dass die Uhren aller Systeme synchronisiert sind. Dasselbe gilt für die Uhrzeit
und das Datum. Wenn die Systemuhren nicht
synchron sind, können die Token aufgrund des Zeitunterschiedes ablaufen, wenn sie den Zielserver
erreichen. Standardmäßig wird die koordinierte Weltzeit (UTC) verwendet, und alle anderen Maschinen
müssen dieselbe UTC-Zeit haben. Informationen dazu, wie Sie dies sicherstellen, finden Sie in der Dokumentation zu Ihrem Betriebssystem.
- Prüfen Sie, ob die LTPA-Token lange genug gültig sind, um die am längsten dauernde Anforderung
an ein nachgeordnetes
System ausführen zu können. Einige Berechtigungsnachweise werden zwischengespeichert, sodass das Zeitlimit
nicht immer
die Länge der Anforderung abdeckt.
Insbesondere für zwischengespeicherte Berechtigungsnachweise
müssen Sie Ihre Einstellungen für den Sicherheitscache
(WSSecureMap) und für das LTPA-Zeitlimit überprüfen.
- Der für die Systemverwaltung standardmäßig verwendete Administrations-Connector ist
SOAP. SOAP ist ein statusunabhängiges HTTP-Protokoll. Dieser Connector ist für die meisten
Situationen ausreichend. Sollten bei der Verwendung des SOAP-Connector Probleme auftreten, können Sie
den Standard-Connector auf allen Servern auf RMI setzen. Der RMI-Connector verwendet CSIv2 (Common Secure Interoperability Version 2). Dies ist ein
statusabhängiges (interagierendes) Protokoll, das für die Zusicherung der Identität
(Downstream-Delegierung), die Authentifizierung in der Nachrichtenschicht
(BasicAuth oder Token) und die Authentifizierung mit Clientzertifikat (Einschränkung der vom
Server anerkannten Clients) konfiguriert werden kann. Wenn Sie den Standard-Connector für einen bestimmten Server ändern möchten,
klicken Sie unter "Weitere Eigenschaften" für diesen Server auf Verwaltungsservices.
Zur Verwaltungssicherheit von Subsystemen kann eine Fehlernachricht
angezeigt werden. Sie gibt an, dass der sendende Prozess dem empfangenden Prozess keinen Berechtigungsnachweis
vorgelegt hat. In der Regel ist dieses Problem darauf zurückzuführen, dass für den sendenden Prozess die Sicherheit inaktiviert, aber für den empfangenden Prozess aktiviert ist. Dies ist ein Hinweis darauf, dass einer der beiden Prozesse
nicht mit der Zelle synchronisiert ist. Das Inaktivieren der Sicherheit für einen bestimmten Anwendungsserver
sollte keinen Einfluss auf die administrative Sicherheit haben.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
Zur Verwaltungssicherheit von Subsystemen kann eine Fehlernachricht
angezeigt werden.
Sie gibt an, dass der sendende Prozess dem empfangenden Prozess keinen Berechtigungsnachweis
vorgelegt hat. Dieser Fehler ist normalerweise auf die folgenden Gründe
zurückzuführen:
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
Wird die folgende Fehlernachricht angezeigt, sollten Sie prüfen, ob die Uhren aller Server in der Zelle synchron
sind und die Konfigurationen aller Knoten mit der Konfiguration des Deployment Manager
synchronisiert wurden. Es kann ein Fehler wie der folgende auftreten: [9/18/02 16:48:22:859 CDT] 3bd06f34 LTPAServerObj E CWSCJ0372E: Validation of
the token failed.
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.