Interne Operationen

In diesem Thema werden interne Anforderungen beschrieben, die der Dienst zur Sicherung von Kundenschlüsseln und kryptografischen Vorgängen für einen weltweit verteilten und skalierbaren Zahlungskryptografie- und Schlüsselverwaltungsdienst implementiert.

HSM-Spezifikationen und Lebenszyklus

AWS Payment Cryptography verwendet eine Flotte kommerziell erhältlicher HSM. Die HSMs sind nach FIPS 140-2 Level 3 validiert und verwenden außerdem Firmware-Versionen und die Sicherheitsrichtlinien, die auf der vom PCI Security Standards Council genehmigten PCI-PTS-Geräteliste als PCI HSM v3-konform aufgeführt sind. Der PCI PTS HSM-Standard beinhaltet zusätzliche Anforderungen für die Herstellung, den Versand, die Bereitstellung, die Verwaltung und die Zerstörung von HSM-Hardware, die für die Zahlungssicherheit und die Einhaltung der Vorschriften wichtig sind, aber in FIPS 140 nicht behandelt werden.

Alle HSMs werden im PCI-Modus betrieben und gemäß der PCI PTS HSM-Sicherheitsrichtlinie konfiguriert. Es sind nur Funktionen aktiviert, die zur Unterstützung von Anwendungsfällen mit AWS Zahlungskryptografie erforderlich sind. AWS Bei der Zahlungskryptografie ist das Drucken, Anzeigen oder Zurückgeben von PINs im Klartext nicht vorgesehen.

Physische Sicherheit von HSM-Geräten

Nur HSMs, deren Geräteschlüssel vor der Auslieferung von einer AWS Payment Cryptography Certificate Authority (CA) vom Hersteller signiert wurden, können vom Service verwendet werden. Bei der AWS Zahlungskryptografie handelt es sich um eine Unterzertifizierungsstelle der Zertifizierungsstelle des Herstellers, die als Vertrauensbasis für HSM-Hersteller- und Gerätezertifikate dient. Die Zertifizierungsstelle des Herstellers implementiert ANSI TR 34 und hat die Einhaltung von PCI PIN Security Annex A und PCI P2PE Annex A bescheinigt. Der Hersteller verifiziert, dass alle HSM mit Geräteschlüsseln, die von der AWS Payment Cryptography CA signiert wurden, an den von AWS angegebenen Empfänger gesendet werden.

Gemäß den Anforderungen von PCI PIN Security stellt der Hersteller eine Liste mit Seriennummern über einen anderen Kommunikationskanal als die HSM-Lieferung bereit. Diese Seriennummern werden bei jedem Schritt der HSM-Installation in AWS-Rechenzentren überprüft. Schließlich validieren die Betreiber von AWS Payment Cryptography die Liste der installierten HSM anhand der Herstellerliste, bevor sie die Seriennummer zur Liste der HSM hinzufügen, denen der Empfang AWS von Zahlungskryptografie-Schlüsseln gestattet ist.

HSMs befinden sich zu jeder Zeit in einem sicheren Speicher oder unterliegen einer doppelten Kontrolle. Dazu gehören:

• Versand vom Hersteller an eine AWS-Rackmontageeinrichtung.

• Während der Rackmontage.

• Versand von der Rackmontageanlage an ein Rechenzentrum.

• Empfang und Installation in einem sicheren Verarbeitungsraum des Rechenzentrums. HSM-Racks ermöglichen eine doppelte Steuerung mit kartengesteuerten Schlössern, alarmgesteuerten Türsensoren und Kameras.

• Während des Betriebs.

• Während der Stilllegung und Zerstörung.

Für jedes chain-of-custody HSM wird ein vollständiges System mit individueller Rechenschaftspflicht geführt und überwacht.

HSM-Initialisierung

Ein HSM wird erst als Teil der AWS Payment Cryptography-Flotte initialisiert, nachdem seine Identität und Integrität anhand von Seriennummern, vom Hersteller installierten Geräteschlüsseln und Firmware-Prüfsummen überprüft wurden. Nachdem die Authentizität und Integrität eines HSM überprüft wurden, wird es konfiguriert, einschließlich der Aktivierung des PCI-Modus. Anschließend werden die Hauptschlüssel für die Region AWS Payment Cryptography und die Hauptschlüssel des Profils eingerichtet, und das HSM steht dem Dienst zur Verfügung.

Wartung und Reparatur von HSM

HSM verfügen über wartungsfähige Komponenten, für die keine Verletzung der kryptografischen Grenzen des Geräts erforderlich ist. Zu diesen Komponenten gehören Lüfter, Netzteile und Batterien. Wenn ein HSM oder ein anderes Gerät im HSM-Rack gewartet werden muss, wird die doppelte Steuerung während der gesamten Zeit, in der das Rack geöffnet ist, aufrechterhalten.

Außerbetriebnahme von HSM

Die Außerbetriebnahme erfolgt aufgrund end-of-life oder des Ausfalls eines HSM. HSM werden logisch auf Null gesetzt, bevor sie aus ihrem Rack genommen werden. Wenn sie funktionsfähig sind, werden sie dann in sicheren Verarbeitungsräumen von AWS-Rechenzentren vernichtet. Sie werden niemals zur Reparatur an den Hersteller zurückgeschickt, für einen anderen Zweck verwendet oder vor ihrer Zerstörung auf andere Weise aus einem sicheren Verarbeitungsraum entfernt.

HSM-Firmware-Update

HSM-Firmware-Updates werden bei Bedarf installiert, um die Übereinstimmung mit den auf PCI PTS HSM und FIPS 140-2 (oder FIPS 140-3) gelisteten Versionen aufrechtzuerhalten, wenn ein Update sicherheitsrelevant ist oder wenn festgestellt wird, dass Kunden von den Funktionen einer neuen Version profitieren können. AWS Auf HSMs für Zahlungskryptografie wird eine Firmware ausgeführt, die den auf PCI PTS HSM gelisteten Versionen entspricht. off-the-shelf Neue Firmware-Versionen werden anhand der PCI- oder FIPS-zertifizierten Firmware-Versionen auf Integrität geprüft und anschließend auf ihre Funktionalität getestet, bevor sie auf allen HSMs eingeführt werden.

Zugriff durch den Bediener

In seltenen Fällen, in denen die während des normalen Betriebs vom HSM gesammelten Informationen nicht ausreichen, um ein Problem zu identifizieren oder eine Änderung zu planen, können Bediener zur Fehlerbehebung auch außerhalb der Konsole auf HSM zugreifen. Die folgenden Schritte werden ausgeführt:

• Aktivitäten zur Problembehandlung werden entwickelt und genehmigt, und die Sitzung außerhalb der Konsole ist geplant.

• Ein HSM wird aus dem Kundenbearbeitungsservice entfernt.

• Die Haupttasten werden gelöscht, und zwar unter doppelter Kontrolle.

• Der Bediener darf ohne Konsole auf das HSM zugreifen, um genehmigte Fehlerbehebungsaktivitäten durchzuführen, wobei die doppelte Kontrolle erfolgt.

  • Nach Beendigung der Sitzung ohne Konsole wird der erste Bereitstellungsprozess auf dem HSM durchgeführt, wobei die Standardfirmware und -konfiguration zurückgegeben und anschließend der Hauptschlüssel synchronisiert wird, bevor das HSM an die Servicekunden zurückgegeben wird.

  • Aufzeichnungen der Sitzung werden in der Änderungsnachverfolgung aufgezeichnet.

  • Die aus der Sitzung gewonnenen Informationen werden für die Planung future Änderungen verwendet.

Alle Aufzeichnungen über den Zugriff auf die Konsole werden auf Einhaltung der Prozessvorschriften und mögliche Änderungen an der HSM-Überwachung, dem non-console-access Verwaltungsprozess oder der Bedienerschulung überprüft.

Schlüsselverwaltung

