Isolement d'un noeud, d'un serveur d'applications et d'un cluster SSL (Secure Sockets Layer)
Secure Sockets Layer (SSL) permet de s'assurer que tout client qui tente de se connecter à un serveur au cours de l'établissement de liaison s'authentifie d'abord auprès du serveur. En utilisant des configurations SSL au niveau du noeud, du serveur d'applications et du cluster, vous pouvez isoler la communication entre les serveurs qui ne sont pas autorisés à communiquer avec les autres sur des ports sécurisés.
Avant de tenter d'isoler les communications contrôlées par WebSphere Application Server, vous devez bien comprendre la topologie de déploiement et l'environnement d'application. Pour isoler un noeud, un serveur d'applications ou un cluster, vous devez pouvoir contrôler les signataires contenus dans les fichiers de clés certifiées associés à la configuration SSL. Lorsque le client ne contient pas de signataire du serveur, il ne peut pas établir de connexion au serveur. Par défaut, WebSphere utilise des certificats chaînés ; chaque noeud est associé à un signataire de certificat racine unique. Comme le noeud est associé à un même signataire racine, les serveurs qu'il comprend peuvent se connecter l'un à l'autre, puisqu'ils partagent ce même signataire. Cependant, si vous utilisez des certificats auto-signés, vous serez chargé de les gérer, mais le serveur qui a créé le certificat personnel contrôlera seul le signataire. Si vous obtenez des certificats d'une autorité de certification, vous devez obtenir plusieurs signataires d'autorité de certification car tous les serveurs peuvent se connecter les uns aux autres s'ils partagent le même signataire.
L'authentification d'une connexion côté serveur uniquement n'est pas une protection adéquate lorsque vous souhaitez isoler un serveur. Tout client peut obtenir un certificat de signataire pour le serveur et l'ajouter à son magasin de relations de confiance. L'authentification client SSL doit également être activée entre les serveurs afin que le serveur puisse contrôler ses connexions en décidant quels certificats client sont dignes de confiance. Pour plus d'informations, voir Activation de l'authentification client SSL (Secure Sockets Layer) pour un noeud final de communication entrante qui s'applique également à l'activation de l'authentification client SSl au niveau de la cellule.
Pour mettre en oeuvre l'isolement, vous devez également utiliser des configurations SSL gérées de manière centralisée pour tous les points de contact de la cellule ou la plupart d'entre eux. Il est possible de définir la portée des configurations gérées de manière centralisée, contrairement à la sélection de la configuration directe ou de point de contact ; d'autre part, ces configurations permettent de créer des configurations SSL, des magasins de clés et des magasins de relations de confiance pour une portée particulière. En raison de la hiérarchie d'héritage des cellules WebSphere Application Server, si vous sélectionnez uniquement les propriétés nécessaires pour une configuration SSL, seules ces propriétés seront définies au niveau de la portée sélectionnée ou à un niveau inférieur. Par exemple, si vous définissez la configuration au niveau de la portée du noeud, celle-ci s'applique au serveur d'applications et aux portées de point de contact individuel située sous la portée du noeud. Pour pus d'informations, voir Association de configuration SSL (Secure Sockets Layer) de manière centralisée avec des portées entrantes et sortantes, Sélection d'un alias de configuration SSL directement depuis une configuration de noeud final, et Association d'une configuration SSL (Secure Sockets Layer) dynamiquement avec un protocole sortant et un noeud final sécurisé distant.
Lorsque vous configurez les magasins de clés, qui contiennent des clés de chiffrement, vous devez travailler au même niveau de portée que celui auquel vous avez défini la configuration SSL et non à un niveau de portée supérieur. Par exemple, si vous créez un magasin de clés qui contient un certificat dont le nom d'hôte fait partie du nom distinctif, stockez ce magasin de clés dans le répertoire de noeud du référentiel de configuration. Si vous décidez de créer un certificat pour le serveur d'applications, stockez ce magasin de clés sur le serveur d'applications contenu dans le répertoire du serveur d'applications.
Lorsque vous configurez les magasins de relations de confiance qui contrôlent les décisions relatives à l'établissement de relations de confiance sur le serveur, vous devez savoir à quel niveau vous souhaitez isoler les serveurs d'applications. Vous ne pouvez pas isoler ces derniers des agents de noeud ou du gestionnaire de déploiement. Toutefois, vous pouvez configurer les points de contact du connecteur SOAP avec le même certificat personnel ou de manière à ce que la confiance soit partagée. La persistance du nommage requiert des connexions IIOP lors de la transmission au gestionnaire de déploiement. Etant donné que les serveurs d'applications se connectent toujours aux agents de noeud lorsque le serveur démarre, le protocole IIOP exige que WebSphere Application Server établisse une relation de confiance entre les serveurs d'applications et les agents de noeud.
Etablissement de l'isolement SSL des noeuds
Par défaut, l'installation de WebSphere Application Server a recours à un certificat chaîné unique pour chaque noeud, de façon que les noeuds puissent être isolés plus facilement. Un magasin de relations de confiance commun, situé dans le répertoire de cellule du référentiel de configuration, contient tous les signataires de chaque noeud fédéré dans la cellule. Après la fédération, chaque processus de cellule considère tous les autres processus de la cellule comme étant dignes de confiance car chaque configuration SSL référence le magasin de relations de confiance commun.
- Le gestionnaire de déploiement doit initier les connexions à tout processus.
- L'agent de noeud doit initier les connexions au gestionnaire de déploiement et à ses propres serveurs d'applications.
- Les serveurs d'applications doivent initier des connexions aux serveurs d'applications du même noeud, à son propre agent de noeud et au gestionnaire de déploiement.

