Considérations de sécurité à prendre en compte lors de l'ajout d'un serveur d'applications de base à WebSphere Application Server, Network Deployment
Vous déciderez sans doute de centraliser la configuration de vos serveurs d'applications de base autonomes en les ajoutant dans une cellule de WebSphere Application Server, Network Deployment. Si la sécurité est activée sur votre serveur d'applications de base, certaines considérations sont à prendre en compte. La question principale, lors de l'ajout d'un noeud à la cellule, consiste à savoir si les registres d'utilisateurs du serveur d'applications de base et du gestionnaire de déploiement sont les mêmes.
Lorsque vous ajoutez
un noeud à la cellule, vous héritez automatiquement du registre
d'utilisateurs et du mécanisme d'authentification de la cellule.
Lorsque
vous ajoutez un noeud à une cellule, le noeud que vous venez de fédérer hérite automatiquement du registre d'utilisateurs (système d'exploitation local, LDAP ou personnalisé), du mécanisme d'authentification (LTPA) et du paramètre d'autorisation (liaisons WebSphere ou profils EJBROLE SAF) de la cellule WebSphere
Application Server, Network Deployment existante.
Dans le cadre d'une sécurité distribuée, tous les serveurs de la cellule doivent utiliser les mêmes registre d'utilisateurs et mécanisme d'authentification. Après une modification du registre d'utilisateurs, vous devez modifier vos applications pour que les mappages d'utilisateurs et de groupes à des rôles soient corrects dans le nouveau registre d'utilisateurs. Voir l'article sur Affectation d'utilisateurs et de groupes à des rôles.
L'infrastructure de clé publique SSL (Secure Sockets Layer) est un autre facteur important à prendre en compte. Avant d'exécuter la commande addNode avec le gestionnaire de déploiement, vérifiez que la commande addNode peut communiquer en tant que client SSL avec le gestionnaire de déploiement. Cette communication requiert que le magasin des tiers dignes de confiance de la commande addNode configuré dans le fichier sas.client.props contienne le certificat signataire du certificat personnel du gestionnaire de déploiement, tel qu'il apparaît dans le fichier de clés spécifié dans la console d'administration.
- Lorsque vous essayez d'exécuter des commandes de gestion du système telles
que la commande addNode, vous devez explicitement spécifier les justificatifs
d'administration permettant d'effectuer l'opération. La commande addNode
accepte les paramètres -username et -password pour l'indication de l'ID
utilisateur et du mot de passe, respectivement.
L'ID utilisateur et le mot de passe
spécifiés doivent correspondre à ceux d'un administrateur ; par exemple, un utilisateur
membre des utilisateurs de la console disposant des droits Utilisateur ou
Administrateur ou l'ID administrateur configuré dans le registre d'utilisateurs. Voici
un exemple de la commande addNode :
addNode CELL_HOST 8879 -includeapps -username utilisateur -password motdepasse.
Le paramètre -includeapps est facultatif, mais il tente d'inclure les applications du serveur dans le gestionnaire de déploiement. La commande addNode risque d'échouer si les registres d'utilisateurs employés par WebSphere Application Server et le gestionnaire de déploiement ne sont pas les mêmes. Pour y remédier, vous pouvez soit rendre identiques les registres d'utilisateurs, soit désactiver la sécurité. Si vous modifiez les registres d'utilisateurs, veillez à vérifier que les mappages utilisateurs à rôles et groupes à rôles sont corrects. Pour plus d'informations sur la syntaxe de la commande addNode, voir rubrique Commande addNode.Remarque : Vous pouvez également exécuter la commande addNode à l'aide de l'outil de gestion des profils de WebSphere z/OS ou de la commande zpmt. Si vous émettez la commande addNode avec la sécurité activée à l'aide de l'outil de gestion des profils de WebSphere z/OS ou de la commande zpmt, vous devez entrer un ID utilisateur doté des droits requis et spécifier les options -user et -password.
- L'ajout d'un noeud distant sécurisé via la console d'administration n'est pas pris en charge. Vous pouvez soit désactiver la sécurité sur le noeud distant avant d'effectuer l'opération, soit effectuer l'opération à partir de la ligne de commande en utilisant le script addNode.
Avant d'exécuter la commande addNode, vous devez vérifier que les fichiers de clés certifiées installés sur les noeuds peuvent communiquer avec les fichiers de clés du gestionnaire de déploiement, et vice versa. Si vous utilisez les fichiers DummyServerKeyFile et DummyServerTrustFile par défaut, cette erreur ne doit pas survenir car ces fichiers peuvent déjà communiquer. Toutefois, n'utilisez jamais ces fichiers fictifs (dummy) dans un environnement de production.
Avant d'exécuter la commande addNode, vous devez vérifier que les fichiers de clés certifiées installés sur les noeuds communiquent avec les fichiers de clés et les fichiers de clés SAF (System Authorization Facility) appartenant au gestionnaire de déploiement, et vice versa. Cette opération aboutit si vous générez des certificats pour le gestionnaire de déploiement utilisant la même autorité de certification que celle utilisée par les processus d'agent de noeud. Les configurations SSL ci-après doivent contenir des fichiers de clés et des fichiers de clés certifiées entre lesquels des interactions sont possibles.
- Le répertoire SSL système défini dans la console d'administration à l'aide de .
- Le répertoire SSL du connecteur JMX approprié si SOAP est défini dans .
- Le répertoire SSL spécifié dans .
Remarque : WebSphere Application Server for z/OS définit des domaines de sécurité à l'aide des préfixes de profil SAF (anciennement appelés domaines de sécurité z/OS) dans l'outil de gestion des profils de WebSphere z/OS ou dans la commande zpmt. Soyez prudent lorsque vous ajoutez un noeud dans une configuration de gestionnaire de déploiement, qui définit un nom de domaine de sécurité différent.- Lorsqu'un client d'une édition antérieure tente d'utiliser la commande addNode pour établir une fédération auprès d'un gestionnaire de déploiement 7.0, le client doit tout d'abord obtenir des signataires pour que l'établissement de la liaison puisse aboutir. Pour plus d'informations, voir la rubrique relative à l'obtention de signataires pour les clients et les serveurs d'une édition antérieure dans l'article concernant la sécurisation de l'installation pour l'extraction de signataire client dans SSL.
- Une fois la commande addNode exécutée, le serveur d'applications se trouve dans un nouveau domaine SSL. Il peut contenir des configurations SSL pointant vers des fichiers de clés et des fichiers de clés certifiées non préparés pour interagir avec d'autres serveurs du même domaine. Déterminez les serveurs qui communiquent entre eux et vérifiez que ces serveurs sont dignes de confiance dans vos fichiers de magasin des tiers dignes de confiance.
Si des incidents liés à la sécurité se produisent dans l'environnement WebSphere Application Server, Network Deployment, voir Traitement des incidents liés aux configurations de sécurité pour trouver des informations sur un incident spécifique. Lorsqu'il est nécessaire de consulter des informations de trace pour corriger une erreur, dans les cas où les serveurs sont répartis, ces informations doivent souvent être collectées simultanément sur tous les serveurs lors de la reconstitution de l'incident. Cette trace peut être activée de manière dynamique ou statique, selon le type d'incident.