Consideraciones sobre la seguridad al registrar un nodo de servidor de aplicaciones base en el agente administrativo

Es posible que decida centralizar el control de los servidores de aplicaciones base autónomos registrándolos en el agente administrativo. Si el servidor de aplicaciones base está configurado actualmente con la seguridad, hay algunos puntos que deben tenerse en cuenta. Estas consideraciones sobre la seguridad se refieren al uso del mandato registerNode y el mandato deregisterNode.

El objetivo del mandato registerNode es tomar un nodo base autónomo y convertirlo en uno que esté gestionado por el agente administrativo. El parámetro principal del mandato registerNode es profilePath, que especifica en qué lugar de la máquina local el agente administrativo puede encontrar el nodo. El parámetro portsFile contiene claves para determinar los puertos en los que el agente administrativo está a la escucha, por cuenta del nodo base. El formato es el mismo para la línea de mandatos manageProfiles.

El mandato registerNode se ejecuta desde el mismo agente administrativo. Se utiliza para registrar un nodo en un agente administrativo. Es necesario que el agente administrativo se encuentre en el mismo sistema que el nodo que se va a registrar. El mandato registerNode sólo es válido en un nodo base. Si un nodo se ha federado en un gestor de despliegue, el mandato registerNode falla con un error.

En primer lugar, el proceso de intercambio de firmantes para el registro de perfiles procesa la configuración de capa de sockets segura (SSL) por omisión, en la que obtiene los firmantes del certificado raíz del NodeDefaultRootStore del agente administrativo y los almacena en el NodeDefaultTrustStore del perfil de destino. A continuación, el proceso obtiene los firmantes del certificado raíz del NodeDefaultRootStore del perfil de destino y los almacena en el NodeDefaultTrustStore del agente administrativo. Los firmantes se almacenan en el almacén de confianza de los perfiles de destino mediante el prefijo de alias "agent_signer", y se almacenan en el almacén de confianza de los agentes administrativos mediante el prefijo de alias <profileName>_signer".

A continuación, el proceso de intercambio de firmantes para el registro de perfiles procesa la configuración de autenticación RSAToken, en el que obtiene los firmantes del certificado raíz y los almacena en el NodeRSATokenTrustStore del perfil de destino. A continuación, el proceso obtiene los firmantes del certificado raíz del NodeRSATokenRootStore del perfil de destino y los almacena en el NodeRSATokenTrustStore del agente administrativo. Los firmantes se almacenan en el almacén de confianza del perfil de destino mediante el prefijo de alias "agent_signer", y se almacenan en el almacén de confianza de los agentes administrativos mediante el prefijo de alias <profileName>_signer".

Adicionalmente, el proceso de registro almacena todos los firmantes del certificado raíz (SSL y RSAToken) del agente administrativo en el almacén de confianza del cliente del perfil de destino (ClientDefaultTrustStore predeterminado).

El mandato deregisterNode activa el proceso de anulación del registro en el que se eliminan todos los firmantes intercambiados durante el proceso de registro tanto del agente administrativo como del perfil base. La configuración del nodo base se conserva, excepto que se marca como no registrado en un agente administrativo. Este mandato sólo es válido para un nodo base anteriormente registrado.

A continuación se indican otras cuestiones que deben tenerse en cuenta al ejecutar el mandato registerNode con la seguridad:
  • Al intentar ejecutar mandatos de gestión de sistema como el mandato registerNode, es necesario especificar de forma explícita las credenciales administrativas para llevar a cabo la operación. El mandato registerNode acepta los parámetros -username y -password para especificar el ID de usuario y la contraseña, respectivamente. El ID de usuario y la contraseña que se especifiquen deben ser de un usuario administrativo; por ejemplo, un usuario que es miembro de los usuarios de la consola con privilegios de administrador, o bien el ID de usuario administrador configurado en el registro de usuario. A continuación se muestra un ejemplo del mandato registerNode:

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

  • Antes de realizar el registro de un nodo a un agente administrativo, se debe habilitar o inhabilitar la seguridad administrativa del nodo.
  • Una vez que se ha registrado el nodo, no es posible habilitar o inhabilitar la seguridad administrativa del mismo (no de ningún otro nodo registrado) hasta que se haya anulado el registro del nodo.
