Protección de canales con SSL/TLS

El soporte TLS en IBM® MQ utiliza el objeto de información de autenticación del gestor de colas y varios mandatos MQSC. También debe contemplar el uso de certificados digitales.

Certificados digitales y depósitos de claves

Se recomienda establecer el atributo de etiqueta de certificado del gestor de colas (CERTLABL) en el nombre del certificado personal que se va a utilizar para la mayor parte de los canales, y alterarlo temporalmente en el caso de excepciones, estableciendo la etiqueta de certificado en aquellos canales que requieren certificados diferentes.

Si necesita muchos canales con certificados que difieren del conjunto de certificados predeterminado en el gestor de colas, debe considerar la posibilidad de dividir los canales entre varios gestores de colas o utilizar un proxy MQIPT frente al gestor de colas para presentar un certificado diferente.

Puede utilizar un certificado diferente para cada canal, pero si almacena demasiados certificados en un depósito de claves, el rendimiento puede verse afectado cuando se inician los canales TLS. Intente mantener el número de certificados en un repositorio de claves en menos de unos 50 y considere que 100 es un máximo, ya que el rendimiento de IBM Global Security Kit (GSKit) disminuye drásticamente con repositorios de claves más grandes.

Si se permiten varios certificados en el mismo gestor de colas se aumentan las posibilidades de que se utilizarán varios certificados de CA en el mismo gestor de colas. De este modo, se aumentan las posibilidades de que existan conflictos en los espacios de nombres distinguidos del asunto para los certificados emitidos por diferentes entidades emisoras de certificados.

Aunque es probable que las entidades emisoras de certificados profesionales tengan mucho cuidado, normalmente las entidades emisoras de certificados internas no tienen convenios de denominación claros y pueden producirse incoherencias no intencionadas entre una entidad emisora de certificados y otra.

Debe comprobar el nombre distinguido del emisor del certificado además del nombre distinguido del asunto. Para ello,utilice un registro SSLPEERMAP de autenticación y establezca los campos SSLPEER y SSLCERTI de modo que coincidan con el nombre distinguido del asunto y del emisor respectivamente.

Certificados autofirmados y firmados por CA

Es importante planificar el uso de certificados digitales, tanto cuando se está desarrollando y probando la aplicación y para su uso en producción. Puede usar certificados firmados por CA o certificados autofirmados, en función del uso de los gestores de colas y las aplicaciones cliente.

Certificados firmados por CA
Para los sistemas de producción, obtenga los certificados de una autoridad certificadora de confianza (CA). Cuando obtiene un certificado de una CA externa, debe pagar por el servicio.
Certificados autofirmados
Mientras desarrolla la aplicación puede utilizar certificados autofirmados o certificados emitidos por una CA local, según la plataforma:

[UNIX, Linux, Windows]En sistemas Windows, UNIXy Linux® , puede utilizar certificados autofirmados. Consulte Creación de un certificado personal autofirmado en UNIX, Linuxy Windowspara obtener instrucciones.

[IBMi]En sistemas IBM i , puede utilizar certificados firmados por la CA local. Consulte Solicitud de un certificado de servidor en IBM i para obtener instrucciones.

[z/OS]En z/OS®, puede utilizar certificados autofirmados o firmados por CA locales. Consulte Creación de un certificado personal autofirmado en z/OS o Solicitud de un certificado personal en z/OS para obtener instrucciones.

Los certificados autofirmados no son adecuados para el uso en producción por las siguientes razones:
  • Los certificados autofirmados no se pueden revocar, lo que podría permitir a un atacante suplantar una identidad después de que se haya comprometido una clave privada. Las CA pueden revocar un certificado comprometido, lo que impide su posterior uso. Los certificados firmados por una CA son, por lo tanto, más seguros para su uso en un entorno de producción, aunque los certificados autofirmados son más convenientes para un sistema de prueba.
  • Los certificados autofirmados nunca caducan. Esto es cómodo y seguro en un entorno de prueba, pero en un entorno de producción pueden producirse infracciones de seguridad. El riesgo se agrava por el hecho de que los certificados autofirmados no se pueden revocar.
  • Un certificado autofirmado se utiliza como un certificado personal y como un certificado de CA raíz (o ancla de confianza del certificado). Un usuario con un certificado personal autofirmado podría utilizarlo para firmar otros certificados personales. En general, esto no se cumple en certificados personales emitidos por una CA y representa un riesgo significativo.

CipherSpecs y certificados digitales

Únicamente un subconjunto de las CipherSpecs soportadas puede utilizarse con todos los tipos de certificados digitales soportados. Por consiguiente, es necesario que elija una CipherSpec adecuada para su certificado digital. Del mismo modo, si la política de seguridad de la empresa requiere que se utilice una determinada CipherSpec, debe obtener certificados digitales adecuados.

Para obtener más información sobre la relación entre CipherSpecs y los certificados digitales, consulte Certificados digitales y compatibilidad con CipherSpec en IBM MQ

Políticas de validación de certificados

