Azure Monitor chaves gerenciadas pelo cliente

  • Artigo

Os dados no Azure Monitor são criptografados com chaves gerenciadas pela Microsoft. Você pode usar sua própria chave de criptografia para proteger os dados e consultas salvas em seus espaços de trabalho. As chaves gerenciadas pelo cliente no Azure Monitor oferecem maior flexibilidade para gerenciar controles de acesso a logs. Depois de configurados, os novos dados ingeridos em espaços de trabalho vinculados são criptografados com sua chave armazenada no Cofre de Chaves do Azure ou no "HSM" gerenciado pelo Cofre de Chaves do Azure.

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

Visão geral das chaves gerenciadas pelo cliente

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

O Azure Monitor assegura que todos os dados e consultas guardadas são encriptados em suportes digitais mediante a utilização de chaves geridas pela Microsoft (MMK). O uso de criptografia do Azure Monitor é idêntico à maneira como a criptografia do Armazenamento do Azure opera.

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 Cofre de Chaves do Azure.

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 - no nível de serviço usando chaves gerenciadas pela Microsoft ou chaves gerenciadas pelo cliente e no nível de infraestrutura, usando dois algoritmos de criptografia diferentes e duas chaves diferentes. A encriptação dupla protege contra um cenário em que um dos algoritmos ou chaves de encriptação pode ser comprometido. Os clusters dedicados também permitem proteger os dados com o Lockbox.

Os dados ingeridos nos últimos 14 dias, ou usados recentemente em consultas, são mantidos em hot-cache (SSD-backed) para eficiência da consulta. Os dados SSD são encriptados com chaves Microsoft, independentemente de configurar chaves geridas pelo cliente, mas o seu controlo sobre o acesso a SSD adere à revogação de chaves.

Importante

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

Como as chaves gerenciadas pelo cliente funcionam no Azure Monitor

O Azure Monitor usa a identidade gerenciada para conceder acesso ao seu Cofre da Chave do Azure. A identidade do cluster do Log Analytics é suportada no nível do cluster. Para permitir chaves gerenciadas pelo cliente em vários espaços de trabalho, um recurso do Cluster do Log Analytics serve como uma conexão de identidade intermediária entre o Cofre da Chave e os espaços de trabalho do Log Analytics. O armazenamento do cluster usa a identidade gerenciada associada ao cluster para autenticar no seu Cofre da Chave do Azure por meio da ID do Microsoft Entra.

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

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

Você pode configurar chaves gerenciadas pelo cliente em um novo cluster ou em um cluster existente vinculado a espaços de trabalho e que já esteja ingerindo dados. Novos dados ingeridos em espaços de trabalho vinculados são criptografados com sua chave e dados mais antigos são ingeridos antes que a configuração permaneça criptografada com chaves da Microsoft. A configuração de chave gerenciada pelo cliente não afeta suas consultas, que continuam a ser executadas em dados antigos e novos sem problemas. Você pode desvincular espaços de trabalho de um cluster a qualquer momento. Os novos dados que você ingere após a desvinculação são criptografados com chaves da Microsoft, e as consultas são realizadas entre dados antigos e novos sem problemas.

Importante

O recurso de chaves gerenciadas pelo cliente é regional. O Cofre da Chave do Azure, o cluster e os espaços de trabalho vinculados devem 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. Recurso de cluster do Log Analytics que tem uma identidade gerenciada com permissões para o Cofre da Chave - a identidade é propagada para o armazenamento de cluster dedicado subjacente
  3. Cluster dedicado
  4. Espaços de trabalho vinculados a cluster dedicado

Operação de chaves de criptografia

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

  • "KEK" - Chave de Encriptação de Chave (a sua chave gerida pelo cliente)
  • "AEK" - Chave de Encriptação de Conta
  • "DEK" - Chave de criptografia de dados

Aplicam-se as seguintes regras:

  • O armazenamento de cluster tem chave de criptografia exclusiva para cada conta de armazenamento, que é conhecida como "AEK".
  • O "AEK" é usado para derivar "DEKs, que são as chaves que são usadas para criptografar cada bloco de dados gravados no disco.
  • Quando você configura uma chave no Cofre da Chave e atualiza os detalhes da chave no cluster, o armazenamento do cluster executa solicitações para 'encapsular' e 'desempacotar' "AEK" para criptografia e descriptografia.
  • O seu "KEK" nunca sai do seu Cofre de Chaves e, se você usar um "HSM" gerenciado, ele nunca sai do hardware.
  • O Armazenamento do Azure usa a identidade gerenciada associada ao recurso de Cluster para autenticação. Ele acessa o Azure Key Vault por meio do Microsoft Entra ID.

