Chave gerida pelo cliente 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 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, enquanto você tem 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). Você pode criptografar dados usando sua própria chave no Cofre de Chaves do Azure, para controle sobre o ciclo de vida da chave e capacidade de revogar o acesso aos seus dados. O uso da criptografia do Azure Monitor é idêntico à maneira como a criptografia do Armazenamento do Azure opera.

A chave gerenciada pelo cliente é fornecida em clusters dedicados, proporcionando maior nível de proteção e controle. Os dados são criptografados no armazenamento duas vezes, uma no nível de serviço usando chaves gerenciadas pela Microsoft ou chaves gerenciadas pelo cliente e uma vez 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. O cluster dedicado também permite 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 da configuração de chaves geridas pelo cliente, mas o seu controlo sobre o acesso a SSD adere à revogação de chaves

O modelo de preços do Log Analytics Dedicated Clusters requer um nível de compromisso a partir de 100 GB por dia.

Como funciona a chave gerenciada pelo cliente 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 a chave gerenciada pelo cliente em vários espaços de trabalho, um recurso do Cluster do Log Analytics funciona 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 a criação do cluster quando a identidade type é definida como "SystemAssigned". Essa identidade pode ser usada posteriormente para conceder acesso de armazenamento ao seu Cofre de Chaves para operações de encapsulamento e desempacotamento.
  • A identidade gerenciada atribuída pelo usuário permite configurar a chave gerenciada pelo cliente na criação do cluster, ao conceder-lhe permissões no Cofre da Chave antes da criação do cluster.

Você pode aplicar a configuração de chave gerenciada pelo cliente a um novo cluster ou cluster existente vinculado a espaços de trabalho e ingestão de dados. Os novos dados ingeridos em espaços de trabalho vinculados são criptografados com sua chave e os dados mais antigos ingeridos antes da configuração permanecem criptografados com a chave da Microsoft. Suas consultas não são afetadas pela configuração de chaves gerenciadas pelo cliente e executadas em dados antigos e novos sem problemas. Você pode desvincular espaços de trabalho do cluster a qualquer momento. Novos dados ingeridos após o deslink são criptografados com a chave da Microsoft, e as consultas são realizadas em dados antigos e novos sem problemas.

Importante

A capacidade chave gerenciada 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.

Screenshot of customer-managed key overview.

  1. Key Vault
  2. Recurso de cluster do Log Analytics com 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, no caso do "HSM" Gerido, 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.

Screenshot of soft delete and purge protection settings.

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 a propriedade identity type para ao criar seu cluster para permitir o acesso ao seu Cofre de Chaves para SystemAssigned operações de "encapsulamento" e "desempacotamento".

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

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

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 permissões Microsoft.Authorization/roleAssignments/write e Microsoft.Authorization/roleAssignments/delete, como Administrador de Acesso de Usuário ou Proprietário.

    Abra o Cofre da Chave no portal do Azure, clique em Configuração de acesso em Configurações e selecione a opção de controle de acesso baseado em função do Azure. Em seguida, insira Controle de acesso (IAM) e adicione a atribuição de função de usuário de criptografia do serviço de criptografia do Key Vault.

    Screenshot of Grant Key Vault RBAC permissions.

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

    Abra o Cofre da Chave no portal do Azure e clique em Políticas de Acesso, selecione Política de acesso ao Cofre e clique em + 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

    Screenshot of Grant Key Vault access policy permissions.

    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 ação ou por meio da função de Colaborador do Log Analytics que contém a */writeMicrosoft.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 exigir atualização explícita de chaves, 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.

Screenshot of Grant Key Vault permissions.

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

O armazenamento em 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 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 o cluster com "keyVaultProperties" a propriedade but omit "keyVersion" 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 o cluster com a versão da chave na "keyVersion" propriedade. A rotação de chaves requer uma atualização explícita "keyVaultProperties" no cluster, 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 atualizá-la no cluster, o armazenamento do cluster continuará usando sua 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 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.

Screenshot of Workbook save.

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.

  • 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 a chave 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 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 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.

  • Atualmente, não há suporte para consultas assíncronas de trabalhos de pesquisa no cenário-chave gerenciado pelo cliente.

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.

  • Taxa de acesso ao Cofre da Chave—A frequência com que o armazenamento de cluster do Azure 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.

  • O link do espaço de trabalho para o cluster falhará se estiver vinculado a outro cluster.

  • Se você criar um cluster e especificar KeyVaultProperties imediatamente, a operação poderá falhar até que a identidade seja atribuída no cluster e concedida no 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á no 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 incorreto. 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á no 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 conflito, o cluster está em processo de exclusão.

Próximos passos