

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

# Notificaciones de obsolescencia
<a name="compliance-dep-notif"></a>

De vez en cuando, AWS CloudHSM pueden dejar de funcionar para cumplir con los requisitos de la norma FIPS 140, PCI-DSS, PCI-PIN, PCI-3DS o por motivos de hardware. SOC2 end-of-support Esta página detalla los cambios que se aplican actualmente.

## HSM1 Depreciación
<a name="hsm-dep-1"></a>

 El soporte del tipo de instancia AWS CloudHSM hsm1.medium finalizará el 31 de marzo de 2026. Para garantizar la continuidad del servicio, presentamos los siguientes cambios: 
+  A partir de abril de 2025, ya no podrá crear nuevos clústeres hsm1.medium. 
+  A partir de enero de 2026, comenzaremos a migrar automáticamente los clústeres hsm1.medium existentes al nuevo tipo de instancia hsm2m.medium. 

 El tipo de instancia hsm2m.medium es compatible con tu tipo de instancia actual y ofrece un rendimiento mejorado. AWS CloudHSM Para evitar interrupciones en las aplicaciones, debe actualizar a la versión más reciente del SDK de cliente. Para obtener instrucciones de actualización, consulte [Migración del SDK de AWS CloudHSM cliente 3 al SDK de cliente 5](client-sdk-migration.md). 

 Tiene dos opciones para la migración: 

1.  Optar por una migración administrada por CloudHSM cuando esté listo. Para obtener más información, [Migración de hsm1.medium a hsm2m.medium](hsm1-to-hsm2-migration.md). 

1.  Crear un nuevo clúster hsm2m.medium a partir de una copia de seguridad del clúster hsm1 y redirigir la aplicación al nuevo clúster. Recomendamos usar una estrategia de blue/green implementación para este enfoque. Para obtener más información, consulte [Crear AWS CloudHSM clústeres a partir de copias de seguridad](create-cluster-from-backup.md). 

## Cumplimiento de la normativa FIPS 140: anulación de mecanismo 2024
<a name="compliance-dep-notif-1"></a>

El Instituto Nacional de Estándares y Tecnología (NIST) [1](#dep-notif-1)recomienda no admitir el cifrado triple DES (DESede3DES DES3) y el empaquetado y desempaquetado de claves RSA con el relleno PKCS \$11 v1.5 después del 31 de diciembre de 2023. Por lo tanto, la compatibilidad con ellos finalizará el 1 de enero de 2024 en nuestros clústeres conformes al Federal Information Processing Standard (FIPS). El soporte para estos sigue siendo para los clústeres que no están en FIPs modo.

Esta guía se aplica a las siguientes operaciones criptográficas:
+ Generación de claves Triple DES
  + `CKM_DES3_KEY_GEN` para la biblioteca PKCS \$111
  + `DESede` Keygen para el proveedor de JCE
  + `genSymKey` con `-t=21` para KMU
+ Cifrado con claves Triple DES (nota: se permiten operaciones de descifrado)
  + Para la biblioteca PKCS \$111: cifrado `CKM_DES3_CBC`, cifrado `CKM_DES3_CBC_PAD` y cifrado `CKM_DES3_ECB`
  + Para el proveedor de JCE: cifrado `DESede/CBC/PKCS5Padding`, cifrado `DESede/CBC/NoPadding`, cifrado `DESede/ECB/Padding` y cifrado `DESede/ECB/NoPadding`
+ Encapsulado, desencapsulado, cifrado y descifrado de claves RSA con padding PKCS\$11 v1.5
  + Encapsulado, desencapsulado, cifrado y descifrado de `CKM_RSA_PKCS` para el SDK de PKCS\$111
  + Encapsulado, desencapsulado, cifrado y descifrado de `RSA/ECB/PKCS1Padding` para el SDK de JCE
  + `wrapKey` y `unWrapKey` con `-m 12` para KMU (tenga en cuenta que `12` es el valor del mecanismo `RSA_PKCS`)

[1] Para obtener más información sobre este cambio, consulte las tablas 1 y 5 de la sección [Transición en el uso de algoritmos criptográficos y longitudes de clave](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf).