Proteção de Dados

A proteção de dados protege informações confidenciais contra acesso não autorizado, exfiltração e uso indevido em todo o ciclo de vida dos dados. Implemente descoberta e classificação para estabelecer inventário de dados, criptografia para proteger dados em trânsito e em repouso e gerenciamento disciplinado de chaves e certificados para manter a integridade criptográfica. Essa abordagem em camadas está alinhada com os princípios do Zero Trust e estratégias de defesa em profundidade.

Sem uma proteção de dados abrangente, as organizações enfrentam violações de dados, penalidades regulatórias e danos à reputação decorrentes da exfiltração de informações confidenciais.

Aqui estão os três pilares principais do domínio de segurança da Proteção de Dados.

Conheça e classifique os seus dados: Descubra informações confidenciais e aplique rótulos consistentes para permitir controles baseados em risco.

Controlos relacionados:

• DP-1: Descubra, classifique e rotule dados confidenciais
• DP-2: Monitore anomalias e ameaças visando dados confidenciais

Proteja os dados com encriptação: Implemente criptografia abrangente para dados em trânsito e em repouso usando padrões criptográficos modernos.

Controlos relacionados:

• DP-3: Criptografar dados confidenciais em trânsito
• DP-4: Habilitar a criptografia de dados em repouso por padrão
• DP-5: Use a opção de chave gerenciada pelo cliente na criptografia de dados em repouso quando necessário

Gerencie a infraestrutura criptográfica: Estabeleça um gerenciamento disciplinado do ciclo de vida de chaves e certificados criptográficos com rotação automatizada e registro de auditoria abrangente.

Controlos relacionados:

• DP-6: Use um processo seguro de gerenciamento de chaves
• DP-7: Use um processo seguro de gerenciamento de certificados
• DP-8: Garantir a segurança do repositório de chaves e certificados

DP-1: Descubra, classifique e rotule dados confidenciais

Azure Policy: Consulte definições de políticas incorporadas do Azure: DP-1.

Princípio da segurança

Estabeleça e mantenha um inventário abrangente de dados confidenciais descobrindo, classificando e rotulando dados em todos os repositórios. Isso permite controles de acesso baseados em risco, políticas de criptografia e monitoramento para proteger contra acesso não autorizado e exfiltração.

Risco a mitigar

Os agentes de ameaças exploram a falta de visibilidade e o tratamento inconsistente de dados confidenciais para exfiltrar ou abusar de informações de alto valor. Quando dados confidenciais não são descobertos, classificados ou rotulados:

• Dados regulamentados não rastreados: (PCI, PHI, PII) armazenados em locais não gerenciados (shadow IT) ignoram os controles necessários de criptografia, retenção ou monitoramento.
• Acesso superprivilegiado: O amplo acesso ao usuário/serviço persiste porque a sensibilidade e o impacto nos negócios não são identificados.
• Proliferação de réplicas: A replicação de dados para analisar, testar ou exportar pipelines espalha conteúdo confidencial em ambientes de baixa confiança.
• Pontos cegos forenses: Os respondedores a incidentes não conseguem dimensionar rapidamente o raio de blasto devido a metadados de sensibilidade ausentes ou incorretos.
• Falha de automação: A governança (DLP, acesso condicional, fluxos de trabalho de criptografia) não é acionada sem uma rotulagem consistente.

A falta de classificação fundamental aumenta o tempo de permanência, amplia as oportunidades de movimento lateral e eleva a exposição regulatória e reputacional.

MITRE ATT&CK

• Reconhecimento (TA0043): coleta de identidade/ativos de dados da vítima (T1596) enumerando contas de armazenamento, catálogos de esquema e metadados de classificação para criar perfis de repositórios de alto valor.
• Descoberta (TA0007): enumeração de contas e permissões (T1087, T1069) para revelar ligações excessivas de função que permitem o escalonamento horizontal ou vertical de acesso a dados.
• Coleta (TA0009): dados do armazenamento em nuvem (T1530) extraindo contêineres de blob não rotulados ou exportações não gerenciadas sem tags de rastreamento.
• Exfiltração (TA0010): exfiltração através de serviços web (T1567) através de endpoints de exportação ad-hoc onde as barreiras de rotulagem/política estão ausentes.
• Exfiltração (TA0010): exfiltração automatizada (T1020) utilizando script de paginação / looping para recolher silenciosamente conjuntos de dados incorretamente classificados.

DP-1.1: Descubra, classifique e rotule dados confidenciais

Use o Microsoft Purview para criar um mapa de dados abrangente que descobre, classifica e rotula automaticamente informações confidenciais em todo o seu conjunto de dados. Estenda a proteção para além da criptografia no nível da infraestrutura implementando o Microsoft Purview Information Protection para aplicar criptografia persistente no nível do documento e direitos de uso que seguem os dados onde quer que eles viajem. Esse recurso fundamental permite que controles de segurança downstream, como prevenção contra perda de dados, acesso condicional e políticas de criptografia, operem com base na sensibilidade dos dados e não apenas na localização.

Descoberta e classificação de dados:

• Implante o Microsoft Purview para descobrir, classificar e rotular dados confidenciais no Azure, no local, no Microsoft 365 e em ambientes multinuvem.
• Use o Microsoft Purview Data Map para verificar e catalogar automaticamente fontes de dados, incluindo o Armazenamento do Azure, o Banco de Dados SQL do Azure, o Azure Synapse Analytics e outros serviços com suporte.
• Habilite rótulos de sensibilidade no Purview Data Map para aplicar automaticamente rótulos de classificação (por exemplo, Confidencial, Altamente Confidencial, PII, PHI) com base em padrões de conteúdo de dados e políticas organizacionais.

Criptografia e proteção no nível do documento:

• Implante o Microsoft Purview Information Protection para aplicar criptografia persistente e direitos de uso a documentos e e-mails com base em rótulos de confidencialidade. Configure rótulos para criptografar automaticamente arquivos, aplicar marcas d'água, restringir o encaminhamento, definir datas de validade e revogar o acesso mesmo depois que os dados saírem da sua organização.
• Habilite o Azure Rights Management Service (Azure RMS) como a tecnologia de proteção subjacente que criptografa documentos e emails com políticas de uso (somente exibição, sem cópia, sem impressão) que persistem independentemente de onde os dados são armazenados ou compartilhados.

Classificação e integração de bases de dados:

• Para bancos de dados SQL do Azure, habilite o SQL Data Discovery & Classification para identificar, classificar e rotular colunas que contenham dados confidenciais, como números de cartão de crédito, números de segurança social ou registros de saúde.
• Integre metadados de classificação com controles downstream: configure políticas de Prevenção de Perda de Dados (DLP) no Microsoft Purview, aplique regras de acesso condicional no Entra ID e imponha políticas de criptografia com base em rótulos de sensibilidade.
• Estabeleça um cronograma de verificação regular para descobrir continuamente ativos de dados confidenciais recém-criados ou modificados à medida que seu conjunto de dados evolui.

Exemplo de implementação

Uma organização global de serviços financeiros implantou o Microsoft Purview Data Map para descobrir e classificar automaticamente dados confidenciais em 200+ contas de Armazenamento do Azure, 50 bancos de dados SQL e espaços de trabalho do Synapse Analytics.

Desafio: A organização não tinha visibilidade de onde os dados confidenciais residiam em seu conjunto de dados do Azure em rápido crescimento. A classificação manual de dados era inconsistente, atrasava a aplicação da governança e criava lacunas de conformidade. Sem a descoberta automatizada, os dados regulamentados (PHI, PII, PCI) permaneciam desprotegidos em locais não gerenciados, e as políticas de prevenção contra perda de dados não podiam ser acionadas adequadamente.

Abordagem da solução:

• Implante o Microsoft Purview Data Map para descoberta de dados: Crie uma conta Purview e registre fontes de dados (contas de Armazenamento do Azure, bancos de dados SQL, espaços de trabalho do Synapse Analytics), configure o Mapa de Dados para verificar fontes usando autenticação de identidade gerenciada, conceda permissões de leitura de identidade de varredura (função db_datareader) para catalogar esquemas e detetar colunas confidenciais.
• Configure a classificação e a deteção de sensibilidade: Configurar regras de verificação para detetar padrões confidenciais (SSN, números de cartão de crédito, números de registros médicos, códigos SWIFT), definir regras de classificação personalizadas alinhadas com a política de classificação de dados ("Confidencial - Interno" para dados confidenciais de negócios, "Altamente Confidencial - Regulamentado" para dados PHI/PCI/PII), configurar limites de rotulagem automática (aplicar "Altamente Confidencial" quando ≥3 padrões PII detetados em um único ativo), estabelecer agendas de varredura com base na criticidade dos dados (semanalmente para produção, mensalmente para arquivos), configure alertas para notificar as equipes de segurança quando novos dados de alta sensibilidade forem descobertos.
• Implemente o Microsoft Purview Information Protection para criptografia no nível do documento: Crie rótulos de sensibilidade no portal de conformidade Purview com configurações de proteção (Público: sem criptografia, apenas marcações visuais; Interna: marca d'água, sem restrições de encaminhamento; Confidencial: criptografar com o Azure RMS, permitir visualização/edição apenas para funcionários, bloquear encaminhamento/impressão; Altamente Confidencial - Regulado: criptografar com o Azure RMS, acesso somente para visualização, sem cópia/impressão/encaminhamento, expiração de 90 dias, acesso revogável), publique rótulos de sensibilidade para usuários por meio de políticas de rótulos (escopo: departamentos Financeiro, Jurídico, Executivo), configure políticas de rotulagem automática para aplicar automaticamente rótulos (≥10 números de Segurança Social (SSNs) → "Altamente Confidencial - Regulamentado", ≥5 números de cartão de crédito → "Altamente Confidencial - Regulamentado"), habilite a proteção do Azure RMS para documentos rotulados armazenados no SharePoint, OneDrive e contas de Armazenamento do Azure, configure a rotulagem no lado do cliente para aplicativos do Office, solicitando que os usuários classifiquem documentos antes de salvar/enviar.

Resultado: A varredura automática do Purview Data Map identificou mais de 15.000 ativos de dados contendo dados regulamentados na primeira semana, reduzindo o tempo de descoberta de meses para dias. A etiquetagem automática da Proteção de Informações aplicou criptografia a 8.500 documentos em 72 horas. As etiquetas de sensibilidade permitiram uma visibilidade contínua do património de dados e uma proteção persistente, mesmo quando os dados são transferidos para dispositivos não geridos.

Nível de criticidade

Deve ter.

Mapeamento de controle

• Controles CIS v8.1: 3.2, 3.7, 3.13
• NIST SP 800-53 Rev.5: RA-2, SC-28
• PCI-DSS v4: 3.2.1, 12.3.1
• NIST CSF v2.0: PR. DS-1, PR. DS-5
• ISO 27001:2022: A.8.11
• SOC 2: CC6.1

DP-2: Monitorizar anomalias e ameaças que visam dados confidenciais

Azure Policy: Veja definições de políticas incorporadas no Azure: DP-2.

Princípio da segurança

Monitore o acesso a dados confidenciais e as atividades de transferência em busca de anomalias que indiquem exfiltração não autorizada, ameaças internas ou contas comprometidas. Use linhas de base comportamentais e contexto de sensibilidade de dados para detetar padrões incomuns, como grandes transferências, tempos de acesso anormais ou movimentação inesperada de dados.

Risco a mitigar

Adversários e insiders mal-intencionados tentam exfiltrar, preparar ou sondar dados confidenciais usando comportamentos furtivos ou de baixo sinal. Sem monitorização contínua de anomalias sensíveis ao contexto, ligada à sensibilidade dos dados:

• Exfiltração silenciosa: Exportações em massa, grandes conjuntos de resultados ou desvio incremental de dados passam despercebidos pela ausência de referências de base.
• Uso indevido de informação privilegiada: As credenciais legítimas executam sequências incomuns (hora do dia, volume, localidade) que ignoram o monitoramento grosseiro.
• Preparação e enumeração: Os atacantes mapeiam esquemas/etiquetas para priorizar alvos de alto valor antes da extração em massa.
• Perguntas sobre a vida fora da terra: As ferramentas administrativas padrão mascaram o reconhecimento em ruído operacional normal.
• Evasão entre lojas: O acesso distribuído por meio de vários serviços evita limites e correlações em armazenamento único.

A deteção inadequada de anomalias corrói a eficácia da resposta a incidentes e permite o escalonamento do reconhecimento para a exfiltração em grande escala com o mínimo de atrito.

MITRE ATT&CK

• Recolha (TA0009): dados do armazenamento na nuvem (T1530) através de leituras anómalas em massa ou de distribuição alargada em contentores sensíveis.
• Acesso a credenciais (TA0006): contas válidas (T1078) abusando de credenciais comprometidas ou internas para se misturar com linhas de base de tráfego legítimas.
• Exfiltração (TA0010): exfiltração automatizada (T1020) usando consultas com script controladas e concebidas para evitar limites de alerta.
• Exfiltração (TA0010): exfiltração para armazenamento em nuvem (T1567.002), armazenamento de dados em regiões ou contas controladas por invasores para posterior recuperação.
• Command & Control / Exfiltration (TA0011/TA0010): protocolo de camada de aplicação (T1071) tunelando linhas sensíveis através de chamadas normais de DB/API.
• Descoberta (TA0007): descoberta de sistemas/serviços (T1082, T1046) enumerando endereços para traçar caminhos de movimento lateral para locais de armazenamento de maior valor.

DP-2.1: Habilitar a deteção de ameaças para serviços de dados

Implante os serviços do Microsoft Defender para fornecer deteção de ameaças em tempo real e monitoramento de anomalias em suas plataformas de armazenamento de dados e banco de dados. Esses serviços usam análise comportamental e inteligência de ameaças para identificar atividades suspeitas, como tentativas de injeção de SQL, padrões de consulta anômalos, volumes incomuns de acesso a dados e potenciais indicadores de exfiltração que os controles de acesso tradicionais não conseguem detetar.

Habilite a deteção de ameaças para serviços de dados:

• Habilite o Microsoft Defender for Storage com verificação de malware e deteção de ameaças de dados confidenciais para monitorar padrões de acesso anômalos, volumes de upload/download incomuns e possíveis tentativas de exfiltração de dados em contas de Armazenamento do Azure.
• Habilite o Microsoft Defender for SQL para detetar atividades suspeitas de banco de dados, incluindo tentativas de injeção de SQL, padrões de consulta anômalos, operações de exportação de dados incomuns e acesso de locais desconhecidos.
• Habilite o Microsoft Defender para Azure Cosmos DB para detetar padrões anômalos de acesso ao banco de dados, exfiltração de dados em potencial e atividades operacionais suspeitas.
• Para bancos de dados de código aberto (PostgreSQL, MySQL, MariaDB), habilite o Microsoft Defender para bancos de dados relacionais de código aberto para detetar ataques de força bruta, padrões de acesso suspeitos e operações administrativas anômalas.

DP-2.2: Monitorar e evitar a exfiltração de dados

Implemente controles proativos de prevenção de perda de dados e monitoramento comportamental para detetar e bloquear transferências de dados não autorizadas antes que elas sejam bem-sucedidas. Combine DLP baseada em políticas com gerenciamento de risco interno, correlação SIEM e resposta automatizada para criar uma abordagem de defesa profunda que interrompa as tentativas de exfiltração em vários canais enquanto fornece evidências forenses para investigação de incidentes.

Implante controles de DLP e risco interno:

• Use as políticas de Prevenção de Perda de Dados (DLP) do Microsoft Purview para evitar a exfiltração de dados confidenciais monitorando e bloqueando transferências não autorizadas de dados classificados nos serviços do Azure, Microsoft 365 e pontos de extremidade.
• Implante o Microsoft Purview Insider Risk Management para detetar comportamentos de risco do usuário usando aprendizado de máquina e análise comportamental. Monitore indicadores, incluindo downloads de dados incomuns, cópia de arquivos para armazenamento em nuvem USB/pessoal, acesso a recursos confidenciais fora do horário normal de trabalho ou picos de acesso a dados antes das datas de demissão. O Insider Risk Management correlaciona sinais do Microsoft 365, Azure, sistemas de RH e ferramentas de segurança para identificar possíveis roubos de dados ou violações de políticas.

Configure o monitoramento e a resposta:

• Configure registos de diagnóstico para serviços de dados e encaminhe-os para o Azure Monitor ou Microsoft Sentinel a fim de estabelecer linhas de base comportamentais e detetar desvios dos padrões normais de acesso.
• Integre logs de serviço de dados com o Microsoft Sentinel para criar regras de análise para detetar padrões anômalos de acesso a dados, como downloads em massa, acesso fora do horário comercial ou comportamentos de consulta suspeitos.
• Implemente fluxos de trabalho automatizados de resposta a incidentes usando os Aplicativos Lógicos do Azure ou os playbooks do Microsoft Sentinel para isolar identidades comprometidas, revogar o acesso e notificar as equipes de segurança quando forem detetadas tentativas de exfiltração de dados.

Observação: Para requisitos de DLP baseados em host, implante recursos de DLP do Microsoft Purview Endpoint ou soluções de terceiros do Azure Marketplace para impor controles de proteção de dados no nível do ponto de extremidade.

Exemplo de implementação

Um provedor de serviços de saúde permitiu que o Microsoft Defender for Storage e o Defender for SQL monitorassem anomalias e ameaças direcionadas aos dados dos pacientes em contas de Armazenamento do Azure e bancos de dados SQL.

Desafio: A organização experimentou pontos cegos na deteção de acesso não autorizado a dados e tentativas de exfiltração. As defesas de perímetro tradicionais falharam em identificar ameaças internas e comprometeram os principais de serviço ao realizar downloads em massa. Sem análise comportamental e deteção de anomalias, os padrões de acesso suspeitos passaram despercebidos por longos períodos, aumentando o risco de violação e o tempo de permanência.

Abordagem da solução:

• Habilite o Microsoft Defender para armazenamento: Habilite o Defender for Storage no nível de assinatura para contas de armazenamento que contenham dados confidenciais, configure a verificação de malware para detetar e colocar em quarentena arquivos mal-intencionados no armazenamento de blobs, habilite a deteção de ameaças de dados confidenciais usando os tipos de informações confidenciais do Purview para identificar padrões de PHI/PII, defina limites de varredura por transação ou limites mensais para controlar custos, aplique proteção a grupos de recursos que contenham contas de armazenamento de produção que hospedam imagens médicas e exportações de EHR.
• Habilite o Microsoft Defender para SQL: Habilite o Defender for SQL no nível de assinatura do Banco de Dados SQL do Azure e da Instância Gerenciada SQL, configure a Avaliação de Vulnerabilidades com verificações recorrentes e designe a conta de armazenamento para resultados da verificação, configure notificações por email para alertar a equipe de segurança sobre vulnerabilidades identificadas, habilite a Proteção Avançada contra Ameaças para detetar tentativas de injeção de SQL, padrões de consulta incomuns, acesso anômalo de regiões desconhecidas, e potencial exfiltração de dados.
• Integre com o Microsoft Sentinel: Conecte o Microsoft Defender for Cloud ao Microsoft Sentinel usando o conector de dados, defina as configurações de diagnóstico (habilite logs de diagnóstico para operações de armazenamento e logs de auditoria SQL, roteie para o espaço de trabalho do Log Analytics), crie regras do Sentinel Analytics para detetar anomalias (alertas de download em massa para downloads >de 10 GB em 1 hora, acesso ao banco de dados fora do horário de expediente, padrões de consulta suspeitos), configure playbooks de resposta automatizados para isolar identidades comprometidas, Revogue o acesso ao armazenamento e notifique as equipes de segurança.
• Implante o Microsoft Purview Insider Risk Management para deteção comportamental de ameaças: Habilite o Insider Risk Management e configure modelos de política (roubo de dados por utilizadores em saída, detectando downloads de arquivos incomuns 30-90 dias antes da demissão, monitorização de vazamentos gerais de dados em USB/cópia de armazenamento em nuvem, vazamentos de dados por utilizadores prioritários com monitoramento aprimorado para funções de alto privilégio), configure indicadores de risco e limites (alertas cumulativos de volume de download de arquivos, picos de acesso fora do expediente, deteção sequencial combinando múltiplos sinais de risco), integre fontes de dados (logs de atividade do Azure, logs de auditoria do Microsoft 365, Defender for Cloud Apps, sistemas de RH, eventos DLP de ponto de extremidade) e configure a triagem de alertas com fluxo de trabalho, direcionando alertas de gravidade média/alta para uma fila de investigação dedicada.

Resultado: O Defender for Storage detetou atividade anômala de download em massa de uma entidade de serviço comprometida em 48 horas. A resposta automatizada isolou a identidade e notificou o SOC em minutos, reduzindo o tempo de deteção de dias para menos de 15 minutos. O Insider Risk Management sinalizou um funcionário que se está a despedir por descarregar dados de pesquisa significativamente acima da sua linha de base pessoal para armazenamento pessoal na nuvem, permitindo uma intervenção rápida.

Nível de criticidade

Deve ter.

Mapeamento de controle

• Controles CIS v8.1: 3.13
• NIST SP 800-53 Rev.5: AC-4, SI-4
• PCI-DSS v4: 3.2.1, 10.4.1
• NIST CSF v2.0: DE. CM-1, PR. DS-5
• ISO 27001:2022: A.8.11, A.8.16
• SOC 2: CC6.1, CC7.2

DP-3: Criptografar dados confidenciais em trânsito

Azure Policy: Veja definições de políticas incorporadas no Azure: DP-3.

Princípio da segurança

Proteja os dados em trânsito usando criptografia forte (como TLS 1.2 ou posterior) para evitar intercetação, adulteração e acesso não autorizado. Defina limites de rede e escopos de serviço onde a criptografia é obrigatória, priorizando o tráfego de rede externa e pública enquanto considera a proteção de rede interna com base na sensibilidade dos dados.

Risco a mitigar

Canais de rede não criptografados ou fracamente protegidos expõem dados confidenciais a intercetação, manipulação e abuso de downgrade. Ausência de criptografia moderna obrigatória de transporte (TLS 1.2+):

• Interceção passiva: Os observadores de rede capturam credenciais, tokens, cargas úteis de API ou dados regulamentados em texto sem formatação.
• Homem-no-meio: Os atacantes alteram consultas, injetam cargas úteis ou capturam material de sessão.
• Rebaixamento do protocolo: O fallback herdado (SSL/TLS < 1.2, HTTP/FTP de texto simples) permite a exploração de pacotes de codificação obsoletos.
• Sequestro de sessão: A falta de integridade do canal permite a reprodução de tokens ou roubo de cookies para movimentação lateral.
• Manipulação da integridade: A adulteração corrompe análises ou desencadeia transações fraudulentas.
• Vias laterais opacas: O tráfego interno de texto simples torna-se material de reconhecimento após o ponto de apoio.

A falha em impor criptografia forte em trânsito amplifica o alcance do impacto de uma violação, acelera o comprometimento de credenciais e prejudica os pressupostos do modelo de confiança zero.

MITRE ATT&CK

• Acesso a credenciais (TA0006): credenciais desprotegidas (T1552) intercetadas durante sessões TLS de texto simples ou rebaixadas expondo tokens/material de sessão.
• Coleção (TA0009): deteção de rede (T1040) coletando cargas úteis e segredos da API atravessando caminhos de cifra fraca ou texto não criptografado.
• Exfiltração (TA0010): exfiltração através de serviços web (T1567) transmissão de dados estruturados por intermédio de endpoints de API legítimos.
• Evasão de Defesa (TA0005): adversário no meio (T1557) forçando o downgrade do TLS ou inserindo proxies de intercetação para visualizar/modificar o tráfego.
• Command & Control (TA0011): protocolo fora da camada de aplicação (T1095) revertendo para transportes legados ou menos inspecionados para contornar a monitorização.

DP-3.1: Impor criptografia TLS para serviços e aplicativos de dados

Estabeleça padrões modernos de segurança na camada de transporte para todos os serviços e plataformas de dados voltados para o cliente, a fim de proteger contra interceção, adulteração e ataques de intermediário. Imponha o uso de TLS 1.2 ou 1.3 como mínimo em armazenamento, aplicações web, bases de dados e gateways de API, desativando simultaneamente protocolos obsoletos e pacotes de cifras fracos que expõem dados a ataques de downgrade criptográfico.

Aplique o TLS para serviços e aplicativos de dados:

• Imponha a transferência segura (somente HTTPS) para contas de Armazenamento do Azure para garantir que todas as conexões de cliente usem TLS 1.2 ou posterior para operações de blob, arquivo, fila e tabela.
• Para aplicativos Web hospedados no Serviço de Aplicativo do Azure, habilite a configuração "Somente HTTPS" e configure a versão mínima do TLS para 1.2 ou 1.3 para evitar ataques de downgrade e garantir padrões criptográficos modernos.
• Configure o Gateway de Aplicativo do Azure para impor a versão mínima do TLS 1.2/1.3 para ouvintes front-end e criptografia de conexão back-end (TLS de ponta a ponta).
• Para o Banco de Dados SQL do Azure e outros serviços de dados PaaS, verifique se "Exigir conexões seguras" ou configurações equivalentes impõem conexões criptografadas; Rejeitar conexões de texto sem formatação.
• Para Gerenciamento de API, Azure Front Door e outros serviços de gateway, configure políticas de versão mínima do TLS para impor o TLS 1.2 ou superior e desabilitar pacotes de codificação fracos.

Observação: O Azure criptografa automaticamente todo o tráfego entre datacenters do Azure usando MACsec (camada 2) e TLS (camada 7). A maioria dos serviços PaaS do Azure habilita o TLS 1.2+ por padrão, mas verifica as configurações mínimas de versão do TLS para serviços com políticas configuráveis pelo cliente (Armazenamento, Serviço de Aplicativo, Gateway de Aplicativo, Gerenciamento de API, Front Door).

DP-3.2: Acesso remoto seguro e protocolos de transferência de arquivos

Elimine o acesso administrativo de texto simples e os protocolos de transferência de arquivos herdados que expõem credenciais e dados confidenciais durante as atividades operacionais. Substitua protocolos inseguros (FTP, RDP/SSH não criptografado) por alternativas modernas e criptografadas e roteie o acesso privilegiado por meio de bastiões centralizados para eliminar a exposição direta à Internet das interfaces de gerenciamento.

Protocolos de gerenciamento remoto seguro:

• Para o gerenciamento remoto de máquinas virtuais do Azure, use protocolos seguros exclusivamente:
  • VMs Linux: Use SSH (porta 22) com autenticação baseada em chave; Desative a autenticação de senha.
  • VMs do Windows: Usar RDP sobre TLS (porta 3389) com a Autenticação de Nível de Rede (NLA) ativada.
  • Acesso privilegiado: Encaminhe conexões administrativas por meio do Azure Bastion para eliminar a exposição de IP público e fornecer acesso de cliente nativo ou baseado em navegador por TLS.

Protocolos seguros de transferência de ficheiros:

• Para operações de transferência de arquivos, use protocolos seguros e desative alternativas herdadas:
  • Use o suporte a SFTP no Armazenamento de Blob do Azure (requer namespace hierárquico).
  • Use FTPS no Serviço de Aplicativo do Azure e no Azure Functions.
  • Desative o protocolo FTP herdado (texto sem formatação).
• Use a Política do Azure para impor políticas de transferência seguras em seu ambiente e monitorar a conformidade para os requisitos de versão do TLS.

Exemplo de implementação

Uma plataforma de comércio eletrônico impôs a versão mínima TLS 1.3 em todos os serviços voltados para o cliente para atender aos requisitos PCI-DSS 4.0.

Desafio: Os protocolos TLS 1.0/1.1 herdados e os pacotes de codificação fracos expuseram os dados de pagamento dos clientes a ataques de intercetação. A aplicação inconsistente de TLS entre as camadas de aplicativos criou lacunas de segurança nas quais os invasores podiam fazer downgrade de conexões. Sem a imposição centralizada de políticas TLS, o desvio de configuração manual permitiu que protocolos inseguros persistissem na produção.

Abordagem da solução:

• Configure o Serviço de Aplicativo do Azure para TLS 1.3: Defina a versão mínima do TLS como 1.3 para aplicativos Web e APIs voltados para o cliente, habilite o modo somente HTTPS para redirecionar automaticamente todo o tráfego HTTP para HTTPS, verifique se os certificados gerenciados ou certificados personalizados usam pacotes de codificação fortes.
• Configure o Gateway de Aplicativo do Azure para TLS de ponta a ponta: Configurar ouvinte HTTPS frontend com política SSL AppGwSslPolicy20220101 (TLS 1.3 mínimo com política CustomV2), carregar certificado TLS ou integrar com Key Vault para gerenciamento de certificados, configurar configurações de back-end para conexões HTTPS (definir protocolo de back-end para HTTPS na porta 443, habilitar "Usar certificado de CA bem conhecido" se os Serviços de Aplicativo de back-end usarem certificados gerenciados pelo Azure, definir versão mínima de TLS como 1.2 para conexões de back-end), criar regras de roteamento vinculando ouvintes HTTPS a pools de back-end com configurações habilitadas para TLS.
• Imponha a transferência segura para o Armazenamento do Azure: Habilite a configuração "Transferência segura necessária" para impor somente HTTPS para operações de blob, arquivo, fila e tabela, defina a versão mínima do TLS como 1.2 para todas as conexões de armazenamento, verifique se todos os tokens SAS e chaves compartilhadas só funcionam em conexões HTTPS.
• Configure o Azure Bastion para acesso remoto seguro: Implante o Azure Bastion na VNet do hub para fornecer acesso RDP/SSH baseado em navegador por TLS 1.2, remova IPs públicos de VMs e roteie todo o acesso administrativo exclusivamente por meio do Bastion.

Resultado: As contas de Armazenamento do Azure rejeitam conexões HTTP no limite de serviço, o Gateway de Aplicativo impõe o TLS 1.3 para conexões de front-end com criptografia de back-end TLS 1.2 e o Azure Bastion elimina a exposição IP pública para gerenciamento de VM.

Nível de criticidade

Deve ter.

Mapeamento de controle

• Controles CIS v8.1: 3.10
• NIST SP 800-53 Rev.5: SC-8
• PCI-DSS v4: 4.2.1, 4.2.2
• NIST CSF v2.0: PR. DS-2
• ISO 27001:2022: A.8.24
• SOC 2: CC6.1, CC6.7

DP-4: Habilitar a criptografia de dados em repouso por padrão

Azure Policy: Ver definições de políticas incorporadas do Azure: DP-4.

Princípio da segurança

Habilite a criptografia em repouso por padrão para proteger os dados contra acesso não autorizado por meio de armazenamento subjacente, roubo de mídia física, exposição de snapshot ou acesso comprometido à infraestrutura. A criptografia complementa os controles de acesso, garantindo que os dados permaneçam protegidos mesmo quando a segurança no nível de armazenamento é ignorada.

Risco a mitigar

As camadas de armazenamento não criptografadas ou seletivamente criptografadas permitem que invasores com acesso fora de banda (comprometimento de infraestrutura, mídia roubada, abuso de snapshot) coletem dados confidenciais em escala. Sem encriptação predefinida:

• Coleta de dados de mídia bruta: Discos roubados, backups ou instantâneos não gerenciados expõem conjuntos de dados completos de texto sem formatação.
• Erosão da fronteira de privilégios: Os administradores de plataforma ou agentes de host comprometidos podem ler dados de locatários sem segregação criptográfica.
• Cópia silenciosa e exfiltração: Réplicas não criptografadas (teste, análise, exportação) tornam-se canais de exfiltração de baixo atrito.
• Violação da integridade: Os invasores modificam dados inativos (DLLs maliciosas, dados de configuração ou dados de referência) para provocar o comprometimento em etapas posteriores.
• Não conformidade regulamentar: A falta de criptografia sistêmica prejudica as garantias exigidas para muitas certificações do setor.
• Exposição de recuperação sem chave: Imagens de recuperação de desastres e arquivos frios retêm indefinidamente conteúdo confidencial em texto simples recuperável.

A não imposição da criptografia universal de dados em repouso aumenta a dimensão das falhas de segurança, complica o escopo forense e amplia o risco operacional e legal subsequente.

MITRE ATT&CK

• Coleção (TA0009): dados do armazenamento em nuvem (T1530) extraindo instantâneos não criptografados, réplicas ou discos desanexados.
• Defense Evasion (TA0005): remoção de indicadores (T1070), edição ou limpeza de logs após acesso a mídia offline / acesso a instantâneos.
• Impacto (TA0040): destruição de dados (T1485) corrompendo ativos inativos não criptografados para interromper processos a jusante.
• Impacto (TA0040): inibe a recuperação do sistema (T1490) excluindo ou alterando backups não criptografados e catálogos de recuperação.
• Impacto (TA0040): manipulação de dados (T1565) modificando sutilmente dados de referência ou configuração armazenados para causar falhas lógicas de estágio posterior.

DP-4.1: Habilitar criptografia de dados em repouso por padrão

Certifique-se de que todos os dados armazenados no Azure estão encriptados em repouso para proteger contra o acesso não autorizado contra o comprometimento da infraestrutura, multimédia roubada ou instantâneos não autorizados. Embora a maioria dos serviços do Azure habilite a criptografia por padrão, verifique a cobertura em máquinas virtuais, contas de armazenamento e bancos de dados e habilite camadas de criptografia adicionais (criptografia no host, criptografia de infraestrutura, computação confidencial e criptografia em nível de coluna) para cargas de trabalho altamente confidenciais para atender aos requisitos regulatórios e de soberania de dados.

Habilite a criptografia para VMs e armazenamento:

• Habilite a criptografia no host para Máquinas Virtuais do Azure para criptografar discos temporários, cache de disco do sistema operacional, cache de disco de dados e discos efêmeros do sistema operacional antes que os dados cheguem ao Armazenamento do Azure. Registre o recurso EncryptionAtHost no nível de assinatura e implante VMs usando tamanhos de VM suportados (por exemplo, série DSv3, Easv4, Dadsv5).
• Habilite a criptografia de infraestrutura (criptografia dupla) para contas de Armazenamento do Azure que exigem camadas de criptografia adicionais. Isso fornece duas camadas de criptografia AES-256 com chaves diferentes nos níveis de serviço e infraestrutura — configure durante a criação da conta de armazenamento, pois não pode ser habilitada após a criação.

Implante computação confidencial e criptografia em nível de coluna:

• Implante VMs Confidenciais do Azure com criptografia de disco confidencial para cargas de trabalho altamente regulamentadas que processam dados confidenciais ou controlados por exportação. Use as séries DCasv5/DCadsv5 (AMD SEV-SNP) ou ECasv5/ECadsv5 (Intel TDX) com chaves de criptografia de disco associadas ao vTPM para assegurar que os dados permaneçam criptografados durante o processamento.
• Para o Banco de Dados SQL do Azure, implemente o Always Encrypted para fornecer criptografia no nível de coluna do lado do cliente para dados altamente confidenciais (SSN, números de cartão de crédito, registros médicos) em que os dados permanecem criptografados mesmo de administradores de banco de dados, operadores de nuvem e usuários altamente privilegiados, mas não autorizados. Use Always Encrypted with secure enclaves (Intel SGX) para permitir consultas mais avançadas em colunas criptografadas.

Monitore e imponha a conformidade com a criptografia:

• Imponha a conformidade de criptografia usando a Política do Azure atribuindo políticas internas como "As máquinas virtuais devem habilitar a criptografia no host", "As contas de armazenamento devem ter criptografia de infraestrutura" e "A criptografia de dados transparente em bancos de dados SQL deve ser habilitada" no escopo da assinatura ou do grupo de gerenciamento.
• Use o Azure Resource Graph para consultar e inventariar configurações de criptografia em seu ambiente, identificando VMs sem criptografia no host, contas de armazenamento sem criptografia de infraestrutura ou bancos de dados sem TDE habilitada.

Observação: Muitos serviços do Azure (Armazenamento do Azure, Banco de Dados SQL do Azure, Azure Cosmos DB) têm a criptografia de dados em repouso habilitada por padrão na camada de infraestrutura usando chaves gerenciadas por serviço que giram automaticamente a cada dois anos. Quando a criptografia não estiver habilitada por padrão, habilite-a no nível de armazenamento, arquivo ou banco de dados com base na viabilidade técnica e nos requisitos de carga de trabalho.

Exemplo de implementação

Uma empresa multinacional de manufatura padronizou a criptografia em repouso em seu ambiente do Azure para proteger dados de ERP, aplicativos da cadeia de suprimentos e segredos comerciais de engenharia.

Desafio: A cobertura de criptografia inconsistente deixou os dados confidenciais vulneráveis ao comprometimento da infraestrutura e ao roubo de snapshots. Os dados do disco temporário e o armazenamento efêmero permaneceram não criptografados, criando lacunas de conformidade. Sem a aplicação sistemática de criptografia, segredos comerciais de engenharia e dados da cadeia de suprimentos podem ser expostos por meio de discos roubados, snapshots não autorizados ou agentes de host comprometidos.

Abordagem da solução:

• Habilite a criptografia no host para Máquinas Virtuais do Azure: Registre o recurso EncryptionAtHost no nível de assinatura, habilite a criptografia no host para VMs usando tamanhos de VM suportados (série DSv3, Easv4, Dadsv5), a criptografia cobre discos temporários, cache de disco do sistema operacional, cache de disco de dados e discos efêmeros do sistema operacional.
• Habilite a criptografia de infraestrutura (criptografia dupla) para o Armazenamento do Azure: Verifique se a Criptografia do Serviço de Armazenamento do Azure (SSE) está habilitada (ativada por padrão — criptografia AES-256), para contas de armazenamento confidenciais, habilite a criptografia de infraestrutura durante a criação da conta de armazenamento (não pode ser habilitada após a criação), resultado: duas camadas de criptografia AES-256 com chaves diferentes.
• Implante VMs Confidenciais do Azure para cargas de trabalho altamente regulamentadas: Selecione a série de VM confidencial apropriada (série DCasv5/DCadsv5 para AMD SEV-SNP ou série ECasv5/ECadsv5 para Intel TDX), habilite a criptografia de disco confidencial com chave gerenciada pela plataforma (vincula chaves de criptografia de disco ao TPM virtual da VM), habilite a Inicialização Segura e o vTPM para atestado, implante para cargas de trabalho que processam dados técnicos controlados por exportação ou PII altamente regulamentada onde os dados devem permanecer criptografados durante o processamento.
• Implemente Sempre Encriptado para colunas confidenciais da base de dados: Identifique colunas altamente confidenciais na Base de Dados SQL do Azure que requeiram criptografia ao nível de coluna (SSN, Número de Cartão de Crédito, Número de Registro Médico), gere chaves de criptografia de coluna (CEK) e chaves mestras de coluna (CMK), armazenando o CMK no Cofre de Chaves do Azure, onde o CEK encripta colunas de dados e o CMK encripta o CEK. Habilite Sempre Encriptado com enclaves seguros (Intel SGX) para permitir consultas mais avançadas em dados encriptados; encripte colunas sensíveis usando a criptografia determinística (para buscas de igualdade) ou a criptografia aleatória (para maior nível de segurança). Configure cadeias de conexão de aplicativos com o Column Encryption Setting=Enabled para encriptação/desencriptação transparente.
• Configurações de criptografia de inventário com o Azure Resource Graph: Consulte o status da criptografia para VMs sem criptografia no host e contas de armazenamento sem criptografia de infraestrutura, exporte resultados para CSV e atribua tarefas de correção aos proprietários de recursos.

Resultado: A criptografia no host resolveu lacunas de conformidade em que os dados do disco temporário não eram criptografados anteriormente. A criptografia de infraestrutura protegeu arquivos de engenharia com duas camadas de criptografia. As VMs confidenciais garantiram que os dados sujeitos a controle de exportação permanecessem criptografados mesmo para os administradores de nuvem. As colunas confidenciais do banco de dados são sempre protegidas por criptografia — os administradores de banco de dados confirmaram a incapacidade de ler texto em claro de colunas criptografadas, cumprindo os requisitos de conformidade.

Nível de criticidade

Deve ter.

Mapeamento de controle

• Controles CIS v8.1: 3.11
• NIST SP 800-53 Rev.5: SC-28
• PCI-DSS v4: 3.5.1, 3.6.1
• NIST CSF v2.0: PR. DS-1
• ISO 27001:2022: A.8.24
• SOC 2: CC6.1

DP-5: Use a opção de chave gerenciada pelo cliente na criptografia de dados em repouso quando necessário

Azure Policy: Veja definições de políticas incorporadas no Azure: DP-5.

Princípio da segurança

Use chaves gerenciadas pelo cliente quando a conformidade normativa, os requisitos contratuais ou a sensibilidade dos dados exigirem controle direto sobre o ciclo de vida da chave de criptografia, incluindo a geração, rotação e autoridade de revogação de chaves. Garantir que os processos de gerenciamento de chaves adequados estejam em vigor para lidar com a sobrecarga operacional.

Risco a mitigar

Confiar apenas em chaves gerenciadas por serviços onde as garantias regulatórias, contratuais ou de segregação exigem controle do locatário introduz riscos de conformidade e concentração. Sem chaves geridas pelo cliente (CMK) devidamente governadas:

• Garantia regulamentar inadequada: Os auditores podem rejeitar evidências de controle criptográfico se a custódia de chaves, cadência de rotação ou autoridade de revogação não puderem ser demonstradas.
• Latência de revogação: A incapacidade de revogar ou substituir rapidamente chaves de plataforma comprometidas estende a janela de exposição após eventos de credencial ou cadeia de abastecimento.
• Exposição jurisdicional: Os mandatos de soberania de dados podem exigir chaves operadas por locatários ou apoiadas por HSM — a ausência prejudica a viabilidade da implantação regional.
• Alcance de impacto entre locatários: A violação de chaves na plataforma multilocatária pode afetar amplos conjuntos de dados quando o isolamento criptográfico é insuficiente.
• Proliferação de sombras: Implantações ad-hoc de CMK sem governança do ciclo de vida levam a chaves obsoletas, órfãs ou fracas.
• Fragilidade operacional: A automação deficiente de rotação ou o mapeamento de dependências ausente causam interrupções de aplicações durante a troca de chaves.

O uso inadequado ou omitido da CMK enfraquece a garantia criptográfica e prejudica o posicionamento estratégico de conformidade para cargas de trabalho sensíveis.

MITRE ATT&CK

• Acesso a credenciais (TA0006): credenciais desprotegidas (T1552) expostas por chaves de plataforma fracamente protegidas ou incorretamente segmentadas.
• Impacto (TA0040): dados encriptados para impacto (T1486) abusando da rotação/revogação do CMK para tornar inacessíveis os dados.
• Impacto (TA0040): manipulação de dados (T1565) modificando metadados de estado de criptografia para dessincronizar camadas de proteção.
• Exfiltração (TA0010): transferir dados para a conta na nuvem (T1537) criptografando novamente e exportando conjuntos de dados para armazenamento controlado por invasores.
• Exfiltração (TA0010): exfiltração sobre serviços Web (T1567) orquestrando exportações em massa de alto volume habilitadas por chave sob padrões normais de serviço.

DP-5.1: Use a opção de chave gerenciada pelo cliente na criptografia de dados em repouso quando necessário

Implemente chaves gerenciadas pelo cliente quando a conformidade regulamentar, mandatos de soberania de dados ou obrigações contratuais exigirem controle direto sobre a custódia de chaves de criptografia, agendas de rotação e autoridade de revogação. Para cargas de trabalho que exigem controle final em que nem mesmo a Microsoft pode descriptografar dados, implemente a Criptografia de Chave Dupla (DKE) onde sua organização mantém uma segunda chave de criptografia fora do Azure. Use o Azure Key Vault ou o Managed HSM para manter o controle criptográfico enquanto equilibra a complexidade operacional do gerenciamento do ciclo de vida das chaves, o planejamento da recuperação de desastres e os possíveis impactos da disponibilidade do serviço decorrentes de erros de gerenciamento de chaves.

Avalie os requisitos de CMK e provisione a infraestrutura principal:

• Avalie os requisitos regulamentares, de conformidade ou de negócios para determinar quais cargas de trabalho precisam de chaves gerenciadas pelo cliente (CMK) em vez de chaves gerenciadas pela plataforma. Os fatores comuns incluem soberania de dados, requisitos de auditoria ou obrigações contratuais para custódia direta de chaves.
• Provisione o Azure Key Vault (Standard ou Premium) ou o Azure Key Vault Managed HSM para armazenar e gerenciar chaves de criptografia gerenciadas pelo cliente. Use o HSM gerenciado para cargas de trabalho que exigem proteção de hardware validada FIPS 140-3 Nível 3.
• Gere chaves de criptografia no Cofre de Chaves do Azure usando recursos de geração de chaves ou importe chaves de HSMs locais usando Bring Your Own Key (BYOK) para máxima portabilidade e controle.

Configure a CMK e estabeleça a hierarquia de chaves:

• Para requisitos de controlo extremos, implemente a Encriptação de Chave Dupla (DKE) onde os documentos confidenciais requerem duas chaves para desencriptação: uma gerida pela Microsoft (Azure RMS) e uma segunda chave gerida exclusivamente pela sua organização no local ou no seu próprio serviço de gestão de chaves externas. Com o DKE, a Microsoft não pode desencriptar os seus dados, mesmo que seja obrigada por um processo legal, uma vez que controla a segunda chave necessária para a desencriptação.
• Configure os serviços do Azure (Armazenamento do Azure, Banco de Dados SQL do Azure, Azure Cosmos DB, Criptografia de Disco do Azure, etc.) para usar a CMK fazendo referência ao URI da chave do Cofre da Chave. Habilite políticas de rotação automática de chaves para reduzir a carga operacional manual.
• Estabeleça uma hierarquia de chave de criptografia de chave (KEK) e chave de criptografia de dados (DEK) onde o KEK (armazenado no Cofre de Chaves) criptografa o DEK (usado pelos serviços), minimizando o impacto da rotação de chaves na disponibilidade do serviço.
• Documente procedimentos de ciclo de vida de chaves, incluindo agendas de rotação de chaves, processos de revogação de chaves comprometidas, fluxos de trabalho de desativação de chaves e procedimentos de recuperação de desastres. Integre a gestão de chaves nos seus processos de gestão da mudança organizacional.

Observação: As chaves gerenciadas pelo cliente exigem investimento operacional contínuo, incluindo gerenciamento do ciclo de vida das chaves, administração do controle de acesso, monitoramento e planejamento de recuperação de desastres. Garanta a prontidão operacional antes de adotar a CMK, pois o gerenciamento inadequado de chaves pode resultar em indisponibilidade ou perda de dados.

Exemplo de implementação

Uma instituição financeira regulamentada implantou chaves gerenciadas pelo cliente (CMK) nos serviços do Azure para satisfazer os requisitos regulatórios de controle criptográfico direto sobre dados de negociação e registros financeiros de clientes.

Desafio: Os auditores regulatórios exigiram controle criptográfico demonstrado, incluindo custódia de chaves, autoridade de rotação e capacidade de revogação. As chaves gerenciadas pelo serviço não podiam fornecer evidências do ciclo de vida da chave controlada pelo locatário. Sem chaves gerenciadas pelo cliente, a organização não tinha capacidade de revogar rapidamente o acesso durante incidentes de segurança e não conseguia atender aos requisitos de soberania de dados para implantações regionais.

Abordagem da solução:

• Provisionar o HSM gerenciado do Azure Key Vault: Crie HSM Gerenciado (FIPS 140-3 Nível 3 validado) com um mínimo de 3 partições HSM para alta disponibilidade, ative o HSM Gerenciado exportando domínio de segurança com chaves de quórum (dividido em fragmentos de chave armazenados em cofres offline geograficamente distribuídos), gere chaves de criptografia (RSA-4096 chamado KEK-Prod-2024) com operações de chave: Wrap Key, Unwrap Key, Encrypt, Decrypt.
• Configure chaves geridas pelo cliente para serviços do Azure: Para configurar a conta de armazenamento do Azure Storage para usar o tipo de encriptação CMK, selecione Key Vault Managed HSM como fonte de chave, ative a identidade gerida atribuída pelo utilizador com a função de Utilizador do Serviço de Criptografia HSM Gerido; para a Base de Dados SQL do Azure, configure a Base de Dados SQL para usar a chave gerida pelo cliente como protetor TDE, selecione a chave do HSM gerido, ative a rotação automática; para o Azure Cosmos DB, ative chaves geridas pelo cliente para a conta do Cosmos DB, selecione chave do HSM gerido, conceda acesso à identidade gerida do Cosmos DB.
• Implemente a rotação automatizada de chaves: Configure a política de rotação com frequência de rotação de 90 dias, habilite a rotação automática, configure a notificação de expiração (alerta 7 dias antes da expiração), crie o alerta do Azure Monitor para a métrica de Chave Perto da Expiração para notificar a equipe de segurança.
• Habilite o log de auditoria para fins de conformidade: Habilite o log de diagnóstico para HSM gerenciado (logs AuditEvent), envie logs para o espaço de trabalho do Log Analytics com armazenamento imutável (retenção de 90 dias para trilhas de auditoria à prova de violação), consulte logs de acesso à chave para monitorar as operações Encrypt, Decrypt, WrapKey e UnwrapKey.
• Documente os principais procedimentos do ciclo de vida: Crie runbooks de revogação de emergência (etapas de revogação de chaves, contatos de resposta a incidentes, procedimentos de recuperação usando chaves de quorum de domínio de segurança), teste runbooks trimestralmente por meio de exercícios de mesa, integre operações CMK no fluxo de trabalho de aprovação de alterações do Gerenciamento de Serviços de TI.

Resultado: Os KEKs RSA-4096 no HSM gerenciado criptografam DEKs de nível de serviço para o Armazenamento do Azure, Banco de Dados SQL e Cosmos DB. A rotação automatizada trimestral minimiza a interrupção ao recriptografar apenas os DEKs. O quórum do domínio de segurança garante a recuperação de desastres mesmo com falhas regionais completas.

Nível de criticidade

Deveria ter.

Mapeamento de controle

• Controles CIS v8.1: 3.11
• NIST SP 800-53 Rev.5: SC-12, SC-28
• PCI-DSS v4: 3.5.1, 3.6.1, 12.3.2
• NIST CSF v2.0: PR. DS-1, ID.AM-3
• ISO 27001:2022: A.8.24
• SOC 2: CC6.1

DP-6: Use um processo seguro de gerenciamento de chaves

Azure Policy: Veja definições de políticas incorporadas no Azure: DP-6.

Princípio da segurança

Implemente processos seguros de gerenciamento de chaves que governem todo o ciclo de vida da chave: geração, distribuição, armazenamento, rotação e revogação. Use serviços dedicados de cofre de chaves com controles de acesso fortes, mantenha padrões criptográficos, imponha a separação de tarefas e garanta que as chaves sejam giradas regularmente e revogadas prontamente quando comprometidas.

Risco a mitigar

Ciclos de vida de chaves criptográficas fracas ou não gerenciadas degradam a garantia fornecida pela criptografia e podem permitir o comprometimento sistêmico. Sem geração, rotação, proteção e revogação de chaves estruturadas:

• Expansão e orfandade de chaves: As chaves não rastreadas persistem para além das necessidades empresariais, retendo uma autoridade de desencriptação indesejada.
• Criptografia obsoleta: A rotação pouco frequente aumenta a exposição a regressão algorítmica, ataques de força bruta ou avanços em ataques de canal lateral.
• Excesso de privilégios: A falta de separação de funções permite que os administradores gerenciem e usem chaves, permitindo o uso indevido de pessoas internas.
• Comprometimento não detetado: Nenhum monitoramento de integridade ou linhagem de versão obscurece se as chaves foram substituídas maliciosamente.
• Falha na revogação: A resposta a incidentes não pode conter criptograficamente o acesso aos dados após suspeita de violação.
• Hierarquia inconsistente: A ausência de camadas KEK/DEK multiplica o raio de impacto da rotação e aumenta a duração da paragem operacional.

O gerenciamento deficiente de chaves transforma a criptografia em um controle point-in-time em vez de uma mitigação sustentada contra ameaças em evolução.

MITRE ATT&CK

• Acesso a credenciais (TA0006): credenciais de repositórios de palavras-passe (T1555) extraindo material de chave mal armazenado ou em cache, ou contas válidas (T1078) explorando funções RBAC de gestão de chaves extensas para aceder ou rodar chaves ilegitimamente.
• Defense Evasion (TA0005): enfraquecer a encriptação (T1600) retendo algoritmos obsoletos / tamanhos de chave insuficientes para reduzir a força criptográfica.
• Impacto (TA0040): destruição de dados (T1485) executando purga destrutiva ou eventos de revogação mal tratados.
• Impacto (TA0040): manipulação de dados (T1565) substituindo ou alterando versões de chave para redirecionar ou desabilitar fluxos de criptografia.

DP-6.1: Estabelecer as principais políticas de gestão e infraestrutura

Crie uma base de governança para o gerenciamento de chaves criptográficas estabelecendo armazenamento centralizado de chaves, definindo padrões criptográficos e selecionando níveis de proteção apropriados com base na sensibilidade da carga de trabalho. Implante o Azure Key Vault como a única fonte de verdade para operações importantes enquanto implementa um log de auditoria abrangente para rastrear todos os acessos de chaves e alterações administrativas para fins forenses e de conformidade.

Estabeleça uma infraestrutura centralizada de gerenciamento de chaves:

• Use o Azure Key Vault como o serviço centralizado de gerenciamento de chaves criptográficas para controlar o ciclo de vida completo da chave: geração, distribuição, armazenamento, rotação e revogação.
• Defina e aplique políticas chave especificando padrões criptográficos mínimos:
  • Tipo de chave: RSA (recomendado: mínimo de 4096 bits ou 3072 bits) ou EC (curvas P-256, P-384, P-521).
  • Principais operações: Limite as operações permitidas (encriptar, desencriptar, assinar, verificar, encapsular, desembrulhar) com base em princípios de privilégios mínimos.
  • Prazo de validade: Defina datas de ativação e expiração para impor o uso de chaves com limite de tempo.

Escolha a camada apropriada do cofre de chaves:

• Escolha a camada apropriada do Azure Key Vault com base nos requisitos de segurança e conformidade da sua carga de trabalho.
  • Chaves protegidas por software (Standard & Premium SKUs): FIPS 140-2 Nível 1 validado
  • Chaves protegidas por HSM (Premium SKU): FIPS 140-2 Nível 2 validado (back-end HSM multilocatário compartilhado)
  • HSM gerido: FIPS 140-3 Nível 3 validado (pool HSM dedicado a um único inquilino)
• Para maior segurança, use o Azure Key Vault Managed HSM para proteção HSM validada por FIPS 140-3 Nível 3 de inquilino único. O HSM gerenciado suporta domínio criptográfico para backup e recuperação de desastres.
• Configure o registo do Cofre de Chaves do Azure e os registos de rotas para o Azure Monitor ou o Microsoft Sentinel para controlar todos os acessos às chaves, eventos de rotação e operações administrativas para fins de auditoria e conformidade.

DP-6.2: Implementar a automação do ciclo de vida das chaves

Automatize a rotação de chaves e estabeleça hierarquias de chaves para reduzir a carga operacional, minimizar erros humanos e permitir a substituição rápida de chaves sem interrupção do serviço. Implemente padrões KEK/DEK que permitam uma rotação eficiente criptografando novamente pequenos pacotes de chaves em vez de conjuntos de dados inteiros e integre procedimentos de recuperação de desastres para manter a disponibilidade de chaves em falhas regionais ou eventos catastróficos.

Implemente a rotação automatizada de chaves:

• Implemente políticas automatizadas de rotação de chaves no Cofre de Chaves do Azure:
  • Configure a frequência de rotação com base nos requisitos de conformidade (intervalos comuns: 90 dias, 180 dias ou anualmente).
  • Habilite as notificações de rotação para alertar as equipes operacionais antes da expiração da chave.
  • Configure a rotação automática para gerar novas versões de chave sem intervenção manual.

Estabeleça hierarquia de chaves e BYOK:

• Estabeleça uma hierarquia de chaves separando chaves de criptografia de chave (KEK) e chaves de criptografia de dados (DEK):
  • Armazene KEKs no Cofre de Chaves do Azure com controles de acesso restrito.
  • Gere DEKs de nível de serviço, criptografadas por KEKs, minimizando o raio de explosão da rotação da chave.
  • Girar o KEK requer apenas a re-encriptação dos DEKs (não dos conjuntos de dados inteiros), facilitando uma rotação de chaves eficiente, sem tempo de inatividade.
• Para cenários BYOK (Bring Your Own Key), gere chaves em HSMs FIPS 140-2 Nível 2+ locais e use o mecanismo de chave de transferência BYOK para importar chaves com segurança para o Cofre de Chaves do Azure ou HSM gerenciado, mantendo a prova criptográfica de origem e custódia da chave.

Implemente procedimentos de recuperação de desastres:

• Crie Cofres de Chaves replicados geograficamente em regiões secundárias.
• Faça backup e restaure chaves para manter a disponibilidade das chaves entre as regiões.
• Documente e teste procedimentos de recuperação de desastres com alvos RTO/RPO definidos.

DP-6.3: Impor a separação de tarefas para o acesso à chave

Previna ameaças internas e abuso de privilégios separando funções de gerenciamento de chaves de funções de operação criptográfica, garantindo que nenhuma identidade única possa criar chaves e usá-las para criptografia ou descriptografia de dados. Implemente monitoramento contínuo para detetar padrões anômalos de acesso de chaves e manter inventários de chaves abrangentes que permitam uma rápida avaliação de impacto durante incidentes de segurança ou auditorias de conformidade.

Impor a separação de funções:

• Implemente o controle de acesso baseado em função (RBAC) ou políticas de acesso para impor a separação de tarefas:
  • Separe funções para administradores de chaves (que podem criar/girar/excluir chaves, mas não podem executar operações criptográficas).
  • Separe funções para usuários-chave (que podem executar operações de criptografia/descriptografia, mas não podem gerenciar chaves).
  • Exemplos de funções: Key Vault Crypto Officer (administradores), Key Vault Crypto User (aplicações/utilizadores).
• Verifique se nenhuma identidade única tem acesso à chave administrativa e operacional para evitar abuso de privilégios.

Monitore o acesso às chaves e mantenha o inventário:

• Integre o monitoramento de acesso de chave com o Microsoft Sentinel para detetar anomalias:
  • Padrões de acesso de chave incomuns (acesso a partir de endereços IP ou regiões desconhecidas).
  • Operações chave em massa (operações excessivas em curtos períodos de tempo).
  • Alterações administrativas fora do horário comercial (exclusão ou rotação de chaves).
• Mantenha um inventário de chaves com o nome da chave, finalidade, cronograma de rotação e serviços dependentes. Revise o inventário regularmente durante as revisões de segurança.

Exemplo de implementação

Um provedor de SaaS de saúde centralizou o gerenciamento de chaves criptográficas usando o Azure Key Vault Premium SKU com chaves protegidas por HSM para criptografia PHI em sua plataforma multilocatário.

Desafio: O gerenciamento fragmentado de chaves entre as equipes de desenvolvimento levou à expansão de chaves, práticas de rotação inconsistentes e dificuldade em rastrear o uso de chaves durante incidentes de segurança. Permissões RBAC muito amplas permitiam que os administradores gerenciassem e usassem chaves, criando risco interno. Sem rotação automatizada e separação de tarefas, a organização enfrentou janelas de comprometimento de chave estendidas e falhas de conformidade de auditoria.

Abordagem da solução:

• Provisione o Azure Key Vault Premium com chaves protegidas por HSM: Crie o Azure Key Vault com a camada Premium para dar suporte a chaves protegidas por HSM, habilite a proteção contra limpeza para evitar a exclusão permanente durante o período de retenção, habilite a exclusão suave com retenção de 90 dias para permitir a recuperação de chaves excluídas acidentalmente, gere chaves de criptografia protegidas por HSM RSA-3072 (KEK-PHI-Prod) com tipo de chave lastreada em hardware.
• Implemente políticas automatizadas de rotação de chaves: Configure a política de rotação com frequência de rotação de 180 dias, habilite a rotação automática e defina a notificação para alertar 30 dias antes do vencimento, crie grupos de ação do Azure Monitor para notificar a equipe de operações de segurança quando as chaves se aproximarem da expiração, configure a ação de rotação para gerar automaticamente novas versões de chave.
• Configure a separação de tarefas do RBAC: Atribua a função Key Vault Crypto Officer aos membros da equipe de segurança (permissões: gerencie o ciclo de vida da chave, mas não pode executar operações de criptografia/descriptografia), atribua a função Key Vault Crypto User a identidades gerenciadas por aplicativos (permissões: execute operações de criptografia/descriptografia somente sem permissões de gerenciamento de chaves), verifique a separação de tarefas garantindo que nenhuma identidade tenha as funções de Crypto Officer e Crypto User.
• Estabeleça a hierarquia KEK/DEK para rotação rápida de chaves: Gere Chaves de Criptografia de Dados (DEKs) no nível do aplicativo dentro do código do aplicativo (chaves AES-256) para criptografar dados do paciente, armazene DEKs criptografadas juntamente com dados criptografados, use o Key Vault KEK para encapsular/criptografar DEKs por meio da operação WrapKey, recupere e desembrulhe DEK usando a operação UnwrapKey ao descriptografar dados do paciente, benefício: girar o KEK requer apenas a recriptografia de DEKs em vez de todo o banco de dados do paciente.
• Integre os logs do Key Vault com o Microsoft Sentinel: Habilite as configurações de diagnóstico para o Cofre de Chaves e envie logs para o espaço de trabalho do Log Analytics, crie regras de análise do Sentinel para detetar padrões incomuns de acesso a chaves, operações de chave em massa, alterações administrativas fora do horário comercial.
• Traga sua própria transferência de chave (BYOK) do HSM local: Baixe a chave de transferência BYOK do Cofre da Chave, exporte a chave do HSM local encapsulada com a chave pública de transferência BYOK do Cofre da Chave, mantenha a prova criptográfica da linhagem da chave, importe a chave encapsulada para o Cofre da Chave, onde ela chega protegida por HSM sem exposição de texto simples.

Resultado: As chaves RSA-3072 giram a cada 180 dias com notificações automatizadas. A separação RBAC impede o abuso de privilégios. A hierarquia KEK/DEK permite uma rotação rápida criptografando novamente apenas DEKs. Soft delete recupera chaves excluídas acidentalmente. O Microsoft Sentinel deteta anomalias como acesso IP desconhecido ou modificações fora do horário comercial.

Nível de criticidade

Deve ter.

Mapeamento de controle

• Controles CIS v8.1: N/A
• NIST SP 800-53 Rev.5: IA-5, SC-12, SC-28
• PCI-DSS v4: 3.6.1, 8.3.2
• NIST CSF v2.0: PR. AC-1, PR. DS-1
• ISO 27001:2022: A.8.24, A.8.3
• SOC 2: CC6.1, CC6.2

DP-7: Use um processo seguro de gerenciamento de certificados

Azure Policy: Veja definições de políticas incorporadas no Azure: DP-7.

Princípio da segurança

Gerencie os ciclos de vida dos certificados por meio de processos centralizados que incluem inventário, renovação automatizada, padrões criptográficos fortes e revogação oportuna. Certifique-se de que os certificados para serviços críticos sejam rastreados, monitorados e renovados antes da expiração para evitar interrupções de serviço e manter comunicações criptografadas seguras.

Risco a mitigar

Ciclos de vida de certificados mal controlados causam interrupções de serviço, enfraquecem canais criptografados e permitem a falsificação de identidade. Sem inventário centralizado, imposição de políticas e renovação automatizada:

• Expirações inesperadas: Certificados caducados desencadeiam interrupções de produção, quebra de APIs, federação de identidades ou caminhos de confiança do cliente.
• Persistência de criptografia fraca: Tamanhos de chave/algoritmos de assinatura herdados (por exemplo, SHA-1, RSA < 2048) permanecem em uso mesmo após serem desaconselhados.
• Abuso de certificados curinga e autoassinados: Certificados autoassinados de amplo escopo ou não configurados permitem a impersonação lateral e o risco de redução de segurança de TLS.
• Comprometimento não detetado: As chaves privadas roubadas permitem uma desencriptação transparente man-in-the-middle ou de tráfego até à rotação.
• Certificados sombra: A emissão não sancionada fora das Autoridades Certificadoras aprovadas fragmenta a governação e aumenta os pontos cegos de revogação.
• Erros de renovação manual: O sequenciamento de substituição inconsistente causa incompatibilidades na cadeia de confiança e desvio parcial do ambiente.

O gerenciamento deficiente de certificados degrada a garantia criptografada e introduz confiabilidade e instabilidade de segurança em serviços críticos.

MITRE ATT&CK

• Evasão de Defesa (TA0005): subverter controles de confiança (T1553) emitindo ou introduzindo certificados fraudulentos / desonestos para ignorar a validação.
• Desenvolvimento de Recursos (TA0042): desenvolver capacidades (T1587) forjando certificados ou ferramentas para futuras fases de intrusão.
• Evasão de defesa (TA0005): enfraquecer a criptografia (T1600) continuando o uso de algoritmos de assinatura obsoletos, reduzindo a garantia de verificação.
• Acesso a credenciais (TA0006): credenciais desprotegidas (T1552) extraindo chaves privadas de armazenamentos de arquivos inseguros ou memória de processo.
• Persistência (TA0003): modificar o processo de autenticação (T1556) reescrevendo fluxos de autenticação baseados em certificado para incorporar acesso de longa duração.

DP-7.1: Estabelecer políticas de certificado e integração de CA

Defina padrões de governança de certificados e integre autoridades de certificação confiáveis para garantir qualidade criptográfica consistente e emissão automatizada em toda a sua infraestrutura. Estabeleça políticas que imponham tamanhos de chave modernos, algoritmos de assinatura e períodos de validade e, ao mesmo tempo, elimine práticas arriscadas, como certificados autoassinados e certificados curinga que expandem as superfícies de ataque quando as chaves privadas são comprometidas.

Estabeleça a infraestrutura de gerenciamento de certificados:

• Use o Azure Key Vault para gerenciar centralmente o ciclo de vida completo do certificado: criação, importação, renovação, rotação, revogação e exclusão segura.
• Defina políticas de certificado no Cofre de Chaves do Azure para impor padrões de segurança organizacionais:
  • Tipo e tamanho da chave: Mínimo RSA de 2048 bits (recomendado: 3072 bits ou 4096 bits para certificados de longa duração); EC P-256 ou superior para certificados de curva elíptica.
  • Algoritmo de assinatura: SHA-256 ou mais forte (proibir SHA-1 e MD5).
  • Prazo de validade: Máximo de 397 dias para certificados TLS públicos (de acordo com os requisitos de linha de base do CA/Browser Forum); Recomenda-se uma duração mais curta (90 dias) para uma exposição reduzida.
  • Autoridade de certificação: Use apenas autoridades de certificação aprovadas e integradas (DigiCert, GlobalSign) ou a autoridade de certificação privada da sua organização.

Integre as autoridades de certificação:

• Use as Autoridades de Certificação parceiras integradas ao Cofre da Chave do Azure para certificados TLS/SSL públicos:
  • DigiCert: Certificados TLS/SSL validados pela organização (OV)
  • GlobalSign: Certificados TLS/SSL validados pela organização (OV)
• Para serviços privados/internos, integre a Autoridade de Certificação interna da sua organização (por exemplo, Serviços de Certificados do Ative Directory - ADCS) com o Azure Key Vault para emissão automatizada de certificados.
• Evite certificados autoassinados e certificados curinga em ambientes de produção:
  • Certificados autoassinados: Não possuem validação de terceiros, não podem ser revogados via CRL/OCSP pública e são rejeitados por navegadores/clientes modernos.
  • Certificados wildcard: O âmbito alargado aumenta o risco caso sejam comprometidos; em vez disso, use certificados de nome alternativo do assunto (SAN) com FQDNs explícitos.

Observação: Para cenários simples, você pode usar os Certificados Gerenciados do Serviço de Aplicativo do Azure (certificados gratuitos e renovados automaticamente para domínios personalizados).

DP-7.2: Implementar a renovação automatizada de certificados

Elimine interrupções de serviço causadas por certificados expirados automatizando fluxos de trabalho de renovação que são acionados bem antes da expiração e atualize perfeitamente os certificados em serviços dependentes sem intervenção manual. Configure os serviços do Azure para recuperar automaticamente certificados renovados do Cofre da Chave usando identidades gerenciadas, reduzindo o trabalho operacional e eliminando o risco de renovações manuais esquecidas durante feriados ou transições de equipe.

Configure a renovação automatizada:

• Habilite a renovação automatizada de certificados no Cofre de Chaves do Azure configurando ações de tempo de vida para acionar a renovação em uma porcentagem especificada do tempo de vida do certificado:
  • Limite de ativação recomendado: entre 80 e 90% do período de validade (por exemplo, aproximadamente 318 dias para um certificado de 397 dias).
  • Ação: Renovar automaticamente (o Key Vault solicita a renovação à autoridade certificadora sem intervenção manual).
• Configure os contatos de notificação para alertar os administradores sobre as próximas expirações de certificados antes que a renovação automática seja acionada.

Habilite a vinculação automática de certificados:

• Para serviços do Azure que dão suporte à rotação automática de certificados (Serviço de Aplicativo do Azure, Gateway de Aplicativo do Azure, Porta da Frente do Azure), configure esses serviços para recuperar automaticamente certificados atualizados do Cofre da Chave usando identidades gerenciadas ou entidades de serviço com políticas de acesso apropriadas ao Cofre da Chave:
  • Os serviços do Azure vincularão automaticamente novas versões de certificado quando renovadas (normalmente dentro de 24 horas, sem necessidade de reinicialização do serviço).
• Para aplicações que não podem consumir automaticamente certificados do Cofre de Chaves, implemente fluxos de trabalho manuais de rotação de certificados com manuais operacionais e alertas de monitorização para evitar interrupções relacionadas à expiração.
• Mantenha um inventário de todos os certificados no Azure Key Vault controlando o nome, a finalidade, a data de validade, os serviços dependentes e o status de renovação do certificado.

DP-7.3: Monitorar o ciclo de vida do certificado e lidar com a revogação

Mantenha a visibilidade contínua da integridade do certificado por meio de monitoramento automatizado, consultas de inventário e painéis que apresentam certificados prestes a expirar, usando criptografia obsoleta ou sem governança adequada. Estabeleça procedimentos de revogação rápida para certificados comprometidos e integre-se à inteligência de ameaças do setor para bloquear proativamente certificados emitidos por autoridades de certificação comprometidas antes que elas permitam ataques man-in-the-middle.

Configure o monitoramento e o alerta:

• Configure alertas do Azure Monitor para eventos de expiração de certificado:
  • Crie alertas 30 dias antes da expiração (notificação de aviso).
  • Crie alertas 7 dias antes da expiração (alerta crítico com escalonamento para a equipe de segurança).

Mantenha o inventário de certificados e painéis:

• Use o Azure Resource Graph para consultar o inventário de certificados:
  • Consultar certificados prestes a expirar (dentro de 30/60/90 dias).
  • Consultar certificados autoassinados.
  • Consultar certificados usando algoritmos preteridos (por exemplo, SHA-1).
• Crie painéis de auditoria de certificados (por exemplo, Power BI) com visualizações:
  • Cronograma de expiração do certificado por intervalo de tempo.
  • Contagem de certificados autoassinados por grupo de recursos.
  • Certificados usando padrões criptográficos obsoletos.
• Revise os painéis de auditoria de certificados regularmente durante as reuniões de revisão de segurança (recomendado: trimestralmente).

Estabelecer procedimentos de revogação:

• Estabeleça procedimentos de revogação de certificados para certificados comprometidos ou retirados.
  • Processo de revogação de documentos (desative o certificado no Cofre da Chave, notifique os serviços dependentes).
  • Mantenha manuais de procedimentos de resposta a incidentes para cenários de comprometimento de certificados.
  • Monitore as notificações do setor relativamente a certificados de CA raiz ou intermediários comprometidos e bloqueie-os prontamente.

Exemplo de implementação

Uma empresa com 200+ aplicativos Web voltados para o público gerenciamento centralizado do ciclo de vida do certificado usando o Azure Key Vault integrado com a DigiCert como sua Autoridade de Certificação.

Desafio: Os processos manuais de renovação de certificados causaram várias interrupções de produção quando os certificados expiraram inesperadamente. Os certificados curinga criavam um raio de explosão excessivo quando as chaves privadas eram comprometidas. O gerenciamento fragmentado de certificados entre as equipes resultou em certificados sombra, padrões criptográficos inconsistentes e revogação atrasada durante incidentes de segurança. Sem renovação automatizada e inventário centralizado, a organização enfrentou falhas de conformidade e interrupções de serviço.

Abordagem da solução:

• Configure a integração da autoridade de certificação com o Azure Key Vault: Adicione o DigiCert (ou outra Autoridade de Certificação parceira) ao Cofre de Chaves com credenciais de API para solicitações de certificado automatizadas.
• Crie políticas de certificado que imponham padrões de segurança: Defina a política de certificado com o nome do certificado (www-contoso-com-2024), emissor (DigiCert), sujeito (CN=www.contoso.com), nomes DNS (SAN: www.contoso.com, api.contoso.com, portal.contoso.com - evitar certificados wildcard), tipo de chave (RSA 4096 bits), algoritmo de assinatura (SHA-256), período de validade (máximo de 397 dias de acordo com a linha de base do CA/Browser Forum), defina a ação de tempo de vida para renovação automática (defina o gatilho em 80% do tempo de vida do certificado, aproximadamente 318 dias para certificado de 397 dias); ação: renovar automaticamente (Key Vault solicita renovação do DigiCert sem intervenção manual).
• Configurar a vinculação automática de certificados para serviços do Azure: Para importar um certificado para o Serviço de Aplicações do Azure a partir do Cofre de Chaves, atribua uma identidade gerida atribuída pelo utilizador com a função de Utilizador de Segredos do Cofre de Chaves, habilite atualizações automáticas de certificados (o Serviço de Aplicações vincula a nova versão do certificado dentro de 24 horas quando renovado, sem necessidade de reinício); para o Gateway de Aplicações do Azure, configure o ouvinte para recuperar o certificado do Cofre de Chaves, atribua uma identidade gerida atribuída pelo utilizador com as funções de Utilizador de Segredos do Cofre de Chaves e Utilizador de Certificados; o Gateway de Aplicações recupera automaticamente o certificado atualizado quando o Cofre de Chaves o renova.
• Configure alertas de expiração de certificado: Crie duas regras de alerta no Azure Monitor — aviso de expiração de 30 dias (enviar notificação para o canal Slack de engenharia da plataforma), alerta crítico de expiração de 7 dias (abrir tíquete do Jira para revisão manual e enviar email para a equipe de segurança).
• Elimine os certificados curinga em favor dos certificados SAN: Audite certificados curinga existentes (*.contoso.com) no Cofre de Chaves, substitua por certificados SAN contendo nomes DNS explícitos (www.contoso.com, api.contoso.com), benefício: se a chave privada for comprometida, apenas os FQDNs listados serão afetados (não todos os subdomínios).
• Monitorar a expiração do certificado: Use o Azure Resource Graph para consultar o inventário de certificados e identificar certificados próximos da expiração (dentro de 30 dias), certificados autoassinados ou certificados usando algoritmo de assinatura SHA-1 preterido, revise o painel trimestralmente durante as reuniões de revisão de segurança.

Resultado: A renovação automatizada de certificados é acionada aos 80% da sua duração. O Serviço de Aplicativo do Azure e o Gateway de Aplicativo recuperam certificados atualizados em 24 horas por meio de identidades gerenciadas (sem necessidade de reinicialização). Os alertas do Azure Monitor notificam a engenharia da plataforma antes da expiração. Os certificados SAN substituem os certificados curinga, reduzindo o raio de jateamento comprometido.

Nível de criticidade

Deve ter.

Mapeamento de controle

• Controles CIS v8.1: N/A
• NIST SP 800-53 Rev.5: IA-5, SC-12, SC-17
• PCI-DSS v4: 3.6.1, 8.3.2
• NIST CSF v2.0: PR. AC-1, ID.AM-3
• ISO 27001:2022: A.8.3
• SOC 2: CC6.1, CC6.2

DP-8: Garantir a segurança do repositório de chaves e certificados

Azure Policy: Consulte definições de políticas incorporadas no Azure: DP-8.

Princípio da segurança

Proteja os serviços do cofre de chaves por meio de controles de defesa em profundidade: acesso de privilégios mínimos, isolamento de rede, registo e monitorização abrangentes, recursos de backup e recuperação e proteção apoiada por HSM, quando necessário. Os cofres de chaves são infraestruturas críticas que protegem chaves criptográficas e certificados usados para criptografia e autenticação.

Risco a mitigar

O comprometimento do repositório de chaves e certificados anula a criptografia, a assinatura e as garantias de identidade upstream. Sem acesso ao cofre fortificado, monitorização e isolamento:

• Exfiltração de chaves: O material KEKs / HSM roubado permite a desencriptação em massa dos dados armazenados e a interceção de tráfego.
• Acesso administrativo sombra: Configuração "RBAC" excessivamente ampla ou erro na configuração da política permite a exportação, eliminação ou reversão de versões de chaves de forma ilícita.
• Adulteração silenciosa: A substituição maliciosa de chaves facilita ataques transparentes do tipo man-in-the-middle ou resulta em códigos/assinaturas falsificados.
• Exposição à rede: O abuso de ponto final público (preenchimento de credenciais, prospecção de API) aumenta a superfície de ataque para ataques de força bruta ou repetição de token.
• Ações destrutivas acidentais: A falta de proteção de exclusão / purga suave leva à perda irreversível de dados criptográficos.
• Linhagem de auditoria insuficiente: A falta de registros imutáveis prejudica a resposta a incidentes e as necessidades probatórias regulatórias.
• Arrendamento não segmentado: As chaves de aplicação misturadas ampliam a amplitude do impacto do movimento lateral após o comprometimento de uma única identidade.

Os pontos fracos do repositório propagam-se rapidamente em falhas sistémicas de confidencialidade, integridade e disponibilidade em cargas de trabalho dependentes.

MITRE ATT&CK

• Acesso a credenciais (TA0006): credenciais/armazenamentos de credenciais desprotegidos (T1552 / T1555) obtidos por meio de políticas de rede ou função de cofre mal configuradas.
• Evasão de defesa (TA0005): adversário no meio (T1557) capturando tráfego vinculado ao cofre para intercetação de chave/certificado, ou enfraquecer a criptografia (T1600) substituindo chaves fortes por material controlado pelo invasor.
• Escalonamento de privilégios (TA0004): contas válidas (T1078) explorando funções de operador de cofre excessivamente amplas para enumerar e alterar segredos.
• Impacto (TA0040): destruição de dados / recuperação inibida (T1485 / T1490) realizando sequências de purga destrutivas que impedem a restauração.

DP-8.1: Implementar controles de acesso para o Cofre de Chaves

Proteja a base criptográfica de sua infraestrutura impondo controles de acesso rígidos baseados em identidade que impeçam o acesso não autorizado a chaves, limitem os privilégios administrativos a janelas de tempo justificadas e eliminem o armazenamento de credenciais por meio de identidades gerenciadas. Implemente a separação de tarefas entre administradores-chave e usuários-chave para evitar que qualquer identidade comprometida gerencie e explore material criptográfico.

Implementar o RBAC e a separação de funções:

• Implemente o RBAC do Azure para o Cofre da Chave para impor o controle de acesso de privilégios mínimos:
  • Para o HSM Gerenciado do Azure Key Vault: use o RBAC local no nível de chave individual, segredo e certificado com funções internas (HSM Gerenciado, Crypto Officer, Crypto User, Crypto Auditor).
  • Para o Azure Key Vault Standard/Premium: crie cofres dedicados por aplicativo ou ambiente para impor a separação lógica e atribuir funções RBAC (Key Vault Administrator, Secrets Officer, Certificate Officer) com escopo específico do aplicativo.
• Impor a separação de tarefas: Separe funções para gerenciamento de chaves (quem pode criar/girar chaves) de operações criptográficas (quem pode usar chaves para criptografar/descriptografar).

Use identidades gerenciadas e acesso JIT:

• Use identidades gerenciadas para recursos do Azure (Serviços de Aplicativo, VMs, Azure Functions, etc.) para acessar o Cofre da Chave em vez de armazenar credenciais no código do aplicativo ou em arquivos de configuração. As identidades gerenciadas eliminam a complexidade do armazenamento de credenciais e da rotação.
• Implemente o Azure AD Privileged Identity Management (PIM) para acesso administrativo just-in-time ao Cofre de Chaves.
  • Configure atribuições elegíveis para a função de administrador de Key Vault (não atribuições permanentes).
  • Exigir justificação, MFA e aprovação para ativação.
  • Defina a duração máxima de ativação (por exemplo, 8 horas).
  • Realize revisões regulares de acesso para revogar privilégios permanentes desnecessários.

DP-8.2: Segurança de rede do Harden Key Vault

Elimine as superfícies de ataque expostas à Internet redirecionando todo o acesso ao Cofre de Chaves através de pontos finais privados nas suas redes virtuais, evitando o preenchimento de credenciais, tentativas de força bruta e reconhecimento por agentes de ameaças externos. Quando o acesso público for inevitável para cenários de CI/CD, implemente regras rígidas de permissão de IP e firewall para criar a menor janela de exposição possível.

Implante o Private Link e configure o firewall:

• Acesso de rede seguro ao Cofre da Chave do Azure usando o Azure Private Link para estabelecer conectividade privada de redes virtuais sem expor o Cofre da Chave à Internet pública.
• Configure o firewall do Cofre da Chave para restringir o acesso a intervalos de IP ou redes virtuais específicos para cenários em que o Private Link não é viável:
  • Desative o acesso público sempre que possível (o Key Vault só pode ser acedido através de um ponto de extremidade privado).
  • Se o acesso público for necessário (por exemplo, para pipelines de CI/CD), permita o acesso de redes selecionadas apenas com listas de permissões de IP estreitas.
• Crie e vincule zonas DNS privadas (por exemplo, privatelink.vaultcore.azure.net) a redes virtuais para garantir a resolução DNS adequada para pontos de extremidade privados.

DP-8.3: Ativar a proteção e o monitoramento do Cofre de Chaves

Implemente proteções de defesa em profundidade que impeçam a perda irreversível de dados criptográficos por meio de eliminação reversível e proteção contra purgação, usando chaves suportadas por HSM para cargas de trabalho de produção que exigem segurança validada pelo FIPS. Implante um monitoramento abrangente com o Microsoft Defender for Key Vault e o Microsoft Sentinel para detetar padrões de acesso anômalos, operações-chave incomuns e anomalias administrativas que indicam comprometimento, ameaças internas ou atividades de reconhecimento direcionadas à sua infraestrutura criptográfica.

Habilite a eliminação suave e proteção contra purga:

• Habilite a proteção de exclusão suave e limpeza em todos os Cofres de Chaves do Azure para evitar a exclusão acidental ou mal-intencionada de chaves, segredos e certificados:
  • A exclusão suave permite a recuperação dentro de um período de retenção (padrão: 90 dias).
  • A proteção contra purgação impede a exclusão permanente durante o período de retenção.
  • Imponha essas configurações com a Política do Azure usando políticas internas: "Os cofres de chaves devem ter a exclusão suave habilitada" e "Os cofres de chaves devem ter a proteção contra limpeza habilitada" (efeito deployIfNotExists).
• Implemente as principais políticas de ciclo de vida para evitar a eliminação criptográfica de dados:
  • Antes de limpar dados criptografados, verifique se as chaves de criptografia são mantidas pelo período de retenção de dados necessário.
  • Ao desativar chaves, utilize a operação desativar em vez de apagar para evitar a perda acidental de dados, enquanto mantém os metadados da chave para fins de auditoria.
  • Crie e teste procedimentos de backup do Cofre de Chaves para cenários de recuperação de desastres.

Utilize chaves suportadas por HSM e BYOK:

• Use chaves apoiadas por HSM para cargas de trabalho de produção que exigem forte proteção criptográfica:
  • Azure Key Vault Premium: chaves RSA-HSM e EC-HSM protegidas por HSMs validados pelo FIPS 140-2 Nível 2 (multilocatário compartilhado).
  • Azure Key Vault Managed HSM: chaves de RSA-HSM e EC-HSM protegidas por HSMs validados segundo o padrão FIPS 140-3 Nível 3 (pools dedicados de inquilino único).
• Para cenários BYOK (Bring Your Own Key), gere chaves em HSMs FIPS 140-2 Nível 2+ locais e use o mecanismo de chave de transferência BYOK para importar chaves com segurança para o Cofre de Chaves do Azure, mantendo a prova criptográfica de origem e custódia da chave.

Habilite o monitoramento e a deteção de ameaças:

• Habilite o log de diagnóstico para o Cofre de Chaves do Azure e encaminhe logs para o Azure Monitor, Log Analytics ou Microsoft Sentinel para capturar todas as operações do plano de gestão e de dados. Monitore atividades suspeitas, incluindo padrões incomuns de acesso a chaves, tentativas de autenticação com falha e alterações administrativas.
• Habilite o Microsoft Defender for Key Vault para detetar padrões de acesso anômalos, operações de chave incomuns e ameaças potenciais, como abuso de credenciais, recuperações suspeitas de chaves ou anomalias administrativas. Integre alertas do Defender for Key Vault com fluxos de trabalho de resposta a incidentes.
• Integre os logs do Key Vault com o Microsoft Sentinel para criar regras de análise para detetar anomalias, como acesso regional incomum, possíveis tentativas de força bruta ou operações administrativas suspeitas. Implemente manuais de resposta automatizados para isolar identidades comprometidas e notificar as equipes de segurança.

Observação: Todos os SKUs do Key Vault impedem a exportação de chaves por design; as operações criptográficas são realizadas dentro do limite seguro do HSM. Nunca exporte ou armazene chaves em texto sem formatação fora do Cofre de Chaves do Azure.

Exemplo de implementação

Uma empresa multinacional de tecnologia implementou segurança de defesa profunda para sua infraestrutura do Azure Key Vault, protegendo chaves de criptografia, segredos de API e certificados TLS para microsserviços 500+.

Desafio: Permissões RBAC muito amplas permitiam que os desenvolvedores tivessem acesso direto aos Cofres de Chaves de produção, resultando em riscos internos e violações de conformidade. A exposição pública na Internet permitiu ataques de preenchimento de credenciais e tentativas de reconhecimento. Sem monitoramento abrangente e resposta automatizada, padrões suspeitos de acesso a chaves não foram detetados. A falta de exclusão lógica e proteção contra purga acarretava o risco de perda permanente de dados criptográficos durante incidentes.

Abordagem da solução:

• Implante cofres de chaves dedicados para segmentação lógica: Crie o Key Vault por ambiente e unidade de negócios com convenção de nomenclatura kv-{businessunit}-{environment}-{region} (por exemplo, kv-finance-prod-eastus2, kv-finance-dev-eastus2), implante em grupos de recursos separados por ambiente para impor o isolamento (a entidade de serviço de desenvolvimento comprometida não pode acessar chaves de produção).
• Configurar RBAC para acesso de privilégios mínimos: Para Key Vaults que não sejam de produção (desenvolvimento/preparação), atribuir o papel de "Usuário de Segredos do Key Vault" (somente leitura) aos grupos de segurança dos desenvolvedores — os desenvolvedores podem ler segredos em desenvolvimento/preparação, mas não têm acesso aos Key Vaults de produção; para Key Vaults de produção, atribuir o papel de "Usuário de Segredos do Key Vault" às entidades de serviço CI/CD (identidades geridas por pipeline do Azure DevOps), limitando o escopo a segredos nomeados específicos, garantindo que não há acesso interativo por parte dos desenvolvedores a chaves de produção.
• Proteja a segurança da rede com o Azure Private Link: Implante pontos de extremidade privados para o Key Vault (selecione a VNet e a sub-rede, crie a zona DNS privada privatelink.vaultcore.azure.net e vincule-a à VNet), configure o firewall do Key Vault (desativar o acesso público, tornando o Key Vault acessível apenas por meio de um ponto de extremidade privado, se o acesso público for necessário para CI/CD, permitir o acesso apenas de redes selecionadas com sub-redes aprovadas do Azure VNet e faixas de endereços IP dos agentes de CI/CD).
• Habilite o Microsoft Defender for Key Vault: Habilite o Microsoft Defender for Key Vault no nível de assinatura, o Defender monitora anomalias, incluindo acesso geográfico incomum, enumeração suspeita (operações de lista rápida indicando reconhecimento), operações administrativas anormais (exclusões secretas em massa).
• Integre com o Microsoft Sentinel para resposta automatizada: Adicione o conector de dados do Microsoft Defender for Cloud ao Sentinel, crie regras do Sentinel Analytics para acesso regional incomum, força bruta potencial, operações administrativas suspeitas, configure manuais de resposta automatizada para desabilitar identidades suspeitas e notifique as equipes de segurança.
• Transmita logs de diagnóstico para o Log Analytics: Habilite o log de diagnóstico para o Key Vault com AuditEvent (todas as operações de chave/segredo/certificado), AllMetrics (frequência de uso, latência), envie para o espaço de trabalho do Log Analytics com retenção de 2 anos, crie consultas KQL personalizadas para deteção de anomalias, incluindo deteção de força bruta potencial (10+ tentativas não autorizadas em 5 minutos), operações de exclusão suave desabilitadas (indicador de sabotagem).
• Implemente o acesso de administrador do Just-In-Time com o Azure AD PIM: Configurar atribuições qualificadas para a função de Administrador do Cofre de Chaves (adicionar membros da equipe de segurança como Atribuição não permanente elegível, exigir Justificação e MFA para ativação, definir duração máxima de ativação de 8 horas, exigir aprovação de arquiteto de segurança sênior), conduzir revisões trimestrais de acesso para todas as atribuições de função de Administrador do Cofre de Chaves; revogar acesso desnecessário.

Resultado: Cofres de chaves dedicados por ambiente impõem a segmentação. O RBAC limita os desenvolvedores a acesso de somente leitura a ambientes não-produtivos. O Private Link elimina a exposição pública à Internet. O Microsoft Defender deteta anomalias. Os playbooks do Sentinel desativam automaticamente identidades suspeitas. O PIM permite o acesso de administrador em tempo real, reduzindo significativamente os privilégios permanentes.

Nível de criticidade

Deve ter.

Mapeamento de controle

• Controles CIS v8.1: N/A
• NIST SP 800-53 Rev.5: IA-5, SC-12, SC-17
• PCI-DSS v4: 3.6.1, 8.3.2
• NIST CSF v2.0: PR. AC-1, PR. DS-1
• ISO 27001:2022: A.8.3, A.8.24
• SOC 2: CC6.1, CC6.2