Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Interpretation von AWS CloudHSM Auditprotokollen

Die Ereignisse in den HSM Audit-Logs haben Standardfelder. Einige Ereignistypen umfassen weitere Felder, die nützliche Informationen über das Ereignis aufzeichnen. Beispiel: Benutzeranmeldungs- und Benutzerverwaltungsereignisse enthalten den Benutzernamen und Typ des Benutzers. Key-Management-Befehle enthalten das Schlüssel-Handle.

Einige der Felder liefern besonders wichtige Informationen. Opcode identifiziert den Verwaltungsbefehl, der aufgezeichnet wird. Sequence No identifiziert ein Ereignis im Protokollstream und gibt die Reihenfolge an, in der es aufgenommen wurde.

Das folgende Beispielereignis ist beispielsweise das zweite Ereignis (Sequence No: 0x1) im Protokollstream für einHSM. Es zeigt die HSM Generierung eines Kennwort-Verschlüsselungsschlüssels, was Teil der Startroutine ist.

Time: 12/19/17 21:01:17.140812, usecs:1513717277140812
Sequence No : 0x1
Reboot counter : 0xe8
Command Type(hex) : CN_MGMT_CMD (0x0)
Opcode : CN_GEN_PSWD_ENC_KEY (0x1d)
Session Handle : 0x1004001
Response : 0:HSM Return: SUCCESS
Log type : MINIMAL_LOG_ENTRY (0)

Die folgenden Felder sind allen AWS CloudHSM Ereignissen im Auditprotokoll gemeinsam.

Beispiele für Audit-Protokollereignisse

Die Ereignisse in einem Protokollstream zeichnen den Verlauf HSM von der Erstellung bis zur Löschung auf. Sie können das Protokoll verwenden, um den Lebenszyklus Ihres Systems zu überprüfen HSMs und Einblicke in dessen Betrieb zu erhalten. Wenn Sie die Ereignisse interpretieren, beachten Sie den Opcode, der den Befehl oder die Aktion zur Verwaltung anzeigt, und die Sequence No, die die Reihenfolge der Ereignisse angibt.

Beispiel: Initialisieren Sie das erste HSM in einem Cluster

Der Audit-Log-Stream für den ersten HSM in jedem Cluster unterscheidet sich erheblich von den Log-Streams der anderen HSMs im Cluster. Das Auditprotokoll für den ersten HSM in jedem Cluster zeichnet dessen Erstellung und Initialisierung auf. Die aus Backups generierten Protokolle der weiteren HSMs Mitglieder des Clusters beginnen mit einem Anmeldeereignis.

Die folgenden Beispielereignisse werden im Protokollstream für die ersten Ereignisse HSM in einem Cluster angezeigt. Das erste Ereignis im Protokoll — das mit Sequence No 0x0 — steht für den Befehl zur Initialisierung von HSM (CN_INIT_TOKEN). Die Antwort (Response : 0: HSM Return: SUCCESS) zeigt an, dass der Befehl erfolgreich war.

Time: 12/19/17 21:01:16.962174, usecs:1513717276962174
Sequence No : 0x0
Reboot counter : 0xe8
Command Type(hex) : CN_MGMT_CMD (0x0)
Opcode : CN_INIT_TOKEN (0x1)
Session Handle : 0x1004001
Response : 0:HSM Return: SUCCESS
Log type : MINIMAL_LOG_ENTRY (0)

Das zweite Ereignis in diesem Beispiel log stream (Sequence No 0x1) zeichnet den Befehl zur Erstellung des Kennwortverschlüsselungsschlüssels auf, den der HSM verwendet (CN_GEN_PSWD_ENC_KEY).

Dies ist eine typische Startsequenz für den ersten Start HSM in jedem Cluster. Da sich HSMs im selben Cluster jeweils Klone des ersten Clusters befinden, verwenden sie denselben Kennwortverschlüsselungsschlüssel.

Time: 12/19/17 21:01:17.140812, usecs:1513717277140812
Sequence No : 0x1
Reboot counter : 0xe8
Command Type(hex) : CN_MGMT_CMD (0x0)
Opcode : CN_GEN_PSWD_ENC_KEY (0x1d)
Session Handle : 0x1004001
Response : 0:HSM Return: SUCCESS
Log type : MINIMAL_LOG_ENTRY (0)

Das dritte Ereignis in diesem beispielhaften Protokollstream (Sequence No 0x2) ist die Erstellung des Benutzers Appliance-Benutzer (AU). Dabei handelt es sich um den AWS CloudHSM -Service. Ereignisse, an denen HSM Benutzer beteiligt sind, enthalten zusätzliche Felder für den Benutzernamen und den Benutzertyp.

Time: 12/19/17 21:01:17.174902, usecs:1513717277174902
Sequence No : 0x2
Reboot counter : 0xe8
Command Type(hex) : CN_MGMT_CMD (0x0)
Opcode : CN_CREATE_APPLIANCE_USER (0xfc)
Session Handle : 0x1004001
Response : 0:HSM Return: SUCCESS
Log type : MGMT_USER_DETAILS_LOG (2)
User Name : app_user
User Type : CN_APPLIANCE_USER (5)

Das vierte Ereignis in diesem Beispiel log stream (Sequence No 0x3) zeichnet das CN_INIT_DONE Ereignis auf, wodurch die Initialisierung von abgeschlossen wirdHSM.

Time: 12/19/17 21:01:17.298914, usecs:1513717277298914
Sequence No : 0x3
Reboot counter : 0xe8
Command Type(hex) : CN_MGMT_CMD (0x0)
Opcode : CN_INIT_DONE (0x95)
Session Handle : 0x1004001
Response : 0:HSM Return: SUCCESS
Log type : MINIMAL_LOG_ENTRY (0)

Sie können den verbleibenden Ereignissen in der Startsequenz folgen. Zu diesen Ereignissen können mehrere An- und Abmeldeereignisse sowie die Generierung des Schlüsselverschlüsselungsschlüssels () KEK gehören. Das folgende Ereignis zeichnet den Befehl auf, mit dem das Passwort des Precrypto-Officers () PRECO geändert wird. Dieser Befehl aktiviert den Cluster.

Time: 12/13/17 23:04:33.846554, usecs:1513206273846554
Sequence No: 0x1d
Reboot counter: 0xe8
Command Type(hex): CN_MGMT_CMD (0x0)
Opcode: CN_CHANGE_PSWD (0x9)
Session Handle: 0x2010003
Response: 0:HSM Return: SUCCESS
Log type: MGMT_USER_DETAILS_LOG (2)
User Name: admin
User Type: CN_CRYPTO_PRE_OFFICER (6)

An- und Abmeldeereignisse

Beachten Sie bei der Interpretation Ihres Auditprotokolls Ereignisse, die das An- und Abmelden von Benutzern aufzeichnen. HSM Diese Ereignisse helfen Ihnen zu bestimmen, welcher Benutzer für die Verwaltungsbefehle verantwortlich ist, die in der Reihenfolge zwischen dem Anmelde- und dem Abmeldebefehl erscheinen.

Dieser Protokolleintrag zeichnet beispielsweise eine Anmeldung durch einen Verschlüsselungsverantwortlichen mit dem Namen admin auf. Die Sequenznummer, 0x0, gibt an, dass dies das erste Ereignis in diesem Protokollstream ist.

Wenn sich ein Benutzer bei einem anmeldetHSM, zeichnet der andere Benutzer HSMs im Cluster ebenfalls ein Anmeldeereignis für den Benutzer auf. Sie finden die entsprechenden Anmeldeereignisse kurz nach dem ersten Anmeldeereignis HSMs in den Protokolldatenströmen anderer Benutzer im Cluster.

Time: 01/16/18 01:48:49.824999, usecs:1516067329824999
Sequence No : 0x0
Reboot counter : 0x107
Command Type(hex) : CN_MGMT_CMD (0x0)
Opcode : CN_LOGIN (0xd)
Session Handle : 0x7014006
Response : 0:HSM Return: SUCCESS
Log type : MGMT_USER_DETAILS_LOG (2)
User Name : admin
User Type : CN_CRYPTO_OFFICER (2)

Das folgende Beispielereignis zeichnet den admin-Verschlüsselungsverantwortlichen auf, der sich abmeldet. Die Sequenznummer, 0x2, gibt an, dass dies das dritte Ereignis im Protokollstream ist.

Wenn der angemeldete Benutzer die Sitzung schließt, ohne sich abzumelden, enthält der Protokollstream ein CN_APP_FINALIZE-Ereignis oder ein Ereignis für das Schließen der Sitzung (CN_SESSION_CLOSE), anstelle eines CN_LOGOUT-Ereignisses. Im Gegensatz zum Anmeldeereignis wird dieses Abmeldeereignis in der Regel nur von demjenigen aufgezeichnetHSM, der den Befehl ausführt.

Time: 01/16/18 01:49:55.993404, usecs:1516067395993404
Sequence No : 0x2
Reboot counter : 0x107
Command Type(hex) : CN_MGMT_CMD (0x0)
Opcode : CN_LOGOUT (0xe)
Session Handle : 0x7014000
Response : 0:HSM Return: SUCCESS
Log type : MGMT_USER_DETAILS_LOG (2)
User Name : admin
User Type : CN_CRYPTO_OFFICER (2)

Schlägt ein Anmeldeversuch fehl, weil der Benutzername ungültig ist, wird ein CN_LOGIN Ereignis mit dem im Anmeldebefehl angegebenen Benutzernamen und Typ HSM aufgezeichnet. Die Antwort zeigt die Fehlermeldung 157, die erläutert, dass der Benutzername nicht vorhanden ist.

Time: 01/24/18 17:41:39.037255, usecs:1516815699037255
Sequence No : 0x4
Reboot counter : 0x107
Command Type(hex) : CN_MGMT_CMD (0x0)
Opcode : CN_LOGIN (0xd)
Session Handle : 0xc008002
Response : 157:HSM Error: user isn't initialized or user with this name doesn't exist
Log type : MGMT_USER_DETAILS_LOG (2)
User Name : ExampleUser
User Type : CN_CRYPTO_USER (1)

Schlägt ein Anmeldeversuch fehl, weil das Passwort ungültig ist, wird ein CN_LOGIN Ereignis mit dem im Anmeldebefehl angegebenen Benutzernamen und Typ HSM aufgezeichnet. Die Antwort zeigt die Fehlermeldung mit dem RET_USER_LOGIN_FAILURE-Fehlercode.

Time: 01/24/18 17:44:25.013218, usecs:1516815865013218
Sequence No : 0x5
Reboot counter : 0x107
Command Type(hex) : CN_MGMT_CMD (0x0)
Opcode : CN_LOGIN (0xd)
Session Handle : 0xc008002
Response : 163:HSM Error: RET_USER_LOGIN_FAILURE
Log type : MGMT_USER_DETAILS_LOG (2)
User Name : testuser
User Type : CN_CRYPTO_USER (1)

Beispiel: Erstellen und Löschen von Benutzern

Dieses Beispiel zeigt die Protokollereignisse, die aufgezeichnet werden, wenn ein Verschlüsselungsverantwortlicher (CO) Benutzer anlegt und löscht.

Das erste Ereignis zeichnet ein CO aufadmin, das sich beim anmeldetHSM. Die Sequenznummer, 0x0, gibt an, dass dies das erste Ereignis im Protokollstream ist. Der Name und Typ des Benutzers, der sich anmeldet, sind im Ereignis enthalten.

Time: 01/16/18 01:48:49.824999, usecs:1516067329824999
Sequence No : 0x0
Reboot counter : 0x107
Command Type(hex) : CN_MGMT_CMD (0x0)
Opcode : CN_LOGIN (0xd)
Session Handle : 0x7014006
Response : 0:HSM Return: SUCCESS
Log type : MGMT_USER_DETAILS_LOG (2)
User Name : admin
User Type : CN_CRYPTO_OFFICER (2)

Das nächste Ereignis im Protokollstream (Sequenz 0x1) zeichnet die Erstellung eines neuen Verschlüsselungsbenutzers (CU, Crypto-User) durch den CO auf. Der Name und Typ des neuen Benutzers sind im Ereignis enthalten.

Time: 01/16/18 01:49:39.437708, usecs:1516067379437708
Sequence No : 0x1
Reboot counter : 0x107
Command Type(hex) : CN_MGMT_CMD (0x0)
Opcode : CN_CREATE_USER (0x3)
Session Handle : 0x7014006
Response : 0:HSM Return: SUCCESS
Log type : MGMT_USER_DETAILS_LOG (2)
User Name : bob
User Type : CN_CRYPTO_USER (1)

