Vous êtes sur la page 1sur 5

Isolement d'un noeud, d'un serveur d'applications et d'un cluster SSL (S... http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm....

Express version 7.0 (Plateformes réparties et Windows) > Développement et déploiement d'applications > Développement d'applications WebSphere > Sécurité > Tâches en
cours : Sécurisation des ressources > Sécurisation des communications > Communications sécurisées à l'aide de SSL

Serveur d'applications - Express, Version 7.0


Systèmes d'exploitation : AIX, HP-UX, Linux, Solaris, Windows
Personnalisation de la table des matières et des résultats de la recherche

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 précis ; cette rubrique 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 plus d'informations, voir Association centralisée des configurations SSL
(Secure Sockets Layer) avec les niveaux de communications entrantes et sortantes, Sélection d'un alias de
configuration SSL directement dans une configuration de point final et Association dynamique d'une
configuration SSL (Secure Sockets Layer) à un protocole de communications sortantes 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.

1 sur 5 11/11/2010 12:06


Isolement d'un noeud, d'un serveur d'applications et d'un cluster SSL (S... http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm....

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.

Vous pouvez modifier la configuration par défaut afin que chaque noeud possède son propre magasin de
relations de confiance, et que chaque serveur d'applications du noeud considère comme digne de confiance
uniquement l'agent de noeud qui utilise le même certificat personnel. Vous devez également ajouter le
signataire au fichier de clés certifiées du noeud afin que WebSphere Application Server puisse établir des
relations sécurisées avec le gestionnaire de déploiement. Pour isoler le noeud, vérifiez que les conditions
ci-dessous sont remplies.
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.

La figure 1 présente l'agent de noeud A qui contient un magasin de clés key.p12 et un magasin de relations de
confiance trust.p12 au niveau du noeud du référentiel de configuration pour le noeud A.

Figure 1.

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

2 sur 5 11/11/2010 12:06


Isolement d'un noeud, d'un serveur d'applications et d'un cluster SSL (S... http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm....

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 la rubrique Association centralisée des configurations
SSL (Secure Sockets Layer) avec les niveaux de communications entrantes et sortantes.

Etablissement de l'isolement SSL du serveur d'applications


Il est plus complexe d'isoler les uns des autres les processus de serveur d'applications que les noeuds. Vous
devez prendre en compte la conception d'application et les condition de topologie ci-dessous.
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.

Si vous configurez les connexions SSL sortantes de manière dynamique, ces conditions peuvent être remplies.
Lorsque vous définissez un protocole de connexion sortante, un hôte cible et un port spécifiques pour chaque
configuration SSL différente, vous pouvez remplacer la configuration pour laquelle la portée a été définie.

La figure 2 indique comment isoler complètement un serveur d'applications, bien que cette approche soit en
réalité plus complexe.

Figure 2.

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 dynamique d'une configuration SSL (Secure Sockets Layer) à un protocole de
communications sortantes et un noeud final sécurisé distant

3 sur 5 11/11/2010 12:06


Isolement d'un noeud, d'un serveur d'applications et d'un cluster SSL (S... http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm....

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 pour les serveurs ci-dessus, vous pouvez aisément étendre
les clusters isolés, si nécessaire.

La figure 3 présente un exemple de configuration de cluster dans laquelle le cluster 1 contient un magasin de
clés key.p12 comportant son propre certificat auto-signé, et un magasin de relations de confiance trust.p12,
situé dans le répertoire config/cells/<nomcellule>/clusters/<nomcluster>.

Figure 3.

Dans cet exemple, le cluster 1 peut contenir des applications Web et le cluster 2 des applications EJB. Après
avoir étudié les différents protocoles, vous choisissez d'activer le trafic IIOP entre les deux clusters. Votre
tâche consiste à définir une configuration SSL de connexion sortante dynamique au niveau de la portée du
serveur 1 avec les propriétés suivantes :

IIOP,nodeAhostname,9403|IIOP,nodeAhostname,9404|IIOP,nodeBhostname,9403|IIOP,nodeBh
ostname,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.

Dans la figure 3, prenez note des éléments suivants concernant les configurations d'isolement du cluster :
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).

4 sur 5 11/11/2010 12:06


Isolement d'un noeud, d'un serveur d'applications et d'un cluster SSL (S... http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm....

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.

Pour plus d'informations, voir la rubrique Association dynamique d'une configuration SSL (Secure Sockets
Layer) à un protocole de communications sortantes et un noeud final sécurisé distant.

Bien que cet article présente les méthodes d'isolement du point de vue SSL, 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.

Remarque : L'objet de cet article n'est pas de décrire tous les facteurs à prendre en compte pour obtenir un
isolement complet.

Concepts associés
Sélection des connexions sortantes dynamiques des configurations SSL
Gestion centrale des configurations SSLo

Tâches associées
Association centralisée des configurations SSL (Secure Sockets Layer) avec les niveaux de communications
entrantes et sortantes
Sélection d'un alias de configuration SSL directement dans une configuration de point final
Association dynamique d'une configuration SSL (Secure Sockets Layer) à un protocole de communications
sortantes et un noeud final sécurisé distant

Rubrique de concept

Conditions d'utilisation | Commentaires

Dernière mise à jour : Sep 8, 2009 5:21:17 AM EDT


http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic =/c om.ibm.websphere.express.doc/info/exp/ae/c sec _sslisolation.html

5 sur 5 11/11/2010 12:06