Alle HSM in einer Region werden mit einem Region-Hauptschlüssel synchronisiert. Ein Region-Hauptschlüssel schützt mindestens einen Profil-Hauptschlüssel. Ein Profilhauptschlüssel schützt Kundenschlüssel.

Alle Hauptschlüssel werden von einem HSM generiert und durch symmetrische Schlüsselverteilung unter Verwendung asymmetrischer Techniken verteilt, die auf ANSI X9 TR 34 und PCI-PIN Anhang A abgestimmt sind.

Themen

• Generation
• Synchronisation der Hauptschlüssel der Region
• Rotation der wichtigsten Schlüssel in der Region
• Synchronisation der Hauptschlüssel des Profils
• Rotation der Hauptschlüssel des Profils
• Schutz
• Haltbarkeit
• Sicherheit der Kommunikation
• Verwaltung der Kundenschlüssel
• Protokollierung und Überwachung

Generation

AES-256-Bit-Hauptschlüssel werden auf einem der für die Service-HSM-Flotte bereitgestellten HSM mithilfe des PCI PTS HSM-Zufallszahlengenerators generiert.

Synchronisation der Hauptschlüssel der Region

Die Hauptschlüssel der HSM-Region werden vom Service für die gesamte regionale Flotte mithilfe von Mechanismen synchronisiert, die in ANSI X9 TR-34 definiert sind. Dazu gehören:

• Gegenseitige Authentifizierung mithilfe von Schlüsseln und Zertifikaten für den Schlüsselverteilungshost (KDH) und das Schlüsselempfangsgerät (KRD), um die Authentifizierung und Integrität von öffentlichen Schlüsseln zu gewährleisten.

• Zertifikate werden von einer Zertifizierungsstelle (CA) signiert, die die Anforderungen des PCI-PIN-Anhangs A2 erfüllt, mit Ausnahme von asymmetrischen Algorithmen und Schlüsselstärken, die für den Schutz von AES-256-Bit-Schlüsseln geeignet sind.

• Identifizierung und Schlüsselschutz für die verteilten symmetrischen Schlüssel entsprechen ANSI X9 TR-34 und PCI-PIN Anhang A1, mit Ausnahme von asymmetrischen Algorithmen und Schlüsselstärken, die für den Schutz von AES-256-Bit-Schlüsseln geeignet sind.

Regionale Hauptschlüssel werden für HSMs eingerichtet, die authentifiziert und für eine Region bereitgestellt wurden, und zwar durch:

• Ein Hauptschlüssel wird auf einem HSM in der Region generiert. Dieses HSM ist als Host für die Schlüsselverteilung vorgesehen.

• Alle bereitgestellten HSMs in der Region generieren ein KRD-Authentifizierungstoken, das den öffentlichen Schlüssel des HSM und nicht wiedergabefähige Authentifizierungsinformationen enthält.

• KRD-Token werden der KDH-Zulassungsliste hinzugefügt, nachdem das KDH die Identität und die Berechtigung des HSM zum Empfang von Schlüsseln überprüft hat.

• Das KDH erstellt für jedes HSM ein authentifizierbares Hauptschlüssel-Token. Token enthalten KDH-Authentifizierungsinformationen und einen verschlüsselten Hauptschlüssel, der nur auf ein HSM geladen werden kann, für das er erstellt wurde.

• Jedes HSM erhält das dafür erstellte Hauptschlüssel-Token. Nach der Validierung der HSM-eigenen Authentifizierungsinformationen und der KDH-Authentifizierungsinformationen wird der Hauptschlüssel mit dem privaten KRD-Schlüssel entschlüsselt und in den Hauptschlüssel geladen.

Für den Fall, dass ein einzelnes HSM mit einer Region erneut synchronisiert werden muss:

• Es wird erneut validiert und mit Firmware und Konfiguration ausgestattet.

• Wenn es neu in der Region ist:

  • Das HSM generiert ein KRD-Authentifizierungstoken.

  • Das KDH fügt das Token seiner Zulassungsliste hinzu.

  • Das KDH generiert ein Hauptschlüssel-Token für das HSM.

  • Das HSM lädt den Hauptschlüssel.

  • Das HSM wird dem Dienst zur Verfügung gestellt.

Dies stellt sicher, dass:

• Nur HSM, das innerhalb einer Region für die Verarbeitung von AWS Zahlungskryptografie validiert wurde, kann den Masterschlüssel dieser Region empfangen.

• Nur ein Masterschlüssel aus einem HSM für AWS Zahlungskryptografie kann an ein HSM in der Flotte verteilt werden.

Rotation der wichtigsten Schlüssel in der Region

Die Hauptschlüssel der Region werden nach Ablauf der Kryptoperiode, im unwahrscheinlichen Fall, dass ein Schlüssel kompromittiert wird, oder nach Änderungen am Dienst, die sich nachweislich auf die Sicherheit des Schlüssels auswirken, ausgetauscht.

Ein neuer Hauptschlüssel für die Region wird wie bei der ersten Bereitstellung generiert und verteilt. Die Hauptschlüssel des gespeicherten Profils müssen in den Hauptschlüssel der neuen Region übersetzt werden.

Die Rotation der Hauptschlüssel der Region hat keine Auswirkungen auf die Kundenabwicklung.

Synchronisation der Hauptschlüssel des Profils

Die Hauptschlüssel des Profils sind durch die Hauptschlüssel der Region geschützt. Dadurch wird ein Profil auf eine bestimmte Region beschränkt.

Die Hauptschlüssel des Profils werden entsprechend bereitgestellt:

• Ein Profilhauptschlüssel wird auf einem HSM generiert, bei dem der Hauptschlüssel der Region synchronisiert ist.

• Der Hauptschlüssel des Profils wird zusammen mit der Profilkonfiguration und anderem Kontext gespeichert und verschlüsselt.

• Das Profil wird von jedem HSM in der Region mit dem Hauptschlüssel der Region für kryptografische Kundenfunktionen verwendet.

Rotation der Hauptschlüssel des Profils

Die Hauptschlüssel des Profils werden nach Ablauf der Kryptoperiode, nach dem Verdacht, dass Schlüssel kompromittiert wurden, oder nach Änderungen am Dienst, die sich nachweislich auf die Sicherheit des Schlüssels auswirken, ausgetauscht.

Schritte der Rotation:

• Ein neuer Profilhauptschlüssel wird generiert und wie bei der ersten Bereitstellung als ausstehender Hauptschlüssel verteilt.

• Ein Hintergrundprozess übersetzt Kundenschlüsselmaterial vom etablierten Profilhauptschlüssel in den ausstehenden Hauptschlüssel.

• Wenn alle Kundenschlüssel mit dem ausstehenden Schlüssel verschlüsselt wurden, wird der ausstehende Schlüssel zum Hauptschlüssel des Profils heraufgestuft.

• Ein Hintergrundprozess löscht das durch den abgelaufenen Schlüssel geschützte Kundenschlüsselmaterial.

Die Rotation des Hauptschlüssels im Profil hat keine Auswirkungen auf die Kundenabwicklung.

Schutz

Schlüssel hängen nur von der zu schützenden Schlüsselhierarchie ab. Der Schutz der Hauptschlüssel ist entscheidend, um den Verlust oder die Beeinträchtigung aller Kundenschlüssel zu verhindern.

Hauptschlüssel der Region können nur aus dem Backup wiederhergestellt werden, wenn HSM authentifiziert und für den Service bereitgestellt wurde. Diese Schlüssel können nur als gegenseitig authentifizierbare, verschlüsselte Hauptschlüssel-Token von einem bestimmten KDH für ein bestimmtes HSM gespeichert werden.

Profilhauptschlüssel werden mit der Profilkonfiguration und den Kontextinformationen gespeichert, die nach Regionen verschlüsselt sind.

Kundenschlüssel werden in Schlüsselblöcken gespeichert, die durch einen Profil-Hauptschlüssel geschützt sind.

Alle Schlüssel befinden sich ausschließlich in einem HSM oder werden durch einen anderen Schlüssel mit gleicher oder höherer kryptografischer Stärke geschützt gespeichert.

Haltbarkeit

Kundenschlüssel für Transaktionskryptografie und Geschäftsfunktionen müssen auch in Extremsituationen verfügbar sein, die normalerweise zu Ausfällen führen würden. AWS Bei der Zahlungskryptografie wird ein mehrstufiges Redundanzmodell für alle Verfügbarkeitszonen und Regionen verwendet. AWS Kunden, die für kryptografische Zahlungsvorgänge eine höhere Verfügbarkeit und Beständigkeit benötigen, als sie vom Service bereitgestellt werden, sollten Architekturen mit mehreren Regionen implementieren.

Die HSM-Authentifizierung und die Hauptschlüssel-Token werden gespeichert und können zur Wiederherstellung eines Hauptschlüssels oder zur Synchronisation mit einem neuen Hauptschlüssel verwendet werden, falls ein HSM zurückgesetzt werden muss. Die Token werden archiviert und bei Bedarf nur unter doppelter Kontrolle verwendet.

Sicherheit der Kommunikation

Extern

AWS API-Endpunkte für Zahlungskryptografie erfüllen AWS Sicherheitsstandards wie TLS 1.2 oder höher und Signature Version 4 für die Authentifizierung und Integrität von Anfragen.

Eingehende TLS-Verbindungen werden auf Netzwerk-Loadbalancern beendet und über interne TLS-Verbindungen an API-Handler weitergeleitet.

Intern

Die interne Kommunikation zwischen Servicekomponenten sowie zwischen Servicekomponenten und anderen AWS wird durch TLS unter Verwendung starker Kryptografie geschützt.

HSM befinden sich in einem privaten, nicht virtuellen Netzwerk, das nur von Servicekomponenten aus erreichbar ist. Alle Verbindungen zwischen HSM und Servicekomponenten sind mit Mutual TLS (mTLS), mindestens TLS 1.2, gesichert. Interne Zertifikate für TLS und mTLS werden von Amazon Certificate Manager mithilfe einer privaten AWS-Zertifizierungsstelle verwaltet. Interne VPCs und das HSM-Netzwerk werden auf unerwartete Aktivitäten und Konfigurationsänderungen überwacht.

Verwaltung der Kundenschlüssel

Bei AWS hat das Vertrauen unserer Kunden oberste Priorität. Sie behalten die volle Kontrolle über Ihre Schlüssel, die Sie unter Ihrem AWS-Konto hochladen oder im Service erstellen, und sind für die Konfiguration des Zugriffs auf Schlüssel verantwortlich.

AWS Payment Cryptography trägt die volle Verantwortung für die physische Einhaltung der HSM-Vorschriften und die Schlüsselverwaltung der vom Service verwalteten Schlüssel. Dies erfordert den Besitz und die Verwaltung der HSM-Hauptschlüssel sowie die Speicherung geschützter Kundenschlüssel in der AWS Payment Cryptography-Schlüsseldatenbank.

Trennung des Kundenschlüsselraums

AWS Bei der Zahlungskryptografie werden wichtige Richtlinien für die gesamte Verwendung von Schlüsseln durchgesetzt, einschließlich der Beschränkung der Hauptbenutzer auf das Konto, dem der Schlüssel gehört, sofern ein Schlüssel nicht ausdrücklich mit einem anderen Konto geteilt wird.

Sicherung und Wiederherstellung

Schlüssel und wichtige Informationen für eine Region werden in verschlüsselten Archiven von gesichert. AWS Für die Wiederherstellung von AWS Archiven ist eine doppelte Kontrolle erforderlich.

Schlüsselblöcke

Alle Schlüssel werden in Schlüsselblöcken im ANSI X9 TR-31-Format gespeichert.

Schlüssel können aus Kryptogrammen oder anderen Schlüsselblockformaten, die von unterstützt werden, in den Dienst importiert werden. ImportKey Ebenso können Schlüssel, sofern sie exportierbar sind, in andere Schlüsselblockformate oder Kryptogramme exportiert werden, die von Schlüsselexportprofilen unterstützt werden.

