Informations à connaître concernant la sécurité avant d'installer ou de mettre à niveau le serveur

Consultez les informations relatives aux fonctions de sécurité améliorées du serveur IBM Storage Protect et aux conditions requises pour la mise à jour de votre environnement.

Avant de commencer

À partir de la version 8.1.2, des améliorations ont été ajoutées à IBM Storage Protect qui imposent des paramètres de sécurité plus stricts. Avant d'installer ou de mettre à niveau IBM Storage Protect, procédez comme suit :
  • Sur le site IBM Documentation, dans la rubrique Quoi de neuf, consultez les informations des sections Sécurité pour en savoir plus sur les mises à jour de sécurité pour chaque version.
  • Si vous disposez de versions précédentes du serveur dans votre environnement, consultez les restrictions et les problèmes connus dans Note technique 562939. Pour éviter ces restrictions et profiter des dernières améliorations de sécurité, prévoyez de mettre à jour tous les serveurs IBM Storage Protect et les clients de sauvegarde-archivage de votre environnement vers la dernière version.
  • Vérifiez que vous avez sauvegardé les répertoires et fichiers suivants, qui sont requis pour restaurer le serveur :
    • Fichier d'options du serveur (dsmserv.opt)
    • Fichier de configuration d'unité (par exemple, devconf.dat)
    • Fichier historique des volumes (par exemple, volhist.dat)
    • Fichiers de clés de chiffrement principales (dsmkeydb.kdb ou dsmkeydb.sth)
    • Fichiers de certificats serveur et de clés privées (cert.kbd ou cert.sth)

Améliorations de la sécurité

Les améliorations de sécurité suivantes ont été ajoutées à compter de la version 8.1.2 :
Protocole de sécurité basé sur le protocole TLS

IBM Storage Protect V8.1.2 et les logiciels suivants ont un protocole de sécurité amélioré qui utilise TLS Version 1.2 ou ultérieure pour l'authentification entre le serveur, l'agent de stockage et les clients de sauvegarde-archivage.

À partir de IBM Storage Protect version 8.1.11, vous pouvez activer le protocole TLS 1.3 pour sécuriser les communications entre les serveurs, les clients et les agents de stockage. Pour que le protocole TLS 1.3 puisse être utilisé, les deux parties dans la session de communication doivent utiliser le protocole TLS 1.3. Si l'une des parties utilise le protocole TLS 1.2, les deux parties utilisent le protocole TLS 1.2 par défaut.

Configuration SSL et distribution des certificats
Les serveurs, agents de stockage et clients qui utilisent le logiciel version 8.1.2 ou ultérieure sont automatiquement configurés pour s'authentifier les uns avec les autres via le protocole TLS.

Grâce au nouveau protocole, chaque serveur, agent de stockage et client possède un certificat autosigné unique pour s'authentifier et permettre les connexions TLS. Les certificats autosignés IBM Storage Protect permettent l'authentification sécurisée entre les entités, le chiffrement renforcé pour la transmission des données et la distribution automatique des clés publiques aux noeuds client. Les certificats sont automatiquement échangés entre tous les clients, agents de stockage et serveurs utilisant la version 8.1.2 ou ultérieure. Vous n'avez pas besoin de configurer TLS manuellement ni d'installer manuellement les certificats pour chaque client. Les nouvelles améliorations TLS ne requièrent pas de modification d'options et les certificats sont transférés aux clients automatiquement lors de la première connexion sauf si vous utilisez un ID administrateur unique pour accéder aux différents systèmes.

Par défaut, les certificats autosignés sont distribués, mais vous pouvez éventuellement utiliser d'autres configurations, telles que celles des certificats signés par une autorité de certification. Pour plus d'informations sur l'utilisation des certificats, voir Secure Sockets Layer and Transport Layer Security communication.

Combinaison des protocoles TCP/IP et TLS pour garantir la sécurité des communications tout en minimisant l'impact sur les performances
Dans les versions précédentes du logiciel IBM Storage Protect, vous deviez choisir TLS ou TCP/IP pour chiffrer toutes les communications. Le nouveau protocole de sécurité offre la possibilité d'utiliser un mix des deux pour sécuriser les communications entre les serveurs, clients et agents de stockage. Par défaut, le protocole TLS est utilisé uniquement pour chiffrer l'authentification et les métadonnées, tandis que TCP/IP est utilisé pour transmettre les données. Sachant que le chiffrement TLS est principalement utilisé pour l'authentification seulement, les performances des opérations de sauvegarde et de restauration sont intactes.

