Tous les produits
Search
Centre de documentation

Key Management Service:Étape 2 : Effectuer la migration

Dernière mise à jour :Aug 09, 2026

Cette rubrique explique comment migrer les ressources d'une instance KMS 1.0 vers une instance KMS 3,0.

Remarque

La migration n'est prise en charge qu'au sein de la même région. Si vous disposez de ressources dans plusieurs régions, achetez une instance KMS 3,0 pour chaque région, puis migrez les ressources de chaque région séparément.

1. Vérifier les ressources à migrer

Remarque

Cette méthode affiche uniquement les clés éligibles à la migration. Pour les clés non éligibles, consultez les clés restantes dans l'ancienne console après la migration et contactez le support technique Alibaba Cloud.

  1. Connectez-vous à la console KMS 1.0. Dans le volet de navigation de gauche, cliquez sur Migration Tool.

  2. Si le bouton Migrate est disponible, cela signifie que vous avez des clés ou des secrets à migrer dans la région actuelle.

    Important

    Les 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 correspondant à la région cible, cliquez sur Migrate.

  3. Cliquez sur les chiffres des colonnes Keys Not Migrated, Migrated Keys, Secrets Not Migrated et Migrated Secrets pour afficher les ID de clés et les noms de secrets spécifiques.

2. Procédure de migration

Important

Vous pouvez migrer au maximum 50 clés et 50 secrets à la fois. Si vous possédez davantage de ressources, effectuez la migration par lots.

Migration mono-compte

  1. Préparez l'instance KMS de destination.

    • Si vous n'avez pas encore acheté d'instance KMS, achetez-en une et activez-la. Pour plus d'informations, consultez la rubrique Acheter et activer une instance KMS.

      Nous vous recommandons d'activer le renouvellement automatique pour l'instance KMS. Cela évite l'expiration et la libération de l'instance, qui entraîneraient des échecs de déchiffrement et rendraient vos données d'application inaccessibles.

    • Si vous disposez déjà d'une instance, assurez-vous que sa version d'image répond aux exigences de migration.

      • Pour une instance de gestion de clés logicielles, si la version de l'image est antérieure à la 2,9.0, mettez à jour l'image vers la dernière version. Pour plus d'informations, consultez la rubrique Mettre à niveau la version de l'image d'une instance KMS.

      • Pour une instance de gestion de clés matérielles, contactez le support technique Alibaba Cloud pour mettre à niveau la version de l'image.

  2. Connectez-vous à la console KMS 1.0 et désactivez la rotation des clés et des secrets.

    Remarque

    Il n'est pas possible de désactiver la rotation par lot. Vous devez désactiver la rotation pour chaque clé individuellement.

    Dans le volet de navigation de gauche, cliquez sur Customer master keys. Accédez à la page de détails de la clé cible. Dans la section des versions de clés, cliquez sur Set rotation policy et désactivez la rotation automatique.

    Dans le volet de navigation de gauche, cliquez sur Secrets. Accédez à la page de détails du secret et cliquez sur Set rotation policy en haut à droite pour désactiver la rotation.

  3. Dans le volet de navigation de gauche, cliquez sur Migration Tool. Trouvez la région contenant les ressources à migrer et cliquez sur Migrate dans la colonne Actions. Sous l'onglet Resources, configurez les paramètres.

    Paramètre

    Description

    Type

    Le type de l'instance KMS de destination.

    Instance

    Sélectionnez l'instance KMS de destination et définissez-la comme instance par défaut.

    Après la migration, si vous créez une ressource sans spécifier d'instance KMS (que ce soit dans la console KMS 1.0 ou en omettant l'ID d'instance KMS dans un appel API), la ressource est créée dans KMS 1.0 et marquée pour migration. Pour éviter cela, définissez une instance par défaut pendant la migration. Une fois l'instance par défaut définie, les ressources créées sans instance KMS spécifiée sont automatiquement attribuées à cette instance par défaut.

    Remarque
    • Si aucune instance par défaut n'a jamais été définie pour la région actuelle, la case à cocher Set as 3.0 Default Instance est automatiquement sélectionnée après avoir choisi une instance KMS de destination. Si une instance par défaut a déjà été définie pour la région, la case n'est pas sélectionnée automatiquement. Toutefois, si vous sélectionnez une autre instance KMS, le paramètre par défaut précédent est automatiquement remplacé.

    • Une seule instance par défaut peut être définie par région.

    Migration Method

    • Automatic Migration : Sélectionnez une heure de migration. La migration démarre automatiquement à l'heure spécifiée.

    • Manual Migration (Start Now) : La migration démarre immédiatement après la configuration.

    Migration Time

    Ce paramètre est requis uniquement si vous sélectionnez Automatic Migration.

    Resources

    Important

    Avant la migration, assurez-vous que votre instance KMS dispose d'un quota suffisant pour éviter les échecs de migration.

    • Manually Select Resources : Sélectionnez les ressources à migrer. Vous pouvez sélectionner au maximum 50 clés et 50 secrets à la fois. Filtrez les ressources par ID de clé, alias de clé et nom de secret.

    • Keys and Secrets : Migre toutes les clés et tous les secrets actuellement en attente de migration.

  4. Lisez attentivement les Migration Instructions, cliquez sur OK, vérifiez la liste de contrôle de migration, puis cliquez sur Migrate.

    Remarque

    Consultez la progression de la migration dans la colonne Task Status. Lorsque la migration est terminée, un message Migration Completed s'affiche.

  5. Si la rotation automatique était activée pour les clés et les secrets avant la migration, réactivez-la après celle-ci. Pour plus d'informations, consultez les rubriques Rotation des clés et Présentation de la gestion des secrets.

Migration multi-comptes

Pour migrer les ressources de plusieurs comptes Alibaba Cloud vers une seule instance KMS, suivez les étapes ci-dessous.

  1. Préparez l'instance KMS de destination dans l'un des comptes.

    • Si vous n'avez pas encore acheté d'instance KMS, achetez-en une et activez-la. Pour plus d'informations, consultez la rubrique Acheter et activer une instance KMS.

      Nous vous recommandons d'activer le renouvellement automatique pour l'instance KMS. Cela évite l'expiration et la libération de l'instance, qui entraîneraient des échecs de déchiffrement et rendraient vos données d'application inaccessibles.

    • Si vous disposez déjà d'une instance, assurez-vous que sa version d'image répond aux exigences de migration.

      • Pour une instance de gestion de clés logicielles, si la version de l'image est antérieure à la 2,9.0, mettez à jour l'image vers la dernière version. Pour plus d'informations, consultez la rubrique Mettre à niveau la version de l'image d'une instance KMS.

      • Pour une instance de gestion de clés matérielles, contactez le support technique Alibaba Cloud pour mettre à niveau la version de l'image.

  2. Partagez l'instance KMS avec les autres comptes Alibaba Cloud. Pour plus d'informations, reportez-vous aux étapes 1 à 3 de la rubrique Partager une instance KMS entre plusieurs comptes.

    Important

    Le partage n'est pris en charge qu'au sein d'un répertoire de ressources, et le propriétaire de la ressource ainsi que le principal doivent appartenir à la même entreprise vérifiée.

  3. Connectez-vous à chaque compte Alibaba Cloud et migrez ses ressources vers l'instance KMS. La procédure est identique à celle d'une migration mono-compte.

Migration HSM BYOK

Remarques importantes

La migration des clés HSM BYOK est prise en charge uniquement dans les régions de Chine continentale.

