[z/OS]

Seguridad SSL (Secure Socket Layer) de WebSphere Application Server for z/OS

En este tema se presupone que entiende el protocolo SSL (Secure Sockets Layer) y el funcionamiento del sistema de servicios criptográficos SSL en z/OS. SSL lo utilizan varios componentes dentro de WebSphere Application Server para proporcionar confianza y privacidad. Estos componentes incluyen el transporte HTTP incorporado, el ORB (Object Request Broker) de cliente y servidor, y el cliente LDAP (Lightweight Directory Access Protocol) seguro. La configuración de SSL es distinta entre cliente y servidor con WebSphere Application Server. Si desea obtener seguridad adicional para las comunicaciones protegidas y la autenticación de usuarios en una red, puede utilizar la seguridad de SSL.

SSL forma parte integral de la seguridad que proporciona WebSphere Application Server for z/OS. Se activa cuando se habilita la seguridad administrativa. Cuando se habilita la seguridad administrativa, el subsistema administrativo utiliza siempre SSL para proteger los mandatos administrativos, la consola de administración y las comunicaciones entre procesos de WebSphere Application Server.

El tiempo de ejecución de WebSphere Application Server para z/OS puede, si lo desea, utilizar SSL cuando se habilita la seguridad del servidor en tales casos:
  • SSL se utiliza para proteger la aplicación web cuando se especifica la confidencialidad como restricción de seguridad de la aplicación Web. Una garantía de transporte CONFIDENCIAL o INTEGRAL garantiza que las comunicaciones entre el cliente web y el servidor web sean seguras y a través de HTTPS (HTTP SSL). Además, puede utilizar SSL para llevar a cabo autenticaciones de clientes cuando la restricción de seguridad (CLIENT_CERT) se especifique durante el despliegue de la aplicación.
  • SSL puede utilizarse para proteger las solicitudes IIOP (Inter-ORB Protocol) cuando se da soporte a SSL/TLS (o es necesario) en los valores de transporte de CSIV2 (Common Secure Interoperability version 2). Se establecen pulsando Seguridad > Seguridad global. Seguridad RMI/IIOP pulse Transporte de entrada CSIv2 o Transporte de salida CSIv2.
  • SSL puede servir para proteger las comunicaciones entre un cliente y un servidor LDAP cuando el registro de usuarios activo es LDAP.
Al configurar SSL, hay dos tipos de repertorios SSL en WebSphere Application Server para z/OS. El tipo de repertorio está relacionado con los servicios subyacentes empleados para procesar SSL.
  • Debe seleccionarse JSSE (Java™ Secure Socket Extension) como el tipo de repertorio SSL para solicitudes administrativas utilizando el conector HTTP/SOAP. Los repertorios JSSE pueden (después de aplicar APAR PQ77586) especificar un conjunto de claves SAF para el almacén de claves o el almacén de confianza, o para un archivo HFS (sistema jerárquico de archivos).
Nota: Todos los repertorios de configuración SSL del tipo SSL (System Secure Sockets Layer), excepto aquello que pertenecen al daemon, se convierten al tipo JSSE (Java Secure Socket Extension). Ahora SSL de sistema sólo lo utiliza el Espacio de direcciones de daemon porque el daemon se ejecuta sin JVM y JSSE sólo se soporta en Java.

En este tema se ofrece una breve explicación del protocolo SSL y de su funcionamiento en z/OS. Para obtener información acerca del protocolo SSL, vaya al sitio web siguiente: http://home.netscape.com/eng/ssl3/ssl-toc.html

