SSL-Knoten, Anwendungsserver und Cluster isolieren
Mit SSL (Secure Sockets Layer) können Sie sicherstellen, dass alle Clients, die eine Verbindung zu einem Server herstellen müssen, beim Handshake zunächst die Serverauthentifizierung durchlaufen müssen. Mit SSL-Konfigurationen auf Knoten-, Anwendungsserver- und Clusterebene können Sie die Kommunikation zwischen Servern isolieren, die miteinander nicht über sichere Ports kommunizieren sollen.
Bevor Sie versuchen, die von WebSphere Application Server gesteuerte Kommunikation einzugrenzen, müssen Sie die Implementierungstopologie und die Anwendungsumgebung genau verstehen. Wenn Sie einen Knoten, Anwendungsserver oder Cluster isolieren wollen, müssen Sie die Unterzeichner kontrollieren können, die in den der SSL-Konfiguration zugeordneten Truststores enthalten sind. Ein Client, der nicht den Unterzeichner des Servers enthält, kann keine Verbindung zum Server herstellen. Standardmäßig verwendet WebSphere verkettete Zertifikate, und jeder Knoten hat einen eindeutigen Stammzertifikatsunterzeichner. Da die Knoten denselben Stammzertifikatsunterzeichner haben, können alle Server auf diesem Knoten Verbindungen untereinander herstellen. Falls Sie jedoch selbst signierte Zertifikate verwenden, wird der Unterzeichner von dem Server gesteuert, der das persönliche Zertifikat erstellt hat. Sie müssen die selbst signierten Zertifikate dennoch verwalten. Wenn Sie Zertifikate von einer Zertifizierungsstelle (CA, Certificate Authority) anfordern, müssen Sie mehrere CA-Unterzeichner anfordern, da alle Server, die gemeinsam denselben Unterzeichner verwenden, Verbindungen zueinander herstellen können.
Wenn Sie einen Server isolieren müssen, ist die Einschränkung der Authentifizierung auf die Serverseite einer Verbindung kein angemessener Schutz. Jeder Client kann ein Unterzeichnerzertifikat für den Server anfordern und zu seinem Truststore hinzufügen. Außerdem muss zwischen Servern die SSL-Clientauthentifizierung aktiviert sein, damit die Server ihre Verbindungen steuern und entscheiden können, welche Clientzertifikate sie anerkennen. Weitere Informationen hierzu finden Sie im Artikel Enabling Secure Sockets Layer client authentication for a specific inbound endpoint, der sich auch mit der Aktivierung der SSL-Clientauthentifizierung auf Zellenebene beschäftigt.
Eine Isolation erfordert außerdem die Verwendung zentral verwalteter SSL-Konfigurationen für alle oder die meisten Endpunkte in der Zelle. Zentral verwaltete Konfigurationen können im Gegensatz zur direkten Konfiguration oder zur Endpunktkonfiguration bereichsorientiert gestaltet werden, sodass eine Erstellung von SSL-Konfigurationen, Keystores und Truststores für einen bestimmten Geltungsbereich möglich ist. Wenn Sie nur die Eigenschaften auswählen, die Sie für eine SSL-Konfiguration benötigen, sind innerhalb des ausgewählten Geltungsbereichs aufgrund der Vererbungshierarchie von WAS-Zellen nur diese Eigenschaften definiert. Angenommen, Sie definieren eine Konfiguration für den Geltungsbereich eines Knotens. Diese Konfiguration gilt dann für den Anwendungsserver und die einzelnen Endpunkte, die diesem Knoten in der Hierarchie untergeordnet sind. Weitere Informationen finden Sie unter SSL-Konfigurationen zentral mit Eingangs- und Ausgangsebenen zuordnen, SSL-Konfigurationsalias direkt aus einer Endpunktkonfiguration auswählen und SSL-Konfiguration dynamisch einem abgehendem Protokoll und einem fernem sicheren Endpunkt zuordnen.
Wenn Sie die Keystores mit den Chiffrierschlüsseln konfigurieren, müssen Sie in demselben Geltungsbereich arbeiten, für den Sie die SSL-Konfiguration definiert haben. Sie dürfen keinen hierarchisch übergeordneten Bereich auswählen. Angenommen, Sie erstellen einen Keystore mit einem Zertifikat, dessen Hostname Teil des DN (definierten Namens) ist. Diesen Keystore müssten Sie im Knotenverzeichnis des Konfigurationsrepositorys speichern. Erstellen Sie aber ein Zertifikat für den Anwendungsserver, müssen Sie diesen Keystore im Verzeichnis des Anwendungsservers unter dem Anwendungsserver speichern.
Wenn Sie die Truststores konfigurieren, die Vertrauensentscheidungen auf dem Server steuern, müssen Sie überlegen, wie stark Sie die Anwendungsserver isolieren möchten. Sie können die Anwendungsserver nicht von den Node Agents oder dem Deployment Manager isolieren. Sie können jedoch für die SOAP-Connector-Endpunkte dasselbe persönliche Zertifikat oder gegenseitiges Vertrauen konfigurieren. Für die Persistenz von Benennungen ist es erforderlich, dass über den Deployment Manager verlaufende Verbindungen IIOP-Verbindungen sind. Da Anwendungsserver beim Start immer eine Verbindung zu den Node Agents herstellen, erfordert das Protokoll IIOP, dass WebSphere Application Server Vertrauen zwischen den Anwendungsservern und Node Agents aufbaut.
SSL-Isolation für Knoten
WebSphere Application Server verwendet standardmäßig für jeden Knoten ein gesondertes verkettetes Zertifikat, sodass Sie Knoten leicht isolieren können. Ein gemeinsamer Truststore im Zellenverzeichnis des Konfigurationsrepositorys enthält für jeden Knoten, der in die Zelle eingebunden wird, alle Unterzeichner. Nach der Einbindung vertraut jeder Zellenprozess allen anderen Zellenprozessen, weil jede SSL-Konfiguration den gemeinsamen Truststore referenziert.
- Der Deployment Manager muss Verbindungen zu jedem Prozess aufbauen.
- Der Node Agent muss Verbindungen zum Deployment Manager und zu seinen eigenen Anwendungsservern aufbauen.
- Der Anwendungsserver muss Verbindungen zu den Anwendungsservern auf demselben Knoten, zu seinem eigenen Node Agent und zum Deployment Manager aufbauen.

Wenn Sie diesem Keystore und Truststore eine SSL-Konfiguration zuordnen, unterbrechen Sie die Verknüpfung mit dem Truststore der Zelle. Falls Sie den Knoten vollständig isolieren möchten, wiederholen Sie diesen Prozess für jeden Knoten in der Zelle. WebSphere Application Server-SSL-Konfigurationen setzen den Geltungsbereich der Zelle außer Kraft und verwenden stattdessen den Geltungsbereich des Knotens, sodass jeder Prozess in diesem Geltungsbereich die für diesen Bereich ausgewählte SSL-Konfiguration mit dem zugehörigen Zertifikatsalias verwendet. Für ein tragfähiges administratives Vertrauen müssen Sie sicherstellen, dass der Unterzeichner von nodeA im gemeinsamen Truststore und der Unterzeichner der Zelle im Truststore von nodeA enthalten ist. Dieselbe Logik gilt für nodeB. Weitere Informationen finden Sie unter SSL-Konfigurationen zentral mit Eingangs- und Ausgangsebenen zuordnen.
SSL-Isolation für Anwendungsserver
- Ein Anwendungsserverprozess muss möglicherweise mit dem Node Agent und dem Deployment Manager kommunizieren.
- Wenn Sie Anwendungsserverprozesse isolieren, können die SSO-Funktionen für die horizontale Weitergabe inaktiviert werden.

Die dynamische Konfiguration bewirkt, dass server1 auf nodeA mit server1 auf nodeB nur über IIOP kommunizieren kann. Die Regel für dynamische abgehende Verbindungen ist IIOP,nodeBhostname,*. Weitere Informationen finden Sie unter SSL-Konfiguration dynamisch zu einem Protokoll für abgehende Daten und zu einem fernen sicheren Endpunkt zuordnen.
SSL-Isolation für Cluster
Wenn Sie die SSL-Isolation eines Clusters konfigurieren möchten, müssen Sie Anwendungsserver zu Clustern zusammenfassen, anstatt sie zentral dem Geltungsbereich eines Knotens oder dynamisch dem Geltungsbereich eines Servers zuzuordnen. Server eines Clusters können miteinander kommunizieren. Anwendungsserver außerhalb des Clusters können jedoch nicht mit dem Cluster kommunizieren, sodass die Server im Cluster isoliert sind. Angenommen, Sie benötigen verschiedene Anwendungen von verschiedenen Abteilungen und wollen gleichzeitig für die Server-Cluster ein bestimmtes gegenseitiges Basisvertrauen etablieren. Mit der oben für Server beschriebenen SSL-Konfigurationsmethode für dynamische abgehende Verbindungen können Sie den isolierten Cluster bei Bedarf ganz einfach ausdehnen.

IIOP,nodeAhostname,9403|IIOP,nodeAhostname,9404|IIOP,nodeBhostname,9403|IIOP,nodeBhostname,9404
Im Geltungsbereich von Cluster1 müssen Sie eine weitere SSL-Konfiguration erstellen, die eine neue Datei
trust.p12 mit dem Unterzeichner von Cluster2 enthält. Abgehende IIOP-Anforderungen werden demzufolge
an die Ports 9403 und 9404 von nodeAhostname oder an die Ports
9403 und 9404 von nodeBhostname gesendet. Die IIOP-SSL-Portnummern dieser beiden Anwendungsserverprozesse in Cluster2 bezeichnen die Ports.
- Die Datei trust.p12 für Cluster1 enthält Unterzeichner, die eine Kommunikation mit sich selbst (Unterzeichner für Cluster1), zwischen beiden Node Agents (nodeAsigner und nodeBsigner) sowie mit dem Deployment Manager (Unterzeichner für die Zelle) ermöglichen.
- Die Datei trust.p12 für Cluster2 enthält Unterzeichner, die eine Kommunikation mit sich selbst (Unterzeichner für Cluster2), zwischen beiden Node Agents (nodeAsigner und nodeBsigner) sowie mit dem Deployment Manager (Unterzeichner für die Zelle) ermöglichen.
- Node Agent A und Node Agent B können untereinander, mit dem Deployment Manager und mit beiden Clustern kommunizieren.
Die in diesem Artikel beschriebenen Isolierungsmethoden sind aus der SSL-Perspektive dargestellt. Sie müssen aber auch sicherstellen, dass Ports, die keine SSL-Ports sind, geschlossen werden und beachten, dass der Implementierungsdeskriptor von Anwendungen die Vertraulichkeitsvorgabe enthalten muss. In der Anzeige "Eingehender CSIv2-Transport" können Sie beispielsweise festlegen, dass SSL erforderlich ist, und die nicht sicheren Kanalports der Serverportkonfiguration inaktivieren.
Außerdem müssen Sie die SSL-Clientauthentifizierung aktivieren, damit die Bedingungen für die Isolierung auf beiden Seiten einer Verbindung via SSL durchgesetzt werden. Ohne gegenseitige SSL-Clientauthentifizierung kann ein Client einfach per Programm einen Unterzeichner für den Server anfordern und damit die angestrebte Isolierung umgehen. Bei aktivierter SSL-Clientauthentifizierung fordert der Server den Unterzeichner des Clients an, bevor eine Verbindung zustande kommt. Wenn das Protokoll HTTP/S verwendet wird, ist der Client in der Regel ein Browser, ein Web-Service oder eine URL-Verbindung. Bei Verwendung des Protokolls IIOP/S ist der Client normalerweise ein anderer Anwendungsserver oder ein Java™-Client. WebSphere Application Server muss die Clients kennen, um feststellen zu können, ob die SSL-Clientauthentifizierung aktiviert werden kann. Alle Anwendungen, die über ein öffentliches Protokoll verfügbar sind, müssen die SSL-Clientauthentifizierung nicht aktivieren, denn der Client kann möglicherweise kein Zertifikat für die Authentifizierung gegenüber dem Server anfordern.