Consideraciones acerca de la seguridad en un entorno de WebSphere Application Server WebSphere Application Server, Network Deployment de varios nodos

WebSphere Application Server, Network Deployment da soporte a una gestión centralizada de nodos distribuidos y servidores de aplicaciones. Este soporte esencialmente implica complejidad, en especial cuando se incluye la seguridad. Puesto que todo se distribuye, la seguridad representa un rol todavía más importante al garantizar que las comunicaciones se protegen adecuadamente entre los servidores de aplicaciones y los agentes de nodos, y entre los agentes de nodos (un gestor de configuración específico de nodos) y el gestor de despliegue (el gestor de configuración centralizado de todo el dominio).

Antes de empezar

[AIX Solaris HP-UX Linux Windows][IBM i]Dado que los procesos son distribuidos, debe utilizarse el mecanismo de autenticación LTPA (Lightweight Third Party Authentication). Los señales LTPA se cifran, firman y se pueden remitir a procesos remotos. No obstante las señales caducan. El conector SOAP, que es el conector por omisión, se utiliza para la seguridad administrativa y no tiene lógica de reintentos para las señales caducadas. No obstante, el protocolo no tiene estado, por lo que se crea una nueva señal para cada solicitud si no hay suficiente tiempo para ejecutar la solicitud en el período de tiempo que queda en la señal. Un conector alternativo es el conector RMI con estado y que tiene alguna lógica de reintentos para corregir señales caducadas volviendo a someter las señales después de detectar el error. Asimismo, dado que las señales tienen un período de caducidad específico, la sincronización de los relojes del sistema es muy importante para el funcionamiento correcto de la validación basada en señales. Si los relojes no están sincronizados (una diferencia entre sí de 10 a 15 minutos), puede encontrar anomalías en la validación que no puedan recuperarse y que podrían haberse evitado si hubieran estado sincronizados. Verifique que la hora, la fecha y los husos horarios son los mismos para todos los sistemas. Se acepta que los nodos estén en husos horarios distintos siempre y cuando las horas sean las correctas entre los husos horarios (por ejemplo, 5 PM CST = 6 PM EST, etc).

[z/OS]Dado que se distribuyen los procesos, debe seleccionarse un mecanismo de autenticación que admita una señal de autenticación como LTPA (Lightweight Third-Party Authentication). Las señales se cifran, firman y se pueden remitir a procesos remotos. No obstante, los símbolos tienen fechas de caducidad que se establecen en la consola administrativa de WebSphere Application Server. El conector SOAP, que es el conector por omisión, se utiliza para la seguridad administrativa y no tiene lógica de reintentos para las señales caducadas. No obstante, el protocolo no tiene estado, por lo que se crea una nueva señal para cada solicitud si no hay suficiente tiempo para ejecutar la solicitud en el período de tiempo que queda en la señal. Un conector alternativo es el conector RMI (Remote Method Invocation) que tiene estado y una lógica de reintentos para corregir señales caducadas mediante la cual vuelve a someter las solicitudes una vez detectado el error. Asimismo, dado que las señales tienen un período de caducidad específico, la sincronización de los relojes del sistema es muy importante para el funcionamiento correcto de la validación basada en señales. Si los relojes no están sincronizados (una diferencia entre sí de 10 a 15 minutos), puede encontrar anomalías en la validación que no puedan recuperarse y que podrían haberse evitado si hubieran estado sincronizados. Verifique que la hora, la fecha y los husos horarios son los mismos para todos los sistemas. Se acepta que los nodos estén en husos horarios distintos siempre y cuando las horas sean las correctas entre los husos horarios (por ejemplo, 5 PM CST = 6 PM EST, etc).

[z/OS]Existen consideraciones adicionales con SSL (Secure Sockets Layer). WebSphere Application Server para z/OS puede utilizar conjuntos de claves RACF (Resource Access Control Facility) para almacenar las claves y los almacenes de confianza que se utilizan para SSL, pero internamente se utilizan protocolos SSL diferentes. Debe asegurarse de configurar los dos:
  • Un repertorio SSL del sistema para uso del contenedor web
  • Un repertorio SSL de JSSE (Java™ Secure Sockets Extension) para que lo utilice el conector HTTP de SOAP si el conector SOAP se utiliza para solicitudes administrativas.
Compruebe que los almacenes y los almacenes de confianza que configure se establezcan de modo que sólo confíen en los servidores con los que se comunican. Asegúrese de que incluyan los certificados de firmante necesarios de dichos servidores en los archivos de confianza de todos los servidores del dominio. Al utilizar una CA (autoridad certificadora) para crear certificados personales, es más fácil garantizar que todos los servidores confíen entre sí si se tiene el certificado raíz de CA en todos los firmantes.

[z/OS]La Herramienta de gestión de perfiles de WebSphere z/OS o el mandato zpmt utiliza la misma entidad emisora de certificados para generar certificados para todos los servidores de una célula dada, incluidos los de los agentes del nodo y los del gestor de despliegue.

Acerca de esta tarea

Considere los siguientes aspectos cuando utilice o planifique un entorno WebSphere Application Server, Network Deployment.

Procedimiento

Resultados

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. Para que la seguridad funcione correctamente, es necesario hacer un examen exhaustivo durante la planificación de la infraestructura.

Qué hacer a continuación

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.

Icon that indicates the type of topic Task topic



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