Integrar o Azure Key Vault no Azure Policy
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. Ele permite que os usuários realizem auditoria, imposição em tempo real e correção de seu ambiente do Azure. Os resultados das auditorias realizadas pela política estão disponíveis para os usuários em um painel de conformidade, onde eles podem ver uma análise detalhada de quais recursos e componentes estão em conformidade e quais não estão. Para obter mais informações, consulte Descrição geral do serviço Azure Policy.
Exemplos de cenários de utilização:
- Você quer melhorar a postura de segurança da sua empresa implementando requisitos em torno de tamanhos mínimos de chaves e períodos máximos de validade de certificados nos cofres de chaves da sua empresa, mas não sabe quais equipes estarão em conformidade e quais não estão.
- No momento, você não tem uma solução para realizar uma auditoria em toda a sua organização ou está conduzindo auditorias manuais do seu ambiente solicitando que equipes individuais dentro da sua organização relatem sua conformidade. Você está procurando uma maneira de automatizar essa tarefa, realizar auditorias em tempo real e garantir a precisão da auditoria.
- Você deseja aplicar as políticas de segurança da sua empresa e impedir que indivíduos criem certificados autoassinados, mas não tem uma maneira automatizada de bloquear sua criação.
- Deseja relaxar em alguns requisitos para as suas equipas de teste, mas deseja manter controlos rígidos sobre o seu ambiente de produção. Precisa de uma maneira automatizada simples de separar a aplicação dos seus recursos.
- Você quer ter certeza de que pode reverter a aplicação de novas políticas no caso de haver um problema no site ativo. Você precisa de uma solução de um clique para desativar a aplicação da política.
- Você está confiando em uma solução de terceiros para auditar seu ambiente e deseja usar uma oferta interna da Microsoft.
Tipos de efeitos políticos e orientações
Ao aplicar 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 aplicação de políticas pode se comportar de forma diferente dependendo do tipo de operação que você está avaliando. Em geral, os efeitos para as políticas que se integram ao Key Vault incluem:
Auditoria: quando o efeito de uma política é definido como
Audit, a política não causará alterações significativas no seu ambiente. Ele só alertará você sobre componentes como certificados que não estão em conformidade com as definições de política dentro de um escopo especificado, marcando esses componentes como não compatíveis no painel de conformidade de políticas. 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) e bloqueia novas versões de componentes existentes que não estão em conformidade com a definição de política. Os recursos não compatíveis existentes em um cofre de chaves não são afetados. As capacidades de «auditoria» continuam a funcionar.Desabilitado: quando o efeito de uma política é definido como
Disabled, a política ainda será avaliada, mas a aplicação não entrará em vigor, sendo assim compatível com a condição comDisabledefeito. Isso é útil para desativar a política para uma condição específica, em vez de todas as condições.Modificar: quando o efeito de uma política é definido como
Modify, você pode executar a adição de tags de recurso, como adicionar aDenytag a uma rede. Isso é útil para desabilitar o acesso a uma rede pública para o HSM gerenciado pelo Azure Key Vault. É necessário configurar uma identidade de gerenciamento para a definição da política por meio doroleDefinitionIdsparâmetro para utilizar oModifyefeito.DeployIfNotExists: quando o efeito de uma política é definido como
DeployIfNotExists, um modelo de implantação é executado quando a condição é atendida. Isso pode ser usado para definir configurações de diagnóstico para o Cofre da Chave para registrar o espaço de trabalho de análise. É necessário configurar uma identidade de gerenciamento para a definição da política por meio doroleDefinitionIdsparâmetro para utilizar oDeployIfNotExistsefeito.AuditIfNotExists: quando o efeito de uma política é definido como
AuditIfNotExists, você pode identificar recursos que não possuem as propriedades especificadas nos detalhes da condição da política. Isso é útil para identificar cofres de chaves que não têm logs de recursos habilitados. É necessário configurar uma identidade de gerenciamento para a definição da política por meio doroleDefinitionIdsparâmetro para utilizar oDeployIfNotExistsefeito.
Definições de política incorporadas disponíveis
As políticas predeterminadas, conhecidas como "internas", facilitam a governança sobre seus cofres de chaves para que você não precise escrever políticas personalizadas no formato JSON para impor regras comumente usadas associadas às práticas recomendadas de segurança. Embora os built-ins sejam predeterminados, 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. Os internos atuais do Azure Key Vault são categorizados em quatro grupos principais: cofre de chaves, certificados, chaves e gerenciamento de segredos. Dentro de cada categoria, as políticas são agrupadas para impulsionar metas de segurança específicas.
Cofres de Chaves
Controlo de Acesso
Usando o serviço de Política do Azure, você pode controlar a migração para o modelo de permissão RBAC em seus cofres. Saiba mais em Migrar da política de acesso ao 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, desativar |
Acesso à rede
Reduza o risco de vazamento de dados restringindo o acesso à rede pública, habilitando conexões de 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 por firewall para que o cofre de chaves não seja acessível por padrão a nenhum IP público.
Proteção contra exclusão
Evite a perda permanente de dados do seu cofre de chaves e seus objetos ativando a proteção de exclusão suave e limpeza. Enquanto a exclusão suave permite que você recupere um cofre de chaves excluído acidentalmente por um período de retenção configurável, a proteção contra limpeza protege você contra ataques internos, impondo um período de retenção obrigatório para cofres de chaves excluídos por software. A proteção contra limpeza só pode ser ativada quando a exclusão suave estiver ativada. Ninguém dentro da sua organização ou da Microsoft pode limpar seus cofres de chaves durante o período de retenção de exclusão suave.
| Política | Efeitos |
|---|---|
| Os Cofres de Chaves devem ter a exclusão suave habilitada | Auditoria (padrão), negar, desativar |
| Os Cofres de Chaves devem ter a proteção contra limpeza ativada | Auditoria (padrão), negar, desativar |
| O HSM gerenciado do Azure Key Vault deve ter a proteção contra limpeza habilitada | Auditoria (padrão), negar, desativar |
Diagnóstico
Impulsione a habilitação de logs de recursos para recriar trilhas de atividades a serem usadas para fins de investigação quando ocorrer um incidente de segurança ou quando sua rede estiver comprometida.
| Política | Efeitos |
|---|---|
| Implantar configurações de diagnóstico para Cofres de Chaves em Hubs de Eventos | DeployIfNotExists (padrão) |
| Implantar - Definir configurações de diagnóstico para HSMs gerenciados pelo Cofre de Chaves para Hubs de Eventos | DeployIfNotExists (padrão), desativado |
| Implantar - Definir configurações de diagnóstico para o espaço de trabalho Key Vaults to Log Analytics | DeployIfNotExists (padrão), desativado |
| Os logs de recursos nos Cofres de Chaves devem ser habilitados | AuditIfNotExists (padrão), desativado |
| Os logs de recursos nos HSMs gerenciados pelo Cofre de Chaves devem ser habilitados | AuditIfNotExists (padrão), desativado |
Certificados
Ciclo de vida dos certificados
Promova o uso de certificados de curta duração para mitigar ataques não detetados, minimizando o período de danos contínuos e reduzindo o valor do certificado para os invasores. Ao implementar certificados de curta duração, recomenda-se monitorar regularmente sua data de validade para evitar interrupções, para que possam ser alternados adequadamente antes da expiração. Você também pode controlar a ação de tempo de vida especificada para certificados que estão dentro de um determinado número de dias após sua expiração ou atingiram uma certa porcentagem de sua vida útil.
| Política | Efeitos |
|---|---|
| [Pré-visualização]: Os certificados devem ter o período máximo de validade especificado | Efeitos: Auditoria (padrão), Negar, Desativado |
| [Pré-visualização]: Os certificados não devem expirar dentro do número de dias especificado | Efeitos: Auditoria (padrão), Negar, Desativado |
| Os certificados devem ter os gatilhos de ação de tempo de vida especificados | Efeitos: Auditoria (padrão), Negar, Desativado |
Nota
É recomendável aplicar a política de expiração do certificado várias vezes com limites de expiração diferentes, por exemplo, nos 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 confiando em uma das autoridades de certificação integradas do Azure Key Vault (Digicert ou GlobalSign) ou em 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, desativado |
| Os certificados devem ser emitidos pela autoridade de certificação não integrada especificada | Auditoria (padrão), negar, desativado |
Atributos do certificado
Restrinja o tipo de certificados do cofre de chaves para que sejam apoiados por RSA, ECC ou 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 seus certificados de 2.048 bits, 3.072 bits ou 4.096 bits.
| Política | Efeitos |
|---|---|
| Os certificados devem usar tipos de chave permitidos | Auditoria (padrão), negar, desativado |
| Os certificados que usam criptografia de curva elíptica devem ter permitido nomes de curva | Auditoria (padrão), negar, desativado |
| Os certificados que usam criptografia RSA devem ter o tamanho mínimo de chave especificado | Auditoria (padrão), negar, desativado |
Chaves
Chaves apoiadas por 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 criptográficas. A chave criptográfica não pode sair de um HSM físico, que fornece um nível maior de segurança do que uma chave de software. Algumas organizações têm requisitos de conformidade que exigem o uso de chaves HSM. Você pode usar essa política para auditar quaisquer chaves armazenadas no Cofre de Chaves que não sejam suportadas pelo HSM. Você também pode usar essa política para bloquear a criação de novas chaves que não são suportadas pelo HSM. Esta política aplicar-se-á a todos os tipos de chave, incluindo RSA e ECC.
| Política | Efeitos |
|---|---|
| As chaves devem ser apoiadas por um módulo de segurança de hardware (HSM) | Auditoria (padrão), negar, desativado |
Ciclo de vida das chaves
Com o gerenciamento de ciclo de vida integrado, você pode sinalizar ou bloquear chaves que não têm uma data de validade, receber alertas sempre que atrasos na rotação de chaves possam 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 acionar 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 que garanta que sua rotação seja agendada dentro do número especificado de dias após a criação | Auditoria (padrão), desativado |
| As chaves do Cofre da Chave devem ter uma data de expiração | Auditoria (padrão), negar, desativado |
| [Pré-visualização]: As chaves HSM geridas devem ter uma data de expiração | Auditoria (padrão), negar, desativado |
| As chaves devem ter mais do que o número especificado de dias antes da expiração | Auditoria (padrão), negar, desativado |
| [Pré-visualização]: As chaves HSM geridas do Azure Key Vault devem ter mais do que o número especificado de dias antes da expiração | Auditoria (padrão), negar, desativado |
| As chaves devem ter o período de validade máximo especificado | Auditoria (padrão), negar, desativado |
| As chaves não devem ficar ativas por mais tempo do que o número especificado de dias | Auditoria (padrão), negar, desativado |
Importante
Se a sua 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 não compatível com a política. Se a sua 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é à data atual. Se o número de dias exceder o limite definido, a chave será marcada como não compatível com a política.
Atributos principais
Restrinja o tipo de chaves do Cofre de Chaves para que sejam apoiadas por RSA, ECC ou 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 o uso de um tamanho mínimo de chave para chaves atuais e novas de 2048 bits, 3072 bits ou 4096 bits. Tenha em mente que o uso de chaves RSA com tamanhos de chave menores não é uma prática de design segura, portanto, recomenda-se 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 criptográfico especificado RSA ou EC | Auditoria (padrão), negar, desativado |
| As chaves que usam criptografia de curva elíptica devem ter os nomes de curva especificados | Auditoria (padrão), negar, desativado |
| [Pré-visualização]: As chaves HSM geridas do Azure Key Vault que utilizam criptografia de curva elíptica devem ter os nomes de curva especificados | Auditoria (padrão), negar, desativado |
| As chaves que usam criptografia RSA devem ter um tamanho de chave mínimo especificado | Auditoria (padrão), negar, desativado |
| [Pré-visualização]: As chaves HSM geridas do Azure Key Vault que utilizam encriptação RSA devem ter um tamanho mínimo de chave especificado | Auditoria (padrão), negar, desativado |
Segredos
Ciclo de vida dos segredos
Com o gerenciamento de ciclo de vida integrado, você pode sinalizar ou bloquear segredos que não têm uma data de validade, receber alertas sempre que atrasos na rotação secreta possam 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 acionar a rotação de chaves e impedir que as chaves fiquem ativas por mais de um número especificado de dias.
| Política | Efeitos |
|---|---|
| Os segredos devem ter uma data de validade | Auditoria (padrão), negar, desativado |
| Os segredos devem ter mais do que o número especificado de dias antes da expiração | Auditoria (padrão), negar, desativado |
| Os segredos devem ter o período máximo de validade especificado | Auditoria (padrão), negar, desativado |
| Os segredos não devem estar ativos por mais tempo do que o número de dias especificado | Auditoria (padrão), negar, desativado |
Importante
Se o seu 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 não compatível com a política. Se o seu 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é à data atual. Se o número de dias exceder o limite definido, o segredo será marcado como não compatível com a política.
Atributos secretos
Qualquer texto sem formatação ou arquivo codificado pode ser armazenado como um segredo do cofre de chaves do Azure. No entanto, sua organização pode querer definir diferentes políticas de rotação e restrições sobre senhas, cadeias de conexão ou certificados armazenados como chaves. Uma tag de tipo de conteúdo pode ajudar um usuário a ver o que está armazenado em um objeto secreto sem ler o valor do segredo. Você pode auditar segredos que não têm 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, desativado |
Cenário de Exemplo
Você gerencia um cofre de chaves usado por várias equipes que contém 100 certificados e deseja garantir que nenhum dos certificados no cofre de chaves seja válido por mais de 2 anos.
- Você atribui os certificados deve ter a política de período de validade máximo especificado, especifica que o período de validade máximo de um certificado é de 24 meses e define o efeito da política como "auditoria".
- Você exibe o relatório de conformidade no portal do Azure e descobre que 20 certificados não são compatíveis e válidos por > 2 anos, e os certificados restantes são compatíveis.
- 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 equipas respondem e 15 dos certificados foram renovados com um período máximo de validade igual ou inferior a 2 anos. Outras equipes não respondem e você ainda tem 5 certificados não compatíveis em seu cofre de chaves.
- Você altera o efeito da política atribuída a "negar". Os 5 certificados não conformes não são revogados e continuam a funcionar. No entanto, não podem ser renovados com um período de validade superior a 2 anos.
Habilitar e gerenciar uma política de cofre de chaves por meio do portal do Azure
Selecionar uma definição de política
Inicie sessão no portal do Azure.
Pesquise "Política" na barra de pesquisa e selecione Política.
Na janela Política, selecione Definições.
No Filtro de categoria, desmarque Selecionar tudo e selecione Cofre de chaves.
Agora você deve ser capaz de ver todas as políticas disponíveis para Visualização Pública, para o Cofre de Chaves do Azure. Certifique-se de que leu e compreendeu a secção de orientações de política acima e selecione uma política que pretende atribuir a um âmbito.
Atribuir uma política a um escopo
Selecione uma política que deseja aplicar, neste exemplo, a política Gerenciar Período de Validade do Certificado é mostrada. Clique no botão Atribuir no canto superior esquerdo.
Selecione a subscrição à qual pretende que a política seja aplicada. Você pode optar por restringir o escopo a apenas 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 pode configurar uma lista de exclusão. Defina o seletor de imposição de política como Habilitado se desejar que o efeito da política (auditoria ou negação) ocorra ou Desabilitado para desativar o efeito (auditoria ou negação).
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 você precisar inserir os parâmetros, você pode desmarcar a opção 'Mostrar apenas parâmetros que precisam de entrada ou revisão'. Selecione auditar ou negar para o efeito da política seguindo as orientações nas seções acima. Em seguida, selecione o botão rever + criar.
Ver resultados de conformidade
Volte para a folha Política e selecione a guia de conformidade. Clique na atribuição de política para a qual deseja visualizar os resultados de conformidade.
Nesta página, você pode filtrar os resultados por cofres compatíveis ou não compatíveis. Aqui você pode ver uma lista de cofres de chaves não compatíveis dentro do escopo da atribuição de política. Um cofre é considerado não compatível se qualquer um dos componentes (certificados) no cofre não estiver em conformidade. Você pode selecionar um cofre individual para exibir os componentes individuais não compatíveis (certificados).
Exibir o nome dos componentes dentro de um cofre que não são compatíveis
Se você precisar verificar se está sendo negada aos usuários a capacidade de criar recursos no cofre de chaves, clique na guia Eventos de componentes (visualização) para exibir um resumo das operações de certificado negadas com o solicitante e carimbos de data/hora das solicitações.
Limitações da Funcionalidade
A atribuição de uma política com um efeito de "negação" pode levar até 30 minutos (caso médio) e 1 hora (pior caso) para começar a negar a criação de recursos não compatíveis. O atraso refere-se aos seguintes cenários:
- É atribuída uma nova política.
- Uma atribuição de política existente é modificada.
- Um novo KeyVault (recurso) é criado em um escopo com políticas existentes.
A avaliação de política de componentes existentes em um cofre pode levar até 1 hora (caso médio) e 2 horas (pior caso) antes que os resultados de conformidade sejam visíveis na interface do usuário do portal.
Se os resultados de conformidade aparecerem como "Não iniciado", pode ser devido aos seguintes motivos:
- A avaliação da apólice 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 dentro do escopo da atribuição de política.
Nota
Os modos do Provedor de Recursos de Política do Azure, como os do Cofre de Chaves do Azure, fornecem informações sobre conformidade na página Conformidade de Componentes.
Passos Seguintes
- Registo e perguntas frequentes sobre a política do Azure para o Cofre da Chave
- Saiba mais sobre o Serviço Azure Policy
- Consulte Exemplos do Cofre da Chave: definições de política internas do Cofre da Chave
- Saiba mais sobre o benchmark de segurança na nuvem da Microsoft no Key Vault