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:

En esta sección también se examina la protección de seguridad ofrecida por cada capa de seguridad y la práctica de seguridad común para obtener una buena calidad de protección en la seguridad de extremo a extremo. La figura siguiente ilustra los bloques de creación que forman el entorno operativo para la seguridad en WebSphere® Application Server

La siguiente información describe todos los componentes de la seguridad de WebSphere Application Server, la seguridad Java™ y la seguridad de plataforma que se ilustran en la figura anterior.
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
[AIX Solaris HP-UX Linux Windows][IBM i]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.

[z/OS]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.
Instalación de WebSphere Application Server, Network Deployment
Importante: Existe una instancia de agente de nodo en todos los nodos del sistema.

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.

[AIX Solaris HP-UX Linux Windows][IBM i]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.

[AIX Solaris HP-UX Linux Windows][IBM i]La figura siguiente muestra un típico entorno de cálculo empresarial de varios niveles.Existe una instancia de agente de nodo en cada nodo de sistema. Cada servidor de aplicaciones de producto consta de un contenedor web, un contenedor EJB (Enterprise Java Beans) y del 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.

[z/OS]La figura siguiente muestra un típico entorno de cálculo empresarial de varios niveles.Existe una instancia de agente de nodo en cada nodo de sistema. Cada servidor de aplicaciones de producto consta de un contenedor web, un contenedor EJB (Enterprise Java Beans) y del 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.

Seguridad administrativa

[AIX Solaris HP-UX Linux Windows][IBM i]Los servidores WebSphere Application Server interactúan entre sí a través de los protocolos de seguridad CSIv2 y SAS (Secure Authentication Services), así como los protocolos HTTP y HTTPS.
Importante: z/SAS sólo está soportado entre servidores de la versión 6.0.x y anteriores que se hayan federado en una célula de la Versión 6.1.
[z/OS]Los servidores WebSphere Application Server interactúan entre sí a través de los protocolos de seguridad CSIv2 y z/SAS (z/OS Secure Authentication Services), así como los protocolos HTTP y HTTPS.
Importante: z/SAS sólo está soportado entre servidores de la versión 6.0.x y anteriores que se hayan federado en una célula de la Versión 6.1.

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.

[z/OS]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.

[AIX Solaris HP-UX Linux Windows][IBM i]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.

[z/OS]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

WebSphere Application Server amplía la seguridad, el control de acceso basado en roles a los recursos administrativos, incluido el subsistema de gestión del sistema JMX, los registros de usuario y el espacio de nombres JNDI ( Java Naming and Directory Interface). El subsistema de administración de WebSphere define cuatro roles de seguridad de administración:
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.
WebSphere Application Server define dos roles adicionales que sólo están disponibles cuando se utilizan scripts de wsadmin.
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.

Tabla 1. Permisos de seguridad de Java EE establecidos para los componentes web. Los permisos de seguridad Java EE establecidos para los componentes web se muestran en la tabla siguiente.
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
Tabla 2. Permisos de seguridad de Java EE establecidos para los componentes EJB. Los permisos de seguridad Java EE establecidos para los componentes EJB se muestran en la tabla siguiente.
Permiso de seguridad Destino Action
java.lang.RuntimePermission queuePrintJob  
java.net.SocketPermission * connect
java.util.PropertyPermission * lectura
Las políticas de seguridad predeterminadas de WebSphere Application Server Java 2 se basan en la especificación de Java EE versión 1.4. La especificación otorga a los componentes web permiso de acceso de lectura y escritura a cualquier archivo del sistema de archivos, que puede ser demasiado amplio. La política por omisión de WebSphere Application Server otorga a los componentes web permisos de lectura y escritura al subdirectorio y al subárbol donde está instalado el módulo web. Las políticas de seguridad de Java 2 por omisión para todos los procesos de JVM (máquinas virtuales Java) y WebSphere Application Server están en los siguientes archivos de política:
[IBM i]/QIBM/ProdData/Java400/jdk15/lib/security/java.policy
[IBM i]Se utiliza como política por omisión para JVM (máquina virtual Java).
[AIX Solaris HP-UX Linux Windows][z/OS]${java.home}/jre/lib/security/java.policy
[AIX Solaris HP-UX Linux Windows][z/OS]Este archivo se utiliza como política por omisión para JVM (máquina virtual Java).
[AIX Solaris HP-UX Linux Windows][IBM i]${USER_INSTALL_ROOT}/properties/server.policy
[AIX Solaris HP-UX Linux Windows][IBM i]Este archivo se utiliza como política por omisión para todos los procesos de servidor del producto.
[z/OS]$WAS_HOME/properties/server.policy
[z/OS]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]
  • 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]
  • $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]
  • 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.

