Protection des canaux avec SSL/TLS

La prise en charge de TLS dans IBM® MQ utilise l'objet d'informations d'authentification du gestionnaire de files d'attente et diverses commandes MQSC. Vous devez également tenir compte de votre utilisation des certificats numériques.

Certificats numériques et référentiels de clés

Il est recommandé de définir l'attribut de label de certificat du gestionnaire de files d'attente ( CERTLABL ) au nom du certificat personnel à utiliser pour la majorité des canaux, et le remplacer pour les exceptions, en définissant le label de certificat sur les canaux qui requièrent des certificats différents.

Si vous avez besoin de plusieurs canaux avec des certificats différents du certificat par défaut défini sur le gestionnaire de files d'attente, vous devez envisager de diviser les canaux entre plusieurs gestionnaires de files d'attente ou d'utiliser un proxy MQIPT devant le gestionnaire de files d'attente pour présenter un certificat différent.

Vous pouvez utiliser un certificat différent pour chaque canal, mais si vous stockez un trop grand nombre de certificats dans un référentiel de clés, vous pouvez vous attendre à ce que les performances soient affectées lors du démarrage des canaux TLS. Essayez de maintenir le nombre de certificats dans un référentiel de clés à moins de 50 environ et considérez que 100 est un maximum car les performances d' IBM Global Security Kit (GSKit) diminuent fortement avec les référentiels de clés plus volumineux.

L'autorisation de plusieurs certificats sur le même gestionnaire de files d'attente augmente les chances que plusieurs certificats de l'autorité de certification soient utilisés sur le même gestionnaire de files d'attente. Cela augmente les chances de conflits d'espace de nom de nom distinctif de sujet de certificat pour les certificats émis par des autorités de certification distinctes.

Alors que les autorités de certification professionnelles sont susceptibles d'être plus prudentes, les autorités de certification internes manquent souvent de conventions de dénomination claires et vous pourriez vous retrouver avec des correspondances inattendues entre une autorité de certification et une autre.

Vous devez vérifier le nom distinctif de l'émetteur du certificat en plus du nom distinctif du sujet. Pour ce faire, utilisez un enregistrement SSLPEERMAP d'authentification de canal et définissez les zones SSLPEER et SSLCERTI pour qu'elles correspondent respectivement au nom distinctif du sujet et au nom distinctif de l'émetteur.

Certificats autosignés et signés par une autorité de certification

Il est important de planifier votre utilisation des certificats numériques, à la fois lorsque vous développez et testez votre application, et pour son utilisation en production. Vous pouvez utiliser des certificats signés par une autorité de certification ou des certificats autosignés, en fonction de l'utilisation des gestionnaires de files d'attente et des applications client.

Certificats signés par une autorité de certification
Pour les systèmes de production, procurez-vous vos certificats auprès d'une autorité de certification (CA) de confiance. Lorsque vous obtenez un certificat d'une autorité de certification externe, vous payez pour le service.
certificats autosignés
Lorsque vous développez votre application, vous pouvez utiliser des certificats autosignés ou des certificats émis par une autorité de certification locale, en fonction de la plateforme:

[AIX, Linux, Windows]SurAIX®, Linux®, and Windows systèmes, vous pouvez utiliser des certificats auto-signés. Voir Création d'un certificat personnel auto-signé surAIX ,Linux et Windows pour les instructions.

[IBM i]SurIBM i systèmes, vous pouvez utiliser des certificats signés par l'autorité de certification locale. Voir Demander un certificat de serveur surIBM i pour obtenir des instructions.

[z/OS]Surz/OS® , vous pouvez utiliser des certificats auto-signés ou signés par une autorité de certification locale. Voir Création d'un certificat personnel auto-signé surz/OS ou Demander un certificat personnel lez/OS pour les instructions.

Les certificats autosignés ne conviennent pas à une utilisation en production pour les raisons suivantes :
  • Les certificats autosignés ne peuvent pas être révoqués, ce qui peut permettre à un agresseur de usurper une identité après qu'une clé privée a été compromise. Les autorités de certification peuvent révoquer un certificat compromis, pour en empêcher toute utilisation future. Les certificats signés par une autorité de certification sont donc plus sûrs à utiliser dans un environnement de production, bien que les certificats autosignés soient plus pratiques pour un système de test.
  • Les certificats autosignés n'arrivent jamais à expiration. Ce comportement est pratique et sûr dans un environnement de test, mais dans un environnement de production, les certificats restent ouverts et donc sujets à des violations de sécurité. Ce risque est aggravé du fait que les certificats autosignés ne peuvent pas être révoqués.
  • Un certificat autosigné est utilisé à la fois comme certificat personnel et comme certificat d'autorité de certification racine (ou ancrage sécurisé). Un utilisateur avec un certificat personnel autosigné doit pouvoir l'utiliser pour signer d'autres certificats personnels. En général, cela n'est pas vrai des certificats personnels émis par une autorité de certification et représente un risque important.

CipherSpecs et certificats numériques

Seul un sous-ensemble des CipherSpecs pris en charge peut être utilisé avec tous les types de certificat numérique pris en charge. Il est donc nécessaire de choisir un CipherSpec approprié pour vos certificats numériques. De même, si la stratégie de sécurité de votre organisation requiert l'utilisation d'un CipherSpec particulier, vous devez obtenir des certificats numériques appropriés.

Pour plus d'informations sur la relation entreCipherSpecs et les certificats numériques, reportez-vous à Certificats numériques etCipherSpec compatibilité dansIBMMQ

