Key Management Service:Etapa 2: Executar a migração

Migração de conta única

1. Prepare a instância de destino do KMS.

   • Se ainda não adquiriu uma instância do KMS, adquira e ative uma primeiro. Para mais informações, consulte Purchase and enable a KMS instance.

     Recomendamos ativar a renovação automática para a instância do KMS. Isso evita que a instância expire e seja liberada, o que causaria falhas de descriptografia e tornaria os dados da sua aplicação inacessíveis.

   • Caso já possua uma instância, verifique se a versão da imagem atende aos requisitos de migração.

     • Para uma instância de gerenciamento de chaves via software, se a versão da imagem for anterior à 2.9.0, atualize a imagem para a versão mais recente. Para mais informações, consulte Upgrade the image version of a KMS instance.

     • Para uma instância de gerenciamento de chaves via hardware, entre em contato com o suporte técnico da Alibaba Cloud para atualizar a versão da imagem.

2. Faça logon no console do KMS 1.0 e desative a rotação de chaves e segredos.

   Nota

   Não é possível desativar a rotação em lotes. Desative a rotação individualmente para cada chave.

   No painel de navegação à esquerda, clique em Customer master keys. Acesse a página de detalhes da chave de destino. Na seção de versões da chave, clique em Set rotation policy e desative a rotação automática.

   No painel de navegação à esquerda, clique em Secrets. Acesse a página de detalhes do segredo e clique em Set rotation policy no canto superior direito para desativar a rotação.

3. No painel de navegação à esquerda, clique em Migration Tool. Localize a região que contém os recursos a serem migrados e clique em Migrate na coluna Actions. Na aba Resources, configure os parâmetros.

   Parâmetro	Descrição
   Type	O tipo da instância de destino do KMS.
   Instance	Selecione a instância de destino do KMS e defina-a como a instância padrão. Após a migração, se você criar um recurso sem especificar uma instância do KMS (seja no console do KMS 1.0 ou ao não fornecer um ID de instância do KMS em uma chamada de API), o recurso será criado no KMS 1.0 e marcado para migração. Para evitar isso, defina uma instância padrão durante a migração. Após definir uma instância padrão, os recursos criados sem uma instância do KMS especificada serão atribuídos automaticamente a essa instância padrão. Nota Se nenhuma instância padrão tiver sido definida para a região atual, a caixa de seleção Set as 3.0 Default Instance será selecionada automaticamente após a seleção de uma instância de destino do KMS. Se uma instância padrão já tiver sido definida para a região, a caixa de seleção não será marcada automaticamente. No entanto, se você selecionar uma instância diferente do KMS, a configuração padrão anterior será substituída automaticamente. Apenas uma instância padrão pode ser definida por região.
   Migration Method	Automatic Migration: Selecione um horário para a migração. O processo inicia automaticamente no horário especificado. Manual Migration (Start Now): A migração começa imediatamente após a configuração.
   Migration Time	Este parâmetro é obrigatório apenas se você selecionar Automatic Migration.
   Resources	Importante Antes de migrar, certifique-se de que sua instância do KMS tenha cota suficiente para evitar falhas na migração. Manually Select Resources: Selecione os recursos a serem migrados. É possível selecionar no máximo 50 chaves e 50 segredos por vez. Filtre os recursos por ID da chave, alias da chave e nome do segredo. Keys and Secrets: Migra todas as chaves e segredos pendentes de migração.

4. Leia atentamente as Migration Instructions, clique em OK, revise a lista de verificação de migração e clique em Migrate.

   Nota

   Visualize o progresso da migração na coluna Task Status. Quando a migração for concluída, uma mensagem Migration Completed será exibida.

5. Se a rotação automática estava ativada para chaves e segredos antes da migração, reative a rotação após a conclusão do processo. Para mais informações, consulte Key rotation e Overview of secret management.

Migração de várias contas

Para migrar recursos de várias contas da Alibaba Cloud para uma única instância do KMS, execute as etapas a seguir.

