Gestion cryptographique
La gestion cryptographique se compose des modes et protocoles de communication qui contrôlent la façon dont la communication sécurisée est gérée entre Lenovo XClarity Administrator et les appareils gérés (tels que des châssis, des serveurs et des commutateurs Flex).
Algorithmes de cryptographie
XClarity Administrator prend en charge le protocole TLS 1.2 et des algorithmes cryptographiques plus puissants pour les connexions réseau sécurisées.
SSH-ED25519
SSH-ED25519-CERT-V01@OPENSSH.COM
ECDSA-SHA2-NISTP256
ECDSA-SHA2-NISTP256-CERT-V01@OPENSSH.COM
ECDSA-SHA2-NISTP384
ECDSA-SHA2-NISTP384-CERT-V01@OPENSSH.COM
ECDSA-SHA2-NISTP521
ECDSA-SHA2-NISTP521-CERT-V01@OPENSSH.COM
RSA-SHA2-512
RSA-SHA2-256
RSA-SHA2-384
Modes cryptographiques pour le serveur de gestion
- Compatibilité. Ce mode est le mode par défaut. Il est compatible avec les anciennes versions de microprogramme, les navigateurs et les autres clients réseau qui n'implémentent pas les normes de sécurité strictes requises pour une compatibilité avec NIST SP 800-131A.
NIST SP 800-131A. Ce mode est conçu pour être conforme à la norme NIST SP 800-131A. XClarity Administrator est conçu pour toujours utiliser une cryptographie renforcée en interne et, le cas échéant, pour utiliser des connexions réseau à cryptographie forte. Toutefois, dans ce mode, les connexions réseau à l'aide d'une cryptographie qui n'est pas approuvée par NIST SP 800-131A ne sont pas autorisées, ce qui inclus le rejet des certificats de la sécurité de la couche de transport (TLS) signés avec SHA-1 ou un hachage plus faible.
Si vous sélectionnez ce mode :Pour tous les ports autres que le port 8443, tous les chiffrements TLS CBC et ceux qui ne prennent pas en charge Perfect Forward Secrecy sont désactivés.
Les notifications d'événements peuvent ne pas être correctement envoyées à certaines souscriptions d'appareil mobile (voir Acheminement des événements vers des appareils mobiles). Certains services externes, tels qu'Android et iOS, présentent des certificats signés avec SHA-1, qui est un algorithme non conforme aux exigences plus strictes du mode NIST SP 800-131A. Par conséquent, toutes les connexions à ces services peuvent échouer avec une exception de certificat ou un échec d'établissement d'une liaison.
Pour plus d'informations sur le paramétrage des modes de sécurité sur le serveur de gestion, voir Configuration des paramètres cryptographiques sur le serveur de gestion.
Modes de sécurité pour les serveurs gérés
Mode de sécurité compatibilité. Sélectionnez ce mode lorsque les services et les clients nécessitent une cryptographie non compatible CNSA/FIPS. Ce mode prend en charge un grand nombre d’algorithmes de cryptographie et permet d’activer tous les services.
NIST SP 800-131A. Sélectionnez ce mode pour garantir la conformité avec la norme NIST SP 800-131A. Cela comprend la restriction des clés RSA à 2 048 octets ou plus, la restriction des hachages utilisés pour les signatures numériques à SHA-256 ou plus et l'assurance que seul les algorithme de chiffrement symétrique conformes à la norme NIST sont utilisés. Ce mode requiert de définir le mode SSL/TLS sur Serveur et client TLS 1.2.
Ce mode n'est pas pris en charge pour les serveurs XCC2.
Sécurité standard. (Serveurs avec XCC2 uniquement) Il s’agit du mode de sécurité par défaut pour les serveurs avec XCC2. Sélectionnez ce mode pour garantir la conformité avec la norme FIPS 140-3. Pour que XCC fonctionne en mode validé FIPS 140-3, seuls les services qui prennent en charge la cryptographie de niveau FIPS 140-3 peuvent être activés. Les services qui ne prennent pas en charge la cryptographie de niveau FIPS 140-2/140-3 sont désactivés par défaut mais peuvent être activés si nécessaire. Si un service utilisant une cryptographie de niveau autre que FIPS 140-3 est activé, le XCC ne peut pas fonctionner en mode validé FIPS 140-3. Ce mode requiert des certificats de niveau FIP.
Sécurité Entreprise Strict. (serveurs avec XCC2 uniquement) Il s’agit du mode le plus sécurisé. Sélectionnez ce mode pour garantir la conformité avec la norme CNSA. Seuls les services qui prennent en charge la cryptographie de niveau CNSA sont autorisés. Les services non sécurisés sont désactivés par défaut et ne peuvent pas être activés. Ce mode requiert des certificats de niveau CNSA.
XClarity Administrator utilise des signatures de certificat RSA-3072/SHA-384 pour les serveurs en mode Sécurité Entreprise Strict.
ImportantLa clé XCC2 Feature On Demand doit être installée sur chaque serveurs avec XCC2 sélectionné pour utiliser ce mode.
Dans ce mode, si XClarity Administrator utilise un certificat autosigné, XClarity Administrator doit utiliser le certificat racine et le certificat de serveur basés sur la norme RSA3072/SHA384. Si XClarity Administrator utilise un certificat à signature externe, XClarity Administrator doit générer une demande CSR basée sur RSA3072/SHA384 et contacter l’autorité de certification externe pour signer un nouveau certificat de serveur basé sur RSA3072/SHA384.
Lorsque XClarity Administrator utilise un certificat basé sur RSA3072/SHA384, XClarity Administrator est susceptible de déconnecter des appareils autres que les serveurs et le châssis Flex System (CMMS), les serveurs ThinkSystem, les serveurs ThinkServer, les serveurs System x M4 et M5, les commutateurs Lenovo ThinkSystem série DB, les commutateurs Lenovo RackSwitch, les commutateurs Flex System, les commutateurs Mellanox, les dispositifs de stockage ThinkSystem DE/DM, le stockage de la bandothèque IBM et les serveurs ThinkSystem SR635/SR655 sur lesquels est copié un microprogramme antérieur à 22C. Pour continuer à gérer les appareils déconnectés, configurez une nouvelle instance de XClarity Administrator avec un certificat basé sur RSA2048/SHA384.
La permutation du mode Mode de sécurité compatibilité ou du mode Sécurité standard ou au mode Sécurité Entreprise Strict n'est pas pris en charge.
Si vous effectuez une mise à niveau du mode Mode de sécurité compatibilité au mode Sécurité standard, vous recevez un avertissement si les certificats ou les clés publiques SSH importés ne sont pas conformes, mais vous pouvez tout de même passer au mode Sécurité standard.
Si vous rétrogradez du mode Sécurité Entreprise Strict au mode Mode de sécurité compatibilité ou au mode Sécurité standard :
Le serveur est automatiquement redémarré pour que le mode de sécurité prenne effet.
Si la clé FoD du mode strict est manquante ou expirée sur XCC2, et si XCC2 utilise un certificat TLS autosigné, XCC2 regénère le certificat TLS autosigné à partir de l’algorithme de conformité Strict standard. XClarity Administrator affiche un échec de connexion en raison d’une erreur de certificat. Pour résoudre l’erreur de certificat non sécurisé, voir Résolution d'un certificat du serveur non sécurisé. Si XCC2 utilise un certificat TLS personnalisé, XCC2 autorise la rétrogradation et vous avertir que vous devez importer un certificat de serveur basé sur la cryptographie du mode Sécurité standard.
- Le mode NIST SP 800-131A n'est pas pris en charge pour les serveurs équipés de XCC2.
- Vous ne pouvez pas faire appel à l’authentification gérée afin de gérer un serveur ThinkSystem ou ThinkAgile lorsque le mode de sécurité de XCC est défini sur TLS v1.3.
- Pour un serveur ThinkSystem ou ThinkAgile qui est géré par le biais de l’authentification gérée, définir le mode de sécurité de XCC sur TLS v1.3 à l’aide de soit XClarity Administrator ou XCC entraîne la mise hors ligne du serveur.
- Serveurs Lenovo ThinkSystem avec processeurs Intel ou AMD (à l’exception de SR635 / SR655)
- Serveurs Lenovo ThinkSystem V2
- Serveurs Lenovo ThinkSystem V3 avec processeurs Intel ou AMD
- Serveurs Lenovo ThinkEdge SE350 / SE450
- Serveurs Lenovo System x
Pour plus d'informations sur le paramétrage des modes de sécurité sur le serveur géré, voir Configuration des paramètres de sécurité pour un serveur géré.