Consideraciones de seguridad al añadir un nodo de servidor de aplicaciones base a WebSphere Application Server Network Deployment

Puede decidir centralizar la configuración de los servidores de aplicaciones base autónomos añadiéndolos a una célula de WebSphere® Application Server Network Deployment . Si el servidor de aplicaciones base está configurado actualmente con la seguridad, hay algunos puntos que deben tenerse en cuenta. La cuestión más importante al añadir un nodo a la célula es si los registros de usuarios entre el servidor de aplicaciones base y el gestor de despliegue son iguales.

[AIX Solaris HP-UX Linux Windows] [IBM i] Al añadir un nodo a la célula, hereda automáticamente el registro de usuarios y el mecanismo de autenticación de la célula.

[z/OS] Al añadir un nodo a una celda, el nuevo nodo federado hereda automáticamente el registro de usuarios (sistema operativo local, LDAP o personalizado), el mecanismo de autenticación (LTPA) y la configuración de autorización (enlaces WebSphere o perfiles EJBROLE de System Authorization Facility (SAF)) de la celda WebSphere Application Server Network Deployment existente.

Para la seguridad distribuida, todos los servidores de la célula deben utilizar el mismo registro de usuarios y mecanismo de autenticación. Para recuperarse de un cambio de registro de usuarios, debe modificar las aplicaciones para que las correlaciones de usuario y grupo a rol sean correctas para el nuevo registro de usuarios. Consulte el tema sobre asignación de usuarios y grupos a roles.

Otra cuestión importante a tener en cuenta es la infraestructura de claves públicas SSL (Secure Sockets Layer). Antes de ejecutar el mandato addNode con el gestor de despliegue, verifique que el mandato addNode puede comunicarse como un cliente SSL con el gestor de despliegue. Esta comunicación requiere que el almacén de confianza de addNode configurado en el archivo sas.client.props contenga el certificado de firmante del certificado personal del gestor de despliegue que se encuentra en el almacén de claves y se especifica en la consola administrativa.

A continuación se indican otras cuestiones que deben tenerse en cuenta al ejecutar el mandato addNode con la seguridad:

Al intentar ejecutar mandatos de gestión de sistema como el mandato addNode, es necesario especificar de forma explícita las credenciales administrativas para llevar a cabo la operación. El mandato addNode 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 addNode:
addNode CELL_HOST 8879 -includeapps -username user -password pass.

El parámetro -includeapps es opcional, pero esta opción intenta incluir las aplicaciones de servidor en el gestor de despliegue. El mandato addNode puede fallar si los registros de usuarios utilizados por WebSphere Application Server y el gestor de despliegue no son iguales. Para corregir este problemas, haga que coincidan los registros de usuarios o desactive la seguridad. Si modifica los registros de usuario, recuerde verificar que las correlaciones de usuarios a roles y grupos a roles son correctas. Consulte MandatoaddNode para obtener más información sobre la sintaxis de addNode .
Nota: También puede ejecutar el mandato addNode utilizando la herramienta de gestión de perfiles WebSphere z/OS® o el mandato zpmt . Si emite el mandato addNode con la seguridad habilitada utilizando la herramienta de gestión de perfiles WebSphere z/OS o el mandato zpmt , debe utilizar un ID de usuario con autorización y especificar las opciones -user y -password .
La adición de un nodo remoto seguro utilizando la consola administrativa no está soportada. Puede inhabilitar la seguridad en el nodo remoto antes de realizar la operación o realizar la operación desde la línea de mandatos con el script addNode.
Antes de ejecutar el mandato addNode , debe verificar que los archivos de almacén de confianza de los nodos pueden comunicarse con los archivos de almacén de claves del gestor de despliegue y viceversa. Al utilizar el valor predeterminado DummyServerKeyFile y DummyServerTrustFile, no debería toparse con este problema porque ya se han podido comunicar. Sin embargo, no utilice nunca estos archivos ficticios en un entorno de producción.
Antes de ejecutar el mandato addNode , debe verificar que los archivos de almacén de confianza en los nodos se comunican con los archivos de almacén de claves y el conjunto de claves SAF (System Authorization Facility) que es propiedad del gestor de despliegue y viceversa. Si genera los certificados para el gestor de despliegue utilizando la misma autoridad certificadora que la utilizada para el proceso agente de nodo, esto resultará satisfactorio. Las configuraciones SSL siguientes deben contener almacenes de claves y almacenes de confianza que puedan interoperar:
- Repertorio SSL del sistema que se especifica en la consola administrativa mediante Administración del sistema > Administrador de implementaciones > Transportes HTTP > sslportno > SSL.
- SSL Repertorio para el conector JMX adecuado si se especifica SOAP. Administración del sistema > dmgr > Servicios de administración > Conectores JMX > SOAPConnector > Propiedades personalizadas > sslConfig.
- SSL repertorio especificado en NodeAgent Administrador del sistema > Agentes de nodo > Servidor NodeAgent > Servicios de administración > Conectores JMX > SOAPConnector > Propiedades personalizadas > sslConfig.
Nota: WebSphere Application Server for z/OS define dominios de seguridad utilizando prefijos de perfil SAF (anteriormente denominados dominios de seguridad z/OS ) en la herramienta de gestión de perfiles WebSphere z/OS o el mandato zpmt . Preste atención cuando añada un nodo a la configuración de Deployment Manager que define un dominio de seguridad diferente.
Cuando un cliente de una versión anterior intenta utilizar el mandato addNode para federarse a un gestor de despliegue de la versión 7.0, en primer lugar el cliente debe obtener los firmantes para que el reconocimiento sea satisfactorio. Para obtener más información, consulte sobre la obtención de firmantes para clientes y servidores de un release anterior en el artículo sobre la instalación segura para la recuperación de firmantes para clientes en SSL.
Después de ejecutar el mandato addNode, el servidor de aplicaciones está en un nuevo dominio SSL. Es posible que contenga configuraciones SSL que señalen los archivos de almacén de claves y los archivos de almacén de confianza que no están preparados para interoperar con otros servidores que están en el mismo dominio. Tenga en cuenta cuáles son los servidores que se comunican entre sí y asegúrese de que se confía en dichos servidores en los archivos de almacén de confianza.

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. Es necesario hacer un examen exhaustivo de la seguridad durante la planificación de la infraestructura. Este documento le ayudará a recortar la cantidad de problemas que pueden producirse debido a las interacciones de seguridad sistemáticas.

Cuando tenga problemas de seguridad relacionados con el entorno de WebSphere Application Server Network Deployment , consulte Resolución de problemas de configuraciones de seguridad para encontrar información adicional sobre el problema. Cuando es necesario efectuar un rastreo para resolver un problema porque los servidores están distribuidos, a menudo es necesario recopilar simultáneamente el rastreo de todos los servidores mientras se vuelve a crear el problema. Este rastreo se puede habilitar de forma dinámica o estática, según el tipo de problema que ocurra.