AWS CloudHSM – Häufig gestellte Fragen

Die Bereitstellung eines HSM in einem AWS-CloudHSM-Cluster wird pro Stunde (bzw. angefangene Stunde) berechnet. Für einen Cluster, der keine HSMs enthält, fallen keine Gebühren an. Auch die automatische Speicherung von verschlüsselten Backups ist in diesem Fall kostenlos. Weitere Informationen finden Sie auf der Preisseite zu AWS CloudHSM. Beachten Sie, dass Netzwerkdatenübertragungen zu und aus Ihren HSMs separat berechnet werden. Weitere Informationen finden Sie unter Datenübertragungspreise für EC2.

Nein, für AWS CloudHSM gibt es kein kostenloses Kontingent.

Nein, die stündliche Gebühr, die je nach Region variiert, hängt nicht davon ab, in welchem Umfang Sie Ihr HSM verwenden.

Nein, wir bieten für AWS CloudHSM kein Reserved-Instance-Preismodell an.

Ja. Für die Inbetriebnahme von AWS CloudHSM gelten verschiedene Voraussetzungen, einschließlich einer Virtual Private Cloud (VPC) in der Region, in der Sie den AWS-CloudHSM-Service wünschen. Weitere Informationen hierzu finden Sie im Benutzerhandbuch für AWS CloudHSM.

Nein. Die Firmware wird von AWS auf der Hardware verwaltet. Die Firmware-Verwaltung erfolgt durch einen Drittanbieter, wobei jegliche Firmware von NIST hinsichtlich ihrer Konformität mit FIPS 140-2 Level 3 bewertet werden muss. Es kann nur durch den FIPS-Schlüssel kryptografisch signierte Firmware installiert werden. (AWS hat keinen Zugriff auf den Schlüssel.)

AWS empfiehlt für Produktionsarbeitslasten dringend die Verwendung von mindestens zwei HSMs in zwei verschiedenen Availability. Für geschäftskritische Arbeitslasten sollten Sie mindestens drei HSMs in mindestens zwei separaten AZs verwenden. Der CloudHSM-Client verarbeitet automatisch jegliche HSM-Ausfälle und sorgt für den transparenten Lastenausgleich zwischen zwei oder mehr HSMs.

AWS erstellt täglich automatische verschlüsselte Backups Ihres CloudHSM-Clusters. AWS erstellt zusätzliche Backups, wenn Lebenszyklusereignisse im Cluster auftreten (wie z. B. das Hinzufügen oder Entfernen eines HSM). Während der 24 Stunden zwischen den Backups sind ausschließlich Sie selbst für die Beständigkeit der in Ihrem Cluster erstellten oder darin importierten Schlüsselinformationen zuständig. Wir empfehlen dringend die Synchronisierung aller erstellten Schlüssel auf mindestens zwei HSMs in zwei verschiedenen Availability Zones, um die Beständigkeit Ihrer Schlüssel zu gewährleisten. Weitere Details zum Überprüfen der Schlüsselsynchronisierung finden Sie im Benutzerhandbuch für AWS CloudHSM.

Die Hochverfügbarkeit wird automatisch sichergestellt, wenn Sie in Ihrem CloudHSM-Cluster mindestens zwei HSMs zwischen zwei Availability Zones verteilt haben. Es ist keine zusätzliche Konfiguration erforderlich. Bei einem Ausfall eines HSM in Ihrem Cluster wird das Modul automatisch ersetzt. Sämtliche Clients werden daraufhin aktualisiert, um die neue Konfiguration widerzuspiegeln, während die Verarbeitung weiter läuft. Zusätzliche HSMs können Sie dem Cluster über die AWS API oder das AWS SDK hinfügen, um die Verfügbarkeit zu erhöhen, ohne die Anwendung zu unterbrechen.