Dann erstellt der CO einen anderen Verschlüsselungsverantwortlichen, alice. Die Sequenznummer zeigt an, dass diese Aktion der vorherigen ohne dazwischenliegende Aktionen folgte.

Time: 01/16/18 01:49:55.993404, usecs:1516067395993404
Sequence No : 0x2
Reboot counter : 0x107
Command Type(hex) : CN_MGMT_CMD (0x0)
Opcode : CN_CREATE_CO (0x4)
Session Handle : 0x7014007
Response : 0:HSM Return: SUCCESS
Log type : MGMT_USER_DETAILS_LOG (2)
User Name : alice
User Type : CN_CRYPTO_OFFICER (2)

Später meldet sich der CO mit Namen admin an und löscht den Verschlüsselungsverantwortlichen mit Namen alice. Das HSM zeichnet ein CN_DELETE_USER Ereignis auf. Der Name und Typ des gelöschten Benutzers sind im Ereignis enthalten.

Time: 01/23/18 19:58:23.451420, usecs:1516737503451420
Sequence No : 0xb
Reboot counter : 0x107
Command Type(hex) : CN_MGMT_CMD (0x0)
Opcode : CN_DELETE_USER (0xa1)
Session Handle : 0x7014007
Response : 0:HSM Return: SUCCESS
Log type : MGMT_USER_DETAILS_LOG (2)
User Name : alice
User Type : CN_CRYPTO_OFFICER (2)

Beispiel: Erstellen und Löschen eines Schlüsselpaares

Dieses Beispiel zeigt die Ereignisse, die in einem HSM Auditprotokoll aufgezeichnet werden, wenn Sie ein key pair erstellen und löschen.

Das folgende Ereignis zeichnet den Crypto-Benutzer (CU) mit dem Namen auf, der crypto_user sich bei der anmeldetHSM.

Time: 12/13/17 23:09:04.648952, usecs:1513206544648952
Sequence No: 0x28
Reboot counter: 0xe8
Command Type(hex): CN_MGMT_CMD (0x0)
Opcode: CN_LOGIN (0xd)
Session Handle: 0x2014005
Response: 0:HSM Return: SUCCESS
Log type: MGMT_USER_DETAILS_LOG (2)
User Name: crypto_user
User Type: CN_CRYPTO_USER (1)

Anschließend erzeugt der CU ein Schlüsselpaar (CN_GENERATE_KEY_PAIR). Das Schlüssel-Handle des privaten Schlüssels ist 131079. Das Schlüssel-Handle des öffentlichen Schlüssels ist 131078.

Time: 12/13/17 23:09:04.761594, usecs:1513206544761594
Sequence No: 0x29
Reboot counter: 0xe8
Command Type(hex): CN_MGMT_CMD (0x0)
Opcode: CN_GENERATE_KEY_PAIR (0x19)
Session Handle: 0x2014004
Response: 0:HSM Return: SUCCESS
Log type: MGMT_KEY_DETAILS_LOG (1)
Priv/Secret Key Handle: 131079
Public Key Handle: 131078

Der CU löscht das Schlüsselpaar sofort wieder. Ein CN_ DESTROY _ OBJECT -Ereignis zeichnet das Löschen des öffentlichen Schlüssels (131078) auf.

Time: 12/13/17 23:09:04.813977, usecs:1513206544813977
Sequence No: 0x2a
Reboot counter: 0xe8
Command Type(hex): CN_MGMT_CMD (0x0)
Opcode: CN_DESTROY_OBJECT (0x11)
Session Handle: 0x2014004
Response: 0:HSM Return: SUCCESS
Log type: MGMT_KEY_DETAILS_LOG (1)
Priv/Secret Key Handle: 131078
Public Key Handle: 0

Anschließend zeichnet ein zweites CN_DESTROY_OBJECT-Ereignis die Löschung des privaten Schlüssels (131079) auf.

Time: 12/13/17 23:09:04.815530, usecs:1513206544815530
Sequence No: 0x2b
Reboot counter: 0xe8
Command Type(hex): CN_MGMT_CMD (0x0)
Opcode: CN_DESTROY_OBJECT (0x11)
Session Handle: 0x2014004
Response: 0:HSM Return: SUCCESS
Log type: MGMT_KEY_DETAILS_LOG (1)
Priv/Secret Key Handle: 131079
Public Key Handle: 0

Und schließlich meldet sich der CU ab.