1. Prepare a instância de destino do KMS em uma das contas.

   • Se ainda não adquiriu uma instância do KMS, adquira e ative uma primeiro. Para mais informações, consulte Purchase and enable a KMS instance.

     Recomendamos ativar a renovação automática para a instância do KMS. Isso evita que a instância expire e seja liberada, o que causaria falhas de descriptografia e tornaria os dados da sua aplicação inacessíveis.

   • Caso já possua uma instância, verifique se a versão da imagem atende aos requisitos de migração.

     • Para uma instância de gerenciamento de chaves via software, se a versão da imagem for anterior à 2.9.0, atualize a imagem para a versão mais recente. Para mais informações, consulte Upgrade the image version of a KMS instance.

     • Para uma instância de gerenciamento de chaves via hardware, entre em contato com o suporte técnico da Alibaba Cloud para atualizar a versão da imagem.

3. Compartilhe a instância do KMS com as outras contas da Alibaba Cloud. Para mais informações, consulte as Etapas 1 a 3 em Share a KMS instance across multiple accounts.

   Importante

   O compartilhamento é suportado apenas dentro de um diretório de recursos, e tanto o proprietário do recurso quanto o principal devem pertencer à mesma empresa verificada.

4. Faça logon em cada conta da Alibaba Cloud e migre seus recursos para a instância do KMS. O procedimento é o mesmo utilizado para a migração de conta única.

Migração HSM BYOK**

Notas de uso

A migração de HSM BYOK é suportada apenas em regiões da China continental.

Procedimento

1. Faça logon no console do KMS 1.0. No painel de navegação à esquerda, clique em Migration Tool para abrir a página Migration Task Information. Localize a região onde está a chave a ser migrada e clique no número na coluna Unmigrated HSM BYOKs.

2. Na página Unmigrated HSM BYOKs, localize a chave HSM BYOK que deseja migrar e clique em Import Wrapped Key Material na coluna Actions.

3. Configurar informações de chave pública e token: Na página de importação de material de chave, configure os seguintes parâmetros e clique em Next.

   Parâmetro	Descrição
   Public Key Type	Selecione o tipo de chave pública usada para criptografar o material da chave. A seguinte opção é suportada: RSA_2048: Usa uma chave pública RSA de 2048 bits.
   Encryption Algorithm	Selecione o algoritmo de criptografia. As seguintes opções são suportadas: RSAES_OAEP_SHA_256 (Recomendado): Utiliza preenchimento RSA OAEP e o algoritmo de hash SHA-256. RSAES_PKCS1_V1_5: Utiliza preenchimento RSA PKCS#1 v1.5.
   Wrapping Key Format	Selecione o formato da chave de empacotamento a ser baixada. Os formatos suportados são der (padrão) e pem.

4. Baixar a chave pública de empacotamento e o token de importação: A importação de material de chave requer uma chave pública de empacotamento e um token de importação. A chave pública de empacotamento criptografa o material da chave para protegê-lo durante a importação, enquanto o token de importação autoriza o processo.

   • Public Key Format:

     • DER Format: O arquivo baixado é nomeado WrappingPublicKey**.bin por padrão.

     • PEM Format: O arquivo baixado é nomeado WrappingPublicKey**.pem por padrão.

   • Import Token: O arquivo baixado é nomeado ImportToken***.txt por padrão.

     Importante

     • Um token de importação é válido por 24 horas e pode ser reutilizado dentro desse período. Após a expiração, obtenha um novo token de importação e chave pública.

     • A chave pública de empacotamento e o token de importação devem ser usados em conjunto. Não utilize uma chave pública de empacotamento de um download com um token de importação de outro.

6. Criptografar o material da chave com a chave pública de empacotamento: Esta seção usa o OpenSSL para gerar material de chave com o algoritmo RSA_2048 como exemplo.

   1. Crie uma chave privada assimétrica de destino para o algoritmo RSA_2048 e converta-a para o formato PKCS#8.

      openssl genrsa -out TakPrivPkcs1.pem 2048
      openssl pkcs8 -topk8 -inform PEM -in TakPrivPkcs1.pem -outform der -nocrypt -out TakPrivPkcs8.bin

   2. Crie uma chave simétrica efêmera (ESK) para o algoritmo AES_256.

      openssl rand -out EskAes256.bin 32

   3. Use a chave pública de empacotamento de importação (IWKpub) para criptografar a chave simétrica efêmera (ESK) e obter o texto cifrado da chave simétrica efêmera (Cipher(ESK)). A criptografia padrão RSAES OAEP é utilizada, onde MGF1 e o algoritmo de hash são 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

      Nota

      Substitua PublicKey.pem pelo nome do arquivo de chave pública baixado do console do KMS.

   4. Utilize a chave simétrica efêmera (ESK) para criptografar a chave privada assimétrica de destino (TAKpriv) e gerar o texto cifrado da chave privada (Cipher(TAKpriv)). O modo de criptografia é ECB e o modo de preenchimento é 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. Monte os dados resultantes no formato Cipher(ESK) || Cipher(TAKpriv) e codifique em Base64.

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

      Nota

      EncryptedKeyMaterial_base64.txt é o arquivo de material de chave que pode ser importado para o KMS.