Ein CloudHSM-Cluster kann bis zu 28 HSMs enthalten (vorbehaltlich Service-Limits des Kontos). Weitere Informationen zu Service-Limits und zum Beantragen einer Limit-Erhöhung finden Sie in der Online-Dokumentation.

Ihr CloudHSM-Cluster wird täglich von AWS gesichert. Sie können die Schlüssel auch aus dem Cluster exportieren („wrapped“) und On-Premises speichern, es sei denn, die Schlüssel wurden als „nicht exportierbar“ generiert.

Ja, Sie finden das Service Level Agreement (SLA) für AWS CloudHSM hier.

Nein. Sie erhalten im Rahmen des Services Single-Tenant-Zugriff auf das HSM. Die zugrundeliegende Hardware kann mit anderen Kunden gemeinsam genutzt werden, aber der Zugriff auf das HSM ist Ihnen vorbehalten.

Die Trennung von Aufgaben und eine rollenbasierte Zugriffssteuerung sind wesentliche Merkmale von AWS CloudHSM. AWS hat begrenzten Zugriff auf das HSM, mit dem wir den Zustand und die Verfügbarkeit des HSM überwachen und gewährleisten, verschlüsselte Backups erstellen und Protokolle von Prüfungen extrahieren sowie in CloudWatch Logs veröffentlichen können. AWS kann nicht auf Schlüssel oder Daten in Ihrem CloudHSM-Cluster zugreifen und lediglich die Schritte ausführen, die HSM-Appliance-Benutzern gestattet sind.

Weitere Informationen zur Aufgabentrennung und den Funktionen, die jeder Benutzerklasse für das HSM zur Verfügung stehen, finden Sie im Benutzerhandbuch für AWS CloudHSM.

Ja. AWS CloudHSM veröffentlicht mehrere Amazon-CloudWatch-Kennzahlen für CloudHSM-Cluster und individuelle HSMs. Um die Kennzahlen abzurufen oder diesbezügliche Benachrichtigungen zu übermitteln, können Sie die Amazon-CloudWatch-Konsole, die API oder das SDK verwenden.

Jedes HSM verfügt über einen gemäß FIPS validierten deterministischen Bit-Zufallsgenerator (Deterministic Random Bit Generator, DRBG), der von einem echten Zufallszahlengenerator (True Random Number Generator, TRNG) innerhalb des HSM-Hardwaremoduls verbreitet wird, der SP800-90B entspricht.

AWS CloudHSM verfügt über physische und logische Mechanismen, um Manipulationsversuche zu erkennen und darauf zu reagieren, indem die Schlüssel der Hardware gelöscht (genullt) werden. Die Hardware ist darauf ausgelegt, Manipulationen zu erkennen, falls eine physische Barriere durchbrochen wird. HSMs sind zudem vor Brute-Force-Anmeldeangriffen geschützt. Nachdem eine festgelegte Anzahl gescheiterter Zugriffsversuche auf ein HSM mit Anmeldeinformationen eines Crypto Officers (CO, Verschlüsselungsverantwortlicher) oder Administrators erreicht ist, sperrt das HSM den CO/Administrator aus. Gleichermaßen gilt: Nachdem eine festgelegte Anzahl gescheiterter Zugriffsversuche auf ein HSM mit Crypto-Benutzer (CU)-Anmeldeinformationen erreicht ist, wird der Benutzer gesperrt und muss von einem CO oder Administrator entsperrt werden.

Amazon überwacht und verwaltet das HSM und das Netzwerk hinsichtlich der Verfügbarkeit und Fehlerbedingungen. Ein ausgefallenes oder vom Netzwerk getrenntes HSM wird automatisch ersetzt. Sie können den Status eines einzelnen HSM mithilfe der APIs, der SDKs oder der CLI-Tools von AWS CloudHSM überprüfen. Außerdem können Sie jederzeit in AWS – Übersicht zum Servicestatus den allgemeinen Status des Service einsehen.