Time: 12/13/17 23:09:04.817222, usecs:1513206544817222
Sequence No: 0x2c
Reboot counter: 0xe8
Command Type(hex): CN_MGMT_CMD (0x0)
Opcode: CN_LOGOUT (0xe)
Session Handle: 0x2014004
Response: 0:HSM Return: SUCCESS
Log type: MGMT_USER_DETAILS_LOG (2)
User Name: crypto_user
User Type: CN_CRYPTO_USER (1)

Beispiel: Generieren und Synchronisieren eines Schlüssels

Dieses Beispiel zeigt den Effekt der Erstellung eines Schlüssels in einem Cluster mit mehreren. HSMs Der Schlüssel wird auf einem Objekt generiertHSM, HSM als maskiertes Objekt aus dem extrahiert und in das andere Objekt HSMs als maskiertes Objekt eingefügt.

Betrachten Sie zunächst den Protokolldatenstrom vonHSM, der die Befehle empfängt und ausführt. Der Protokollstream ist nach der HSM ID benannthsm-abcde123456, die HSM ID erscheint jedoch nicht in den Protokollereignissen.

Zunächst meldet sich der testuser Crypto-Benutzer (CU) bei der an hsm-abcde123456HSM.

Time: 01/24/18 00:39:23.172777, usecs:1516754363172777
Sequence No : 0x0
Reboot counter : 0x107
Command Type(hex) : CN_MGMT_CMD (0x0)
Opcode : CN_LOGIN (0xd)
Session Handle : 0xc008002
Response : 0:HSM Return: SUCCESS
Log type : MGMT_USER_DETAILS_LOG (2)
User Name : testuser
User Type : CN_CRYPTO_USER (1)

Die CU führt einen exSymKeyBefehl aus, um einen symmetrischen Schlüssel zu generieren. Der hsm-abcde123456 HSM generiert einen symmetrischen Schlüssel mit einem Tastenkürzel von. 262152 Der HSM zeichnet ein CN_GENERATE_KEY Ereignis in seinem Protokoll auf.

Time: 01/24/18 00:39:30.328334, usecs:1516754370328334
Sequence No : 0x1
Reboot counter : 0x107
Command Type(hex) : CN_MGMT_CMD (0x0)
Opcode : CN_GENERATE_KEY (0x17)
Session Handle : 0xc008004
Response : 0:HSM Return: SUCCESS
Log type : MGMT_KEY_DETAILS_LOG (1)
Priv/Secret Key Handle : 262152
Public Key Handle : 0

Das nächste Ereignis im Protokollstream für hsm-abcde123456 zeichnet den ersten Schritt im Schlüssel-Synchronisationsprozess auf. Der neue Schlüssel (Schlüsselname262152) wird HSM als maskiertes Objekt aus dem extrahiert.

Time: 01/24/18 00:39:30.330956, usecs:1516754370330956
Sequence No : 0x2
Reboot counter : 0x107
Command Type(hex) : CN_MGMT_CMD (0x0)
Opcode : CN_EXTRACT_MASKED_OBJECT_USER (0xf0)
Session Handle : 0xc008004
Response : 0:HSM Return: SUCCESS
Log type : MGMT_KEY_DETAILS_LOG (1)
Priv/Secret Key Handle : 262152
Public Key Handle : 0

Betrachten Sie nun den Log-Stream für HSM hsm-zyxwv987654 einen anderen HSM im selben Cluster. Dieser Protokollstream enthält auch ein Anmelde-Ereignis für den CU testuser. Der Zeitwert zeigt, dass dies kurz nach der Anmeldung des Benutzers bei der der Fall ist hsm-abcde123456HSM.

Time: 01/24/18 00:39:23.199740, usecs:1516754363199740
Sequence No : 0xd
Reboot counter : 0x107
Command Type(hex) : CN_MGMT_CMD (0x0)
Opcode : CN_LOGIN (0xd)
Session Handle : 0x7004004
Response : 0:HSM Return: SUCCESS
Log type : MGMT_USER_DETAILS_LOG (2)
User Name : testuser
User Type : CN_CRYPTO_USER (1)