SSL (Secure Sockets Layer) lo utilizan varios componentes dentro de WebSphere Application Server para proporcionar confianza y privacidad. Estos componentes son el transporte HTTP incorporado, el ORB (cliente y servidor) y el cliente LDAP seguro. La configuración de SSL es distinta entre cliente y servidor con WebSphere Application Server. Si desea obtener seguridad adicional para las comunicaciones protegidas y la autenticación de usuarios en una red, puede utilizar la seguridad de SSL (Secure Sockets Layer). El soporte para SSL en in WebSphere Application Server for z/OS tiene varios objetivos:
  • Proporcionar formas aceptadas por la industria de proteger la seguridad de los mensajes a medida que van fluyendo por la red. Esto suele denominarse Transport Layer Security. TSL (Transport Layer Security) es una función que proporciona privacidad e integridad de datos entre dos aplicaciones comunicantes. La protección se produce en una capa de software sobre el protocolo de transporte de base (por ejemplo, sobre TCP/IP).

    SSL proporciona seguridad sobre el enlace de comunicaciones mediante tecnologías de cifrado, lo que garantiza la integridad de los mensajes en la red. Como las comunicaciones están cifradas entre las dos partes, un tercero no puede interferir en los mensajes. SSL también proporciona confidencialidad (con lo que garantiza que el mensaje no se pueda leer), detección de respuesta y detección de "fuera de secuencia".

  • Proporcionar un medio de comunicación seguro mediante el que distintos protocolos de autenticación puedan operar. Una sesión de SSL única puede contener varios protocolos de autenticación, es decir, varios métodos de probar las identidades de los participantes en la comunicación.
    El soporte de SSL siempre proporciona un mecanismo mediante el que el servidor prueba su identidad. El soporte de SSL en WebSphere Application Server para z/OS permite las formas siguientes para que los clientes prueben su identidad:
    • La autenticación básica (también denominada autenticación SSL Tipo 1), en la que un cliente prueba su identidad al servidor mediante el paso del ID de un usuario y su contraseña (o frase de contraseña) que son conocidos por el servidor de destino.
      Con la autenticación básica de SSL:
      • Un cliente z/OS puede comunicarse de forma segura con WebSphere Application Server for z/OS con un ID de usuario y una contraseña definidas por el mecanismo de nombre de usuario y contraseña CSIv2 denominado GSSUP (Generic Security Services Username Password).
      • Un cliente de WebSphere Application Server puede comunicarse de forma segura con un servidor WebSphere Application Server para z/OS utilizando un ID de usuario y contraseña (o expresión de contraseña) de MVS.
      • Como siempre es necesaria una contraseña en las solicitudes, sólo pueden establecerse las conexiones cliente-a-servidor simples. Es decir, el servidor no puede enviar el ID de usuario de un cliente a otro servidor para la respuesta a una solicitud.
    • El soporte para certificados de cliente, en los que tanto el servidor como el cliente deben probarse sus respectivas identidades.

      Cuando se proporcionan certificados digitales para autenticación a WebSphere Application Server para z/OS, el certificado descifrado se correlaciona con una identidad de usuario válida en el repositorio de usuarios habilitado. Las aplicaciones Web pueden tener miles de clientes, lo que hace que la gestión de la autenticación de clientes suponga una sobrecarga administrativa. Cuando el sistema operativo local es el repositorio de usuarios habilitado en WebSphere Application Server para z/OS, el filtro de nombres de certificados SAF le permite correlacionar certificados de cliente, sin tener que almacenarlos, en los ID de usuario de MVS. Mediante el filtro de nombres de certificados, puede autorizar a conjuntos de usuarios el acceso a servidores sin la sobrecarga administrativa de tener que crear ID de usuario de MVS ni gestionar los certificados de cliente para cada usuario.

    • El soporte de SSL siempre proporciona un mecanismo mediante el que el servidor prueba su identidad. Son varios los mecanismos que pueden utilizarse para probar la identidad de los clientes. El protocolo SSL v3 (y TLS) permite que los certificados digitales de clientes puedan intercambiarse si lo desea. Estos certificados pueden utilizarse para la autenticación.
    • El soporte de aserción de identidad de CSIv2, que incluye los principales de z/OS, los nombres distinguidos X501 y los certificados digitales X509.
    • La aserción de identidad, o la asociación de confianza, en la que un servidor intermediario puede enviar las identidades de sus clientes al servidor de destino de una forma segura y eficaz. Este soporte utiliza los certificados de cliente para establecer el servidor intermediario como propietario de una sesión de SSL. Con RACF (Resource Access Control Facility), el sistema puede asegurarse de que se puede confiar en el servidor intermedio (para ofrecer este nivel de confianza, los administradores otorgan autorización CBIND a los ID de usuario de RACF que ejecutan el código de sistema seguro). Una vez que se establece la confianza en este servidor intermedio, el servidor de destino no debe verificarse de forma separada las identidades del cliente (los ID de usuario de MVS); esas identidades de clientes simplemente se confirman sin necesidad de autenticación.
  • Para poder interoperar de forma segura con otros productos, como:
    • Servidor de transacciones CICS (Customer Information Control System) para z/OS
    • Otras versiones de WebSphere Application Server
    • Object Request Brokers compatibles con CORBA (Common Object Request Broker Architecture)

