Problèmes connus relatifs aux instances de AWS CloudHSM hsm2m.medium

Conséquence : la connexion à hsm2m.medium suit une interprétation trop stricte des exigences de conformité, ce qui se traduit par une latence accrue.

Solution : Si vous avez créé une nouvelle instance hsm2m.medium ou si vous avez migré vers hsm2m.medium depuis hsm1.medium avant le 20 décembre 2025, vous devrez réinitialiser votre mot de passe afin de bénéficier des améliorations de performances que nous avons mises en œuvre pour les opérations de connexion. Reportez-vous au changement de mot de passe pour obtenir des instructions.

Conséquence : l'instance HSM hsm2m.medium a amélioré l'architecture de partage équitable, ce qui se traduit par des performances prévisibles plus cohérentes par rapport à hsm1.medium. Avec hsm1.medium, les clients peuvent constater une amélioration des performances Find Key en raison d'une utilisation irrégulière des ressources HSM. Cependant, les performances de hsm1.medium find key diminuent lorsque l'instance HSM est corrigée ou mise à jour avec un nouveau microprogramme. Ce problème affecte des opérations telles que KeyStore.getKey() dans JCE.

Résolution : ce problème a été résolu. La meilleure pratique consiste à mettre en cache les résultats des opérations clés de recherche. La mise en cache réduira le nombre total d'opérations de recherche de clés, car il s'agit d'une opération gourmande en ressources dans HSM. En outre, implémentez de nouvelles tentatives côté client avec un ralentissement et une instabilité exponentiels afin de réduire les échecs liés à la régulation du HSM.

Conséquence : tout utilisateur CO tentant de définir l'attribut fiable d'une clé recevra un message d'erreur le signalantUser type should be CO or CU.

Résolution : les versions futures du SDK client résoudront ce problème. Les mises à jour seront annoncées dans notre guide de l'utilisateurHistorique du document.

Conséquence : l'opération de vérification ECDSA effectuée HSMs en mode FIPS échouera.

État de la résolution : ce problème a été résolu dans la version 5.13.0 du SDK client. Vous devez effectuer une mise à niveau vers cette version du client ou une version ultérieure pour bénéficier du correctif.

Conséquence : les certificats au format DER ne peuvent pas être enregistrés en tant qu'ancres de confiance mTLS avec la CLI CloudHSM.

Solution : vous pouvez convertir un certificat au format DER au format PEM à l'aide de la commande openssl : openssl x509 -inform DER -outform PEM -in certificate.der -out certificate.pem

Conséquence : toutes les opérations effectuées par l'application seront interrompues et l'utilisateur sera invité à saisir le mot de passe lors de la saisie standard à plusieurs reprises pendant toute la durée de vie de l'application. Les opérations expireront et échoueront si le mot de passe n'est pas fourni avant la durée du délai d'expiration de l'opération.

Solution : les clés privées cryptées par phrase secrète ne sont pas prises en charge pour les fichiers MTL. Supprimer le chiffrement par phrase secrète de la clé privée du client

Conséquence : la réplication utilisateur échoue sur les instances hsm2m.medium lors de l'utilisation de la CLI CloudHSM. La user replicate commande fonctionne comme prévu sur les instances de hsm1.medium.

Résolution : ce problème a été résolu.

Conséquence : des opérations telles que la génération de nombres aléatoires peuvent échouer sur les instances hsm2m.medium pendant qu'AWS CloudHSM crée une sauvegarde.

Solution : Pour minimiser les interruptions de service, mettez en œuvre les meilleures pratiques suivantes :

Pour plus d'informations sur les bonnes pratiques, consultez Les meilleures pratiques pour AWS CloudHSM.

Conséquence : le SDK client 5.8 et les versions ultérieures ne réessaieront pas certaines opérations limitées par HSM

Solution : suivez les meilleures pratiques pour concevoir votre cluster de manière à gérer la charge et à mettre en œuvre de nouvelles tentatives au niveau de l'application. Nous travaillons actuellement sur un correctif. Les mises à jour seront annoncées dans notre guide de l'utilisateurHistorique du document.

État de la résolution : ce problème a été résolu dans le SDK AWS CloudHSM client 5.16.2. Vous devez effectuer une mise à niveau vers cette version du client ou une version ultérieure pour bénéficier du correctif.

Conséquence : lorsque vous utilisez le AES/CBC mécanisme de déballage des clés à l'aide du fournisseur AWS CloudHSM JCE, les opérations utilisant un IV de 16 octets rempli de zéros échouent sur les instances hsm2m.medium, en raison d'un contrôle de validation supplémentaire qui n'existait pas dans les instances hsm1.medium.

État de la résolution : Nous travaillons sur un correctif qui permettra d'accepter le zéro octet lors IVs des opérations de AES/CBC déballage.

Conséquence : ce problème concerne les démarrages à froid tels que les déploiements ou les redémarrages d'applications clientes. L'instance HSM hsm2m.medium possède une architecture de partage équitable améliorée qui garantit des performances, un débit et une latence plus constants pour tous les clients. À l'heure actuelle, sur hsm1.medium, vous pouvez observer des performances supérieures aux prévisions pour l'initialisation simultanée de connexions HSM. Cependant, les performances d'initialisation de la connexion hsm1.medium varient en fonction des mises à jour du système sous-jacent.

Solution : suivez les meilleures pratiques et échelonnez les déploiements et redémarrages des applications clientes afin de limiter le nombre d'applications clientes initialisant des connexions HSM simultanément. Nous vous recommandons également d'implémenter de nouvelles tentatives au niveau de l'application pour l'initialisation de l'application cliente. En outre, démarrez à l'aide de l'outil de configuration --cluster-id <cluster ID> pour ajouter toutes les adresses IP HSM au fichier de configuration du client.