7. Importar o material de chave de migração: Na página de importação de material de chave, configure os seguintes parâmetros e clique em OK.

   Importante

   O material de chave para migração é válido por 21 dias. Se a migração não for realizada dentro desse período, reimporte o material da chave.

   Parâmetro	Descrição
   Key Material Format	Selecione o formato do material de chave a ser enviado. Os formatos suportados são base64 (padrão) e bin.
   Wrapped Key Material	Envie o arquivo de material de chave criptografado com a chave pública de empacotamento.
   Import Token	Envie o arquivo de token de importação baixado na Etapa 4.
   Set Expiration Time	Defina um tempo de expiração para o material da chave. As seguintes opções são suportadas: Never expires (Padrão): O material da chave nunca expira. Custom: Defina um tempo de expiração personalizado para o material da chave. O material da chave será excluído às 00:00 (UTC+8) na data especificada.

8. Executar a migração: Retorne à página Migration Task Information, localize a região onde o HSM BYOK de destino está situado e clique em Migrate na coluna Actions. Na aba Resources, configure os parâmetros.

   • Type: Hardware Management Instance.

   • Resources: Selecione Manually select resources e, em seguida, selecione a chave HSM BYOK de destino.Resource Name

Solução de problemas

• "current hardware BYOK key was not imported for migration": Indica que o material de chave de migração ainda não foi importado para a chave HSM BYOK. Complete primeiro o procedimento de importação de material de chave descrito neste tópico.

• "current hardware BYOK key material is expired, please reimport": Indica que o material de chave de migração expirou porque seu período de validade de 21 dias passou. Reimporte o material da chave.

3. Operações pós-migração

Importante

Após a migração, o KMS aplica uma política padrão às chaves e segredos migrados. Para mais informações, consulte Overview of key policies e Overview of secret policies.

1. Faça logon no console do KMS 3.0 para visualizar e confirmar os recursos migrados.

   • Chaves de service

     1. Acesse a página Keys e selecione uma região na barra de menu superior.

     2. Clique na aba Default Keys. Verifique se suas chaves de service estão listadas e se a coluna Key Usage está definida como Service Key.

   • Chaves mestras de cliente

     1. Acesse a página Keys e selecione uma região na barra de menu superior.

     2. Clique na aba Customer Master Keys e verifique se as chaves mestras de cliente migradas são exibidas.

     Se algumas CMKs não forem exibidas no console do KMS 3.0 após a migração, verifique o seguinte:

     • Verifique se a chave foi migrada com sucesso.

     • Confirme se a chave não é uma chave de service. Chaves de service são criadas e gerenciadas por services da Alibaba Cloud e não aparecem listadas em Customer Master Keys.

     • Caso confirme que a chave foi migrada com sucesso, mas ela ainda não apareça no console do KMS 3.0, o problema pode ser causado por dados obsoletos no console. Entre em contato com o suporte técnico da Alibaba Cloud para corrigir os dados obsoletos. Após a resolução do problema, a CMK será restaurada e exibida normalmente.

   • Segredos

     1. Acesse a página Secrets e selecione uma região na barra de menu superior.

     2. Selecione a instância do KMS e confirme se os segredos migrados estão listados. Em seguida, selecione a aba Self-managed secrets. A interface é organizada da seguinte forma: O painel de filtros à esquerda lista cada tipo de segredo e sua contagem, incluindo generic secret, RAM Secrets, database secret e ECS secret. A lista à direita mostra o nome do segredo, tipo do segredo, criador, data de criação, tags, descrição e ações (Details, Schedule deletion, Cancel deletion).

3. Se você utiliza o Terraform para gerenciar recursos do KMS, modifique a configuração do Terraform. Para mais informações, consulte Modify configurations after migration in a Terraform scenario.

4. Monitoramento da migração