Por lo general, las aplicaciones no requieren más permisos para ejecutarse que los que recomienda la especificación Java EE para poder llevarse entre los distintos servidores de aplicaciones. No obstante, algunas aplicaciones pueden exigir más permisos. WebSphere Application Server da soporte al empaquetado de un archivo was.policy con todas las aplicaciones a fin de otorgar permisos adicionales a esa aplicación.
Atención: Otorgue permisos adicionales a una aplicación únicamente después de considerar cuidadosamente la posibilidad de que se ponga en peligro la integridad del sistema.

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 especifique las opciones Habilitar seguridad administrativa y Utilizar la seguridad de Java 2 para restringir a las aplicaciones el acceso a los recursos locales en el panel Seguridad global de la consola administrativa, la información y los demás datos de configuración sensibles se almacenan en un conjunto de archivos de configuración XML. Tanto el control de acceso basado en roles como el control de acceso basado en permisos de seguridad de Java 2 se emplean para proteger la integridad de los datos de configuración. En el ejemplo se utiliza la protección de datos de configuración para ilustrar cómo se mantiene la integridad del sistema.
Atención: La opción Habilitar seguridad global de releases anteriores de WebSphere Application Server es la misma que la opción Habilitar seguridad administrativa de Versión 9.0. Asimismo, la opción Habilitar seguridad de Java 2 de releases anteriores es la misma que la opción Utilizar la seguridad de Java 2 para restringir a las aplicaciones el acceso a los recursos locales de Versión 9.0.
  • 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][IBM i]

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.

[z/OS]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.

Si empieza por el plug-in de WebSphere Application Server en el servidor web, puede configurar la autenticación SSL mutua entre él y el servidor HTTPS de WebSphere Application Server. Cuando se utiliza el certificado, puede limitar el plug-in de WebSphere Application Server de modo que sólo pueda comunicarse con los dos servidores WebSphere Application Server seleccionados, como se muestra en la figura siguiente. Tenga en cuenta que puede utilizar los certificados autofirmados para reducir la administración y los costes.
Por ejemplo, desea restringir el servidor HTTPS en WebSphere Application Server A y en WebSphere Application Server B para que sólo acepte conexiones de sockets seguros del plug-in W de WebSphere Application Server.
Por ejemplo, suponga que desea restringir el servidor HTTPS en WebSphere Application Server A y en WebSphere Application Server B de forma que acepte sólo las conexiones de socket seguro del plug-in de WebSphere Application Server, W.
  • [AIX Solaris HP-UX Linux Windows][IBM i]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.
  • [z/OS]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.
Configure el servidor HTTPS de WebSphere Application Server B para utilizar el certificado B y confiar en el certificado W. l
Tabla 3. Relaciones de confianza de ejemplo. La relación de confianza que aparece en la figura anterior se muestra en la siguiente tabla.
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.

Es posible que desee restringir WebSphere Application Server A para que se pueda comunicar sólo con WebSphere Application Server C y WebSphere Application Server B se pueda comunicar sólo con WebSphere Application Server D. Todos los WebSphere Application Server deben poder comunicarse con el gestor de despliegue de WebSphere Application Server E; por lo tanto, cuando utilice certificados autofirmados, podría configurar la relación de la clave y confianza CSIv2 y SOAP/HTTPS, tal como se muestra en la siguiente tabla.
Tabla 4. Relaciones de confianza y claves CSIv2 y SOAP/HTTPS de ejemplo. Las relaciones de confianza y claves CSIv2 y SOAP/HTTPS se muestran en la tabla siguiente.
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.

[AIX Solaris HP-UX Linux Windows][IBM i]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.


Icon that indicates the type of topic Concept topic



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