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 de dados completo. Implemente a descoberta e a classificação para estabelecer inventário de dados, criptografia para proteger dados em trânsito e em repouso e gerenciamento de chaves e certificados disciplinados para manter a integridade criptográfica. Essa abordagem em camadas se alinha com princípios de Confiança Zero e estratégias de defesa detalhadas.

Sem proteção abrangente de dados, as organizações enfrentam violações de dados, penalidades regulatórias e danos à reputação devido à 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 seus dados: Descubra informações confidenciais e aplique rótulos consistentes para habilitar controles baseados em risco.

Controles relacionados:

• DP-1: descobrir, classificar e rotular dados confidenciais
• DP-2: Monitorar anomalias e ameaças direcionadas a dados confidenciais

Proteger dados com criptografia: Implemente criptografia abrangente para dados em trânsito e em repouso usando padrões criptográficos modernos.

Controles relacionados:

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

Gerenciar a infraestrutura criptográfica: Estabeleça o gerenciamento de ciclo de vida disciplinado para chaves criptográficas e certificados com rotação automatizada e log de auditoria abrangente.

Controles relacionados:

• DP-6: usar um processo de gerenciamento de chave segura
• DP-7: usar um processo seguro de gerenciamento de certificados
• DP-8: garantir a segurança do repositório de chaves e certificados

DP-1: descobrir, classificar e rotular dados confidenciais

Azure Policy: Confira as definições de política internas do Azure: DP-1.

Princípio de 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 e exfiltração não autorizados.

Risco a mitigar

Os atores de ameaça 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) armazenado em locais não gerenciados (TI sombra) ignora os controles de criptografia, retenção ou monitoramento necessários.
• Acesso com privilégios excessivos: O amplo acesso de usuário/serviço persiste porque a confidencialidade e o impacto nos negócios não são identificados.
• Proliferação de réplicas: A replicação de dados para pipelines de análise de dados, teste ou exportação espalha conteúdo confidencial em ambientes de baixa confiança.
• Pontos cegos forenses: Os respondedores de incidentes não conseguem definir rapidamente a área de impacto devido a metadados de sensibilidade ausentes ou incorretos.
• Falha de automação: A governança (DLP, acesso condicional, fluxos de trabalho de criptografia) falha ao disparar sem rotulagem consistente.

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

MITRE ATT&CK

• Reconhecimento (TA0043): coleta de identidade da vítima/ativos de dados (T1596) ao enumerar contas de armazenamento, catálogos de esquemas e metadados de classificação, a fim de perfilar repositórios de alto valor.
• Descoberta (TA0007): enumeração de conta e permissão (T1087, T1069) para revelar associações de função excessivas que permitem escalonamento horizontal ou vertical de acesso a dados.
• Coleção (TA0009): dados do armazenamento em nuvem (T1530) extraindo contêineres de blob sem rótulo ou exportações não gerenciadas sem marcas de acompanhamento.
• Exfiltração (TA0010): exfiltração por serviços Web (T1567) por meio de pontos de extremidade de exportação ad hoc em que os portões de rotulagem/política estão ausentes.
• Exfiltração (TA0010): exfiltração automatizada (T1020) usando paginação e loop automatizados por script para coletar silenciosamente conjuntos de dados mal classificados.

DP-1.1: descobrir, classificar e rotular dados confidenciais

Use o Microsoft Purview para criar um mapa de dados abrangente que descubra, classifique e rotule automaticamente informações confidenciais em todo o seu patrimônio de dados. Estenda a proteção além da criptografia em nível de infraestrutura implementando a Proteção de Informações do Microsoft Purview para aplicar a criptografia persistente no nível do documento e os direitos de uso que seguem os dados onde quer que eles viajem. Essa funcionalidade 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 confidencialidade de dados e não apenas na localização.

Descoberta e classificação de dados:

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

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

• Implante a Proteção de Informações do Microsoft Purview para aplicar direitos persistentes de criptografia e uso a documentos e emails com base em rótulos de confidencialidade. Configure rótulos para criptografar arquivos automaticamente, aplicar marcas d'água, restringir o encaminhamento, definir datas de validade e revogar o acesso mesmo após os dados deixarem sua organização.
• Habilite o Azure RMS (Serviço de Gerenciamento de Direitos do Azure) como a tecnologia de proteção subjacente que criptografa documentos e emails com políticas de uso (somente exibição, sem cópia, sem impressão) que persistem independentemente de onde os dados são armazenados ou compartilhados.

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

• Para bancos de dados SQL do Azure, habilite a Descoberta e Classificação de Dados SQL para identificar, classificar e rotular colunas contendo dados confidenciais, como números de cartão de crédito, números de segurança social ou registros de integridade.
• Integrar metadados de classificação com controles downstream: configurar políticas de Prevenção contra Perda de Dados (DLP) no Microsoft Purview, aplicar regras de acesso condicional na ID do Entra e impor políticas de criptografia com base em rótulos de confidencialidade.
• Estabeleça um agendamento de verificação regular para descobrir continuamente ativos de dados confidenciais recém-criados ou modificados à medida que seu patrimônio de dados evolui.

Exemplo de implementação

Uma organização global de serviços financeiros implantou o Mapa de Dados do Microsoft Purview para descobrir e classificar dados confidenciais automaticamente em mais de 200 contas de Armazenamento do Azure, 50 bancos de dados SQL e workspaces do Synapse Analytics.

Desafio: A organização não tinha visibilidade de onde os dados confidenciais residiam em seu acervo de dados do Azure em rápido crescimento. A classificação manual de dados era inconsistente, atrasou a imposição de governança e criou lacunas de conformidade. Sem a descoberta automatizada, os dados regulamentados (PHI, PII, PCI) permaneceram desprotegidos em locais não gerenciados e as políticas de prevenção contra perda de dados não puderam ser disparadas adequadamente.

Abordagem da solução:

• Implantar o Mapa de Dados do Microsoft Purview para descoberta de dados: Crie uma conta do Purview e registre fontes de dados (contas de Armazenamento do Azure, bancos de dados SQL, workspaces do Synapse Analytics), configure o Mapa de Dados para escanear fontes usando autenticação de identidade gerenciada e conceda à identidade de verificação permissões de leitura (função db_datareader) para catalogar esquemas e detectar colunas confidenciais.
• Configurar a detecção de classificação e confidencialidade: Configurar regras de verificação para detectar padrões confidenciais (SSN, números de cartão de crédito, números de registro médico, códigos SWIFT), definir regras de classificação personalizada alinhadas com a política de classificação de dados ("Confidencial – Interno" para dados confidenciais de negócios, "Altamente Confidencial - Regulado" para dados PHI/PCI/PII), configurar limites de rotulagem automática (aplicar "Altamente Confidencial" quando ≥3 padrões de PII detectados em um único ativo), estabelecer agendas de verificação com base na criticidade de dados (semanalmente para produção, mensalmente para arquivos), configure alertas para notificar as equipes de segurança quando novos dados de alta confidencialidade forem descobertos.
• Implante a Proteção de Informações do Microsoft Purview para criptografia em nível de documento: Crie rótulos de confidencialidade no portal de conformidade do Purview com configurações de proteção (Público: sem criptografia, somente marcações visuais; Interno: marca d'água, sem restrições de encaminhamento; Confidencial: criptografar com o Azure RMS, permitir exibição/edição somente para funcionários, bloquear encaminhamento/impressão; Altamente Confidencial – Regulamentado: criptografar com o Azure RMS, acesso somente exibição, sem cópia/impressão/encaminhamento, expiração de 90 dias, acesso revogável), publique rótulos de confidencialidade aos usuários por meio de políticas de rótulo (escopo: finanças, jurídicos, departamentos executivos), configure políticas de rotulagem automática para aplicar automaticamente rótulos (≥10 SSNs → "Altamente Confidencial – Regulamentado", ≥5 números de cartão de crédito → "Altamente Confidencial – Regulamentado"), habilite a proteção do Azure RMS para documentos rotulados armazenados no SharePoint, configure a rotulagem do lado do cliente para as contas do OneDrive e do Armazenamento do Azure para aplicativos do Office para solicitar que os usuários classifiquem documentos antes de salvar/enviar.

Resultado: A verificação automática do Mapa de Dados do Purview identificou mais de 15.000 ativos de dados que contêm dados regulamentados na primeira semana, reduzindo o tempo de descoberta de meses para dias. A rotulagem automática da Proteção de Informações aplicou criptografia a 8.500 documentos em 72 horas. Os rótulos de confidencialidade habilitaram a visibilidade contínua do conjunto de dados e a proteção persistente, mesmo quando os dados são movidos para dispositivos não gerenciados.

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: Monitorar anomalias e ameaças direcionadas a dados confidenciais

Azure Policy: Confira as definições de política internas do Azure: DP-2.

Princípio de segurança

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

Risco a mitigar

Adversários e insiders mal-intencionados tentam exfiltrar, preparar ou investigar dados confidenciais usando comportamentos furtivos ou de baixo sinal. Sem monitoramento contínuo de anomalias ciente do contexto vinculado à sensibilidade dos dados:

• Exfiltração silenciosa: Exportações em massa, conjuntos de resultados grandes ou sifonamento incremental passam despercebidos devido à falta de linhas de base.
• Uso indevido de pessoal interno: As credenciais legítimas executam sequências incomuns (hora do dia, volume, localidade) que ignoram o monitoramento superficial.
• Preparo e enumeração: Os invasores mapeiam esquemas/rótulos para priorizar destinos de alto valor antes da extração em massa.
• Consultas de vida fora da terra: As ferramentas administrativas padrão mascaram o reconhecimento em ruído operacional normal.
• Evasão entre repositórios: O acesso distribuído em vários serviços evita limites de repositório único e correlação.

A detecção inadequada de anomalias corroe a eficácia da resposta a incidentes e permite o escalonamento do reconhecimento para a exfiltração em larga escala com o mínimo de atrito.

MITRE ATT&CK

• Coleção (TA0009): dados do armazenamento em nuvem (T1530) por meio de leituras anômalas em massa ou com alta difusão em contêineres confidenciais.
• Acesso à Credencial (TA0006): contas válidas (T1078) abusando de credenciais comprometidas ou internas para mesclar com linhas de base de tráfego legítimas.
• Exfiltração (TA0010): exfiltração automatizada (T1020) usando consultas com script restritas projetadas para evitar limites de alerta.
• Exfiltração (TA0010): exfiltração para armazenamento em nuvem (T1567.002), preparando dados em regiões ou contas controladas por invasores para recuperação posterior.
• Comando & Controle/Exfiltração (TA0011/TA0010): protocolo da camada de aplicação (T1071) encaminhando dados sensíveis por meio de chamadas normais de BD/API.
• Descoberta (TA0007): descoberta de sistema/serviço (T1082, T1046) enumerando pontos de extremidade para mapear caminhos de movimentação lateral para repositórios de valor mais alto.

DP-2.1: habilitar a detecção de ameaças para serviços de dados

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

Habilitar a detecção de ameaças para serviços de dados:

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

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

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

Implantar controles de risco interno e DLP:

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

Configurar monitoramento e resposta:

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

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

Exemplo de implementação

Um provedor de serviços de saúde habilitou o Microsoft Defender para Armazenamento e o Defender para SQL para monitorar anomalias e ameaças direcionadas a dados de pacientes em contas do Armazenamento do Azure e bancos de dados SQL.

Desafio: A organização experimentou pontos cegos na detecção de tentativas de acesso e exfiltração de dados não autorizadas. Defesas de perímetro tradicionais falharam em detectar ameaças internas e principais de serviço comprometidos realizando downloads em massa. Sem a análise comportamental e a detecçã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 espera.

Abordagem da solução:

• Habilitar o Microsoft Defender para Armazenamento: Habilite o Defender para Armazenamento no nível de assinatura para contas de armazenamento que contêm dados confidenciais, configure a verificação de malware para detectar e colocar arquivos mal-intencionados em quarentena no armazenamento de blobs, habilite a detecção de ameaças de dados confidenciais usando tipos de informações confidenciais do Purview para identificar padrões de PHI/PII, definir limites de verificação por transação ou limites mensais para controlar os custos, aplicar proteção a grupos de recursos que contêm contas de armazenamento de produção que hospedam imagens médicas e exportações de EHR.
• Habilite o Microsoft Defender para SQL: Habilite o Defender para SQL no nível de assinatura do Banco de Dados SQL do Azure e da Instância Gerenciada de SQL, configure a Avaliação de Vulnerabilidade com verificações recorrentes e designe a conta de armazenamento para resultados de verificação, configure notificações por email para alertar a equipe de segurança de vulnerabilidades identificadas, habilite a Proteção Avançada contra Ameaças para detectar tentativas de injeção de SQL, padrões de consulta incomuns, acesso anômalo de regiões desconhecidas, e exfiltração de dados em potencial.
• Integre-se ao Microsoft Sentinel: Conecte o Microsoft Defender para Nuvem ao Microsoft Sentinel usando o conector de dados, defina as configurações de diagnóstico (habilite logs de diagnóstico para operações de armazenamento e logs de auditoria do SQL, encaminhe para o workspace do Log Analytics), crie regras do Sentinel Analytics para detectar anomalias (alertas de download em massa para downloads >de 10 GB em 1 hora, acesso de banco de dados fora do horário comercial, padrões de consulta suspeitos), configure guias estratégicos de resposta automatizados para isolar identidades comprometidas, revogar o acesso ao armazenamento e notificar as equipes de segurança.
• Implante o Gerenciamento de Risco Interno do Microsoft Purview para detecção de ameaças comportamentais: Habilite o Gerenciamento de Risco Interno e configure modelos de política (deteção de roubo de dados por usuários prestes a sair, verificando downloads de arquivos incomuns de 30 a 90 dias antes da saída, monitoramento de vazamentos de dados gerais ao copiar para armazenamento USB/nuvem, vazamentos de dados por usuários prioritários com monitoramento aprimorado para funções de alto privilégio); configure indicadores de risco e limites (alertas de volume cumulativo de downloads de arquivos, picos de acessos fora do horário de expediente, detecção de sequência combinando múltiplos sinais de risco); integre fontes de dados (Logs de Atividades do Azure, logs de auditoria do Microsoft 365, Defender para Aplicativos de Nuvem, sistemas de RH, eventos DLP de endpoint); configure o fluxo de trabalho de triagem para direcionar alertas de média/alta gravidade para uma fila de investigação dedicada.

Resultado: O Defender para Armazenamento detectou 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 detecção de dias para menos de 15 minutos. O Insider Risk Management sinalizou um funcionário de partida baixando dados de pesquisa significativamente acima da linha de base pessoal para o armazenamento em nuvem pessoal, 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: Confira as definições de política internas do Azure: DP-3.

Princípio de segurança

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

Risco a mitigar

Canais de rede não criptografados ou protegidos de maneira fraca expõem dados confidenciais à interceptação, manipulação e degradação intencional. Sem criptografia de transporte moderna imposta (TLS 1.2+):

• Interceptação passiva: Observadores de rede capturam credenciais, tokens, conteúdos de API ou dados regulamentados em texto sem formatação.
• Homem no meio: Os invasores alteram consultas, injetam cargas ou coletam material de sessão.
• Downgrade de protocolo: O fallback herdado (SSL/TLS < 1.2, HTTP/FTP de texto não criptografado) permite a exploração de conjuntos de criptografia obsoletos.
• Sequestro de sessão: A falta de integridade do canal permite a reprodução de tokens ou o roubo de cookies para movimentação lateral.
• Manipulação de integridade: A adulteração corrompe a análise ou dispara transações fraudulentas.
• Caminhos laterais opacos: O tráfego de texto em claro interno torna-se material de reconhecimento após uma invasão.

A falha ao impor criptografia forte em trânsito amplifica o impacto do vazamento de dados, acelera o comprometimento de credenciais e prejudica os pressupostos de confiança zero.

MITRE ATT&CK

• Acesso a Credenciais (TA0006): credenciais desprotegidas (T1552) interceptadas durante sessões TLS com texto plano ou rebaixadas, expondo material de sessão/tokens.
• Coleção (TA0009): T1040 (detecção de rede) colhendo cargas de API e segredos que atravessam caminhos fracos de criptografia ou texto limpo.
• Exfiltração (TA0010): exfiltração de dados estruturados via serviços web (T1567) por streaming através de pontos de extremidade de API legítimos.
• Evasão de Defesa (TA0005): adversário no meio (T1557) forçando o downgrade do TLS ou inserindo proxies de interceptação para exibir/modificar o tráfego.
• Comando & Controle (TA0011): protocolo fora da camada de aplicação (T1095) revertendo para meios de transporte legados ou menos inspecionados para contornar o monitoramento.

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

Estabeleça padrões modernos de segurança de camada de transporte em todos os serviços voltados para o cliente e plataformas de dados para proteger contra ataques de interceptação, adulteração e ataques de intermediário. Imponha o uso mínimo do TLS 1.2 ou 1.3 em armazenamento, aplicativos web, bancos de dados e gateways de API, desabilitando simultaneamente protocolos herdados e conjuntos de cifras fracas que expõem os dados a ataques de downgrade criptográfico.

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

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

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

DP-3.2: Proteger protocolos de acesso remoto e transferência de arquivos

Elimine o acesso administrativo de texto sem formatação e os protocolos de transferência de arquivo 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 rote o acesso privilegiado por meio de bastiões centralizados para eliminar a exposição direta à Internet de interfaces de gerenciamento.

Proteger protocolos de gerenciamento remoto:

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

Protocolos de transferência de arquivo seguros:

• Para operações de transferência de arquivo, use protocolos seguros e desabilite alternativas herdadas:
  • Use o suporte a SFTP no Armazenamento de Blobs do Azure (requer namespace hierárquico).
  • Use o FTPS no Serviço de Aplicativo do Azure e no Azure Functions.
  • Desabilite o protocolo FTP herdado (texto não criptografado).
• Use o Azure Policy para impor políticas de transferência seguras em seu ambiente e monitorar a conformidade para os requisitos de versão do TLS.

Exemplo de implementação

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

Desafio: Protocolos TLS 1.0/1.1 herdados e conjuntos de criptografias fracas expuseram dados de pagamento do cliente a ataques de interceptação. A imposição inconsistente do TLS através das camadas de aplicativo criou brechas de segurança nas quais os invasores poderiam rebaixar as conexões. Sem imposição centralizada da política de TLS, o desvio de configuração manual permitiu que protocolos inseguros persistissem em produção.

Abordagem da solução:

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

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

Nível de criticidade

Deve ter.

Mapeamento de controle

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

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

Azure Policy: Confira as definições de política internas do Azure: DP-4.

Princípio de segurança

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

Risco a mitigar

Camadas de armazenamento não criptografadas ou criptografadas seletivamente permitem que invasores com acesso fora de banda (comprometimento de infraestrutura, mídia roubada, abuso de instantâneo) coletem dados confidenciais em escala. Sem criptografia padrão:

• Coleta de dados de mídia bruta: Discos roubados, backups ou instantâneos não gerenciados expõem conjuntos de dados de texto sem formatação completos.
• Erosão de limite de privilégios: Administradores de plataforma ou agentes host comprometidos podem ler dados de locatário sem segregação criptográfica.
• Cópia silenciosa &exfiltração: Réplicas não criptografadas (teste, análise, exportação) tornam-se canais de exfiltração de baixo atrito.
• Violação de integridade: Os invasores modificam dados inativos (DLLs mal-intencionadas, configuração ou dados de referência) para disparar um comprometimento em estágio posterior.
• Não conformidade regulatória: A falta de criptografia sistêmica prejudica as garantias necessárias para muitas certificações do setor.
• Exposição de recuperação sem uso de chaves: Imagens de recuperação de desastre e arquivos arquivados a frio retêm conteúdo confidencial indefinidamente em texto legível recuperável.

Não impor a criptografia em repouso universalmente aumenta a escala de violações, 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.
• Evasão de Defesa (TA0005): remoção de indicador (T1070) edição ou limpeza de logs após a mídia offline/acesso de instantâneo.
• Impacto (TA0040): destruição de dados (T1485) corrompendo ativos inativos não criptografados para interromper processos downstream.
• Impacto (TA0040): inibir 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 a criptografia de dados em repouso por padrão

Verifique se todos os dados armazenados no Azure são criptografados em repouso para proteger contra acesso não autorizado contra comprometimento de infraestrutura, mídia roubada ou instantâneos não autorizados. Embora a maioria dos serviços do Azure habilite a criptografia por padrão, verifique a cobertura entre máquinas virtuais, contas de armazenamento e bancos de dados e habilite camadas de criptografia adicionais (criptografia no host, criptografia de infraestrutura, computação confidencial e criptografia em nível de coluna) para cargas de trabalho altamente confidenciais atenderem aos requisitos de soberania de dados e regulamentação.

Habilitar a criptografia para VMs e armazenamento:

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

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

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

Monitorar e impor a conformidade de criptografia:

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

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

Exemplo de implementação

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

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

Abordagem da solução:

• Habilitar criptografia no host para máquinas virtuais do Azure: Registre o recurso EncryptionAtHost no nível da assinatura, habilite a criptografia no host para VMs usando tamanhos de VM compatíveis (série DSv3, Easv4, Dadsv5), criptografia abrange discos temporários, cache de disco do sistema operacional, cache de disco de dados e discos do sistema operacional efêmero.
• Habilite a criptografia de infraestrutura (criptografia dupla) para o Armazenamento do Azure: Verifique se a SSE (Criptografia do Serviço de Armazenamento do Azure) está habilitada (ativada por padrão — criptografia AES-256), para contas de armazenamento confidenciais habilitar a criptografia de infraestrutura durante a criação da conta de armazenamento (não pode ser habilitada após a criação), resultado: duas camadas de criptografia AES-256 com chaves diferentes.
• Implantar VMs confidenciais do Azure para cargas de trabalho altamente regulamentadas: Selecione a série de VM confidencial apropriada (série DCasv5/DCadsv5 para AMD SEV-SNP ou série ECasv5/ECadsv5 para Intel TDX), habilite a criptografia de disco confidencial com chave gerenciada por plataforma (associa chaves de criptografia de disco ao TPM virtual da VM), habilite a Inicialização Segura e o vTPM para atestado, implantação para cargas de trabalho que processam dados técnicos controlados por exportação ou PII altamente regulamentada, em que os dados devem permanecer criptografados durante o processamento.
• Implementar o Always Encrypted para colunas de banco de dados confidenciais: Identificar colunas altamente confidenciais no Azure SQL Database que exigem criptografia de nível de coluna (SSN, Número do Cartão de Crédito, Número do Registro Médico), gerar chaves de criptografia de coluna (CEK) e chaves mestras de coluna (CMK) armazenando a CMK no Azure Key Vault com a CEK criptografando colunas de dados e a CMK criptografando a CEK, habilitar o Always Encrypted com enclaves seguros (Intel SGX) para permitir consultas mais avançadas em dados criptografados, criptografar colunas confidenciais usando criptografia determinística (para pesquisas de igualdade) ou criptografia aleatória (segurança máxima), configurar cadeias de conexão de aplicativo com a configuração de criptografia de coluna definida como 'Enabled' para criptografia/descriptografia transparente.
• Configurações de criptografia de inventário com o Azure Resource Graph: Consultar o status de criptografia para VMs sem criptografia no host e contas de armazenamento sem criptografia de infraestrutura, exportar resultados para CSV e atribuir tarefas de correção aos proprietários de recursos.

Resultado: A criptografia no host abordou lacunas de conformidade em que os dados de disco temporário não foram criptografados anteriormente. Arquivos de engenharia protegidos por infraestrutura criptografada, com duas camadas de criptografia. As VMs confidenciais garantiram que os dados controlados pela exportação permanecessem criptografados mesmo para administradores de nuvem. Colunas de banco de dados confidenciais protegidas pelo Always Encrypted — os administradores de banco de dados confirmaram a incapacidade de ler texto em claro de colunas criptografadas, atendendo aos 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: usar a opção de chave gerenciada pelo cliente na criptografia de dados em repouso quando necessário

Azure Policy: Confira as definições de política internas do Azure: DP-5.

Princípio de segurança

Use chaves gerenciadas pelo cliente quando a conformidade regulatória, os requisitos contratuais ou a confidencialidade de dados exigem controle direto sobre o ciclo de vida da chave de criptografia, incluindo geração de chave, rotação e autoridade de revogação. Verifique se os processos de gerenciamento de chaves adequados estão em vigor para lidar com a sobrecarga operacional.

Risco a mitigar

Depender apenas de chaves gerenciadas pelo serviço onde garantias regulatórias, contratuais ou de segregação exigem o controle do locatário pode introduzir riscos de conformidade e concentração. Sem CMK (chaves gerenciadas pelo cliente) corretamente governadas:

• Garantia regulatória inadequada: Os auditores poderão rejeitar evidências de controle criptográfico se a custódia da chave, a cadência de rotação ou a autoridade de revogação não puderem ser demonstradas.
• Latência de revogação: A incapacidade de revogar ou alternar rapidamente as chaves da plataforma comprometidas estende a janela de exposição após eventos de credenciais ou da cadeia de suprimentos.
• Exposição jurisdicional: Os mandatos de soberania de dados podem exigir chaves operadas pelo locatário ou apoiadas por HSM— a ausência prejudica a viabilidade da implantação regional.
• Raio de explosão entre locatários distintos: O comprometimento de chave em plataformas multilocatárias pode afetar amplos conjuntos de dados em caso de insuficiência do isolamento criptográfico.
• Proliferação de sombras: Implantações de CMK ad hoc sem governança de ciclo de vida levam a chaves obsoletas, órfãs ou fracas.
• Fragilidade operacional: A automação de rotação ruim ou o mapeamento de dependência ausente causam interrupções no funcionamento do aplicativo durante o processo de substituição de chave.

O uso inadequado ou omitido do CMK enfraquece a garantia criptográfica e prejudica o posicionamento de conformidade estratégica para cargas de trabalho confidenciais.

MITRE ATT&CK

• Acesso à Credencial (TA0006): credenciais desprotegidas (T1552) expostas por chaves de plataforma fracamente protegidas ou segmentadas incorretamente.
• Impacto (TA0040): dados criptografados para impacto (T1486) abusando da rotação/revogação do CMK para tornar os dados inacessíveis.
• 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 de nuvem (T1537) criptografando e exportando conjuntos de dados novamente para o armazenamento controlado pelo invasor.
• Exfiltração (TA0010): exfiltração em serviços Web (T1567) orquestrando exportações em massa com habilitação de chave para alto volume dentro de padrões normais de serviço.

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

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

Avalie os requisitos do CMK e provisione a infraestrutura de chave:

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

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

• Para requisitos de controle extremo, implemente a DKE (Criptografia de Chave Dupla), em que documentos confidenciais exigem duas chaves para descriptografia: uma gerenciada pela Microsoft (Azure RMS) e uma segunda chave gerenciada exclusivamente por sua organização local ou em seu próprio serviço de gerenciamento de chaves externas. Com o DKE, a Microsoft não pode descriptografar seus dados mesmo que sejam obrigados pelo processo legal, pois você controla a segunda chave necessária para descriptografia.
• Configure os serviços do Azure (Armazenamento do Azure, Banco de Dados SQL do Azure, Azure Cosmos DB, Azure Disk Encryption etc.) para usar o CMK fazendo referência ao URI da chave do Key Vault. Habilite políticas de rotação automática de chaves para reduzir a carga operacional manual.
• Estabeleça uma hierarquia de chave de criptografia de chave (KEK) e de chave de criptografia de dados (DEK), onde o KEK (armazenado no Vault de Chaves) criptografa o DEK (usado pelos serviços) e minimiza o impacto da rotação de chaves na disponibilidade do serviço.
• Documente os principais procedimentos de ciclo de vida, incluindo agendamentos de rotação de chaves, processos de revogação para chaves comprometidas, fluxos de trabalho de aposentadoria de chaves e procedimentos de recuperação de desastre. Integre o gerenciamento de chaves aos processos de gerenciamento de alterações organizacionais.

Nota: As chaves gerenciadas pelo cliente exigem investimentos operacionais contínuos, incluindo gerenciamento de ciclo de vida chave, administração de controle de acesso, monitoramento e planejamento de recuperação de desastres. Verifique a preparação operacional antes de adotar o CMK, pois o gerenciamento inadequado de chaves pode resultar em indisponibilidade ou perda de dados.

Exemplo de implementação

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

Desafio: Os auditores regulatórios exigiram controle criptográfico demonstrado, incluindo custódia de chave, 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 controlado pelo inquilino. Sem chaves gerenciadas pelo cliente, a organização não tinha capacidade de revogar rapidamente o acesso durante incidentes de segurança e não conseguia atender aos requisitos de soberania de dados para implantações regionais.

Abordagem da solução:

• Provisionar o HSM Gerenciado do Azure Key Vault: Crie o HSM Gerenciado (FIPS 140-3 Nível 3 validado) com no mínimo 3 partições de HSM para alta disponibilidade, ative o HSM Gerenciado exportando o domínio de segurança com chaves de quórum (divididas em fragmentos de chave armazenados em cofres offline distribuídos geograficamente), gere chaves de criptografia (RSA-4096 denominada KEK-Prod-2024) com operações de chave: Encapsular, Desencapsular, Criptografar, Descriptografar.
• Configurar chaves gerenciadas pelo cliente para os serviços do Azure: Para o Armazenamento do Azure, configure a conta de armazenamento para usar o tipo de criptografia CMK, selecione o HSM Gerenciado do Key Vault como fonte de chave, ative a identidade gerenciada atribuída pelo usuário com a função de Usuário de Criptografia do Serviço HSM Gerenciado; para o Banco de Dados SQL do Azure, configure o Banco de Dados SQL para usar a chave gerenciada pelo cliente como protetor de TDE, selecione a chave no HSM Gerenciado, ative a rotação automática de chaves; para o Azure Cosmos DB, habilite as chaves gerenciadas pelo cliente para a conta do Cosmos DB, selecione a chave HSM gerenciada e conceda acesso à identidade gerenciada do Cosmos DB.
• Implementar rotação automatizada de chaves: Configure a política de rotação com frequência de rotação de 90 dias, habilite a rotação automática, configure a notificação de expiração (alerta 7 dias antes da expiração), crie um alerta do Azure Monitor para a métrica Key Near Expiry para notificar a equipe de segurança.
• Habilite o log de auditoria para conformidade: Habilite o log de diagnóstico para HSM Gerenciado (logs AuditEvent), envie logs para o workspace do Log Analytics com armazenamento imutável (retenção de 90 dias para trilhas de auditoria à prova de adulteração), consulte os logs de acesso de chaves para monitorar as operações Encrypt, Decrypt, WrapKey e UnwrapKey.
• Documentar os procedimentos do ciclo de vida da chave: Crie runbooks para revogação de emergência (incluindo etapas para revogar chaves, contatos para resposta a incidentes, procedimentos de recuperação usando chaves de quórum do domínio de segurança), teste os runbooks trimestralmente através de exercícios simulados, integre as operações do Gerenciamento de Chaves Mestras (CMK) ao fluxo de trabalho de aprovação de mudanças do Gerenciamento de Serviços de TI.

Resultado: As KEKs RSA-4096 no HSM Gerenciado criptografam as DEKs do nível de serviço para Armazenamento do Azure, Banco de Dados SQL e Cosmos DB. A rotação automatizada trimestral minimiza o tempo de inatividade recriptografando apenas os DEKs. O quorum do domínio de segurança garante a recuperação de desastre mesmo com falha regional completa.

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: Confira as definições de política internas do Azure: DP-6.

Princípio de segurança

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

Risco a mitigar

Ciclos de vida de chave criptográfica fracos ou não gerenciados degradam a garantia fornecida pela criptografia e podem habilitar o comprometimento sistêmico. Sem geração estruturada de chave, rotação, proteção e revogação:

• Expansão e orfanato de chaves: As chaves não rastreadas persistem além da necessidade de negócios, retendo a autoridade de descriptografia não intencional.
• Criptografia obsoleta: A rotação pouco frequente aumenta a exposição a downgrade algorítmico, ataques de força bruta ou avanços em canais laterais.
• Exceder privilégios: A falta de separação de função permite que os administradores gerenciem e usem chaves, possibilitando o uso indevido por usuários internos.
• Comprometimento não detectado: Nenhum monitoramento de integridade ou linhagem de versão obscurece se as chaves foram substituídas maliciosamente.
• Revogação falhou: A resposta a incidentes não consegue criptograficamente conter o acesso a dados após uma suspeita de violação.
• Hierarquia inconsistente: A camada KEK/DEK ausente multiplica o raio da explosão de rotação e aumenta o tempo de inatividade operacional.

O gerenciamento de chaves deficientes transforma a criptografia em um controle pontual em vez de uma mitigação sustentada contra ameaças em evolução.

MITRE ATT&CK

• Acesso à Credencial (TA0006): credenciais de repositórios de senhas (T1555) extraindo material de chave armazenado incorretamente ou armazenado em cache ou contas válidas (T1078) explorando funções RBAC de gerenciamento de chaves amplas para acessar ou girar chaves de forma ilegítima.
• Evasão de Defesa (TA0005): enfraquecer a criptografia (T1600) retendo algoritmos preteridos/tamanhos de chave insuficientes para reduzir a força criptográfica.
• Impacto (TA0040): destruição de dados (T1485) ao executar purga destrutiva ou em eventos de revogação mal administrados.
• 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 políticas de gerenciamento de chaves e infraestrutura

Crie uma base de governança para o gerenciamento de chaves criptográficas estabelecendo o armazenamento centralizado de chaves, definindo padrões criptográficos e selecionando níveis de proteção apropriados com base na sensibilidade da carga de trabalho. Implante o Azure Key Vault como a única fonte de verdade para operações de chaves, implementando o log de auditoria abrangente para acompanhar todo o acesso às chaves e alterações administrativas para fins de conformidade e forense.

Estabelecer infraestrutura centralizada de gerenciamento de chaves:

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

Escolha a camada apropriada do cofre de chaves:

• Escolha a camada apropriada do Key Vault com base nos requisitos de segurança e conformidade da carga de trabalho:
  • Chaves protegidas por software (SKUs Standard &Premium): FIPS 140-2 Nível 1 validado
  • Chaves protegidas por HSM (SKU Premium): FIPS 140-2 Nível 2 validado (backend HSM multitenant compartilhado)
  • HSM gerenciado: FIPS 140-3 Nível 3 validado (pool de HSM dedicado a um único locatário)
• Para obter segurança aprimorada, use o HSM Gerenciado do Azure Key Vault para proteção de HSM validada de Nível 3 do FIPS 140-3 para locatário único. O HSM gerenciado dá suporte ao domínio criptográfico para backup e recuperação de desastre.
• Configure os logs do Azure Key Vault e encaminhe-os para o Azure Monitor ou o Microsoft Sentinel para monitorar todo o acesso a chaves, eventos de rotação e operações administrativas, visando auditoria e conformidade.

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

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

Implementar rotação automatizada de chaves:

• Implementar políticas automatizadas de rotação de chaves no 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 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.

Estabelecer hierarquia de chaves e BYOK:

• Estabeleça uma hierarquia de chaves que separa Chaves de Criptografia de Chave (KEK) e Chaves de Criptografia de Dados (DEK):
  • Armazene KEKs no Azure Key Vault com controles de acesso restritos.
  • Gere DEKs de nível de serviço, criptografados por KEKs, minimizando o raio de explosão da rotação de chaves.
  • Girar o KEK requer apenas criptografar novamente DEKs (não conjuntos de dados inteiros), permitindo uma rotação eficiente de chaves sem tempo de inatividade.
• Para cenários Bring Your Own Key (BYOK), gere chaves em HSMs locais de Nível 2+ FIPS 140-2 e use o mecanismo de chave de transferência BYOK para importar chaves com segurança para o Azure Key Vault ou HSM gerenciado, mantendo a comprovação criptográfica de origem e posse das chaves.

Implementar procedimentos de recuperação de desastre:

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

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

Evite ameaças internas e abuso de privilégios separando as funções de gerenciamento de chaves das funções de operação criptográfica, garantindo que nenhuma identidade única possa tanto criar chaves quanto usá-las para criptografar ou descriptografar dados. Implemente o monitoramento contínuo para detectar padrões de acesso importantes anômalos e manter inventários importantes abrangentes que permitem a avaliação de impacto rápido durante incidentes de segurança ou auditorias de conformidade.

Impor a separação de tarefas:

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

Monitore o acesso à chave e mantenha o inventário:

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

Exemplo de implementação

Um provedor de SaaS de saúde centralizou o gerenciamento de chaves criptográficas usando o SKU Premium do Azure Key Vault com chaves protegidas por HSM para criptografar Informações de Saúde Protegidas (PHI) em sua plataforma multilocatário.

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

Abordagem da solução:

• Provisione o Azure Key Vault Premium com chaves protegidas por HSM: Crie o Azure Key Vault com a camada Premium para dar suporte a chaves protegidas por HSM, habilite a proteção contra limpeza para evitar a exclusão permanente durante o período de retenção, habilite a exclusão reversível com retenção de 90 dias para permitir a recuperação de chaves excluídas acidentalmente, gere chaves de criptografia protegidas por HSM RSA-3072 (KEK-PHI-Prod) com tipo de chave com suporte de hardware.
• Implementar políticas automatizadas de rotação de chaves: Configure a política de rotação com frequência de rotação de 180 dias, habilite a rotação automática e defina a notificação como alerta 30 dias antes da expiração, crie grupos de ações do Azure Monitor para notificar a equipe de operações de segurança quando as chaves se aproximarem da expiração, configurar a ação de rotação para gerar automaticamente novas versões de chave.
• Configurar a separação de tarefas do RBAC: Atribua a função de Agente de Criptografia do Key Vault aos membros da equipe de segurança (permissões: gerenciar o ciclo de vida da chave, mas não pode executar operações de criptografia/descriptografia), atribuir a função de Usuário de Criptografia do Key Vault a identidades gerenciadas pelo aplicativo (permissões: executar operações criptografadas/descriptografar somente sem permissões de gerenciamento de chaves), verifique a separação de funções garantindo que nenhuma identidade tenha funções de Crypto Officer e Crypto User.
• Estabeleça a hierarquia KEK/DEK para rotação rápida de chaves: Gere DEKs (Chaves de Criptografia de Dados) no nível do aplicativo no código do aplicativo (chaves AES-256) para criptografar dados de pacientes, armazenar DEKs criptografados juntamente com dados criptografados, usar o KEY Vault KEK para encapsular/criptografar DEKs por meio da operação WrapKey, recuperar e desembrulhar o DEK usando a operação UnwrapKey ao descriptografar dados do paciente, benefício: girar KEK só requer criptografar novamente DEKs em vez de todo o banco de dados do paciente.
• Integrar logs do Key Vault ao Microsoft Sentinel: Habilite as configurações de diagnóstico para o Key Vault e envie logs para o workspace do Log Analytics, crie regras de análise do Sentinel para detectar padrões de acesso de chave incomuns, operações de chave em massa, alterações administrativas fora do horário comercial.
• Transferência BYOK (Bring Your Own Key) do HSM no local: Baixe a chave de transferência BYOK do Key Vault, exporte a chave do HSM no local embalada com a chave pública de transferência BYOK do Key Vault, mantenha a prova criptográfica da linhagem da chave, importe a chave embalada para o Key Vault, onde ela chega protegida por HSM sem exposição do texto em claro.

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

Nível de criticidade

Deve ter.

Mapeamento de controle

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

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

Azure Policy: Confira as definições de política internas do Azure: DP-7.

Princípio de segurança

Gerenciar ciclos de vida de certificado por meio de processos centralizados que incluem inventário, renovação automatizada, padrões criptográficos fortes e revogação oportuna. Verifique se os certificados para serviços críticos são 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 certificado mal controlados causam interrupções de serviço, enfraquecem os canais criptografados e permitem a representação. Sem inventário centralizado, imposição de política e renovação automatizada:

• Expirações inesperadas: Certificados expirados causam interrupções na produção, interrupções em APIs, federações de identidade ou cadeias de confiança do cliente.
• Persistência de criptografia fraca: Tamanhos de chave herdados/algoritmos de assinatura (por exemplo, SHA-1, RSA < 2048) continuam em uso mesmo após a depreciação.
• Uso indevido de curinga e autoassinado: Certificados autoassinados de escopo amplo ou não gerenciados permitem a impersonação lateral e o risco de downgrade do TLS.
• Comprometimento não detectado: Chaves privadas roubadas permitem ataques transparentes de intermediário (homem-no-meio) ou descriptografia de tráfego até que a rotação das chaves ocorra.
• Certificados de sombra: A emissão não sancionada fora das ACs aprovadas fragmenta a governança e aumenta os pontos cegos de revogação.
• Erros de renovação manual: O sequenciamento de substituição inconsistente causa incompatibilidades de cadeia de confiança e descompasso parcial do ambiente.

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

MITRE ATT&CK

• Evasão de Defesa (TA0005): subverta controles de confiança (T1553) emitindo ou introduzindo certificados fraudulentos/desonestos para ignorar a validação.
• Desenvolvimento de Recursos (TA0042): desenvolver recursos (T1587) forjando certificados ou ferramentas para futuras fases de intrusão.
• Evasão de Defesa (TA0005): enfraquecimento da criptografia (T1600), continuidade no uso de algoritmos de assinatura obsoletos, reduzindo a garantia de verificação.
• Acesso à Credencial (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 os 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 a qualidade criptográfica consistente e a emissão automatizada em sua infraestrutura. Estabeleça políticas que impõem tamanhos de chave modernos, algoritmos de assinatura e períodos de validade, eliminando práticas arriscadas, como certificados autoassinados e certificados curinga que expandem superfícies de ataque quando chaves privadas são comprometidas.

Estabelecer a infraestrutura de gerenciamento de certificados:

• Use o Azure Key Vault para gerenciar centralmente o ciclo de vida completo do certificado: criação, importação, renovação, rotação, revogação e exclusão segura.
• Defina políticas de certificado no Azure Key Vault para impor padrões de segurança organizacional:
  • Tipo e tamanho da chave: RSA 2048 bits mínimo (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).
  • Período de validade: Máximo de 397 dias para certificados TLS públicos (por requisitos de linha de base do Fórum de Autoridade de Certificação/Navegador); durações mais curtas (90 dias) recomendadas para exposição reduzida.
  • Autoridade de certificação: Use somente CAs aprovadas e integradas (DigiCert, GlobalSign) ou a AC privada da sua organização.

Integrar autoridades de certificação:

• Use autoridades de certificação associadas integradas ao Azure Key Vault para certificados TLS/SSL públicos:
  • DigiCert: Certificados TLS/SSL validados pela organização (OV)
  • GlobalSign: Certificados TLS/SSL validados pela organização (OV)
• Para serviços privados/internos, integre a Autoridade de Certificação interna da sua organização (por exemplo, Serviços de Certificados do Active Directory – ADCS) ao Azure Key Vault para emissão automatizada de certificados.
• Evite certificados autoassinados e certificados curinga em ambientes de produção:
  • Certificados autoassinados: Não há validação de terceiros, não pode ser revogada por meio de CRL/OCSP público e é rejeitada por navegadores/clientes modernos.
  • Certificados curinga: Escopo amplo aumenta o risco quando comprometido; ao invés de, use certificados SAN (nome alternativo do sujeito) com FQDNs explícitos.

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

DP-7.2: implementar a renovação automatizada de certificado

Elimine as interrupções de serviço causadas por certificados expirados, automatizando fluxos-de-trabalho de renovação que são ativados bem antes da expiração e atualizam os certificados de forma perfeita em todos os serviços dependentes, sem intervenção manual. Configure os serviços do Azure para recuperar automaticamente certificados renovados do Key Vault usando identidades gerenciadas, reduzindo a labuta operacional e eliminando o risco de renovações manuais esquecidas durante feriados ou transições de pessoal.

Configurar a renovação automatizada:

• Habilite a renovação automatizada de certificados no Azure Key Vault configurando ações de tempo de vida para disparar a renovação em uma porcentagem especificada do tempo de vida do certificado:
  • Gatilho recomendado: 80-90% de período de validade (por exemplo, ~318 dias para o certificado de 397 dias).
  • Ação: renovar automaticamente (o Key Vault solicita a renovação da AC sem intervenção manual).
• Configure contatos de notificação para alertar os administradores sobre as expirações futuras do certificado antes dos gatilhos de renovação automática.

Habilitar a associação automática de certificado:

• Para os serviços do Azure que dão suporte à rotação automática de certificados (Serviço de Aplicativo do Azure, Gateway de Aplicativo do Azure, Azure Front Door), configure esses serviços para recuperar automaticamente certificados atualizados do Key Vault usando identidades gerenciadas ou entidades de serviço com políticas de acesso apropriadas do Key Vault:
  • Os serviços do Azure associarão automaticamente novas versões de certificado quando forem renovadas (normalmente dentro de 24 horas, nenhuma reinicialização de serviço é necessária).
• Para aplicativos que não podem consumir automaticamente certificados do Key Vault, implemente fluxos de trabalho manuais de rotação de certificados com runbooks operacionais e alertas de monitoramento para evitar interrupções relacionadas à expiração.
• Mantenha um inventário de todos os certificados no Azure Key Vault acompanhando o nome do certificado, a finalidade, a data de expiração, os serviços dependentes e o status de renovação.

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

Mantenha a visibilidade contínua da integridade de certificados por meio de monitoramento automatizado, consultas de inventário e dashboards que destacam certificados próximos do vencimento, usando criptografia obsoleta ou sem governança adequada. Estabeleça procedimentos de revogação rápida para certificados comprometidos e integre-se à inteligência contra ameaças do setor para bloquear proativamente certificados emitidos pelas autoridades de certificação comprometidas antes que eles habilitem ataques man-in-the-middle.

Configurar monitoramento e alertas:

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

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

• Use o Azure Resource Graph para consultar o inventário de certificados:
  • Consultar certificados próximos à expiração (dentro de 30/60/90 dias).
  • Pesquisar certificados autoassinados.
  • Consultar certificados usando algoritmos preteridos (por exemplo, SHA-1).
• Crie painéis de auditoria de certificado (por exemplo, Power BI) com visualizações:
  • Linha do tempo de expiração do certificado por intervalo de tempo.
  • Contagem de certificados autoassinados por grupo de recursos.
  • Certificados usando padrões criptográficos preteridos.
• Examine os painéis de auditoria de certificado 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 certificado para certificados comprometidos ou desativados:
  • Processo de revogação de documentos (desabilite o certificado no Key Vault, notifique os serviços dependentes).
  • Manter manuais de resposta a incidentes para cenários de comprometimento de certificado.
  • Monitore os avisos da indústria sobre certificados de autoridade certificadora (CA) raiz ou intermediários comprometidos e bloqueie-os prontamente.

Exemplo de implementação

Uma empresa com mais de 200 aplicativos Web voltados para o público centralizou o gerenciamento do ciclo de vida de certificados usando o Azure Key Vault integrado ao DigiCert como autoridade de certificação.

Desafio: Os processos manuais de renovação de certificado causaram várias interrupções de produção quando os certificados expiraram inesperadamente. Certificados curinga criaram um raio de explosão excessivo quando as chaves privadas foram comprometidas. O gerenciamento de certificado fragmentado entre as equipes resultou em certificados de 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 de certificação com o Azure Key Vault: Adicione DigiCert (ou outra autoridade de certificação parceira) ao Key Vault com credenciais de API para solicitações de certificado automatizadas.
• Crie políticas de certificado que impõem padrões de segurança: Defina a política de certificado com nome de certificado (www-contoso-com-2024), emissor (DigiCert), assunto (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 os padrões do CA/Browser Forum), configure a ação de renovação automática com base na duração do certificado (defina o gatilho em aproximadamente 80% da duração do certificado, ou cerca de 318 dias para um certificado de 397 dias), ação: renovar automaticamente (o Key Vault solicita a renovação do DigiCert sem intervenção manual).
• Configurar a associação automática de certificados para os serviços do Azure: Para o Azure App Service, importe o certificado do Key Vault, atribua a identidade gerenciada atribuída pelo usuário com a função de Usuário de Segredos do Key Vault, habilite atualizações automáticas de certificado (o App Service associa a nova versão do certificado dentro de 24 horas quando renovado, sem necessidade de reinicialização); para o Azure Application Gateway, configure o listener para recuperar o certificado do Key Vault, atribua a identidade gerenciada atribuída pelo usuário com as funções de Usuário de Segredos do Key Vault e Usuário de Certificados, e o Application Gateway recupera automaticamente o certificado atualizado quando o Key Vault o renova.
• Configurar alertas de expiração de certificado: Crie duas regras de alerta no Azure Monitor — aviso de expiração de 30 dias (enviar notificação para o canal slack de engenharia de plataforma), alerta crítico de expiração de 7 dias (abra o tíquete Jira para revisão manual e envie email para a equipe de segurança).
• Elimine certificados curinga em favor de certificados SAN: Audite certificados curinga existentes (*.contoso.com) no Key Vault, substitua por certificados SAN contendo nomes DNS explícitos (www.contoso.comapi.contoso.com), benefício: se a chave privada estiver comprometida, somente FQDNs listados serão afetados (nem todos os subdomínios).
• Monitorar a expiração do certificado: Use o Azure Resource Graph para consultar o inventário de certificados e identificar certificados próximos à expiração (dentro de 30 dias), certificados autoassinados ou certificados usando o algoritmo de assinatura SHA-1 preterido, examine o painel trimestralmente durante as reuniões de revisão de segurança.

Resultado: Renovação automatizada de certificados é acionada quando atingir 80% do tempo de vida. O Serviço de Aplicativo do Azure e o Gateway de Aplicativo recuperam certificados atualizados dentro de 24 horas por meio de identidades gerenciadas (nenhuma reinicialização necessária). Os alertas do Azure Monitor notificam a engenharia da plataforma antes da expiração. Os certificados SAN substituem certificados curinga, reduzindo o raio de explosão de comprometimento.

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: Confira as definições de política internas do Azure: DP-8.

Princípio de segurança

Proteja os serviços de cofres de chaves por meio de controles de defesa em profundidade: acesso com o mínimo de privilégios, isolamento de rede, registro e monitoramento abrangentes, recursos de backup e recuperação e proteção suportada por HSM, quando necessário. Os cofres de chaves são uma infraestrutura crítica que protege chaves criptográficas e certificados usados para criptografia e autenticação.

Risco a mitigar

O comprometimento do repositório de chave e certificado anula a criptografia upstream, a assinatura e as garantias de identidade. Sem acesso reforçado ao cofre, sem monitoramento, e sem isolamento:

• Exfiltração de chaves: Chaves de Criptografia Simétrica (KEKs) ou material de Módulo de Segurança de Hardware (HSM) roubados permitem a descriptografia em massa de dados armazenados e a interceptação de tráfego.
• Acesso administrativo à sombra: A configuração incorreta de RBAC ou de políticas excessivamente amplas permite a exportação, remoção ou reversão de versão ilícita de chave.
• Adulteração silenciosa: A substituição mal-intencionada de chaves permite ataques de intermediário ou códigos/assinaturas forjados.
• Exposição à rede: O abuso de ponto de extremidade público (ataque de preenchimento de credenciais, sondagem de API) aumenta a superfície de ataque para força bruta ou reprodução de tokens.
• Ações destrutivas acidentais: A ausência de exclusão reversível/proteção contra limpeza leva à perda irreversível de dados criptográficos.
• Linhagem de auditoria insuficiente: A falta de logs imutáveis prejudica a resposta a incidentes e as necessidades de evidências regulatórias.
• Locação não desagregada: As chaves de aplicativo misturadas ampliam o raio de alcance do movimento lateral após um único comprometimento de identidade.

As fraquezas do repositório se propagam rapidamente em falhas sistêmicas de confidencialidade, integridade e disponibilidade entre cargas de trabalho dependentes.

MITRE ATT&CK

• Acesso à Credencial (TA0006): credenciais desprotegidas/repositórios de credenciais (T1552/T1555) obtidos por meio de função de vault ou políticas de rede configuradas incorretamente.
• Evasão de Defesa (TA0005): intermediário adversário (T1557) capturando o tráfego destinado ao cofre para interceptação de chave/certificado, ou enfraquecendo a criptografia (T1600) substituindo chaves fortes por material controlado pelo invasor.
• Ta0004 (Escalonamento de Privilégios): contas válidas (T1078) explorando funções de operador de cofre abrangentes para enumerar e alterar segredos.
• Impacto (TA0040): destruição de dados/inibição de recuperação (T1485/T1490) executando sequências de purga destrutivas que impedem a restauração.

DP-8.1: implementar controles de acesso para o Key Vault

Proteja a base criptográfica de sua infraestrutura impondo controles de acesso estritos baseados em identidade que impedem o acesso de chave não autorizado, limitam privilégios administrativos a janelas de tempo justificadas e eliminam o armazenamento de credenciais por meio de identidades gerenciadas. Implemente a separação de tarefas entre os principais administradores e os principais usuários para impedir que qualquer identidade comprometida única gerencie e explore material criptográfico.

Implementar o RBAC e a separação de tarefas:

• Implemente o RBAC do Azure para Key Vault para impor controle de acesso com privilégios mínimos.
  • Para o HSM Gerenciado do Azure Key Vault: use o RBAC local no nível individual de chave, segredo e certificado com funções padrão (Managed HSM Crypto Officer, Crypto User, Crypto Auditor).
  • Para o Azure Key Vault Standard/Premium: crie cofres dedicados para cada aplicativo ou ambiente, a fim de impor a separação lógica e atribua funções RBAC (Administrador do Key Vault, Oficial de Segredos, Oficial de Certificados) com escopo específico para o aplicativo.
• Impor a separação de funções: separar funções para o gerenciamento de chaves (que podem criar/girar chaves) de operações criptográficas (que podem usar chaves para criptografar/descriptografar).

Utilize identidades gerenciadas e acesso JIT:

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

DP-8.2: proteger a segurança de rede do Key Vault

Elimine superfícies de ataque voltadas para a Internet roteando todo o acesso ao Key Vault por meio de pontos de extremidade privados em suas redes virtuais, impedindo ataques de preenchimento de credenciais, tentativas de força bruta e reconhecimento por atores de ameaças externas. 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.

Implantar o Link Privado e configurar o firewall:

• Proteger o acesso de rede ao Azure Key Vault usando o Link Privado do Azure para estabelecer conectividade privada de VNets sem expor o Key Vault à Internet pública.
• Configure o firewall do Key Vault para restringir o acesso a intervalos de IP ou VNets específicos para cenários em que o Link Privado não é viável:
  • Desabilite o acesso público quando possível (Key Vault acessível somente por meio 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 VNets para garantir a resolução de DNS adequada para pontos de extremidade privados.

DP-8.3: habilitar a proteção e o monitoramento do Key Vault

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

Habilite a exclusão reversível e a proteção contra remoção:

• Habilite a exclusão suave e proteção contra exclusão completa em todos os Azure Key Vaults para evitar a exclusão acidental ou mal-intencionada de chaves, segredos e certificados:
  • O "soft delete" permite a recuperação dentro de um período de retenção (padrão: 90 dias).
  • A proteção contra exclusão impede a eliminação permanente durante o período de retenção.
  • Imponha essas configurações com o Azure Policy usando políticas internas: "Os cofres de chaves devem ter a exclusão reversível habilitada" e "Os cofres de chaves devem ter a proteção de limpeza habilitada" (efeito deployIfNotExists).
• Implemente as principais políticas de ciclo de vida para evitar a eliminação criptográfica de dados:
  • Antes de limpar dados criptografados, verifique se as chaves de criptografia são retidas para o período de retenção de dados necessário.
  • Durante a desativação de chaves, use desativar em vez de excluir para evitar perda acidental de dados, preservando os metadados das chaves para fins de auditoria.
  • Crie e teste procedimentos de backup do Key Vault para cenários de recuperação de desastre.

Use chaves suportadas por HSM e BYOK:

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

Habilitar o monitoramento e a detecção de ameaças:

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

Nota: Todas as SKUs do Key Vault impedem a exportação de chave por design; as operações criptográficas são executadas dentro do limite de HSM seguro. Nunca exporte ou armazene chaves em texto sem formatação fora do Azure Key Vault.

Exemplo de implementação

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

Desafio: Permissões RBAC excessivamente amplas permitiram que os desenvolvedores tivessem acesso direto aos Key Vaults de produção, criando riscos internos e violações de conformidade. A exposição pública à Internet permitiu ataques de preenchimento de credenciais e tentativas de reconhecimento. Sem monitoramento abrangente e resposta automatizada, os padrões de acesso a chaves suspeitas não foram detectados. A falta de proteção contra exclusão e limpeza reversível arriscou a perda permanente de dados criptográficos durante incidentes.

Abordagem da solução:

• Implantar Key Vaults dedicados para segmentação lógica: Crie um Key Vault por ambiente e por unidade de negócios com a convenção de nomenclatura kv-{businessunit}-{environment}-{region} (por exemplo, kv-finance-prod-eastus2, kv-finance-dev-eastus2), e implante-os em grupos de recursos separados por ambiente para garantir isolamento (uma entidade de serviço de desenvolvimento comprometida não pode acessar as chaves de produção).
• Configurar o RBAC para acesso de privilégios mínimos: Para cofres de chaves não-produtivos (desenvolvimento/homologação), atribua o papel de Usuário de Segredos do Key Vault (somente leitura) a grupos de segurança dos desenvolvedores. Os desenvolvedores podem ler segredos no desenvolvimento/homologação, mas não têm acesso aos cofres de chaves de produção; para cofres de chaves de produção, atribua o papel de Usuário de Segredos do Key Vault às entidades de serviço de CI/CD (identidades gerenciadas do pipeline do Azure DevOps), limitando o escopo a segredos nomeados específicos, sem acesso interativo de desenvolvedores às chaves de produção.
• Proteger a segurança de rede com o Link Privado do Azure: Implante pontos de extremidade privados para o Key Vault (selecione VNet e sub-rede, crie uma zona DNS privada privatelink.vaultcore.azure.net e vincule à VNet), configure o firewall do Key Vault (desabilite o acesso público com o Key Vault acessível apenas por meio de ponto de extremidade privado, se o acesso público necessário para CI/CD permitir o acesso de redes selecionadas somente com sub-redes de VNet do Azure aprovadas e intervalos de endereços IP do agente CI/CD).
• Habilitar o Microsoft Defender para Key Vault: Habilitar o Microsoft Defender para Key Vault no nível da assinatura, o Defender monitora anomalias, incluindo acesso geográfico incomum, enumeração suspeita (operações de lista rápida indicando reconhecimento), operações administrativas anormais (exclusões de segredo em massa).
• Integre-se ao Microsoft Sentinel para resposta automatizada: Adicione o conector de dados do Microsoft Defender para Nuvem ao Sentinel, crie regras do Sentinel Analytics para acesso regional incomum, força bruta potencial, operações administrativas suspeitas, configure guias estratégicos de resposta automatizados para desabilitar identidades suspeitas e notificar as equipes de segurança.
• Transmitir logs de diagnóstico para o Log Analytics: Habilite o logging de diagnóstico para o Key Vault com AuditEvent (todas as operações de chave/segredo/certificado), AllMetrics (frequência de uso, latência), enviar para o workspace do Log Analytics com retenção de 2 anos, criar consultas KQL personalizadas para detecção de anomalias, incluindo a detecção de tentativas de força bruta potenciais (mais de 10 tentativas não autorizadas em 5 minutos), desabilitar operações de exclusão suave (indicador de sabotagem).
• Implementar o acesso de administrador Just-in-Time com o Azure AD PIM: Configure atribuições qualificadas para a função de Administrador do Key Vault (adicione membros da equipe de segurança como Qualificados e não permanentes, exija Justificativa e MFA para ativação, defina a duração máxima de ativação 8 horas, exija aprovação do arquiteto de segurança sênior), realize revisões de acesso trimestral para todas as atribuições de função de Administrador do Key Vault; revogar o acesso desnecessário.

Resultado: Cofres de Chaves dedicados por ambiente garantem segmentação. O RBAC limita os desenvolvedores ao acesso somente leitura de não produção. O Link Privado elimina a exposição pública à Internet. O Microsoft Defender detecta anomalias. Planos de ação do Sentinel desativam automaticamente identidades suspeitas. O PIM permite o acesso de administrador just-in-time (no momento exato), 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