Étape 2 : Effectuer la migration - Key Management Service - Centre de documentation Alibaba Cloud

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 d'une 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 la console héritée après la migration et contactez le support technique Alibaba Cloud.

Connectez-vous à la console KMS 1.0. Dans le volet de navigation de gauche, cliquez sur Migration ToolMigration Tool.
Si le bouton MigrateMigrate 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. Veillez à vérifier 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.
Cliquez sur les nombres figurant dans les colonnes Keys Not MigratedKeys Not Migrated, Migrated KeysMigrated Keys, Secrets Not MigratedSecrets Not Migrated et Migrated SecretsMigrated Secrets pour afficher les ID de clé et les noms de secret spécifiques.

2. Procédure de migration

Important

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

Migration mono-compte

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 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 possédez déjà une instance, assurez-vous que sa version d'image répond aux exigences de migration.
  - Pour une instance de gestion logicielle des clés, 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 Mettre à niveau la version de l'image d'une instance KMS.
  - Pour une instance de gestion matérielle des clés, contactez le support technique Alibaba Cloud pour mettre à niveau la version de l'image.
Connectez-vous à la console KMS 1.0 et désactivez la rotation des clés et des secrets.

Remarque
Il est impossible 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é, 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 dans le coin supérieur droit pour désactiver la rotation.

Dans le volet de navigation de gauche, cliquez sur Migration ToolMigration Tool. Recherchez la région contenant les ressources à migrer et cliquez sur MigrateMigrate dans la colonne ActionsActions. Sous l'onglet ResourcesResources, 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 de fournir un 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, vous devez définir une instance par défaut lors de 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 que vous avez 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 un maximum de 50 clés et 50 secrets à la fois. Vous pouvez filtrer 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.

Lisez attentivement les Migration InstructionsMigration Instructions, cliquez sur OKOK, passez en revue la liste de contrôle de migration, puis cliquez sur MigrateMigrate.

Remarque
Consultez la progression de la migration dans la colonne Task StatusTask Status. Lorsque la migration est terminée, un message Migration Completed s'affiche.
Si la rotation automatique était activée pour les clés et les secrets avant la migration, réactivez-la après la migration. Pour plus d'informations, consultez Rotation des clés et Vue d'ensemble 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.

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 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 possédez déjà une instance, assurez-vous que sa version d'image répond aux exigences de migration.
  - Pour une instance de gestion logicielle des clés, 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 Mettre à niveau la version de l'image d'une instance KMS.
  - Pour une instance de gestion matérielle des clés, contactez le support technique Alibaba Cloud pour mettre à niveau la version de l'image.
Partagez l'instance KMS avec les autres comptes Alibaba Cloud. Pour plus d'informations, reportez-vous aux étapes 1 à 3 de Partager une instance KMS entre plusieurs comptes.

Important
Le partage n'est pris en charge qu'au sein d'un annuaire de ressources, et le propriétaire de la ressource ainsi que le principal doivent appartenir à la même entreprise vérifiée.
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 sur l'utilisation

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

Procédure

Connectez-vous à la console KMS 1.0. Dans le volet de navigation de gauche, cliquez sur Migration ToolMigration Tool pour ouvrir la page Migration Task InformationMigration Task Information. Recherchez la région où se trouve la clé à migrer et cliquez sur le nombre figurant dans la colonne Unmigrated HSM BYOKsUnmigrated HSM BYOKs.
Sur la page Unmigrated HSM BYOKsUnmigrated HSM BYOKs, recherchez la clé HSM BYOK que vous souhaitez migrer et cliquez sur Import Wrapped Key MaterialImport Wrapped Key Material dans la colonne ActionsActions.

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

Paramètre	Description
Public Key Type	Sélectionnez le type de clé publique utilisé pour chiffrer le matériel de clé. L'option suivante est prise en charge : RSA_2048 : Utilise 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.

Télécharger la clé publique d'enveloppement et le jeton d'importation : L'importation du matériel de clé nécessite une clé publique d'enveloppement et un jeton d'importation. La clé publique d'enveloppement chiffre le matériel de clé pour le protéger pendant l'importation, tandis que le jeton d'importation autorise le processus.
- Public Key FormatPublic Key Format :
  - DER FormatDER Format : Le fichier téléchargé est nommé WrappingPublicKey**.bin par défaut.
  - PEM FormatPEM Format : Le fichier téléchargé est nommé WrappingPublicKey**.pem par défaut.
