Communications par SSL et TLS

Editer en ligne

Le protocole SSL (Secure Sockets Layer) ou TLS (Transport Layer Security) est utilisé pour assurer la sécurité de la couche de transport pour une connexion sécurisée entre les serveurs IBM Storage Protect, les clients, les agents de stockage et Operations Center. Si vous envoyez des données entre le serveur, le client et l'agent de stockage, SSL est utilisé pour chiffrer la session.

Cette illustration présente schématiquement les communications au sein d' SSL entre le serveur Protect d' IBM Storage, le centre d'opérations, le client de sauvegarde et d'archivage, l'agent de stockage, le serveur central et les serveurs périphériques.
Restriction : n'utilisez pas le protocole SSL pour communiquer avec une instance IBM Db2 de base de données utilisée par le IBM Storage Protect serveur.
Chaque serveur ou agent de stockage possède une clé privée unique et un certificat signé unique utilisés pour autoriser les connexions SSL. Le certificat autosigné pour chaque serveur ou agent de stockage est distribué automatiquement sur tous les clients, agents de stockage et serveurs qui utilisent SSL pour communiquer. Les certificats sont vérifiés par le serveur ou client SSL qui demande ou initie la communication SSL.
Remarque: L'échange automatique de certificats se produit uniquement lors de la première connexion à un serveur. Si le paramètre SESSIONSECURITY d'un noeud ou d'un administrateur n'a pas été mis à jour sur la valeur STRICT, le serveur distribue automatiquement le certificat autosigné et le certificat signé par une autorité de certification au noeud client lors de la première connexion. Après la première connexion effectuée par un noeud ou un administrateur qui utilise une version 8.1.2 ou ultérieure ou une version 7.1.8 ou ultérieure client et serveur, les certificats doivent être distribués manuellement.
Au lieu d'utiliser des certificats autosignés, vous pouvez utiliser des certificats signés par une autorité de certification. Si vous utilisez des certificats signés par une autorité de certification, chaque serveur et agent de stockage IBM Storage Protect doit envoyer un certificat de serveur unique à une autorité de certification à signer. L'autorité de certification retourne un certificat serveur signé, qui doit être ajouté à la base de données de clés du serveur, en même temps que le certificat d'autorité de certification racine et tous les certificats d'autorité de certification intermédiaires. Il n'est pas nécessaire de distribuer le certificat signé par une autorité de certification à des clients, mais vous devez installer le certificat racine et le certificat intermédiaire de l'autorité de certification dans la base de données de clés de tous les clients, agents de stockage et serveurs utilisant SSL pour communiquer avec le serveur ou l'agent de stockage. Les certificats racine et intermédiaires de l'autorité de certification sont utilisés pour vérifier le certificat serveur signé par l'autorité de certification. Si le certificat racine de l'autorité de certification et le certificat intermédiaire ne sont pas installés sur un client, les tentatives d'authentification échouent avec l'erreur suivante :
ANS1694E The certificate identity could not be verified

Chaque certificat signé doit connaître le nom DNS et l'adresse IP du serveur, faute de quoi les tentatives d'authentification sont rejetées. Si les valeurs saisies sont incorrectes, la même erreur ANS1694E est générée.

Tableau 1. Certificats autosignés et certificats signés par une autorité de certification
Capacité

Certificats IBM Storage Protect autosignés

Certificats signés par une autorité de certification
Active l'authentification sécurisée entre les points d'extrémité Oui Oui
Active le chiffrement renforcé pour la transmission de données Oui Oui
Distribution automatique des clés publiques aux clients Oui Oui1
Traitement automatique des certificats expirés    
Certificat commun utilisé sur les clients pour plusieurs serveurs   Oui
Emplacement central pour la gestion et la révocation des certificats   Oui
  1. Le certificat du serveur n'est pas stocké sur les clients. Les certificats racine et intermédiaires d'autorité de certification doivent être installés sur les systèmes client.
  
Remarques :
  • Le serveur IBM Storage Protect accepte les certificats signés par l'autorité de certification qui utilisent la méthode de chiffrement SHA-256 ou la méthode de chiffrement Secure Hash Algorithm précédente. Les certificats SHA-256 sont conçus pour améliorer la sécurité et respecter les normes NIST (National Institute of Standards and Technology). Pour cette raison, la méthode préférée consiste à utiliser des certificats SHA-256 pour les communications entre le serveur et Operations Center.
  • Si un serveur possède un certificat MD5-signed libellé Tivoli® Storage Manager Server SelfSigned Key défini comme certificat par défaut lors de la mise à niveau vers la version 8.1.4 ou ultérieure, le certificat par défaut est automatiquement mis à jour pour utiliser un certificat avec une signature SHA. Dans les versions antérieures à la version 7.1.8, le certificat par défaut était libellé TSM Server SelfSigned Key et avait une signature MD5, ce qui ne prend pas en charge le protocole TLS 1.2 requis par défaut pour les clients version 8.1.2 ou ultérieure et le centre d'opérations. A partir de la version 8.1.4, les serveurs qui utilisent le certificat signé MD5 comme certificat par défaut sont automatiquement mis à jour pour utiliser un certificat par défaut avec une signature SHA portant le libellé TSM Server SelfSigned SHA Key. Une copie du certificat est stockée dans le fichier cert256.arm, qui se trouve dans le répertoire d'instance du serveur. Si certains de vos clients utilisent des versions antérieures à 7.1.8 ou 8.1.2 et qu'ils utilisaient un certificat MD5-signed, vous devez les configurer manuellement pour qu'ils utilisent le certificat contenu dans le cert256.arm fichier.
    Astuce: avant de mettre à jour le serveur pour utiliser le nouveau certificat par défaut avec une signature SHA, distribuez le fichier cert256.arm aux clients afin d'éviter les échecs de sauvegarde client. Chaque client doit obtenir et importer le nouveau certificat avant de pouvoir se connecter à un serveur qui utilise le nouveau certificat SHA par défaut. Vous n'avez pas besoin de retirer les certificats précédents.

Un serveur, un client ou un agent de stockage IBM Storage Protect peut servir de client SSL lors de la communication. Le client SSL est le composant qui initie la communication et vérifie le certificat du serveur SSL. Par exemple, si le client IBM Storage Protect lance la communication SSL avec le serveur IBM Storage Protect, le client IBM Storage Protect est le client SSL et le serveur est le serveur SSL.

Le tableau 2 répertorie les composants pouvant servir de client SSL ou de serveur SSL.
Tableau 2. SSL les clients et les serveurs dans IBM Storage Protect l'environnement
Client SSL Serveur SSL Scénario
Client Serveur Le client IBM Storage Protect lance une demande de communication avec le serveur IBM Storage Protect. Le client vérifie le certificat. Le serveur fournit le certificat.
Serveur (par exemple un serveur source) Serveur (par exemple un serveur cible) Le serveur source IBM Storage Protect lance une demande de communication avec le serveur cible IBM Storage Protect. Le serveur source agit en tant que client SSL et vérifie le certificat fourni par le serveur cible.

Ce type de communication est courant lors des processus de réplication.
Client par l'intermédiaire d'un agent de stockage Serveur Le client vérifie chaque certificat lorsqu'il lance la communication SSL séparément avec le serveur IBM Storage Protect et l'agent de stockage.

Lorsque l'agent de stockage communique avec le serveur à l'aide du protocole de communication SSL, l'agent de stockage agit en tant que client SSL et vérifie le certificat fourni par le serveur.

L'agent de stockage peut être à la fois client et serveur SSL.

Le client doit utiliser le même protocole de communication (SSL ou TCP/IP) pour communiquer avec le serveur et l'agent de stockage.
Serveur Serveur LDAP Le serveur IBM Storage Protect lance une demande de communication avec le serveur LDAP. Le serveur IBM Storage Protect agit en tant que client SSL et vérifie le certificat fourni par le serveur LDAP.
Centre d'opérations Serveur Le centre d'opérations lance une demande de communication avec le serveur IBM Storage Protect. Le Centre d'opérations agit en tant que client SSL et vérifie le certificat fourni par le serveur IBM Storage Protect.
Reporting Serveur L'agent de génération de rapports lance une demande de communication avec le serveur IBM Storage Protect. La fonction de génération de rapports agit en tant que client SSL et vérifie le certificat fourni par le serveur IBM Storage Protect.