Compartilhar via

Chaves gerenciadas pelos clientes do Azure Monitor

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. Uma vez configurado, novos dados ingeridos em workspaces conectados são criptografados com sua chave no Azure Key Vault ou Azure Key Vault Managed HSM (Módulo de Segurança de Hardware).

Visão geral da chave gerenciada pelo cliente

Criptografia de Dados em Repouso é 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 a criptografia do Armazenamento do Azure funciona.

Para controlar o ciclo de vida da chave com a capacidade de revogar dados de acesso, criptografe dados com sua própria chave no Azure Key Vault ou no HSM Gerenciado do Azure Key Vault. A funcionalidade de chaves gerenciadas pelo cliente está disponível em clusters dedicados e fornece 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. Clusters dedicados também permitem proteger dados com o Lockbox.

Os dados ingeridos nos últimos 14 dias, ou usados recentemente em consultas, são mantidos em cache quente (suportado por 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 é suportada 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 identitytype é definida 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 identitytype estiver definido como UserAssigned e concedendo-lhe permissões no seu Key Vault antes da criação do cluster.

Configure chaves gerenciadas pelo cliente em um novo cluster ou em um cluster dedicado existente com espaços de trabalho vinculados que ingerem dados. Desvincular espaços de trabalho de um cluster pode ser feito 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 sem interrupções. Quando você desvincula workspaces de um cluster, novos dados ingeridos são criptografados com chaves gerenciadas pela Microsoft.

Importante

A funcionalidade 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. Cofre de Chaves
  2. Recurso de cluster do Log Analytics que tem uma identidade gerenciada com permissões para o Key Vault - a identidade é propagada para o armazenamento de cluster dedicado subjacente
  3. Cluster dedicado
  4. Espaços de trabalho associados 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 de Conta
  • DEK – Chave de Criptografia de Dados

As seguintes regras se aplicam:

  • O armazenamento do cluster tem uma chave de criptografia exclusiva para cada Conta de Armazenamento, que é conhecida como AEK.
  • O AEK é usado para derivar DEKs, que são as chaves usadas para criptografar cada bloco de dados gravados em disco.
  • Quando você configura a KEK gerenciada pelo cliente no seu cluster, o armazenamento do cluster executa wrap e unwrap solicita ao seu Key Vault a criptografia e a descriptografia de AEK.
  • Sua KEK nunca sai do seu Key Vault. Se você armazenar sua chave em um HSM Gerenciado do Azure Key Vault, ela também nunca sairá desse hardware.
  • O Armazenamento do Microsoft Azure usa a identidade gerenciada associada ao cluster para autenticação. Ele acessa o Azure Key Vault via Microsoft Entra ID.

Etapas de provisionamento da chave 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 chave
  5. Vinculando espaços de trabalho

Uma configuração de chave gerenciada pelo cliente não dá suporte à configuração de detalhes de identidade e identificador de chave. Execute essas operações por meio do PowerShell, da CLI ou das solicitações REST .

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 Microsoft.Resources/deployments/*e Microsoft.OperationalInsights/clusters/write permissões, conforme fornecido pela função interna do Log Analytics Contributor, por exemplo
Alterar propriedades do cluster Microsoft.OperationalInsights/clusters/write permissões, conforme fornecido pela função interna do Log Analytics Contributor, por exemplo
Vincular espaços de trabalho a um cluster Microsoft.OperationalInsights/clusters/write, Microsoft.OperationalInsights/workspaces/write, e Microsoft.OperationalInsights/workspaces/linkedservices/write permissões, conforme fornecido pela função interna do Log Analytics Contributor, por exemplo
Verificar status do link do espaço de trabalho Microsoft.OperationalInsights/workspaces/read permissões para o espaço de trabalho, conforme fornecido pela função interna do Log Analytics Reader, por exemplo
Obter clusters ou verificar o status de provisionamento de um cluster Microsoft.OperationalInsights/clusters/read permissões, conforme fornecido pela função interna Log Analytics Reader, por exemplo
Atualizar a camada de compromisso ou billingType em um cluster Microsoft.OperationalInsights/clusters/write permissões, conforme fornecido pela função interna do Log Analytics Contributor, por exemplo
Conceder as permissões necessárias Função de proprietário ou colaborador que tem */write permissões ou a função integrada Colaborador do Log Analytics que tem Microsoft.OperationalInsights/* permissões
Desvincular um espaço de trabalho do cluster Microsoft.OperationalInsights/workspaces/linkedServices/delete permissões, conforme fornecido pela função interna do Log Analytics Contributor, por exemplo
Excluir um cluster dedicado Microsoft.OperationalInsights/clusters/delete permissões, conforme fornecido pela função interna do Log Analytics Contributor, por exemplo

Armazenamento da chave de criptografia (KEK)

Um portfólio de produtos do Azure Key Management lista os cofres e 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 nas propriedades do seu Key Vault, tanto a exclusão suave quanto a proteção contra limpeza devem estar habilitadas.

Importante

É recomendável configurar a notificação por meio da Grade de Eventos do Azure para responder efetivamente aos eventos do Azure Key Vault, como uma chave se aproximando da expiração. Quando a chave expira, a ingestão e as consultas não são afetadas, mas você não pode atualizar a chave no cluster. Siga estas etapas para resolvê-lo

  1. Identifique a chave usada na página de resumo do cluster no Azure Portal, no Modo de Exibição JSON
  2. Estender a data de validade da chave no Azure Key Vault
  3. Atualize o cluster com a chave ativa, preferencialmente com o valor de versão "", para sempre usar a versão mais recente automaticamente

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

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

Criar agrupamento

Os clusters utilizam identidade gerenciada para criptografia de dados com seu Key Vault. Configure a propriedade identitytype 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 essas propriedades no corpo da solicitação para a identidade gerenciada atribuída pelo sistema

{
  "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 a chave não podem ser atualizadas simultaneamente para um cluster. Atualização em duas operações consecutivas.
  • Ao atualizar SystemAssigned para UserAssigned, atribua a identidade UserAssign no Key Vault e atualize identity no cluster.
  • Ao atualizar UserAssigned para SystemAssigned, atribua a identidade SystemAssigned no Key Vault e atualize 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. Atribuir 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. Selecione Ir para controle de acesso (IAM) e adicione a atribuição de função Usuário de Criptografia do Key Vault Crypto Service.
    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 concedidas ao Key Vault.

  2. Atribuir 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 de chave – selecione Obter>Encapsular Chave e Desencapsular Chave.
    • Selecione um principal 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 do principal 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 do Grant 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 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 serem usadas para AEKwrap e unwrap.

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 detalhes de identidade e identificador de chave na mesma operação. Se você precisar atualizar ambos, a atualização deverá ocorrer em duas operações consecutivas.
  • Se você estiver habilitando ou alterando apenas o CMK, use a API REST em vez da CLI. A CLI de atualização do cluster envia uma atualização para a capacidade mesmo quando essa propriedade não é usada no comando, disparando limites para alteração de 30 dias ou mínimo de 500 GB.

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

Atualizar KeyVaultProperties no cluster com detalhes do identificador de chave.

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

Não aplicável

Importante

Essa 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.

Siga o procedimento ilustrado no artigo de clusters dedicados.

Siga o procedimento ilustrado no artigo de clusters dedicados.

Revogação de chave

Importante

  • A maneira recomendada de revogar o acesso aos seus dados é desabilitando sua chave ou excluindo a Política de Acesso em seu Key Vault.
  • Configurar o identitytype 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 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 não podem ser recuperados. Os dados ficam inacessíveis nesses workspaces e as consultas falham. Os dados ingeridos anteriormente permanecem no armazenamento enquanto seu cluster e seus espaços de trabalho não forem excluídos. A política de retenção de dados rege dados inacessíveis e os limpa quando o período de retenção é atingido. Os dados ingeridos nos últimos 14 dias e os dados usados recentemente em consultas também são mantidos em cache quente (com suporte de SSD) para a eficiência das consultas. Os dados no SSD são excluídos na operação de revogação de chave e ficam inacessíveis. O armazenamento em cluster tenta acessar o Key Vault para operações wrap e unwrap periodicamente. Depois que a chave for habilitada e unwrap for bem-sucedido, os dados do SSD serão recarregados do armazenamento. A ingestão de dados e a funcionalidade de consulta sã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. Dados sempre criptografados com a Chave de Criptografia de Conta (AEK), que é criptografada com sua nova versão da Chave de Criptografia de Chave (KEK) no Key Vault.

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 na sintaxe de consulta ou comentários. As organizações limitadas por rigorosos requisitos regulatórios e de conformidade devem manter essas informações criptografadas com a chave gerenciada pelo cliente. O Azure Monitor permite armazenar consultas salvas, funções 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 do salvamento da pasta de trabalho.

Observação

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 alertas 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 a 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 salvas

  • Você precisa ter permissões de "gravação" no seu espaço de trabalho e na sua conta de armazenamento.
  • A Conta de Armazenamento deve ser StorageV2 e estar na mesma região que o workspace do Log Analytics.
  • Ao vincular uma conta de armazenamento para consultas salvas, as consultas e funções salvas existentes são removidas da área de trabalho por motivos de privacidade. Se você precisar ter essas funções úteis, copie as consultas e funções salvas existentes antes da configuração. Você pode exibir consultas salvas usando o PowerShell ou quando exportar modelo em Automação em seu workspace.
  • As consultas salvas no pacote de consultas não são armazenadas na Conta de Armazenamento vinculada e não podem ser criptografadas com a chave gerenciada pelo cliente. É recomendável salvar como consulta herdada para proteger consultas com chave gerenciada pelo cliente.
  • Consultas e funções salvas na Conta de Armazenamento vinculada são consideradas artefatos de serviço e seu formato pode mudar.
  • Não há suporte para as consultas "histórico" e "fixar no painel" ao vincular a Conta de Armazenamento para consultas salvas.
  • Você pode vincular uma conta de armazenamento única ou separada para consultas salvas e consultas de alerta de pesquisa de log.
  • Para manter consultas e funções criptografadas com sua chave, configure a Conta de Armazenamento vinculada com a chave gerenciada pelo cliente. Essa operação pode ser feita na criação de uma Conta de Armazenamento ou mais tarde.

Configurar a Conta de Armazenamento Vinculado para consultas salvas

Vincule uma conta de armazenamento para consultas e funções salvas para manter as consultas salvas em sua Conta de Armazenamento.

Observação

A operação remove consultas e funções salvas do workspace para uma tabela em sua Conta de Armazenamento. Você pode desvincular a Conta de Armazenamento para consultas salvas, para mover consultas e funções salvas de volta para seu workspace. Atualize o navegador se as consultas não forem salvas ou se as funções não aparecerem no Portal do Azure após a operação.

Não aplicável

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

Configurar a conta de armazenamento vinculada para consultas de alerta de pesquisa de log

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

  • As consultas de alerta são armazenadas como blobs na Conta de Armazenamento.
  • Os alertas de pesquisa de log acionados não contêm resultados de pesquisa nem a consulta de alerta. Use dimensões de alerta para obter o contexto dos alertas disparados.
  • Para manter consultas e funções criptografadas com sua chave, configure a Conta de Armazenamento vinculada com a chave gerenciada pelo cliente. Essa operação pode ser feita na criação de uma Conta de Armazenamento ou mais tarde.

Vincule uma conta de armazenamento para Alertas para manter consultas de alertas de pesquisa de registro em sua conta de armazenamento.

Não aplicável

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

Sistema de Proteção de Dados do Cliente

O Lockbox fornece a você o controle para aprovar ou rejeitar o pedido de um 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-chave gerenciadas 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 espaço de trabalho 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.

  • São permitidas no máximo duas operações de link de espaço de trabalho em um espaço de trabalho específico em um 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 detalhes de identidade e identificador de chave na mesma operação. Se você precisar atualizar ambos, a atualização deverá ocorrer em duas operações consecutivas.

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

  • O Lockbox não se aplica a tabelas com o plano de tabela auxiliar.

  • A criptografia dupla é configurada automaticamente para clusters criados a partir de outubro de 2020 em regiões com suporte. Você pode verificar se o cluster está configurado para criptografia dupla enviando uma GET solicitação no cluster e observando que o isDoubleEncryptionEnabled valor é true para clusters com criptografia dupla habilitada.

    • Se você criar um cluster e receber um erro: "nome da região não dá suporte à Criptografia Dupla para 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 workspace vinculado é permitida enquanto ele está vinculado ao cluster. Se você decidir recuperar o workspace 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 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 espaços de trabalho devem estar na mesma região e no mesmo locatário do Microsoft Entra, mas podem estar em assinaturas diferentes.

  • Configurar o identitytype 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 pode usar uma chave gerenciada pelo cliente com uma identidade gerenciada atribuída pelo usuário se o seu Key Vault estiver em um Private-Link (rede virtual). Use uma identidade gerenciada atribuída pelo sistema neste cenário.

Solução de problemas

  • Comportamento por disponibilidade do Key Vault:

    • O armazenamento de operação normal armazena em cache AEK por curtos períodos de tempo e retorna ao Key Vault para unwrap periodicamente.

    • Erros de conexão do Key Vault—o armazenamento lida com erros temporários (tempos limite, falhas de conexão, problemas de DNS) permitindo que as chaves permaneçam no cache durante o problema de disponibilidade, além de superar falhas e problemas de disponibilidade. Os recursos de consulta e ingestão continuam sem interrupção.

  • Taxa de acesso ao Key Vault – a frequência com que o armazenamento do cluster acessa o Key Vault para wrap e unwrap operações está entre 6 a 60 segundos.

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

  • Se você receber um erro de conflito ao criar um cluster, um cluster com o mesmo nome pode ter sido excluído nos últimos 14 dias e ter seu nome reservado. Os nomes de cluster excluídos ficam disponíveis 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 o KeyVaultProperties imediatamente, a operação poderá falhar até que uma identidade seja atribuída ao cluster e concedida ao Key Vault.

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

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

  • 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 funcionalidade de consulta. Atualize a versão da chave com '' notação para garantir 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 uma GET solicitação para o cluster ou workspace e observar a resposta. Por exemplo, um espaço de trabalho desvinculado não tem o clusterResourceId sob o features.

  • Mensagens de erro

    Atualização do cluster

    • 400 – O cluster está em processo 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 faltem permissões ou que a chave não exista. Verifique se você definiu a política de acesso e a chave no Key Vault.
    • 400 – A chave não pode ser recuperada. O Key Vault deve ser definido como exclusão reversível e proteção contra 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 processo de exclusão. Espere pela conclusão da operação assíncrona e tente de novo.

    Cluster Obter

    • 404 – Cluster não encontrado, o cluster 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

  • Last updated on