El estándar IETF RFC 5280 especifica una serie de reglas de validación de certificados que el software de aplicación compatible debe implementar para evitar ataques de suplantación. Un conjunto de reglas de validación de certificados se conoce como una política de validación de certificados. Para obtener más información sobre las políticas de validación de certificados en IBM MQ, consulte Políticas de validación de certificados en IBM MQ.

Planificación de la comprobación de la revocación de certificados

Si se permiten varios certificados de diferentes entidades emisoras de certificados es muy probable que se requiera una comprobación adicional de la revocación de certificados.

En concreto, si ha configurado explícitamente el uso de un servidor de revocación desde una CA específica, por ejemplo, utilizando un objeto AUTHINFO o una estructura MQAIR (Authentication Information Record), la comprobación de la revocación fallará cuando se presente un certificado de una CA diferente.

Debe evitar esta configuración explícita del servidor de revocación de certificados. En su lugar, debe habilitar la comprobación implícita en la que cada certificado contiene su propia ubicación del servidor de revocación en una extensión del certificado, por ejemplo, un punto de distribución de CRL o AuthorityInfoAccess de OCSP.

Para obtener más información, consulte OCSPCheckExtensions y CDPCheckExtensions.

Mandatos y atributos para soporte TLS

El protocolo TLS (seguridad de la capa de transporte) proporciona seguridad de canal, con protección contra escuchas y manipulaciones no autorizadas y contra falsas identidades. El soporte de IBM MQ para TLS le permite especificar, en la definición de canal, que un canal determinado utilice la seguridad TLS. También puede especificar información detallada sobre el tipo de seguridad que desea, como por ejemplo, el algoritmo de cifrado que desea utilizar.

  • Los mandatos MQSC siguientes dan soporte a TLS:
    ALTER AUTHINFO
    Modifica los atributos de un objeto de información de autenticación.
    DEFINE AUTHINFO
    Crea un objeto de información de autenticación.
    DELETE AUTHINFO
    Suprime un objeto de información de autenticación.
    DISPLAY AUTHINFO
    Visualiza los atributos de un objeto de información de autenticación específico.
  • Los siguientes parámetros de gestor de colas dan soporte a TLS:
    CERTLABL
    Define una etiqueta de certificado personal que utilizar.
    SSLCRLNL
    El atributo SSLCRLNL especifica una lista de nombres de objetos de información de autenticación que se utilizan para proporcionar ubicaciones de revocación de certificados para permitir la comprobación de certificados TLS mejorada.
    SSLCRYP
    En sistemas Windows , UNIX y Linux , establece el atributo de gestor de colas SSLCryptoHardware . Este atributo es el nombre de la serie de parámetros que puede utilizar para configurar el hardware criptográfico que tiene en el sistema.
    SSLEV
    Determina si se envía un mensaje de suceso TLS cuando un canal que utiliza TLS no puede establecer una conexión TLS correctamente.
    SSLFIPS
    Especifica si sólo se van a utilizar algoritmos certificados por FIPS si la criptografía se lleva a cabo en IBM MQ , en lugar de en hardware criptográfico. Si el hardware de cifrado está configurado, se utilizan los módulos de cifrado que proporciona el producto de hardware, que pueden estar certificados por FIPS en un nivel determinado. Depende del producto de hardware que se esté utilizando.
    SSLKEYR
    En sistemas UNIX, Linuxy Windows , asocia un repositorio de claves con un gestor de colas. La base de datos de claves se mantiene en una base de datos de claves de GSKit . GSKit le permite utilizar la seguridad TLS en sistemas Windows , UNIX y Linux .
    SSLRKEYC
    El número de bytes que se deben enviar y recibir en una conversación TLS antes de volver a negociar la clave secreta. El número de bytes incluye la información de control que envía el MCA.
  • Los siguientes parámetros de canal dan soporte a TLS:
    CERTLABL
    Define una etiqueta de certificado personal que utilizar.
    SSLCAUTH
    Define si IBM MQ requiere y valida un certificado del cliente TLS.
    SSLCIPH
    Especifica la fuerza del cifrado y su función (CipherSpec), por ejemplo, TLS_RSA_WITH_AES_128_CBC_SHA. CipherSpec debe coincidir en ambos extremos del canal.
    SSLPEER
    Especifica el nombre distinguido (identificador exclusivo) de los asociados permitidos.
En este apartado se describen los mandatos setmqaut, dspmqaut, dmpmqaut, rcrmqobj, rcdmqimg y dspmqfls para dar soporte al objeto de información de autenticación. También describe el mandato runmqckm (iKeycmd) para gestionar certificados en sistemas UNIX y Linux y la herramienta runmqakm para gestionar certificados en UNIX, Linuxy Windows. Consulte los apartados siguientes:
Para obtener una visión general de la seguridad de canal utilizando TLS, consulte
Para conocer detalles de los mandatos MQSC asociados a TLS, consulte
Para conocer detalles de los mandatos PCF asociados a TLS, consulte