Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Habilitar uma segunda camada de criptografia para dados em repouso usando Chaves Gerenciadas pelo Cliente durante a criação de uma nova conta do Azure Cosmos DB está disponível em geral há algum tempo. Como próxima etapa natural, agora temos a capacidade de habilitar a CMK em contas existentes do Azure Cosmos DB.
Esse recurso elimina a necessidade de migração de dados para uma nova conta para habilitar a CMK. Ajuda a melhorar a postura de segurança e conformidade dos clientes.
A ativação da CMK inicia um processo assíncrono em segundo plano para criptografar todos os dados existentes na conta, enquanto os novos dados recebidos são criptografados antes de persistir. Não há necessidade de esperar que a operação assíncrona seja bem-sucedida. O processo de habilitação consome RUs não utilizadas/sobressalentes para que não afete suas cargas de trabalho de leitura/gravação. Você pode consultar este link para planejamento de capacidade assim que sua conta for criptografada.
Comece ativando a CMK em suas contas existentes
Importante
Percorra a seção de pré-requisitos minuciosamente. Estes pré-requisitos são considerações importantes.
Pré-requisitos
Todas as etapas de pré-requisito necessárias durante a configuração das Chaves Gerenciadas pelo Cliente para novas contas são aplicáveis para habilitar a CMK em sua conta existente. Consulte os passos aqui
Observação
É importante observar que habilitar a criptografia em sua conta do Azure Cosmos DB adiciona uma pequena sobrecarga à ID do documento, limitando o tamanho máximo da ID do documento a 990 bytes em vez de 1.024 bytes. Se a sua conta tiver documentos com IDs maiores que 990 bytes, o processo de criptografia falhará até que esses documentos sejam excluídos.
Para verificar se sua conta está em conformidade, você pode usar o aplicativo de console fornecido hospedado aqui para verificar sua conta. Certifica-te de que estás a utilizar o endpoint da tua propriedade de conta 'sqlEndpoint', independentemente da API selecionada.
Se você deseja desativar a validação do lado do servidor para isso durante a migração, entre em contato com o suporte.
Passos para ativar a CMK na sua conta existente
Para habilitar a CMK numa conta existente, atualize a conta com um modelo ARM definindo um identificador de chave do Cofre de Chaves na propriedade keyVaultKeyUri – tal como faria ao habilitar a CMK numa nova conta. Esta etapa pode ser feita emitindo uma chamada PATCH com a seguinte carga útil:
{
"properties": {
"keyVaultKeyUri": "<key-vault-key-uri>"
}
}
A saída deste comando CLI para habilitar a CMK aguarda a conclusão da criptografia de dados.
az cosmosdb update --name "testaccount" --resource-group "testrg" --key-uri "https://keyvaultname.vault.azure.net/keys/key1"
Etapas para habilitar a CMK em sua conta existente do Azure Cosmos DB com backup contínuo ou conta de armazenamento analítico
Para habilitar a CMK em uma conta existente que tenha backup contínuo e restauração point-in-time habilitados, precisamos seguir algumas etapas extras. Siga o passo 1 ao passo 5 e, em seguida, siga as instruções para ativar a CMK na conta existente.
Configurar identidade gerida para a conta Cosmos Configurar identidades geridas com a ID do Microsoft Entra para a conta Azure Cosmos DB
Atualizar a conta Cosmos para definir a identidade padrão de modo a apontar para a identidade gerida adicionada na etapa anterior.
Para identidade gerenciada pelo sistema:
az cosmosdb update--resource-group $resourceGroupName --name $accountName --default-identity "SystemAssignedIdentity"Para identidade gerenciada pelo usuário :
az cosmosdb update -n $sourceAccountName -g $resourceGroupName --default-identity "UserAssignedIdentity=/subscriptions/00000000-0000-0000-0000-00000000/resourcegroups/MyRG/providers/Microsoft.ManagedIdentity/userAssignedIdentities/MyID"Configure o Keyvault conforme indicado na documentação aqui
Adicionar política de acesso no keyvault para a identidade padrão definida na etapa anterior
Atualize a conta cosmos para definir o URI do cofre de chaves; esta atualização aciona a ativação do CMK na conta.
az cosmosdb update --name $accountName --resource-group $resourceGroupName --key-uri $keyVaultKeyURI
Limitações conhecidas
- Não há suporte para habilitar a CMK em contas existentes do Azure Cosmos DB para Apache Cassandra.
- A ativação da CMK está disponível apenas a nível de conta Cosmos DB e não em coleções.
- Certifique-se de que a conta não possui documentos com IDs grandes superiores a 990 bytes antes de ativar a CMK. Caso contrário, receberá um erro devido ao limite máximo suportado de 1.024 bytes após a encriptação.
- Durante a criptografia de dados existentes, as ações do plano de controle, como "adicionar região", são bloqueadas. Essas ações são desbloqueadas e podem ser usadas logo após a conclusão da criptografia.
- Não há suporte para habilitar a CMK em contas existentes do Azure Cosmos DB que tenham a Pesquisa Vetorial habilitada .
Monitorar o progresso da criptografia resultante
Habilitar a CMK em uma conta existente é uma operação assíncrona que inicia uma tarefa em segundo plano que criptografa todos os dados existentes. Como tal, a solicitação de API REST para habilitar a CMK fornece em sua resposta uma URL "Azure-AsyncOperation". Consultar este URL com as solicitações GET retorna o status da operação geral, que por fim é bem-sucedida. Este mecanismo é descrito na íntegra neste artigo.
A conta do Cosmos DB pode continuar sendo usada e os dados podem continuar a ser gravados sem esperar que a operação assíncrona seja bem-sucedida. O comando CLI para habilitar a CMK aguarda a conclusão da criptografia de dados.
Para permitir que uma conta existente do Cosmos DB seja usada na CMK, uma verificação precisa ser feita para garantir que a conta não tenha "IDs grandes". Um "ID grande" é um ID de documento que excede 990 caracteres. Essa verificação é obrigatória para a migração CMK e é feita pela Microsoft automaticamente. Durante esse processo, você pode ver um erro.
ERRO: (InternalServerError) Erro inesperado na verificação de documentos para migração CMK. Por favor, tente novamente a operação.
Esse erro acontece quando o processo de verificação usa mais RUs do que os provisionados na coleção, lançando um erro 429. Uma solução para este problema é aumentar temporariamente de forma significativa as suas Unidades de Recurso (RUs). Como alternativa, você pode usar o aplicativo de console fornecido hospedado aqui para verificar suas coleções.
Observação
Se você deseja desativar a validação do lado do servidor para isso durante a migração, entre em contato com o suporte. Desativar a validação é aconselhável apenas se você tiver certeza de que não há IDs grandes. Se for encontrado um Large ID durante a encriptação, o processo é interrompido até que o documento Large ID seja resolvido.
Se tiver mais perguntas, contacte o Suporte da Microsoft.
FAQs
Quais são os fatores dos quais o tempo de criptografia depende?
A habilitação da CMK é uma operação assíncrona e depende da disponibilidade de suficientes RUs não utilizadas. Sugerimos ativar a CMK fora do horário de pico e, se aplicável, pode aumentar as RUs antecipadamente, para acelerar a criptografia. É também uma função direta do tamanho dos dados.
Precisamos nos preparar para o tempo de inatividade?
A ativação da CMK inicia um processo assíncrono em segundo plano para criptografar todos os dados. Não há necessidade de esperar que a operação assíncrona seja bem-sucedida. A conta do Azure Cosmos DB está disponível para leituras e gravações e não há necessidade de um tempo de inatividade.
Você pode aumentar as RUs uma vez que a CMK foi acionada?
Sugerimos aumentar as RUs antes de acionar CMK. Depois que a CMK é acionada, algumas operações do plano de controle são bloqueadas até que a criptografia seja concluída. Esse bloqueio pode impedir que o usuário aumente as RUs uma vez que a CMK é acionada.
Para permitir que uma conta existente do Cosmos DB seja usada com CMK, uma verificação Large ID é realizada automaticamente pela Microsoft para resolver uma das limitações conhecidas listadas anteriormente. Este processo também consome RUs extras e é uma boa ideia aumentar significativamente os RUs para evitar o erro 429.
Existe uma maneira de reverter a criptografia ou desativar a criptografia depois de acionar a CMK?
Uma vez que o processo de criptografia de dados usando CMK é acionado, ele não pode ser revertido.
A ativação da criptografia usando CMK na conta existente terá impacto no tamanho dos dados e nas leituras/gravações?
Como seria de esperar, ao ativar a CMK, há um ligeiro aumento no tamanho dos dados e nas RUs para acomodar o processamento extra de encriptação/desencriptação.
Você deve fazer backup dos dados antes de ativar a CMK?
Ativar a CMK não representa nenhuma ameaça de perda de dados.
Os backups antigos são feitos como parte do backup periódico criptografado?
Não. Os backups periódicos antigos não são criptografados. Os backups recém-gerados após a ativação da CMK são criptografados.
Qual é o comportamento em contas existentes habilitadas para backup contínuo?
Quando a CMK está ativada, a criptografia também é ativada para backups contínuos. Quando a CMK estiver ativada, todas as contas restauradas daqui para frente serão habilitadas para CMK.
Qual é o comportamento se a CMK estiver habilitada na conta habilitada para PITR e restaurarmos a conta para o momento em que a CMK foi desativada?
Nesse caso, a CMK está explicitamente habilitada na conta de destino restaurada pelos seguintes motivos:
- Uma vez que a CMK está ativada na conta, é impossível desativar a CMK.
- Esse comportamento está alinhado com o design atual de restauração da conta habilitada para CMK com backup periódico
O que acontece quando o usuário revoga a chave enquanto a migração CMK está em andamento?
O estado da chave é verificado quando a criptografia CMK é acionada. Se a chave no cofre da Chave do Azure estiver em situação regular, a criptografia será iniciada e o processo será concluído sem verificação adicional. Mesmo que a chave seja revogada ou o cofre de chaves do Azure seja excluído ou indisponível, o processo de criptografia será bem-sucedido.
Podemos ativar a criptografia CMK em nossa conta de produção existente?
Yes. Percorra minuciosamente a seção de pré-requisitos. Recomendamos testar todos os cenários primeiro em contas de não produção e, quando estiver confortável, poderá considerar contas de produção.
Como faço para migrar uma conta do Azure Cosmos DB para um locatário diferente?
Se a sua conta do Cosmos DB tiver as Chaves Geridas pelo Cliente ativadas, só poderá migrar a conta se for uma conta de chave gerida pelo cliente entre locatários diferentes. Para obter mais informações, consulte o guia sobre como configurar chaves gerenciadas pelo cliente entre locatários para sua conta do Azure Cosmos DB com o Azure Key Vault.
Warning
Após a migração, é crucial manter a conta do Azure Cosmos DB e o Cofre da Chave do Azure em locatários separados para preservar a relação original entre locatários. Verifique se a chave do Cofre da Chave permanece no lugar até que a migração da conta do Cosmos DB seja concluída.
Passos seguintes
- Saiba mais sobre a criptografia de dados no Azure Cosmos DB.
- Consulte o artigo Chaves gerenciadas pelo cliente para obter etapas detalhadas se você optar por adicionar uma segunda camada de criptografia com sua própria chave.
- Explore as certificações Microsoft na Central de Confiabilidade do Azure.