Interprétation AWS CloudHSM des journaux d'audit - AWS CloudHSM
Exemples d'événements de journaux d'audit

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 figurant dans les journaux HSM d'audit comportent 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) du flux de log pour unHSM. Il montre la HSM génération d'une clé de cryptage de mot de passe, 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 à laquelle l'événement s'est produit dans le UTC fuseau horaire. 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)

Un compteur ordinal persistant de 32 bits qui est incrémenté lors du redémarrage du HSM matériel.

Tous les événements d'un flux de journaux ont la même valeur de compteur de redémarrages. Toutefois, le compteur de redémarrage n'est peut-être pas propre à un flux de journaux, car il peut varier selon les HSM instances du 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, consultezAWS CloudHSM référence du journal d'audit.

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 log enregistrent l'historique du, HSM depuis sa création jusqu'à 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.

Exemple : Initialisation du premier HSM dans un cluster

Le flux du journal d'audit du premier HSM de chaque cluster diffère considérablement des flux de journaux HSMs des autres du cluster. Le journal d'audit du premier HSM de chaque cluster enregistre sa création et son initialisation. 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 des HSM audits dans le cloud (30 août 2018). Pour plus d'informations, consultez Historique du document.

Les exemples d'événements suivants apparaissent dans le flux de journal pour le premier événement HSM d'un cluster. Le premier événement du journal, celui avecSequence 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 log stream (Sequence No 0x1) enregistre la commande permettant de créer la clé de chiffrement du mot de passe qu'il HSM utilise (CN_GEN_PSWD_ENC_KEY).

Il s'agit d'une séquence de démarrage typique 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), qui est le service AWS CloudHSM . Les événements impliquant des HSM utilisateurs 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 log stream (Sequence No 0x3) enregistre l'CN_INIT_DONEévénement, ce qui termine l'initialisation duHSM. 

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, ainsi que la génération de la clé de chiffrement (KEK). L'événement suivant enregistre la commande qui modifie le mot de passe du précryptographe (). 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

Lorsque vous interprétez votre journal d'audit, notez les événements qui enregistrent les connexions, entrées et déconnexions des utilisateursHSM. 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 à unHSM, 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 généralement enregistré uniquement par HSM celui 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, HSM un CN_LOGIN événement est enregistré avec le nom d'utilisateur et le type 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 valideHSM, un CN_LOGIN événement est enregistré avec le nom d'utilisateur et le type 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 COadmin, se connectant auHSM. 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. Il HSM enregistre un CN_DELETE_USER événement. 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 enregistrés dans un journal d'HSMaudit lorsque vous créez et supprimez une paire de clés.

L'événement suivant enregistre l'utilisateur cryptographique (CU) nommé se crypto_user connectant auHSM. 

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 OBJECT événement CN_ DESTROY _ 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ésHSMs. La clé est générée sur l'unHSM, extraite de HSM l'objet masqué et insérée dans l'autre HSMs sous forme d'objet masqué.

Note

Les outils du client peuvent échouer à synchroniser la clé. La commande peut également inclure le min_srv paramètre, qui synchronise la clé uniquement avec le nombre spécifié deHSMs. 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 log du journal HSM qui reçoit et exécute les commandes. Le flux de journal porte le nom HSM IDhsm-abcde123456, mais celui-ci HSM n'apparaît pas dans les événements du journal.

Tout d'abord, l'utilisateur testuser cryptographique (CU) se connecte au 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)

La CU exécute une exSymKeycommande pour générer une clé symétrique. hsm-abcde123456HSMGénère une clé symétrique avec un manche de262152. HSMEnregistre un CN_GENERATE_KEY événement 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é (manche de touche262152) en est extraite HSM sous forme d'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

Considérons maintenant le flux de log correspondant HSM hsm-zyxwv987654 HSM à un autre dans le même cluster. Ce flux de journaux inclut également un événement de connexion pour l'utilisateur de chiffrement (CU) testuser. La valeur temporelle indique que cela se produit peu de temps après la connexion de l'utilisateur au 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)

Ce flux de journal HSM correspondant ne contient aucun CN_GENERATE_KEY événement. Mais il y a un événement qui enregistre la synchronisation de la clé correspondanteHSM. 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 du CU se déconnecte, cet CN_LOGOUT événement apparaît uniquement dans le journal de l'utilisateur HSM qui a reçu 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ésHSMs.

L'événement suivant enregistre la journalisation CU (testuser) dans key_mgmt_util. 

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 exSymKeycommande pour exporter la clé7, une clé de 256 bitsAES. La commande utilise la touche6, une clé de 256 bits sur leHSMs, comme AES clé d'encapsulation.

Celui HSM qui reçoit la commande enregistre un CN_WRAP_KEY événement pour la clé7, la clé en cours d'exportation. 

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, il HSM enregistre un CN_NIST_AES_WRAP événement pour la clé d'encapsulation, clé6. La clé est enveloppée puis immédiatement déballée, mais elle n'HSMenregistre 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 exSymKey commande écrit la clé exportée dans un fichier mais ne modifie pas la clé duHSM. 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 imSymKeycommande pour importer une AES clé dans leHSMs. La commande utilise la clé 6 en tant que clé d'encapsulage.

Celui HSM qui reçoit les commandes enregistre d'abord un CN_NIST_AES_WRAP événement pour la clé6, la clé d'encapsulation. 

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, il HSM enregistre un CN_UNWRAP_KEY événement 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, HSM enregistre un CN_EXTRACT_MASKED_OBJECT_USER événement lorsque la clé 11 est extraite du HSM sous forme d'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 log d'un autre HSM groupe 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 montre l'événement du journal d'audit enregistré lorsqu'un utilisateur cryptographique (CU) partage ou annule le partage de la clé ECC privée avec d'autres utilisateurs cryptographiques. La CU utilise la shareKeycommande et fournit le descripteur de touche, l'ID utilisateur et la valeur 1 à partager ou la valeur 0 pour annuler le partage de la clé.

Dans l'exemple suivant, celui HSM qui reçoit la commande enregistre un CM_SHARE_OBJECT événement 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)