Azure Monitor chaves gerenciadas pelo cliente

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 aos logs. Uma vez configurados, os novos dados ingeridos em espaços de trabalho vinculados são criptografados com sua chave no Cofre de Chaves do Azure ou no HSM (Módulo de Segurança de Hardware) do Azure Key Vault Managed HSM .

Visão geral das chaves gerenciadas pelo cliente

A criptografia de dados 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 use várias opções para gerenciar de perto a criptografia e as chaves de criptografia.

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

Para controlar o ciclo de vida da chave com a capacidade de revogar dados de acesso, criptografe dados com sua própria chave no Cofre de Chaves do Azure ou no HSM Gerenciado do Azure Key Vault. O recurso 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 encriptação dupla protege contra um cenário em que um dos algoritmos ou chaves de encriptação está comprometido. Os clusters dedicados também permitem proteger dados com 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 geridas pela Microsoft, independentemente de configurar chaves geridas pelo cliente, mas o seu controlo sobre o acesso a SSD adere à revogação de chaves.

Como as chaves gerenciadas pelo cliente funcionam no Azure Monitor

O Azure Monitor usa a identidade gerenciada para conceder acesso à sua chave no Cofre da Chave do Azure. 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 o Cofre de Chaves e os espaços de trabalho do Log Analytics. O armazenamento do cluster utiliza a identidade gerida associada ao cluster para autenticar no seu Azure Key Vault através do serviço Microsoft Entra ID.

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 o cluster quando identitytype é definida como SystemAssigned. Esta identidade é usada posteriormente para conceder acesso de armazenamento ao seu Cofre de Chaves, permitindo a criptografia e descriptografia de dados.
• A identidade gerida atribuída pelo utilizador permite configurar chaves geridas pelo cliente na criação do cluster, quando identitytype está definido como UserAssigned, e conceder-lhe permissões no 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 ingerindo dados. A desvinculação de espaços de trabalho de um cluster pode ser feita a qualquer momento. Os novos dados ingeridos em 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 consultas, onde as consultas são realizadas em dados antigos e novos sem problemas. Quando você desvincula espaços de trabalho de um cluster, os novos dados ingeridos são criptografados com chaves gerenciadas pela Microsoft.

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

Tipos de chaves de encriptação

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

• KEK - Key Encryption Key (a sua chave gerida pelo cliente)
• AEK - Chave de Encriptação de Conta
• DEK - Chave de Encriptação de Dados

Aplicam-se as seguintes regras:

• O armazenamento de 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 que são usadas para criptografar cada bloco de dados gravados no disco.
• Quando configura o KEK gerido pelo cliente no seu cluster, o armazenamento do cluster faz wrap e unwrap solicitações ao seu Azure Key Vault para a criptografia e descriptografia AEK.
• O seu KEK nunca sai do seu Cofre de Chaves. Se você armazenar sua chave em um HSM gerenciado do Azure Key Vault, ele também nunca sairá desse hardware.
• O Armazenamento do Azure usa a identidade gerenciada associada ao 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 um cluster dedicado
3. Conceder permissões ao Cofre de Chaves
4. Atualizar um cluster dedicado com os detalhes do identificador de chave
5. Vinculando espaços de trabalho

Uma configuração de chave gerenciada pelo cliente não suporta a configuração de detalhes de identidade e identificador de chave. Execute essas operações por meio de solicitações PowerShell, CLI ou REST .

Permissões obrigatórias

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

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 esta configuração em propriedades no seu Cofre de Chaves, tanto o Soft delete como a Purge protection devem estar ativados.

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

• Eliminação Suave
• A proteção Purge protege contra a exclusão forçada do segredo e do cofre, mesmo após a exclusão suave

Criar cluster

Os clusters usam identidade gerida para criptografia de dados com o Key Vault. Configure identitytype a propriedade para SystemAssigned ou UserAssigned, ao criar o seu cluster, para permitir acesso ao seu Cofre de Chaves, possibilitando operações de criptografia e de descriptografia de dados.

Por exemplo, adicione essas propriedades no corpo da solicitação para identidade gerenciada atribuída ao sistema

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

Siga o procedimento ilustrado no artigo dedicado do cluster.

Conceder permissões do Cofre da Chave

Existem dois modelos de permissão no Cofre de Chaves para conceder acesso ao seu cluster e ao armazenamento subjacente: controle de acesso baseado em funções do Azure (Azure RBAC) e políticas de acesso ao Cofre (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 >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 de 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.

   

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

   Abra o Cofre da Chave no portal do Azure e selecione Políticas de Acesso>Política de Acesso ao Cofre>+ 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.
   • Selecione uma identidade principal dependendo do tipo de identidade usado no cluster (identidade gerida atribuída ao sistema ou ao utilizador)
     • 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

   

   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. A permissão pode ser concedida através do Proprietário ou Colaborador que contém a ação */write, ou através da função de 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.

Atualizar KeyVaultProperties no cluster com detalhes do identificador de chave.

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

az account set --subscription cluster-subscription-id

az monitor log-analytics cluster update --no-wait --name "cluster-name" --resource-group "resource-group-name" --key-name "key-name" --key-vault-uri "key-uri" --key-version "key-version"

$clusterResourceId = az monitor log-analytics cluster list --resource-group "resource-group-name" --query "[?contains(name, "cluster-name")].[id]" --output tsv
az resource wait --created --ids $clusterResourceId --include-response-body true

Select-AzSubscription "cluster-subscription-id"

Update-AzOperationalInsightsCluster -ResourceGroupName "resource-group-name" -ClusterName "cluster-name" -KeyVaultUri "key-uri" -KeyName "key-name" -KeyVersion "key-version" -AsJob

# Check when the job is done when `-AsJob` was used
Get-Job -Command "New-AzOperationalInsightsCluster*" | Format-List -Property *

PATCH https://management.azure.com/subscriptions/<subscription-id>/resourcegroups/<resource-group-name>/providers/Microsoft.OperationalInsights/clusters/cluster-name?api-version=2023-09-01
Authorization: Bearer <token> 
Content-type: application/json
 
{
  "properties": {
    "keyVaultProperties": {
      "keyVaultUri": "https://key-vault-name.vault.azure.net",
      "keyName": "key-name",
      "keyVersion": ""
    }
  }
}

{
  "identity": {
    "type": "SystemAssigned",
    "tenantId": "tenant-id",
    "principalId": "principal-id"
  },
  "sku": {
    "name": "capacityreservation",
    "capacity": 100
  },
  "properties": {
    "keyVaultProperties": {
      "keyVaultUri": "https://key-vault-name.vault.azure.net",
      "keyName": "key-name",
      "keyVersion": ""
      },
    "provisioningState": "Succeeded",
    "clusterId": "cluster-id",
    "billingType": "Cluster",
    "lastModifiedDate": "last-modified-date",
    "createdDate": "created-date",
    "isDoubleEncryptionEnabled": false,
    "isAvailabilityZonesEnabled": false,
    "capacityReservationProperties": {
      "lastSkuUpdate": "last-sku-modified-date",
      "minCapacity": 100
    }
  },
  "id": "/subscriptions/subscription-id/resourceGroups/resource-group-name/providers/Microsoft.OperationalInsights/clusters/cluster-name",
  "name": "cluster-name",
  "type": "Microsoft.OperationalInsights/clusters",
  "___location": "cluster-region"
}

Vincular espaço de trabalho ao cluster

Siga o procedimento ilustrado no artigo Clusters Dedicados.

Desvincular espaço de trabalho do cluster

Siga o procedimento ilustrado no artigo Clusters Dedicados.

Revogação de chaves

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 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. A política de retenção de dados rege os 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 hot-cache (SSD-backed) para eficiência da consulta. Os dados na SSD são eliminados na operação de revogação de chaves e tornam-se inacessíveis. O armazenamento de cluster tenta alcançar o Key Vault para as operações wrap e unwrap periodicamente. Quando a chave é ativada e unwrap é bem-sucedida, os dados SSD são recarregados do armazenamento. A ingestão de dados e a funcionalidade de consulta são retomadas em 30 minutos.

Rotação de chaves

A rotação das chaves tem dois modos:

• Autorotation—atualize "keyVaultProperties" propriedade no cluster e omita "keyVersion" 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 as propriedades de "keyVaultProperties" e 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, 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 criptografados com a Chave de Criptografia de Conta (AEK), que é criptografada com sua nova versão de Chave de Criptografia de Chave (KEK) no Cofre de Chaves.

Chave gerida pelo cliente para consultas guardadas e alertas de pesquisa em logs

A linguagem de consulta usada no Log Analytics é expressiva e pode conter informações confidenciais na sintaxe da consulta ou nos 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-lhe armazenar consultas, funções e alertas de pesquisa de registo guardados encriptados com a sua chave na sua própria Conta de Armazenamento quando associado à sua área 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.

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 salvas

• Você precisa ter permissões de "gravação" em seu espaço de trabalho e conta de armazenamento.
• A Conta de Armazenamento deve ser StorageV2 e estar na mesma região do espaço de trabalho do Log Analytics.
• Ao vincular uma Conta de Armazenamento para consultas salvas, as consultas e funções salvas existentes são removidas do seu espaço de trabalho para privacidade. Se você precisar tê-los à mão, copie as consultas e funções salvas existentes antes da configuração. Você pode exibir consultas salvas usando o PowerShell, ou quando Exportar o modelo sob Automação no seu espaço de trabalho.
• 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.
• As consultas e funções salvas na Conta de Armazenamento vinculada são consideradas artefatos de serviço e seu formato pode mudar.
• A consulta 'histórico' e o 'afixar ao painel' não são suportados 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 realizada durante a criação da conta de armazenamento ou posteriormente.

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

az account set --subscription "storage-account-subscription-id"

$storageAccountId = '/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Storage/storageAccounts/<storage name>'

az account set --subscription "workspace-subscription-id"

az monitor log-analytics workspace linked-storage create --type Query --resource-group "resource-group-name" --workspace-name "workspace-name" --storage-accounts $storageAccountId

Select-AzSubscription "StorageAccount-subscription-id"

$storageAccountId = (Get-AzStorageAccount -ResourceGroupName "resource-group-name" -Name "storage-account-name").id

Select-AzSubscription "workspace-subscription-id"

New-AzOperationalInsightsLinkedStorageAccount -ResourceGroupName "resource-group-name" -WorkspaceName "workspace-name" -DataSourceType Query -StorageAccountIds $storageAccountId

PUT https://management.azure.com/subscriptions/<subscription-id>/resourcegroups/<resource-group-name>/providers/Microsoft.OperationalInsights/workspaces/<workspace-name>/linkedStorageAccounts/Query?api-version=2020-08-01
Authorization: Bearer <token> 
Content-type: application/json
 
{
  "properties": {
    "dataSourceType": "Query", 
    "storageAccountIds": 
    [
      "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Storage/storageAccounts/<storage-account-name>"
    ]
  }
}

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

Configurar consultas de alerta de pesquisa de log na Conta de Armazenamento associada

Considerações antes de definir uma chave gerida pelo cliente para consultas de alertas de log guardadas

• As consultas de alerta são armazenadas como *blob* na Conta de Armazenamento.
• Os alertas de pesquisa de log acionados não contêm os resultados da pesquisa ou a consulta de alerta. Use dimensões de alerta para obter contexto para os 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 realizada durante a criação da conta de armazenamento ou posteriormente.

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

az account set --subscription "storage-account-subscription-id"

$storageAccountId = '/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Storage/storageAccounts/<storage name>'

az account set --subscription "workspace-subscription-id"

az monitor log-analytics workspace linked-storage create --type ALerts --resource-group "resource-group-name" --workspace-name "workspace-name" --storage-accounts $storageAccountId

Select-AzSubscription "StorageAccount-subscription-id"

$storageAccountId = (Get-AzStorageAccount -ResourceGroupName "resource-group-name" -Name "storage-account-name").id

Select-AzSubscription "workspace-subscription-id"

New-AzOperationalInsightsLinkedStorageAccount -ResourceGroupName "resource-group-name" -WorkspaceName "workspace-name" -DataSourceType Alerts -StorageAccountIds $storageAccountId

PUT https://management.azure.com/subscriptions/<subscription-id>/resourcegroups/<resource-group-name>/providers/Microsoft.OperationalInsights/workspaces/<workspace-name>/linkedStorageAccounts/Alerts?api-version=2020-08-01
Authorization: Bearer <token> 
Content-type: application/json
 
{
  "properties": {
    "dataSourceType": "Alerts", 
    "storageAccountIds": 
    [
      "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Storage/storageAccounts/<storage-account-name>"
    ]
  }
}

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 capacidade reservada no cluster
• Atualizar tipo de faturação 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 ligações de espaço de trabalho em um determinado espaço de trabalho é permitido num 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 de tabela 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 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 — "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 e do cofre, mesmo após a exclusão suave.

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

• Definir o cluster identitytype 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 chave.

• Não é possível usar uma chave gerenciada pelo cliente com identidade gerenciada atribuída pelo usuário se o Cofre da Chave estiver em um Private-Link (rede virtual). Use uma identidade gerenciada atribuída ao sistema neste cenário.

Resolução de Problemas

• Comportamento por disponibilidade do Azure Key Vault:

  • As operações normais armazenam em cache o AEK por curtos períodos de tempo e voltam ao unwrap Key Vault 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. As funcionalidades de consulta e ingestão continuam sem interrupção.

• Taxa de acesso ao Cofre de Chaves - a frequência com que o armazenamento do cluster acede ao Cofre de Chaves para operações de wrap e unwrap é entre 6 e 60 segundos.

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

• Se receber um erro de conflito ao criar um cluster, um cluster com o mesmo nome pode ter sido eliminado nos últimos catorze dias e ter o seu nome reservado. Os nomes de cluster excluídos ficam disponíveis 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 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 atualizar o cluster existente com KeyVaultProperties e Get e a Política de Acesso da chave estiver ausente no Cofre de Chaves, 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. Pode estar 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 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 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 uma GET solicitação para o cluster ou espaço de trabalho e observar a resposta. Por exemplo, um espaço de trabalho desvinculado não tem o clusterResourceId sob features.

• 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 definiu a chave e a Política de Acesso no Cofre de Chaves.
  • 400 - A chave não é recuperável. O Cofre de Chaves deve ser configurado para Eliminação Suave e Proteção contra Eliminação. 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 tentar criar um cluster com esse nome e ocorrer um conflito, o cluster está em processo de eliminação.

Próximos passos

• Saiba mais sobre a faturação de cluster dedicada do Log Analytics
• Saiba mais sobre o design adequado dos espaços de trabalho do Log Analytics