Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Notifications d’obsolescence
<a name="compliance-dep-notif"></a>

De temps à autre, cette fonctionnalité AWS CloudHSM peut être désapprouvée afin de rester conforme aux exigences des normes FIPS 140, PCI-DSS, PCI-PIN, PCI-3DS, ou pour des raisons matérielles. SOC2 end-of-support Cette page répertorie les modifications actuellement applicables.

## HSM1 Obsolète
<a name="hsm-dep-1"></a>

 Le support du type d'instance AWS CloudHSM hsm1.medium atteindra la fin du support le 31 mars 2026. Pour garantir un service continu, nous introduisons les modifications suivantes : 
+  À partir d'avril 2025, vous ne pourrez plus créer de nouveaux clusters hsm1.medium. 
+  À partir de janvier 2026, nous commencerons à migrer automatiquement les clusters hsm1.medium existants vers le nouveau type d'instance hsm2m.medium. 

 Le type d'instance hsm2m.medium est compatible avec votre type d' AWS CloudHSM instance actuel et offre de meilleures performances. Pour éviter toute interruption de vos applications, vous devez effectuer une mise à niveau vers la dernière version du SDK client. Pour les instructions de mise à niveau, consultez[Migration du SDK AWS CloudHSM client 3 vers le SDK client 5](client-sdk-migration.md). 

 Deux options s'offrent à vous pour la migration : 

1.  Optez pour une migration gérée par CloudHSM lorsque vous êtes prêt. Pour plus d’informations, consultez [Migration de hsm1.medium vers hsm2m.medium](hsm1-to-hsm2-migration.md). 

1.  Créez un nouveau cluster hsm2m.medium à partir d'une sauvegarde de votre cluster hsm1 et redirigez votre application vers le nouveau cluster. Nous recommandons d'utiliser une stratégie de blue/green déploiement pour cette approche. Pour de plus amples informations, veuillez consulter [Création de AWS CloudHSM clusters à partir de sauvegardes](create-cluster-from-backup.md). 

## Conformité à la norme FIPS 140 : mécanisme 2024 rendu obsolète
<a name="compliance-dep-notif-1"></a>

Le National Institute of Standards and Technology (NIST) [1](#dep-notif-1)recommande que la prise en charge du chiffrement Triple DES (DESede, 3DES DES3) et de l'encapsulation et du déballage des clés RSA avec le rembourrage PKCS \#1 v1.5 ne soit plus autorisée après le 31 décembre 2023. Par conséquent, leur prise en charge prend fin le 1er janvier 2024 dans nos clusters en mode Federal Information Processing Standard (FIPS). Support de ces derniers pour les clusters en FIPs mode non utilisé.

Ce guide s'applique aux opérations cryptographiques suivantes :
+ Génération de clés Triple DES
  + `CKM_DES3_KEY_GEN` pour la bibliothèque PKCS\#11
  + Keygen `DESede` pour le fournisseur JCE
  + `genSymKey` avec `-t=21` pour le KMU
+ Chiffrement avec des clés Triple DES (remarque : les opérations de déchiffrement sont autorisées)
  + Pour la bibliothèque PKCS\#11 : chiffrement `CKM_DES3_CBC`, chiffrement `CKM_DES3_CBC_PAD` et chiffrement `CKM_DES3_ECB`
  + Pour le fournisseur JCE : chiffrement `DESede/CBC/PKCS5Padding`, chiffrement `DESede/CBC/NoPadding`, chiffrement `DESede/ECB/Padding` et chiffrement `DESede/ECB/NoPadding`
+ Encapsulage, désencapsulage, chiffrement et déchiffrement de clés RSA avec le rembourrage PKCS\#1 v1.5
  + encapsulage, désencapsulage, chiffrement et déchiffrement `CKM_RSA_PKCS` pour le SDK PKCS\#11
  + encapsulage, désencapsulage, chiffrement et déchiffrement `RSA/ECB/PKCS1Padding` pour le SDK JCE
  + `wrapKey` et `unWrapKey` avec `-m 12` pour le KMU (où `12` la valeur du mécanisme `RSA_PKCS`)

[1] Pour plus de détails sur cette modification, reportez-vous aux tableaux 1 et 5 de la section [Transition de l'utilisation des algorithmes de chiffrement et des longueurs de clé](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf).