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.
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) ouCN_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
etERROR
dans le champResponse
. - 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.
Rubriques
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.
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), 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). 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_DESTROY_OBJECT 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_srv 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 exSymKeycommande 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_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é AES 256 bits. La commande utilise la touche6
, 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 imSymKeycommande 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 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)