Si vous le souhaitez, vous pouvez utiliser le protocole TLS pour chiffrer la transmission des données en utilisant l'option client SSL pour les communications de client à serveur, et le paramètre SSL dans la commande UPDATE SERVER pour les communications de serveur à serveur.

Simplicité des mises à niveau par lots grâce à la compatibilité avec les versions antérieures
Les versions mises à niveau des serveurs et des clients IBM Storage Protect peuvent continuer à se connecter à des versions plus anciennes lorsque le paramètre SESSIONSECURITY est défini sur TRANSITIONNEL.

Vous n'êtes pas obligé de mettre à jour les clients de sauvegarde-archivage vers la version 8.1.2 ou ultérieure avant de mettre à niveau les serveurs. Une fois que vous avez mis à niveau un serveur au niveau de la version 8.1.2 ou ultérieure, les noeuds et les administrateurs qui utilisent des versions précédentes du logiciel continueront à communiquer avec le serveur en utilisant la valeur TRANSITIONAL jusqu'à ce que l'entité réponde aux exigences associées à la valeur STRICT. De même, vous pouvez mettre à niveau les clients de sauvegarde-archivage vers la version 8.1.2 ou ultérieure avant de mettre à niveau vos serveurs IBM Storage Protect, mais vous n'êtes pas obligé de mettre à niveau les serveurs en premier. La communication entre les serveurs et les clients utilisant des versions différentes n'est pas interrompue. Toutefois, vous ne profiterez pas des avantages offerts par l'amélioration de la sécurité tant que les clients et les serveurs n'ont pas été mis à niveau.

Application d'une sécurité stricte à l'aide du paramètre SESSIONSECURITY
Pour utiliser le nouveau protocole de sécurité, le serveur, le noeud client ou les entités administrateur doivent utiliser le logiciel IBM Storage Protect qui prend en charge le paramètre SESSIONSECURITY . La sécurité de session est le niveau de sécurité utilisé pour la communication entre les noeuds client IBM Storage Protect, les clients d'administration et les serveurs. Vous pouvez spécifier les valeurs suivantes pour ce paramètre :
STRICT
Enforce le niveau de sécurité le plus élevé, actuellement TLS 1.2, pour la communication entre les serveurs, les noeuds et les administrateurs IBM Storage Protect.
TRANSITIONAL
Indique que le protocole de communication existant (par exemple, TCP/IP) est utilisé jusqu'à la mise à jour de votre logiciel IBM Storage Protect vers la version 8.1.2 ou ultérieure. Il s'agit de la valeur par défaut. Lorsque SESSIONSECURITY=TRANSITIONAL est défini, des paramètres de sécurité plus stricts sont automatiquement appliqués lorsque des versions ultérieures du protocole TLS sont utilisées et que le logiciel est mis à niveau vers la version 8.1.2 ou une version ultérieure. Dès lors qu'un noeud, un administrateur ou un serveur répond aux exigences correspondant à la valeur STRICT, la sécurité de niveau session est automatiquement mise à jour vers la valeur STRICT, et l'entité ne peut plus s'authentifier à l'aide d'une version antérieure du client ou de protocoles TLS plus anciens.
Si SESSIONSECURITY=TRANSITIONAL et que le serveur, le noeud ou l'administrateur n'a jamais rempli les conditions requises pour la valeur STRICT, le serveur, le noeud ou l'administrateur continuera à s'authentifier à l'aide de la valeur TRANSITIONAL. Toutefois, dès que le serveur, le noeud ou l'administrateur répond aux exigences de la valeur STRICT, la valeur du paramètre SESSIONSECURITY est automatiquement mise à jour de TRANSITIONAL vers STRICT. Ensuite, le serveur, le noeud ou l'administrateur ne peut plus s'authentifier à l'aide d'une version du client ou d'un protocole SSL/TLS qui ne répond plus aux exigences pour STRICT.
Restriction: une fois qu'un administrateur a réussi à s'authentifier auprès d'un serveur à l'aide d'un logiciel IBM Storage Protect V8.1.2 ou ultérieure ou d'un logiciel Tivoli Storage Manager V7.1.8 ou ultérieure, il ne peut plus s'authentifier auprès du même serveur à l'aide de versions de client ou de serveur antérieures à V8.1.2 ou V7.1.8. Cette restriction s'applique également au serveur de destination lorsque vous utilisez des fonctions telles que le routage de commande, l'exportation de serveur à serveur qui s'authentifie auprès du serveur IBM Storage Protect de destination en tant qu'administrateur à partir d'un autre serveur, les connexions d'administrateur à l'aide du centre d'opérations et les connexions à partir du client de ligne de commande d'administration.
Pour les sessions de client et d'administration, les sessions de routage de commande d'administration peuvent échouer sauf si l'ID administrateur a déjà acquis des certificats pour tous les serveurs auxquels l'ID administrateur se connecte. Les administrateurs qui s'authentifient à l'aide de la commande dsmadmc, de la commande dsmc ou du programme dsm ne peuvent pas s'authentifier à l'aide d'une version antérieure après s'être authentifiés à l'aide de la version 8.1.2 ou d'une version ultérieure. Pour résoudre les problèmes d'authentification rencontrés par les administrateurs, voir les conseils suivants :
  • Vérifiez que tous les logiciels IBM Storage Protect utilisés par le compte administrateur pour se connecter sont mis à niveau vers la version 8.1.2 ou ultérieure. Si un compte administrateur se connecte depuis plusieurs systèmes, assurez-vous que le certificat du serveur est installé sur chacun de ces systèmes.
  • Si nécessaire, créez un compte administrateur distinct à utiliser uniquement avec les clients et les serveurs qui utilisent la version 8.1.1 ou une version antérieure du logiciel.