Falls das AWS-CloudHSM-Cluster nur ein einziges HSM umfasst, ist es tatsächlich möglich, dass seit dem letzten täglichen Backup erstellte Schlüssel verloren gehen. Bei AWS-CloudHSM-Clustern mit zwei oder mehr HSMs (idealerweise in unterschiedlichen Availability Zones) gehen die Schlüssel nicht verloren, wenn bei einem einzelnen HSM Fehler auftreten. Weitere Informationen hierzu finden Sie unter Bewährte Methoden.

Nein. Amazon hat keinen Zugriff auf Ihre Schlüssel oder Anmeldeinformationen und deshalb keine Möglichkeit, Ihre Schlüssel wiederherstellen, sollten Sie Ihre Anmeldeinformationen verlieren.

AWS CloudHSM basiert auf Hardware mit einer Validierung nach Federal Information Processing Standard (FIPS) 140-2 Level 3. Informationen über das FIPS 140-2 Sicherheitsprofil für die von CloudHSM verwendete Hardware und die ausgeführte Firmware finden Sie auf unserer Compliance-Seite.

Ja. CloudHSM stellt HSMs mit einer FIPS 140-2 Level 3-Validierung zur Verfügung. Folgen Sie im Benutzerhandbuch für CloudHSM dem Verfahren im Abschnitt zur Überprüfung der HSM-Authentizität, um sicherzustellen, dass Ihr HSM auf der Modellhardware authentisch ist, die in der NIST-Sicherheitsrichtlinie aus der vorherigen Frage angegeben ist.

AWS CloudHSM wird immer im FIPS 140-2-Modus ausgeführt. Sie können dies mithilfe der CLI-Tools gemäß der Erläuterung im Benutzerhandbuch für CloudHSM verifizieren. Durch Ausführen des Befehls „getHsmInfo“ wird als Status der FIPS-Modus angegeben.

Ja. AWS CloudTrail zeichnet Aufrufe von AWS-APIs für Ihr Konto auf. Der AWS-API-Aufrufverlauf, der von AWS CloudTrail generiert wird, ermöglicht eine Sicherheitsanalyse, Nachverfolgung von Ressourcenänderungen und Überwachung der Compliance von Vorschriften. Weitere Informationen zu AWS CloudTrail finden Sie auf der Startseite von CloudTrail. In der AWS-Managementkonsole von CloudTrail können Sie CloudTrail aktivieren.

AWS CloudTrail beinhaltet keine der HSM-Geräte- oder Zugriffsprotokolle. Diese werden Ihrem AWS-Konto direkt über AWS CloudWatch Logs bereitgestellt. Weitere Informationen hierzu finden Sie im Benutzerhandbuch für AWS CloudHSM.

Weitere Informationen zu den Compliance-Programmen, die CloudHSM abdecken, erhalten Sie auf der Website zur AWS-Compliance. Im Gegensatz zu anderen AWS-Services, werden die Compliance-Anforderungen bezüglich AWS CloudHSM häufig direkt durch die FIPS 140-2 Level 3-Validierung der Hardware an sich erfüllt, anstatt im Rahmen eines separaten Prüfprogramms.

FIPS 140-2 Level 3 ist für bestimmte Anwendungsfälle wie etwa das Ausstellen von SSL-Zertifikaten als öffentliche Zertifizierungsstelle, Dokumentsignierungen oder Zahlungen erforderlich.

Sehen Sie sich die Daten in AWS-Services unter Berücksichtigung des Compliance-Programms an, um zu erfahren, in welchen Compliance-Berichten AWS CloudHSM berücksichtigt wird. Verwenden Sie AWS Artifact, um selbst kostenlose On-Demand-Compliance-Berichte zu erstellen.

Interessieren Sie sich ausschließlich für die FIPS-Validierung für HSMs von AWS CloudHSM, finden Sie unter FIPS-Validierung weitere Informationen.

