Visión general de la planificación de seguridad
Cuando accede a información en Internet, se conecta a través de servidores web y servidores del producto a los datos de la empresa mediante el programa de fondo. En este apartado se examinan varias prácticas de seguridad habituales y configuraciones típicas.
En esta sección también se examinan la protección de seguridad que proporciona cada capa de seguridad y la práctica de seguridad habitual para obtener una alta calidad de protección en la seguridad de extremo a extremo. En la siguiente figura se muestran los módulos que forman el entorno operativo de la seguridad de WebSphere Application Server:
- Seguridad de WebSphere Application Server
- Seguridad de WebSphere
- La seguridad de WebSphere Application Server pone en marcha servicios y políticas de seguridad de forma unificada para acceder a los recursos Web, enterprise beans y recursos de administración JMX. Consta de las tecnologías de seguridad de WebSphere Application Server y de las características para dar soporte las exigencias de un entorno de empresa seguro.
- Seguridad de Java
- API (interfaz de programas de aplicación) de seguridad Java Platform, Enterprise Edition (Java EE)
- El colaborador de seguridad implementa las políticas de seguridad basadas en Java Platform, Enterprise Edition (Java EE) y da soporte a las API de seguridad Java.
- Seguridad de EJB utilizando Common Secure Interoperability Protocol Version 2 (CSIv2)
- CSIv2 (Common Secure Interoperability Version 2) es un protocolo de seguridad de tres niveles basado en IIOP desarrollado por OMG (Object Management Group). Este protocolo proporciona protección de mensajes, autenticación interoperativa y delegación. Los tres niveles constan de un nivel de seguridad de transporte, un nivel de autenticación de cliente suplementario y un nivel de atributo de seguridad. WebSphere Application Server para z/OS da soporte a CSIv2, con el nivel de conformidad 0.
- Seguridad de Java 2
- El modelo de seguridad de Java 2 proporciona un control de acceso exhaustivo a los recursos del sistema incluidos el sistema de archivos, la propiedad del sistema, la conexión de sockets, la ejecución de hebras, la carga de clases, etc. Para poder acceder a un recurso protegido, debe otorgarse de forma explícita el permiso necesario al código de la aplicación.
- Máquina virtual Java (JVM) 5.0
- El modelo de seguridad JVM proporciona una capa de seguridad por encima de la capa del sistema operativo. Por ejemplo, la seguridad JVM protege la memoria del acceso sin restricciones, genera excepciones cuando se producen errores en una hebra y define los tipos de matrices.
- Seguridad de la plataforma
Seguridad del sistema operativo
La infraestructura de seguridad del sistema operativo subyacente proporciona determinados servicios de seguridad para WebSphere Application Server. Estos servicios incluyen el soporte de seguridad del sistema de archivos que protege los archivos sensibles de la instalación del producto para WebSphere Application Server. El administrador del sistema puede configurar el producto para obtener información de autenticación directamente del registro de usuario del sistema operativo.
Seguridad del sistema operativo
La infraestructura de seguridad del sistema operativo subyacente proporciona determinados servicios de seguridad para WebSphere Application Server. La identidad del sistema operativo del sirviente, controlador y daemon Tarea iniciada, como se establece en el perfil STARTED (Iniciado), es la identidad que se utiliza para controlar el acceso a recursos del sistema, como por ejemplo archivos o sockets. Opcionalmente, la seguridad del sistema operativo puede proporcionar los servicios de autenticación mediante el registro de usuarios del sistema operativo local y/o los servicios de autorización mediante la autorización SAF para la consola administrativa de WebSphere y las aplicaciones que se ejecuten en el servidor de aplicaciones.
Además de conocer SSL (Secure Sockets Layer) y TLS (Transport Layer Security), el administrador debe familiarizarse con SAF (System Authorization Facility) y RACF (Resource Access Control Facility).
La identidad y verificación de usuarios puede gestionarse utilizando un sistema operativo local como registro de usuario, RACF o un producto equivalente basado en SAF. Alternativamente, se puede utilizar un registro LDAP, personalizado o de usuarios federado.
WebSphere puede configurarse para utilizar la autorización SAF, que hará uso de RACF o un producto equivalente basado en SAF para gestionar y proteger los recursos de usuarios y grupos. Alternativamente, WebSphere puede configurarse para utilizar la autorización de WebSphere o un proveedor de autorización externo de JACC.
Al utilizar el sistema operativo local como registro de usuarios o utilizar la autorización SAF, la auditoría de seguridad es una característica heredada de RACF o los productos equivalentes basados en SAF.
- Seguridad de la red
- Las capas de seguridad de la red proporcionan autenticación a nivel de transporte, además de integridad de mensajes y confidencialidad. Puede configurar la comunicación entre servidores de aplicaciones independientes para utilizar SSL (Secure Sockets Layer). También puede utilizarse la seguridad IP y la red privada virtual (VPN) para añadir más protección a los mensajes.
Cada servidor de aplicaciones del producto consta de un contenedor web, un contenedor de EJB (Enterprise Java Beans) y una subsistema administrativo.
El gestor de despliegue de WebSphere Application Server sólo contiene el código administrativo de WebSphere Application Server y la consola administrativa.
La consola administrativa es una aplicación web Java EE que proporciona la interfaz para realizar funciones administrativas. Los datos de configuración de WebSphere Application Server se almacenan en archivos descriptores XML, que la seguridad del sistema operativo debe proteger. Las contraseñas y otros datos de configuración importantes pueden modificarse a través de la consola administrativa. No obstante, debe proteger estas contraseñas y datos sensibles. Para obtener más información, consulte Cifrado de contraseñas en archivos.
La aplicación web de la consola administrativa tiene una limitación de datos de configuración que requiere que sólo se pueda acceder a los servlets de la consola administrativa y a los archivos JSP (JavaServer Pages) a través de una conexión SSL, cuando la seguridad administrativa está habilitada.
En
WebSphere Application Server Versión 6.0.x y
anteriores, el puerto HTTPS de la consola administrativa estaba configurado para utilizar
DummyServerKeyFile.jks y DummyServerTrustFile.jks con el certificado autofirmado por
omisión. Las claves y certificados ficticios debe sustituirse inmediatamente después de la instalación de
WebSphere Application Server. Las claves son comunes en toda la instalación y, por lo tanto, no son seguras. WebSphere Application Server Versión 6.1 proporciona
la gestión integrada de claves y certificados, que
genera claves privadas diferenciadas y certificados autofirmados con el nombre de host de servidor
incorporado para habilitar la verificación de nombres de host. WebSphere Application Server
Versión 6.1
también permite la integración con una autoridad de certificación (CA) externa para utilizar certificados
emitidos por una CA. El proceso de instalación de WebSphere Application Server Versión 6.1 proporciona una
opción para habilitar la seguridad administrativa durante la instalación. Como resultado, un proceso de
WebSphere Application Server queda protegido
inmediatamente después de la instalación. WebSphere Application Server Versión 7.0 amplía las funciones de
gestión de certificados incorporadas mediante la creación de un certificado encadenado (certificado personal
firmado por un certificado raíz) para poder renovar el certificado personal sin que ello afecte a la
confianza establecida. También permite la adaptación del certificado durante la creación de perfiles (puede importar el nombre distinguido (DN) propio o cambiar el existente que se ha creado de manera predeterminada). Asimismo, permite cambiar la contraseña predeterminada del almacén de claves.
La figura siguiente muestra un típico entorno de cálculo
empresarial de varios niveles.
La figura siguiente muestra un típico entorno de cálculo
empresarial de varios niveles.
Seguridad administrativa
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
![[z/OS]](../images/ngzos.gif)
Puede configurar estos protocolos para utilizar Secure Sockets Layer (SSL) cuando habilite WebSphere Application Server seguridad administrativa. El subsistema administrativo de WebSphere Application Server de cada usuario utiliza los conectores de JMX (Java Management Extensions), SOAP y RMI/IIOP (Remote Method Invocation over the Internet Inter-ORB Protocol) para pasar mandatos administrativos y datos de configuración. Cuando la seguridad administrativa está inhabilitada, el conector de JMX SOAP utiliza el protocolo HTTP y el conector RMI/IIOP utiliza el protocolo TCP/IP. Cuando la seguridad administrativa está habilitada, el conector SOAP JMX siempre utiliza el protocolo HTTPS. Cuando la seguridad administrativa está habilitada, puede configurar el conector de JMX RMI/IIOP para que utilice SSL o TCP/IP. Se recomienda habilitar la seguridad administrativa y habilitar SSL para proteger los datos de configuración sensibles.
Puede habilitar HTTPS para las aplicaciones aunque la
seguridad administrativa esté
inhabilitada. Puede configurar el puerto de SSL para un servidor concreto añadiendo el puerto SSL a la lista
de puertos HTTP del contenedor web además de a la ubicación en la que se añade de los hosts virtuales de la
configuración de entorno.
Puede conectar con la aplicación web mediante HTTPS y el puerto correcto. La comunicación interna de
WebSphere Application Server para z/OS no utiliza SSL a menos
que habilite la seguridad administrativa.
Cuando inhabilite la seguridad administrativa, puede inhabilitar la seguridad de aplicaciones en cada servidor de aplicaciones individual deseleccionando la opción Habilitar seguridad administrativa en el nivel de servidor. Para obtener más información, consulte Protección de servidores de aplicaciones específicos. La inhabilitación de la seguridad del servidor de aplicaciones no afecta al subsistema administrativo de ese servidor de aplicaciones, que sólo se controla mediante la configuración de seguridad. El código de aplicación y el subsistema de administración de un servidor de aplicaciones comparten la configuración opcional de protocolo de seguridad por servidor.
Seguridad para recursos Java EE
El contenedor Web y el contenedor EJB proporcionan la seguridad para recursos Java EE. Cada contenedor ofrece dos tipos de seguridad: la seguridad declarativa y la seguridad mediante programa.
En la seguridad declarativa, la estructura de seguridad de la aplicación incluye la integridad y la confidencialidad de los mensajes de red, los requisitos de autenticación, los roles de seguridad y el control de acceso. El control de acceso se expresa en un formato externo a la aplicación. En concreto, el descriptor de despliegue es el principal vehículo de la seguridad declarativa en la plataforma Java EE. WebSphere Application Server mantiene la política de seguridad Java EE, incluida la información derivada del descriptor de despliegue y la especificada por los desplegadores y administradores en un conjunto de archivos descriptores XML. Durante el tiempo de ejecución, el contenedor utiliza la política de seguridad definida en los archivos del descriptor XML para forzar las restricciones de datos y el control de acceso.
Cuando la seguridad declarativa no es suficiente para expresar el modelo de seguridad de la aplicación, puede utilizar la seguridad programada para tomar decisiones de acceso. Cuando la seguridad administrativa está habilitada y la seguridad del servidor de aplicaciones no se ha inhabilitado a nivel de servidor, se aplica la seguridad de aplicaciones Java EE. Cuando se especifica la política de seguridad de un recurso web, el contenedor web realiza el control de acceso cuando un cliente web solicita el recurso. El contenedor web solicita los datos de autenticación al cliente web si no existe ninguno según el método de autenticación especificado, garantiza que se cumplan las restricciones de datos y determina si el usuario autenticado tiene el rol de seguridad necesario. El colaborador de seguridad web utiliza una implementación del gestor de acceso para aplicar el control de acceso basado en roles. El gestor de acceso toma las decisiones de autorización basándose en la política de seguridad derivada del descriptor de despliegue. El principal del usuario autenticado puede acceder al archivo JSP o al servlet solicitado si el principal de usuario tiene uno de los roles de seguridad necesarios. Los servlets y las páginas JSP pueden utilizar los métodos HttpServletRequest, isUserInRole y getUserPrincipal.
Cuando la seguridad administrativa y la seguridad de aplicaciones están
habilitadas y la seguridad de aplicaciones de nivel de servidor de
aplicaciones no está inhabilitada, el contenedor EJB aplica el control de
acceso al invocar el método EJB.
Cuando se habilita la seguridad a nivel de
célula, a menos que se inhabilite la seguridad del servidor, el contenedor
EJB aplica el control de acceso al invocar el método EJB.
La autenticación se realiza independientemente de qué se haya definido un permiso de método para el método EJB específico. El colaborador de seguridad de EJB utiliza una implementación del gestor de acceso para aplicar el control de acceso basado en roles. El gestor de acceso toma las decisiones de autorización basándose en la política de seguridad derivada del descriptor de despliegue. El principal del usuario autenticado puede acceder al método EJB solicitado si tiene uno de los roles de seguridad necesarios. El código EJB puede utilizar los métodos EJBContext: isCallerInRole y getCallerPrincipal. Utilice el control de acceso basado en roles de Java EE para proteger los datos de empresa valiosos contra el acceso por parte de usuarios no autorizados a través de Internet y de la intranet. Consulte Protección de aplicaciones web con una herramienta de ensamblaje y Protección de aplicaciones de enterprise bean.
Seguridad basada en roles
- Rol de supervisor
- Un supervisor puede ver la información de configuración y el estado pero no puede realizar cambios.
- Rol de operador
- Un operador puede activar los cambios de estado del módulo ejecutable, como iniciar un servidor de aplicaciones o detener una aplicación pero no puede realizar cambios de configuración.
- Rol de configurador
- Un configurador puede modificar la información de configuración pero no puede cambiar el estado del tiempo de ejecución.
- Rol de administrador
- Operador que, al igual que un configurador, puede modificar además la configuración de seguridad sensible y la política de seguridad, por ejemplo configurando los ID y las contraseñas del servidor, habilitando o inhabilitando la seguridad seguridad administrativa y Java y correlacionando usuarios y grupos con el rol de administrador.
- iscadmins
- El rol iscadmins tiene privilegios de administrador para gestionar usuarios y grupos en los repositorios federados únicamente desde la consola administrativa.
- Desplegador
- Un desplegador puede ejecutar acciones de configuración y operaciones de tiempo de ejecución en las aplicaciones.
- Adminsecuritymanager
- Un gestor de seguridad administrativa puede correlacionar usuarios con roles administrativos. Asimismo, cuando se utiliza una seguridad de administración precisa, los usuarios a los que se otorga este rol pueden gestionar grupos de autorización.
- Auditor
- Un auditor puede ver y modificar los valores de configuración del subsistema de auditoría de seguridad.
Un usuario con el rol de configurador puede realizar la mayoría de tareas de administración, entre las que se incluyen la instalación de nuevas aplicaciones y nuevos servidores de aplicaciones. Existen determinadas tareas de configuración para las que un configurador no tiene autorización suficiente cuando la seguridad administrativa está habilitada, incluida la modificación de la identidad y la contraseña de WebSphere Application Server, la modificación de contraseñas y claves LTPA (Lightweight Third-Party Authentication) y la asignación de usuarios a roles de seguridad administrativos. Estas tareas de configuración críticas requieren el rol administrativo porque el ID de servidor está correlacionado al rol administrativo.
Habilite la seguridad administrativa de WebSphere Application Server para proteger la integridad del subsistema de administración. La seguridad del servidor de aplicaciones puede inhabilitarse de manera selectiva si no hay información confidencial que proteger. Para proteger la seguridad administrativa, consulte Autorización del acceso a roles administrativos y Asignación de usuarios y grupos a roles.
Permisos de seguridad de Java 2
WebSphere Application Server utiliza el modelo de seguridad Java 2 para crear un entorno seguro a fin de ejecutar el código de la aplicación. La seguridad de Java 2 proporciona un control de acceso basado en políticas preciso para proteger los recursos del sistema como, por ejemplo, archivos, propiedades del sistema, la apertura de conexiones de sockets, la carga de bibliotecas, etc. La especificación Java EE Versión 1.4 define un conjunto habitual de permisos de seguridad Java 2 que los componentes web y EJB esperan tener.
Permiso de seguridad | Destino | Action |
---|---|---|
java.lang.RuntimePermission | loadLibrary | |
java.lang.RuntimePermission | queuePrintJob | |
java.net.SocketPermission | * | connect |
java.io.FilePermission | * | lectura, escritura |
java.util.PropertyPermission | * | lectura |
Permiso de seguridad | Destino | Action |
---|---|---|
java.lang.RuntimePermission | queuePrintJob | |
java.net.SocketPermission | * | connect |
java.util.PropertyPermission | * | lectura |
/QIBM/ProdData/Java400/jdk15/lib/security/java.policy
Se utiliza como política por omisión para JVM (máquina virtual Java).
${java.home}/jre/lib/security/java.policy
Este archivo se utiliza como política por omisión para JVM (máquina virtual Java).
${USER_INSTALL_ROOT}/properties/server.policy
Este archivo se utiliza como política por omisión para todos los procesos de servidor del producto.
$WAS_HOME/properties/server.policy
Este archivo se utiliza como política por omisión para todos los procesos de servidor del producto.
Para simplificar la gestión de política, la política de WebSphere Application Server se basa en un tipo de recurso en lugar de la base de código (ubicación). Los archivos siguientes son los archivos de políticas por omisión de un subsistema WebSphere Application Server. Estos archivos de política, que son una extensión del módulo ejecutable de WebSphere Application Server, se denominan interfaces de programación de proveedores de servicios (SPI - Service Provider Programming Interfaces) y se comparten entre diversas aplicaciones Java EE:
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
- raíz_perfil/config/cells/nombre_célula/nodes/nombre_nodo/spi.policy
Este archivo se utiliza para recursos incorporados definidos en el archivo resources.xml, como los controladores JMS (Java Message Service), JavaMail y JDBC.
- raíz_perfil/config/cells/nombre_célula/nodes/nombre_nodo/library.policy
Este archivo se utiliza para la biblioteca compartida definida por la consola administrativa de WebSphere Application Server.
- raíz_perfil/config/cells/nombre_célula/nodes/nombre_nodo/app.policy
Este archivo se utiliza como política por omisión para las aplicaciones Java EE.
![[z/OS]](../images/ngzos.gif)
- $WAS_HOME/config/cells/nombre_célula/nodes/nombre_nodo/spi.policy
Este archivo se utiliza para recursos incorporados definidos en el archivo resources.xml, como los controladores JMS (Java Message Service), API JavaMail y JDBC.
- $WAS_HOME/config/cells/nombre_célula/nodes/nombre_nodo/library.policy
Este archivo se utiliza para la biblioteca compartida definida por la consola administrativa de WebSphere Application Server.
- $WAS_HOME/config/cells/nombre_célula/nodes/nombre_nodo/app.policy
Este archivo se utiliza como política por omisión para las aplicaciones Java EE.
![[IBM i]](../images/iseries.gif)
- raíz_perfil/config/cells/nombre_célula/nodes/nombre_nodo/spi.policy
Se utiliza para recursos incorporados definidos en el archivo resources.xml, como los controladores JMS (Java Message Service), JavaMail y JDBC.
- raíz_perfil/config/cells/nombre_célula/nodes/nombre_nodo/library.policy
Se utiliza para la biblioteca compartida definida por la consola administrativa de WebSphere Application Server.
- raíz_perfil/config/cells/nombre_célula/nodes/nombre_nodo/app.policy
Se utiliza como política de omisión para las aplicaciones Java EE.
Al cargar las bibliotecas en WebSphere Application Server no permite que las aplicaciones dejen el área de depuración de Java. WebSphere Application Server utiliza un archivo de políticas de filtro de permisos que le alerta cuando se produce un error en la instalación de una aplicación debido a requisitos adicionales de los permisos. Por ejemplo, se recomienda que no otorgue permiso java.lang.RuntimePermission exitVM a una aplicación para que el código de aplicación no puede interrumpir WebSphere Application Server.
La política de filtrado se define mediante la máscara de filtro del archivo raíz_perfil/config/cells/nombre_célula/filter.policy. Por otra parte, WebSphere Application Server también realiza el filtrado de permisos de módulo ejecutable en base a la política de filtrado de módulo ejecutable para garantizar que a ningún código de aplicación se le otorgue un permiso que se considere perjudicial para la integridad del sistema.
Por lo tanto, es posible que muchas de las aplicaciones desarrolladas para los releases anteriores de WebSphere Application Server no tengan habilitada la seguridad de Java 2. Para migrar estas aplicaciones a la última versión de WebSphere Application Server, puede otorgar temporalmente a estas aplicaciones el permiso java.security.AllPermission del archivo was.policy. Compruebe estas aplicaciones para asegurarse de que se ejecutan en un entorno en el que está activa la seguridad de Java 2. Por ejemplo, identifique qué permisos adicionales, si hay alguno, son necesarios y otorgue éstos a una aplicación concreta únicamente. Si no se otorga el permiso AllPermission. a las aplicaciones se reduce el riesgo de comprometer la integridad del sistema. Para obtener más información sobre cómo migrar aplicaciones, consulte Migración de la política de seguridad de Java 2.
El módulo ejecutable de WebSphere Application Server utiliza la seguridad de Java 2 para proteger las funciones de módulo ejecutable sensibles. Las aplicaciones a las que se otorgan el permiso AllPermission, no sólo pueden acceder a recursos del sistema críticos, sino también a recursos de tiempo de ejecución de WebSphere Application Server y pueden provocar daños a los dos. En los casos en los que una aplicación pueda considerarse libre de riesgos, WebSphere Application Server permite inhabilitar la seguridad de Java 2 de forma individual en cada servidor de aplicaciones. Puede aplicar la seguridad de Java 2 por omisión en la consola administrativa y borrar el distintivo de seguridad de Java 2 para inhabilitarla en un servidor de aplicaciones concreto.
- Cuando se aplica la seguridad de Java 2, el código de aplicación no puede acceder a las clases de módulo ejecutable de WebSphere Application Server que gestionan los datos de configuración a menos que al código se le hayan concedido los permisos necesarios de ejecución de WebSphere Application Server.
- Cuando se aplica la seguridad de Java 2, el código de aplicación no puede acceder a los archivos XML de configuración de WebSphere Application Server a menos que al código se le hayan concedido los permisos necesarios de lectura y escritura de archivos.
- El subsistema administrativo de JMX proporciona SOAP a través de la interfaz remota de HTTP o HTTPS y RMI/IIOP para permitir a los programas de aplicación extraer y modificar datos y archivos de configuración. Cuando se habilita la seguridad administrativa, un programa de aplicación puede modificar la configuración de WebSphere Application Server siempre y cuando el programa de aplicación haya presentado datos de autenticación válidos y que la identidad de seguridad tenga los roles de seguridad necesarios.
- Si un usuario puede inhabilitar la seguridad de Java 2, este usuario también puede modificar la configuración de WebSphere Application Server, incluidos los datos de autenticación e identificación de seguridad de WebSphere Application Server con otros datos críticos. Sólo los usuarios con el rol de seguridad administrador pueden inhabilitar la seguridad de Java 2.
- Puesto que a la identidad de seguridad de WebSphere Application Server se le ha otorgado el rol de administrador, sólo los usuarios con el rol de administrador pueden inhabilitar la seguridad administrativa, cambiar los ID de servidor y las contraseñas, y correlacionar usuarios y grupos con roles administrativos, etc.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
Otros recursos de tiempo de ejecución
Otros recursos de tiempo de ejecución de WebSphere Application Server están protegidos por un mecanismo parecido al que se describe previamente. Es muy importante habilitar la seguridad administrativa de WebSphere Application Server y utilizar la seguridad de Java 2 para restringir el acceso a los recursos locales. La especificación Java EE define varios métodos de autenticación para componentes web: autenticación básica HTTP, autenticación basada en formulario y autenticación de certificado de cliente HTTPS. Al utilizar el inicio de sesión de certificado de cliente, es más conveniente para el cliente del navegador si los recursos web tienen restricciones de datos confidenciales o integrales. Si un navegador utiliza HTTP para acceder a los recursos web, el contenedor web redireccionará el navegador automáticamente al puerto HTTPS. El protocolo de seguridad CSIv2 también da soporte a la autenticación de certificados de cliente. También puede utilizar la autenticación de cliente SSL para configurar una comunicación segura entre un conjunto seleccionado de servidores basándose en una relación de confianza.
El protocolo de seguridad CSIv2 también da soporte a la autenticación de certificados de cliente. La autenticación de cliente SSL también puede utilizarse para configurar
comunicaciones seguras entre un grupo de servidores seleccionado basándose
en una relación de confianza.

