Integrar o Azure Key Vault ao Azure Policy

Artigo
08/08/2024

O Azure Policy é uma ferramenta de governança que oferece aos usuários a capacidade de auditar e gerenciar seu ambiente do Azure em escala, permitindo que eles coloquem proteções nos recursos do Azure para garantir que estejam em conformidade com as regras de política atribuídas. A ferramenta permite que os usuários realizem auditoria, imposição em tempo real e correção do ambiente do Azure. Os resultados das auditorias realizadas pela política estão disponíveis aos usuários em um painel de conformidade que mostra o detalhamento de quais recursos e componentes estão em conformidade e quais não estão. Para obter mais informações, consulte a Visão geral do serviço Azure Policy.

Exemplo de cenários de uso:

Você quer melhorar a postura de segurança da empresa implementando requisitos quanto aos tamanhos mínimos de chave e períodos máximos de validade dos certificados nos cofres de chaves da sua empresa, mas não sabe quais equipes vão cumpri-los e quais não vão.
Atualmente, você não tem uma solução para executar uma auditoria na organização ou está realizando auditorias manuais do ambiente, solicitando que equipes individuais dentro da organização relatem a respectiva conformidade. Está procurando uma maneira de automatizar essa tarefa, executar auditorias em tempo real e garantir a precisão da auditoria.
Você quer impor as políticas de segurança da empresa e impedir que as pessoas criem certificados autoassinados, mas não tem um método automatizado de bloquear essa criação.
Você quer suavizar alguns requisitos para as equipes de teste, mas manter rígido controle sobre o ambiente de produção. Você precisa de uma maneira simples e automatizada de separar a imposição de seus recursos.
Você quer ter a certeza de que pode reverter a imposição de novas políticas no caso de um problema do site ativo. Você precisa de uma solução para desativar a imposição da política com apenas um clique.
Você está contando com uma solução de terceiros para auditar seu ambiente e quer usar uma oferta interna da Microsoft.

Diretrizes e tipos de efeito da política

Ao impor uma política, você pode determinar seu efeito sobre a avaliação resultante. Cada definição de política permite que você escolha um dos vários efeitos. Portanto, a imposição da política talvez se comporte de forma diferente dependendo do tipo de operação que você está avaliando. Em geral, os efeitos das políticas que se integram ao Key Vault incluem:

Auditoria: quando o efeito de uma política for definido como Audit, a política não causará alterações interruptivas no ambiente. Ela só alertará você sobre componentes, como certificados que não estão em conformidade com as definições da política em um escopo especificado, marcando-os como fora de conformidade no painel de conformidade com a política. A auditoria será padrão se nenhum efeito de política for selecionado.
Negar: quando o efeito de uma política é definido como Deny, a política bloqueia a criação de novos componentes (como certificados), bem como novas versões de componentes existentes que não cumprem a definição da política. Os recursos existentes não compatíveis em um cofre de chaves não são afetados. Os recursos de "auditoria" continuarão funcionando.
Desabilitado: quando o efeito de uma política for definido como Disabled, a política ainda será avaliada, mas a imposição não entrará em vigor, sendo assim compatível com a condição com o efeito Disabled. Isso é útil para desabilitar a política para uma condição específica em vez de todas as condições.
Modificar: quando o efeito de uma política for definido como Modify, você poderá executar a adição de marcas de recurso, como adicionar a marca Deny a uma rede. Isso é útil para desabilitar o acesso a uma rede pública para o HSM gerenciado do Azure Key Vault. É necessário configurar uma identidade de gerenciamento para a definição de política por meio do parâmetro roleDefinitionIds para utilizar o efeito Modify.
DeployIfNotExists: quando o efeito de uma política for definido como DeployIfNotExists, um modelo de implantação será executado quando a condição for atendida. Isso pode ser usado para definir as configurações de diagnóstico do Azure Key Vault no workspace do Log Analytics. É necessário configurar uma identidade de gerenciamento para a definição de política por meio do parâmetro roleDefinitionIds para utilizar o efeito DeployIfNotExists.
AuditIfNotExists: quando o efeito de uma política for definido como AuditIfNotExists, você poderá identificar recursos que não têm as propriedades especificadas nos detalhes da condição de política. Isso é útil para identificar cofres de chaves que não tenham logs de recursos habilitados. É necessário configurar uma identidade de gerenciamento para a definição de política por meio do parâmetro roleDefinitionIds para utilizar o efeito DeployIfNotExists.

Definições de política interna disponíveis