Die Leistung kann je nach Konfiguration, Datengröße und zusätzlicher Anwendungslast auf Ihren EC2-Instances variieren. Um die Leistung zu erhöhen, können Sie Ihren Clustern zusätzliche HSM-Instances hinzufügen. Wir empfehlen Ihnen, Ihre Anwendung unter Last zu testen, um die Skalierungsanforderungen zu ermitteln.

Weitere Informationen finden Sie auf der Leistungsseite im Benutzerhandbuch für AWS CloudHSM.

Einzelheiten zu wichtigen Speicher- und Clusterkapazitäten finden Sie unter AWS-CloudHSM-Kontingente.

Nicht direkt. Sie sollten AWS Key Management Service mit benutzerdefiniertem Schlüsselspeicher verwenden, um Amazon-RDS-Daten mithilfe von Schlüsseln zu sichern, die in Ihrem AWS-CloudHSM-Cluster generiert und gespeichert werden.

Die Nutzung von AWS CloudHSM als Vertrauensquelle wird von mehreren Drittanbietern unterstützt. Das bedeutet, dass Sie beim Erstellen und Speichern der zugrunde liegenden Schlüssel in Ihrem CloudHSM-Cluster eine Software-Lösung Ihrer Wahl einsetzen können.

Die AWS CloudHSM Client Library ist ein von AWS bereitgestelltes Softwarepaket, mit dem Sie und Ihre Anwendungen mit CloudHSM-Clustern interagieren können.

Nein. Die gesamte Kommunikation zwischen dem Client und Ihrem HSM ist durchgängig verschlüsselt. AWS kann diese Kommunikation weder sehen noch abfangen. Auch Ihre Cluster-Anmeldeinformationen sind für AWS unzugänglich.

Anweisungen finden Sie im Benutzerhandbuch für CloudHSM.

Nein. Die CloudHSM-Tools kommunizieren direkt mit Ihrem CloudHSM-Cluster über die CloudHSM Client Library. Der verwendete Kanal ist sicher und nutzt die gegenseitige Authentifizierung. AWS kann keine Kommunikation zwischen dem Client, den Tools und dem HSM beobachten. Sie ist duchgängig verschlüsselt.

Eine vollständige Liste der unterstützten Betriebssysteme finden Sie in unserer Online-Dokumentation.

Der Host, auf dem Sie die CloudHSM Client Library und/oder die CLI-Tools ausführen, muss zu allen HSMs in Ihrem CloudHSM-Cluster über ein Netzwerk verbunden sein.

Sie können CloudHSM-Cluster und HSMs erstellen, ändern und löschen und ihren Status abrufen. Die Verwendungsmöglichkeiten der AWS-CloudHSM-API beschränken sich auf Vorgänge, die AWS mit seinen begrenzten Zugriffsrechten ausführen kann. Die API kann nicht auf die Inhalte des HSM zugreifen oder zur Änderung von Benutzern, Richtlinien oder anderen Einstellungen genutzt werden. Weitere Informationen zur API finden Sie in der CloudHSM-Dokumentation, weitere Informationen zum SDK auf der Seite mit den Tools für Amazon Web Services.

Stellen Sie zunächst sicher, dass die von Ihnen benötigten Algorithmen und Modi von AWS CloudHSM unterstützt werden. Ihr Konto-Verwalter kann uns bei Bedarf gerne Feature-Anfragen stellen. Bestimmen Sie als nächstes Ihre primäre Rotationsstrategie. Wir haben auch einen detaillierten Migrationsleitfaden für AWS CloudHSM bereitgestellt. Jetzt sind Sie bereit für die ersten Schritte mit AWS CloudHSM.

Ihre Rotationsstrategie hängt vom Typ Ihrer Anwendung ab. Nachfolgend einige gängige Beispiele.

