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. Esta abordagem em camadas está alinhada com os princípios do Confiança Zero e as 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 as definições de política integradas 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 construir um mapa de dados abrangente que descobre, classifica e rotula automaticamente informações sensíveis em todo o seu património de dados. Estenda a proteção para além da encriptação ao nível da infraestrutura, implementando o Proteção de Informações do Microsoft Purview para aplicar encriptação persistente ao nível do documento e direitos de utilização que seguem os dados para onde quer que 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:

• Implemente Microsoft Purview para descobrir, classificar e rotular dados sensíveis em ambientes Azure, on-premises, Microsoft 365 e multi-cloud.
• Use Microsoft Purview Data Map para escanear e catalogar automaticamente fontes de dados, incluindo Armazenamento do Azure, Base de Dados SQL do Azure, Azure Synapse Analytics e outros serviços suportados.
• 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:

• Implemente Proteção de Informações do Microsoft Purview para aplicar encriptação persistente e direitos de utilização a documentos e emails com base em rótulos de sensibilidade. 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.
• Ative o Azure Rights Management Service (Azure RMS) como a tecnologia de proteção subjacente que encripta documentos e emails com políticas de utilização (apenas visualização, sem cópia, sem impressão) que persistem independentemente de onde os dados são armazenados ou partilhados.

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

• Para bases de dados SQL do Azure, ative SQL Data Discovery & SQL Classificação para identificar, classificar e rotular colunas contendo dados sensíveis como números de cartão de crédito, números de segurança social ou registos de saúde.
• Integrar metadados de classificação com controlos a jusante: configurar políticas de Prevenção de Perda de Dados (DLP) no Microsoft Purview, aplicar regras de acesso condicional no Entra ID e aplicar políticas de encriptação baseadas 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 implementou o Microsoft Purview Data Map para descobrir e classificar automaticamente dados sensíveis em 200+ contas Armazenamento do Azure, 50 bases de dados SQL e espaços de trabalho Synapse Analytics.

Desafio: A organização não tinha visão sobre onde residiam dados sensíveis ao longo do seu património de dados de 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:

• Implementar Microsoft Purview Data Map para descoberta de dados: Criar uma conta Purview e registar fontes de dados (contas Armazenamento do Azure, bases de dados SQL, espaços de trabalho Synapse Analytics), configurar o Data Map para escanear fontes usando autenticação de identidade gerida, conceder permissões de leitura de identidade de varredura (função db_datareader) para catalogar esquemas e detetar colunas sensíveis.
• 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.
• Implementar Proteção de Informações do Microsoft Purview para encriptação ao nível do documento: Criar etiquetas de sensibilidade no portal de conformidade Purview com definições de proteção (Público: sem encriptação, apenas marcações visuais; Interno: marca de água, sem restrições de encaminhamento; Confidencial: encriptar com Azure RMS, permitir visualização/edição apenas para funcionários, bloquear encaminhamento/impressão; Altamente Confidencial - Regulado: encriptar com Azure RMS, acesso apenas de visualização, sem cópia/impressão/encaminhamento, validade de 90 dias, acesso revogável), publicar etiquetas de sensibilidade aos utilizadores através de políticas de rótulos (âmbito: Finanças, Jurídico, Departamentos Executivos), configurar políticas de rotulagem automática para aplicar automaticamente as etiquetas (≥10 SSNs → "Altamente Confidencial - Regulado", ≥5 números de cartão de crédito → "Altamente Confidencial - Regulado"), ativar a proteção do Azure RMS para documentos rotulados armazenados em contas SharePoint, OneDrive e Armazenamento do Azure, configurar a etiquetagem no cliente para as aplicações do Office para solicitar aos utilizadores que classifiquem documentos antes de guardar/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 auto-rotulagem da Information Protection aplicou encriptação 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: Ver definições de políticas incorporadas 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

Implemente serviços Microsoft Defender para fornecer deteção de ameaças em tempo real e monitorização de anomalias nas suas plataformas de armazenamento de dados e bases 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:

• Ative o Microsoft Defender para Armazenamento com varredura de malware e deteção de ameaças de dados sensíveis para monitorizar padrões de acesso anómalos, volumes invulgares de upload/download e potenciais tentativas de exfiltração de dados entre Armazenamento do Azure contas.
• Ative o Microsoft Defender para SQL para detetar atividades suspeitas na base de dados, incluindo tentativas de injeção SQL, padrões de consulta anómalos, operações invulgares de exportação de dados e acesso a partir de locais desconhecidos.
• Ative Microsoft Defender para Azure Cosmos DB para detetar padrões anómalos de acesso a bases de dados, potencial exfiltração de dados e atividades operacionais suspeitas.
• Para bases de dados open-source (PostgreSQL, MySQL), ative o Microsoft Defender para bases de dados relacionais open-source 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:

• Utilizar políticas Prevenção de Perda de Dados do Microsoft Purview (DLP) para prevenir a exfiltração de dados sensíveis, monitorizando e bloqueando transferências não autorizadas de dados classificados entre Azure serviços, Microsoft 365 e endpoints.
• Implemente Gestão do risco interno do Microsoft Purview para detetar comportamentos de risco dos utilizadores usando aprendizagem automática e análises comportamentais. 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. A Gestão de Riscos Insider correlaciona sinais provenientes do Microsoft 365, Azure, sistemas de RH e ferramentas de segurança para identificar potenciais roubos de dados ou violações de políticas.

Configure o monitoramento e a resposta:

• Configure registos diagnósticos para serviços de dados e encaminhe-os para Azure Monitor ou Microsoft Sentinel para estabelecer padrões de comportamento e detetar desvios dos padrões normais de acesso.
• Integrar registos de serviços de dados com Microsoft Sentinel para criar regras analíticas para detetar padrões anómalos de acesso a dados, como downloads em massa, acessos fora de horas ou comportamentos de consulta suspeitos.
• Implementar fluxos de trabalho automatizados de resposta a incidentes usando Azure Logic Apps ou Microsoft Sentinel playbooks para isolar identidades comprometidas, revogar o acesso e notificar as equipas de segurança quando forem detetadas tentativas de exfiltração de dados.

Nota: Para requisitos de DLP baseados em host, implemente capacidades Microsoft Purview DLP de endpoint ou soluções de terceiros da Azure Marketplace para impor controlos de proteção de dados ao nível do endpoint.

Exemplo de implementação

Um prestador de cuidados de saúde permitiu que o Microsoft Defender for Storage e o Defender para SQL monitorizassem anomalias e ameaças direcionadas a dados de pacientes através de contas do Armazenamento do Azure e bases 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:

• Ativar Microsoft Defender para Armazenamento: Ativar Defender para Armazenamento ao nível de subscrição para contas de armazenamento contendo dados sensíveis, configurar a análise de malware para detetar e quarentena ficheiros maliciosos em armazenamento blob, ativar a deteção de ameaças de dados sensíveis usando Tipos de Informação Sensível Purview para identificar padrões PHI/PII, definir limites de varrimento por transação ou limites mensais para controlar custos, aplicar proteção a grupos de recursos que contenham contas de armazenamento de produção que alojam imagens médicas e exportações de EHR.
• Ativar Microsoft Defender para SQL: Ativar Defender para SQL ao nível de subscrição para Base de Dados SQL do Azure e SQL Managed Instance, configurar a Avaliação de Vulnerabilidades com análises recorrentes e designar conta de armazenamento para os resultados das análises, configurar notificações por email para alertar a equipa de segurança sobre vulnerabilidades identificadas, permitir que o Advanced Threat Protection detete tentativas de injeção SQL, padrões de consulta invulgares, acesso anómalo de regiões desconhecidas e potencial exfiltração de dados.
• Integrar com Microsoft Sentinel: Ligar Microsoft Defender para a Cloud à Microsoft Sentinel usando conector de dados, configurar definições de diagnóstico (ativar registos de diagnóstico para operações de armazenamento e registos de auditoria SQL, encaminhar para Log Analytics espaço de trabalho), criar regras Sentinel Analytics para detetar anomalias (alertas de download em massa para downloads >10 GB dentro de 1 hora, acesso a bases de dados fora de horas, padrões de consulta suspeitos), configurar manuais de resposta automática para isolar identidades comprometidas, revogar o acesso ao armazenamento e notificar as equipas de segurança.
• Implementar o Gestão do risco interno do Microsoft Purview para deteção de ameaças comportamentais: Ativar a Gestão de Riscos Internos e configurar modelos de políticas (detecção de roubo de dados por colegas que saem através de downloads invulgares de ficheiros entre 30 a 90 dias antes da sua saída, monitorizar fugas gerais de dados através de cópia para armazenamento USB/cloud, fugas de dados por utilizadores prioritários com monitorização reforçada para funções de alto privilégio), configurar indicadores e limiares de risco (alertas de volume cumulativo de downloads de ficheiros, picos de acesso fora do horário de expediente, deteção de sequência através da combinação de múltiplos sinais de risco), integrar fontes de dados (Azure Activity Logs, Microsoft 365 audit logs, Defender for Cloud Apps, sistemas de RH, eventos de prevenção de perda de dados nos pontos finais), configurar o fluxo de trabalho para triagem de alertas, encaminhando alertas de média/alta gravidade para uma fila dedicada de investigação.

Resultado: O Defender para Armazenamento detetou atividade anómala de download em massa de um principal de serviço comprometido dentro de 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: Consulte as definições de políticas incorporadas do 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:

