Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Interprétation AWS CloudHSM des journaux d'audit
Les événements des journaux d'audit de HSM ont des champs standard. Certains types d'événement ont des champs supplémentaires qui capturent des informations utiles sur l'événement. Par exemple, les événements de connexion utilisateur et de gestion des utilisateurs incluent le nom de l'utilisateur et le type d'utilisateur de l'utilisateur. Les commandes de gestion de clé incluent le handle de la clé.
Plusieurs des champs fournissent des informations particulièrement importantes. Le champ `Opcode` identifie la commande de gestion qui est en cours d'enregistrement. La `Sequence No` identifie un événement dans le flux de journaux et indique l'ordre dans lequel il a été enregistré.
Par exemple, l'exemple d'événement suivant est le deuxième événement (`Sequence No: 0x1`) dans le flux de journal pour un HSM. Il indique le HSM qui génère un mot de passe clé de chiffrement, ce qui fait partie de sa routine de démarrage.
```
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)
```
Les champs suivants sont communs à tous les AWS CloudHSM événements du journal d'audit.
**Heure**
Heure à la laquelle l'événement s'est produit dans le fuseau horaire UTC. L'heure est affichée dans un format compréhensible par les utilisateurs et au format d'heure Unix en microsecondes.
**Reboot counter (Compteur de redémarrages)**
Compteur ordinal 32 bits persistant, incrémenté quand le matériel HSM est redémarré.
Tous les événements d'un flux de journaux ont la même valeur de compteur de redémarrages. Toutefois, le compteur de redémarrages peut ne pas être unique pour un flux de journaux, car il peut varier entre les différentes instances HSM dans le même cluster.
**Sequence No (N° de séquence)**
Compteur ordinal 64 bits incrémenté pour chaque événement de journal. Le premier événement de chaque flux de journaux a le numéro de séquence 0x0. Il ne doit y avoir aucun écart dans les valeurs `Sequence No`. Le numéro de séquence est unique au sein d'un flux de journaux uniquement.
**Command type (Type de commande)**
Valeur hexadécimale qui représente la catégorie de la commande. Les commandes dans les flux de journaux AWS CloudHSM ont un type de commande `CN_MGMT_CMD` (0x0) ou `CN_CERT_AUTH_CMD` (0x9).
**Opcode (Code d'opération)**
Identifie la commande de gestion qui a été exécutée. Pour obtenir la liste des `Opcode` valeurs figurant dans les journaux AWS CloudHSM d'audit, consultez[AWS CloudHSM référence du journal d'audit](cloudhsm-audit-log-reference.md).
**Session handle (Handle de session)**
Identifie la session dans laquelle la commande a été exécutée et l'événement a été consigné.
**Réponse**
Enregistre la réponse à la commande de gestion. Vous pouvez rechercher les valeurs `SUCCESS` et `ERROR` dans le champ `Response`.
**Type de journal**
Indique le type de AWS CloudHSM journal du journal qui a enregistré la commande.
+ `MINIMAL_LOG_ENTRY (0)`
+ `MGMT_KEY_DETAILS_LOG (1)`
+ `MGMT_USER_DETAILS_LOG (2)`
+ `GENERIC_LOG`
## Exemples d'événements de journaux d'audit
Les événements d'un flux de journaux enregistrent l'historique du HSM de sa création à sa suppression. Vous pouvez utiliser le journal pour passer en revue le cycle de vie de votre HSMs ordinateur et avoir un aperçu de son fonctionnement. Lorsque vous interprétez les événements, notez le `Opcode`, qui indique la commande de gestion ou l'action et le `Sequence No`, qui indique l'ordre des événements.
**Topics**
+ [Exemple : Initialiser le premier HSM dans un cluster](#example-audit-log-first-hsm)
+ [Événements de connexion et de déconnexion](#example-audit-log-login-logout)
+ [Exemple : Créer et supprimer des utilisateurs](#example-audit-log-first-hsm)
+ [Exemple : Créer et supprimer une paire de clés](#example-audit-log-manage-keys)
+ [Exemple : Générer et Synchroniser une clé](#audit-log-example-gen-key)
+ [Exemple : Exporter une clé](#audit-log-example-export-key)
+ [Exemple : Importer une clé](#audit-log-example-import-key)
+ [Exemple : Partager une clé et annuler le partage d’une clé](#audit-log-example-share-unshare-key)
### Exemple : Initialiser le premier HSM dans un cluster
Le flux du journal d'audit du premier HSM de chaque cluster est très différent des flux de journal des autres HSMs HSM du cluster. Le journal d'audit du premier HSM de chaque cluster enregistre la création et l'initialisation de celui-ci. Les journaux des éléments supplémentaires HSMs du cluster, qui sont générés à partir de sauvegardes, commencent par un événement de connexion.
**Important**
Les entrées d'initialisation suivantes n'apparaîtront pas dans les CloudWatch journaux des clusters initialisés avant le lancement de la fonctionnalité de journalisation d'audit CloudHSM (30 août 2018). Pour plus d'informations, consultez [Historique du document](document-history.md).
Les exemples d'événements suivants apparaissent dans le flux de journaux pour le premier HSM d'un cluster. Le premier événement dans le journal, celui contenant `Sequence No 0x0`, représente la commande permettant d’initialiser le HSM (`CN_INIT_TOKEN`). La réponse indique que la commande a réussi (`Response : 0: HSM Return: SUCCESS`).
```
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)
```
Le deuxième événement de cet exemple de flux de journaux (`Sequence No 0x1`) enregistre la commande pour créer la clé de chiffrement de mot de passe que le HSM utilise (`CN_GEN_PSWD_ENC_KEY`).
Il s'agit d'une séquence de démarrage classique pour le premier HSM de chaque cluster. Comme HSMs les clones du premier cluster se trouvent les suivants, ils utilisent la même clé de chiffrement par mot de passe.
```
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)
```
Le troisième événement de cet exemple de flux de journaux (`Sequence No 0x2`) est la création de l'[utilisateur de l'appareil (AU)](understanding-users-cmu.md#appliance-user-cmu), qui est le service AWS CloudHSM . Les événements qui impliquent des utilisateurs de HSM incluent des champs supplémentaires pour le nom d'utilisateur et le type d'utilisateur.
```
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)
```
Le quatrième événement de cet exemple de flux de journaux (`Sequence No 0x3`) enregistre l'événement `CN_INIT_DONE`, qui termine l'initialisation du HSM.
```
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)
```
Vous pouvez suivre les autres événements dans la séquence de démarrage. Ces événements peuvent inclure plusieurs événements de connexion et de déconnexion, et la génération de la clé de chiffrement de clé (KEK). L'événement suivant enregistre la commande qui modifie le mot de passe du [responsable du pré-chiffrement (PRECO)](understanding-users-cmu.md#preco). Cette commande active le 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)
```
### Événements de connexion et de déconnexion
Lors de l'interprétation de votre journal d'audit, notez les événements qui enregistrent la connexion au HSM et la déconnexion de celui-ci. Ces événements pour vous aident à déterminer quel utilisateur est responsable des commandes de gestion qui apparaissent dans la séquence entre les commandes de connexion et de déconnexion.
Par exemple, cette entrée de journal enregistre une connexion par un responsable de chiffrement nommé `admin`. Le numéro de séquence, `0x0`, indique qu'il s'agit du premier événement de ce flux de journaux.
Lorsqu'un utilisateur se connecte à un HSM, l'autre HSMs utilisateur du cluster enregistre également un événement de connexion pour l'utilisateur. Vous pouvez trouver les événements de connexion correspondants dans les flux de log des autres HSMs utilisateurs du cluster peu après l'événement de connexion initial.
```
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)
```
L'exemple d'événement suivant enregistre la déconnexion du responsable de chiffrement `admin`. Le numéro de séquence, `0x2`, indique qu'il s'agit du troisième événement du flux de journaux.
Si l'utilisateur connecté ferme la session sans se déconnecter, le flux de journaux inclut un `CN_APP_FINALIZE` ou un événement de fermeture de session (`CN_SESSION_CLOSE`), au lieu d'un événement `CN_LOGOUT`. Contrairement à l'événement de connexion, cet événement de déconnexion est enregistré généralement uniquement par le HSM qui exécute la commande.
```
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)
```
Si une tentative de connexion échoue parce que le nom d'utilisateur n'est pas valide, le HSM enregistre un événement `CN_LOGIN` avec le nom et le type d'utilisateur fournis dans la commande de connexion. La réponse affiche un message d'erreur 157, qui explique que le nom d'utilisateur n'existe pas.
```
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)
```
Si une tentative de connexion échoue parce que le mot de passe n'est pas valide, le HSM enregistre un événement `CN_LOGIN` avec le nom et le type d'utilisateur fournis dans la commande de connexion. La réponse affiche le message d'erreur avec le code d'erreur `RET_USER_LOGIN_FAILURE`.
```
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)
```
### Exemple : Créer et supprimer des utilisateurs
Cet exemple montre les événements de journal qui sont enregistrés lorsqu'un responsable de chiffrement (CO) crée et supprime des utilisateurs.
Le premier événement enregistre un CO, `admin`, qui se connecte au HSM. Le numéro de séquence `0x0` indique qu'il s'agit du premier événement du flux de journaux. Le nom et le type de l'utilisateur qui s'est connecté sont inclus dans l'événement.
```
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)
```
L'événement suivant dans le flux de journaux (séquence `0x1`) enregistre que le responsable de chiffrement (CO) crée un utilisateur de chiffrement (CU). Le nom et le type du nouvel utilisateur sont inclus dans l'événement.
```
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)
```
Ensuite, le CO crée un autre responsable de chiffrement, `alice`. Le numéro de séquence indique que cette action suivait l'action précédente sans action intermédiaire.
```
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)
```
Plus tard, le CO nommé `admin` se connecte et supprime le responsable de chiffrement nommé `alice`. Le HSM enregistre un événement `CN_DELETE_USER`. Le nom et le type de l'utilisateur supprimé sont inclus dans l'événement.
```
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)
```
### Exemple : Créer et supprimer une paire de clés
Cet exemple montre les événements qui sont enregistrés dans le journal d'audit d'un HSM lorsque vous créez et supprimez une paire de clés.
L'événement suivant enregistre l'utilisateur de chiffrement (CU) nommé `crypto_user` qui se connecte au HSM.
```
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)
```
Ensuite, le CU génère une paire de clés (`CN_GENERATE_KEY_PAIR`). La clé privée dispose du handle de clé `131079`. La clé publique dispose du handle de clé `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
```
Le CU supprime immédiatement la paire de clés. Un événement CN\$1DESTROY\$1OBJECT enregistre la suppression de la clé publique (131078).
```
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
```
Ensuite, un deuxième événement `CN_DESTROY_OBJECT` enregistre la suppression de la clé privée (`131079`).
```
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
```
Enfin, le CU se déconnecte.
```
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)
```
### Exemple : Générer et Synchroniser une clé
Cet exemple montre l'effet de la création d'une clé dans un cluster comportant plusieurs clés HSMs. La clé est générée sur un HSM, extraite du HSM en tant qu'objet masqué et insérée dans l'autre en HSMs tant qu'objet masqué.
**Note**
Les outils du client peuvent échouer à synchroniser la clé. La commande peut également inclure le **min\$1srv** paramètre, qui synchronise la clé uniquement avec le nombre spécifié de HSMs. Dans les deux cas, le AWS CloudHSM service synchronise la clé avec l'autre clé HSMs du cluster. Comme ils HSMs enregistrent uniquement les commandes de gestion côté client dans leurs journaux, la synchronisation côté serveur n'est pas enregistrée dans le journal HSM.
Examinez d'abord le flux de journaux du HSM qui reçoit et exécute les commandes. Le flux de journaux est nommé pour le HSM ID `hsm-abcde123456`, mais l'ID du HSM n'apparaît pas dans les événements du journal.
Tout d'abord, l'utilisateur de chiffrement (CU) `testuser` se connecte au HSM `hsm-abcde123456`.
```
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)
```
La CU exécute une [exSymKey](key_mgmt_util-genSymKey.md)commande pour générer une clé symétrique. Le HSM `hsm-abcde123456` génère une clé symétrique avec un handle de clé `262152`. Le HSM enregistre un événement `CN_GENERATE_KEY` dans son journal.
```
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
```
L'événement suivant dans le flux de journaux pour `hsm-abcde123456` enregistre la première étape du processus de synchronisation de clé. La nouvelle clé (handle de clé `262152`) est extraite du HSM en tant qu'objet masqué.
```
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
```
Examinez maintenant le flux de journaux pour le HSM `hsm-zyxwv987654`, un autre HSM du même cluster. Ce flux de journaux inclut également un événement de connexion pour l'utilisateur de chiffrement (CU) `testuser`. La valeur temporelle montre que cela se produit peu de temps après que l'utilisateur se connecte au HSM `hsm-abcde123456`.
```
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)
```
Ce flux de journaux pour ce HSM n'a pas d'événement `CN_GENERATE_KEY`. Mais il y a un événement qui enregistre la synchronisation de la clé pour ce HSM. L'événement `CN_INSERT_MASKED_OBJECT_USER` enregistre la réception de la clé `262152` en tant qu'objet masqué. La clé `262152` existe maintenant sur les deux HSMs dans le 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
```
Lorsque l'utilisateur de chiffrement (CU) se déconnecte, cet événement `CN_LOGOUT` s'affiche uniquement dans le flux de journaux du HSM qui reçoit les commandes.
### Exemple : Exporter une clé
Cet exemple montre les événements du journal d'audit enregistrés lorsqu'un utilisateur cryptographique (CU) exporte des clés depuis un cluster comportant plusieurs clés HSMs.
L'événement suivant enregistre la journalisation CU (`testuser`) dans [key\$1mgmt\$1util](key_mgmt_util.md).
```
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)
```
La CU exécute une [exSymKey](key_mgmt_util-exSymKey.md)commande pour exporter la clé`7`, une clé AES 256 bits. La commande utilise la touche`6`, une touche AES 256 bits sur le HSMs, comme clé d'encapsulation.
Le HSM qui reçoit la commande enregistre un événement `CN_WRAP_KEY` pour la clé `7`, la clé qui est exportée.
```
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
```
Ensuite, le HSM enregistre un événement `CN_NIST_AES_WRAP` pour la clé d'encapsulage, la clé `6`. La clé est encapsulée, puis immédiatement désencapsulée, mais le HSM n'enregistre qu'un seul événement.
```
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
```
La commande **exSymKey** écrit les clés exportées dans un fichier, mais ne modifie pas la clé dans le HSM. Par conséquent, il n'y a aucun événement correspondant dans les journaux des autres HSMs membres du cluster.
### Exemple : Importer une clé
Cet exemple montre les événements du journal d'audit enregistrés lorsque vous importez des clés HSMs dans un cluster. Dans cet exemple, l'utilisateur cryptographique (CU) utilise la [imSymKey](key_mgmt_util-imSymKey.md)commande pour importer une clé AES dans le HSMs. La commande utilise la clé `6` en tant que clé d'encapsulage.
Le HSM qui reçoit les commandes enregistre un événement `CN_NIST_AES_WRAP` pour la clé `6`, la clé d'encapsulage.
```
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
```
Ensuite, le HSM enregistre un événement `CN_UNWRAP_KEY` qui représente l'opération d'importation. Le handle de clé `11` est attribué à la clé importée.
```
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
```
Lorsqu'une nouvelle clé est générée ou importée, les outils clients tentent automatiquement de synchroniser la nouvelle clé avec les autres HSMs clés du cluster. Dans ce cas, le HSM enregistre un événement `CN_EXTRACT_MASKED_OBJECT_USER` lorsque la clé `11` est extraite du HSM en tant qu'objet masqué.
```
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
```
Les flux de log des autres HSMs membres du cluster reflètent l'arrivée de la clé nouvellement importée.
Par exemple, cet événement a été enregistré dans le flux de journaux d'un autre HSM du même cluster. Cet événement `CN_INSERT_MASKED_OBJECT_USER` enregistre l'arrivée d'un objet masqué qui représente la clé `11`.
```
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
```
### Exemple : Partager une clé et annuler le partage d’une clé
Cet exemple illustre l’événement de journal d’audit qui est enregistré lorsqu’un utilisateur de chiffrement (CU) partage ou annule le partage d’une clé privée ECC avec d'autres utilisateurs de chiffrement. Le CU utilise la commande [shareKey](cloudhsm_mgmt_util-shareKey.md) et fournit le handle de clé, l’ID utilisateur et la valeur `1` pour partager ou la valeur `0` pour annuler le partage de la clé.
Dans l'exemple suivant, le HSM qui reçoit la commande, enregistre un événement `CM_SHARE_OBJECT` qui représente l'opération de partage.
```
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)
```