Interpretieren von HSM-Audit-Prüfprotokollen - AWS CloudHSM
Beispiele für Audit-Protokollereignisse

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.

Interpretieren von HSM-Audit-Prüfprotokollen

Die Ereignisse in den HSM-Audit-Protokollen haben standardisierte Felder. 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.

Beispiel: Das folgende Beispielereignis ist das zweite Ereignis (Sequence No: 0x1) im Protokollstream für ein HSM. Es zeigt, wie das HSM einen Passwort-Verschlüsselungsschlüssel erzeugt, der Teil seiner 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.

Zeit

Die Zeit, zu der das Ereignis in der UTC-Zeitzone aufgetreten ist. Die Zeit wird als menschenlesbare Zeit und Unix-Zeit in Mikrosekunden angezeigt.

Neustart des Zählers

Ein 32-Bit persistenter Ordinalzähler, der beim Neustart der HSM-Hardware erhöht wird.

Alle Ereignisse in einem Protokollstream haben den gleichen Neustartzählerwert. Der Neustartzähler ist jedoch möglicherweise nicht eindeutig für einen Protokollstream, da er sich zwischen verschiedenen HSM-Instances im selben Cluster unterscheiden kann.

Sequenz Nr.

Ein 64-Bit-Ordinalzähler, der bei jedem Protokollereignis erhöht wird. Das erste Ereignis in jedem Protokollstream hat eine Sequenznummer von 0x0. Es dürfen keine Lücken in den Sequence No-Werten vorhanden sein. Die Sequenznummer ist nur in einem Protokollstream eindeutig.

Befehlstyp

Ein hexadezimaler Wert, der die Kategorie des Befehls repräsentiert. Befehle im AWS CloudHSM -Protokollstream haben einen Befehlstyp CN_MGMT_CMD (0x0) oder CN_CERT_AUTH_CMD (0x9).

Opcode

Identifiziert den ausgeführten Verwaltungsbefehl. Eine Liste der Opcode Werte in den AWS CloudHSM Audit-Logs finden Sie unterHSM-Auditprotokoll-Referenz.

Session-Handle

Identifiziert die Sitzung, in der der Befehl ausgeführt und das Ereignis protokolliert wurde.

Antwort

Zeichnet die Antwort auf den Verwaltungsbefehl auf. Sie können das Response-Feld nach den Werten SUCCESS und ERROR durchsuchen.

Protokolltyp

Gibt den Protokolltyp des Protokolls an, in dem AWS CloudHSM der Befehl aufgezeichnet wurde.

  • MINIMAL_LOG_ENTRY (0)

  • MGMT_KEY_DETAILS_LOG (1)

  • MGMT_USER_DETAILS_LOG (2)

  • GENERIC_LOG

Beispiele für Audit-Protokollereignisse

Die Ereignisse in einem Protokollstream zeichnen die Historie des HSM von der Erstellung bis zum Löschen auf. Mit dem Protokoll können Sie den Lebenszyklus Ihrer HSMs überprüfen und sich einen Überblick über deren Betrieb verschaffen. 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 des ersten HSM in einem Cluster

Der Audit-Protokollstream für das erste HSM in jedem Cluster unterscheidet sich erheblich von den Protokollströmen anderer HSMs im Cluster. Das Auditprotokoll für das erste HSM in jedem Cluster zeichnet seine Erstellung und Initialisierung auf. Die Protokolle weiterer HSMs im Cluster, die aus Backups generiert werden, beginnen mit einem Anmeldeereignis.

Wichtig

Die folgenden Initialisierungseinträge werden nicht in den CloudWatch Protokollen von Clustern angezeigt, die vor der Veröffentlichung der CloudHSM-Audit-Logging-Funktion (30. August 2018) initialisiert wurden. Weitere Informationen finden Sie unter Dokumentenhistorie.

Die folgenden Beispielereignisse erscheinen im Protokollstream für den ersten HSM in einem Cluster. Das erste Ereignis im Protokoll – das mit Sequence No 0x0 – entspricht dem Befehl für die Initialisierung des 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 exemplarischen Protokollstream (Sequence No 0x1) zeichnet den Befehl zum Erstellen des Kennwortverschlüsselungsschlüssels auf, den das HSM verwendet (CN_GEN_PSWD_ENC_KEY).

Dies ist eine typische Startsequenz für das erste HSM in jedem Cluster. Da nachfolgende HSMs im gleichen Cluster Klone des ersten sind, verwenden sie den gleichen Passwort-Verschlü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 eines Protokollstreams (Sequence No 0x3) zeichnet das CN_INIT_DONE-Ereignis, das die Initialisierung des HSM abschließt. 

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. Diese Ereignisse können mehrere An- und Abmeldeereignisse und die Generierung des Schlüsselverschlüsselungscodes (Key Encryption Key, KEK) umfassen. Das folgende Ereignis zeichnet den Befehl auf, der das Passwort des Precrypto Officer (PRECO) ändert. 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 die Ereignisse bei der Interpretation Ihres Audit-Protokolls, die das Ein- und Ausloggen von Benutzern in das HSM repräsentieren. 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 HSM anmeldet, zeichnen die anderen HSMs im Cluster auch ein Anmeldeereignis für den Benutzer auf. Die entsprechenden Anmeldeereignisse finden Sie in den Protokollströmen anderer HSMs im Cluster, kurz nach dem ersten Anmeldeereignis. 

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 typischerweise nur von jenem HSM aufgezeichnet, das 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)

Wenn ein Anmeldeversuch fehlschlägt, weil der Benutzername ungültig ist, zeichnet das HSM ein CN_LOGIN-Ereignis mit dem Benutzernamen und -typ im Login-Befehl auf. 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)