• Aplicar transferência segura (apenas HTTPS) para contas do Armazenamento do Azure, garantindo que todas as ligações dos clientes usem TLS 1.2 ou versão superior para operações de blob, ficheiros, filas e tabelas.
• Para aplicações web alojadas em Serviço de Aplicações do Azure, ative a definição "HTTPS Only" e configure a versão TLS minimum para 1.2 ou 1.3 para evitar ataques de downgrade e garantir padrões criptográficos modernos.
• Configure Gateway de Aplicação do Azure para impor a versão mínima TLS 1.2/1.3 tanto para ouvintes de frontend como para encriptação de ligação do backend (TLS de extremo a extremo).
• Para o Base de Dados SQL do Azure e outros serviços de dados PaaS, verifique se "Exigir Conexões Seguras" ou definições equivalentes impõem ligações encriptadas; rejeite ligações em texto simples.
• Para Gestão de APIs, Azure Front Door e outros serviços de gateway, configure políticas mínimas de versões TLS para aplicar TLS 1.2 ou superior e desativar conjuntos de cifras fracas.

Nota: Azure encripta automaticamente todo o tráfego entre Azure datacenters usando MACsec (camada 2) e TLS (camada 7). A maioria dos serviços PaaS do Azure ativa o TLS 1.2+ por defeito, mas verifica as definições mínimas de versão TLS para serviços com políticas configuráveis pelo cliente (Armazenamento, Serviço de Aplicações, Gateway de Aplicações, Gestão de API, Porta Frontal).

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 a gestão remota de máquinas virtuais Azure, use exclusivamente protocolos seguros:
  • VMs Linux: Use SSH (porta 22) com autenticação baseada em chave; Desative a autenticação de senha.
  • Windows VMs: Usar RDP sobre TLS (porta 3389) com a Autenticação a Nível de Rede (NLA) ativada.
  • Acesso privilegiado: Encaminhar ligações administrativas através de Azure Bastion para eliminar exposição pública a IP e fornecer acesso baseado em navegador ou cliente nativo via TLS.

Protocolos seguros de transferência de ficheiros:

• Para operações de transferência de arquivos, use protocolos seguros e desative alternativas herdadas:
  • Use suporte SFTP em Armazenamento de Blobs do Azure (requer espaço de nomes hierárquico).
  • Usa FTPS em Serviço de Aplicações do Azure e Funções do Azure.
  • Desative o protocolo FTP herdado (texto sem formatação).
• Use Azure Policy para aplicar políticas de transferência segura em todo o seu ambiente e monitorizar a conformidade com os requisitos de versão 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 Serviço de Aplicações do Azure para TLS 1.3: Defina a versão mínima TLS para 1.3 para aplicações web e APIs orientadas ao cliente, ative o modo apenas HTTPS para redirecionar automaticamente todo o tráfego HTTP para HTTPS, verifique se os certificados geridos ou personalizados usam conjuntos de cifras fortes.
• Configure o Gateway de Aplicação do Azure para TLS de ponta a ponta: Configure o ouvinte HTTPS do frontend com a política SSL AppGwSslPolicy20220101 (TLS 1.3 no mínimo com a política CustomV2), carregue um certificado TLS ou integre-o com o Key Vault para gestão de certificados, configure as definições de backend para conexões HTTPS (defina o protocolo de backend para HTTPS na porta 443, ative "Use certificado CA bem conhecido" se os Serviços de Aplicações de backend usarem certificados geridos pelo Azure, defina a versão mínima TLS para 1.2 para conexões de backend), crie regras de encaminhamento que liguem ouvintes HTTPS a pools de backend com definições TLS ativadas.
• Impor transferência segura para Armazenamento do Azure: Ativar a definição "Transferência segura necessária" para impor apenas HTTPS para operações de blob, ficheiro, fila e tabela, definir a versão mínima TLS para 1.2 para todas as ligações de armazenamento, verificar se todos os tokens SAS e chaves partilhadas funcionam apenas através de ligações HTTPS.
• Configurar Azure Bastion para acesso remoto seguro: Implementar Azure Bastion no hub VNet para fornecer acesso RDP/SSH baseado em navegador via TLS 1.2, remover IPs públicos das VMs e encaminhar todo o acesso administrativo exclusivamente através do Bastion.

Resultado: As contas de Armazenamento do Azure rejeitam ligações HTTP no limite do serviço, o Application Gateway impõe TLS 1.3 para ligações frontend com encriptação backend TLS 1.2, e o Azure Bastion elimina a exposição a IP público para a gestão de VMs.

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: Veja definições de políticas pré-definidas 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

Garanta que todos os dados armazenados no Azure estão encriptados em repouso para proteger contra acessos não autorizados devido a comprometimento de infraestruturas, media roubada ou snapshots não autorizados. Embora a maioria dos serviços Azure permita encriptação por defeito, verifica a cobertura entre máquinas virtuais, contas de armazenamento e bases de dados, e permite camadas adicionais de encriptação (encriptação no host, encriptação de infraestrutura, computação confidencial e encriptação ao nível das colunas) para cargas de trabalho altamente sensíveis, cumprindo requisitos regulatórios e de soberania de dados.

Habilite a criptografia para VMs e armazenamento:

• Ative encryption-at-host para Máquinas Virtuais do Azure encriptar discos temporários, cache de disco do sistema operativo, cache de disco de dados e discos efémeros do sistema operativo antes de os dados chegarem 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).
• Ative a encriptação infraestrutura (dupla encriptação) para contas Armazenamento do Azure que necessitem de camadas adicionais de encriptação. 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:

• Implantar VMs Azure Confidenciais com encriptação de disco confidencial para cargas de trabalho altamente regulamentadas que processam dados controlados por exportação ou sensíveis. 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 Base de Dados SQL do Azure, implementar Sempre Encriptado para fornecer encriptação ao nível das colunas do lado do cliente para dados altamente sensíveis (SSN, números de cartão de crédito, registos médicos), onde os dados permanecem encriptados mesmo por administradores de bases de dados, operadores cloud e utilizadores de alto privilégio 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:

• Impor a conformidade com a encriptação usando Azure Policy atribuindo políticas incorporadas como "As máquinas virtuais devem permitir a encriptação no anfitrião", "As contas de armazenamento devem ter encriptação da infraestrutura" e "Encriptação de Dados Transparente em bases de dados SQL devem estar ativadas" no âmbito de subscrição ou grupo de gestão.
• Utilize Azure Resource Graph para consultar e listar configurações de encriptação em todo o seu ambiente, identificando VMs sem encriptação no anfitrião, contas de armazenamento sem encriptação de infraestrutura ou bases de dados sem TDE ativado.

Nota: Muitos serviços de Azure (Armazenamento do Azure, Base de Dados SQL do Azure, Azure Cosmos DB) têm a encriptação de dados em repouso ativada por defeito na camada de infraestrutura, utilizando chaves geridas pelo serviço que rodam 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 fabrico padronizou a encriptação em repouso no seu ambiente Azure para proteger dados ERP, aplicações da cadeia de abastecimento 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:

• Ativar a encriptação no host para Máquinas Virtuais do Azure: Registar a funcionalidade EncryptionAtHost ao nível da subscrição, ativar a encriptação no host para VMs que utilizam tamanhos de VM suportados (séries DSv3, Easv4, Dadsv5), a encriptação cobre discos temporários, cache de disco do sistema operativo, cache de disco de dados e discos efémeros do sistema operativo.
• Ativar a encriptação da infraestrutura (dupla encriptação) para Armazenamento do Azure: Verificar Armazenamento do Azure Encriptação do Serviço (SSE) está ativada (ativada por defeito — encriptação AES-256), para contas de armazenamento sensíveis permitir a encriptação da infraestrutura durante a criação da conta de armazenamento (não pode ser ativada após a criação), resultado: duas camadas de encriptação AES-256 com chaves diferentes.
• Implementar VMs Azure Confidenciais para cargas de trabalho altamente reguladas: Selecionar séries Confidential VM apropriadas (DCasv5/DCadsv5-series para AMD SEV-SNP ou ECasv5/ECadsv5-series para Intel TDX), ativar encriptação confidencial de disco com chave gerida pela plataforma (vincular chaves de encriptação de disco ao TPM virtual da VM), ativar Secure Boot e vTPM para atestado, implementar para cargas de trabalho que processam dados técnicos controlados por exportação ou PII altamente reguladas onde os dados devem permanecer encriptado durante o processamento.
• Implementar o Always Encrypted para colunas sensíveis de bases de dados: Identificar colunas altamente sensíveis no Base de Dados SQL do Azure que necessitem de encriptação ao nível das colunas (SSN, CreditCardNumber, MedicalRecordNumber), gerar chaves de encriptação de colunas (CEK) e chaves mestras de coluna (CMK), armazenando a CMK no Azure Key Vault, com CEK a encriptar colunas de dados e CMK a encriptar CEK. Ativar o Always Encrypted com enclaves seguros (Intel SGX) para permitir consultas avançadas em dados encriptados, encriptar colunas sensíveis usando encriptação determinística (para consultas de igualdade) ou encriptação aleatória (para máxima segurança), configurar strings de conexão de aplicação com Column Encryption Setting=Enabled para encriptação/desencriptação transparente.
• Configurações de encriptação de inventário com Azure Resource Graph: Consultar o estado da encriptação para VMs sem contas de encriptação no host e de armazenamento sem encriptação de infraestrutura, exportar resultados para CSV e atribuir tarefas de remediação aos proprietários dos 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: Consultar definições de políticas incorporadas de 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 requerem controlo final onde nem a Microsoft consegue desencriptar dados, implemente a Encriptação de Dupla Chave (DKE), onde a sua organização mantém uma segunda chave de encriptação fora do Azure. Use o Azure Key Vault ou o HSM Gerido para manter o controlo criptográfico, equilibrando a complexidade operacional da gestão do ciclo de vida das chaves, planeamento de recuperação de desastres e potenciais impactos na disponibilidade de serviços devido a erros de gestão 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.
• Provisão Azure Key Vault (Standard ou Premium) ou Azure Key Vault HSM gerida para armazenar e gerir chaves de encriptação geridas pelo cliente. Use o HSM gerenciado para cargas de trabalho que exigem proteção de hardware validada FIPS 140-3 Nível 3.
• Gerar chaves de encriptação dentro de Azure Key Vault usando capacidades de geração chaves, ou importar chaves de HSMs locais usando Bring Your Own Key (BYOK) para máxima portabilidade e controlo.

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

• Para requisitos extremos de controlo, implemente Encriptação de Dupla Chave (DKE) onde documentos sensíveis requerem duas chaves para desencriptação: uma gerida pela Microsoft (Azure RMS) e uma segunda chave gerida exclusivamente pela sua organização localmente ou no seu próprio serviço externo de gestão de chaves. Com a DKE, a Microsoft não pode desencriptar os seus dados mesmo que seja obrigada por processo legal, pois controla a segunda chave necessária para a desencriptação.
• Configure os serviços do Azure (Armazenamento do Azure, Base de Dados SQL do Azure, Azure Cosmos DB, Azure Disk Encryption, etc.) para usar o CMK através da referência ao Key Vault Key URI. Habilite políticas de rotação automática de chaves para reduzir a carga operacional manual.
• Estabelecer uma hierarquia de chave de criptografia de chave (KEK) e chave de criptografia de dados (DEK), onde a KEK (armazenada no Key Vault) encripta a DEK (utilizada pelos serviços), minimizando o impacto da rotação de chaves na disponibilidade dos serviços.
• 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 regulada implementou chaves geridas pelo cliente (CMK) em todos os serviços da Azure para satisfazer os requisitos regulatórios de controlo criptográfico direto sobre dados de negociação e registos financeiros dos 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:

• Provisionamento de HSM Gerido do Azure Key Vault: Criar HSM Gerido (FIPS 140-3 Nível 3 validado) com pelo menos 3 partições HSM para alta disponibilidade, ativar o HSM Gerido exportando o domínio de segurança com chaves de quórum (divididas em fragmentos de chave armazenados em cofres offline distribuídos geograficamente), gerar chaves de criptografia (RSA-4096 nomeado KEK-Prod-2024) com operações de chave: Wrap Key, Unwrap Key, encriptar, desencriptar.
• Configurar chaves geridas pelo cliente para serviços Azure: Para o Armazenamento do Azure, configure a conta de armazenamento para usar o tipo de encriptação CMK, selecione o HSM Gerido do Key Vault como fonte de chaves, e ative a identidade gerida atribuída pelo utilizador com a função de Utilizador de Encriptação do Serviço Crypto do HSM Gerido; para o 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 e ative a rotação automática de chaves; para o Azure Cosmos DB, ative as chaves geridas pelo cliente para a conta Cosmos DB, selecione a chave do HSM Gerido e conceda acesso à identidade gerida do Cosmos DB.
• Implementar rotação automática de chaves: Configurar a política de rotação com frequência de rotação de 90 dias, ativar a rotação automática, configurar a notificação de expiração (alerta 7 dias antes da expiração), criar Azure Monitor alerta para a métrica Key Near Expiry para notificar a equipa de segurança.
• Ativar registos de auditoria para conformidade: Ativar registos de diagnóstico para HSM geridos (registos AuditEvent), enviar registos para o workspace do Log Analytics com armazenamento imutável (retenção de 90 dias para trilhas de auditoria à prova de adulteração), consultar registos de acesso a chaves para monitorizar operações de Encriptação, Desencriptação, EmpacotarChave e DesempacotarChave.
• 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: KEKs RSA-4096 em HSMs geridos encriptam DEKs de nível de serviço para Armazenamento do Azure, Base 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: Consulte as definições de políticas integradas do 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. Implemente o Azure Key Vault como a única fonte de verdade para operações de chave, ao mesmo tempo que implementa registos de auditoria abrangentes para acompanhar todos os acessos de chaves e alterações administrativas para fins de conformidade e investigação forense.

Estabeleça uma infraestrutura centralizada de gerenciamento de chaves:

• Use Azure Key Vault como serviço centralizado de gestão criptográfica de chaves para controlar todo o ciclo de vida 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 o nível Key Vault apropriado 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, utilize Azure Key Vault Managed HSM para proteção HSM de locatário único validada de acordo com FIPS 140-3 Nível 3. O HSM gerenciado suporta domínio criptográfico para backup e recuperação de desastres.
• Configurar registos Azure Key Vault e encaminhar registos para Azure Monitor ou Microsoft Sentinel para acompanhar todos os acessos-chave, 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:

• Implementar políticas automática de rotação de chaves em Azure Key Vault:
  • 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 Azure Key Vault com controlos de acesso restritos.
  • 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 Bring Your Own Key (BYOK), gere chaves em HSMs on-premises FIPS 140-2 Nível 2+ e utilize o mecanismo de transferência de chave BYOK para importar chaves de forma segura para Azure Key Vault HSM ou Managed HSM, mantendo provas criptográficas da 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:

• Integrar a monitorização de acesso de chaves com 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 fornecedor SaaS na área da saúde centralizou a gestão criptográfica de chaves usando o Azure Key Vault Premium SKU com chaves protegidas por HSM para encriptação PHI em toda a sua plataforma multi-inquilino.

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:

• Provisionar Azure Key Vault Premium com chaves protegidas por HSM: Criar um Azure Key Vault com o nível Premium para suportar chaves protegidas por HSM, ativar a proteção contra purgas para evitar a eliminação permanente durante o período de retenção, ativar a eliminação reversível com retenção de 90 dias para permitir a recuperação de chaves apagadas acidentalmente, gerar chaves de encriptação RSA-3072 protegidas por HSM (KEK-PHI-Prod) com tipo de chave suportada por hardware.
• Implementar políticas automatizadas de rotação de chaves: Configurar a política de rotação com frequência de rotação de 180 dias, ativar a rotação automática e definir a notificação para alertar 30 dias antes do vencimento, criar grupos de ação Azure Monitor para notificar a equipa de operações de segurança quando as chaves estiverem perto do prazo, configurar a ação de rotação para gerar automaticamente novas versões de chaves.
• Configurar a separação de funções RBAC: Atribuir o papel de Oficial de Criptografia do Key Vault aos membros da equipa de segurança (permissões: gerir o ciclo de vida da chave, mas não pode realizar operações de encriptação/desencriptação), atribuir o papel de Utilizador de Criptografia do Key Vault às identidades geridas por aplicações (permissões: realizar operações de encriptação/desencriptação apenas, sem permissões de gestão de chaves), verificar a separação de funções garantindo que nenhuma identidade tem ambos os papéis de Oficial e Utilizador de Criptografia.
• Estabelecer a hierarquia KEK/DEK para rotação rápida de chaves: Gerar Chaves de Encriptação de Dados (DEKs) ao nível da aplicação dentro do código da aplicação (chaves AES-256) para encriptar dados do paciente, armazenar DEKs encriptados juntamente com dados encriptados, usar Key Vault KEK para envolver/encriptar DEKs via operação WrapKey, recuperar e desdobrar DEK usando a operação UnwrapKey ao desencriptar dados do paciente, benefício: rotação do KEK apenas requer a reencriptação dos DEKs em vez de toda a base de dados do paciente.
• Integrar registos do Key Vault com o Microsoft Sentinel: Ativar as definições de diagnóstico para o Key Vault e enviar registos para o espaço de trabalho do Log Analytics, criar regras de análise do Sentinel para detetar padrões invulgares de acesso a chaves, operações em massa de chaves e alterações administrativas fora de horas.
• Transferência Bring Your Own Key (BYOK) do HSM no local: Transferir a chave de transferência BYOK do Key Vault, exportar a chave do HSM no local envolvida com a chave pública de transferência BYOK do Key Vault, manter a prova criptográfica da linhagem da chave, importar a chave envolvida para o Key Vault onde chega protegida por HSM sem exposição ao 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 a IPs desconhecido ou modificações fora de horário.

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 as definições de políticas predefinidas do 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 Azure Key Vault para gerir centralmente todo o ciclo de vida dos certificados: criação, importação, renovação, rotação, revogação e eliminação segura.
• Defina políticas certificate em Azure Key Vault para aplicar normas 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 Autoridades Certificadoras parceiras integradas com o Azure Key Vault para certificados públicos TLS/SSL:
  • 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 Certificadora interna da sua organização (por exemplo, Active Directory Certificate Services - ADCS) com o Azure Key Vault para emissão automática 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.