As políticas predeterminadas, conhecidas como "internas", facilitam a governança nos cofres de chaves de modo que não seja necessário escrever políticas personalizadas no formato JSON para impor regras comumente usadas associadas às melhores práticas de segurança. Embora as internas sejam predeterminadas, certas políticas exigem que você defina parâmetros. Por exemplo, definindo o efeito da política, você pode auditar o cofre de chaves e seus objetos antes de impor uma operação de negação para evitar interrupções. As internas atuais do Azure Key Vault são categorizadas em quatro grupos principais: cofre de chaves, certificados, chaves e gerenciamento de segredos. Dentro de cada categoria, as políticas são agrupadas para direcionar metas de segurança específicas.

Cofres de Chaves

Controle de acesso

Usando o serviço Azure Policy, você pode governar a migração para o modelo de permissão do RBAC em seus cofres. Saiba mais em Migrar da política de acesso do cofre para um modelo de permissão de controle de acesso baseado em função do Azure

Política	Efeitos
O Azure Key Vault deve usar o modelo de permissão RBAC	Auditoria (Padrão), Negar, Desabilitado

Acesso de rede

Reduza o risco de vazamento de dados restringindo o acesso à rede pública, habilitando conexões do Link Privado do Azure, criando zonas DNS privadas para substituir a resolução DNS para um ponto de extremidade privado e habilitando a proteção de firewall para que o cofre de chaves não seja acessível por padrão a qualquer IP público.

Política	Efeitos
O Azure Key Vault deve desabilitar o acesso à rede pública	Auditoria (Padrão), Negar, Desabilitado
[Versão prévia] O HSM Gerenciado do Azure Key Vault deve desabilitar o acesso à rede pública	Auditoria (Padrão), Negar, Desabilitado
[Versão prévia]: configurar HSMs Gerenciados do Azure Key Vault para desabilitar o acesso à rede pública	Modificar (Padrão), Desabilitado
[Versão prévia]: os cofres de chaves do Azure devem usar link privado	Auditoria (Padrão), Negar, Desabilitado
[Versão prévia]: HSMs Gerenciados do Azure Key Vault devem usar link privado	Auditoria (Padrão), Desabilitado
[Versão prévia]: configurar os cofres de chaves do Azure com pontos de extremidade privados	DeployIfNotExists (Padrão), Desabilitado
[Preview]: Configurar o HSM gerenciado do Azure Key Vault com pontos de extremidade privados	DeployIfNotExists (Padrão), Desabilitado
[Versão prévia]: configurar os cofres de chaves do Azure para usar zonas DNS privadas	DeployIfNotExists (Padrão), Desabilitado
Cofres de Chaves devem ter firewall habilitado	Auditoria (Padrão), Negar, Desabilitado
Configurar Cofres de Chaves para habilitar o firewall	Modificar (Padrão), Desabilitado

Proteção contra exclusão

Evite a perda permanente de dados do cofre de chaves e seus objetos habilitando a exclusão reversível e a proteção de limpeza. Enquanto a exclusão reversível permite que você recupere um cofre de chaves excluído acidentalmente por um período de retenção configurável, a proteção de limpeza protege você contra ataques internos aplicando um período de retenção obrigatório para cofres de chaves excluídos temporariamente. A proteção contra limpeza só poderá ser habilitada quando a exclusão reversível estiver habilitada. Ninguém dentro de sua organização nem a Microsoft pode limpar os cofres de chaves durante o período de retenção de exclusão temporária.

Policy	Efeitos
Cofres de Chaves devem ter exclusão temporária habilitada	Auditoria (Padrão), Negar, Desabilitado
Cofres de Chaves devem ter proteção de limpeza habilitada	Auditoria (Padrão), Negar, Desabilitado
O HSM Gerenciado do Azure Key Vault deve ter a proteção contra limpeza habilitada	Auditoria (Padrão), Negar, Desabilitado

Diagnósticos

Controle a habilitação dos logs de recursos para recriar as trilhas de atividade a serem usadas para fins de investigação quando ocorrer um incidente de segurança ou quando a rede for comprometida.

Política	Efeitos
Implantar configurações de diagnóstico para Key Vaults nos Hubs de Eventos	DeployIfNotExists (Padrão)
Implantar – Definir configurações de diagnóstico para HSMs gerenciados pelo Key Vault para Hubs de Eventos	DeployIfNotExists (Padrão), Desabilitado
Implantar – Definir configurações de diagnóstico de Cofres de Chaves no workspace do Log Analytics	DeployIfNotExists (Padrão), Desabilitado
Logs de recursos em Cofres de Chaves devem estar habilitados	AuditIfNotExists (Padrão), Desabilitado
Logs de recursos m HSMs Gerenciados do Key Vault devem estar habilitados	AuditIfNotExists (Padrão), Desabilitado

Certificados

Ciclo de vida de certificados

Promova o uso de certificados de curta duração para atenuar ataques não detectados, minimizando o período de danos contínuos e reduzindo o valor do certificado para os invasores. Ao implementar certificados de curta duração, é recomendável monitorar regularmente a data de validade deles para evitar interrupções, de modo que possam ser girados adequadamente antes da expiração. Também é possível controlar a ação de tempo de vida especificada para certificados que estão dentro de um determinado número de dias de sua expiração ou que atingiram uma determinada porcentagem de sua vida útil.

Política	Efeitos
[Versão prévia]: certificados devem ter o período de validade máximo especificado	Efeitos: Auditoria (Padrão), Negar, Desabilitado
[Versão prévia]: certificados não devem expirar após o número de dias especificado	Efeitos: Auditoria (Padrão), Negar, Desabilitado
Os certificados devem ter os gatilhos de ação de tempo de vida especificados	Efeitos: Auditoria (Padrão), Negar, Desabilitado

Observação

É recomendável aplicar a política de expiração do certificado várias vezes com diferentes limites de expiração como, por exemplo, limites de 180, 90, 60 e 30 dias.

Autoridade de certificação

Audite ou imponha a seleção de uma autoridade de certificação específica para emitir seus certificados, contando com uma das autoridades de certificação integradas do Azure Key Vault (Digicert ou GlobalSign) ou com uma autoridade de certificação não integrada de sua preferência. Você também pode auditar ou negar a criação de certificados autoassinados.

Política	Efeitos
Os certificados devem ser emitidos pela autoridade de certificação integrada especificada	Auditoria (Padrão), Negar, Desabilitado
Os certificados devem ser emitidos pela autoridade de certificação não integrada especificada	Auditoria (Padrão), Negar, Desabilitado

Atributos de certificado

Restrinja o tipo dos certificados do cofre de chaves para ser RSA, ECC ou com suporte de HSM. Se você usar criptografia de curva elíptica ou certificados ECC, poderá personalizar e selecionar nomes de curva, como P-256, P-256K, P-384 e P-521. Se você usar certificados RSA, poderá escolher um tamanho mínimo de chave para que os certificados sejam de 2048 bits, 3072 bits ou 4096 bits.

Policy	Efeitos
Os certificados devem usar os tipos de chave permitidos	Auditoria (Padrão), Negar, Desabilitado
Os certificados que usam a criptografia de curva elíptica devem ter nomes de curva permitidos	Auditoria (Padrão), Negar, Desabilitado
Os certificados que usam a criptografia RSA devem ter o tamanho mínimo de chave especificado	Auditoria (Padrão), Negar, Desabilitado

simétricas

Chaves com suporte de HSM

Um HSM é um módulo de segurança de hardware que armazena chaves. Um HSM fornece uma camada física de proteção para chaves de criptografia. A chave de criptografia não pode sair de um HSM físico, o que fornece um nível maior de segurança do que uma chave de software. Algumas organizações têm requisitos de conformidade que determinam o uso de chaves do HSM. Você pode usar essa política para auditar todas as chaves armazenadas no Key Vault que não tenham suporte de HSM. Você também pode usá-la para bloquear a criação de chaves que não tenham suporte do HSM. Essa política será aplicada a todos os tipos de chave, incluindo RSA e ECC.

Política	Efeitos
As chaves devem contar com o suporte de um HSM (módulo de segurança de hardware)	Auditoria (Padrão), Negar, Desabilitado

Ciclo de vida das chaves

Com os internos de gerenciamento do ciclo de vida, você pode sinalizar ou bloquear chaves que não tiverem uma data de validade, obter alertas sempre que atrasos na rotação de chaves puderem resultar em uma interrupção, impedir a criação de novas chaves próximas à data de validade, limitar o tempo de vida e o status ativo das chaves para impulsionar a rotação de chaves e impedir que as chaves fiquem ativas por mais de um número especificado de dias.

Política	Efeitos
As chaves devem ter uma política de rotação garantindo que sua rotação seja agendada dentro do número especificado de dias após a criação	Auditoria (Padrão), Desabilitado
As chaves do Key Vault devem ter uma data de validade	Auditoria (Padrão), Negar, Desabilitado
[Versão prévia]: chaves de HSM Gerenciado devem ter uma data de expiração	Auditoria (Padrão), Negar, Desabilitado
As chaves devem ter um número maior de dias do que o especificado até a validade	Auditoria (Padrão), Negar, Desabilitado
[Versão Prévia]: chaves de HSM gerenciado do Azure Key Vault devem ter um número de dias até a expiração maior que o especificado	Auditoria (Padrão), Negar, Desabilitado
As chaves devem ter o período máximo de validade especificado	Auditoria (Padrão), Negar, Desabilitado
As chaves não devem ficar ativas por mais tempo do que o número de dias especificado	Auditoria (Padrão), Negar, Desabilitado

Importante

Se a chave tiver uma data de ativação definida, a política acima calculará o número de dias decorridos desde a data de ativação da chave até a data atual. Se o número de dias exceder o limite definido, a chave será marcada como sem conformidade com a política. Se a chave não tiver uma data de ativação definida, a política calculará o número de dias decorridos desde a data de criação da chave até a data atual. Se o número de dias exceder o limite definido, a chave será marcada como sem conformidade com a política.

Atributos de chave

Restrinja o tipo dos certificados das chaves do Key Vault para ser RSA, ECC ou ter suporte de HSM. Se você usar criptografia de curva elíptica ou chaves ECC, poderá personalizar e selecionar nomes de curva, como P-256, P-256K, P-384 e P-521. Se você usar chaves RSA, poderá exigir que o uso de um tamanho mínimo de chave para chaves atuais e novas seja de 2048 bits, 3072 bits ou 4096 bits. Tenha em mente que usar chaves RSA com tamanhos de chave menores não é uma prática de design segura, portanto, é recomendável bloquear a criação de novas chaves que não atendam ao requisito de tamanho mínimo.

Política	Efeitos
As chaves devem ser do tipo de criptografia especificado, RSA ou EC	Auditoria (Padrão), Negar, Desabilitado
As chaves que usam a criptografia de curva elíptica devem ter os nomes de curva permitidos	Auditoria (Padrão), Negar, Desabilitado
[Versão Prévia]: chaves de HSM gerenciado do Azure Key Vault que usam criptografia de curva elíptica devem ter os nomes de curva especificados	Auditoria (Padrão), Negar, Desabilitado
As chaves que usam a criptografia RSA devem ter o tamanho mínimo da chave especificado	Auditoria (Padrão), Negar, Desabilitado
[Versão Prévia]: chaves de HSM gerenciado do Azure Key Vault que usam a criptografia RSA devem ter um tamanho mínimo de chave especificado	Auditoria (Padrão), Negar, Desabilitado

Segredos

Ciclo de vida dos segredos

Com os internos de gerenciamento do ciclo de vida, você pode sinalizar ou bloquear segredos que não tiverem uma data de validade, obter alertas sempre que atrasos na rotação de segredos puderem resultar em uma interrupção, impedir a criação de novas chaves próximas à data de validade, limitar o tempo de vida e o status ativo das chaves para impulsionar a rotação de chaves e impedir que as chaves fiquem ativas por mais de um número especificado de dias.

Política	Efeitos
Segredos devem ter uma data de validade	Auditoria (Padrão), Negar, Desabilitado
Os segredos devem ter um número maior de dias do que o especificado até a validade	Auditoria (Padrão), Negar, Desabilitado
Os segredos devem ter o período máximo de validade especificado	Auditoria (Padrão), Negar, Desabilitado
Os segredos não devem ficar ativos por mais tempo do que o número de dias especificado	Auditoria (Padrão), Negar, Desabilitado

Importante

Se o segredo tiver uma data de ativação definida, a política acima calculará o número de dias decorridos desde a data de ativação do segredo até a data atual. Se o número de dias exceder o limite definido, o segredo será marcado como sem conformidade com a política. Se o segredo não tiver uma data de ativação definida, esta política calculará o número de dias decorridos desde a data de criação do segredo até a data atual. Se o número de dias exceder o limite definido, o segredo será marcado como sem conformidade com a política.

Atributos de segredos

Qualquer texto sem formatação ou arquivo codificado pode ser armazenado como um segredo do cofre de chaves. No entanto, sua organização pode definir diferentes políticas de rotação e restrições em senhas, cadeias de conexão ou certificados armazenados como chaves. Uma marca de tipo de conteúdo pode ajudar o usuário a saber o que está armazenado em um objeto de segredo sem ler o valor do segredo. Você pode auditar segredos que não tenham uma marca de tipo de conteúdo definida ou impedir que novos segredos sejam criados se eles não tiverem uma marca de tipo de conteúdo definida.

Política	Efeitos
Os segredos devem ter o tipo de conteúdo definido	Auditoria (Padrão), Negar, Desabilitado

