Os segredos do Key Management Service (KMS) são recursos específicos de cada região. Se você receber uma notificação de migração de região, migre seus segredos para a região de destino o mais rápido possível para evitar interrupções no serviço. A abordagem de migração depende do tipo de segredo.
|
Tipo de segredo |
Migração necessária |
Abordagem |
|
Segredo genérico (em uma instância KMS) |
Sim |
Migre usando backup e restauração |
|
Segredo genérico (fora de uma instância KMS) |
Sim |
Recrie o segredo na região de destino usando a API |
|
Segredo RAM |
Migração não suportada — exclua e recrie |
Exclua na região de origem e crie na região de destino |
|
Segredo ApsaraDB RDS |
Não |
As instâncias do ApsaraDB RDS são específicas da região; os segredos acompanham automaticamente |
|
Segredo ECS |
Não |
As instâncias do Elastic Compute Service (ECS) são específicas da região; os segredos acompanham automaticamente |
Segredo genérico
Restrições
Durante a migração, não execute operações no segredo da região de origem até concluir o processo e excluir o segredo original. Por exemplo, não modifique os metadados do segredo nem crie uma nova versão (não chame
PutSecretValue).Após a migração, os timestamps de criação do segredo e de suas versões diferirão entre as regiões de origem e de destino. Essa diferença não afeta seus serviços.
Migrar um segredo genérico em uma instância KMS
Se o segredo genérico foi criado dentro de uma instância KMS, migre-o usando backup e restauração. Para obter detalhes, consulte Backups.
Migrar um segredo genérico fora de uma instância KMS
Na versão antiga do KMS, era possível criar um segredo genérico sem adquirir uma instância KMS. Esse tipo de segredo é considerado "fora de uma instância KMS". No KMS 3.0, você deve adquirir uma instância KMS antes de criar um segredo genérico.
Use o procedimento a seguir para recriar o segredo na região de destino por meio de chamadas de API.
Etapa 1: Consultar e salve os detalhes do segredo na região de origem
Chame as APIs a seguir na região de origem para obter todas as informações necessárias para recriar o segredo:
|
API |
Parâmetro principal |
Finalidade |
|
|
Defina |
Obter os metadados do segredo (nome, tipo, tags, descrição e configuração estendida) |
|
|
Defina |
Listar todas as versões do segredo, incluindo as obsoletas |
|
|
Chame uma vez por versão |
Recuperar o valor e o tipo de valor do segredo para cada versão |
Os VersionIds na resposta de ListSecretVersionIds não estão ordenados por data de criação. Ordene-os localmente antes de prosseguir.
Por exemplo, se ListSecretVersionIds retornar três versões, ordene-as pela data de criação:
|
Versão |
Criada em |
Estágio |
|
v1 |
1º de janeiro de 2023 |
|
|
v2 |
1º de maio de 2023 |
|
|
v3 |
1º de novembro de 2023 |
|
Etapa 2: Migrar sua aplicação para a região de destino
Transfira sua aplicação para a região de destino.
-
Crie uma credencial para a aplicação na região de destino:
Se usar um par AccessKey de um usuário ou função do Resource Access Management (RAM): Crie um usuário ou função RAM na região de destino e anexe a política
AliyunKMSSecretAdminAccess. Consulte Criar um usuário RAM e conceder permissões ao usuário RAM e Criar uma função RAM e anexar as políticas necessárias à função.Se usar uma chave de cliente de um ponto de acesso de aplicação (AAP): Adquira uma instância KMS e crie uma chave de cliente na região de destino. Consulte Criar um AAP.
-
Atualize as configurações de endpoint e credenciais na aplicação.
Os endpoints do KMS e os endpoints de instância KMS são diferentes. Configure o endpoint com base no SDK usado. Para obter detalhes, consulte Referências de SDK .
Etapa 3: Criar o segredo na região de destino
Adquira uma instância KMS na região de destino. Consulte Seleção de instância e Adquirir e ativar uma instância KMS.
Crie uma chave na instância KMS para criptografar o segredo. Consulte Introdução ao Gerenciamento de Chaves.
-
Chame as APIs a seguir para recriar o segredo com metadados, versões e valores idênticos:
API
O que definir
CreateSecretUse os valores de
DescribeSecretparasecretName,secretType,Tags,DescriptioneExtendedConfig. ParaVersionId, use a versão inicial (v1 neste exemplo). ParaSecretDataeSecretDataType, use os valores deGetSecretValueda versão inicial.PutSecretValueArmazene cada versão restante. Neste exemplo, chame uma vez para v2 e outra para v3.
UpdateSecretVersionStageDefina o estágio para cada versão. Neste exemplo: v1 →
001, v2 →ACSPrevious, v3 →ACSCurrent. Chame
DescribeSecretem ambas as regiões e confirme se as informações sobre o segredo são idênticas.
Etapa 4: Verifique sua aplicação
Teste a aplicação na região de destino para confirmar se ela acessa o segredo e funciona conforme o esperado.
Etapa 5: Exclua o segredo na região de origem
Após confirmar que a aplicação funciona corretamente na região de destino, exclua o segredo na região de origem. Consulte Gerencie e use segredos genéricos.
Use o ActionTrail para verificar chamadas de API recentes a um segredo antes de excluí-lo. Os eventos relacionados a segredos incluemGetSecretValue,DescribeSecret,ListSecretVersionIds,PutSecretValue,UpdateSecret,UpdateSecretVersionStage,UpdateSecretRotationPolicyeRestoreSecret. Consulte Usar o ActionTrail para consultar eventos do KMS e Auditar eventos do KMS .
Segredo RAM
A migração não é suportada. Um usuário RAM pode ter apenas um segredo RAM no KMS. Para mover um segredo RAM para uma nova região, exclua-o na região de origem e crie um novo na região de destino.
Antes de excluir um segredo RAM do KMS, certifique-se de que ele não está mais em uso. A exclusão do segredo RAM no KMS não remove o par AccessKey associado.
Segredo ApsaraDB RDS
A migração não é necessária. As instâncias do ApsaraDB RDS são recursos específicos da região, portanto, os segredos associados não precisam ser migrados separadamente.
Segredo ECS
A migração não é necessária. As instâncias do Elastic Compute Service (ECS) são recursos específicos da região, portanto, os segredos associados não precisam ser migrados separadamente.