Principais etapas de provisionamento gerenciadas pelo cliente

  1. Criando o Azure Key Vault e armazenando a chave
  2. Criando cluster
  3. Conceder permissões ao Cofre da Chave
  4. Atualizando o cluster com detalhes do identificador de chave
  5. Vinculando espaços de trabalho

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

Armazenando chave de criptografia ("KEK")

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

Crie ou use um Cofre da Chave do Azure existente na região em que o cluster está planejado. No cofre de chaves, gere ou importe uma chave para ser usada para criptografia de logs. O Cofre da Chave do Azure deve ser configurado como recuperável, para proteger sua chave e o acesso aos seus dados no Azure Monitor. Você pode verificar essa configuração em propriedades no Cofre da Chave, tanto a proteção Soft delete quanto a Purge devem ser habilitadas.

Captura de tela das configurações de proteção de exclusão suave e limpeza.

Essas configurações podem ser atualizadas no Cofre da Chave por meio da CLI e do PowerShell:

Criar cluster

Os clusters usam identidade gerenciada para criptografia de dados com o Cofre da Chave. Configure identity type a propriedade para SystemAssigned ou UserAssigned ao criar seu cluster para permitir o acesso ao seu Cofre de Chaves para operações de criptografia e descriptografia de dados.

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

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

Nota

O tipo de identidade pode ser alterado após a criação do cluster sem interrupção da ingestão ou consultas com as seguintes considerações

  • Atualizando SystemAssigned para UserAssigned—Conceda a identidade UserAssign no Cofre da Chave e, em seguida, atualize identity type no cluster
  • Atualizando UserAssigned para SystemAssigned—Desde que a identidade gerenciada atribuída ao sistema foi criada após a atualização do cluster identity type com SystemAssignedo , as etapas a seguir devem ser seguidas
    1. Atualize o cluster e remova a chave — defina keyVaultUri, keyNamee keyVersion com o valor ""
    2. Atualizar cluster identity type para SystemAssigned
    3. Atualize o Cofre da Chave e conceda permissões à identidade
    4. Atualizar chave no cluster

Siga o procedimento ilustrado no artigo Clusters dedicados.

Conceder permissões do Cofre da Chave

Há dois modelos de permissão no Cofre da Chave para conceder acesso ao seu cluster e armazenamento subjacente: controle de acesso baseado em função do Azure (Azure RBAC) e políticas de acesso do Vault (legado).

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

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

    1. Abra o Cofre da Chave 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 controle de acesso (IAM) e adicione a atribuição de função de usuário de criptografia do Serviço de Criptografia do Cofre de Chaves.
    3. Selecione Identidade gerenciada na guia Membros e selecione a assinatura para identidade e a identidade como membro

    Captura de tela das permissões RBAC do Grant Key Vault.

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

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

    • Permissões de chave—selecione Obter, Chave de encapsulamento e Desembrulhar chave.
    • Selecionar entidade — dependendo do tipo de identidade usado no cluster (identidade gerenciada atribuída ao sistema ou ao usuário)
      • Identidade gerenciada atribuída ao sistema - insira o nome do cluster ou o ID da entidade do cluster
      • Identidade gerenciada atribuída pelo usuário - insira o nome da identidade

    Captura de ecrã das permissões da política de acesso ao Cofre da Chave de Concessão.

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

Atualizar cluster com detalhes do identificador de chave

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

Esta etapa atualiza o armazenamento de cluster dedicado com a chave e a versão a serem usadas para encapsular e desempacotar "AEK".

Importante

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

Captura de ecrã das permissões Conceder Cofre de Chaves.

Atualize KeyVaultProperties no cluster com detalhes do identificador de chave.

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

N/A

Importante

Esta etapa deve ser executada somente após o provisionamento do cluster. Se você vincular espaços de trabalho 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" em seu espaço de trabalho e cluster para executar essa operação. Microsoft.OperationalInsights/workspaces/write Inclui e Microsoft.OperationalInsights/clusters/write.

Siga o procedimento ilustrado no artigo Clusters dedicados.

Revogação de chaves

Importante

  • A forma recomendada de revogar o acesso aos seus dados é desativando a sua chave ou eliminando a Política de Acesso no Cofre da Chave.
  • Definir o cluster identity type para None também revoga o acesso aos seus dados, mas essa abordagem não é recomendada, pois você não pode revertê-lo sem entrar em contato com o suporte.

O armazenamento de cluster sempre respeita as alterações nas permissões de chave dentro de uma hora ou antes, e o armazenamento fica indisponível. Novos dados ingeridos em espaços de trabalho vinculados são descartados e irrecuperáveis. Os dados estão inacessíveis nesses espaços de trabalho e as consultas falham. Os dados ingeridos anteriormente permanecem armazenados desde que o cluster e os espaços de trabalho não sejam excluídos. Os dados inacessíveis são regidos pela política de retenção de dados e eliminados 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 hot-cache (SSD-backed) para eficiência da consulta. Os dados no SSD são excluídos na operação de revogação de chave e tornam-se inacessíveis. O armazenamento em cluster tenta alcançar o Cofre da Chave para encapsular e desempacotar periodicamente e, uma vez que a chave é ativada, o desempacotamento é bem-sucedido, os dados SSD são recarregados do armazenamento e a ingestão e consulta de dados são retomadas em 30 minutos.

Rotação de chaves

A rotação das chaves tem dois modos:

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

Todos os seus dados permanecem acessíveis durante e após a operação de rotação de chaves. Dados sempre encriptados com a Chave de Encriptação de Conta ("AEK"), que é encriptada com a sua nova versão da Chave de Encriptação de Chave ("KEK") no Cofre de Chaves.

Chave gerenciada pelo cliente para consultas salvas e alertas de pesquisa de log

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

Chave gerenciada pelo cliente para pastas de trabalho

Com as considerações mencionadas para Chave gerenciada pelo cliente para consultas salvas e alertas de pesquisa de log, o Azure Monitor permite que você armazene consultas de 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 Azure na operação 'Salvar' da Pasta de Trabalho.

Captura de ecrã de Guardar livro.

Nota

As consultas permanecem criptografadas com a chave da Microsoft ("MMK") nos seguintes cenários, independentemente da configuração de chave gerenciada pelo cliente: painéis do Azure, Aplicativo Lógico do Azure, Blocos de Anotações do Azure e Runbooks de Automação.

Ao vincular sua Conta de Armazenamento para consultas salvas, o serviço armazena consultas salvas e registra consultas de alerta de pesquisa em sua Conta de Armazenamento. Tendo controle sobre sua política de criptografia em repouso da Conta de Armazenamento, você pode proteger consultas salvas e registrar alertas de pesquisa 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" em seu espaço de trabalho e conta de armazenamento.
  • Certifique-se de criar sua conta de armazenamento na mesma região em que o espaço de trabalho do Log Analytics está localizado, com criptografia de chave gerenciada pelo cliente. Isso é importante, pois as consultas salvas são armazenadas no armazenamento de tabelas e só podem ser criptografadas 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 mudar.
  • A vinculação de uma Conta de Armazenamento para consultas remove as consultas salvas existentes do seu espaço de trabalho. Copiar salva consultas que você precisa antes dessa configuração. Você pode exibir suas consultas salvas usando o PowerShell.
  • O 'histórico' de consultas e o 'fixar no painel' não são suportados ao vincular a Conta de Armazenamento para consultas.
  • Você pode vincular uma única Conta de Armazenamento a um espaço de trabalho para consultas salvas e consultas de alerta de pesquisa de log.
  • Os alertas de pesquisa de log são salvos no armazenamento de blob 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 resultados de pesquisa ou consulta de alerta. Você pode usar dimensões de alerta para obter contexto nos alertas disparados.

Configurar o BYOS para consultas salvas

Vincule uma Conta de Armazenamento para consultas para manter as consultas salvas em sua Conta de Armazenamento.

N/A

Após a configuração, qualquer nova consulta de pesquisa salva será salva em seu armazenamento.

Configurar o BYOS para consultas de alerta de pesquisa de log

Vincule uma Conta de Armazenamento para Alertas para manter consultas de alertas de pesquisa de log em sua Conta de Armazenamento.

N/A

Após a configuração, qualquer nova consulta de alerta será salva em seu armazenamento.

Sistema de Proteção de Dados do Cliente

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

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

Saiba mais sobre o Customer Lockbox for Microsoft Azure

Principais operações gerenciadas pelo cliente

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

  • Obter todos os clusters no grupo de recursos
  • Obter todos os clusters na subscrição
  • Atualizar reserva de capacidade no cluster
  • Atualizar faturaçãoTipo no cluster
  • Desvincular um espaço de trabalho do cluster
  • Eliminar o cluster