Avant une mise à niveau

Avant la mise à niveau d'un serveur, lisez les instructions de la liste suivante.
Tableau 1. Liste de contrôle de planification
Instruction Description
Sauvegardez les fichiers de serveur suivants :
  • Bases de données de clés (cert.kdb et dsmkeydb.kdb)
  • Fichiers de dissimulation (cert.sth et dsmkeydb.sth)

À partir de IBM Storage Protect version 8.1.2, une clé de chiffrement maître est générée automatiquement lorsque vous démarrez le serveur si la clé de chiffrement maître n'existait pas précédemment.

La clé de chiffrement principale est stockée dans une base de données de clés, dsmkeydb.kdb. Les certificats serveur sont toujours stockés dans la base de données de clés cert.kdb et accessibles par le fichier de dissimulation cert.sth. Vous devez protéger à la fois les bases de données de clés (cert.kdb et dsmkeydb.kdb) et les fichiers de dissimulation (cert.sth et dsmkeydb.sth) qui fournissent un accès à chacune des bases de données de clés. Par défaut, la commande BACKUP DB protège la clé de chiffrement principale de la même manière que pour l'historique des volumes et les fichiers devconfig. Pensez à mémoriser le mot de passe de sauvegarde de base de données pour pouvoir restaurer la base de données. Le fichier dsmserv.pwd du serveur IBM Storage Protect , qui a été utilisé pour stocker la clé de chiffrement principale dans les éditions précédentes, n'est plus utilisé.

Planifiez soigneusement les mises à niveau pour les ID administrateur Identifiez tous les systèmes utilisés par les comptes administrateur pour se connecter à des fins d'administration.
Après une authentification réussie à la version 8.1.2 ou ultérieure, les administrateurs ne peuvent pas s'authentifier sur les versions antérieures du logiciel IBM Storage Protect sur le même serveur. Si un ID administrateur unique est utilisé pour la connexion à plusieurs systèmes, prévoyez de mettre à niveau tous les systèmes vers la version 8.1.2 ou ultérieure pour vous assurer que le certificat est installé sur tous les systèmes auxquels l'administrateur se connecte.
Astuce: Vous ne serez pas verrouillé sur un serveur si le paramètre SESSIONSECURITY de tous vos ID administrateur est mis à jour avec la valeur STRICT. Vous pouvez importer manuellement le certificat public du serveur sur un client à partir duquel vous émettez la commande dsmadmc.
Si vous utilisez le protocole TLS avec des versions précédentes du client utilisant le certificat TSM Server SelfSigned Key (cert.arm), mettez à jour vos clients vers la version 8.1.4 ou ultérieure. Dans les éditions antérieures à la version 7.1.8, le certificat par défaut s'appelait TSM Server SelfSigned Key et possédait une signature MD5, qui ne prend pas en charge le protocole TLS 1.2 ou ultérieure requis par défaut pour les clients V8.1.2 ou ultérieurs et le centre d'opérations. Pour résoudre ce problème, effectuez l'une des étapes suivantes :
  • Mettez à niveau le serveur vers la version 8.1.4 ou une version ultérieure. À 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 s'appelait TSM Server SelfSigned SHA Key. Une copie du nouveau certificat par défaut est stockée dans le fichier cert256.arm, qui se trouve dans le répertoire d'instance du serveur.
    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.
  • Pour mettre à jour manuellement votre certificat par défaut, suivez les instructions fournies dans Note technique 562939.

Etape suivante