Procédure

  1. Connectez-vous à la console KMS 1.0. Dans le volet de navigation de gauche, cliquez sur Migration Tool pour ouvrir la page Migration Task Information. Trouvez la région où se trouve la clé à migrer et cliquez sur le chiffre dans la colonne Unmigrated HSM BYOKs.

  2. Sur la page Unmigrated HSM BYOKs, trouvez la clé HSM BYOK que vous souhaitez migrer et cliquez sur Import Wrapped Key Material dans la colonne Actions.

  3. Configurer la clé publique et les informations de jeton : Sur la page d'importation du matériau de clé, configurez les paramètres suivants, puis cliquez sur Next.

    Paramètre

    Description

    Public Key Type

    Sélectionnez le type de clé publique utilisé pour chiffrer le matériau de clé. L'option suivante est prise en charge :

    • RSA_2048 : Utiliser une clé publique RSA 2048 bits.

    Encryption Algorithm

    Sélectionnez l'algorithme de chiffrement. Les options suivantes sont prises en charge :

    • RSAES_OAEP_SHA_256 (Recommandé) : Utilise le remplissage RSA OAEP et l'algorithme de hachage SHA-256.

    • RSAES_PKCS1_V1_5 : Utilise le remplissage RSA PKCS#1 v1.5.

    Wrapping Key Format

    Sélectionnez le format de la clé d'enveloppement à télécharger. Les formats pris en charge sont der (par défaut) et pem.

  4. Télécharger la clé publique d'enveloppement et le jeton d'importation : L'importation du matériau de clé nécessite une clé publique d'enveloppement et un jeton d'importation. La clé publique d'enveloppement chiffre le matériau de clé pour le protéger lors de l'importation, tandis que le jeton d'importation autorise le processus.

    • Public Key Format :

      • DER Format : Le fichier téléchargé est nommé WrappingPublicKey**.bin par défaut.

      • PEM Format : Le fichier téléchargé est nommé WrappingPublicKey**.pem par défaut.

    • Import Token : Le fichier téléchargé est nommé ImportToken***.txt par défaut.

      Important
      • Un jeton d'importation est valide pendant 24 heures et peut être réutilisé durant cette période. Après expiration, obtenez un nouveau jeton d'importation et une nouvelle clé publique.

      • La clé publique d'enveloppement et le jeton d'importation doivent être utilisés ensemble. Vous ne pouvez pas utiliser une clé publique d'enveloppement issue d'un téléchargement avec un jeton d'importation issu d'un autre.

  5. Chiffrer le matériau de clé avec la clé publique d'enveloppement : Cette section utilise OpenSSL pour générer un matériau de clé avec l'algorithme RSA_2048 à titre d'exemple.

    1. Créez une clé privée asymétrique cible pour l'algorithme RSA_2048 et convertissez-la au format PKCS#8.

      openssl genrsa -out TakPrivPkcs1.pem 2048
      openssl pkcs8 -topk8 -inform PEM -in TakPrivPkcs1.pem -outform der -nocrypt -out TakPrivPkcs8.bin
    2. Créez une clé symétrique éphémère (ESK) pour l'algorithme AES_256.

      openssl rand -out EskAes256.bin 32
    3. Utilisez la clé publique de la clé d'enveloppement d'importation (IWKpub) pour chiffrer la clé symétrique éphémère (ESK) afin d'obtenir le texte chiffré de la clé symétrique éphémère (Cipher(ESK)). Le chiffrement standard RSAES OAEP est utilisé, où MGF1 et l'algorithme de hachage sont SHA256.

      openssl pkeyutl -encrypt -pubin -inkey PublicKey.pem  -in EskAes256.bin  -pkeyopt \
      rsa_padding_mode:oaep -pkeyopt rsa_oaep_md:sha256 -pkeyopt rsa_mgf1_md:sha256 -out \
      CipherEsk.bin
      Remarque

      Remplacez PublicKey.pem par le nom du fichier de clé publique téléchargé depuis la console KMS.

    4. Utilisez la clé symétrique éphémère (ESK) pour chiffrer la clé privée asymétrique cible (TAKpriv) afin de générer le texte chiffré de la clé privée (Cipher(TAKpriv)). Le mode de chiffrement est ECB et le mode de remplissage est PKCS#7 Padding.

      xxd -l 32  -c 32 -ps EskAes256.bin | xargs -I {} openssl enc  -aes-256-ecb -e  -K {} -in \
      TakPrivPkcs8.bin -nosalt -out CipherTakPriv.bin
    5. Assemblez les données résultantes au format Cipher(ESK) || Cipher(TAKpriv), puis effectuez un encodage Base64.

      cat CipherEsk.bin CipherTakPriv.bin > EncryptedKeyMaterial.bin
      openssl enc -e -base64 -A -in EncryptedKeyMaterial.bin -out EncryptedKeyMaterial_base64.txt
      Remarque

      EncryptedKeyMaterial_base64.txt est le fichier de matériau de clé pouvant être importé dans KMS.

  6. Importer le matériau de clé de migration : Sur la page d'importation du matériau de clé, configurez les paramètres suivants, puis cliquez sur OK.

    Important

    Le matériau de clé destiné à la migration est valide pendant 21 jours. Si la migration n'est pas effectuée dans ce délai, réimportez le matériau de clé.

    Paramètre

    Description

    Key Material Format

    Sélectionnez le format du matériau de clé à télécharger. Les formats pris en charge sont base64 (par défaut) et bin.

    Wrapped Key Material

    Téléchargez le fichier de matériau de clé chiffré avec la clé publique d'enveloppement.

    Import Token

    Téléchargez le fichier de jeton d'importation que vous avez obtenu à l'étape 4.

    Set Expiration Time

    Définissez une date d'expiration pour le matériau de clé. Les options suivantes sont prises en charge :

    • Never expires (Par défaut) : Le matériau de clé n'expire jamais.

    • Custom : Définissez une date d'expiration personnalisée pour le matériau de clé. Le matériau de clé sera supprimé à 00:00 (UTC+8) à la date spécifiée.

  7. Effectuer la migration : Revenez à la page Migration Task Information, trouvez la région où se trouve le HSM BYOK cible et cliquez sur Migrate dans la colonne Actions. Sous l'onglet Resources, configurez les paramètres.

    • Type : Hardware Management Instance.

    • Resources : Sélectionnez Manually select resources, puis sélectionnez la clé HSM BYOK cible.Resource Name