Dieser Protokollstream HSM hat dafür kein CN_GENERATE_KEY Ereignis. Es gibt jedoch ein Ereignis, das die Synchronisation des Schlüssels aufzeichnetHSM. Das CN_INSERT_MASKED_OBJECT_USER-Ereignis zeichnet den Empfang des Schlüssels 262152 als maskiertes Objekt auf. Jetzt 262152 ist der Schlüssel für beide HSMs im Cluster vorhanden.

Time: 01/24/18 00:39:30.408950, usecs:1516754370408950
Sequence No : 0xe
Reboot counter : 0x107
Command Type(hex) : CN_MGMT_CMD (0x0)
Opcode : CN_INSERT_MASKED_OBJECT_USER (0xf1)
Session Handle : 0x7004003
Response : 0:HSM Return: SUCCESS
Log type : MGMT_KEY_DETAILS_LOG (1)
Priv/Secret Key Handle : 262152
Public Key Handle : 0

Wenn sich der CU-Benutzer abmeldet, erscheint dieses CN_LOGOUT Ereignis nur im Protokollstream desjenigenHSM, der die Befehle empfangen hat.

Beispiel: Exportieren eines Schlüssels

Dieses Beispiel zeigt die Auditprotokollereignisse, die aufgezeichnet werden, wenn ein Crypto-Benutzer (CU) Schlüssel aus einem Cluster mit mehreren exportiertHSMs.

Das folgende Ereignis zeichnet die CU (testuser)-Anmeldung bei key_mgmt_util auf.

Time: 01/24/18 19:42:22.695884, usecs:1516822942695884
Sequence No : 0x26
Reboot counter : 0x107
Command Type(hex) : CN_MGMT_CMD (0x0)
Opcode : CN_LOGIN (0xd)
Session Handle : 0x7004004
Response : 0:HSM Return: SUCCESS
Log type : MGMT_USER_DETAILS_LOG (2)
User Name : testuser
User Type : CN_CRYPTO_USER (1)

Die CU führt einen exSymKeyBefehl zum Exportieren eines Schlüssels7, eines AES 256-Bit-Schlüssels, aus. Der Befehl verwendet den Schlüssel6, einen AES 256-Bit-Schlüssel auf demHSMs, als Umbruchschlüssel.

Derjenige, der den Befehl empfängtHSM, zeichnet ein CN_WRAP_KEY Ereignis für den Schlüssel auf7, d. h. den Schlüssel, der exportiert wird.

Time: 01/24/18 19:51:12.860123, usecs:1516823472860123
Sequence No : 0x27
Reboot counter : 0x107
Command Type(hex) : CN_MGMT_CMD (0x0)
Opcode : CN_WRAP_KEY (0x1a)
Session Handle : 0x7004003
Response : 0:HSM Return: SUCCESS
Log type : MGMT_KEY_DETAILS_LOG (1)
Priv/Secret Key Handle : 7
Public Key Handle : 0

Dann HSM zeichnet er ein CN_NIST_AES_WRAP Ereignis für den Wrapping-Schlüssel auf6. Der Schlüssel wird umhüllt und dann sofort wieder entpackt, aber es wird nur ein Ereignis HSM aufgezeichnet.

Time: 01/24/18 19:51:12.905257, usecs:1516823472905257
Sequence No : 0x28
Reboot counter : 0x107
Command Type(hex) : CN_MGMT_CMD (0x0)
Opcode : CN_NIST_AES_WRAP (0x1e)
Session Handle : 0x7004003
Response : 0:HSM Return: SUCCESS
Log type : MGMT_KEY_DETAILS_LOG (1)
Priv/Secret Key Handle : 6
Public Key Handle : 0

Der exSymKey Befehl schreibt den exportierten Schlüssel in eine Datei, ändert jedoch nicht den Schlüssel auf derHSM. Folglich gibt es keine entsprechenden Ereignisse in den Protokollen anderer Mitglieder HSMs des Clusters.

Beispiel: Importieren eines Schlüssels

Dieses Beispiel zeigt die Auditprotokollereignisse, die aufgezeichnet werden, wenn Sie Schlüssel HSMs in einen Cluster importieren. In diesem Beispiel verwendet der Crypto-Benutzer (CU) den imSymKeyBefehl, um einen AES Schlüssel in den zu importierenHSMs. Der Befehl verwendet Schlüssel 6 als Verpackungsschlüssel.

Derjenige, der die Befehle empfängtHSM, zeichnet zuerst ein CN_NIST_AES_WRAP Ereignis für den Schlüssel auf6, den Wrapping Key.