Nota: Para cenários simples, pode usar Serviço de Aplicações do Azure Certificados Geridos (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 Key Vault usando identidades geridas, reduzindo o trabalho operacional e eliminando o risco de renovações manuais esquecidas durante feriados ou transições de funcionários.

Configure a renovação automatizada:

• Ative a renovação automática de certificados no Azure Key Vault configurando ações de ciclo de vida para desencadear a renovação numa percentagem especificada da vida útil 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 (Key Vault solicita renovação à CA 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 Azure que suportam rotação automática de certificados (Serviço de Aplicações do Azure, Gateway de Aplicação do Azure, Azure Front Door), configure estes serviços para recuperar automaticamente certificados atualizados do Key Vault utilizando identidades geridas ou princípios de serviço com políticas de acesso Key Vault apropriadas:
  • Os serviços do Azure associam automaticamente as novas versões dos certificados quando renovadas (normalmente dentro de 24 horas, sem necessidade de reinício do serviço).
• Para aplicações que não conseguem consumir automaticamente certificados do Key Vault, implemente fluxos de trabalho de rotação manual de certificados com guias operacionais e alertas de monitoramento para evitar interrupções relacionadas com a expiração.
• Mantenha um inventário de todos os certificados no Azure Key Vault, acompanhando o nome do certificado, finalidade, data de expiração, serviços dependentes e estado 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 Azure Monitor para eventos de expiração do 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 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 (desativar o certificado no Key Vault, notificar 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+ aplicações web públicas centralizou a gestão do ciclo de vida dos certificados usando o Azure Key Vault integrado com o DigiCert como sua Autoridade Certificadora.

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:

• Configurar a integração da autoridade certificadora com Azure Key Vault: Adicionar DigiCert (ou outra Autoridade Certificadora parceira) a Key Vault com credenciais API para pedidos automáticos de certificados.
• Criar políticas de certificado que apliquem normas de segurança: Definir a política de certificado com nome do certificado (www-contoso-com-2024), emitente (DigiCert), entidade (CN=www.contoso.com), nomes DNS (SAN: www.contoso.com, api.contoso.com, portal.contoso.com - evitar certificados curinga), tipo de chave (RSA 4096 bits), algoritmo de assinatura (SHA-256), período de validade (máximo de 397 dias conforme o padrão do CA/Browser Forum), configurar a ação de renovação automática (definir o acionador em 80% do tempo de vida do certificado, aproximadamente 318 dias para um certificado de 397 dias), ação: renovação automática (o Key Vault solicita a renovação ao DigiCert sem intervenção manual).
• Configurar a ligação automática de certificados para os serviços Azure: Para o Serviço de Aplicações do Azure, importar o certificado do Key Vault, atribuir uma identidade gerida atribuída pelo utilizador com a função de Utilizador de Segredos do Key Vault, ativar atualizações automáticas de certificados (o Serviço de Aplicação vincula a nova versão do certificado em 24 horas quando renovado, não é necessário reiniciar); para o Gateway de Aplicação do Azure, configurar o listener para recuperar o certificado do Key Vault, atribuir uma identidade gerida atribuída pelo utilizador com as funções de Utilizador de Segredos e Utilizador de Certificados do Key Vault, o Application Gateway recupera automaticamente o certificado atualizado quando o Key Vault o renova.
• Configurar alertas de expiração de certificados: Criar 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 um ticket do Jira para revisão manual e enviar email à equipa de segurança).
• Eliminar os certificados wildcard em favor dos certificados SAN: Auditar os certificados wildcard existentes (*.contoso.com) em Key Vault, substituir 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 são afetados (não todos os subdomínios).
• Monitorizar a expiração do certificado: Use Azure Resource Graph para consultar o inventário de certificados e identificar certificados próximos da expiração (dentro de 30 dias), certificados auto-assinados ou certificados usando o algoritmo de assinatura SHA-1 obsoleto, rever o painel trimestralmente durante 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 Aplicações do Azure e o Application Gateway recuperam certificados atualizados dentro de 24 horas através de identidades geridas (não é necessário reiniciar). 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 do 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 controlos de acesso para Key Vault

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:

• Implementar Azure RBAC para o Key Vault para aplicar o controlo de acesso com privilégio mínimo:
  • Para Azure Key Vault HSM Gerido: Utilize RBAC local ao nível individual de chaves, segredos e certificados com funções incorporadas (Oficial de Cripto do HSM Gerido, Utilizador de Cripto, Auditor de Cripto).
  • Para Azure Key Vault Standard/Premium: Crie cofres dedicados por aplicação ou ambiente para impor a separação lógica e atribuir funções RBAC (Administrador Key Vault, Oficial de Segredos, Oficial de Certificação) com âmbito específico da aplicação.
• 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:

• Utilize identidades geridas para recursos do Azure (Serviços de Aplicação, VMs, Funções do Azure, etc.) para aceder ao Key Vault, em vez de armazenar credenciais em código de aplicação ou ficheiros de configuração. As identidades gerenciadas eliminam a complexidade do armazenamento de credenciais e da rotação.
• Implementar Azure AD Privileged Identity Management (PIM) para acesso administrativo em tempo real ao Key Vault:
  • Configure atribuições elegíveis para a função de Administrador do Key Vault (não para 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 superfícies de ataque com exposição à internet encaminhando todo o acesso ao Key Vault através de endpoints privados dentro das suas redes virtuais, impedindo o preenchimento de credenciais, tentativas de força bruta e reconhecimento por atores de ameaça 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.

Implementar Private Link e configurar firewall:

• Acesso seguro à rede a Azure Key Vault usando Azure Private Link para estabelecer conectividade privada a partir de VNets sem expor Key Vault à internet pública.
• Configure Key Vault firewall para restringir o acesso a intervalos de IP específicos ou VNets para cenários onde Private Link não seja viável:
  • Desative o acesso público sempre que possível (o Key Vault só é acessível através de endpoint 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 monitorização do Key Vault

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. Implemente monitorização abrangente com o Microsoft Defender for Key Vault e Microsoft Sentinel para detetar padrões de acesso anómalos, operações invulgares de chaves e anomalias administrativas que indiquem comprometimento, ameaças internas ou atividades de reconhecimento direcionadas à sua infraestrutura criptográfica.

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

• Ative soft delete e purge protection em todos os Azure Key Vaults para evitar a eliminação acidental ou maliciosa 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.
  • Aplica estas definições com o Azure Policy usando políticas integradas: "Os cofres de chaves devem ter a eliminação suave ativada" e "Os cofres de chaves devem ter proteção contra purgas ativada" (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.
  • Criar e testar procedimentos Key Vault backup 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: RSA-HSM e EC-HSM chaves protegidas por HSMs validados Nível 2 FIPS 140-2 (multi-inquilino partilhado).
  • Azure Key Vault HSM Geridos: chaves RSA-HSM e EC-HSM protegidas por HSMs validados de Nível 3 FIPS 140-3 (pools dedicados de locatário único).
• Para cenários Bring Your Own Key (BYOK), gere chaves em HSMs FIPS 140-2 Nível 2+ on-premises e utilize o mecanismo de transferência de chave BYOK para importar chaves de forma segura para Azure Key Vault, mantendo provas criptográficas da origem e custódia da chave.

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

• Ative os registos de diagnóstico para o Azure Key Vault e encaminhe-os para o Azure Monitor, Log Analytics ou Microsoft Sentinel, para capturar todas as operações do plano de gestão e do plano de dados. Monitore atividades suspeitas, incluindo padrões incomuns de acesso a chaves, tentativas de autenticação com falha e alterações administrativas.
• Ative o Microsoft Defender para Key Vault, para detetar padrões de acesso anómalos, operações de chave invulgares, e potenciais ameaças, tais como abuso de credenciais, recuperações suspeitas de chaves ou anomalias administrativas. Integre alertas do Defender para Key Vault com fluxos de trabalho de resposta a incidentes.
• Integrar registos de Key Vault com Microsoft Sentinel para criar regras analíticas para detetar anomalias como acessos regionais invulgares, potenciais 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.

Nota: Todos os SKUs 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 simples fora do Azure Key Vault.

Exemplo de implementação

Uma empresa multinacional de tecnologia implementou segurança de defesa aprofundada para a sua infraestrutura Azure Key Vault, protegendo chaves de encriptação, segredos da API e certificados TLS para 500+ microserviços.

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:

• Implementar Cofres de Chaves dedicados para segmentação lógica: Criar Key Vault por ambiente e unidade de negócio com a convenção de nomes kv-{businessunit}-{environment}-{region} (por exemplo, kv-finance-prod-eastus2, kv-finance-dev-eastus2), implementar em grupos de recursos separados por ambiente para impor isolamento (o dev service principal comprometido não pode aceder a chaves de produção).
• Configure o RBAC para acesso de privilégio mínimo: Para Cofres de Chaves não produtivas (desenvolvimento/staging), atribua Utilizador de Segredos do Key Vault (apenas leitura) a grupos de segurança de programadores — os programadores podem ler segredos em desenvolvimento/staging, mas não têm acesso a Cofres de Chaves de produção; para os Cofres de Chaves de produção, atribua Utilizador de Segredos do Key Vault aos princípios de serviço de CI/CD (identidades geridas por pipeline do Azure DevOps) e limite o âmbito a segredos nomeados específicos; sem acesso interativo de programadores às chaves de produção.
• Reforçar a segurança de rede com Azure Private Link: Implementar endpoints privados para Key Vault (selecionar VNet e subrede, criar zona DNS privada privatelink.vaultcore.azure. net e ligação ao VNet), configurar o firewall Key Vault (desativar o acesso público com o Key Vault acessível apenas via endpoint privado, se o acesso público exigido para CI/CD permitir acesso a partir de redes selecionadas apenas com subredes Azure VNet aprovadas e intervalos de endereços IP de agentes CI/CD).
• Ativar o Microsoft Defender para Key Vault: Ative o Microsoft Defender para Key Vault ao nível da subscrição, para que o Defender possa monitorizar anomalias, incluindo acessos geográficos invulgares, enumerações suspeitas (operações de listagem rápidas que indicam reconhecimento) e operações administrativas anormais (como eliminações em massa de segredos).
• Integrar com o Microsoft Sentinel para resposta automática: Adicionar o conector de dados do Microsoft Defender para a Cloud ao Sentinel, criar regras Sentinel Analytics para acessos regionais invulgares, forças brutas potenciais e operações administrativas suspeitas, configurar livros de execução automática para desativar identidades suspeitas e notificar as equipas de segurança.
• Transmitir registos de diagnóstico para Log Analytics: Ativar registos de diagnóstico para Key Vault com AuditEvent (todas as operações de chave/segredo/certificado), AllMetrics (frequência de utilização, latência), enviar para o espaço de trabalho do Log Analytics com retenção de 2 anos, criar consultas KQL personalizadas para deteção de anomalias, incluindo a deteção potencial de ataques de força bruta (10+ tentativas não autorizadas em 5 minutos), operações de eliminação suave desativadas (indicador de sabotagem).
• Implementar o acesso administrativo Just-In-Time com Azure AD PIM: Configurar atribuições elegíveis para a função de Administrador do Key Vault (adicionar membros da equipa de segurança como Elegíveis e não permanentes, exigir justificação e a realização de Autenticação Multifator (MFA) para ativação de acesso, definir a duração máxima de ativação de 8 horas, exigir aprovação do arquiteto sénior de segurança), realizar revisões trimestrais de acesso para todas as atribuições de funções de Administrador do Key Vault. 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. Private Link elimina a exposição pública na 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