Considérations de sécurité à prendre en compte lors de l'enregistrement d'un noeud de serveur d'applications de base auprès de l'agent administratif

Vous déciderez sans doute de centraliser le contrôle de vos serveurs d'applications de base autonomes en les enregistrant auprès de l'agent administratif. Si la sécurité est activée sur votre serveur d'applications de base, certaines considérations sont à prendre en compte. Les considérations de sécurité qui suivent s'appliquent à l'utilisation des commandes registerNode et deregisterNode.

L'objectif de la commande registerNode est de prendre un noeud de base autonome et de le convertir en un noeud géré par l'agent administratif. Le principal paramètre de la commande registerNode est profilePath qui indique où l'agent administratif peut trouver le noeud sur la machine locale. Le paramètre portsFile contient des clés permettant de déterminer les ports qu'écoute l'agent administratif pour le noeud de base. Le format est le même que pour la ligne de commande manageProfiles.

La commande registerNode s'exécute depuis l'agent administratif lui-même. Elle permet d'enregistrer un noeud auprès d'un agent administratif. Ce dernier doit être sur le même système que le noeud à enregistrer. La commande registerNode n'est valide que sur un noeud de base. SI un noeud a été fédéré sur un gestionnaire de déploiement, la commande registerNode échouera et signalera une erreur.

Tout d'abord le processus d'enregistrement des profils des signataires de l'échange traite la configuration SSL, dont il tire les signataires du certificat racine à partir du fichier NodeDefaultRootStore de l'agent administratif puis il les stocke dans le fichier NodeDefaultTrustStore du profil cible. Ensuite, ce processus obtient les signataires du certificat racine à partir du fichier NodeDefaultRootStore du profil cible puis il les stocke dans le fichier NodeDefaultTrustStore de l'agent administratif. Les signataires sont stockés dans le magasin d'accréditations des profils cible à l'aide du préfixe d'alias "agent_signer", puis stockés dans le magasin d'accréditations des agents administratifs à l'aide du préfixe d'alias "<profileName>_signer".

Ensuite, le processus d'enregistrement de profils des signataires de l'échange traite la configuration d'authentification RSAToken, dont il tire les signataires du certificat racine du NodeRSATokenRootStore de l'agent administratif puis les stocke dans le NodeRSATokenTrustStore du profil cible. Ensuite, ce processus obtient les signataires du certificat racine à partir du fichier NodeRSATokenRootStore du profil cible puis il les stocke dans le fichier NodeRSATokenTrustStore de l'agent administratif. Les signataires sont stockés dans le magasin d'accréditations du profil cible à l'aide du préfixe d'alias "agent_signer", puis stockés dans le magasin d'accréditations des agents administratifs à l'aide du préfixe d'alias "<profileName>_signer".

De plus, le processus d'enregistrement stocke tous les signataires du certificat racine (SSL et RSAToken) de l'agent administratif dans le magasin d'accréditations client du profil cible (ClientDefaultTrustStore par défaut).

La commande deregisterNode active le processus de désenregistrement qui supprime de l'agent administrative et du profil de base tous les signataires échangés pendant le processus d'enregistrement. La configuration du noeud de base est conservée, mais il est marqué comme non enregistré auprès d'un agent administratif. Cette commande n'est valide que sur un noeud de base précédemment enregistré.

Les points suivants doivent être pris en compte lors de l'exécution de la commande registerNode alors que la sécurité est activée.
  • Lorsque vous essayez d'exécuter des commandes de gestion du système telles que la commande registerNode, vous devez explicitement spécifier les justificatifs d'administration permettant d'effectuer l'opération. La commande registerNode accepte les paramètres -username et -password pour l'indication de l'ID utilisateur et du mot de passe. 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 registerNode :

    registerNode -profilePath /WebSphere/AppServer/profiles/default -host localhost -connType SOAP -port 8877 -username WSADMIN -password ADMINPWD

  • Avant son enregistrement sur un agent d'administration, la sécurité administrative d'un noeud doit être activée ou désactivée.
  • Une fois un noeud enregistré, vous ne pouvez plus activer ou désactiver sa sécurité administrative (ni celle d'un autre noeud enregistré) tant qu'il n'est pas désenregistré.
Il est important de bien comprendre les interactions de sécurité entre les serveurs répartis pour limiter les incidents liés aux communications sécurisées. La sécurité complique les choses car elle nécessite la gestion d'une fonction supplémentaire. L'agent administratif fournit une manière de gérer des fonctions supplémentaires tout en protégeant la sécurité.

Questions et réponses d'ordre général susceptibles de vous aider lors de l'utilisation de la commande registerNode avec la sécurité

Est-il possible de modifier le paramètre de sécurité d'un noeud une fois qu'il a été enregistré auprès d'un agent d'administration ?
La sécurité administrative peut être activée ou désactivée dans l'agent d'administration et tous les noeuds enregistrés. Par ailleurs, les noeuds enregistrés et l'agent d'administration peuvent avoir d'autres configurations de sécurité différentes avant ou après l'enregistrement du noeud. Toutefois, la configuration de la sécurité administrative doit être cohérente entre l'agent d'administration et les noeuds enregistrés.
Est-il possible de modifier le paramètre de sécurité d'un agent d'administration après l'enregistrement d'un noeud ?
Non. Voir la question et la réponse précédentes. La configuration de la sécurité administrative ne serait pas cohérente entre les agents d'administration et les noeuds enregistrés.
La sécurité doit-elle être activée pour un noeud si elle est déjà activée pour l'agent d'administration ?
Oui. La sécurité administrative doit être activée pour un noeud si elle est déjà activée pour l'agent d'administration.
L'agent d'administration et le noeud peuvent-ils avoir des paramètres et des valeurs de sécurité différents avant l'enregistrement du noeud ?
Oui, à l'exception de la valeur de sécurité administrative.
Quelle est la syntaxe correcte des paramètres -username nom d'utilisateur / -password mot de passe et -nodeusername nom_utilisateur_noeud / -nodepassword mot de passe_noeud dans la commande registerNode ?
Le paramètre nom d'utilisateur / mot de passe fait référence à un ID utilisateur et un mot de passe d'administration définis dans l'agent d'administration. Le paramètre nom_utilisateur_noeud / mot de passe_noeud fait référence au nom d'utilisateur et au mot de passe d'administration définis dans le noeud à enregistrer.
Remarque : Le paramètre nom_utilisateur_noeud / mot de passe_noeud est requis uniquement lorsque la sécurité administrative est activée sur l'agent d'administration et sur le noeud à enregistrer.
Exemple de syntaxe de la commande RegisterNode :
${WAS_ROOT}/profiles/AA_1/bin/registerNode.sh
-connType SOAP
-port ${soap}
-username $SUSER
-password $SPASS
-profilePath ${WAS_ROOT}/profiles/AS_1_1
-nodeusername $SUSER2
-nodepassword $SPASS2 
[z/OS]
Considération spécifique à z/OS : Sous z/OS, l'ID utilisateur du contrôleur d'un agent administratif doit avoir pour groupe de configuration Unix System Services par défaut la configuration de groupe du/des serveur(s) d'application qu'il va administrer. L'identifiant d'utilisateur du serviteur de l'agent administratif doit être connecté au même groupe. La manière la plus simple pour le vérifier est d'indiquer un unique ID de groupe de configuration lors de la configuration de l'agent administratif et de son/ses serveur(s) d'applications.

Si la sécurité administrative s'appuie sur un registre local System Authorization Facility (SAF), l'ID utilisateur utilisé pour appeler les commandes registerNode.sh et deregisterNode.sh doit avoir les droits d'administrateur pour l'agent administratif et doit également être connecté au groupe de configuration Unix System Services de l'agent administratif et de son ou ses serveurs d'applications.

Si le stockage des certificats utilise des fichiers de clés SAF, les signataires ne sont pas échangés pendant l'enregistrement. Vous devez vous assurer que les certificats serveur de l'agent administratif, et des serveurs d'applications qu'il va administrer, partagent le même signataire et que ce dernier est dans le fichier de clés de l'ID administrateur utilisé pour appeler registerNode.sh ou deregisterNode.sh.
Remarque : Le fichier de clés utilisé pendant l'enregistrement ou le désenregistrement est celui associé à l'agent administratif.

Icône indiquant le type de rubrique Rubrique de référence



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rsec_7register_admin_agent
Nom du fichier : rsec_7register_admin_agent.html