La comprensión correcta de las interacciones de seguridad entre servidores distribuidos reducirá la cantidad de problemas detectados con las comunicaciones seguras. La seguridad añade complejidad porque es necesario gestionar funciones adicionales. El agente administrativo proporciona un medio para gestionar funciones adicionales conservando la seguridad.

Preguntas y respuestas generales que pueden ayudar a utilizar registerNode con seguridad

¿Se puede cambiar el valor de seguridad de un nodo después de haberlo registrado en un agente administrativo?
La seguridad administrativa debe habilitarse o inhabilitarse en el agente administrativo y en todos los nodos registrados. Aparte de esto, los nodos registrados y el agente administrativo pueden tener otras configuraciones de seguridad diferentes antes de registrar el nodo o después. Sin embargo, la configuración de la seguridad administrativa debe ser coherente entre el agente administrativo y los nodos registrados.
¿Se puede cambiar el valor de seguridad del agente administrativo tras haber registrado un nodo?
No. Consulte la pregunta y respuesta anterior. La configuración de la seguridad administrativa no sería coherente entre los agentes administrativos y los nodos registrados.
¿Es necesario que un nodo tenga la seguridad habilitada si el agente administrativo tiene la seguridad habilitada?
Sí. Es necesario que un nodo tenga la seguridad administrativa habilitada si el agente administrativo tiene la seguridad administrativa habilitada.
¿El agente administrativo y el nodo pueden tener valores de seguridad y otros valores diferentes antes de registrar el nodo?
Sí, excepto el valor de la seguridad administrativa.
¿Cuál es el uso correcto de los parámetros: -username nombre_usuario / -password contraseña y -nodeusername nombre_usuario_nodo / -nodepassword contraseña_nodo en el mandato registerNode?
username / password hace referencia a un usuario administrativo y contraseña definidos en el agente administrativo. nodeusername / nodepassword hace referencia al usuario administrativo y contraseña definidos en el nodo que se va a registrar.
Nota: nodeusername / nodepassword sólo son necesarios cuando la seguridad administrativa está habilitada en el agente administrativo y en el nodo que se va a registrar.
Ejemplo de uso de 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]
Consideraciones especiales para z/OS: En z/OS, el ID de usuario del controlador del agente administrativo debe tener como grupo de configuración de Unix System Services predeterminado al grupo de configuración de los servidores de aplicaciones que administrará. El ID de usuario del sirviente del agente administrativo debe estar conectado al mismo grupo. La manera más sencilla de asegurarse de esto consiste en especificar un único ID de grupo de configuración al configurar el agente administrativo y sus servidores de aplicaciones.

Cuando un registro local de SAF (System Authorization Facility) se utilice para la seguridad administrativa, el ID de usuario que se utilice para invocar los mandatos registerNode.sh y deregisterNode.sh deberá tener privilegios administrativos para el agente administrativo y estar conectado también al grupo de configuración de Unix System Services para el agente administrativo y sus servidores de aplicaciones.

Cuando se utilicen conjuntos de claves SAF para el almacenamiento de certificados, los firmantes no se intercambiarán durante el registro. Debe asegurarse de que los certificados de usuario del agente administrativo y los servidores de aplicaciones que va a administrar compartan un firmante común, y de que dicho firmante común se encuentre en el conjunto de claves del ID de usuario del administrador que se utiliza para invocar registerNode.sh o deregisterNode.sh.
Nota: El conjunto de claves utilizado durante el registro o la anulación del registro es el que se encuentra asociado al agente administrativo.

Icon that indicates the type of topic Reference topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rsec_7register_admin_agent
File name: rsec_7register_admin_agent.html