Cenário de Exemplo

Você gerencia um cofre de chaves usado por várias equipes; o cofre contém 100 certificados e você quer ter certeza de que nenhum desses certificados será válido por mais de 2 anos.

Você atribui a política Os certificados devem ter o período de validade máximo especificado, especifica que o período máximo de validade de um certificado é de 24 meses e define o efeito da política como "Auditar".
Você exibe o relatório de conformidade no portal do Azure e descobre que 20 certificados estão fora de conformidade e são válidos por > 2 anos, e que os certificados restantes estão em conformidade.
Você entra em contato com os proprietários desses certificados e comunica o novo requisito de segurança de que os certificados não podem ser válidos por mais de 2 anos. Algumas equipes respondem e 15 dos certificados foram renovados com um período de validade máximo de 2 anos ou menos. Outras equipes não respondem e você ainda tem 5 certificados fora de conformidade em seu cofre de chaves.
Você altera o efeito da política que atribuiu como "negar". Os 5 certificados fora de conformidade não são revogados e continuam funcionando. No entanto, eles não podem ser renovados com um período de validade superior a 2 anos.

Habilitação e gerenciamento de uma política do cofre de chaves por meio do portal do Azure

Selecionar uma definição de política

Faça logon no Portal do Azure.
Procure por "Política" na barra de pesquisa e selecione Política.
Na janela Política, selecione Definições.
No filtro Categoria, desmarque Selecionar Tudo e selecione Key Vault.
Agora deve ser possível ver todas as políticas disponíveis para Visualização Pública do Azure Key Vault. Certifique-se de que leu e entendeu a seção de diretrizes de política acima e selecione uma política que queira atribuir a um escopo.

Atribuir uma política a um escopo

Selecione uma política que queira aplicar. Neste exemplo, a política Gerenciar o período de validade do certificado é mostrada. Clique no botão de atribuição no canto superior esquerdo.
Selecione a assinatura na qual deseja que a política seja aplicada. Você pode optar por restringir o escopo a um único grupo de recursos em uma assinatura. Se quiser aplicar a política a toda a assinatura e excluir alguns grupos de recursos, você também poderá configurar uma lista de exclusões. Defina o seletor de imposição de política para Habilitado se quiser que o efeito da política (auditar ou negar) ocorra ou para Desabilitado para desativar o efeito (auditar ou negar).
Clique na guia de parâmetros na parte superior da tela para especificar o período máximo de validade em meses que você deseja. Se precisar inserir os parâmetros, desmarque a opção "Mostrar somente os parâmetros que precisam de entrada ou revisão". Selecione auditar ou negar para o efeito da política seguindo as diretrizes nas seções acima. Em seguida, selecione o botão revisar + criar.

Exibir resultados da conformidade

Volte para a folha Política e selecione a guia Conformidade. Clique na atribuição de política para a qual deseja exibir os resultados da conformidade.
Nessa página, você pode filtrar os resultados por cofres em conformidade ou fora de conformidade. Aqui, você pode ver uma lista de cofres de chaves fora de conformidade no escopo da atribuição de política. Um cofre será considerado fora de conformidade se algum dos componentes (certificados) no cofre estiver fora de conformidade. É possível selecionar um cofre individual para exibir os componentes individuais fora de conformidade (certificados).
Exiba o nome dos componentes em um cofre que está fora de conformidade
Se precisar verificar se os usuários estão sendo impedidos de criar recursos no cofre de chaves, você poderá clicar na guia Eventos de Componente (versão prévia) para exibir um resumo das operações de certificado negadas com o solicitante e os carimbos de data/hora das solicitações.

Limitações do recurso

A atribuição de uma política com um efeito "negar" pode levar de 30 minutos (caso médio) a 1 hora (pior caso) para entrar em vigor e começar a negar a criação de recursos fora de conformidade. O atraso se refere aos seguintes cenários:

Uma nova política foi atribuída.
Uma atribuição de política existente foi modificada.
Um KeyVault (recurso) foi criado em um escopo com políticas existentes.

A avaliação da política de componentes existentes em um cofre pode levar de 1 hora (caso médio) a 2 horas (pior caso) antes que os resultados da conformidade possam ser vistos na interface do usuário do portal.

Se os resultados da conformidade aparecerem como "Não Iniciados", pode ser por um destes motivos:

A avaliação da política ainda não foi concluída. A latência da avaliação inicial pode levar até 2 horas no pior cenário.
Não há cofres de chaves no escopo da atribuição de política.
Não há cofres de chaves com certificados no escopo da atribuição de política.