Bekannte Probleme für AWS CloudHSM hsm2m.medium-Instanzen

Auswirkung: Die Anmeldung bei hsm2m.medium erfolgt nach einer zu strengen Interpretation der Compliance-Anforderungen, was zu einer erhöhten Latenz führt.

Lösung: Wenn Sie vor dem 20. Dezember 2025 eine neue hsm2m.medium-Instance erstellt oder vor dem 20. Dezember 2025 von hsm1.medium zu hsm2m.medium migriert haben, müssen Sie Ihr Passwort zurücksetzen, um die Leistungsverbesserungen nutzen zu können, die wir für Anmeldevorgänge implementiert haben. Anweisungen zum Ändern des Passworts finden Sie.

Auswirkung: Die HSM-Instance hsm2m.medium verfügt über eine verbesserte Fairshare-Architektur, was im Vergleich zu hsm1.medium zu einer konsistenteren, vorhersehbaren Leistung führt. Bei hsm1.medium können Kunden aufgrund der unregelmäßigen Nutzung der HSM-Ressourcen eine höhere Findkey-Performance beobachten. Die Leistung von hsm1.medium find key nimmt jedoch ab, wenn die HSM-Instance gepatcht oder mit neuer Firmware aktualisiert wird. Dieses Problem wirkt sich auf Operationen wie in JCE aus. KeyStore.getKey()

Lösung: Dieses Problem wurde behoben. Als bewährte Methode empfiehlt es sich, die Ergebnisse von Suchvorgängen im Cache zu speichern. Durch das Zwischenspeichern wird die Gesamtzahl der Suchvorgänge nach Schlüsselwörtern reduziert, da es sich dabei um einen ressourcenintensiven Vorgang in HSM handelt. Implementieren Sie außerdem clientseitige Wiederholungsversuche mit exponentiellem Backoff und Jitter, um Fehler bei der HSM-Drosselung zu reduzieren.

Auswirkung: Jeder CO-Benutzer, der versucht, das vertrauenswürdige Attribut eines Schlüssels festzulegen, erhält eine entsprechende Fehlermeldung. User type should be CO or CU

Lösung: Zukünftige Versionen des Client-SDK werden dieses Problem lösen. Updates werden in unseren Benutzerhandbüchern bekannt gegebenDokumentverlauf.

Auswirkung: Die ECDSA-Überprüfung für HSMs im FIPS-Modus schlägt fehl.

Lösungsstatus: Dieses Problem wurde in der Client-SDK-Version 5.13.0 behoben. Sie müssen ein Upgrade auf diese Client-Version oder höher durchführen, um von dem Update profitieren zu können.

Auswirkung: Zertifikate im DER-Format können nicht als mTLS-Vertrauensanker mit CloudHSM CLI registriert werden.

Problemumgehung: Sie können ein Zertifikat im DER-Format mit dem Befehl openssl in das PEM-Format konvertieren: openssl x509 -inform DER -outform PEM -in certificate.der -out certificate.pem

Auswirkung: Alle von der Anwendung ausgeführten Operationen werden angehalten und der Benutzer wird während der gesamten Lebensdauer der Anwendung mehrmals zur Eingabe der Passphrase bei der Standardeingabe aufgefordert. Bei Vorgängen kommt es zu einer Zeitüberschreitung und sie schlagen fehl, wenn die Passphrase nicht vor Ablauf der Zeitüberschreitung des Vorgangs eingegeben wird.

Problemumgehung: Mit Passphrase verschlüsselte private Schlüssel werden für mTLs nicht unterstützt. Entfernen Sie die Passphrasenverschlüsselung aus dem privaten Schlüssel des Clients

Auswirkung: Die Benutzerreplikation schlägt auf hsm2m.medium-Instances fehl, wenn die CloudHSM-CLI verwendet wird. Der user replicate Befehl funktioniert auf hsm1.medium-Instances erwartungsgemäß.

Lösung: Dieses Problem wurde behoben.

Auswirkung: Vorgänge wie das Generieren von Zufallszahlen können auf hsm2m.medium-Instances fehlschlagen, während AWS CloudHSM ein Backup erstellt.

Lösung: Implementieren Sie die folgenden Best Practices, um Serviceunterbrechungen zu minimieren:

Weitere Informationen zu bewährten Methoden, finden Sie unter Bewährte Methoden für AWS CloudHSM.

Auswirkung: Das Client-SDK 5.8 und höher wiederholen einige HSM-gedrosselte Operationen nicht

Problemumgehung: Folgen Sie den bewährten Methoden, um Ihren Cluster so zu gestalten, dass er die Last bewältigt, und implementieren Sie Wiederholungen auf Anwendungsebene. Wir arbeiten derzeit an einer Lösung. Updates werden in unseren Benutzerhandbüchern bekannt gegebenDokumentverlauf.

Lösungsstatus: Dieses Problem wurde im AWS CloudHSM Client SDK 5.16.2 behoben. Sie müssen ein Upgrade auf diese Client-Version oder höher durchführen, um von dem Update profitieren zu können.

Auswirkung: Wenn der AES/CBC Mechanismus zum Entpacken von Schlüsseln mithilfe des AWS CloudHSM JCE-Providers verwendet wird, schlagen Operationen mit einer 16-Byte-IV, die mit Null gefüllt ist, auf hsm2m.medium-Instances fehl. Dies liegt an einer zusätzlichen Validierungsprüfung, die in hsm1.medium-Instances nicht durchgeführt wurde.

Lösungsstatus: Wir arbeiten an einem Fix, der es ermöglicht, dass Null-Byte-IVs bei Unwrap-Vorgängen akzeptiert werden. AES/CBC

Auswirkung: Dieses Problem betrifft Kaltstarts wie die Bereitstellung oder Neustarts von Client-Anwendungen. Die HSM-Instance hsm2m.medium verfügt über eine verbesserte Fair-Share-Architektur, die eine konsistentere Leistung, einen einheitlicheren Durchsatz und eine gleichmäßigere Latenz für alle Kunden gewährleistet. Derzeit kann es bei der gleichzeitigen Initialisierung der HSM-Verbindung auf hsm1.medium vorkommen, dass die Leistung höher als vorgesehen ist. Die Leistung der hsm1.medium-Verbindungsinitialisierung hängt jedoch von den zugrunde liegenden Systemupdates ab.

Lösung: Halten Sie sich an die bewährten Methoden und verteilen Sie die Bereitstellung und Neustarts der Client-Anwendungen gestaffelt, um die Anzahl der Client-Anwendungen zu begrenzen, die gleichzeitig HSM-Verbindungen initialisieren. Wir empfehlen außerdem, Wiederholungen für die Initialisierung von Client-Anwendungen auf Anwendungsebene zu implementieren. Führen Sie außerdem Bootstrap mithilfe des Konfigurationstools durch--cluster-id <cluster ID>, um alle HSM-IP-Adressen zur Client-Konfigurationsdatei hinzuzufügen. Dieses Verhalten wurde in der AWS CloudHSM Client SDK-Version 5.17.1 und höher verbessert. Wir empfehlen ein Upgrade auf die neueste SDK-Version, um von dieser Verbesserung zu profitieren.