Lorsque vous associez une configuration SSL à ce magasin de clés et à ce magasin de relations de confiance, vous rompez le lien avec le magasin de relations de confiance doté d'une portée au niveau de la cellule. Pour isoler complètement les noeuds, répétez ce processus pour chaque noeud de la cellule. Les configurations SSL de WebSphere Application Server utilisent la portée de noeud à la place de la portée de la cellule, afin que chaque processus à ce niveau de portée utilise la configuration SSL et l'alias de certificat que vous avez sélectionnés à ce niveau de portée. Pour établir des relations de confiance administratives appropriées, vérifiez que le signataire du noeud A se trouve dans le magasin de relations de confiance commun et que le signataire de la cellule se trouve dans le magasin de relations de confiance du noeud A. Le même logique s'applique également au noeud B. Pour plus d'informations, voir Association de configuration SSL (Secure Sockets Layer) de manière centralisé avec des portées entrantes et sortantes.
Etablissement de l'isolement SSL du serveur d'applications
- Un processus de serveur d'applications peut avoir besoin de communiquer avec l'agent de noeud et le gestionnaire de déploiement.
- L'isolement des processus de serveur d'applications les uns par rapport aux autres peut entraîner la désactivation des fonctions de connexion unique pour la propagation horizontale.

La configuration dynamique permet au serveur 1 du noeud A de communiquer avec le serveur 1 du noeud B via le protocole IIOP. La règle de connexion sortante dynamique est IIOP,nodeBhostname,*. Pour plus d'informations, voir Association d'une configuration SSL (Secure Sockets Layer) dynamiquement avec un protocole sortant et un noeud final sécurisé distant.
Etablissement de l'isolement SSL du cluster
Vous pouvez configurer les serveurs d'applications dans des clusters au lieu de définir leur portée de manière centralisée au niveau du noeud ou de manière dynamique sur le serveur pour établir l'isolement SSL du cluster. Si les serveurs configurés en cluster peuvent communiquer entre eux, les serveurs d'applications situés à l'extérieur du cluster ne peuvent pas communiquer avec ce dernier, ce qui isole les serveurs faisant partie du cluster. Par exemple, vous pouvez séparer des applications de départements différents tout en conservant un niveau de confiance de base entre les serveurs configurés en cluster. En utilisant la méthode de configuration SSL de connexions sortantes dynamiques décrite précédemment pour les serveurs, vous pouvez aisément étendre les clusters isolés, si nécessaire.

IIOP,nodeAhostname,9403|IIOP,nodeAhostname,9404|IIOP,nodeBhostname,9403|IIOP,nodeBhostname,9404
Vous devez créer une autre configuration SSL au niveau de la portée du cluster 1 qui contient un nouveau fichier trust.p12 avec le signataire du cluster 2.
Ainsi, les demandes IIOP sortantes sont acheminées soit vers les ports nodeAhostname 9403 et 9404, soit vers les ports nodeBhostname 9403 et 9404. Les numéros de port SSL IIOP sur ces deux processus de serveur d'applications faisant partie du cluster 2 identifient les ports. - Le magasin de relations de confiance trust.p12 du cluster 1 contient des signataires autorisant les communications avec lui-même (signataire du cluster 1), entre les deux agents de noeud (nodeAsigner et nodeBsigner) et avec le gestionnaire de déploiement (signataire de la cellule).
- Le magasin de relations de confiance trust.p12 du cluster 2 contient des signataires autorisant les communications avec lui-même (signataire du cluster 2), entre les deux agents de noeud (nodeAsigner et nodeBsigner) et avec le gestionnaire de déploiement (signataire de la cellule).
- L'agent de noeud A et l'agent de noeud B peuvent communiquer entre eux, mais aussi avec le gestionnaire de déploiement et les deux clusters.
Bien que les méthodes d'isolement du point de vue SSL soient présentées, vous devez également vous assurer que les ports non SSL sont fermés ou que les applications requièrent la contrainte de confidentialité dans le descripteur de déploiement. Par exemple, vous pouvez définir le panneau de transport des communications entrantes CSIv2 de manière à ce que SSL soit requis et désactiver les ports du canal qui ne sont pas sécurisés à partir de la configuration des ports du serveur.
De plus, vous devez activer l'authentification client SSL pour que SSL puisse s'assurer que les conditions requises pour l'isolement soient remplies aux deux extrémités d'une connexion. Sans authentification client SSL mutuelle, un client peut aisément obtenir, par programme, un signataire pour le serveur, ce qui est contraire au principe d'isolement. Avec l'authentification client SSL, le serveur a besoin du signataire du client pour que la connexion aboutisse. Pour le protocole HTTP/S, le client est généralement un navigateur, un service Web ou une connexion URL. Pour le protocole IIOP/S, le client est généralement un autre serveur d'applications ou un client Java™. WebSphere Application Server doit connaître les clients pour pouvoir déterminer si l'activation de l'authentification du client SSL est possible. Toute application disponible par le biais d'un protocole public doit activer l'authentification client SSL car le client peut ne pas obtenir de certificat pour s'authentifier auprès du serveur.