Contrôle du cycle de vie des clés de chiffrement

IBM® Key Protect for IBM Cloud® suit les directives de sécurité établies par le NIST SP 800-57 pour les états clés.

Etats et transitions de clés

Les clés cryptographiques passent souvent par plusieurs états qui dépendent de la durée de vie des clés et de leur utilisation actuelle pour chiffrer des données.

Key Protect fournit une interface graphique et une API REST pour le suivi des clés au fur et à mesure qu'elles passent d'un état à un autre tout au long de leur cycle de vie. Le diagramme ci-dessous décrit les différents états connus par la clé passe entre sa génération et sa destruction.

Bien que ce diagramme présente des clés à l'état « Pré-activation », un état défini dans les normes NIST, d'un point de vue technique, « Pré-activation » définit un état avant qu'une clé n'existe. Les clés qui n'existent pas encore ne peuvent évidemment pas avoir d'état. Néanmoins, il est montré ici par souci d'exhaustivité conceptuelle. L'état "purgé" d'une clé, dans laquelle le matériau de la clé a été définitivement détruit au bout d'un certain temps, après le passage de la clé à l'état Détruit, n'apparaît pas dans ce diagramme et est également un état de non-existence.

Diagramme des états clés.
États et transitions clés.

Décrit les principaux états et transitions.
Etat Mappage d'entiers Description
Active 1 Les clés passent immédiatement dans l'état Actif à la date d'activation. Cette transition marque le début de la cryptopériode d'une clé. Les clés sans date d'activation deviennent immédiatement actives et le restent jusqu'à leur expiration ou leur destruction.
Interrompu 2 Une clé passe dans un état Suspendu lorsqu'elle est Désactivé pour les opérations de chiffrement et de déchiffrement. Dans cet état, la clé ne peut pas protéger les données de manière cryptographique et ne peut passer qu'aux états Actif ou Détruit.
Désactivé 3 Une clé passe à l'état Désactivé dans un délai d'une heure après sa date d'expiration, si une date est affectée. Dans cet état, les seules actions qui peuvent être effectuées sur la clé sont le désencapsulage, l'encapsulage, la rotation et la suppression.
Détruite 5 Les clés passent à l'état Détruit après avoir été supprimées. Les clés dans cet état peuvent être récupérées pendant 30 jours mais deviennent éligibles à la purge après 90 jours. Elles peuvent également être purgées quatre heures après avoir passé à l'état Détruit, si nécessaire. Après avoir été passé à l'état Détruit, les métadonnées associées à une clé, telles que son nom et un enregistrement de sa dernière transition, sont conservées dans la base de données Key Protect jusqu'à ce que la clé soit purgée. Pour plus d'informations, voir A propos de la suppression et de la purge des clés.

Soyez prudent lorsque vous définissez une date d'expiration, car les clés créées avec une date d'expiration passent automatiquement à l'état désactivé dans l'heure qui suit l'expiration. Dans cet état, les seules actions autorisées sur la clé sont le déballage, le remballage, la rotation et la suppression. Les clés désactivées ne peuvent pas être utilisées pour crypter (envelopper) de nouvelles données, même si elles ont été tournées pendant la désactivation. La rotation ne réinitialise pas la date d'expiration, ne la prolonge pas et ne permet pas de la modifier. Il est recommandé que toutes les données cryptées à l'aide d'une clé expirant ou périmée soient recryptées à l'aide d'une nouvelle clé racine client (CRK) avant que la CRK originale n'expire, afin d'éviter toute interruption de service. La suppression et la restauration d'une clé désactivée ne la ramènent pas à l'état actif. Si l'attribut expiration_date est omis, la clé n'expire pas.