SSL está inhabilitado por omisión y el soporte de SSL es opcional. Si está ejecutando WebSphere Application Server para z/OS con la seguridad activada, la consola de administración necesita SSL. Java Secure Socket Extension (JSSE) es el tipo de repertorio SSL utilizado.

Tabla 1. Secuencia de conexiones SSL.

En esta tabla se describe cómo funciona una conexión SSL.

Fase Descripción
Negociación Una vez que el cliente ha localizado el servidor, el cliente y el servidor negocian el tipo de seguridad para las comunicaciones. Si va a utilizarse SSL, se indica al cliente que se conecte a un puerto SSL especial.
Acoplamiento El cliente se conecta al puerto SSL y se produce el reconocimiento de comunicación SSL. Si es satisfactorio, se inicia la comunicación cifrada. El cliente autentica el servidor inspeccionando el certificado digital del servidor.

Si se utilizan certificados de cliente durante el reconocimiento de comunicación, el servidor autentica el cliente inspeccionando su certificado digital.

Comunicación en curso. Durante el reconocimiento de comunicación SSL, el cliente y el servidor negocian una especificación de cifrado que se utilizará para cifrar las comunicaciones.
solicitud de primer cliente La determinación de la identidad de cliente depende del mecanismo autenticación de clientes elegido, que puede ser uno de los siguientes:
  • ID de usuario y contraseña CSIv2 (GSSUP)
  • Identidad comprobada CSIv2

Normas

  • Un cliente Java o C++ en z/OS es interoperable con un WebSphere Application Server para z/OS o una estación de trabajo del servidor de aplicaciones, y puede utilizar. La seguridad CSIv2 sólo soporta clientes Java en z/OS.
  • Parte del reconocimiento de comunicación es negociar las especificaciones criptográficas utilizadas por SSL para la protección de mensajes. Dos factores determinan las especificaciones de cifrado y los tamaños de clave utilizados:
    • El nivel de seguridad de los servicios criptográficos instalados en el sistema, que determina las especificaciones de cifrado y los tamaños de claves disponibles para WebSphere Application Server para z/OS.
    • La configuración del servidor mediante la consola de administración le permite especificar las suites de cifrado SSL.
    Para obtener más información, consulte z/OS System Secure Sockets Layer Programming.
  • Para los sockets System SSL de z/OS debe utilizar RACF o un equivalente para almacenar claves y certificados digitales. La colocación de claves y certificados digitales en una base de datos de claves en HFS no es una opción.
Consejo: Para definir la seguridad de autenticación básica de SSL, debe antes solicitar un certificado firmado para el servidor y una certificado de autoridad de certificación (CA) de la autoridad de certificación que ha firmado el certificado del servidor. Después de que haya recibido un certificado firmado para el servidor y un certificado de CA de la autoridad de certificación, debe utilizar RACF para autorizar el uso de certificados digitales, certificados de servidor de almacén y conjuntos de claves de servidor en RACF, cree un alias de repertorio SSL y defina las propiedades de seguridad SSL para el servidor mediante la consola de administración.

Para los clientes, debe crear un conjunto de claves y conectar a él el certificado de CA desde la autoridad de certificación que emitió el certificado del servidor. Para un cliente z/OS, debe utilizar RACF para crear un conjunto de claves de cliente y para conectar el certificado de CA a ese conjunto de claves. Para que el cliente autentique el servidor, éste (en realidad, el ID de usuario del controlador) debe poseer un certificado firmado por una autoridad de certificación. El servidor pasa el certificado firmado para probar su identidad al cliente. El certificado de CA del cliente debe proceder de la misma autoridad de certificación que emitió el certificado del servidor. El cliente utiliza el certificado de CA para verificar la autenticidad del certificado del servidor. Una vez verificado el certificado, el cliente puede tener la seguridad de que los mensajes realmente proceden de ese servidor y no de otro lugar. Para que el servidor autentique el cliente, observe que el cliente no pasa ningún certificado que pruebe su identidad al servidor. En el esquema de autenticación básica de SSL, el servidor autentica el cliente solicitándole un ID de usuario y una contraseña (o frase de contraseña).

Consulte Configuración de un conjunto de claves para sea utilizado por SSL (Secure Sockets Layer) del daemon para obtener información sobre la creación de un conjunto de claves para el ID de usuario de MVS del daemon.


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_settingupssl
File name: csec_settingupssl.html