Time: 01/24/18 19:58:23.170518, usecs:1516823903170518
Sequence No : 0x29
Reboot counter : 0x107
Command Type(hex) : CN_MGMT_CMD (0x0)
Opcode : CN_NIST_AES_WRAP (0x1e)
Session Handle : 0x7004003
Response : 0:HSM Return: SUCCESS
Log type : MGMT_KEY_DETAILS_LOG (1)
Priv/Secret Key Handle : 6
Public Key Handle : 0

Dann HSM zeichnet er ein CN_UNWRAP_KEY Ereignis auf, das den Importvorgang darstellt. Der importierte Schlüssel ist dem Schlüssel-Handle 11 zugeordnet.

Time: 01/24/18 19:58:23.200711, usecs:1516823903200711
Sequence No : 0x2a
Reboot counter : 0x107
Command Type(hex) : CN_MGMT_CMD (0x0)
Opcode : CN_UNWRAP_KEY (0x1b)
Session Handle : 0x7004003
Response : 0:HSM Return: SUCCESS
Log type : MGMT_KEY_DETAILS_LOG (1)
Priv/Secret Key Handle : 11
Public Key Handle : 0

Wenn ein neuer Schlüssel generiert oder importiert wird, versuchen die Client-Tools automatisch, den neuen Schlüssel mit HSMs einem anderen Schlüssel im Cluster zu synchronisieren. In diesem Fall HSM zeichnet er ein CN_EXTRACT_MASKED_OBJECT_USER Ereignis auf, wenn der Schlüssel HSM als maskiertes Objekt aus dem extrahiert 11 wird.

Time: 01/24/18 19:58:23.203350, usecs:1516823903203350
Sequence No : 0x2b
Reboot counter : 0x107
Command Type(hex) : CN_MGMT_CMD (0x0)
Opcode : CN_EXTRACT_MASKED_OBJECT_USER (0xf0)
Session Handle : 0x7004003
Response : 0:HSM Return: SUCCESS
Log type : MGMT_KEY_DETAILS_LOG (1)
Priv/Secret Key Handle : 11
Public Key Handle : 0

Die Protokolldatenströme anderer Benutzer HSMs im Cluster spiegeln die Ankunft des neu importierten Schlüssels wider.

Dieses Ereignis wurde beispielsweise im Protokollstream eines anderen Ereignisses HSM im selben Cluster aufgezeichnet. Dieses CN_INSERT_MASKED_OBJECT_USER-Ereignis zeichnet die Ankunft eines maskierten Objekts auf, das den Schlüssel 11 darstellt.

Time: 01/24/18 19:58:23.286793, usecs:1516823903286793
Sequence No : 0xb
Reboot counter : 0x107
Command Type(hex) : CN_MGMT_CMD (0x0)
Opcode : CN_INSERT_MASKED_OBJECT_USER (0xf1)
Session Handle : 0xc008004
Response : 0:HSM Return: SUCCESS
Log type : MGMT_KEY_DETAILS_LOG (1)
Priv/Secret Key Handle : 11
Public Key Handle : 0

Beispiel: Freigeben eines Schlüssels und Aufheben der Freigabe

Dieses Beispiel zeigt das Auditprotokollereignis, das aufgezeichnet wird, wenn ein Krypto-Benutzer (CU) seinen ECC privaten Schlüssel mit anderen Krypto-Benutzern teilt oder nicht teilt. Die CU verwendet den shareKeyBefehl und gibt das Schlüssel-Handle, die Benutzer-ID und den Wert an, der geteilt werden 1 soll, oder den Wert, mit dem die gemeinsame Nutzung des Schlüssels aufgehoben werden 0 soll.

Im folgenden Beispiel zeichnet die Person, HSM die den Befehl empfängt, ein CM_SHARE_OBJECT Ereignis auf, das den Vorgang „Teilen“ darstellt.

Time: 02/08/19 19:35:39.480168, usecs:1549654539480168
Sequence No	: 0x3f
Reboot counter	: 0x38
Command Type(hex)	: CN_MGMT_CMD (0x0)
Opcode	: CN_SHARE_OBJECT (0x12)
Session Handle	: 0x3014007
Response	: 0:HSM Return: SUCCESS
Log type	: UNKNOWN_LOG_TYPE (5)