- Import TokenImport 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 son 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 par paire. 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.
Chiffrer le matériel de clé avec la clé publique d'enveloppement : Cette section utilise OpenSSL pour générer du matériel 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ériel de clé pouvant être importé dans KMS.

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

Important

Le matériel 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ériel de clé.

Paramètre	Description
Key Material Format	Sélectionnez le format du matériel 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ériel 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ériel de clé. Les options suivantes sont prises en charge : Never expires (Par défaut) : Le matériel de clé n'expire jamais. Custom : Définissez une date d'expiration personnalisée pour le matériel de clé. Le matériel de clé est supprimé à 00:00 (UTC+8) à la date spécifiée.

Effectuer la migration : Revenez à la page Migration Task InformationMigration Task Information, recherchez la région où se trouve le HSM BYOK cible et cliquez sur MigrateMigrate dans la colonne ActionsActions. Sous l'onglet ResourcesResources, configurez les paramètres.
- TypeType : Hardware Management InstanceHardware Management Instance.
- ResourcesResources : Sélectionnez Manually select resources, puis choisissez la clé HSM BYOK cible.Resource Name Resource Name

Dépannage

« current hardware BYOK key was not imported for migration » : Cela indique que le matériel 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ériel de clé décrite dans cette rubrique.
« current hardware BYOK key material is expired, please reimport » : Cela indique que le matériel de clé de migration a expiré car sa période de validité de 21 jours est écoulée. Réimportez le matériel de clé.

3. Opérations post-migration

Important

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

Connectez-vous à la console KMS 3.0 pour afficher et confirmer les ressources migrées.
- Clés de service
  1. Accédez à la page KeysKeys et sélectionnez une région dans la barre de menu supérieure.
  2. Cliquez sur l'onglet Default KeysDefault Keys. Vérifiez que vos clés de service sont répertoriées et que la colonne Key UsageKey Usage est définie sur Service KeyService Key.
- Clés maîtres clientes
  1. Accédez à la page KeysKeys et sélectionnez une région dans la barre de menu supérieure.
  2. Cliquez sur l'onglet Customer Master KeysCustomer Master Keys et vérifiez que les clés maîtres clientes 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 KeysCustomer Master Keys .
  - Si vous confirmez que la clé a été migrée avec succès mais qu'elle n'apparaît 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 les données obsolètes. Une fois le problème résolu, la CMK sera restaurée et s'affichera normalement.
- Secrets
  1. Accédez à la page SecretsSecrets 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, y compris generic secret, RAM SecretsRAM Secrets, 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).
Si vous utilisez Terraform pour gérer les ressources KMS, modifiez la configuration Terraform. Pour plus d'informations, consultez Modifier les configurations après la migration dans un scénario Terraform.

4. Surveillance de la migration

Pour garantir une migration des clés fluide, observable et traçable, nous vous recommandons d'utiliser Cloud Monitor, 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.

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 ne provoque pas de charges anormales ni d'erreurs sur la passerelle partagée.
- Métriques à observer :
  - Latence des requêtes : Vérifiez toute augmentation significative.
  - Distribution 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 afficher :
  - Méthode 1 : Connectez-vous à la console KMS 3.0. Sur la page Vue d'ensemble, vérifiez les métriques telles que la latence des requêtes et les codes d'erreur sur le tableau de bord Shared GatewayShared Gateway.
  - Méthode 2 : Connectez-vous à la console Cloud Monitor. Dans la section Product MonitoringProduct 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 les utiliser comme point de comparaison.

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 transitent 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 effectué 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	Cloud Monitor : 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, 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é de point de terminaison. Enquêtez sur le problème.

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

Pour obtenir un suivi plus granulaire des requêtes et diagnostiquer les 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.

Stratégie de surveillance recommandée

Phase

Focus de la surveillance

Outil

Avant la migration

Stabilité de la passerelle partagée

Tableau de bord Cloud Monitor

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