Wenn ein Anmeldeversuch fehlschlägt, weil das Passwort ungültig ist, zeichnet das HSM ein CN_LOGIN-Ereignis mit dem Benutzernamen und -typ im Login-Befehl auf. 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 einen CO, admin, bei der Anmeldung im HSM auf. 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 Schlüsselpaar erstellen und löschen.

Das folgende Ereignis zeichnet die Anmeldung des Verschlüsselungsbenutzers (CU, Crypto User) mit Namen crypto_user am HSM auf. 

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 die Löschung 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 Schlüsselerstellung in einem Cluster mit mehreren HSMs. Der Schlüssel wird auf einem HSM erzeugt, aus dem HSM als maskiertes Objekt extrahiert und in den anderen HSMs als maskiertes Objekt eingefügt.

Anmerkung

Die Client-Tools können den Schlüssel möglicherweise nicht synchronisieren. Der Befehl kann außerdem den Parameter min_srv umfassen, der den Schlüssel nur mit der angegebenen Anzahl von HSMs synchronisiert. In beiden Fällen synchronisiert der AWS CloudHSM Dienst den Schlüssel mit den anderen HSMs im Cluster. Da die HSMs nur Client-seitige Verwaltungsbefehle in ihren Protokollen aufzeichnen, wird die serverseitige Synchronisation nicht im HSM-Protokoll aufgezeichnet.

Betrachten Sie zunächst den Protokollstream des HSM, das die Befehle empfängt und ausführt. Der Protokollstream ist nach der HSM-ID, hsm-abcde123456, benannt, aber die HSM-ID erscheint nicht in den Protokollereignissen.

Zunächst meldet sich der testuser-Verschlüsselungsbenutzer (CU, Crypto User) am hsm-abcde123456-HSM an.

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. Das hsm-abcde123456-HSM generiert einen symmetrischen Schlüssel mit dem Schlüssel-Handle 262152. Das HSM vermerkt ein CN_GENERATE_KEY-Ereignis im Protokoll. 

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üssel-Handle 262152) wird aus dem HSM als maskiertes Objekt 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 jetzt den Protokollstream für das HSM hsm-zyxwv987654, ein anderes HSM im selben Cluster. Dieser Protokollstream enthält auch ein Anmelde-Ereignis für den CU testuser. Der Zeitwert zeigt an, dass es kurz nach der Anmeldung des Benutzers am HSM hsm-abcde123456 auftritt.

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 für diese HSM verfügt nicht über ein CN_GENERATE_KEY-Ereignis. Aber es hat ein Ereignis, das die Synchronisation des Schlüssels zu diesem HSM aufzeichnet. Das CN_INSERT_MASKED_OBJECT_USER-Ereignis zeichnet den Empfang des Schlüssels 262152 als maskiertes Objekt auf. Jetzt existiert der Schlüssel 262152 auf beiden HSMs im Cluster.

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 der CU-Benutzer sich abmeldet, wird dieses CN_LOGOUT-Ereignis nur in den Protokollstream jenes HSM aufgenommen, das die Befehle erhalten hat.

Beispiel: Exportieren eines Schlüssels

Dieses Beispiel zeigt die Audit-Protokoll-Ereignisse, die aufgezeichnet werden, wenn ein Verschlüsselungsbenutzer (CU, Crypto User) Schlüssel aus einem Cluster mit mehreren HSMs exportiert.

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üssels aus7, einen 256-Bit-AES-Schlüssel. Der Befehl verwendet den Schlüssel 6, ein 256-Bit-AES-Schlüssel in den HSMs, als Verpackungsschlüssel.

Das HSM, das den Befehl empfängt, vermerkt ein CN_WRAP_KEY-Ereignis für den Schlüssel 7, 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

Anschließend verzeichnet das HSM ein CN_NIST_AES_WRAP-Ereignis für den Verpackungsschlüssel 6. Der Schlüssel wird verpackt und anschließend sofort wieder entpackt, aber der HSM zeichnet nur ein Ereignis auf.

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 aber nicht den Schlüssel auf dem HSM. Daher gibt es keine entsprechenden Ereignisse in den Protokollen der anderen HSMs im Cluster.

Beispiel: Importieren eines Schlüssels

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

Das HSM, das den Befehl empfängt, vermerkt ein CN_NIST_AES_WRAP-Ereignis für den Schlüssel 6, den Verpackungsschlüssel. 

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

Anschließend verzeichnet das HSM ein CN_UNWRAP_KEY-Ereignis für den Importvorgang. 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 anderen HSMs im Cluster zu synchronisieren. In diesem Fall zeichnet das HSM ein CN_EXTRACT_MASKED_OBJECT_USER-Ereignis auf, wenn der Schlüssel 11 aus dem HSM als maskiertes Objekt extrahiert 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 Protokollströme anderer HSMs im Cluster spiegeln die Ankunft des neu importierten Schlüssels wider.

Dieses Ereignis wurde beispielsweise im Protokollstream eines anderen HSM im gleichen 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 Prüfprotokollereignis, das aufgezeichnet wird, wenn ein CU den privaten ECC-Schlüssel für andere CUs freigibt oder die Freigabe aufhebt. Der CU verwendet den Befehl shareKey und stellt das Schlüssel-Handle, die Benutzer-ID und den Wert 1 zur Verfügung, um den Schlüssel freizugeben oder den Wert 0, um die Freigabe aufzuheben.

Im folgenden Beispiel zeichnet der HSM, der den Befehl empfängt, ein CM_SHARE_OBJECT-Ereignis auf. Dieses Ereignis repräsentiert den Vorgang der Freigabe.

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)