Para garantir uma migração de chaves tranquila, observável e rastreável, recomendamos o uso do Cloud Monitor, Simple Log Service (SLS) e ActionTrail para monitorar integralmente os gateways compartilhados e dedicados antes, durante e após a migração. As seções a seguir descrevem pontos-chave de observação e ações recomendadas.

1. Antes da migração: Observe o painel do gateway compartilhado

   Até que você conclua a migração e alterne o endpoint do cliente, todas as solicitações do KMS continuam sendo processadas pelo gateway compartilhado. Nesta etapa, concentre-se na estabilidade e no desempenho do gateway compartilhado.

   • Objetivo: Confirmar que a migração não causa cargas anormais ou erros no gateway compartilhado.

   • Métricas a observar:

     • Latência de solicitação: Verifique se há algum aumento significativo.

     • Distribuição de códigos de erro (como 4xx e 5xx): Confirme que não há aumento repentino de erros anormais.

     • Tendências de QPS/TPS: Compare o tráfego antes e depois da migração para garantir consistência. Isso ajuda a prevenir picos de solicitações ou interrupções causadas por operações incorretas.

   • Como visualizar:

     • Método 1: Faça logon no console do KMS 3.0. Na página Overview, verifique métricas como latência de solicitação e códigos de erro no painel Shared Gateway.

     • Método 2: Faça logon no console do Cloud Monitor. Na seção Product Monitoring, pesquise por Key Management Service para visualizar o painel Shared gateway.

   Nota

   Recomendamos registrar as métricas de linha de base antes da migração para usar como referência de comparação.

2. Após a migração: Observe simultaneamente os painéis do gateway compartilhado e do gateway dedicado

   • Antes de alternar o endpoint: Continue observando o gateway compartilhado. Embora as chaves tenham sido migradas para uma instância dedicada, as solicitações ainda são roteadas pelo gateway compartilhado até que você alterne o endpoint do cliente. O gateway compartilhado encaminha transparentemente essas solicitações para a instância dedicada de backend.

   • Após alternar o endpoint: Observe simultaneamente os gateways compartilhado e dedicado. Depois que o cliente concluir a alternância do endpoint, as solicitações acessarão diretamente a instância dedicada através do gateway dedicado. Neste ponto, monitore ambos os gateways:

     Tipo de gateway	Pontos-chave de observação	Método
     Gateway dedicado	Códigos de erro Alterações na latência de solicitação Tendências de QPS correspondem às expectativas	Cloud Monitor: Painel do gateway dedicado do KMS
     Gateway compartilhado	Verifique se o tráfego fez a transição completa. Identifique quaisquer solicitações remanescentes ou anormais.	Observe o painel do gateway compartilhado para a região correspondente

     Nota

     Critérios para identificar anomalias:

     • Se o gateway dedicado reportar um alto número de erros de limitação, ajuste o tipo de instância ou a política de limitação.

     • Caso o gateway compartilhado ainda receba uma alta frequência de solicitações, isso indica que alguns clientes não alternaram os endpoints. Investigue o problema.

3. Observação em nível de log: Analise logs de acesso detalhados usando o SLS

   Para obter rastreamento de solicitações mais granular e diagnóstico de problemas, recomendamos ativar os seguintes recursos de coleta de logs:

   • Logs de acesso do gateway dedicado:

     • Adquira o service adicional de análise de logs para gateways dedicados para entregar logs automaticamente ao Simple Log Service (SLS).

     • Consulte e analise logs por campos como ID da chave, ID da conta Alibaba Cloud, operação de API e código de status de resposta.

   • Logs de acesso detalhados do gateway compartilhado:

     • Ative o ActionTrail e entregue rastros de eventos para um Logstore do SLS especificado.

     • Analise comportamentos específicos de solicitação consultando condições como EventName = "Decrypt" e ResourceType = "KMS".

     • Use o campo ErrorCode para determinar a causa de falhas, como permissões insuficientes ou uma chave inexistente.

5. Estratégia de monitoramento recomendada

   Fase	Foco do monitoramento	Ferramenta
   Antes da migração	Estabilidade do gateway compartilhado	Painel do Cloud Monitor
   Durante a alternância	Taxa de sucesso de solicitações, mudanças repentinas na latência	Monitoramento em tempo real + alertas do SLS
   Após a migração	Status de integridade do gateway dedicado	Painel do gateway dedicado + logs do SLS
   Durante todo o processo	Tendências anormais de códigos de erro	ActionTrail + análise agregada do SLS