Para realizar esta tarea, puede generar tres certificados utilizando IKEYMAN y los programas de utilidad de gestión de certificados. Asimismo, puede utilizar el certificado W y los certificados de confianza A y B. Configure el servidor HTTPS de WebSphere Application Server A para que utilice el certificado A y confíe en el certificado W.
Para realizar esta tarea, puede generar tres certificados utilizando RACF (Resource Access Control Facility), denominados certificados W, A y B. Configure el plug-in de WebSphere Application Server para que utilice el certificado W y confíe en los certificados A y B. Configure el servidor HTTPS de WebSphere Application Server A para que utilice el certificado A y confíe en el certificado W.
Servidor | Clave | Confianza |
---|---|---|
Plug-in de WebSphere Application Server | W | A, B |
WebSphere Application Server A | Una célula de | W |
WebSphere Application Server B | B | W |
El gestor de despliegue de WebSphere Application Server es un punto central en la administración. Los mandatos de gestión del sistema se envían desde el gestor de despliegue a cada servidor de aplicaciones individual. Cuando la seguridad administrativa está habilitada, puede configurar los servidores WebSphere Application Server para que exijan SSL y la autenticación mutua.
Server | Clave | Confianza |
---|---|---|
WebSphere Application Server A | Una célula de | C, E |
WebSphere Application Server B | B | D, E |
WebSphere Application Server C | C | A, E |
WebSphere Application Server D | D | B, E |
Gestor de despliegue E de WebSphere Application Server | E | A, B, C, D |
Cuando WebSphere Application Server se configura para que utilice un registro de usuario LDAP (Lightweight Directory Access Protocol), también puede configurar SSL con autenticación mutua entre cada servidor de aplicaciones y el servidor LDAP con certificados autofirmados para que ninguna contraseña sea visible cuando se pasa de WebSphere Application Server al servidor LDAP.
En este ejemplo no se han descrito los procesos de agente de nodo. Cada agente de nodo tiene que comunicarse con los servidores de aplicaciones en el mismo nodo y con el gestor de despliegue. Los agentes de nodo también necesitan comunicarse con los servidores LDAP cuando se han configurado para utilizar el registro de usuarios LDAP. Es lógico dejar que el gestor de despliegue y los agentes de nodo utilicen el mismo certificado. Supongamos que los servidores de aplicaciones A y C están en el mismo nodo de sistemas. El agente de nodo de dicho nodo necesita tener los certificados A y C en su almacén de confianza.
WebSphere Application Server no proporciona una configuración de registro ni un programa de utilidad de
gestión. Además, estipula la política de contraseñas del registro. Se recomienda
que utilice la política de contraseñas que recomienda el registro, incluidos el período de caducidad y la longitud de la
contraseña.
Servidor y la seguridad administrativa
- Características de CSIv2 (Common Secure Interoperability Versión 2)
- Aserción de identidad en el servidor en sentido descendente
- Selección de un mecanismo de autenticación
- Selección de un registro o repositorio
- Seguridad Java 2
- JAAS (Java Authentication and Authorization Service)
- Seguridad de conectores Java EE
- Excepción de control de acceso para la seguridad de Java 2
- Implementación de un proveedor de autenticación personalizado mediante JASPI