Ler em inglês

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 sua própria chave de criptografia para proteger os dados em seus espaços de trabalho. As chaves gerenciadas pelo cliente no Azure Monitor oferecem controle sobre o ciclo de vida da chave de criptografia e acesso a logs. Depois de configurado, os novos dados ingeridos nos espaços de trabalho vinculados serão criptografados com sua chave no Azure Key Vault ou Azure Key Vault Gerenciado "HSM".

Visão geral da chave gerenciada pelo cliente

Criptografia de Dados Inativa é um requisito comum de privacidade e segurança em organizações. Você pode permitir que o Azure gerencie completamente a criptografia inativa ou usar várias opções para gerenciar de perto 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 controlar o ciclo de vida da chave com a capacidade de revogar o acesso aos dados, criptografe os dados com sua própria chave no Azure Key Vault ou Azure Key Vault Gerenciado "HSM". A capacidade de usar chaves gerenciadas pelo cliente está disponível em clusters dedicados e oferece a você um nível mais alto de proteção e controle.

Os dados ingeridos em clusters dedicados são criptografados 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 criptografia dupla protege contra um cenário em que um dos algoritmos ou chaves de criptografia está 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 SSD são criptografados com chaves gerenciadas pela Microsoft, independentemente de você configurar chaves gerenciadas pelo cliente, mas seu controle sobre o acesso SSD está em conformidade com a revogação de chaves.

Importante

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

Como funciona a chave gerenciada pelo cliente no Azure Monitor

O Azure Monitor usa identidade gerenciada para conceder acesso à sua chave no Azure Key Vault. A identidade dos clusters do Log Analytics tem suporte no nível do cluster. Para fornecer chaves gerenciadas pelo cliente em vários espaços de trabalho, um recurso de cluster do Log Analytics serve como uma conexão de identidade intermediária entre seu Key Vault e seus workspaces do Log Analytics. 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 configurar chaves gerenciadas pelo cliente na criação do cluster, quando identity type estiver definido como UserAssigned, e conceder permissões no seu Key Vault antes da criação do cluster.

Você pode configurar chaves gerenciadas pelo cliente em um novo cluster ou em um cluster dedicado existente com espaços de trabalho vinculados que ingerem dados. Da mesma forma, você pode desvincular espaços de trabalho de um cluster a qualquer momento. Os novos dados ingeridos nos espaços de trabalho vinculados são criptografados com sua chave e os dados mais antigos permanecem criptografados com chaves gerenciadas pela Microsoft. A configuração não interrompe a ingestão ou as consultas, que são executadas em dados antigos e novos e novos sem problemas. Quando você desvincular os espaços de trabalho de um cluster. Os novos dados ingeridos são criptografados com chaves gerenciadas pela Microsoft.

Importante

A capacidade das chaves gerenciadas pelo cliente é regional. Seu Azure Key Vault, cluster dedicado e 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. 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

Tipos 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.
  • Ao configurar a chave gerenciada pelo cliente "KEK" no cluster, o armazenamento do cluster executará solicitações de 'encapsulamento' e 'desencapsulamento' para seu Key Vault para criptografia e descriptografia "AEK".
  • Sua "KEK" nunca sai do seu Key Vault e, se você armazenar sua chave no Azure Key Vault Gerenciado "HSM", ela nunca sairá do hardware.
  • O Armazenamento do Microsoft Azure usa a identidade gerenciada associada ao 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. Criando um cluster dedicado
  3. Conceder permissões ao Key Vault
  4. Atualizando um cluster dedicado com detalhes do identificador de chaves
  5. Vinculando workspaces

A configuração da chave gerenciada pelo cliente ainda não tem suporte total no portal do Azure e o provisionamento pode ser realizado por meio de solicitações PowerShell, CLI ou 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:

Permissões necessárias

Para executar ações relacionadas ao cluster, você precisa ter estas permissões:

Ação Permissões ou função necessárias
Criar um cluster dedicado As permissões Microsoft.Resources/deployments/* e Microsoft.OperationalInsights/clusters/write, conforme fornecidas pela função interna do Colaborador do Log Analytics, por exemplo
Alterar propriedades do cluster As permissões Microsoft.OperationalInsights/clusters/write, conforme fornecidas pela função interna do Colaborador do Log Analytics, por exemplo
Vincular workspaces a um cluster As permissões Microsoft.OperationalInsights/clusters/write, Microsoft.OperationalInsights/workspaces/write e Microsoft.OperationalInsights/workspaces/linkedservices/write conforme fornecidas pela função interna do Colaborador do Log Analytics, por exemplo
Verificar o status de vinculação do workspace As permissões Microsoft.OperationalInsights/workspaces/read para os workspaces, conforme fornecidas pela função integrada Leitor do Log Analytics, por exemplo
Obter clusters ou verificar o status de provisionamento de um cluster As permissões Microsoft.OperationalInsights/clusters/read, conforme fornecidas pela função interna do Leitor do Log Analytics, por exemplo
Atualizar a camada de compromisso ou billingType em um cluster As permissões Microsoft.OperationalInsights/clusters/write, conforme fornecidas pela função interna do Colaborador do Log Analytics, por exemplo
Conceder as permissões necessárias Função Proprietário ou Colaborador que tenha permissões */write ou uma função interna de Colaborador do Log Analytics que tenha permissões Microsoft.OperationalInsights/*
Desvincular um workspace do cluster As permissões Microsoft.OperationalInsights/workspaces/linkedServices/delete, conforme fornecidas pela função interna do Colaborador do Log Analytics, por exemplo
Excluir um cluster dedicado As permissões Microsoft.OperationalInsights/clusters/delete, conforme fornecidas pela função interna do Colaborador do Log Analytics, por exemplo

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.

Por exemplo, adicione estas propriedades no corpo da solicitação para a identidade gerenciada atribuída pelo sistema

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

Observação

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

  • A identidade e chave não podem ser atualizadas simultaneamente no cluster — atualize em duas operações consecutivas
  • Atualizando SystemAssigned para UserAssigned—Conceder UserAssign identidade no Key Vault, depois atualizar identity no cluster
  • Atualizando UserAssigned para SystemAssigned—Conceder SystemAssigned identidade no Key Vault, depois atualizar identity no cluster

Siga o procedimento ilustrado no artigo sobre cluster dedicado.

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. A permissão pode ser concedida pelo Proprietário ou Colaborador que contém a ação */write, ou pela 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 de chave explícita, confira Rotação de chaves para determinar a abordagem adequada 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.

Siga o artigo procedimento ilustrado no artigo de clusters dedicados.

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 do cluster sempre respeita as alterações nas permissões de chave em uma hora ou menos, e o armazenamento se torna 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