Chave do Azure Monitor gerenciada pelo cliente

  • Artigo

Os dados no Azure Monitor são criptografados com chaves gerenciadas pela Microsoft. Você pode usar a própria chave de criptografia para proteger os dados e as consultas salvas nos workspaces. As chaves gerenciadas pelo cliente no Azure Monitor dão maior flexibilidade para gerenciar os controles de acesso aos logs. Depois de configurados, os novos dados ingeridos em workspaces vinculados são criptografados com sua chave armazenada no Azure Key Vault ou no "HSM" Gerenciado do Azure Key Vault.

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

Visão geral da chave gerenciada pelo cliente

Criptografia em repouso é um requisito comum de privacidade e segurança em organizações. Você pode permitir que o Azure gerencie completamente a criptografia em repouso, enquanto você tem várias opções para gerenciar de forma rigorosa 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). Você pode criptografar dados usando sua própria chave no Azure Key Vault, para controlar o ciclo de vida da chave e a capacidade de revogar o acesso aos seus dados. O uso da criptografia pelo Azure Monitor é idêntico ao uso pelo Armazenamento do Microsoft Azure.

A chave gerenciada pelo cliente é entregue em clusters dedicados, fornecendo maior nível de proteção e controle. Os dados são criptografados no armazenamento duas vezes, uma vez no nível do 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 criptografia dupla protege contra um cenário em que um dos algoritmos ou chaves de criptografia pode estar comprometido. O cluster dedicado também permite proteger dados com o Lockbox.

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 do SSD permanecem criptografados com chaves da Microsoft, seja qual for a configuração da chave gerenciada pelo cliente, mas seu controle sobre o acesso ao SSD segue a revogação de chave

O modelo de preços de Clusters Dedicados do Log Analytics exige um nível de compromisso começando em 100 GB/dia.

Como funciona a chave gerenciada pelo cliente no Azure Monitor

O Azure Monitor usa identidade gerenciada para conceder acesso ao Azure Key Vault. A identidade do cluster de Log Analytics é permitida no nível de cluster. Para permitir uma chave gerenciada pelo cliente em vários workspaces, um novo recurso de Cluster do Log Analytics executa uma conexão de identidade intermediária entre o Key Vault e seus workspaces do Log Analytics. O armazenamento do cluster utiliza a identidade gerida associada ao cluster para autenticar o seu 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 ao sistema é mais simples e gerada automaticamente com a criação do cluster quando identidade type é definida como “SystemAssigned”. Essa identidade pode ser usada posteriormente para conceder acesso de armazenamento à sua Key Vault para operações de encapsulamento e desencapsulamento.
  • A identidade gerenciada atribuída pelo usuário permite configurar a chave gerenciada pelo cliente na criação do cluster, ao conceder a ela permissões no Key Vault antes da criação do cluster.

Você pode aplicar a configuração de chave gerenciada pelo cliente a um novo cluster ou a um cluster existente vinculado a workspaces e ingestão de dados. Novos dados ingeridos em workspaces 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 chave gerenciada pelo cliente e são executadas em dados antigos e novos perfeitamente. Você pode desvincular os workspaces do cluster quando quiser. Os novos dados ingeridos após a desvinculação são criptografados com a chave da Microsoft, e as consultas são realizadas normalmente em dados novos e antigos.

Importante

A capacidade da chave gerenciada pelo cliente é regional. Seu Azure Key Vault, cluster e workspaces vinculados precisam estar na mesma região, mas 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 Key Vault – A identidade é propagada para o armazenamento de cluster dedicado subjacente
  3. Cluster dedicado
  4. Workspaces vinculados ao cluster dedicado

Operação 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.
  • Quando você configura uma chave em seu Key Vault e atualiza os detalhes da chave no cluster, o armazenamento de cluster executa solicitações para encapsular e desencapsular a AEK para criptografia e descriptografia.
  • A sua KEK nunca deixa seu Key Vault e, no caso de uma HSM gerenciado, ela nunca deixa o hardware.
  • O Armazenamento do Microsoft Azure usa a identidade gerenciada associada ao recurso de 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. Criar cluster
  3. Conceder permissões ao Key Vault
  4. Atualizar cluster com detalhes do identificador de chave
  5. Vinculando workspaces

A configuração de chave gerenciada pelo cliente não é permitida no portal do Azure atualmente e o provisionamento pode ser executado por meio do PowerShell, da CLI ou de solicitações 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.

Screenshot of soft delete and purge protection settings.

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

Criar cluster

Os clusters utilizam identidade gerenciada para criptografia de dados com seu Key Vault. Configure a propriedade de identidadetype para SystemAssigned ao criar o cluster para permitir o acesso ao seu Key Vault para operações de encapsular e desencapsular.

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

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

Siga o artigo procedimento ilustrado no artigo de clusters dedicados.

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

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

    Screenshot of Grant Key Vault RBAC permissions.

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

    Abra o Key Vault no portal do Azure e clique em Políticas de Acesso, selecione Política de acesso do cofre e clique em + Adicionar Política de Acesso para criar uma política com estas 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

    Screenshot of Grant Key Vault access policy permissions.

    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. Essa 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 usar para encapsulamento e desencapsulamento de AEK.

Importante

  • A rotação de chaves pode ser automática ou exigir atualização explícita de chave, confira 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 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.

Screenshot of Grant Key Vault permissions.

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.

Você precisa ter permissões de gravação tanto no workspace, quanto no cluster para executar essa operação. Ele inclui Microsoft.OperationalInsights/workspaces/write e Microsoft.OperationalInsights/clusters/write.

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 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 de cluster sempre respeita as alterações nas permissões de chave dentro de uma hora ou menos e o armazenamento fica indisponível. Novos dados ingeridos em workspaces vinculados são descartados e nã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 o cluster com "keyVaultProperties", mas omita a propriedade "keyVersion" ou defina-a como "". O armazenamento usa automaticamente a versão mais recente da chave.
  • Atualização explícita da versão da chave – atualize o cluster com a versão da chave na propriedade "keyVersion". A rotação de chave exige uma atualização "keyVaultProperties" explícita no cluster. 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 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.

Screenshot of Workbook save.

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.

  • 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 a chave da Microsoft. Você pode consultar dados ingeridos antes e depois da configuração da chave gerenciada pelo cliente sem problemas.

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

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

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 cluster do Armazenamento do Azure acessa o Key Vault para operações de encapsulamento e desencapsulamento é entre seis 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 do workspace ao cluster falhará se ele 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 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 é recuperável. 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