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 Audit-Logs
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 unter[AWS CloudHSM Referenz zum Auditprotokoll](cloudhsm-audit-log-reference.md).
**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. Sie können das Protokoll verwenden, um den Lebenszyklus Ihres Computers 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.
**Topics**
+ [Beispiel: Initialisieren des ersten HSM in einem Cluster](#example-audit-log-first-hsm)
+ [An- und Abmeldeereignisse](#example-audit-log-login-logout)
+ [Beispiel: Erstellen und Löschen von Benutzern](#example-audit-log-first-hsm)
+ [Beispiel: Erstellen und Löschen eines Schlüsselpaares](#example-audit-log-manage-keys)
+ [Beispiel: Generieren und Synchronisieren eines Schlüssels](#audit-log-example-gen-key)
+ [Beispiel: Exportieren eines Schlüssels](#audit-log-example-export-key)
+ [Beispiel: Importieren eines Schlüssels](#audit-log-example-import-key)
+ [Beispiel: Freigeben eines Schlüssels und Aufheben der Freigabe](#audit-log-example-share-unshare-key)
### Beispiel: Initialisieren des ersten HSM in einem Cluster
Der Audit-Log-Stream für das erste HSM in jedem Cluster unterscheidet sich erheblich von den Log-Streams anderer HSMs HSMs im Cluster. Das Auditprotokoll für das erste HSM in jedem Cluster zeichnet seine Erstellung und Initialisierung auf. Die Protokolle der weiteren Mitglieder HSMs des Clusters, 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](document-history.md).
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 sich HSMs im selben Cluster nacheinander 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)](understanding-users-cmu.md#appliance-user-cmu). 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)](understanding-users-cmu.md#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, 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 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 Erstellung eines Schlüssels in einem Cluster mit mehreren HSMs. Der Schlüssel wird auf einem HSM generiert, als maskiertes Objekt aus dem HSM extrahiert und in das andere HSMs als maskiertes Objekt eingefügt.
**Anmerkung**
Die Client-Tools können den Schlüssel möglicherweise nicht synchronisieren. Oder der Befehl könnte den **min\_srv** Parameter enthalten, der den Schlüssel nur mit der angegebenen Anzahl von synchronisiert. HSMs In beiden Fällen synchronisiert der AWS CloudHSM Dienst den Schlüssel mit dem anderen Schlüssel HSMs im Cluster. Da sie nur clientseitige Verwaltungsbefehle in ihren Protokollen HSMs 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 [exSymKey](key_mgmt_util-genSymKey.md)Befehl 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 ist der Schlüssel für beide HSMs im Cluster `262152` 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 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 Auditprotokollereignisse, die aufgezeichnet werden, wenn ein Krypto-Benutzer (CU) Schlüssel aus einem Cluster mit mehreren exportiert HSMs.
Das folgende Ereignis zeichnet die CU (`testuser`)-Anmeldung bei [key\_mgmt\_util](key_mgmt_util.md) 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 [exSymKey](key_mgmt_util-exSymKey.md)Befehl zum Exportieren eines Schlüssels aus`7`, eines 256-Bit-AES-Schlüssels. Der Befehl verwendet den Schlüssel`6`, einen 256-Bit-AES-Schlüssel auf dem HSMs, als Umschließungsschlü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. Folglich gibt es keine entsprechenden Ereignisse in den Protokollen anderer Mitglieder des HSMs 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 [imSymKey](key_mgmt_util-imSymKey.md)Befehl, um einen AES-Schlüssel in den zu importieren HSMs. 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 HSMs einem anderen Schlüssel 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 Protokolldatenströme anderer Benutzer HSMs im Cluster spiegeln den Eingang 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](cloudhsm_mgmt_util-shareKey.md) 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)
```