Seguridad
La información siguiente proporciona una visión general de la seguridad en WebSphere Application Server.
- Autenticación
- Control de acceso a recursos
- Integridad de los datos
- Confidencialidad
- Privacidad
- Interoperatividad segura
- Database 2 (DB2)
- CICS
Information Management System (IMS)
- MQ Series
- Lotus Domino
- IBM Directory
Un servidor de seguridad compatible con SAF (System Authorization Facility), incluido RACF (Resource Access Control Facility) de IBM z/OS Security Server.
- Un servidor proxy inverso seguro, incluido WebSEAL
Gestión de
identificación:
Para WebSphere Application Server
Versión 7.x y releases anteriores:
Para sacar partido de las características de seguridad de SAF,
los usuarios deben identificarse con un ID de usuario basado en z/OS. Puede utilizar módulos de correlación de principales
para correlacionar una identidad de J2EE con el ID de usuario basado en
plataforma (en este caso un ID de usuario de RACF). Se debe crear una correlación de
principales del ID de usuario LDAP con el ID de usuario
RACF,
para que se puedan realizar las comprobaciones de EJBROLE de SAF. Para
ello, debe existir un módulo de inicio de sesión de correlación que
permita derivar un ID de usuario
z/OS
del usuario configurado en el registro LDAP. (Se puede utilizar la auditoría SMF
(mediante SAF) para hacer un seguimiento de estos cambios).
Novedades para WebSphere Application Server Versión 8.0
y posterior:
![[z/OS]](../images/ngzos.gif)
- Utilice el módulo de correlación JAAS para correlacionar la identidad J2EE con una identidad SAF.
- Utilice la característica de correlación de identidad distribuida en SAF, que requiere una determinada versión de SAF. No se debe configurar ningún módulo de correlación JAAS en WebSphere. En este caso, los usuarios se identifican utilizando su identidad de usuario distribuido; por ejemplo, la identidad de usuario en el registro LDAP. La correlación se maneja mediante el administrador de seguridad de z/OS por medio de los perfiles de SAF RACMAP. Esta opción mejora la auditoría SMF al permitir que la identidad de usuarios distribuidos y la identidad SAF se registren en el registro de auditoría. Para obtener más información, consulte Correlación de identidad distribuida utilizando SAF.
Basado en estándares del sector
IBM WebSphere Application Server proporciona un modelo unificado, basado en permisos y políticas para proteger los recursos web, los puntos finales de servicio web y los Enterprise JavaBeans según las especificaciones J2EE. Específicamente, WebSphere Application Server es compatible con la especificación Java EE 6 y ha aprobado J2EE Compatibility Test Suite.
- Modelo de seguridad de Java 2, que ofrece un control de acceso de gran precisión, basado en permisos y políticas a los recursos del sistema.
- Protocolo de seguridad CSIv2
(Common Secure Interoperability Versión 2), además del protocolo de
seguridad SAS (Secure Authentication Services).
Ambos protocolos están soportados en releases anteriores de WebSphere Application Server. CSIv2 forma parte integral de la especificación J2EE 1.4 y es fundamental
para la interoperatividad entre los servidores de aplicaciones de proveedores
diferentes y con los servicios CORBA de empresa.
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.
- Modelo de programación JAAS (Java Authentication and Authorization Service) para las aplicaciones Java, servlets y enterprise beans.
- Arquitectura de conector J2EE para conectar adaptadores de recursos que den soporte al acceso a Enterprise Information Systems.
Los modelos e interfaces de seguridad estándar que admiten la comunicación de sockets seguros, el cifrado de mensajes y el cifrado de datos son JSSE (Java Secure Socket Extension) y JCE (Java Cryptographic Extension).
Paradigma de la arquitectura abierta
Un servidor de aplicaciones forma parte integral de la infraestructura de sistemas de empresa de varios niveles. IBM WebSphere Application Server adopta el paradigma de la arquitectura abierta, y proporciona varios puntos de plug-in para integrarse con los componentes de software de empresa para proporcionar seguridad de principio a fin. Los puntos de plug-in se basan en las especificaciones J2EE estándar, siempre que sea aplicable.
El fondo sombreado de color azul oscuro indica el límite entre WebSphere Application ServerVersión 9.0 y otros componentes de aplicación de empresa.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
El mecanismo de autenticación LTPA está diseñado para la seguridad de todas las plataformas. Los
servidores en sentido descendente pueden validar la señal de seguridad. También soporta el establecimiento de una relación de asociación de confianza con
servidores proxy seguros inversos y SSO (Inicio de sesión único), lo que se
analizará más adelante. Aparte de la combinación de LTPA y la interfaz
de registro de usuarios personalizado o LDAP, la versión 6.x o
posteriores da soporte a LTPA con una interfaz de registro de
usuarios del sistema operativo local. La
nueva configuración es particularmente útil para un solo nodo con varios servidores de
aplicaciones. Puede funcionar en un entorno distribuido si la implementación del
registro de usuarios del sistema operativo local es un registro de
usuarios centralizado, como por ejemplo
Windows
Domain Controller, o si se puede mantener en estado constante en varios
nodos.
WebSphere Application Server da soporte a la arquitectura de conector J2EE y
ofrece autenticación gestionada por contenedor.
Proporciona un módulo de
correlación de credenciales y principales J2C
(Java
2 Connector) predeterminado que correlaciona cualquier credencial de
usuario autenticado con una credencial de contraseña para el dominio de
seguridad EIS (Enterprise Information Systems) especificado. El módulo
de correlación es un módulo de inicio de sesión JAAS especial
que está diseñado según las especificaciones JAAS y el conector de Java 2. También se pueden conectar otros módulos de inicio de
sesión de correlación.
![[z/OS]](../images/ngzos.gif)
Registros de usuario y control de acceso
La información sobre los usuarios y los grupos reside en un registro de usuarios. En WebSphere Application Server, un registro de usuarios autentica un usuario y recupera información sobre los usuarios y grupos, para ejecutar funciones relacionadas con la seguridad, incluidas la autenticación y la autorización.
- Sistema operativo local basado en SAF
- LDAP
- Depósitos federados
Además de los registros de Local OS, LDAP y repositorios federados, WebSphere Application Server también proporciona un plug-in para dar soporte a cualquier registro utilizando la característica Registro personalizado (también llamado Registro de usuarios personalizado).
Cuando se selecciona la implementación del registro del sistema operativo local de WebSphere Application Server, puede integrar las funciones de z/OS Security Server, como RACF (Resource Access Control Facility), utilizando directamente SAF (Security Access Facility) en el entorno de WebSphere. Si configura un registro distinto del sistema operativo local, también puede aprovechar los recursos de z/OS Security Server con dos opciones. Puede configurar un módulo de correlación JAAS conectable (seguido de un módulo de inicio de sesión JAAS proporcionado por WebSphere Application Server para z/OS) en las configuraciones de inicio de sesión del sistema adecuadas. En WebSphere Application Server Versión 8.5, puede utilizar como alternativa la característica de correlación de identidades distribuidas.
Para más información, consulte Selección de un registro o repositorio.
Configuraciones de WebSphere Application Server: Con WebSphere Application ServerVersión 9.0 para z/OS puede integrar aplicaciones que no son z/OS con recursos específicos de z/OS como SAF (System Authorization Facility) y RACF. Esto permite unificar registros de WebSphere Application Server para z/OS y plataformas que no son z/OS. Por ejemplo:
Configuración del servidor de aplicaciones | Tipo de registro | Método de autorización | Ventaja |
---|---|---|---|
WebSphere Application Server | LDAP | Enlaces de WebSphere y proveedores de seguridad externos, por ejemplo Tivoli Access Manager | Registros compartidos (en un plataforma heterogénea) |
WebSphere Application Server para z/OS | RACF | Enlaces de WebSphere y EJBROLE de RACF | Acceso centralizado y recursos de auditoría (puede incluir servidores que ejecutan la versión 4.0) |
Entorno mixto de WebSphere Application Server | LDAP o personalizado | Enlaces de WebSphere, proveedores de seguridad externos y EJBROLE de RACF | Registros compartidos, acceso centralizado y recursos de auditoría |
- Configuración de registro de red de WebSphere Application Server
- Configuración de registro de red de WebSphere Application Server para z/OS:
- Registro de red de WebSphere Application Server con extensiones de seguridad de z/OS
Mecanismos de autenticación
- Lightweight Third Party Authentication (LTPA)
Lightweight Third Party Authentication genera una señal de seguridad para usuarios autenticados, que puede utilizarse para representar a ese usuario autenticado en llamadas posteriores al mismo servidor o a otros servidores dentro de un dominio de inicio de sesión único (SSO).
- Kerberos
Para este release de WebSphere Application Server se ha añadido soporte de seguridad para Kerberos como mecanismo de autenticación. Kerberos es un protocolo de autenticación de red desarrollado, flexible, abierto y muy seguro. Kerberos incluye las funciones de autenticación, autenticación mutua, integridad y confidencialidad de mensajes, así como funciones de delegación.
- SWAM (Simple
WebSphere
Authentication Mechanism)SWAM es fácil de configurar y muy útil en entornos de un solo servidor de aplicaciones, pero fuerza una autenticación de ID de usuario y contraseña para cada solicitud.Nota: SWAM estaba en desuso en un release anterior de WebSphere Application Servery se eliminará en futuros releases.
Protocolos de autenticación IIOP
El protocolo de autenticación IIOP hace referencia a los mecanismos utilizados para autenticar solicitudes desde un cliente Java a WebSphere Application Server para z/OS, o entre servidores de aplicaciones J2EE. CSIv2 (Common Secure Interoperability Versión 2) se implementa en WebSphere Application Server para z/OS Versión 6.x o posteriores y se considera el protocolo estratégico.
![[z/OS]](../images/ngzos.gif)
Seguridad de conector de WebSphere Application Server para z/OS
WebSphere Application Server da soporte a la arquitectura de conector J2EE y ofrece autenticación gestionada por contenedor. Proporciona un módulo de correlación de credenciales y principales J2C predeterminado que correlaciona cualquier credencial autenticada de usuario con una credencial de contraseña para el dominio de seguridad EIS (Enterprise Information Systems) especificado. También se da soporte a los conectores específicos de z/OS cuando el sistema EIS está en el mismo dominio de seguridad que WebSphere Application Server. En este caso, las contraseñas no son necesarias, ya que las credenciales de autenticación utilizadas para las solicitudes de J2EE se pueden utilizar como credenciales de EIS.
Seguridad de servicios web
WebSphere Application Server permite proteger los servicios web basándose en la especificación de seguridad de servicios web de OASIS (Organization for the Advancement of Structured Information Standards) Versión 1.1. Estos estándares especifican cómo proporcionar protección para el intercambio de mensajes en entornos de servicios web. La especificación define los recursos centrales para proteger la integridad y la confidencialidad de los mensajes y proporciona los mecanismos para asociar al mensaje demandas relacionadas con la seguridad.
Asociaciones de confianza
- IBM Tivoli Access Manager para e-business
- WebSEAL
- Proxy de memoria caché
Propagación de atributos de seguridad
- Un registro de usuarios de empresa que consulta atributos estáticos
- Un módulo de inicio de sesión personalizado que puede consultar atributos estáticos o dinámicos
Modalidad de interoperatividad de inicio de sesión único
En WebSphere Application Server, la opción de modalidad de interoperatividad habilita conexiones SSO (Inicio de sesión único) para que WebSphere Application Server versión 6.1.x o posteriores pueda interactuar con versiones anteriores del servidor de aplicaciones. Cuando se selecciona esta opción, WebSphere Application Server añade el LtpaToken antiguo en la respuesta para que se pueda enviar a otros servidores que sólo funcionan con este tipo de símbolo. Esta opción sólo se aplica cuando está habilitada la opción Propagación de atributos de seguridad de entrada web. Para obtener más información sobre el inicio de sesión único, consulte Implementación del inicio de sesión único para minimizar las autenticaciones de usuario web.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
![[z/OS]](../images/ngzos.gif)
Seguridad para recursos de J2EE con contenedores web y contenedores EJB
Cada contenedor ofrece dos tipos de seguridad: la seguridad declarativa y la seguridad programada. En la seguridad declarativa, la estructura de seguridad de una aplicación (que incluye la integridad y la confidencialidad de los datos, los requisitos de autenticación, los roles de seguridad y 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 J2EE. WebSphere Application Server mantiene una política de seguridad J2EE, incluida la información derivada del descriptor de despliegue y la especificada por los desplegadores y administradores en un conjunto de archivos del descriptor XML. En el tiempo de ejecución, el contenedor utiliza la política de seguridad definida en los archivos del descriptor XML para implantar 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, el código de la aplicación puede utilizar la seguridad programada para tomar las decisiones de acceso. La API (interfaz de programación de aplicaciones) para la seguridad programada consta de dos métodos de la interfaz EJBContext de EJB (Enterprise JavaBeans) (isCallerInRole, getCallerPrincipal) y tres métodos de la interfaz HttpServletrequest de servlet (isUserInRole, getUserPrincipal y getRemoteUser).
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[z/OS]](../images/ngzos.gif)
Seguridad Java 2
WebSphere Application Server da soporte al modelo de seguridad de Java 2. Los códigos de sistema como el subsistema administrativo, el contenedor web y el contenedor EJB, se ejecutan en el dominio de seguridad de WebSphere Application Server, al que en la actual implementación se otorga el permiso AllPermission y puede acceder a todos los recursos del sistema. El código de aplicación que se ejecuta en el dominio de seguridad de aplicación y al que, de forma predeterminada, se le otorgan los permisos de acuerdo con las especificaciones J2EE, sólo puede acceder a un conjunto restringido de recursos del sistema. Las clases de tiempo de ejecución de WebSphere Application Server están protegidas por el cargador de clases de WebSphere Application Server y son invisibles para el código de aplicación.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[z/OS]](../images/ngzos.gif)
Seguridad del conector J2EE (Java 2 Platform, Enterprise Edition)
WebSphere Application Server da soporte a la arquitectura de conector J2EE y ofrece autenticación gestionada por contenedor. Proporciona un módulo de correlación de credenciales y principales J2C predeterminado que correlaciona cualquier credencial autenticada de usuario con una credencial de contraseña para el dominio de seguridad EIS (Enterprise Information Systems) especificado.
También se da soporte a los conectores específicos de z/OS cuando el
sistema EIS está en el mismo dominio de seguridad que
WebSphere Application Server. En este caso, las contraseñas no son necesarias, ya que las
credenciales de autenticación utilizadas para las solicitudes de J2EE se
pueden utilizar como credenciales de EIS.
Para obtener más información, consulte Identidad de hebra de conexiones.
De forma predeterminada, todos los procesos de servidor de aplicaciones comparten una configuración de seguridad común, definida en un documento XML de seguridad a nivel de célula. La configuración de seguridad determina si se ha aplicado la seguridad de WebSphere Application Server, si se ha forzado la seguridad de Java 2, la configuración del mecanismo de autenticación y el registro de usuarios, las configuraciones del protocolo de seguridad, las configuraciones de inicio de sesión JAAS y las configuraciones SSL. Las aplicaciones pueden tener sus propios requisitos de seguridad exclusivos. Cada proceso del servidor de aplicaciones puede crear una configuración de seguridad por servidor, para dar respuesta a sus propios requisitos de seguridad o correlacionarse con un dominio de seguridad de WebSphere. No todas las configuraciones de seguridad se pueden modificar a nivel de servidor de aplicaciones. Algunas configuraciones de seguridad que pueden modificarse a nivel de servidor de aplicaciones incluyen la posibilidad de aplicar la seguridad de aplicaciones, la seguridad de Java 2 y las configuraciones del protocolo de seguridad. Los dominios de seguridad de WebSphere permiten más control sobre la configuración de seguridad y se pueden correlacionar con servidores individuales. Para obtener más información, consulte Varios dominios de seguridad.
Para obtener más información general, consulte
Estados de seguridad
con soporte de identidades de hebra.
La configuración de la seguridad del subsistema de administración viene siempre determinada por el documento de seguridad a nivel de célula. La configuración de la seguridad del contenedor web y el contenedor de EJB viene determinada por el documento opcional de seguridad a nivel de servidor, que tiene prioridad sobre el documento de seguridad a nivel célula.
La configuración de seguridad, a nivel de célula y a nivel de servidor de aplicaciones, está gestionada por la aplicación de consola administrativa basada en la web o por la aplicación de scripts adecuada.
![[z/OS]](../images/ngzos.gif)
Seguridad Web
- Autenticación básica HTTP
- Autenticación de clientes HTTPS
- Inicio de sesión basado en formularios
- Señal SPNEGO (Simple and Protected GSS-API Negotiation)
En WebSphere Application Server, el registro de usuarios del sistema operativo local no da soporte a la función de correlación.
Cuando se configura el mecanismo de autenticación
LTPA y se habilita SSO (inicio de sesión único), se emite para un cliente autenticado una
cookie de seguridad, que puede representar al usuario dentro del dominio de
seguridad especificado.
Se recomienda utilizar SSL (Capa de sockets seguros) para que no intercepten ni se reproduzcan la cookie de seguridad o la información de autenticación básica. Cuando se configura una asociación de confianza, WebSphere Application Server puede correlacionar una identidad de usuario autenticado con las credenciales de seguridad a partir de la relación de confianza establecida con el servidor proxy inverso seguro.
- 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 decisiones de autorización basándose en la política de seguridad derivada del descriptor de despliegue. Un principal de 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 los archivos JSP pueden utilizar los métodos HttpServletRequest: isUserInRole, getUserPrincipal y getRemoteUser. Por ejemplo, la consola administrativa utiliza el método isUserInRole para determinar el conjunto apropiado de funciones administrativas que se deben exponer a un principal de usuario.
- 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 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 de EJB puede utilizar los métodos EJBContext isCallerInRole y getCallerPrincipal. El código EJB también puede utilizar el modelo de programación JAAS para realizar el inicio de sesión de JAAS y los métodos WSSubject doAs y doAsPrivileged. El código del bloque doAs y doAsPrivileged PrivilegedAction se ejecuta bajo la identidad Subject. De lo contrario, el método de EJB se ejecuta bajo la identidad RunAs o la identidad de llamante, en función de la configuración de RunAs.
Seguridad de EJB
Cuando la seguridad está habilitada, el contenedor de EJB aplica el control de acceso al invocar el método de EJB. La autenticación se realiza independientemente de qué se haya definido un permiso de método para el método EJB específico.
Un cliente de aplicaciones Java puede proporcionar los datos de autenticación de varias formas. Utilizando el archivo sas.client.props, un cliente Java puede especificar si desea utilizar un ID de usuario y una contraseña para la autenticación, o si desea utilizar un certificado de cliente SSL. El certificado de cliente se almacena en el archivo de claves o en la tarjeta criptográfica de hardware, tal como está definido en un archivo sas.client.props. El ID de usuario y la contraseña se pueden definir de manera opcional en el archivo sas.client.props.
En tiempo de ejecución, el cliente Java puede realizar un inicio de sesión programado o realizar una autenticación poco activa.
En la autenticación poco activa, cuando el cliente Java accede a un enterprise bean protegido por primera vez, el tiempo de ejecución de seguridad intenta obtener los datos de autenticación necesarios. Dependiendo del valor de configuración en el archivo sas.client.props, el tiempo de ejecución de seguridad busca los datos de autenticación de este archivo o se los pide al usuario. El cliente Java también puede utilizar el inicio de sesión programado. WebSphere Application Server da soporte al modelo de programación JAAS, y el inicio de sesión JAAS (LoginContext) es la forma recomendada de iniciar sesión mediante programación. La función de ayudante login_helper request_login está en desuso en la versión 6.x y Versión 9.0. Los clientes Java programados en el APT login_helper pueden ejecutarse en esta versión.
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 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. El código EJB también puede utilizar el modelo de programación JAAS para realizar el inicio de sesión JAAS y los métodos WSSubject doAs y doAsPrivileged. El código en el bloque de PrivilegedAction doAs y doAsPrivileged se ejecuta con la identidad de Sujeto. De lo contrario, el método de EJB se ejecuta con la identidad de RunAs o la identidad del llamante, dependiendo de la configuración de RunAs. La especificación RunAs de J2EE ocurre a nivel de enterprise bean. Cuando se especifica la identidad de RunAs, se aplica a todos los métodos de bean. La extensión de IBM RunAs a nivel de método presentada en la versión 4.0 continúa estando soportada en esta versión.
![[z/OS]](../images/ngzos.gif)
Aprobación de FIPS (Federal Information Processing Standards)
FIPS (Federal Information Processing Standards) son los estándares y directrices emitidos por el National Institute of Standards and Technology (NIST) para los sistemas informáticos federales. Los FIPS se desarrollan cuando el gobierno federal tiene una necesidad urgente de estándares, como por ejemplo para la seguridad y la interoperatividad, pero no existen estándares ni soluciones del sector aceptables.
WebSphere Application Server integra módulos criptográficos, que incluyen JSSE (Java Secure Socket Extension) y JCE (Java Cryptography Extension), que se han sometido a la certificación FIPS 140-2.
Para más información, consulte Configuración de los archivos JSSE (Java Secure Socket Extension) aprobados por FIPS (Federal Information Processing Standard).
- AES (FIPS 197)
- TripleDES (FIPS 46-3)
- SHA1 Algoritmo de conversión de mensajes (FIPS 180-1)
- Algoritmos RSA y DSA de firma digital (FIPS 186-2)
- ANSI X 9.31 (FIPS 186-2)
- IBM Random Number Generator
El módulo criptográfico IBMJCEFIPS contiene los algoritmos aprobados por FIPS, que constituyen un subgrupo adecuado de los que aparecen en los módulos IBM JCE.