Dépannage

  • « current hardware BYOK key was not imported for migration » : Cela indique que le matériau de clé de migration n'a pas encore été importé pour la clé HSM BYOK. Terminez d'abord la procédure d'importation du matériau de clé décrite dans cette rubrique.

  • « current hardware BYOK key material is expired, please reimport » : Cela indique que le matériau de clé de migration a expiré car sa période de validité de 21 jours est dépassée. Réimportez le matériau de clé.

3. Opérations post-migration

Important

Après la migration, KMS applique une politique par défaut aux clés et secrets migrés. Pour plus d'informations, consultez les rubriques Présentation des politiques de clés et Présentation des politiques de secrets.

  1. Connectez-vous à la console KMS 3,0 pour afficher et confirmer les ressources migrées.

    • Clés de service

      1. Accédez à la page Keys et sélectionnez une région dans la barre de menu supérieure.

      2. Cliquez sur l'onglet Default Keys. Vérifiez que vos clés de service sont répertoriées et que la colonne Key Usage est définie sur Service Key.

    • Clés maîtres client (CMK)

      1. Accédez à la page Keys et sélectionnez une région dans la barre de menu supérieure.

      2. Cliquez sur l'onglet Customer Master Keys et vérifiez que les clés maîtres client migrées s'affichent.

      Si certaines CMK ne s'affichent pas dans la console KMS 3,0 après la migration, vérifiez les points suivants :

      • Vérifiez que la clé a bien été migrée.

      • Vérifiez que la clé n'est pas une clé de service. Les clés de service sont créées et gérées par les services Alibaba Cloud et ne figurent pas sous Customer Master Keys.

      Si vous confirmez que la clé a été migrée avec succès mais qu'elle ne s'affiche toujours pas dans la console KMS 3,0, le problème peut être dû à des données obsolètes dans la console. Contactez le support technique Alibaba Cloud pour corriger ces données. Une fois le problème résolu, la CMK sera restaurée et s'affichera normalement.

    • Secrets

      1. Accédez à la page Secrets et sélectionnez une région dans la barre de menu supérieure.

      2. Sélectionnez l'instance KMS et confirmez que les secrets migrés sont répertoriés. Ensuite, sélectionnez l'onglet Self-managed secrets. L'interface utilisateur est organisée comme suit : Le panneau de filtre à gauche répertorie chaque type de secret et son nombre, notamment generic secret, AK/SK secret, database secret et ECS secret. La liste à droite affiche le nom du secret, le type de secret, le créateur, la date de création, les tags, la description et les actions (Details, Schedule deletion, Cancel deletion).

  2. Si vous utilisez Terraform pour gérer les ressources KMS, modifiez la configuration Terraform. Pour plus d'informations, consultez la rubrique Modifier les configurations après la migration dans un scénario Terraform.

4. Surveillance de la migration