Vous pouvez contrôler l'utilisation des clés avec des dates d'expiration en utilisant la fonction IBM Cloud Logs. Les journaux indiquent la date d'expiration et le nombre de jours restants à l'aide des propriétés JSON responseData.expirationDate et responseData.daysToKeyExpire pour les clés qui ont une date d'expiration et pour les valeurs action suivantes : kms.secrets.wrap, kms.secrets.unwrap, kms.secrets.rewrap, kms.secrets.read, kms.secrets.readmetadata, kms.secrets.create, kms.secrets-with-policy-overrides.create et kms.secrets.expire. En outre, un appel REST réussi à GET /api/v2/keys renvoie la propriété expirationDate pour chaque clé ayant une date d'expiration.

Etats de clé et actions de service

Les états de clé ont une incidence sur la réussite ou l'échec d'une action effectuée sur une clé. Par exemple, si une clé est à l'état Actif , vous ne pouvez pas restaurer la clé, car la clé n'a pas été supprimée précédemment.

Le tableau suivant décrit comment les états de clé affectent les actions de service. Les en-têtes de colonne représentent les états de clé, et les en-têtes de ligne représentent les actions que vous pouvez effectuer sur une clé. L'icône de coche (Icône de coche) indique que l'action sur une clé est censée réussir en fonction de l'état clé.

Décrit comment les états clés affectent les actions des services.
Action Active Suspendu (clés désactivées) Désactivé (clés arrivées à expiration) Détruit (clés supprimées)
Obtenir la clé icône de coche icône de coche icône de coche icône de coche
Répertorier les clés icône de coche icône de coche icône de coche
Effectuer la rotation de la clé icône de coche icône de coche
Encapsuler une clé icône de coche
Désencapsuler une clé icône de coche icône de coche
Réencapsuler une clé icône de coche icône de coche
Désactiver la clé icône de coche
Activer la clé icône de coche
Supprimer la clé icône de coche icône de coche icône de coche
Restaurer la clé icône de coche

Cryptopériodes, périodes d'utilisation de l'expéditeur et périodes d'utilisation du destinataire

Si vous connaissez les termes de la norme NIST et les systèmes de gestion des clés, vous connaissez probablement les concepts de "cryptopériode", de "période d'utilisation par l'auteur" et de "période d'utilisation par le destinataire".

Une « cryptoperiode » décrit le cycle de vie complet d'une clé. Si une clé est purgée un an après sa création, la cryptopériode de la clé était d'un an. La cryptopériode d'une clé commence donc à sa création.

De même, la « période d'utilisation de l'expéditeur » et la « période d'utilisation du destinataire » commencent lors de la création d'une clé. Le premier décrit le temps pendant lequel une clé peut être utilisée pour protéger les données en les encapsulant. La « période d'utilisation du destinataire », quant à elle, décrit le temps pendant lequel une clé peut être « désencapsulée » pour déchiffrer les données protégées. Rappelez-vous que les clés désactivées ne peuvent plus être utilisées pour encapsuler des données, mais peuvent toujours être utilisées pour en désencapsuler. Par conséquent, si une clé passe à l'état Désactivé (par exemple, en établissant une date d'expiration), sa période d'utilisation de l'expéditeur est terminée. Toutefois, sa période d'utilisation du destinataire se poursuivra jusqu'à ce que la clé soit supprimée.

Si aucune date d'expiration n'est définie sur une clé (et qu'elle n'est pas suspendue, désactivée ou détruite manuellement), la période d'utilisation de l'expéditeur, la période d'utilisation du destinataire et la cryptopériode de la clé sont les mêmes.

Surveillance des changements de cycle de vie

Une fois que vous avez ajouté une clé au service, utilisez le tableau de bord Key Protect ou les API REST Key Protect pour afficher la dernière fois que la clé a été transférée.

À des fins d'audit, vous pouvez également contrôler la piste d'activité d'une clé en intégrant Key Protect avec IBM Cloud Logs. Une fois que les deux services ont été mis en place et fonctionnent, des événements sont générés et automatiquement collectés dans un journal IBM Cloud Logs lorsque vous effectuez des actions sur des clés dans Key Protect.