Compartilhar via

Chaves gerenciadas pelos clientes do Azure Monitor

  • Artigo

Os dados no Azure Monitor são criptografados com chaves gerenciadas pela Microsoft. Você pode usar a própria chave de criptografia para proteger os dados e as consultas salvas nos workspaces. As chaves gerenciadas pelo cliente no Azure Monitor dão maior flexibilidade para gerenciar os controles de acesso aos logs. Depois de configurados, os novos dados ingeridos em workspaces vinculados são criptografados com sua chave armazenada no Azure Key Vault ou no "HSM" Gerenciado do Azure Key Vault.

Examine as limitações e restrições antes da configuração.

Visão geral da chave gerenciada pelo cliente

Criptografia em repouso é um requisito comum de privacidade e segurança em organizações. Você pode permitir que o Azure gerencie completamente a criptografia em repouso ou você pode usar várias opções para gerenciar atentamente a criptografia e as chaves de criptografia.

O Azure Monitor garante que todos os dados e consultas salvos sejam criptografados em repouso com as chaves gerenciadas pela Microsoft (MMK). O uso da criptografia pelo Azure Monitor é idêntico à forma como o Armazenamento do Microsoft Azure funciona.

Para gerenciar o ciclo de vida da chave e poder revogar o acesso aos seus dados, você pode criptografar dados com sua própria chave usando o Azure Key Vault.

As chaves gerenciadas pelo cliente estão disponíveis em clusters dedicados e fornecem um nível mais alto de proteção e controle. Os dados são criptografados no armazenamento duas vezes, uma no nível do serviço usando chaves gerenciadas pela Microsoft ou chaves gerenciadas pelo cliente, e outra no nível de infraestrutura, usando dois algoritmos de criptografia diferentes e duas chaves diferentes. A criptografia dupla protege contra um cenário em que um dos algoritmos ou chaves de criptografia pode estar comprometido. O cluster dedicado também permite proteger dados com o Sistema de Proteção.

Os dados ingeridos nos últimos 14 dias ou usados recentemente em consultas são mantidos em cache frequente (com suporte de SSD) para eficiência da consulta. Os dados do SSD são criptografados com chaves da Microsoft, seja qual for a chave gerenciada pelo cliente, mas seu controle sobre o acesso ao SSD segue a revogação de chave.

Importante

Os clusters dedicados usam um modelo de preço de nível de compromisso de pelo menos 100 GB/dia.

Como funciona a chave gerenciada pelo cliente no Azure Monitor

O Azure Monitor usa identidade gerenciada para conceder acesso ao Azure Key Vault. A identidade do cluster de Log Analytics é permitida no nível de cluster. Para permitir uma chave gerenciada pelo cliente em vários workspaces, um recurso de Cluster do Log Analytics realiza uma conexão de identidade intermediária entre seus workspaces do Log Analytics e Key Vault. O armazenamento do cluster usa a identidade gerenciada associada ao cluster para autenticar o Azure Key Vault através do Microsoft Entra ID.

Os clusters permitem dois tipos de identidade gerenciados: atribuídos pelo sistema e atribuídos pelo usuário, enquanto uma única identidade pode ser definida em um cluster, dependendo do cenário.

  • A identidade gerenciada atribuída pelo sistema é mais simples e gerada automaticamente com o cluster quando o identity type estiver definido como SystemAssigned. Essa identidade é usada posteriormente para conceder acesso de armazenamento ao seu Key Vault para fins de criptografia e descriptografia de dados.
  • A identidade gerenciada atribuída pelo usuário permite que você configure chaves gerenciadas pelo cliente na criação do cluster, quando o identity type estiver definido como UserAssigned e concedendo-lhe permissões no seu Key Vault antes da criação do cluster.

Você pode configurar chaves gerenciadas pelo cliente a um novo cluster ou a um cluster existente que é vinculado aos workspaces e já está ingerindo dados. Novos dados ingeridos em workspaces vinculados são criptografados com sua chave, e os dados mais antigos ingeridos antes da configuração permanecem criptografados com chaves da Microsoft. A configuração de chave gerenciada pelo cliente não afeta suas consultas, que continuam sendo executadas em dados antigos e novos de forma integrada. Você pode desvincular os workspaces de um cluster quando quiser. Os novos dados ingeridos após a desvinculação são criptografados com chaves da Microsoft e as consultas são realizadas em dados novos e antigos de forma integrada.

Importante

A capacidade das chaves gerenciadas pelo cliente é regional. Seu Azure Key Vault, cluster e workspaces vinculados precisam estar na mesma região, mas podem estar em assinaturas diferentes.

Captura de tela da visão geral da chave gerenciada pelo cliente.

  1. Key Vault
  2. O recurso do cluster do Log Analytics que tem uma identidade gerenciada com permissões para Key Vault: a identidade é propagada para o armazenamento de cluster dedicado subjacente
  3. Cluster dedicado
  4. Workspaces vinculados ao cluster dedicado

Operação de chaves de criptografia

Há três tipos de chaves envolvidas na criptografia de dados de Armazenamento:

  • "KEK" – Chave de criptografia de chave (sua chave gerenciada pelo cliente)
  • "AEK" – Chave de criptografia da conta
  • "DEK" – Chave de criptografia dos dados

As seguintes regras se aplicam:

  • O armazenamento de cluster tem uma chave de criptografia exclusiva para cada conta de armazenamento, que é conhecida como AEK.
  • A AEK é usada para derivar DEKs, que são as chaves usadas para criptografar cada bloco de dados gravado no disco.
  • Quando você configura uma chave em seu Key Vault e atualiza os detalhes da chave no cluster, o armazenamento de cluster executa solicitações para encapsular e desencapsular a AEK para criptografia e descriptografia.
  • A sua "KEK" nunca deixa seu Key Vault e, no caso de um "HSM" gerenciado, nunca deixa o hardware.
  • O Armazenamento do Microsoft Azure usa a identidade gerenciada associada ao recurso de cluster para autenticação. Ele acessa o Azure Key Vault por meio da ID do Microsoft Entra.

Etapas de provisionamento dachave gerenciada pelo cliente

  1. Criar o Azure Key Vault e armazenar a chave
  2. Criar cluster
  3. Conceder permissões ao Key Vault
  4. Atualizar cluster com detalhes do identificador de chave
  5. Vinculando workspaces

A configuração de chave gerenciada pelo cliente não é permitida no portal do Azure atualmente e o provisionamento pode ser executado por meio do PowerShell, da CLI ou de solicitações REST.

Armazenamento da chave de criptografia (KEK)

Um portfólio de produtos de Gerenciamento de Chaves do Azure lista os cofres e os HSMs gerenciados que podem ser usados.

Crie ou use um Azure Key Vault existente na região em que o cluster está planejado. No cofre de chaves, gere ou importe uma chave a ser usada para criptografia de logs. O Azure Key Vault precisa ser configurado como recuperável para proteger sua chave e o acesso aos dados no Azure Monitor. Você pode verificar essa configuração em propriedades no seu Key Vault, a Exclusão temporária e a Proteção contra limpeza devem ser habilitadas.

Captura de tela das configurações de proteção contra exclusão temporária e limpeza reversível.

Essas configurações podem ser atualizadas no Key Vault via CLI e PowerShell:

Criar cluster

Os clusters utilizam identidade gerenciada para criptografia de dados com seu Key Vault. Configure a propriedade identity type como SystemAssigned ou UserAssigned ao criar seu cluster para permitir o acesso ao seu Key Vault para operações de criptografia e descriptografia de dados.

Configurações de identidade no cluster para identidade gerenciada atribuída pelo sistema

{
  "identity": {
    "type": "SystemAssigned"
    }
}

Observação

O tipo de identidade pode ser alterado após o cluster ter sido criado, sem interrupção para ingestão ou consultas, com as seguintes considerações

  • Atualizando SystemAssigned para UserAssigned: conceda a identidade atribuída pelo usuário no Key Vault e, em seguida, atualize o identity type no cluster
  • Atualizando UserAssigned para SystemAssigned: como a identidade gerenciada atribuída pelo sistema foi criada após a atualização do identity type do cluster com SystemAssigned, as etapas a seguir devem ser seguidas
    1. Atualize o cluster e remova a chave: defina keyVaultUri, keyName e keyVersion com o valor ""
    2. Atualize o identity type do cluster para SystemAssigned
    3. Atualize o Key Vault e conceda permissões à identidade
    4. Atualize a chave no cluster

Siga o artigo procedimento ilustrado no artigo de clusters dedicados.

Conceder permissões do Key Vault

Existem dois modelos de permissão no Key Vault para conceder acesso ao cluster e ao armazenamento subjacente: controle de acesso baseado em função do Azure (Azure RBAC) e políticas de acesso ao Vault (herdado).

  1. Atribua o RBAC do Azure que você controla (recomendado)

    Para adicionar atribuições de função, você precisa ter uma função com permissões Microsoft.Authorization/roleAssignments/write e Microsoft.Authorization/roleAssignments/delete, como Administrador de Acesso do Usuário ou Proprietário.

    1. Abra o Key Vault no portal do Azure e selecione Configurações>Configuração de acesso>Controle de acesso baseado em função do Azure e Aplicar
    2. Clique no botão Ir para o controle de acesso (IAM) e adicione a atribuição de função Usuário de Criptografia do Serviço de Criptografia do Key Vault.
    3. Selecione Identidade gerenciada na guia Membros e selecione a assinatura para a identidade e a identidade como membro

    Captura de tela das permissões RBAC da Concessão do Key Vault.

  2. Atribuir a política de acesso ao cofre (herdado)

    Abra o Key Vault no portal do Azure e selecione Políticas de Acesso>Política de acesso do Cofre>+ Adicionar política de acesso para criar uma política com essas configurações:

    • Permissões da chave: selecione Obter, Encapsular Chave e Desencapsular Chave.
    • Selecionar entidade de segurança – dependendo do tipo de identidade usado no cluster (identidade gerenciada atribuída pelo sistema ou pelo usuário)
      • Identidade gerenciada atribuída pelo sistema – insira o nome do cluster ou a ID da entidade de segurança do cluster
      • Identidade gerenciada atribuída pelo usuário – insira o nome da identidade

    Captura de tela das permissões da política de acesso da Concessão do Key Vault.

    A permissão Obter é necessária para verificar se o Key Vault está configurado como recuperável para proteger sua chave e o acesso aos seus dados do Azure Monitor.

Atualizar cluster com detalhes do identificador de chave

Todas as operações no cluster exigem a permissão de ação Microsoft.OperationalInsights/clusters/write. Essa permissão pode ser concedida por meio do proprietário ou colaborador que contém a ação */write ou por meio da função colaborador do Log Analytics que contém a ação Microsoft.OperationalInsights/*.

Esta etapa atualiza o armazenamento de cluster dedicado com a chave e a versão a usar para encapsulamento e desencapsulamento de AEK.

Importante

  • A rotação de chaves pode ser automática ou por versão explícita da chave; confira Rotação de chaves para determinar a abordagem adequada para você antes de atualizar os detalhes do identificador de chaves no cluster.
  • A atualização do cluster não deve incluir os detalhes do identificador da chave e da identidade na mesma operação. Se você precisar atualizar ambos, a atualização deverá ocorrer em duas operações consecutivas.

Captura de tela de Conceder permissões do Key Vault.

Atualize o KeyVaultProperties no cluster com os detalhes do identificador de chave.

A operação é assíncrona e pode levar um tempo para ser concluída.

N/D

Importante

Essa etapa deve ser executada somente após o provisionamento do cluster. Se você vincular workspaces e ingerir dados antes do provisionamento, os dados ingeridos serão descartados e não poderão ser recuperados.

Você precisa ter permissões de gravação tanto no workspace, quanto no cluster para executar essa operação. Ele inclui Microsoft.OperationalInsights/workspaces/write e Microsoft.OperationalInsights/clusters/write.

Siga o artigo procedimento ilustrado no artigo de clusters dedicados.

Revogação de chave

Importante

  • A maneira recomendada para revogar o acesso aos seus dados é desabilitar a chave ou excluir a política de acesso no Key Vault.
  • Configurar o identity type do cluster para None também revoga o acesso aos seus dados, mas essa abordagem não é recomendada, pois você não pode revertê-la sem entrar em contato com o suporte.

O armazenamento de cluster sempre respeita as alterações nas permissões da chave dentro de uma hora ou menos e o armazenamento fica indisponível. Novos dados ingeridos em workspaces vinculados são descartados e não são recuperáveis. Os dados ficam inacessíveis nesses workspaces e as consultas falham. Os dados anteriormente ingeridos permanecem no armazenamento, desde que seu cluster e workspaces não sejam excluídos. Os dados inacessíveis são regidos pela política de retenção de dados e são limpos quando a retenção é atingida. Os dados ingeridos nos últimos 14 dias e os dados usados recentemente em consultas também são mantidos em cache frequente (com suporte de SSD) para eficiência da consulta. Os dados no SSD são excluídos na operação de revogação de chave e se torna inacessível. O armazenamento de cluster tenta acessar o Key Vault para encapsular e desembrulhar periodicamente e, quando a chave estiver habilitada, o desembrulhamento for bem-sucedido, os dados SSD serão recarregados do armazenamento e a ingestão de dados e a consulta serão retomadas dentro de 30 minutos.

Alteração de chaves

A rotação de chaves tem dois modos:

  • Rotação automática: atualize as propriedades "keyVaultProperties" no cluster e omita a propriedade "keyVersion", ou a defina como "". O armazenamento usa automaticamente a versão mais recente da chave.
  • Atualização da versão explícita da chave: atualize as propriedades "keyVaultProperties" e atualize a versão da chave na propriedade "keyVersion". A rotação de chaves requer uma atualização explícita da propriedade "keyVersion" no cluster. Para obter mais informações, confira Atualizar cluster com detalhes do identificador de chave. Se você gerar uma nova versão de chave no Key Vault, mas não atualizá-la no cluster, o armazenamento do cluster continuará usando sua chave anterior. Se você desabilitar ou excluir a chave antiga antes de atualizar a nova chave no cluster, entrará no estado de revogação de chave.

Todos os seus dados permanecem acessíveis durante e após a operação de rotação de chave. Os dados sempre são criptografados com a AEK (chave de criptografia de conta), que é criptografada com sua nova versão de KEK (chave de criptografia de chave) no Key Vault.

Chave gerenciada pelo cliente para consultas salvas e alertas de log

A linguagem de consulta usada no Log Analytics é expressiva e pode conter informações confidenciais em comentários ou na sintaxe de consulta. Algumas organizações exigem que essas informações sejam protegidas na política de chave gerenciada pelo cliente e você precisa salvar suas consultas criptografadas com sua chave. O Azure Monitor permite armazenar consultas salvas e alertas de pesquisa de log criptografados com sua chave em sua própria Conta de Armazenamento quando vinculado ao seu workspace.

Chave gerenciada pelo cliente para Pastas de Trabalho

Com as considerações mencionadas em Chave gerenciada pelo cliente para consultas salvas e alertas de pesquisa de logs, o Azure Monitor habilita o armazenamento de consultas da Pasta de Trabalho criptografadas com sua chave em sua própria Conta de Armazenamento, ao selecionar Salvar conteúdo em uma Conta de Armazenamento do Microsoft Azure na operação "Salvar" da Pasta de Trabalho.

Captura de tela da pasta de trabalho salva.

Observação

As consultas permanecem criptografadas com a chave da Microsoft ("MMK") nos seguintes cenários, independentemente da configuração da chave gerenciada pelo cliente: Painéis do Azure, Aplicativos Lógicos do Azure, Notebooks do Azure e Runbooks de Automação.

Ao vincular sua conta de armazenamento para consultas salvas, o serviço armazena consultas salvas e consultas de alerta de pesquisa de log em sua conta de armazenamento. Tendo controle em sua conta de armazenamento política de criptografia em repouso, você pode proteger consultas salvas e alertas de pesquisa de log com chave gerenciada pelo cliente. No entanto, você será responsável pelos custos associados a essa conta de armazenamento.

Considerações antes de definir a chave gerenciada pelo cliente para consultas

  • Você precisa ter permissões de gravação no workspace e na conta de armazenamento.
  • Crie sua Conta de Armazenamento na mesma região em que o workspace do Log Analytics está localizado, com criptografia de chave gerenciada pelo cliente. Isso é importante porque as consultas guardadas são armazenadas no armazenamento de tabelas e só podem ser encriptadas na criação da Conta de Armazenamento.
  • As consultas salvas no pacote de consultas não são criptografadas com a chave gerenciada pelo cliente. Selecione Salvar como consulta herdada ao salvar consultas para protegê-las com a chave gerenciada pelo cliente.
  • As consultas salvas no armazenamento são consideradas artefatos de serviço e seu formato pode ser alterado.
  • Vincular uma conta de armazenamento para consultas remove as consultas salvas existentes do seu workspace. A cópia salva as consultas que você precisa antes dessa configuração. Você pode exibir as consultas salvas utilizando o PowerShell.
  • Não há suporte para consultar "histórico" e "fixar no painel" ao vincular a Conta de Armazenamento para consultas.
  • Você pode vincular uma única conta de armazenamento a um workspace para consultas salvas e consultas de alerta de pesquisa de log.
  • Os alertas de pesquisa de log são salvos no armazenamento de blobs e a criptografia de chave gerenciada pelo cliente pode ser configurada na criação da conta de armazenamento ou posteriormente.
  • Os alertas de pesquisa de log disparados não conterão os resultados da pesquisa nem a consulta de alerta. Você pode usar as dimensões de alerta para obter contexto nos alertas acionados.

Configurar o BYOS para consultas salvas

Vincule uma conta de armazenamento para consultas para manter as consultas salvas na sua conta de armazenamento.

N/D

Depois da configuração, qualquer nova consulta de pesquisa salva será salva no armazenamento.

Configurar o BYOS para consultas de alertas de pesquisa de log

Vincule uma conta de armazenamento para Alertas a fim de manter as consultas de alertas de pesquisa de log em sua conta de armazenamento.

N/D

Depois da configuração, qualquer nova consulta de alerta será salva no armazenamento.

Sistema de Proteção de Dados do Cliente

O Sistema de Proteção de Dados oferece o controle para aprovar ou rejeitar a solicitação de engenheiro da Microsoft para acessar seus dados durante uma solicitação de suporte.

O Lockbox é fornecido em um cluster dedicado no Azure Monitor, onde sua permissão para acessar dados é concedida no nível da assinatura.

Saiba mais sobre o Sistema de Proteção de Dados do Cliente do Microsoft Azure

Operações de chave gerenciada pelo cliente

A chave gerenciada pelo cliente é fornecida no cluster dedicado e essas operações são citadas no artigo de cluster dedicado

  • Obter todos os clusters no grupo de recursos
  • Obter todos os clusters na assinatura
  • Atualizar reserva de capacidade no cluster
  • Atualizar billingType no cluster
  • Desvincular um workspace do cluster
  • Excluir cluster

Limitações e restrições

  • É possível criar um máximo de cinco clusters ativos em cada região e assinatura.

  • Um número máximo de sete clusters reservados (ativos ou excluídos recentemente) pode existir em cada região e assinatura.

  • No máximo 1.000 workspaces do Log Analytics podem ser vinculados a um cluster.

  • Um máximo de duas operações de vinculação de workspace em um workspace específico é permitido no período de 30 dias.

  • No momento, não há suporte para mover o cluster para outro grupo de recursos ou assinatura.

  • A atualização do cluster não deve incluir os detalhes do identificador da chave e da identidade na mesma operação. Se você precisar atualizar ambos, a atualização deverá ocorrer em duas operações consecutivas.

  • O Sistema de Proteção de Dados não está disponível atualmente na China.

  • O Sistema de Proteção não se aplica a tabelas com o plano Auxiliar.

  • A criptografia dupla é configurada automaticamente para clusters criados a partir de outubro de 2020 em regiões com suporte. Para verificar se o cluster está configurado para criptografia dupla, envie uma solicitação GET ao cluster e observe se o valor isDoubleEncryptionEnabled é true para clusters com criptografia dupla habilitada.

    • Se você criar um cluster e receber um erro "O nome-da-região não dá suporte à criptografia dupla para clusters", ainda poderá criar o cluster sem criptografia dupla adicionando "properties": {"isDoubleEncryptionEnabled": false} ao corpo da solicitação REST.
    • As configurações de criptografia dupla não podem ser alteradas após a criação do cluster.

  • A exclusão de um workspace vinculado é permitida enquanto ele está vinculado ao cluster. Se você decidir recuperar o workspace durante o período de exclusão temporária, ele retornará ao estado anterior e permanecerá vinculado ao cluster.

  • A criptografia de chave gerenciada pelo cliente se aplica a dados ingeridos após o tempo de configuração. Os dados que foram ingeridos antes da configuração permanecem criptografados com chaves da Microsoft. Você pode consultar dados ingeridos antes e depois da configuração da chave gerenciada pelo cliente de forma integrada.

  • O Azure Key Vault deve ser configurado como recuperável. Essas propriedades não são habilitadas por padrão e devem ser configuradas usando a CLI ou o PowerShell:

  • O Azure Key Vault, o cluster e os workspaces devem estar na mesma região e no mesmo locatário do Microsoft Entra, mas podem estar em assinaturas diferentes.

  • Configurar o identity type do cluster para None também revoga o acesso aos seus dados, mas essa abordagem não é recomendada, pois você não pode revertê-la sem entrar em contato com o suporte. A maneira recomendada para revogar o acesso aos seus dados é a revogação de chave.

  • Você não poderá usar a chave gerenciada pelo cliente com a identidade gerenciada atribuída pelo usuário se o seu Key Vault estiver no Link Privado (VNet). Você pode usar a identidade gerenciada atribuída pelo sistema nesse cenário.

  • O plano de tabela Auxiliar não é compatível com chaves gerenciadas pelo cliente. Os dados em tabelas com o plano Auxiliar são criptografados com chaves gerenciadas pela Microsoft, mesmo se você proteger os dados no restante do workspace do Log Analytics usando sua própria chave de criptografia.

Solução de problemas

  • Comportamento por disponibilidade do Key Vault:

    • Operação normal – o armazenamento armazena AEK em cache por curtos períodos e volta para o Key Vault para desencapsular periodicamente.

    • Erros de conexão do Key Vault – o armazenamento trata erros transitórios (tempos limite, falhas de conexão, problemas de "DNS"), permitindo que as chaves permaneçam no cache durante o problema de disponibilidade, e supera falhas e problemas de disponibilidade. As capacidades de consulta e ingestão continuam sem interrupção.

  • Taxa de acesso do Key Vault: a frequência com que o armazenamento de cluster acessa o Key Vault para operações de encapsulamento e desencapsulamento é entre 6 e 60 segundos.

  • Se você atualizar o cluster enquanto ele estiver no estado de provisionamento ou estiver atualizando o estado, a atualização falhará.

  • Se você receber um erro de conflito ao criar um cluster, é possível que um cluster com o mesmo nome tenha sido excluído nos últimos 14 dias e mantido reservado. O nome do cluster excluído fica disponível por 14 dias após a exclusão.

  • A vinculação de workspace a um cluster falhará se esse workspace estiver vinculado a outro cluster.

  • Se você criar um cluster e especificar KeyVaultProperties imediatamente, a operação poderá falhar até que uma identidade seja atribuída no cluster e concedida ao Key Vault.

  • Se você atualizar o cluster existente com KeyVaultProperties e a Política de Acesso da chave ''Get'' estiver ausente no Key Vault, a operação falhará.

  • Se você não implantar o cluster, verifique se seu Azure Key Vault, cluster e os workspaces vinculados estão na mesma região. Eles podem estar em assinaturas diferentes.

  • Se você girar sua chave no Key Vault e não atualizar os novos detalhes do identificador de chave no cluster, o cluster continuará usando a chave anterior e seus dados ficarão inacessíveis. Atualize os novos detalhes do identificador de chave no cluster para retomar a ingestão de dados e a consulta. Você pode atualizar a versão da chave com "''" para que o armazenamento sempre use a versão de chave mais recente automaticamente.

  • Algumas operações são de execução prolongada e podem demorar um pouco para serem concluídas, incluindo a criação de cluster, a atualização de chave de cluster e a exclusão de cluster. Você pode verificar o status da operação enviando solicitação GET ao cluster ou workspace e observar a resposta. Por exemplo, um workspace desvinculado não terá clusterResourceId em recursos.

  • Mensagens de erro

    Atualização do cluster

    • 400 – O cluster está em estado de exclusão. A operação assíncrona está em andamento. O cluster precisa concluir a operação antes que uma atualização seja executada.
    • 400 – KeyVaultProperties não está vazio, mas tem um formato inválido. Confira a atualização do identificador de chave.
    • 400 – Falha ao validar a chave no Key Vault. Pode ser que faltam permissões ou a chave não existe. Verifique se você definiu a política de acesso e a chave no Key Vault.
    • 400 – A chave não pode ser recuperada. Key Vault precisa ser definido como exclusão reversível e proteção de limpeza. Confira a documentação do Key Vault
    • 400 – A operação não pode ser executada agora. Espere pela conclusão da operação assíncrona e tente de novo.
    • 400 – O cluster está em estado de exclusão. Espere pela conclusão da operação assíncrona e tente de novo.

    Obtenção de cluster

    • 404 – Cluster não encontrado. Ele pode ter sido excluído. Se você tentar criar um cluster com esse nome e ocorrer um conflito, significa que o cluster está em processo de exclusão.

Próximas etapas