Pour garantir une migration de clés fluide, observable et traçable, nous vous recommandons d'utiliser CloudMonitor, Simple Log Service (SLS) et ActionTrail afin de surveiller de manière exhaustive les passerelles partagées et dédiées avant, pendant et après la migration. Les sections suivantes décrivent les points d'observation clés et les actions recommandées.

  1. Avant la migration : Observer le tableau de bord de la passerelle partagée

    Jusqu'à ce que vous acheviez la migration et basculiez le point de terminaison du client, toutes les requêtes KMS continuent d'être traitées par la passerelle partagée. À ce stade, concentrez-vous sur la stabilité et les performances de la passerelle partagée.

    • Objectif : Confirmer que la migration n'entraîne pas de charges anormales ou d'erreurs sur la passerelle partagée.

    • Métriques à observer :

      • Latence des requêtes : Vérifiez toute augmentation significative.

      • Répartition des codes d'erreur (tels que 4xx et 5xx) : Confirmez qu'il n'y a pas d'augmentation soudaine des erreurs anormales.

      • Tendances QPS/TPS : Comparez le trafic avant et après la migration pour assurer la cohérence. Cela permet d'éviter les pics de requêtes ou les interruptions causés par des opérations incorrectes.

    • Comment visualiser :

      • Méthode 1 : Connectez-vous à la console KMS 3,0. Sur la page Overview, vérifiez les métriques telles que la latence des requêtes et les codes d'erreur sur le tableau de bord Shared Gateway.

      • Méthode 2 : Connectez-vous à la console CloudMonitor. Dans la section Product Monitoring, recherchez Key Management Service pour afficher le tableau de bord Shared gateway.

    Remarque

    Nous vous recommandons d'enregistrer les métriques de référence avant la migration pour servir de point de comparaison.

  2. Après la migration : Observer simultanément les tableaux de bord des passerelles partagée et dédiée

    • Avant le basculement du point de terminaison : Continuez à observer la passerelle partagée. Bien que les clés aient été migrées vers une instance dédiée, les requêtes passent toujours par la passerelle partagée jusqu'à ce que vous basculiez le point de terminaison du client. La passerelle partagée transfère ces requêtes de manière transparente vers l'instance dédiée backend.

    • Après le basculement du point de terminaison : Observez simultanément les passerelles partagée et dédiée. Une fois que le client a terminé le basculement du point de terminaison, les requêtes accèdent directement à l'instance dédiée via la passerelle dédiée. À ce stade, surveillez les deux passerelles :

      Type de passerelle

      Points d'observation clés

      Méthode

      Passerelle dédiée

      • Codes d'erreur

      • Variations de la latence des requêtes

      • Les tendances QPS correspondent aux attentes

      CloudMonitor : Tableau de bord de la passerelle dédiée KMS

      Passerelle partagée

      • Vérifiez que le trafic a entièrement basculé.

      • Identifiez toute requête restante ou anormale.

      Observez le tableau de bord de la passerelle partagée pour la région correspondante

      Remarque

      Critères d'identification des anomalies :

      • Si la passerelle dédiée signale un nombre élevé d'erreurs de limitation de débit, ajustez le type d'instance ou la politique de limitation.

      • Si la passerelle partagée reçoit toujours un grand nombre de requêtes, cela indique que certains clients n'ont pas basculé leur point de terminaison. Enquêtez sur le problème.

  3. Observation au niveau des journaux : Analyser les journaux d'accès détaillés à l'aide de SLS

    Pour obtenir un suivi des requêtes plus granulaire et faciliter le diagnostic des problèmes, nous vous recommandons d'activer les fonctionnalités de collecte de journaux suivantes :

    • Journaux d'accès de la passerelle dédiée :

      • Achetez le service à valeur ajoutée d'analyse des journaux pour les passerelles dédiées afin de livrer automatiquement les journaux à Simple Log Service (SLS).

      • Interrogez et analysez les journaux par champs tels que l'ID de clé, l'ID de compte Alibaba Cloud, l'opération API et le code d'état de la réponse.

    • Journaux d'accès détaillés de la passerelle partagée :

      • Activez ActionTrail et livrez les traces d'événements vers un Logstore SLS spécifié.

      • Analysez des comportements de requête spécifiques en interrogeant des conditions telles que EventName = "Decrypt" et ResourceType = "KMS".

      • Utilisez le champ ErrorCode pour déterminer la cause des échecs, tels que des autorisations insuffisantes ou une clé inexistante.

  4. Stratégie de surveillance recommandée

    Phase

    Focus de la surveillance

    Outil

    Avant la migration

    Stabilité de la passerelle partagée

    Tableau de bord CloudMonitor

    Pendant le basculement

    Taux de réussite des requêtes, variations soudaines de la latence

    Surveillance en temps réel + alertes SLS

    Après la migration

    État de santé de la passerelle dédiée

    Tableau de bord de la passerelle dédiée + journaux SLS

    Tout au long du processus

    Tendances des codes d'erreur anormaux

    ActionTrail + analyse agrégée SLS