Si vous utilisez Alibaba Cloud Key Management Service (KMS) 1,0, migrez vos ressources vers une instance logicielle ou matérielle de gestion de clés KMS 3,0 dans la même région pour améliorer les performances et l'expérience utilisateur. Après la migration, vos clés et vos secrets sont stockés dans l'instance KMS. Les clés sont uniques au sein d'une région, tandis que les secrets sont uniques au sein d'un compte Alibaba Cloud et d'une instance KMS de cette région. Cette rubrique explique comment migrer les ressources de KMS 1,0 vers une instance KMS 3,0.
Pourquoi migrer
Afin d'offrir une meilleure expérience produit, Alibaba Cloud entame la phase de fin de support et de correctifs (EOSF) pour KMS 1,0 le 30 mars 2025 à 00:00:00 (GMT+8). KMS 1,0 entrera ensuite dans la phase de fin de support (EOS) le 30 septembre 2025 à 00:00:00 (GMT+8). Pour éviter toute interruption de service, migrez vos ressources KMS 1,0 vers une instance KMS 3,0 dès que possible. La migration vers une instance KMS 3,0 offre les avantages suivants :
Impact de la migration
Impact sur l'activité
-
La migration affecte les aspects suivants de votre activité :
-
Disponibilité du service : La migration KMS sépare les opérations du plan de contrôle de celles du plan de données. Le processus de migration n'affecte pas vos opérations commerciales. Les appels de secret, le chiffrement des produits cloud et le chiffrement des applications continuent de fonctionner normalement.
ImportantPendant la fenêtre de migration, du début jusqu'à l'achèvement du processus, vous ne pouvez pas effectuer d'opérations sur le plan de contrôle, telles que la création, la modification ou la suppression de ressources sur les clés, les secrets ou les instances KMS. Cette restriction évite les échecs de migration liés à des problèmes de cohérence des données. Nous vous recommandons d'effectuer la migration pendant les heures creuses.
Compatibilité Terraform : Si vous utilisez Terraform pour gérer KMS, un ID d'instance sera ajouté à vos ressources après la migration. Pour éviter la libération intempestive des ressources lors des opérations ultérieures sur le plan de contrôle, modifiez votre configuration Terraform une fois la migration terminée. Pour plus d'informations, consultez Modifier la configuration dans un scénario Terraform après la migration.
-
-
La migration n'affecte pas les aspects suivants de votre activité :
Compatibilité SDK : Après la migration, les applications personnalisées peuvent continuer à utiliser le kit de développement logiciel (SDK) existant sans aucune modification du code ou des applications. Si vous utilisez les SDK d'autres produits, tels que Function Compute, pour le chiffrement et le déchiffrement, vous n'avez pas besoin de les modifier. Cela garantit une migration efficace, fluide et transparente.
Impact sur les performances : Si vous accédiez aux clés et aux secrets via le réseau public avant la migration, vous pouvez continuer à utiliser le SDK existant après la migration. Les performances restent inchangées. Pour les améliorer, passez de l'accès par réseau public à l'accès VPC. Après ce changement, les performances dépendront du type d'instance.
Politiques de contrôle d'accès : Vous pouvez continuer à utiliser vos politiques de contrôle d'accès existantes après la migration sans aucune modification.
-
Autres impacts :
Les ID de version des clés symétriques et asymétriques changent après la migration. Si votre application personnalisée inclut une logique de validation des ID de version de clé, évaluez et supprimez cette logique avant la migration. Sinon, ce changement entraînera l'échec de la validation dans votre application.
RemarqueSi vous utilisez OpenAPI, les appels effectués avec l'ancien ID de version de clé réussiront toujours après la migration. Vous n'avez pas besoin de modifier votre code métier.
Impact sur les coûts
La logique de facturation des instances KMS 3,0 diffère de celle de KMS 1,0. Avant de migrer, prenez connaissance des coûts associés aux instances KMS 3,0. Pour plus d'informations, consultez Facturation par abonnement et Paiement à l'utilisation.
Remarques sur la migration des clés
KMS migre les métadonnées et le matériel de clé des clés maîtres client (CMK). Les métadonnées incluent l'ID de clé, l'état de la clé, la protection contre la suppression, l'alias et les tags. Ces données restent inchangées après la migration.
Clés de service
Les clés de service n'ont pas besoin d'être migrées. Vous pouvez continuer à les utiliser normalement. Affichez les clés de service dans la nouvelle console après vous être connecté. Les produits cloud créent automatiquement les clés de service lorsque vous configurez le chiffrement côté serveur. Leurs alias suivent le format alias/acs/<CloudProduct>.
Clés maîtres client
Seules les clés dont l'état est Enabling peuvent être migrées. Les clés dans d'autres états, tels que Disabled ou Schedule Deletion, ne peuvent pas être migrées.
-
Niveau de protection : Software
Le tableau suivant indique les types d'instance vers lesquels vous pouvez migrer.
ImportantBring-Your-Own-Key (BYOK) : La migration est prise en charge. KMS migre directement le matériel de clé. Vous n'avez pas besoin de le télécharger manuellement.
Clés multiversions : La migration est prise en charge. KMS migre toutes les versions de clé.
Si la rotation automatique est activée pour une clé, désactivez-la manuellement avant la migration pour garantir la cohérence des versions. Pour plus d'informations, consultez Rotation automatique des clés.
Dans une instance matérielle de gestion de clés, les clés peuvent être stockées dans une base de données ou un HSM. Par défaut, les clés migrées vers une instance matérielle de gestion de clés sont stockées dans la base de données, car les clés stockées en base de données prennent en charge la rotation. Ce paramètre ne peut pas être modifié.
Spécification de clé à migrer
Instance logicielle de gestion de clés
Instance matérielle de gestion de clés
Aliyun_AES_256 (version unique)
Aliyun_AES_256 (multiversion)
RSA_2048 (version unique)
EC_P256 (version unique)
EC_P256K (version unique)
-
Niveau de protection : HSM
ImportantSeules les clés situées en Chine continentale peuvent être migrées. Les clés situées hors de Chine continentale ne peuvent pas être migrées. Si vous disposez de clés non migrables, contactez-nous.
Bring-Your-Own-Key (BYOK) : La migration est prise en charge. KMS migre directement le matériel de clé, vous n'avez donc pas besoin de le télécharger manuellement.
Clés multiversions : La migration est prise en charge pour certains types de clés. KMS migre toutes les versions de clé.
Si la rotation automatique est activée pour une clé, désactivez-la manuellement avant la migration pour garantir la cohérence des versions. Pour plus d'informations, consultez Rotation automatique des clés.
Dans une instance matérielle de gestion de clés, les clés peuvent être stockées dans une base de données ou un HSM. Par défaut, les clés migrées vers une instance matérielle de gestion de clés sont stockées dans la base de données, car les clés stockées en base de données prennent en charge la rotation. Ce paramètre ne peut pas être modifié.
Le tableau suivant indique les types d'instance vers lesquels vous pouvez migrer.
Spécification de clé à migrer
Instance logicielle de gestion de clés
Instance matérielle de gestion de clés
Aliyun_AES_256 (version unique)
Aliyun_AES_256 (multiversion)
Aliyun_SM4 (version unique)
Aliyun_SM4 (multiversion)
RSA_2048 (version unique)
EC_P256 (version unique)
EC_P256K (version unique)
RSA_3072 (version unique)
EC_SM2 (version unique)
Remarques sur la migration des secrets
Tous les types de secrets peuvent être migrés.
Dans KMS 3,0, les secrets doivent être uniques au sein d'un compte Alibaba Cloud et d'une instance KMS dans une seule région. Si plusieurs secrets dans KMS 1,0 portent le même nom, ou si un secret portant le même nom existe déjà dans l'instance KMS 3,0 de destination, la migration n'est pas prise en charge.
KMS migre les métadonnées et toutes les versions d'un secret. Les métadonnées incluent le nom du secret, l'état et les tags. Ces données restent inchangées après la migration.
Les secrets dont la rotation automatique est activée peuvent être migrés. Pour garantir la cohérence des versions, désactivez manuellement la rotation automatique avant la migration.
Lorsque vous migrez un secret, migrez également la clé maître qui le chiffre.
Les secrets chiffrés avec une clé gérée par le système peuvent être migrés. Cependant, la fonctionnalité de sauvegarde des données n'est pas prise en charge pour ces secrets après la migration. Pour plus d'informations sur la fonctionnalité de sauvegarde des données, consultez Gestion de la reprise après sinistre.
Vérifier rapidement les ressources à migrer
Cette méthode affiche uniquement les clés pouvant être migrées. Pour les clés qui ne peuvent pas être migrées, affichez les clés restantes dans la console héritée après la migration et contactez le support technique Alibaba Cloud pour obtenir de l'aide.
Connectez-vous à la console KMS 1,0. Dans le volet de navigation de gauche, cliquez sur Migration Tool.
-
Si le bouton Migrate est disponible, cela indique que vous avez des clés ou des secrets à migrer dans la région actuelle.
ImportantLes données sont affichées par région. Vérifiez les données de toutes les régions afin de ne négliger aucune ressource.
Sur la page Migration Information, examinez le tableau indiquant le nombre de clés et de secrets dans chaque région, y compris les colonnes Keys not migrated, Migrated keys, Secrets not migrated et Migrated secrets, ainsi que l'état de la tâche. Dans la colonne Actions de la région cible, cliquez sur Migrate.
Cliquez sur les nombres dans les colonnes Keys Not Migrated, Migrated Keys, Secrets Not Migrated et Migrated Secrets pour afficher les IDs de clé et les noms de secret spécifiques.
Choisir une instance KMS 3,0 adaptée
Évaluez les aspects suivants pour choisir une instance KMS 3,0 adaptée.
Besoins métier : Choisissez une instance KMS adaptée en fonction des types d'instance vers lesquels vos clés peuvent être migrées.
Besoins en performance : Tenez compte de la fréquence des opérations de chiffrement et de déchiffrement des données dans votre activité. Par exemple, si votre activité est une plateforme de commerce électronique à fort trafic traitant de nombreuses commandes quotidiennement, vous devez chiffrer les informations de paiement des utilisateurs (telles que les numéros de carte bancaire et les mots de passe de paiement) et les données de commande. Vous aurez peut-être besoin d'une instance KMS avec un QPS élevé. Dans ce cas, choisissez une instance KMS prenant en charge 2 000 ou 4 000 QPS pour garantir que les opérations de chiffrement et de déchiffrement soient effectuées rapidement et éviter les retards ou échecs de transaction.
Besoins de conformité : Si votre activité doit se conformer à la certification FIPS, vous devez acheter une instance matérielle de gestion de clés.
Budget : Les instances KMS proposent deux méthodes de facturation : l'abonnement et le paiement à l'utilisation. La méthode de paiement à l'utilisation est recommandée uniquement si votre activité utilise KMS exclusivement pour le chiffrement des produits cloud. Pour tous les autres scénarios, nous vous recommandons d'utiliser une instance par abonnement.