Règles de validation de certificat

La norme IETF RFC 5280 spécifie une série de règles de validation de certificat que les logiciels d'application conformes doivent implémenter afin d'éviter les attaques d'usurpation d'identité. Un ensemble de règles de validation de certificat est appelé règle de validation de certificat. Pour plus d'informations sur les politiques de validation des certificats dansIBM MQ , voir Politiques de validation des certificats dansIBMMQ .

Planification de la vérification de la révocation de certificat

L'autorisation de plusieurs certificats provenant de différentes autorités de certification peut entraîner une vérification supplémentaire inutile de la révocation des certificats.

En particulier, si vous avez configuré explicitement l'utilisation d'un serveur de révocation à partir d'une autorité de certification particulière, par exemple à l'aide d'un objet AUTHINFO ou d'une structure d'enregistrement d'informations d'authentification (MQAIR), une vérification de révocation échoue lorsqu'elle est présentée avec un certificat provenant d'une autre autorité de certification.

Vous devez éviter la configuration explicite du serveur de révocation de certificat. Au lieu de cela, vous devez activer la vérification implicite lorsque chaque certificat contient son propre emplacement de serveur de révocation dans une extension de certificat, par exemple, CRL Distribution Point, ou OCSP AuthorityInfoAccess.

Pour plus d'informations, voir OCSPCheckExtensions et CDPCheckExtensions.

Commandes et attributs pour la prise en charge de TLS

Le protocole TLS (Transport Layer Security) fournit une sécurité de canal, avec une protection contre les écoutes clandestines, la contrefaçon et l'usurpation d'identité. La prise en charge de TLS par IBM MQ vous permet de spécifier, dans la définition de canal, qu'un canal particulier utilise la sécurité TLS. Vous pouvez également spécifier les détails du type de sécurité de votre choix, par exemple l'algorithme de chiffrement que vous souhaitez utiliser.

  • Les commandes MQSC suivantes prennent en charge TLS:
    MODIFIER LES INFORMATIONS D'IDENTIFICATION
    Modifie les attributs d'un objet d'informations d'authentification.
    DÉFINIR AUTHINFO
    Crée un objet d'informations d'authentification.
    SUPPRIMER AUTHINFO
    Supprime un objet d'informations d'authentification.
    INFORMATIONS D'AUTHENTIFICATION D'AFFICHAGE
    Affiche les attributs d'un objet d'informations d'authentification spécifique.
  • Les paramètres de gestionnaire de files d'attente suivants prennent en charge TLS:
    CERTLABL
    Définit un libellé de certificat personnel à utiliser.
    Mot de passe de clé
    Sur les systèmes AIX, Linux, and Windows , définit le mot de passe utilisé par IBM MQ pour accéder au référentiel de clés. Cette zone est chiffrée à l'aide du système de protection par mot de passe.
    SSLCRLNL
    L'attribut SSLCRLNL spécifie une liste de noms d'objets d'informations d'authentification qui sont utilisés pour fournir des emplacements de révocation de certificat afin de permettre une vérification améliorée des certificats TLS.
    SSLCRYP
    Sur les systèmes AIX, Linux, and Windows , définissez l'attribut de gestionnaire de files d'attente SSLCryptoHardware . Cet attribut est le nom de la chaîne de paramètres que vous pouvez utiliser pour configurer le matériel cryptographique que vous avez sur votre système.
    SSLEV
    Détermine si un message d'événement TLS est signalé si un canal utilisant TLS ne parvient pas à établir une connexion TLS.
    SSLFIPS
    Indique si seuls les algorithmes certifiés par FIPS doivent être utilisés si la cryptographie est effectuée dans IBM MQ , plutôt que dans le matériel cryptographique. Si du matériel cryptographique est configuré, les modules cryptographiques fournis par le produit matériel sont utilisés, et ceux-ci peuvent être certifiés FIPS à un niveau particulier. Cela dépend du produit matériel utilisé.
    SSLKEYR
    Sur les systèmes AIX, Linux, and Windows , associe un référentiel de clés à un gestionnaire de files d'attente. GSKit vous permet d'utiliser la sécurité TLS sur les systèmes AIX, Linux, and Windows .
    SSLRKEYC
    Nombre d'octets à envoyer et à recevoir dans une conversation TLS avant la renégociation de la clé secrète. Le nombre d'octets inclut les informations de contrôle envoyées par l'agent MCA.
  • Les paramètres de canal suivants prennent en charge TLS:
    CERTLABL
    Définit un libellé de certificat personnel à utiliser.
    SSLCAUTH
    Indique si IBM MQ requiert et valide un certificat du client TLS.
    SSLCIPH
    Indique la force et la fonction de chiffrement (CipherSpec), par exemple TLS_RSA_WITH_AES_128_CBC_SHA. Des CipherSpecs compatibles doivent être définis pour les deux extrémités du canal.
    SSLPEER
    Indique le nom distinctif (identificateur unique) des partenaires autorisés.
Cette section décrit les commandes setmqaut, dspmqaut, dmpmqaut, rcrmqobj, rcdmqimget dspmqfls permettant de prendre en charge l'objet d'informations d'authentification. Il décrit également les commandes qui peuvent être utilisées pour gérer les clés et les certificats sur AIX, Linux, and Windows. Reportez-vous aux sections suivantes :
Pour une présentation de la sécurité des canaux à l'aide de TLS, voir
Pour plus de détails sur les commandes MQSC associées à TLS, voir
Pour plus de détails sur les commandes PCF associées à TLS, voir