Consideraciones de seguridad al añadir un nodo de servidor de aplicaciones base en WebSphere Application Server, Network Deployment
Es posible que decida centralizar la configuración de los servidores de aplicaciones base autónomos añadiéndolos a la 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.
Al añadir un nodo a la célula, se puede heredar automáticamente tanto el registro de usuario como el mecanismo de autenticación de la célula.
Cuando se añade un nodo a una célula, el nodo recién federado hereda de forma automática el registro de
usuario (sistema operativo local, LDAP o Personalizado), el mecanismo de autenticación (LTPA y el valor de
autorización (enlaces de
WebSphere o perfiles
EJBROLE de SAF (System Authorization Facility) de la célula existente
deWebSphere Application Server, Network Deployment.
En el caso de 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 apartado 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.
- 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 usuario -password contraseña.
El parámetro -includeapps es opcional, pero esta opción intenta incluir las aplicaciones de servidor en el gestor de despliegue. Es posible que el mandato addNode falle si los registros de usuario utilizados por WebSphere Application Server y el gestor de despliegue no son los mismos. 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 el apartado addNode (mandato) 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 de WebSphere z/OS o el mandato zpmt. Si emite el mandato addNode con la seguridad habilitada utilizando la Herramienta de gestión de perfiles de 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 se pueden comunicar 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 de los nodos se comunican con los archivos de almacén de claves y el conjunto de claves SAF (System Authorization Facility) 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 de confianza que puedan operar conjuntamente:
- El repertorio SSL del sistema especificado en la consola administrativa con .
- El repertorio SSL del conector JMX adecuado, si se especifica SOAP .
- Repertorio SSL especificado en .
Nota: WebSphere Application Server para z/OS define dominios de seguridad utilizando prefijos de perfiles SAF (anteriormente denominados dominios de seguridad de z/OS) en la herramienta de gestión de perfiles de 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.
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 ver si puede obtener más información 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.