Verwendung von Schlüsseln

Die Verwendung von Schlüsseln ist auf die KeyUsage vom Dienst konfigurierten Werte beschränkt. Der Dienst schlägt alle Anfragen fehl, bei denen der Schlüssel, der Verwendungsmodus oder der Algorithmus für den angeforderten kryptografischen Vorgang unangemessen verwendet wurden.

Beziehungen zum Schlüsselaustausch

PCI PIN Security und PCI P2PE verlangen, dass Organisationen, die Schlüssel zur Verschlüsselung von PINs gemeinsam nutzen, einschließlich des KEK, mit dem diese Schlüssel gemeinsam genutzt werden, diese Schlüssel nicht mit anderen Organisationen teilen. Es hat sich bewährt, dass symmetrische Schlüssel nur von zwei Parteien gemeinsam genutzt werden, auch innerhalb derselben Organisation. Dadurch werden die Auswirkungen vermuteter wichtiger Sicherheitslücken minimiert, die den Austausch der betroffenen Schlüssel erzwingen könnten.

Selbst in Geschäftsfällen, bei denen Schlüssel zwischen mehr als zwei Parteien gemeinsam genutzt werden müssen, sollte die Anzahl der Parteien auf die Mindestanzahl beschränkt werden.

AWS Die Zahlungskryptografie bietet Schlüsselkennzeichnungen, anhand derer die Verwendung von Schlüsseln im Rahmen dieser Anforderungen nachverfolgt und durchgesetzt werden kann.

Beispielsweise können KEK und BDK für verschiedene Schlüsseleingabefunktionen identifiziert werden, indem für alle Schlüssel, die mit diesem Dienstanbieter geteilt werden, ein „KIF“ = „PosStation“ gesetzt wird. Ein anderes Beispiel wäre, Schlüssel, die mit Zahlungsnetzwerken geteilt werden, mit „Network“ = „“ zu kennzeichnen. PayCard Durch Tagging können Sie Zugriffskontrollen einrichten und Prüfberichte erstellen, um Ihre wichtigsten Managementpraktiken durchzusetzen und nachzuweisen.

Löschen von Schlüsseln

DeleteKey markiert Schlüssel in der Datenbank zum Löschen nach einem vom Kunden konfigurierbaren Zeitraum. Nach diesem Zeitraum wird der Schlüssel unwiederbringlich gelöscht. Dies ist ein Sicherheitsmechanismus, um das versehentliche oder böswillige Löschen eines Schlüssels zu verhindern. Schlüssel, die zum Löschen markiert sind, sind nur für Aktionen verfügbar RestoreKey.

Gelöschte Schlüssel verbleiben nach dem Löschen 7 Tage lang in Service-Backups. Sie können in diesem Zeitraum nicht wiederhergestellt werden.

Schlüssel, die zu geschlossenen AWS-Konten gehören, sind zum Löschen markiert. Wenn das Konto vor Ablauf der Löschfrist reaktiviert wird, werden alle zum Löschen markierten Schlüssel zwar wiederhergestellt, aber deaktiviert. Sie müssen von Ihnen erneut aktiviert werden, um sie für kryptografische Operationen verwenden zu können.

Protokollierung und Überwachung

Zu den internen Serviceprotokollen gehören:

• CloudTrail Protokolle der vom Service getätigten AWS-Serviceaufrufen

• CloudWatch Protokolle beider Ereignisse werden direkt in CloudWatch Protokollen oder Ereignissen von HSM protokolliert

• Protokolldateien von HSM- und Servicesystemen

• Log-Archive

Alle Protokollquellen überwachen und filtern nach vertraulichen Informationen, einschließlich Informationen zu Schlüsseln. Die Protokolle werden systematisch überprüft, um sicherzustellen, dass sie keine sensiblen Kundeninformationen enthalten.

Der Zugriff auf die Protokolle ist auf Personen beschränkt, die für die Erfüllung von Aufgaben benötigt werden.

Alle Protokolle werden gemäß den AWS-Richtlinien zur Aufbewahrung von Protokollen aufbewahrt.