Sicherheitsaspekte beim Hinzufügen eines Basisanwendungsserverknotens zu WebSphere Application Server Network Deployment
Unter bestimmten Umständen könnte die Entscheidung anstehen, die Konfiguration Ihrer eigenständigen Basisanwendungsserver durch das Hinzufügen der Server zu einer WebSphere Application Server Network Deployment-Zelle zu zentralisieren. Falls der Basisanwendungsserver derzeit für Sicherheit konfiguriert ist, gilt es einiges zu beachten. Die Hauptfrage, die sich beim Hinzufügen eines Knotens zur Zelle stellt, ist, ob die Benutzerregistrys des Basisanwendungsservers und des Deployment Manager übereinstimmen.
Beim Hinzufügen eines Knotens zur Zelle werden automatisch die Benutzerregistry und das Authentifizierungsverfahren
der Zelle übernommen.
Wenn Sie einer Zelle einen Knoten hinzufügen,
übernimmt der neu eingebundene Knoten automatisch
die Benutzerregistry (Lokales Betriebssystem, LDAP oder Angepasst), das Authentifizierungsverfahren
(LTPA) und die Berechtigungseinstellung (WebSphere-Bindungen oder
SAF-EJBROLE-Profile) der vorhandenen WebSphere Application Server Network Deployment-Zelle.
Wegen der verteilten Sicherheit müssen alle Server der Zelle dieselbe Benutzerregistry und dasselbe Authentifizierungsverfahren verwenden. Wenn sich eine Benutzerregistry geändert hat, müssen Sie Ihre Anwendungen so ändern, dass die Zuordnungen von Benutzern und Gruppen zu Rollen für die neue Benutzerregistry richtig sind. Nähere Informationen finden Sie im Artikel Benutzer und Gruppen Rollen zuordnen.
Außerdem muss unbedingt die SSL-Infrastruktur für öffentliche Schlüssel beachtet werden. Vergewissern Sie sich vor dem Ausführen des Befehls addNode mit dem Deployment Manager, dass der Befehl addNode als SSL-Client mit dem Deployment Manager kommunizieren kann. Diese Kommunikation setzt voraus, dass der Truststore von "addNode", der in der Datei sas.client.props konfiguriert ist, das Ausstellerzertifikat für das persönliche Zertifikat des Deployment Manager aus dem Keystore enthält. Der Keystore ist in der Administrationskonsole angegeben.
- Wenn Sie versuchen, Systemverwaltungsbefehl wie addNode auszuführen,
müssen Sie explizit Ihre Administratorberechtigung nachweisen, um die Operation ausführen zu können. Der Befehl addNode akzeptiert die Parameter -username und -password, mit denen
die Benutzer-ID und das Kennwort angegeben werden können.
Die angegebene Benutzer-ID/Kennwort-Kombination muss einen
Benutzer mit Administratorberechtigung bezeichnen, z. B. einen Benutzer, der
Member der Konsolbenutzergruppe mit den Berechtigungen Administrator
ist, oder die Verwaltungsbenutzer-ID, die in der Benutzerregistry definiert ist. Es folgt ein Beispiel für den Befehl addNode:
addNode CELL_HOST 8879 -includeapps -username Benutzer -password Kennwort.
Der Parameter -includeapps ist optional und versucht, die Serveranwendungen dem Deployment Manager hinzuzufügen. Der Befehl addNode könnte scheitern, wenn WebSphere Application Server und der Deployment Manager nicht dieselbe Benutzerregistry verwenden. Sie können diesen Fehler beheben, indem Sie identische Registrys verwenden oder die Sicherheit inaktivieren. Falls Sie die Benutzerregistrys ändern, achten Sie darauf, dass die Zuordnungen von Benutzern zu Rollen und von Gruppen zu Rollen stimmen. Nähere Informationen zur Syntax von addNode finden Sie im Artikel Befehl "addNode".Anmerkung: Sie können den Befehl addNode auch mit WebSphere z/OS Profile Management Tool oder mit dem Befehl zpmt ausführen. Wenn Sie den Befehl addNode mit WebSphere z/OS Profile Management Tool oder mit dem Befehl zpmt ausführen und die Sicherheit aktiviert ist, müssen Sie eine berechtigte Benutzer-ID verwenden und die Optionen -user und -password angeben.
- Das Hinzufügen eines sicheren fernen Knotens mit der Administrationskonsole wird nicht unterstützt. Sie können die Sicherheit auf dem fernen Knoten inaktivieren, bevor Sie die Operation durchführen, oder die Operation mit dem Script addNode von der Befehlszeile aus ausführen.
Vergewissern Sie sich vor der Ausführung des Befehls addNode, dass die Truststore-Dateien auf den Knoten mit den Keystore-Dateien des Deployment Manager und umgekehrt kommunizieren können. Wenn Sie die Standarddateien DummyServerKeyFile und DummyServerTrustFile verwenden, sollte das Problem nicht auftreten, da diese Dateien kommunizieren können. Verwenden Sie diese Testdateien nicht in einer Produktionsumgebung.
Vergewissern Sie sich vor der Ausführung des Befehls addNode, dass die Truststore-Dateien auf den Knoten mit den Keystore-Dateien und dem SAF-Schlüsselring des Deployment Manager und umgekehrt kommunizieren. Wenn Sie die Zertifikate für den Deployment Manager mit derselben Zertifizierungsstelle wie die für den Node-Agent-Prozess generieren, treten keine Probleme auf. Die folgenden SSL-Konfigurationen müssen Keystores und Truststores enthalten, die miteinander interagieren können:
- System-SSL-Repertoire, das in der Administrationskonsole unter angegeben wird.
- SSL-Repertoire für den entsprechenden JMX-Connector, wenn SOAP unter angegeben wird.
- SSL-Repertoire, das unter angegeben wird.
Anmerkung: WebSphere Application Server for z/OS definiert Sicherheitsdomänen mit SAF-Profilpräfixen (die früher als z/OS-Sicherheitsdomänen bezeichnet wurden) in WebSphere z/OS Profile Management Tool oder im Befehl zpmt. Gehen Sie vorsichtig vor, wenn Sie einer Deployment-Manager-Konfiguration, die eine andere Sicherheitsdomäne definiert, einen Knoten hinzufügen.- Wenn ein Client aus einem früheren Release versucht, den Befehl addNode zum Einbinden eines Knotens in einen Deployment Manager der Version 7.0 zu verwenden, muss der Client für einen erfolgreichen Handshake zuerst Unterzeichner anfordern. Weitere Informationen finden Sie im Abschnitt "Unterzeichner für Clients und Server aus einem früheren Release abrufen" im Artikel "Sichere Installation zum Abrufen des Clientunterzeichners in SSL".
- Nach Ausführung des Befehls addNode befindet sich der Anwendungsserver in einer neuen SSL-Domäne. Er könnte SSL-Konfigurationen enthalten, die auf Keystore- und Truststore-Dateien zeigen, die nicht mit anderen Servern derselben Domäne interagieren können. Überlegen Sie, welche Server miteinander kommunizieren müssen, und stellen Sie sicher, dass diese in Ihren Truststore-Dateien anerkannt sind.
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.