Limitações e restrições

  • Um máximo de cinco clusters ativos podem ser criados 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.

  • Um máximo de 1.000 espaços de trabalho do Log Analytics podem ser vinculados a um cluster.

  • Um máximo de duas operações de link de espaço de trabalho em um espaço de trabalho específico é permitido em um período de 30 dias.

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

  • A atualização do cluster não deve incluir detalhes de identidade e identificador de chave na mesma operação. Caso você precise atualizar ambos, a atualização deve ser em duas operações consecutivas.

  • O Lockbox não está disponível na China atualmente.

  • O Lockbox 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 suportadas. Você pode verificar se o cluster está configurado para criptografia dupla enviando uma solicitação GET no cluster e observando que o isDoubleEncryptionEnabled valor é true para clusters com criptografia dupla habilitada.

    • Se você criar um cluster e receber um erro — "region-name doesn't support Double Encryption for clusters", você ainda poderá criar o cluster sem criptografia dupla, adicionando "properties": {"isDoubleEncryptionEnabled": false} o 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 espaço de trabalho vinculado é permitida enquanto estiver vinculado ao cluster. Se você decidir recuperar o espaço de trabalho durante o período de exclusão suave, ele retornará ao estado anterior e permanecerá vinculado ao cluster.

  • A criptografia de chave gerenciada pelo cliente se aplica aos dados recém-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 de chave gerenciada pelo cliente perfeitamente.

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

    • Exclusão suave.
    • A proteção contra limpeza deve ser ativada para proteger contra a exclusão forçada do segredo, mesmo após a exclusão suave.

  • Seu Cofre de Chaves do Azure, cluster e espaços de trabalho devem estar na mesma região e no mesmo locatário do Microsoft Entra, mas podem estar em assinaturas diferentes.

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

  • Não é possível usar a chave gerenciada pelo cliente com identidade gerenciada atribuída pelo usuário se o Cofre da Chave estiver em Private-Link (vNet). Você pode usar a identidade gerenciada atribuída ao sistema nesse cenário.

  • O plano de tabela auxiliar não suporta chaves gerenciadas pelo cliente. Os dados em tabelas com o plano Auxiliar são criptografados com chaves gerenciadas pela Microsoft, mesmo que você proteja os dados no restante do espaço de trabalho do Log Analytics usando sua própria chave de criptografia.

Resolução de Problemas

  • Comportamento por disponibilidade do Cofre de Chaves:

    • Operação normal — o armazenamento armazena em cache "AEK" por curtos períodos de tempo e volta ao Cofre da Chave para desempacotar periodicamente.

    • Erros de conexão do Key Vault — o armazenamento lida com erros transitórios (tempos limites, falhas de conexão, problemas de "DNS"), permitindo que as chaves permaneçam no cache durante o problema de disponibilidade, e supera blips e problemas de disponibilidade. Os recursos de consulta e ingestão continuam sem interrupção.

  • A taxa de acesso ao Cofre da Chave - a frequência com que o armazenamento do cluster acessa o Cofre da Chave para encapsular e desempacotar - é entre 6 e 60 segundos.

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

  • Se você tiver conflito — erro ao criar um cluster, um cluster com o mesmo nome pode ter sido excluído nos últimos 14 dias e mantido reservado. O nome do cluster excluído fica disponível 14 dias após a exclusão.

  • A vinculação de um espaço de trabalho a um cluster falhará se o espaço de trabalho 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 ao cluster e concedida ao Cofre da Chave.

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

  • Se você não conseguir implantar seu cluster, verifique se o Cofre da Chave do Azure, o cluster e os espaços de trabalho vinculados estão na mesma região. O pode ser em diferentes assinaturas.

  • Se você girar sua chave no Cofre da Chave e não atualizar os detalhes do novo identificador de chave no cluster, o cluster continuará usando a chave anterior e seus dados ficarão inacessíveis. Atualize os detalhes do novo identificador de chave no cluster para retomar a ingestão e consulta de dados. 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 longa execução e podem levar algum tempo para serem concluídas, incluindo a criação de cluster, atualização de chave de cluster e exclusão de cluster. Você pode verificar o status da operação enviando a solicitação GET para o cluster ou espaço de trabalho e observar a resposta. Por exemplo, o espaço de trabalho desvinculado não terá o clusterResourceId em recursos.

  • Mensagens de erro

    Atualização de cluster

    • 400 - O cluster está em estado de exclusão. A operação assíncrona está em andamento. O cluster deve concluir sua operação antes que qualquer operação de atualização seja executada.
    • 400 - KeyVaultProperties não está vazio, mas tem um formato ruim. Consulte Atualização do identificador de chave.
    • 400 - Falha ao validar a chave no Cofre da Chave. Pode ser devido à falta de permissões ou quando a chave não existe. Verifique se você definiu a chave e a Política de Acesso no Cofre da Chave.
    • 400 - A chave não é recuperável. O Cofre de Chaves deve ser definido como Soft-delete e Purge-protection. Consulte a documentação do Key Vault
    • 400 - A operação não pode ser executada agora. Aguarde a conclusão da operação assíncrona e tente novamente.
    • 400 - O cluster está em estado de exclusão. Aguarde a conclusão da operação assíncrona e tente novamente.

    Obter cluster

    • 404--Cluster não encontrado, o cluster pode ter sido excluído. Se você tentar criar um cluster com esse nome e obter um conflito, o cluster estará no processo de exclusão.

Próximos passos