• Private Schlüssel für die Signatur: Der private Schlüssel im HSM entspricht in der Regel einem Zwischenzertifikat, das seinerseits von einem Offline-Unternehmens-Root signiert wird. Sie rotieren Schlüssel durch Ausgabe eines neuen Zwischenzertifikats. Erstellen Sie einen neuen privaten Schlüssel und generieren Sie den entsprechenden CSR mit OpenSSL auf AWS CloudHSM. Signieren Sie den CSR danach mit dem gleichen Offline-Unternehmens-Root. Eventuell muss dieses neue Zertifikat bei allen Partnern registriert werden, die nicht automatisch die gesamte Zertifikatskette verifizieren. Danach signieren Sie alle neuen Anforderungen (z. B. für Dokumente, Code oder andere Zertifikate) mit dem privaten Schlüssel, der dem neuen Zertifikat folgt. Mit dem entsprechenden öffentlichen Schlüssel können Sie die Signaturen des ursprünglichen privaten Schlüssels aber nach wie vor verifizieren. Es ist kein Widerruf erforderlich. Der Prozess entspricht der Stilllegung oder Archivierung eines Signaturschlüssels.
• Oracle Transparent Data Encryption: Ihre elektronische Börse können Sie transferieren, indem Sie zunächst von einem Hardware-Keystore (Ihrem bisherigen HSM) zu einem Software-Keystore und danach zurück zu einem Hardware-Keystore (AWS CloudHSM) wechseln. Hinweis: Wenn Sie Amazon RDS verwenden, lesen Sie die obigen häufig gestellten Fragen „Wird Amazon RDS Oracle TDE von AWS CloudHSM unterstützt?“
• Symmetrischer Schlüssel für die Umschlagverschlüsselung: Umschlagverschlüsselung bezieht sich auf die Hauptarchitektur, in der ein Schlüssel im HSM viele Datenschlüssel auf dem Anwendungshost ver- bzw. entschlüsselt. Vermutlich verwenden Sie bereits einen Rotationsprozess, der die Datenschlüssel mit dem alten Wrapping-Schlüssel entschlüsselt und sie mit dem neuen Wrapping-Schlüssel verschlüsselt. Der einzige Unterschied bei der Migration besteht darin, dass der neue Wrapping-Schlüssel auf AWS CloudHSM erstellt und verwendet wird und nicht mehr auf Ihrem bisherigen HSM. Falls Sie noch keinen Prozess (bzw. kein Tool) für die Schlüsselrotation eingerichtet haben, müssen Sie einen erstellen.

Hier unterscheiden sich jedoch jede Anwendung und jeder Anwendungsfall. Lösungen für häufig auftretende Szenarien werden im Migrationsleitfaden für CloudHSM besprochen. Bei weiteren Fragen eröffnen Sie einen Supportfall mit Details Ihrer Anwendung, dem aktuell verwendeten HSM-Typ und dem verwendeten Schlüsseltyp. Geben Sie außerdem an, ob diese Schlüssel exportiert werden können. Wir helfen Ihnen bei der Entwicklung eines geeigneten Migrationspfads.

Nein. Es kann jedoch vorkommen, dass AWS aufgrund von erforderlichen Upgrades oder Hardware-Fehlern Wartungsarbeiten durchführen muss. Wir bemühen uns, Sie vorab über das persönliche Zustands-Dashboard von solchen Wartungsarbeiten in Kenntnis zu setzen, falls wir davon ausgehen, dass sie sich auf Sie auswirken.

Bitte beachten Sie, dass es in Ihrer Verantwortung liegt, Ihren Cluster für eine hohe Verfügbarkeit zu entwickeln. AWS empfiehlt dringend, CloudHSM-Cluster mit zwei oder mehr HSMs in separaten Availability Zones zu verwenden. Weitere Informationen zu den empfohlenen bewährten Methoden finden Sie in unserer Online-Dokumentation.

Lösungen für häufig auftretende Probleme finden Sie in unserem Leitfaden zur Fehlerbehebung. Sollten die Probleme weiterhin auftreten, wenden Sie sich an den AWS Support.