Segurança de Rede

A segurança da rede protege as cargas de trabalho na nuvem contra ameaças como acesso não autorizado, violações de dados e interrupção do serviço, controlando o tráfego em vários limites. Ao contrário das defesas tradicionais focadas no perímetro, os ambientes de nuvem modernos exigem estratégias de defesa profunda com segmentação, conectividade privada e proteção de borda para lidar com superfícies de ataque dinâmicas, incluindo serviços expostos, caminhos de movimento lateral e canais de comando e controle. As organizações que implementam controles de rede abrangentes mantêm ambientes seguros por padrão, enquanto aqueles que negligenciam esses controles enfrentam movimentos laterais irrestritos e exposição prolongada a ameaças.

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

Limites de rede seguros: Imponha controles rigorosos nas bordas da rede e entre segmentos por meio de defesa profunda em várias camadas, incorporando firewalls, proteção contra DDoS, firewalls de aplicativos da Web e conectividade privada, seguindo o princípio do menor privilégio para negar tráfego não autorizado por padrão.

Controlos relacionados:

• NS-2: Serviços de nuvem seguros com controles de rede
• NS-3: Implante o firewall na borda da rede corporativa
• NS-5: Implante a proteção DDOS
• NS-6: Implante o firewall de aplicativos Web
• NS-9: Conecte-se à rede local ou na nuvem de forma privada

Aplique o isolamento de rede: Divida as redes em segmentos isolados alinhados com a estratégia de segmentação empresarial e os níveis de risco para limitar a propagação de ameaças, reduzir a superfície de ataque e impedir movimentos laterais não autorizados.

Controlos relacionados:

• NS-1: Estabelecer limites de segmentação de rede

Monitorize e responda: Mantenha visibilidade contínua da atividade da rede por meio de monitoramento abrangente, deteção de invasões e segurança de protocolo para identificar comportamentos suspeitos, violações de políticas e ameaças ativas rapidamente.

Controlos relacionados:

• NS-4: Implante sistemas de deteção e prevenção de intrusão (IDS/IPS)
• NS-8: Detetar e desabilitar serviços e protocolos inseguros
• NS-10: Garanta a segurança do DNS (Sistema de Nomes de Domínio)

NS-1: Estabelecer limites de segmentação de rede

Azure Policy: Veja definições de políticas incorporadas Azure: NS-1.

Princípio da segurança

A segmentação de rede envolve a divisão de uma rede em segmentos menores e isolados para controlar e limitar o fluxo de tráfego entre os recursos da nuvem para reduzir o raio de explosão.

Projete sua segmentação de rede para garantir que sua implantação de rede virtual esteja alinhada com sua estratégia de segmentação corporativa e diferentes níveis de risco. A estratégia de segmentação comum inclui:

• Separe Corpnet usando redes de aplicações.
• Redes de aplicativos separadas
• Redes separadas de ambiente de produção e teste

Consulte o Azure Well-Architected Framework para saber mais sobre as principais estratégias de segmentação de rede:

• Estratégia de segmentação do Azure

Risco a mitigar

Sem limites de segmentação de rede, as organizações enfrentam movimentos laterais irrestritos, permitindo que os invasores atravessem infraestruturas de rede e comprometam ativos de alto valor.

• Exposição plana à rede: A ausência de segmentação permite o movimento lateral irrestrito, permitindo que os adversários comprometam ativos de alto valor atravessando uma topologia de rede não particionada.
• Caminhos de escalonamento de privilégios: Limites inadequados permitem vetores de acesso não autorizados, facilitando o escalonamento de privilégios de usuário por meio do acesso a sub-redes e cargas de trabalho confidenciais.
• Propagação de malware: A segmentação insuficiente permite a rápida disseminação de códigos maliciosos, como ransomware, entre nós interconectados, amplificando a superfície de ataque e o impacto operacional.
• Cegueira do tráfego Este-Oeste: O tráfego irrestrito entre segmentos dificulta a deteção de anomalias e a resposta a incidentes, reduzindo a visibilidade dos movimentos internos de ameaças e complicando a análise forense.

MITRE ATT&CK

• Acesso Inicial (TA0001): acesso não autorizado a redes e serviços expostos (por exemplo, T1190 - Exploit Public-Facing Application).
• Movimento Lateral (TA0008): realização de ataques através de redes virtuais (VNets) e tráfego entre sub-redes não restrito (por exemplo, T1021 - Serviços Remotos).
• Exfiltração (TA0010): exfiltração de dados por tráfego de saída não restrito para transferências de dados não autorizadas para servidores externos (por exemplo, T1041 - Exfiltração pelo Canal C2).
• Comando e Controle (TA0011): propagação de malware por comunicação com IPs ou domínios maliciosos através de regras de firewall e inteligência de ameaças (por exemplo, T1071 - Application Layer Protocol).

NS-1.1: Crie segmentação usando VNet e sub-redes

O isolamento de rede virtual estabelece limites fundamentais de segurança em ambientes de nuvem, permitindo que as organizações separem cargas de trabalho por nível de confiança, unidade organizacional ou agrupamento de aplicativos. Essa abordagem evita movimentos laterais irrestritos e reduz o raio de explosão quando ocorrem violações, alinhando a arquitetura de rede com estratégias de segmentação corporativa e princípios de confiança zero.

Implemente a segmentação de rede virtual criando limites e subdivisões de rede isolados:

• Projete a topologia VNet com base na estratégia de segmentação: Crie redes virtuais alinhadas com zonas de confiança, unidades organizacionais ou agrupamentos de aplicativos definidos em sua estratégia de segmentação empresarial, garantindo que cada VNet represente um limite de segurança distinto.

• Isolar cargas de trabalho de alto risco: Identifique cargas de trabalho que exigem isolamento rigoroso (por exemplo, bancos de dados de produção, sistemas de processamento de pagamentos) e implante-as em redes virtuais dedicadas e isoladas para minimizar a exposição e evitar contaminação cruzada.

• Crie sub-redes para segmentação granular: Dentro de cada rede virtual, crie sub-redes distintas não sobrepostas para segmentar ainda mais a rede com base em camadas de aplicativos (por exemplo, camada da Web, camada de aplicativo, camada de banco de dados) ou requisitos funcionais, permitindo um controle de tráfego e microssegmentação mais precisos.

NS-1.2: Restringir o tráfego de rede usando o NSG

Os grupos de segurança de rede impõem filtragem de tráfego ao nível da sub-rede e da interface de rede, permitindo um controlo preciso dos fluxos de comunicação entre segmentos de rede e redes externas. Ao implementar políticas de negação por padrão com regras explícitas de permissão, as organizações garantem que apenas o tráfego autorizado ultrapasse os limites da rede, impedindo o acesso não autorizado e reduzindo a superfície de ataque.

Implemente a restrição de tráfego de rede usando regras NSG:

• Identificar requisitos de comunicação: Analise os recursos em cada VNet para entender suas necessidades de comunicação de tráfego norte-sul (externo) e leste-oeste (interno), documentando portas, protocolos, endereços de origem e endereços de destino necessários para funções comerciais legítimas.

• Defina regras explícitas de permissão e negação: Para aplicativos bem definidos (por exemplo, arquiteturas de três camadas), use a abordagem "negar por padrão, permitir por exceção" para criar regras NSG com base na porta, protocolo, endereço IP de origem e endereço IP de destino, permitindo explicitamente apenas o tráfego necessário enquanto nega todas as outras comunicações.

• Use grupos de segurança de aplicativos para cenários complexos: Quando muitos aplicativos e pontos de extremidade interagem, simplifique o gerenciamento de regras NSG usando grupos de segurança de aplicativos (ASGs) para agrupar recursos logicamente (por exemplo, servidores Web, servidores de banco de dados) e, em seguida, defina regras NSG com base nesses grupos, em vez de endereços IP explícitos, melhorando a capacidade de manutenção e reduzindo a complexidade da configuração.

• Monitore e otimize com logs de fluxo: Habilite os logs de fluxo da rede virtual para monitorar o tráfego permitido ou negado pelas regras NSG, identificando o tráfego frequentemente negado que pode indicar uma configuração inadequada ou tráfego frequentemente permitido que poderia informar a otimização das regras e reduzir o ruído nos logs.

Exemplo de implementação

Uma organização precisava proteger um aplicativo de várias camadas com ambientes separados de produção, desenvolvimento e teste, evitando movimentos laterais não autorizados e acesso externo.

Desafio: A organização tinha uma aplicação de três camadas (web, aplicação, banco de dados) com todos os recursos em um único grande segmento de rede, permitindo a comunicação irrestrita entre todos os níveis e ambientes. Isso criou riscos de segurança significativos, incluindo potencial movimento lateral entre produção e não produção, acesso irrestrito à Internet a partir de servidores de banco de dados e incapacidade de isolar cargas de trabalho de alto risco.

Abordagem da solução:

• Segmentação de VNet por ambiente: Criei redes virtuais separadas para ambientes de produção (10.0.0.0/16), desenvolvimento (10.1.0.0/16) e teste (10.2.0.0/16), estabelecendo limites de isolamento de rede que impedem o acesso entre ambientes e limitam o raio de explosão de possíveis violações.
• Segmentação da sub-rede por camada: Dentro da rede virtual de produção, criou sub-redes distintas não sobrepostas para cada camada de aplicativo - camada da Web (10.0.1.0/24), camada de aplicativo (10.0.2.0/24) e camada de banco de dados (10.0.3.0/24) - permitindo o controle granular de tráfego entre as camadas.
• Regras do NSG para o controlo do tráfego norte-sul: Regras NSG configuradas para negar todo o tráfego de entrada da Internet (0.0.0.0/0) para sub-redes internas e restringir o acesso de saída à Internet apenas para destinos confiáveis, com regras específicas permitindo apenas conexões externas necessárias para a camada da Web enquanto bloqueia todo o acesso à Internet da camada de banco de dados.
• Regras do NSG para o controlo de tráfego este-oeste: Implementadas políticas de negação por padrão com regras de permissão explícitas entre camadas - camada web permitida de saída para a camada de aplicações somente nas portas necessárias, camada de aplicações permitida de saída para a camada de bases de dados somente na porta 1433 (SQL), e camada de bases de dados negada a todo o outro tráfego de entrada, exceto da sub-rede da camada de aplicações.
• Acesso à gestão remota: Portas de gerenciamento remoto restritas (RDP 3389/TCP, SSH 22/TCP) para aceitar conexões somente da sub-rede de host bastion confiável (10.0.0.0/26), eliminando o acesso direto à Internet às interfaces de gerenciamento.

Resultado: A organização eliminou o movimento lateral irrestrito entre camadas de aplicativos e ambientes, reduziu significativamente a superfície de ataque removendo o acesso direto à Internet dos sistemas de back-end e estabeleceu limites de rede aplicáveis alinhados com os princípios de confiança zero. Os logs de fluxo permitiram o monitoramento contínuo do tráfego permitido e negado para otimização contínua e validação do perfil de segurança.

Nível de criticidade

Deve ter.

Mapeamento de controle

• NIST SP 800-53 Rev.5: SC-7, SC-32, AC-4, CM-7
• PCI-DSS v4: 1.2.1, 1.3.1, 1.4.1
• Controles CIS v8.1: 12.1, 12.2, 12.6
• NIST CSF v2.0: PR. IR-01, PR. AC-05
• ISO 27001:2022: A.8.20, A.8.21
• SOC 2: CC6.1, CC6.6

NS-2: Serviços nativos de nuvem seguros com controles de rede

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

Princípio da segurança

Use recursos nativos de serviço para proteger o acesso à rede aos recursos para evitar e reduzir a exposição dos recursos à rede não confiável. Estas funcionalidades incluem:

• Estabelecer pontos de acesso privados para recursos para evitar a exposição do tráfego de rede que passa pela rede pública.
• Implante o recurso em redes virtuais onde você pode restringir a VNet para estabelecer um ponto de acesso privado para o serviço.
• Configure firewalls nativos do serviço para restringir o tráfego de entrada ou desativar o acesso à rede pública.

Nota: Além do controle básico de acesso à rede e filtragem de tráfego, você também deve usar recursos de deteção de ameaças para monitorar serviços como DNS (NS-10) para detetar a possível exfiltração de dados.

Risco a mitigar

Os agentes de ameaças exploram serviços de nuvem expostos publicamente para realizar exfiltração de dados, ataques na camada de aplicativos e intercetação de tráfego.

• Exfiltração de dados através de terminais públicos: Os atacantes exploram contas de armazenamento, bancos de dados ou APIs acessíveis publicamente para exfiltrar dados confidenciais, estabelecendo conexões não autorizadas com pontos de extremidade expostos, ignorando controles de segmentação de rede e permitindo o roubo de dados em larga escala.
• Ataques de camada de aplicativo contra pontos de extremidade públicos: Ataques distribuídos de negação de serviço (DDoS), injeção de SQL e outras explorações de aplicativos têm como alvo serviços da Web, APIs e bancos de dados expostos publicamente, sobrecarregando recursos ou explorando vulnerabilidades para causar interrupção do serviço ou comprometimento de dados.
• Ataques man-in-the-middle: Os atacantes intercetam o tráfego que flui através de redes públicas para serviços expostos publicamente, capturando credenciais, tokens de sessão ou dados confidenciais transmitidos sem criptografia adequada ou conectividade privada, permitindo a tomada de conta ou roubo de dados.

MITRE ATT&CK

• Acesso Inicial (TA0001): acesso não autorizado por exposição pública na Internet de serviços em nuvem (por exemplo, serviços de armazenamento em nuvem, serviços de banco de dados), exploração visando pontos finais públicos (por exemplo, T1190 - Exploit Public-Facing Application).
• Exfiltração (TA0010): exfiltração de dados por roteamento de tráfego em conexões de rede virtual privada, reduzindo o risco de vazamento de dados para servidores externos (por exemplo, T1041 - Exfiltração pelo Canal C2).
• Movimento Lateral (TA0008): serviços pivotantes de invasores dentro de redes virtuais, acesso não autorizado entre recursos de nuvem (por exemplo, T1021 - Serviços Remotos).

NS-2.1 Usar link privado para conexão de serviço

A conectividade privada elimina a exposição pública à Internet para serviços em nuvem, estabelecendo caminhos de rede diretos dentro de sua infraestrutura virtual. O Private Link cria terminais privados com endereços IP dedicados dentro das suas redes virtuais, garantindo que o tráfego para serviços na nuvem nunca atravessa a Internet pública, mantendo padrões de acesso baseados em DNS. Essa abordagem reduz significativamente a superfície de ataque e evita a exfiltração de dados por meio de pontos de extremidade acessíveis publicamente.

Implemente a conectividade privada para serviços de nuvem por meio destas etapas:

• Implante pontos de extremidade privados para serviços suportados: Crie pontos de extremidade privados em sua rede virtual para recursos do Azure que suportem Link Privado (por exemplo, Armazenamento do Azure, Banco de Dados SQL do Azure, Cofre da Chave do Azure), estabelecendo endereços IP privados (por exemplo, 10.0.2.4) acessíveis somente a partir de sua rede virtual.

• Configurar zonas DNS privadas: Crie zonas DNS Privadas do Azure para substituir a resolução DNS pública, garantindo que FQDNs (nomes de domínio totalmente qualificados), como mystorageaccount1.blob.core.windows.net, resolvam para endereços IP privados dentro da sua rede virtual, em vez de para pontos de extremidade públicos, mantendo uma conectividade perfeita para aplicações que usam acesso baseado em FQDN.

• Desative o acesso público: Configure as configurações de nível de serviço para desabilitar totalmente o acesso à rede pública assim que os pontos de extremidade privados forem implantados, garantindo que todo o tráfego flua exclusivamente por meio de conectividade privada sem fallback para pontos de extremidade públicos.

Observação: Determinados serviços do Azure também podem permitir comunicação privada por meio do recurso de ponto de extremidade do serviço , embora o Azure Private Link seja recomendado para acesso seguro e privado a serviços hospedados na plataforma Azure. Para implantações, como serviços Web hospedados em VMs do Azure, evite atribuir IPs públicos diretamente a VMs, a menos que seja fortemente justificado; em vez disso, use o Gateway de Aplicativo do Azure ou o Balanceador de Carga do Azure como o front-end para acesso ao serviço.

NS-2.2 Implantar o serviço na VNet

A integração de rede virtual permite que os serviços em nuvem operem dentro dos limites da rede privada, estabelecendo conectividade direta com recursos hospedados pela rede virtual sem exposição pública à Internet. Ao implantar serviços em redes virtuais, as organizações obtêm controle granular sobre o tráfego de rede por meio de grupos de segurança e tabelas de rotas, mantendo o isolamento do serviço contra ameaças externas.

Implante serviços com integração de VNet onde houver suporte:

• Implante serviços em redes virtuais: Para serviços que dão suporte à integração de redes virtuais (por exemplo, Serviço de Aplicativo do Azure, Azure Functions, Instâncias de Contêiner do Azure), configure a implantação em redes virtuais novas ou existentes, especificando sub-redes apropriadas alinhadas com sua estratégia de segmentação e habilitando a comunicação privada com outros recursos de rede virtual.

• Configure os controles de segurança de rede: Aplique regras de NSG (grupo de segurança de rede) à sub-rede do serviço para restringir o tráfego de entrada e saída, implementando o acesso de privilégios mínimos permitindo apenas a comunicação necessária para destinos específicos (por exemplo, sub-redes de banco de dados, pontos de extremidade de armazenamento) enquanto nega todo o outro tráfego.

NS-2.3 Configurar firewall nativo de serviço

Os firewalls de nível de serviço fornecem proteção de defesa profunda restringindo o acesso à rede no nível de recursos, complementando os controles de camada de rede com limites de segurança específicos do aplicativo. Esses recursos nativos de firewall permitem que as organizações limitem a exposição a intervalos de IP específicos ou redes virtuais enquanto desabilitam completamente o acesso público quando apropriado, reduzindo a superfície de ataque sem exigir alterações complexas na topologia da rede.

Configure os firewalls de serviço para restringir o acesso.

• Habilite os recursos de firewall de serviço: Para serviços que suportam firewalls nativos (por exemplo, Armazenamento do Azure, Banco de Dados SQL do Azure, Cofre da Chave do Azure), habilite a funcionalidade de firewall durante a criação de recursos ou em recursos existentes para controlar quais redes podem acessar o serviço.

• Defina regras baseadas em IP ou VNet: Configure regras de firewall para permitir o acesso apenas de intervalos de IP públicos específicos (por exemplo, redes de escritórios corporativos) ou sub-redes específicas da rede virtual do Azure, implementando o acesso de privilégios mínimos negando todas as outras fontes.

• Desative o acesso público quando possível: Quando os serviços exigirem acesso apenas de redes privadas, use a opção de alternância para desativar completamente o acesso à rede pública, garantindo que o serviço esteja inacessível a partir da Internet, independentemente das regras baseadas em IP.

NS-2.4 Usar o perímetro de segurança de rede para isolamento de recursos PaaS

O Perímetro de Segurança de Rede estabelece um limite de rede lógico em torno de vários recursos PaaS, permitindo uma comunicação segura entre serviços dentro de um perímetro confiável explícito e, ao mesmo tempo, evitando a exfiltração não autorizada de dados. Ao contrário dos controles por recurso, o Perímetro de Segurança de Rede fornece um limite de segurança unificado que permite a comunicação dentro do perímetro sem regras de acesso individuais enquanto bloqueia o acesso externo por padrão.

Implemente o Perímetro de Segurança de Rede para proteger os recursos de PaaS:

• Crie e associe recursos: Estabeleça um perímetro de segurança de rede e adicione recursos PaaS suportados (Armazenamento do Azure, Banco de Dados SQL, Cofre de Chaves, Hubs de Eventos, Cosmos DB) por meio de associações de recursos, habilitando a comunicação dentro do perímetro onde os recursos associados podem se comunicar livremente.

• Configure modos e regras de acesso: Comece com o modo de transição para entender os padrões de acesso antes de fazer a transição para o modo imposto para obter a máxima proteção. Defina regras explícitas de acesso de entrada e saída usando endereços IP, assinaturas ou FQDNs para controlar o tráfego fora do perímetro, mantendo a postura de negação padrão.

• Habilite a monitorização e a integração da Ligação Privada: Configure registos de diagnóstico para registar tentativas de acesso e violações de políticas. O tráfego de ponto final privado é automaticamente permitido no perímetro, complementando a conectividade VNet-to-PaaS com controles de exfiltração de dados no nível do perímetro.

Exemplo de implementação

Uma organização precisava proteger o banco de dados de back-end e os recursos de armazenamento e, ao mesmo tempo, permitir o acesso de serviços de aplicativos sem expor recursos à Internet pública.

Desafio: A organização tinha contas do Banco de Dados SQL do Azure e do Armazenamento do Azure com pontos de extremidade públicos padrão, tornando-os acessíveis pela Internet e criando riscos significativos de exfiltração de dados. Os serviços de aplicativos foram implantados com IPs públicos e careciam de integração VNet, impedindo controles de acesso baseados em rede privada. Os firewalls de nível de serviço não foram configurados, permitindo acesso irrestrito de qualquer fonte assim que a autenticação foi bem-sucedida.

Abordagem da solução:

• Pontos de extremidade de link privado para serviços PaaS: Pontos de extremidade privados implantados para o Banco de Dados SQL do Azure (IP privado atribuído 10.0.2.4) e Conta de Armazenamento do Azure (IP privado atribuído 10.0.2.5) em uma sub-rede de pontos de extremidade privados dedicada (10.0.2.0/24), estabelecendo conectividade privada que roteia o tráfego pela rede backbone do Azure sem exposição à internet.
• Zonas DNS privadas para resolução de nomes: Criou zonas de DNS privado do Azure para substituir a resolução de DNS público, garantindo que os FQDNs de aplicativos (por exemplo, mysqldb.database.windows.net, mystorageaccount.blob.core.windows.net) sejam resolvidos para IPs privados dentro da VNet em vez de pontos de extremidade públicos, mantendo conectividade perfeita para aplicativos que usam acesso baseado em FQDN.
• Integração de VNet para serviços de aplicativos:Integração de VNet configurada para o Serviço de Aplicativo do Azure, implantando o aplicativo em uma sub-rede de aplicativo (10.0.1.0/24) para habilitar a comunicação direta com pontos de extremidade privados sem exigir endereços IP públicos ou roteamento de Internet.
• Firewalls nativos de serviço:Firewalls de nível de serviço habilitados no Armazenamento do Azure para restringir o acesso a sub-redes VNet específicas (sub-rede de aplicativo 10.0.1.0/24) e serviços confiáveis da Microsoft, enquanto desabilita completamente o acesso à rede pública no nível de serviço para o Banco de Dados SQL do Azure para impor conectividade somente privada.
• Regras do NSG para defesa em profundidade: Regras NSG aplicadas à sub-rede do aplicativo permitindo tráfego de saída apenas para a sub-rede de ponto de extremidade privado (10.0.2.0/24) nas portas necessárias (443 para armazenamento, 1433 para SQL), implementando controle de acesso de privilégios mínimos que complementa as proteções de nível de serviço.

Resultado: A organização eliminou a exposição pública à Internet para recursos de back-end, reduzindo significativamente os riscos de exfiltração de dados e a superfície de ataque. A conectividade privada garantiu que todo o tráfego entre aplicativos e serviços de dados permanecesse na rede de backbone do Azure sem atravessar a Internet pública, enquanto os controles em camadas (Link Privado, zonas DNS, firewalls de serviço, NSGs) forneciam proteção de defesa profunda alinhada com os princípios de confiança zero.

Nível de criticidade

Deve ter.

Mapeamento de controle

• NIST SP 800-53 Rev.5: SC-7(4), SC-7(5), AC-4(21)
• PCI-DSS v4: 1.3.1, 1.3.2, 1.4.2
• Controles CIS v8.1: 12.4, 12.7
• NIST CSF v2.0: PR. AC-05, PR. DS-05
• ISO 27001:2022: A.8.20, A.8.22
• SOC 2: CC6.1, CC6.6

NS-3: Implante o firewall na borda da rede corporativa

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

Princípio da segurança

Use o firewall na borda da rede para executar filtragem avançada no tráfego de rede de e para redes externas, como a Internet, e entre segmentos de rede interna.

No mínimo, a política de firewall deve incluir:

• Bloqueie sites e endereços IP incorretos conhecidos.
• Restrinja protocolos de alto risco, como protocolos de gerenciamento remoto e protocolos de intranet em redes de borda para impedir acesso não autorizado ou movimento lateral.
• Aplique regras de aplicativo para permitir apenas destinos externos aprovados e bloquear sites não autorizados ou arriscados.

Risco a mitigar

Os adversários exploram vulnerabilidades expostas a redes públicas ou não confiáveis por meio de protocolos acessíveis, domínios mal-intencionados e controles de rede fracos.

• Acesso não autorizado através de protocolos expostos: Protocolos acessíveis ao público, como RDP (TCP 3389) ou SMB (TCP 445), permitem que os invasores obtenham entrada não autorizada, comprometendo a integridade do sistema por meio de exploits como ataques de força bruta ou CVE.
• Malware e phishing através de domínios/IPs maliciosos: Domínios e IPs maliciosos facilitam a entrega de malware ou campanhas de phishing, colocando em risco endpoints e dados confidenciais por meio de ataques de comando e controle ou engenharia social.
• Exfiltração de dados através de tráfego de saída irrestrito: A saída descontrolada para destinos não aprovados permite que os adversários exfiltrem dados confidenciais, correndo o risco de violações e violações de conformidade por meio de canais secretos como HTTPS POSTs.
• Movimento lateral devido à fraca segmentação: A segmentação de rede insuficiente permite que os invasores girem internamente, explorando o tráfego entre segmentos (por exemplo, SMB, Kerberos) para se propagar a partir de sistemas comprometidos.
• Vulnerabilidades de aplicações/URLs não fidedignas: O acesso a URLs e aplicativos arriscados ou não confiáveis aumenta a exposição a exploits, elevando os riscos de incidentes e a não conformidade com as normas regulamentares.

MITRE ATT&CK

• Acesso Inicial (TA0001): acesso não autorizado a protocolos de alto risco (por exemplo, RDP/TCP 3389, SSH/TCP 22) ou domínios maliciosos (por exemplo, T1190 - Exploit Public-Facing Application).
• Comando e Controle (TA0011): malware que se conecta a IPs/domínios maliciosos (por exemplo, T1071 - Application Layer Protocol).
• Exfiltração (TA0010): transferências de dados não autorizadas através do tráfego de saída para destinos não aprovados (por exemplo, T1041 - Exfiltração pelo Canal C2).
• Movimento Lateral (TA0008): inibe a pivotação interna através de tráfego intersegmentos não filtrado (por exemplo, SMB/TCP 445, Kerberos/TCP 88) (por exemplo, T1021 - Serviços Remotos).

NS-3.1 Preparar para a implantação do Firewall do Azure

A implantação do Firewall do Azure requer topologia de rede adequada, permitindo a inspeção centralizada de tráfego entre os limites da rede. As arquiteturas Hub-and-spoke posicionam o firewall no núcleo da rede, encaminhando todo o tráfego das ligações através de um ponto de inspeção central, enquanto as rotas definidas pelo utilizador garantem que o fluxo de tráfego siga os caminhos pretendidos. Esta preparação estabelece a base para uma proteção de borda abrangente e filtragem entre segmentos.

Prepare a infraestrutura de rede para a implantação do Firewall do Azure:

• Configurar a topologia de rede virtual hub/spoke: Implantar o Azure Firewall num hub VNet para gerir centralmente e proteger o tráfego em várias spoke VNets hospedando cargas de trabalho de aplicações, estabelecendo um ponto único de aplicação para políticas de segurança de rede.

• ** Conecte redes virtuais spoke: Use o emparelhamento de VNets para ligar cada VNet spoke ao hub VNet onde o Azure Firewall está implementado, permitindo comunicação entre spokes através do hub, mantendo o isolamento da rede.

• Configurar rotas definidas pelo usuário (UDRs): Crie tabelas de rotas direcionando o tráfego de rede das VNets spoke por meio do Firewall do Azure na rede hub, incluindo rotas para saída de internet (0.0.0.0/0) e, opcionalmente, para tráfego entre spokes, caso a comunicação entre spokes exija inspeção.

NS-3.2 Implantar o Firewall do Azure com políticas apropriadas

O Firewall do Azure fornece filtragem de tráfego de camada de aplicativo com monitoração de estado com gerenciamento centralizado de políticas em segmentos de rede corporativa. Ao combinar regras de rede, regras de aplicativos e inteligência contra ameaças, os firewalls inspecionam os fluxos de tráfego em várias camadas, enquanto a filtragem de URL e a inspeção TLS permitem o controle granular sobre comunicações HTTP/HTTPS. O design adequado da política equilibra os requisitos de segurança com as necessidades operacionais por meio de hierarquias de regras estruturadas e filtragem baseada em categorias.

Implante e configure o Firewall do Azure com políticas abrangentes:

• Implantar o Firewall do Azure na VNet do hub: Implante o Firewall do Azure (camada Standard ou Premium com base nos recursos necessários) na VNet do hub, atribuindo endereços IP públicos para tráfego destinado à Internet e endereços IP privados para roteamento interno de VNets de spoke.

• Crie políticas de firewall com regras de filtragem: Defina políticas de Firewall do Azure contendo regras de rede (filtragem baseada em IP/porta), regras de aplicativo (filtragem baseada em FQDN) e regras de inteligência de ameaças, organizando regras em coleções com base em requisitos de segurança (por exemplo, permitir serviços críticos para os negócios, bloquear IPs mal-intencionados, negar categorias de risco).

• Configure a filtragem de URL para tráfego HTTP/HTTPS: Implemente regras de aplicativo baseadas em FQDN para permitir ou negar domínios específicos (por exemplo, permitir *.microsoft.com, negar *.torrent) e configure a filtragem baseada em categorias para bloquear categorias inteiras de sites (por exemplo, Hacking, Mídias Sociais) enquanto permite categorias relacionadas ao trabalho.

• Habilite a inspeção TLS para filtragem avançada: Para implantações de camada Premium, habilite a inspeção TLS carregando certificados no Cofre de Chaves do Azure, permitindo que o firewall descriptografe, inspecione e criptografe novamente o tráfego HTTPS para uma filtragem de URL mais profunda e deteção de ameaças além da inspeção baseada em SNI.

Exemplo de implementação

Uma organização com múltiplos workloads de aplicações em diferentes VNets spoke precisava de inspeção de segurança de rede centralizada para todo o tráfego destinado à Internet e comunicações entre spoke enquanto impedia o acesso a domínios maliciosos e categorias de sites não autorizados.

Desafio: A organização tinha workloads implantadas em VNets de spoke separados com acesso direto à Internet, o que resultava na criação de políticas de segurança inconsistentes e na incapacidade de inspeccionar centralmente o tráfego. Cada spoke tinha suas próprias regras NSG, levando ao desvio de política e lacunas de segurança. Não havia visibilidade de conexões de saída para domínios potencialmente maliciosos, nenhuma capacidade de bloquear categorias de sites arriscadas (mídia social, compartilhamento de arquivos) e nenhuma inspeção de conteúdo de tráfego HTTPS. O tráfego entre segmentos fluiu livremente sem inspeção, permitindo um potencial movimentação lateral depois de um comprometimento.

Abordagem da solução:

• Topologia Hub-and-spoke com firewall centralizado: Implantou o Azure Firewall Premium num hub VNet (10.0.0.0/16) com AzureFirewallSubnet dedicada (10.0.1.0/26, IP privado do firewall 10.0.1.4), estabelece um único ponto de imposição para a inspeção do tráfego de rede e gerenciamento de políticas.
• Emparelhamento VNet para conectividade falada: Usado o emparelhamento VNet para conectar a VNet spoke do aplicativo (10.1.0.0/16) e a VNet spoke do banco de dados (10.2.0.0/16) à VNet do hub, permitindo o roteamento centralizado do tráfego através do firewall.
• Rotas definidas pelo utilizador para a orientação do tráfego: Criou tabelas de rotas em cada VNet spoke redirecionando todo o tráfego ligado à Internet (0.0.0.0/0) e o tráfego entre raios para o IP privado do Firewall do Azure (10.0.1.4), forçando toda a saída pelo ponto de inspeção central.
• Políticas de firewall com filtragem multicamadas: Definiu políticas abrangentes do Firewall do Azure , incluindo regras de rede (permitir DNS UDP/53 para DNS do Azure, negar todos os outros protocolos por padrão), regras de aplicativo (permitir FQDNs críticos para os negócios como *.microsoft.com, negar domínios de compartilhamento de arquivos como *.torrent) e regras de inteligência de ameaças (bloquear IPs mal-intencionados conhecidos de feeds de ameaças do Microsoft Defender).
• Filtragem de URL e bloqueio baseado em categorias: Implementei regras de aplicativos baseadas em FQDN para controle preciso de domínio e filtragem baseada em categorias para bloquear categorias inteiras de sites (Hacking, Mídias Sociais, Jogos) enquanto permitia categorias relacionadas ao trabalho (Negócios/Economia, Tecnologia/Internet), aplicando políticas de uso aceitáveis na borda da rede.
• Inspeção TLS para tráfego HTTPS:Inspeção TLS habilitada com certificados armazenados no Cofre de Chaves do Azure, permitindo que o firewall descriptografe, inspecione e criptografe novamente o tráfego HTTPS para filtragem de URL mais profunda e deteção de ameaças além da inspeção baseada em SNI, excluindo domínios bancários confidenciais da descriptografia de acordo com os requisitos de conformidade.

Resultado: A organização estabeleceu visibilidade e controle centralizados sobre todo o tráfego destinado à Internet e entre spoke, eliminando desvios de políticas e pontos cegos de segurança. A inspeção TLS permitiu a deteção de ameaças ocultas no tráfego HTTPS criptografado, enquanto a filtragem baseada em categoria reduziu substancialmente a exposição a conteúdo da Web arriscado. A arquitetura hub-and-spoke forneceu uma postura de segurança escalável e consistente em todas as cargas de trabalho com gerenciamento unificado de políticas e proteção abrangente contra ameaças.

Nível de criticidade

Deve ter.

Mapeamento de controle

• NIST SP 800-53 Rev.5: SC-7, SC-7(5), AC-4, SI-4(4)
• PCI-DSS v4: 1.2.1, 1.3.1, 1.4.1, 1.4.2
• Controles CIS v8.1: 9.2, 9.3, 13.1
• NIST CSF v2.0: PR. AC-05, PR. PT-04, DE. CM-01
• ISO 27001:2022: A.8.20, A.8.22
• SOC 2: CC6.1, CC6.6, CC7.2

NS-4: Implante sistemas de deteção e prevenção de intrusão (IDS/IPS)

Princípio da segurança

Utilize sistemas de deteção e prevenção de intrusões de rede (IDS/IPS) para inspecionar a rede e o tráfego de carga útil de e para a sua carga de trabalho ou redes virtuais. Certifique-se de que o IDS/IPS esteja sempre ajustado para fornecer alertas de alta qualidade à sua solução SIEM.

Nota: Para obter uma capacidade mais detalhada de deteção e prevenção ao nível do host, utilize um IDS/IPS baseado em host ou uma solução de deteção e resposta de endpoint (EDR) também baseada em host, em conjunto com o IDS/IPS de rede.

Risco a mitigar

Os adversários exploram vulnerabilidades em protocolos, aplicativos e tráfego interno para executar atividades maliciosas.

• Explorações de protocolo: Vulnerabilidades em protocolos como RDP (TCP 3389) ou HTTP/HTTPS (TCP 80/443) permitem acesso não autorizado ou comprometimento do sistema por meio de exploits como ataques direcionados ao CVE.
• Comunicações de comando e controlo (C2): Servidores mal-intencionados estabelecem controle sobre dispositivos comprometidos por meio de consultas DNS ou retornos de chamada baseados em IP, facilitando a exploração persistente ou a propagação de malware.
• Explorações de aplicativos: Ataques como injeção de SQL, cross-site scripting (XSS) ou estouros de buffer têm como alvo vulnerabilidades de aplicativos para roubar dados ou executar código arbitrário.
• Movimento lateral: Tráfego interno anômalo, como enumeração SMB (TCP 445) ou abuso de tíquete Kerberos (TCP 88), sinaliza a rotação do invasor dentro da rede.
• Exfiltração de dados: Transferências de dados não autorizadas ocorrem através de canais criptografados (por exemplo, HTTPS POSTs) ou saída de alto volume, usando ofuscação para evitar a deteção.

MITRE ATT&CK

• Acesso Inicial (TA0001): intrusões não autorizadas através de exploits visando vulnerabilidades de rede (por exemplo, T1190 - Exploit Public-Facing Application).
• Execução (TA0002): execução de código malicioso a partir de exploits de vulnerabilidade ou cargas úteis C2 (por exemplo, T1059 - Command and Scripting Interpreter).
• Comando e Controlo (TA0011): comunicações C2 de malware utilizando consultas DNS ou callbacks baseados em IP (por exemplo, T1071 - Application Layer Protocol).
• Movimento Lateral (TA0008): tráfego interno anómalo (por exemplo, enumeração SMB) que indica movimento de pivotagem (por exemplo, T1021 - Serviços Remotos).
• Exfiltração (TA0010): transferências de dados não autorizadas através de canais encriptados ou ofuscados (por exemplo, T1041 - Exfiltração através do Canal C2).

NS-4.1 Implantar o Firewall Premium do Azure para IDPS

Os sistemas de deteção e prevenção de intrusões fornecem identificação de ameaças baseada em assinaturas, combinando padrões de tráfego de rede com assinaturas de ataques conhecidos, permitindo o bloqueio em tempo real de tentativas de exploração e comunicações maliciosas. O recurso IDPS do Azure Firewall Premium oferece bibliotecas de assinaturas continuamente atualizadas, abrangendo as categorias de exploits, malware, controlo e comando, e phishing, enquanto suporta os modos de alerta apenas e prevenção. A seleção e o ajuste adequados de assinaturas garantem a deteção de elevada fidelidade enquanto se minimizam os falsos positivos.

Implante e configure o IDPS por meio do Firewall Premium do Azure:

• Implante o Firewall Premium do Azure: Implante o Firewall Premium do Azure com Política Premium em sua VNet de hub para habilitar os recursos IDPS juntamente com outros recursos avançados, como inspeção TLS e filtragem de URL.

• Selecione as regras de assinatura do IDPS: Escolha regras de assinatura IDPS na biblioteca de assinaturas com base nas prioridades de ameaças, começando com assinaturas de alta gravidade em categorias críticas como "Malware", "Exploits" e "Phishing" que se alinham com o perfil de ameaça e a tolerância ao risco da sua organização.

• Configure o modo IDPS: Defina o modo IDPS para o modo Alerta inicialmente para teste e ajuste para observar correspondências de assinatura sem bloquear o tráfego e, em seguida, faça a transição para o modo Alerta e Negação para ambientes de produção para prevenir ativamente as ameaças detetadas enquanto mantém alertas para monitoramento de segurança.

• Ajuste as assinaturas: Ajuste as regras de assinatura individuais com base na experiência operacional, desativando ou reduzindo a prioridade das assinaturas que geram falsos positivos excessivos enquanto garante que as assinaturas de alta prioridade permaneçam ativas, otimizando a relação sinal-ruído para as equipes de operações de segurança.

Exemplo de implementação

Uma organização precisava proteger a infraestrutura crítica contra exploits conhecidos e ataques de dia zero, mantendo a visibilidade da atividade de ameaças sem interromper as operações comerciais legítimas.

Desafio: A organização operava um aplicativo Web de várias camadas processando transações financeiras sem deteção de ameaças baseada em assinatura além das regras básicas de firewall. As equipes de segurança não tinham visibilidade das tentativas de exploração direcionadas a servidores de aplicativos, não tinham capacidade de detetar comunicações de comando e controle e experimentavam alertas falsos positivos de soluções IDS genéricas que exigiam ajustes extensivos.

Solution:

• Azure Firewall Premium com IDPS: Implantou o Firewall Premium do Azure na VNet de hub, habilitando recursos de IDPS juntamente com inspeção TLS e filtragem de URL, estabelecendo deteção centralizada de ameaças baseada em assinatura para todo o tráfego de VNet falado.

• Seleção da regra de assinatura:Selecionou assinaturas IDPS de alta gravidade de categorias críticas, incluindo Malware (Cobalt Strike, Metasploit, ransomware C2), Exploits (PaperCut CVE-2023-27350, Log4Shell, ProxyShell), Phishing (coleta de credenciais) e padrões de Comando e Controle.

• Modo de alerta e afinação: Configurado o IDPS no modo de alerta para testes iniciais, mantendo as assinaturas CVE de alta prioridade ativas, para observar correspondências de assinatura sem bloquear o tráfego de rede, analisando alertas para identificar falsos positivos de ferramentas legítimas de DevOps e chamadas de API de parceiros e depois criando exceções de assinaturas para cenários conhecidos como bons.

• Transição do modo de prevenção: Transição do IDPS para o modo de alerta e negação para produção após a validação, bloqueando ativamente as ameaças detetadas, incluindo tentativas de exploração do PaperCut, ataques Log4Shell e comunicações C2.

• Integração Sentinel: Configurou logs de diagnóstico para o Log Analytics, criou regras analíticas do Sentinel correlacionando deteções de IDPS com eventos de autenticação e estabeleceu a criação automatizada de incidentes para alertas de alta gravidade.

Resultado: As tentativas de exploração foram bloqueadas com êxito, impedindo a execução remota de código. A exploração de vulnerabilidades críticas foi eliminada antes do comprometimento. As taxas de falsos positivos diminuíram significativamente, mantendo uma cobertura completa de CVE. As equipes de segurança alcançaram uma rápida revisão de alertas e resposta a incidentes, estabelecendo visibilidade contínua de ameaças com inteligência acionável para defesa proativa.

Nível de criticidade

Deve ter.

Mapeamento de controle

• NIST SP 800-53 Rev.5: SI-4, SI-4(4), SI-4(5), SC-7(5)
• PCI-DSS v4: 11.4.1, 11.4.2, 1.4.1
• Controles CIS v8.1: 13.2, 13.6, 13.7
• NIST CSF v2.0: DE. CM-01, DE. CM-04, DE. CM-07
• ISO 27001:2022: A.8.16, A.8.22, A.5.24
• SOC 2: CC6.1, CC7.2

NS-5: Implantar a proteção DDOS

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

Princípio da segurança

Implante proteção contra DDoS em vários níveis para mitigar efetivamente ataques direcionados a diferentes serviços e protocolos na rede e nas camadas de aplicativos.

Risco a mitigar

Os agentes de ameaças atacam redes, servidores ou aplicativos usando tráfego mal-intencionado avassalador para causar interrupção do serviço.

• Ataques volumétricos (inundação da rede): Os atacantes inundam as interfaces de rede com enormes volumes de tráfego (por exemplo, milhões de pacotes por segundo) para esgotar a largura de banda, a capacidade de processamento do roteador ou os recursos do balanceador de carga, causando indisponibilidade do serviço. Os exemplos incluem inundações UDP, inundações ICMP ou ataques de reflexão DNS amplificados utilizando protocolos como NTP ou SSDP.
• Ataques de protocolo (exaustão do estado): Os atacantes exploram as vulnerabilidades dos protocolos das Camadas 3 e 4 para esgotar recursos com estado, como tabelas de conexão TCP ou estados de sessão de firewall. As técnicas comuns incluem ataques de inundação TCP SYN, que sobrecarregam servidores com conexões semiabertas, ou ataques de inundação ACK direcionados a dispositivos baseados em estado.
• Ataques da camada de recursos (sobrecarga do aplicativo): Ataques limitados de Camada 7, como inundações HTTP GET/POST, visam recursos de aplicativos (por exemplo, CPU, memória ou conexões de banco de dados) para sobrecarregar servidores Web ou APIs. Esses ataques visam esgotar os recursos de computação, causando picos de latência ou interrupções.
• Ataques de amplificação: Os atacantes exploram servidores mal configurados (por exemplo, servidores DNS, NTP ou Plex Media no UDP 32414) para amplificar o tráfego, enviando pequenas consultas que geram grandes respostas direcionadas ao alvo, sobrecarregando a capacidade da rede. Os exemplos incluem amplificação de DNS ou ataques de reflexão SSDP.

MITRE ATT&CK

• Impacto (TA0040): interrompe a disponibilidade do serviço por meio de inundações volumétricas (por exemplo, UDP/ICMP) ou sobrecargas de recursos (por exemplo, inundações HTTP) para negar acesso (por exemplo, T1498 - Network Denial of Service).
• Desenvolvimento de Recursos (TA0042): aproveita sistemas comprometidos para ataques de amplificação (por exemplo, reflexão DNS/NTP) para ampliar o impacto do ataque (por exemplo, T1584 - Infraestrutura Comprometida).

NS-5.1 Implemente a proteção DDOS na camada de rede apropriada

Implante proteção contra DDoS nas camadas de rede e aplicativo para se defender contra ataques volumétricos e específicos de aplicativos. O Azure fornece vários níveis de proteção: Proteção de Rede DDoS para cobertura abrangente de redes virtuais com suporte de resposta rápida, Proteção IP contra DDoS para proteção econômica de IPs individuais e proteção da camada de aplicativos por meio do WAF. Configure o monitoramento e os alertas para validar a eficácia da proteção e garantir a resiliência do aplicativo durante ataques:

• Implante a proteção contra DDoS da camada de rede: Escolha entre Proteção de Rede DDoS para implantações de carga de trabalho que exigem cobertura abrangente de VNet e suporte de resposta rápida para investigação de ataques e análise pós-ataque ou Proteção IP DDoS para proteção econômica de um número limitado de IPs sem suporte de resposta rápida.

• Implante a proteção contra DDoS da camada de aplicativo: Habilite a proteção contra DDoS no Firewall de Aplicativo Web do Azure (WAF), no Gateway de Aplicativo ou na Porta Frontal do Azure para se defender contra ataques da camada de aplicativo (Camada 7).

• Configure o monitoramento e os alertas: Configure alertas e monitore métricas e logs do serviço de proteção contra DDoS e seus aplicativos para garantir a eficácia da proteção, a resiliência do aplicativo e o desempenho desejado durante e após ataques.

Exemplo de implementação

Uma organização de comércio eletrônico precisava de proteção abrangente contra DDoS para aplicativos voltados para o cliente que experimentam crescentes tentativas de ataques volumétricos e na camada de aplicativos durante as altas temporadas de compras.

Desafio: A organização operava uma plataforma global de comércio eletrônico com aplicativos web voltados para o público, APIs e infraestrutura de entrega de conteúdo exposta à internet. Durante os eventos de pico, a plataforma sofreu vários ataques DDoS, incluindo ataques de inundação UDP, ataques de inundação TCP SYN que exauriram as tabelas de conexão do balanceador de carga, ataques de inundação HTTP destinados às APIs de checkout e ataques de amplificação de DNS. Sem proteção DDoS dedicada, esses ataques causaram interrupções de serviço, resultando em perda de receita e insatisfação do cliente.

Solution:

• Proteção de rede DDoS: Proteção de Rede DDoS do Azure habilitada em redes virtuais de produção que hospedam aplicativos voltados para o cliente, fornecendo proteção abrangente em nível de rede virtual com ajuste adaptável, deteção automática de ataques nas camadas 3 e 4 e mitigação em tempo real.

• Proteção da camada de aplicação: Implantou o Gateway de Aplicativo do Azure com WAF para aplicativos regionais e o Azure Front Door com WAF para entrega de borda global, habilitando a proteção contra DDoS de Camada 7 com limitação de taxa, deteção de inundação HTTP e regras de proteção de bot.

• Configuração da política de proteção: Criou um plano de proteção contra DDoS associando todas as redes virtuais de produção, configurou padrões de tráfego de linha de base de aprendizagem de ajuste adaptável, habilitou o monitoramento de tráfego sempre ativo e definiu políticas de proteção que abrangem inundações UDP, inundações TCP SYN, inundações ICMP e ataques de protocolo.

• Monitorização e alerta: Configuraram logs de diagnóstico DDoS enviando telemetria de ataque para o espaço de trabalho do Log Analytics, criaram alertas do Azure Monitor acionando notificações imediatas quando ataques foram detetados, estabeleceram pasta de trabalho do Sentinel correlacionando ataques DDoS com métricas de desempenho de aplicativos e configuraram o Application Insights monitorando a integridade do aplicativo durante a mitigação.

• Envolvimento de resposta rápida:Resposta rápida contra DDoS ativada que fornece acesso direto a especialistas em proteção contra DDoS durante ataques ativos para análise de ataques em tempo real, desenvolvimento de estratégias de mitigação personalizadas e perícia forense pós-ataque.

Resultado: Os ataques DDoS durante a alta temporada de compras foram mitigados com sucesso com zero interrupções de serviço. Inundações volumétricas, inundações SYN e inundações HTTP foram bloqueadas automaticamente, mantendo a disponibilidade da plataforma. O Rapid Response forneceu análises especializadas para ataques sofisticados. Os períodos críticos de compras mantiveram um elevado tempo de atividade sem qualquer latência nas transações dos clientes, mesmo durante as fases de mitigação.

Nível de criticidade

Deve ter.

Mapeamento de controle

• NIST SP 800-53 Rev.5: SC-5, SC-5(1), SC-5(2), SI-4(4)
• PCI-DSS v4: 6.4.2, 11.4.7
• Controles CIS v8.1: 13.3
• NIST CSF v2.0: PR. PT-05, DE. CM-01
• ISO 27001:2022: A.8.13, A.8.24
• SOC 2: CC6.1, CC7.2

NS-6: Implante o firewall de aplicativos Web

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

Princípio da segurança

Implante um firewall de aplicativo Web (WAF) e configure regras para proteger aplicativos Web e APIs contra ataques específicos de aplicativos inspecionando, detetando e filtrando tráfego HTTP/HTTPS mal-intencionado.

Risco a mitigar

Os atacantes exploram vulnerabilidades de aplicações Web para obter acesso não autorizado, executar código malicioso, roubar credenciais ou exfiltrar dados.

• Ataques de injeção (por exemplo, injeção de SQL, injeção de comando): Os invasores exploram vulnerabilidades de validação de entrada para injetar código mal-intencionado em consultas ou comandos de aplicativos da Web, permitindo acesso não autorizado ao banco de dados, exfiltração de dados ou comprometimento do sistema. A injeção de SQL (SQLi) manipula consultas de back-end (por exemplo, anexando ' OR '1'='1 a um formulário de login), enquanto a injeção de comandos executa comandos arbitrários do sistema operacional (por exemplo, ; rm -rf / através de um campo de formulário).
• Violações do protocolo HTTP e solicitações malformadas: Os atacantes enviam solicitações HTTP malformadas (por exemplo, cabeçalhos inválidos, cargas úteis superdimensionadas ou métodos não padrão como TRACE) para explorar vulnerabilidades em servidores ou aplicativos da Web, potencialmente causando falhas ou acesso não autorizado. Esses ataques têm como alvo servidores mal configurados ou estruturas não corrigidas.
• Ataques impulsionados por bots (por exemplo, preenchimento de credenciais, scraping): bots automatizados lançam ataques de preenchimento de credenciais (por exemplo, pontos de extremidade de login de força bruta com credenciais roubadas) ou raspam conteúdo confidencial (por exemplo, dados de preços), sobrecarregando servidores ou comprometendo contas de usuários. Esses ataques exploram autenticação fraca ou APIs desprotegidas.
• Explorações específicas do aplicativo (por exemplo, inclusão de arquivo remoto, inclusão de arquivo local): Os atacantes exploram vulnerabilidades para incluir ficheiros maliciosos (por exemplo, incluir 'http://evil.com/shell.php') ou aceder a ficheiros do servidor local (por exemplo, .. /.. /etc/passwd) através de parâmetros de URL manipulados ou entradas de formulário, permitindo a execução de código ou exposição de dados.

MITRE ATT&CK

• Acesso inicial (TA0001): Explora a injeção de SQL, XSS ou inclusão remota de arquivos para obter entrada (por exemplo, T1190 - Exploit Public-Facing Application).
• Execução (TA0002): Executa código malicioso através de injeção de comando, RFI ou XSS (por exemplo, T1059 - Command and Scripting Interpreter).
• Acesso a credenciais (TA0006): Rouba credenciais através de XSS ou preenchimento de credenciais (por exemplo, T1539 - Steal Web Session Cookie, T1110 - Brute Force).
• Coleção (TA0009): Reúne dados via injeção ou raspagem de SQL (por exemplo, T1213 - Dados de repositórios de informações).

NS-6.1 Configurar o Azure WAF com regras apropriadas

Habilite os recursos de firewall de aplicativo Web (WAF) no Gateway de Aplicativo do Azure, na Porta da Frente do Azure ou na CDN (Rede de Entrega de Conteúdo) do Azure para proteger aplicativos e APIs contra ataques baseados na Web. Selecione o serviço apropriado com base nos requisitos do aplicativo, configure as políticas WAF com regras internas e personalizadas, defina o modo de política com base na postura de segurança e associe a política ao ponto de extremidade do serviço:

• Selecione o serviço WAF apropriado: Escolha Azure Application Gateway para aplicativos hospedados em rede virtual, Azure Front Door para entrega de borda global ou CDN do Azure para cargas de trabalho com muito conteúdo com base nos requisitos e na arquitetura do aplicativo.

• Configure políticas WAF com regras internas e personalizadas: Comece com conjuntos de regras internos comuns, como o OWASP Core Rule set (CRS 3.2) e as regras de proteção de bot (Microsoft Bot Manager). Adicione regras personalizadas (por exemplo, limitação de taxa para >100 solicitações/min) e exclusões para reduzir falsos positivos com base no cenário de ameaças e no perfil de segurança do aplicativo.

• Defina o modo de política WAF: Use o modo de deteção inicialmente ou para aplicativos não críticos para evitar interromper o tráfego legítimo durante a configuração e a otimização de regras. Mude para o modo de prevenção para aplicações críticas assim que as regras forem validadas para bloquear pedidos maliciosos.

• Associe a política WAF ao ponto de extremidade do serviço: Associe a política WAF ao Application Gateway, Front Door ou CDN endpoint para garantir que todo o tráfego HTTP/HTTPS seja roteado através do WAF para inspeção.

Exemplo de implementação

Uma organização precisava proteger aplicativos Web e APIs voltados para o cliente contra injeção de SQL, ataques XSS e preenchimento de credenciais orientado por bot, mantendo o desempenho para usuários legítimos.

Desafio: A organização tinha aplicativos da Web implantados globalmente sem proteção contra as 10 principais vulnerabilidades do OWASP, resultando em várias tentativas de injeção de SQL, ataques orientados por bots sobrecarregando endpoints de login e sem visibilidade de padrões de tráfego mal-intencionados. Os aplicativos não tinham controles de limitação de taxa, permitindo abuso de API e ataques de preenchimento de credenciais, e não havia nenhum mecanismo para distinguir usuários legítimos de bots mal-intencionados.

Abordagem da solução:

• Seleção de serviço WAF: Implantou o Gateway de Aplicativo do Azure com WAF para aplicativos hospedados pela rede virtual e o Azure Front Door com WAF para aplicativos distribuídos globalmente que exigem proteção de borda e acesso de baixa latência.
• Conjuntos de regras de proteção incorporados: Habilitado o OWASP Core Rule set (CRS) 3.2 para proteção contra injeção de SQL, cross-site scripting (XSS), inclusão remota de arquivos e outras vulnerabilidades comuns da Web, e ativado as regras do Microsoft Bot Manager para identificar e bloquear bots mal-intencionados, permitindo rastreadores legítimos do mecanismo de pesquisa e serviços de monitoramento.
• Regras personalizadas para ameaças específicas: Implementou regras de limitação de taxa bloqueando clientes que excedem 100 solicitações por minuto para evitar abuso de API e preenchimento de credenciais, regras de filtragem geográfica bloqueando o tráfego de regiões de alto risco onde os serviços não estão disponíveis e regras baseadas na reputação de IP bloqueando solicitações de intervalos de IP mal-intencionados conhecidos identificados por meio de feeds de inteligência de ameaças.
• Gestão da exclusão: Criei exclusões direcionadas para cenários de negócios legítimos, como pontos de extremidade /checkout com entradas de formulário complexas que acionaram falsos positivos nas regras OWASP, pontos de extremidade /upload lidando com envios de arquivos grandes e pontos de extremidade /api com padrões de cabeçalho incomuns, mas válidos, de aplicativos móveis.
• Transição da deteção para a prevenção: Iniciou o WAF no modo de deteção por duas semanas para identificar falsos positivos, refinou regras e exclusões com base em padrões de tráfego legítimos e, em seguida, fez a transição para o modo de prevenção para aplicativos de produção para bloquear ativamente as ameaças, mantendo a continuidade dos negócios.

Resultado: A organização eliminou as tentativas de injeção de SQL e de exploração de XSS, reduziu substancialmente os ataques orientados por bot por meio de regras do gerenciador de bots e estabeleceu uma visibilidade abrangente das ameaças de aplicativos da Web. Os controles de limitação de taxa evitaram o abuso da API e o preenchimento de credenciais, enquanto a transição em fases do modo de deteção para o modo de prevenção garantiu que os usuários legítimos não sofressem interrupção do serviço.

Nível de criticidade

Deve ter.

Mapeamento de controle

• NIST SP 800-53 Rev.5: SC-7, SC-7(5), SI-10, SI-10(1), SI-11
• PCI-DSS v4: 6.4.1, 6.4.2, 11.4.7
• Controles CIS v8.1: 13.2, 13.9
• NIST CSF v2.0: PR. AC-05, PR. PT-05, DE. CM-04
• ISO 27001:2022: A.8.20, A.8.22, A.8.25
• SOC 2: CC6.1, CC6.6, CC7.2

NS-7: Gerencie a segurança da rede de forma centralizada e eficaz

Princípio da segurança

Para reduzir o risco operacional e a configuração incorreta em ambientes de rede complexos e fragmentados, use recursos de gerenciamento de rede nativos da nuvem para centralizar, simplificar e impor configurações consistentes de segurança de rede.

Risco a mitigar

A falta de controle centralizado resulta em configurações de segurança negligenciadas ou desatualizadas, aumentando o risco de exploração.

• Aplicação de políticas inconsistente e configurações incorretas: O gerenciamento descentralizado geralmente leva a conjuntos de regras fragmentados e lacunas de políticas, tornando mais fácil para os invasores descobrirem e explorarem pontos fracos. Erros de configuração são mais prováveis, aumentando as chances de exposição acidental ou acesso não intencional.
• Visibilidade reduzida e resposta atrasada: Sem uma abordagem de gestão unificada, a monitorização e a resposta a incidentes tornam-se mais lentas e menos eficazes. Isso pode atrasar a deteção de atividades maliciosas, permitindo que os invasores tenham mais tempo para escalar ataques ou exfiltrar dados.
• Dificuldade em manter a conformidade: Uma gestão central inadequada complica os esforços para cumprir consistentemente as normas regulamentares e da indústria, correndo o risco de não conformidade e potenciais sanções.

MITRE ATT&CK

• Acesso inicial (TA0001): Exploração de configurações incorretas ou configurações de segurança desatualizadas para obter acesso não autorizado (por exemplo, T1190 - Exploit Public-Facing Application, T1133 - External Remote Services).
• Evasão de Defesa (TA0005): Aproveitando conjuntos de regras fragmentados e falta de monitoramento centralizado para evitar a deteção (por exemplo, T1562 - Impair Defenses).
• Movimento Lateral (TA0008): Movendo-se lateralmente através da rede, explorando lacunas de política ou segmentação desatualizada (por exemplo, T1021 - Serviços Remotos).
• Comando e Controlo (TA0011): Usando caminhos de rede não monitorados ou mal configurados para estabelecer e manter canais C2 (por exemplo, T1071 - Application Layer Protocol).

NS-7.1 Gerencie a segurança da rede de forma centralizada e eficaz

Use as ferramentas centralizadas e as práticas padronizadas do Azure para simplificar e dimensionar o gerenciamento de segurança de rede, garantindo uma aplicação consistente, a redução de erros de configuração e um monitoramento aprimorado. Implemente a aplicação centralizada de políticas, padronize o gerenciamento de firewall e roteamento, permita monitoramento e análise abrangentes e mantenha a consistência de recursos por meio de práticas de governança:

• Implemente a aplicação centralizada de políticas: Use o Azure Virtual Network Manager (AVNM) para definir Regras de Administração de Segurança que se aplicam consistentemente entre assinaturas e regiões. Retenha NSGs para microssegmentação em nível de carga de trabalho. Aplique políticas por meio de grupos de rede (por exemplo, por ambientes: de produção, de não-produção).

• Padronize o firewall e o gerenciamento de roteamento: Gerencie regras do Firewall do Azure por meio do Gerenciador de Firewall com objetos de Política de Firewall. Padronize em grupos de IP e tags de serviço em vez de IPs brutos. Use o Firewall Premium do Azure onde a inspeção TLS, IDPS e filtragem de URL são necessárias. Prefira hubs seguros de WAN virtual ou uma topologia de hub-and-spoke compartilhada para impor a intenção de roteamento de forma consistente.

• Habilite monitorização e análise abrangentes: Use logs de fluxo de rede virtual v2 (para substituir os logs de fluxo NSG). Habilite os logs de diagnóstico do Firewall do Azure e integre-os ao Traffic Analytics, ao Log Analytics e ao Microsoft Sentinel. Utilize a Análise de Política de Firewall e as contagens de acessos às regras para eliminar regras não utilizadas ou duplicadas.

• Manter a consistência e a governança dos recursos: Aplique convenções de nomenclatura CAF e tags de recursos obrigatórios a todas as redes virtuais, NSGs, regras de firewall e grupos. Use o Adaptive Network Hardening do Defender for Cloud para refinar regras excessivamente permissivas.

Exemplo de implementação

Caso de uso: Plataforma de pagamento multirregional consolida a segurança da rede em escala

Contexto: Um processador de pagamento de médio porte operando no Leste dos EUA e na Europa Ocidental com 4 assinaturas (Prod, Non-Prod, Shared Services, SecOps) sob um locatário precisa de segmentação PCI-DSS, menos incidentes de desvio de regras e monitoramento centralizado.

Aplicação centralizada de políticas com o Azure Virtual Network Manager:

• Conceção: Crie o AVNM no nível do grupo de gerenciamento. Defina dois grupos de rede: ng-prod e ng-nonprod com associação dinâmica pela tag subscriptionId. Crie Regras de Administração de Segurança (SARs) para impor guardrails organizacionais que avaliam antes dos NSGs: Deny-Inbound-Internet-to-Spokes (bloqueia a entrada não solicitada da Internet para todas as sub-redes faladas), Allow-Hub-Infra (permite serviços de hub - Firewall/Bastion - em porta-vozes), Allow-Platform-DNS (permite DNS de resolvedores de hub para porta-vozes).
• Limites da equipa da aplicação: As cargas de trabalho mantêm NSGs para micro-segmentação (por exemplo: web para api: 443, api para db: 1433) dentro de cada spoke. As alterações do NSG pertencem às equipes de aplicativos; As SARs são de propriedade da equipe de segurança da plataforma.
• Resultado: Os guarda-corpos são consistentes em ambas as regiões; as equipes de aplicativos não podem criar acidentalmente acesso direto à Internet, mesmo que um NSG esteja configurado incorretamente.

Firewall e gerenciamento de roteamento com o Firewall Manager e a WAN Virtual:

• Conceção: Implante hubs seguros de WAN virtual em cada região (Leste dos EUA, Europa Ocidental). Anexe spokes ao hub mais próximo e ative a intenção de encaminhamento para que todas as saídas da Internet sejam inspecionadas. Use o Gestor de Firewall com uma Política de Firewall global (Camada: Premium) e duas políticas filhas (Prod/Não-Prod) para substituições de ambiente.
• Estrutura política: A política básica (global) inclui Threat Intelligence definido como Alert + Deny, inspeção TLS habilitada para HTTPS de saída, IDPS ativado no modo balanceado e regras de permissão de saída usando tags de serviço (Storage, KeyVault, AzureMonitor) e grupos IP para pontos de extremidade parceiros. A política de subconfiguração Prod tem filtragem de URL mais rigorosa (bloqueando URLs não categorizados) e uma lista de permissão para gateways de pagamento via Grupos de IP. A política de Não-Produção tem acesso mais abrangente às ferramentas de desenvolvimento por meio de Tags de Serviço (AzureDevOps, AzureContainerRegistry).
• Resultado: Painel único para gerenciar regras com alterações propagadas para ambos os hubs. O roteamento é consistente e todo o tráfego de saída é inspecionado com desencriptação de TLS quando permitido.

Monitoramento e análise com Flow Logs v2 e Sentinel:

• Configuração de telemetria: Habilite os Logs de Fluxo de Rede Virtual v2 em todas as redes virtuais e envie para um espaço de trabalho central do Log Analytics na assinatura do SecOps. Configure os logs de diagnóstico do Firewall do Azure (Aplicativo, Rede, DNS, ThreatIntel, IDPS) no mesmo espaço de trabalho. Ative a Análise de Tráfego no espaço de trabalho.
• Loop de otimização: Ative a Análise de Políticas de Firewall e revise as contagens de acertos das regras mensalmente. Crie uma pasta de trabalho do Sentinel que correlacione logs de fluxo (norte-sul e leste-oeste), permissões de firewall/negação de acessos e assinaturas IDPS acionadas. Automatizar uma solicitação de alteração se uma regra tiver 0 acessos por 45 dias (candidato a remoção) ou se uma regra de negação for atingida por uma subrede de produção (possível erro de roteamento).
• Resultado: Após dois ciclos de revisão, 18% de regras de firewall e 22 regras NSG obsoletas são removidas, reduzindo a latência de avaliação de regras e o risco de alteração.

Consistência de recursos e governança com CAF e Defender for Cloud:

• Normas: Aplique nomenclatura CAF (por exemplo, vnet-prd-eus-01, nsg-prd-eus-web-01, azfw-policy-global-01) e tags obrigatórias: env, owner, dataClass, costCenter.
• Execução: Use as iniciativas de Política do Azure para exigir NSG em cada sub-rede, exigir configurações de diagnóstico em redes virtuais e Firewall para o espaço de trabalho central de LA e negar a criação sem tags obrigatórias. Ative o Defender for Cloud - Adaptive Network Hardening em todas as filiais com itens de ação semanais revistos na SecOps CAB.
• Resultado: A deriva da plataforma é rapidamente identificada; regras excessivamente permissivas são reforçadas usando as recomendações baseadas em dados do Defender.

Sequência de distribuição e critérios de aceitação:

• Configure hubs seguros vWAN, anexe barras, habilite a intenção de encaminhamento (apenas para raios piloto). Critérios de aceitação: Egressão da conexão do piloto através do firewall; nenhum IP público acessível diretamente.
• Implante SARs AVNM nos ambientes NG não-produtivo, verifique se não há interrupção, e depois no NG produtivo. Critérios de aceitação: Sondas sintéticas confirmam que os serviços de hub (DNS/Bastion) ainda alcançam as ramificações; o acesso à Internet continua a ser negado.
• Ativar vNet Flow Logs v2 e ativar todos os diagnósticos de firewall; integrar a pasta de trabalho do Sentinel. Critérios para aceitação: Os painéis mostram fluxos, acessos negados, incidentes de IDPS por região.
• Aplicar iniciativas políticas; remediar itens não conformes; habilitar o Adaptive Hardening. Critérios de aceitação: A conformidade atinge 95%, e é criado um backlog de itens para atualização das regras de NSG/firewall.
• Primeira revisão do Policy Analytics; Remova as regras não utilizadas através da janela Alterar. Critérios de aceitação: Contagem de regras reduzida em 15% com impacto zero no cliente.

Exemplos de runbooks operacionais:

• SARs do Azure Virtual Network Manager: Negar entrada da Internet para pontos de extremidade (prioridade 100), permitir infraestrutura do hub para pontos de extremidade (prioridade 200: intervalos de hub src 10.0.0.0/16)
• Estrutura da política de firewall: azfw-policy-global-01 (Premium) com coleções de regras "Allow-Azure-Platform-ST" (Service Tags) e "Allow-Partners-IPs" (Grupos IP: ipg-payment-gws), além de políticas subordinadas "azfw-policy-prd-01" e "azfw-policy-npd-01"
• Diagnóstico: Destino: law-secops-01, Categorias: AZFWApplicationRule, AZFWNetworkRule, AZFWIDPS, AZFWThreatIntel, AZFWDnsProxy, FlowLogV2

Nível de criticidade

Deve ter.

Mapeamento de controle

• NIST SP 800-53 Rev.5: CM-2, CM-3, CM-6, CA-7, SI-4
• PCI-DSS v4: 1.4.5, 11.5.1, 12.4.1
• Controles CIS v8.1: 4.1, 4.2, 12.4, 13.6
• NIST CSF v2.0: PR.IP-01, DE.CM-01, DE.CM-07
• ISO 27001:2022: A.8.9, A.8.32, A.5.37
• SOC 2: CC6.6, CC7.2, CC8.1

NS-8: Detetar e desabilitar serviços e protocolos inseguros

Azure Policy: Veja definições de políticas incorporadas Azure: NS-8.

Princípio da segurança

Descubra e desative serviços e protocolos inseguros na camada de SO, aplicativo ou pacote de software. Implante controles de compensação se não for possível desabilitar serviços e protocolos inseguros.

Risco a mitigar

Os agentes de ameaças exploram serviços e protocolos inseguros e vulneráveis para comprometer sistemas e dados.

• Exploração de fraquezas criptográficas: SSL/TLSv1 e cifras fracas (por exemplo, RC4, DES) são vulneráveis a ataques MITM (por exemplo, POODLE, BEAST), permitindo que adversários descriptografem dados confidenciais, como tokens de sessão, por meio de ataques de oráculo de preenchimento ou de texto cifrado escolhido.
• Acesso não autorizado via explorações de protocolo: As vulnerabilidades SSHv1 e SMBv1 (por exemplo, CVE-2001-1473, CVE-2017-0144/EternalBlue) permitem a execução remota de código ou acesso não autenticado, permitindo pontos de apoio iniciais.
• Roubo de credenciais: LM/NTLMv1 e wDigest armazenam hashes fracos ou credenciais de texto simples, vulneráveis a pass-the-hash ou raspagem de memória (por exemplo, Mimikatz extraindo dados LSASS).
• Movimento Lateral: As sessões e exploits não criptografados do SMBv1 (por exemplo, EternalBlue) permitem a propagação de malware ou a retransmissão de credenciais entre redes.

MITRE ATT&CK

• Acesso inicial (TA0001): Exploração de protocolos inseguros como SSL/TLSv1 ou SSHv1, que são vulneráveis a ataques de downgrade de protocolo ou exploits conhecidos, bloqueando a entrada não autorizada (por exemplo, T1190 - Exploit Public-Facing Application).
• Acesso a credenciais (TA0006): Roubo de credenciais explorando LM/NTLMv1 e wDigest, que armazenam credenciais em formatos reversíveis ou hashes fracos, frustrando pass-the-hash ou raspagem de memória (por exemplo, T1003 - OS Credential Dumping).
• Movimento Lateral (TA0008): Inibe o SMBv1 pivotante do invasor, que é vulnerável a exploits como o EternalBlue, impedindo a propagação entre redes (por exemplo, T1021 - Serviços Remotos).

NS-8.1 Detetar e desabilitar serviços e protocolos inseguros

Use a Pasta de Trabalho de Protocolo Inseguro Interna do Microsoft Sentinel para descobrir e mitigar serviços e protocolos inseguros no seu ambiente da Azure. Esta pasta de trabalho identifica o uso de protocolos e serviços que não atendem aos padrões de segurança apropriados, como SSL/TLSv1, SSHv1, SMBv1, LM/NTLMv1, wDigest, cifras fracas em Kerberos e ligações LDAP não assinadas. Após a identificação, desative esses protocolos e serviços inseguros. Quando a desativação não for viável, implemente controles de compensação para reduzir a superfície de ataque.

Descubra protocolos inseguros: Use a pasta de trabalho de protocolo não seguro do Microsoft Sentinel para identificar o uso de SSL/TLSv1, SSHv1, SMBv1, LM/NTLMv1, wDigest, cifras Kerberos fracas e ligações LDAP não assinadas em seu ambiente.

Desative serviços e protocolos inseguros: Desative os serviços e protocolos inseguros identificados que não atendem aos padrões de segurança apropriados para eliminar vulnerabilidades.

Implementar controlos compensatórios: Se a desativação de serviços ou protocolos inseguros não for possível devido a requisitos de negócios ou restrições técnicas, use controles de compensação, como bloquear o acesso a recursos por meio de grupos de segurança de rede, Firewall do Azure ou Firewall de Aplicativo Web do Azure para reduzir a superfície de ataque.

Exemplo de implementação

Uma organização de assistência médica precisava eliminar protocolos inseguros em seu ambiente do Azure para atender aos requisitos de conformidade com a HIPAA e reduzir a superfície de ataque para informações de saúde protegidas.

Desafio: A organização operava uma infraestrutura híbrida com aplicativos herdados que exigiam conectividade com recursos hospedados no Azure. A avaliação de segurança revelou o uso generalizado de protocolos inseguros, incluindo SSL/TLSv1.0 em servidores Web que servem portais de pacientes, SMBv1 habilitado em servidores de arquivos para software de geração de imagens médicas legado, autenticação LM/NTLMv1 em controladores de domínio e servidores de aplicativos, autenticação wDigest armazenando credenciais em formato reversível, ligações LDAP não assinadas em controladores do Ative Directory e criptografia Kerberos fraca em contas de serviço. A organização não tinha visibilidade sobre o uso do protocolo e enfrentava possíveis violações de conformidade com a HIPAA.

Solution:

• Implantação da pasta de trabalho do protocolo inseguro do Sentinel: Implantou o Microsoft Sentinel e instalou a pasta de trabalho de protocolo inseguro a partir do hub de conteúdo, conectou fontes de dados, incluindo logs de eventos de segurança do Windows, logs do Azure Monitor, logs do Ative Directory e logs de fluxo de rede, estabelecendo uma linha de base abrangente do uso de protocolo inseguro em ambiente híbrido.

• Descoberta de protocolo: Pasta de trabalho de protocolo não seguro usada para identificar o uso de SSL/TLSv1.0 em servidores Web, tráfego SMBv1 de estações de trabalho de geração de imagens médicas herdadas, padrões de autenticação LM/NTLMv1, wDigest habilitado em servidores Windows, ligações LDAP não assinadas de aplicativos herdados e criptografia Kerberos RC4 fraca em contas de serviço.

• Protocolo sistemático de desativação: Criou um plano de remediação em fases validado através do conselho consultivo de alterações, desativou o TLSv1.0/1.1 em servidores Web depois de confirmar que os utilizadores do portal do paciente operavam navegadores modernos com suporte TLS 1.2+, desativou o SMBv1 depois de coordenar com atualizações de software do fornecedor de imagiologia médica, fez a transição dos controladores de domínio da autenticação NTLMv1 para NTLMv2, desativou o wDigest através da Política de Grupo, impôs a assinatura LDAP nos controladores de domínio e atualizou a encriptação Kerberos da conta de serviço para AES256.

• Controlos compensatórios das exceções: Implementou controles de compensação baseados em rede para sistemas que exigem suporte temporário a protocolos inseguros, incluindo VLAN isolada para estações de trabalho de geração de imagens médicas legadas que exigem SMBv1, regras NSG que restringem o tráfego SMBv1 exclusivamente a VLAN isolada, Firewall do Azure negando SMBv1 de saída de sub-redes de produção, host de salto dedicado para aplicativos de RH herdados e monitoramento aprimorado por meio do Defender for Endpoint sinalizando o uso do protocolo fora das sub-redes de exceção aprovadas.

• Monitorização contínua: Estabeleceu a higiene contínua do protocolo por meio de regras de análise do Microsoft Sentinel acionando alertas para novas conexões de protocolo inseguras fora das exceções aprovadas, a Política do Azure negando a implantação sem o requisito mínimo do TLS 1.2 e a Pasta de Trabalho de Protocolo Inseguro semanalmente analisa o progresso da correção.

Resultado: Conexões TLS fracas foram eliminadas dos portais dos pacientes. O SMBv1 foi desativado após atualizações de imagens médicas, eliminando a vulnerabilidade do EternalBlue e alcançando a conformidade com a HIPAA. O NTLMv1 fez a transição para o NTLMv2, impedindo ataques pass-the-hash. A desativação do wDigest mitigou o roubo de credenciais. A assinatura LDAP bloqueou consultas não assinadas. Kerberos foi atualizado para AES256, diminuindo o risco de ataques de Kerberoasting (um tipo de ataque de cibersegurança). Os controles de compensação continham sistemas legados com movimento lateral zero. Conformidade total com a HIPAA alcançada.

Nível de criticidade

Deve ter.

Mapeamento de controle

• NIST SP 800-53 Rev.5: SC-8, SC-8(1), SC-13, IA-5(1)
• PCI-DSS v4: 2.2.4, 4.2.1, 6.2.4
• Controles CIS v8.1: 4.8, 9.3, 13.4
• NIST CSF v2.0: PR. DS-02, PR. IP-01, DE. CM-04
• ISO 27001:2022: A.8.24, A.8.26, A.5.14
• SOC 2: CC6.1, CC6.7, CC7.1

NS-9: Conecte-se à rede local ou na nuvem de forma privada

Princípio da segurança

Use conexões privadas para comunicação segura entre diferentes redes, como datacenters de provedores de serviços em nuvem e infraestrutura local em um ambiente de colocation.

Risco a mitigar

Quando os dados trafegam por redes públicas, ficam vulneráveis a intercetação, acesso não autorizado e adulteração.

• Interceção de dados: Quando os dados viajam por redes públicas como a internet, eles passam por vários roteadores, switches e provedores de serviços, qualquer um dos quais pode ser comprometido ou monitorado por atores mal-intencionados. Os invasores podem implantar ferramentas de deteção de pacotes (por exemplo, Wireshark) para capturar pacotes de dados. Se os dados não estiverem criptografados ou fracamente criptografados, informações confidenciais - como credenciais de login, detalhes financeiros ou dados comerciais proprietários - podem ser expostas.
• Ataques Man-in-the-Middle (MitM): Em um ataque MitM, um invasor secretamente interceta e potencialmente altera a comunicação entre duas partes que acreditam estar a comunicar diretamente uma com a outra. Isso representa uma grave ameaça a operações confidenciais, como transações financeiras ou processos de autenticação.
• Acesso não autorizado: Redes públicas ou inadequadamente protegidas aumentam a probabilidade de usuários não autorizados obterem acesso ou adulterarem sistemas ou recursos privados. Os atacantes podem explorar as fraquezas da rede para alcançar a infraestrutura interna que deve permanecer inacessível do exterior.

MITRE ATT&CK

• Acesso inicial (TA0001): Exploração de protocolos não criptografados ou fracamente criptografados (por exemplo, HTTP ou versões desatualizadas de TLS) vulneráveis a deteção de pacotes ou ataques MitM, permitindo a entrada não autorizada em sistemas (por exemplo, T1190 - Exploit Public-Facing Application).
• Acesso a credenciais (TA0006): Roubo de credenciais através de tráfego de rede intercetado, exploração de protocolos de texto não criptografado (por exemplo, Telnet ou FTP) ou criptografia fraca suscetível à descriptografia, facilitando o acesso não autorizado (por exemplo, T1040 - Network Sniffing).
• Movimento Lateral (TA0008): Propagação dentro de redes através da exploração de serviços mal configurados ou expostos (por exemplo, RDP ou SMB sem patch), permitindo que os atacantes pivotem usando credenciais roubadas ou vulnerabilidades (por exemplo, T1021 - Serviços Remotos).

NS-9.1 Use a rede virtual privada (VPN) do Azure para conectividade leve site a site ou ponto a site

Use a VPN (rede virtual privada) do Azure para criar conexões seguras e criptografadas entre sites locais ou dispositivos de usuário final e redes virtuais do Azure para cenários de conectividade leve. A VPN do Azure fornece uma solução económica para conectividade site a site (ligação de redes inteiras) ou conectividade ponto a site (ligação de dispositivos individuais) sem necessidade de infraestrutura dedicada:

• Implante VPN site a site: Use VPN site a site para conectar com segurança sua rede local à rede virtual do Azure, permitindo uma comunicação perfeita entre recursos locais e cargas de trabalho do Azure.

• Implante VPN ponto a site: Use VPN ponto a site para permitir que dispositivos individuais de usuário final (laptops, estações de trabalho) se conectem com segurança à rede virtual do Azure a partir de locais remotos.

NS-9.2 Use o Azure ExpressRoute (ou WAN Virtual) para conexões de alto desempenho de nível empresarial

Use o Azure ExpressRoute ou a WAN Virtual do Azure para estabelecer conexões privadas, de alto desempenho e baixa latência entre os datacenters do Azure e a infraestrutura local em ambientes de colocation. Essas soluções de nível empresarial ignoram a Internet pública, fornecendo largura de banda dedicada, desempenho previsível e segurança aprimorada para cargas de trabalho de missão crítica que exigem conectividade consistente:

• Implante o ExpressRoute para conectividade privada dedicada: Use o Azure ExpressRoute para criar uma conexão privada entre sua infraestrutura local e os datacenters do Azure por meio de um provedor de conectividade, garantindo largura de banda dedicada e latência previsível para cargas de trabalho corporativas.

• Implante a WAN Virtual para conectividade global: Use a WAN Virtual do Azure para criar uma rede global conectando vários sites, filiais e regiões do Azure por meio de uma arquitetura unificada de hub-and-spoke com recursos integrados de segurança e roteamento.

NS-9.3 Usar VNet ou emparelhamento de sub-rede para ingressar em redes virtuais

Use o emparelhamento de rede virtual ou o emparelhamento de sub-rede para estabelecer conectividade privada entre redes virtuais do Azure sem rotear o tráfego pela Internet pública. O tráfego de rede entre redes virtuais emparelhadas permanece na rede de backbone do Azure, fornecendo conexões de baixa latência e alta largura de banda sem sobrecarga de criptografia. Escolha o emparelhamento de sub-rede quando a conectividade de rede virtual completa for desnecessária, limitando a exposição apenas a sub-redes específicas:

• Implante o emparelhamento de rede virtual: Use o emparelhamento de rede virtual para conectar redes virtuais do Azure inteiras, permitindo que recursos em VNets diferentes se comuniquem de forma privada como se estivessem na mesma rede.

Exemplo de implementação

Uma organização multinacional de serviços financeiros precisava de conectividade segura e de alto desempenho entre data centers locais, filiais e recursos de nuvem do Azure, eliminando a exposição pública à Internet para transações financeiras confidenciais.

Desafio: A organização operava vários data centers locais com filiais em todo o mundo, exigindo conectividade com aplicativos hospedados no Azure que processam transações financeiras e dados de clientes. A arquitetura inicial usava VPN site a site pela Internet, experimentando latência imprevisível, limitações de largura de banda durante o horário de pico de negociação, preocupações de segurança sobre dados financeiros atravessando a Internet pública apesar da criptografia e requisitos de conformidade que exigem conectividade privada para PCI-DSS e GDPR. Os funcionários remotos que se conectam via VPN ponto a site tiveram problemas inconsistentes de desempenho e autenticação. Os aplicativos em diferentes regiões do Azure exigiam comunicação entre regiões de baixa latência sem roteamento por meio de hubs locais.

Solution:

• ExpressRoute para conectividade de data center principal: Implantou circuitos Azure ExpressRoute em data centers primários por meio de instalações de colocalização com provedores de conectividade ExpressRoute, estabelecendo conectividade privada de Camada 3 à rede de backbone do Azure com baixa latência consistente, configurou o ExpressRoute com peering da Microsoft para serviços PaaS do Azure e peering privado para recursos hospedados em VNets, implementou o roteamento BGP com configuração ativa-ativa para alta disponibilidade e failover automático.

• VPN site a site para conectividade de filiais: Implantei VPN site a site para filiais sem acesso a instalações de colocalização, criando VPN Gateway em hub VNet com configuração ativo-ativo para alta disponibilidade, configurei túneis IPsec/IKE com forte criptografia atendendo aos padrões de segurança do setor financeiro, implementei roteamento BGP para seleção dinâmica de caminhos permitindo que as filiais se conectassem ao hub regional mais próximo, estabeleci túneis redundantes garantindo conectividade durante as janelas de manutenção.

• VPN ponto a site para funcionários remotos:VPN ponto a site configurada com autenticação do Azure Active Directory para funcionários remotos que exigem acesso seguro a aplicativos hospedados no Azure, a autenticação baseada em certificados é ativada como alternativa para cenários sem acesso à Internet ao Azure AD, endereços IP de cliente atribuídos do pool dedicado encaminhados para recursos VNet do Azure através de rotas definidas pelo utilizador, protocolo OpenVPN implementado para clientes macOS/Linux e IKEv2/SSTP para clientes Windows fornecendo ampla compatibilidade de dispositivos, configuração de túnel dividido permite acesso direto à Internet para tráfego não corporativo enquanto encaminha o tráfego destinado ao Azure através do túnel VPN, otimizando a largura de banda.

• pt-PT: WAN virtual para conectividade de malha global: Implantou a WAN Virtual do Azure com hubs seguros em várias regiões fornecendo arquitetura de trânsito global, conectou circuitos de ExpressRoute a hubs de WAN Virtual permitindo conectividade de qualquer para qualquer entre data centers e regiões do Azure sem roteamento por meio de hubs no local, conexões VPN integradas site a site de filiais para o hub WAN Virtual mais próximo com otimização automática de roteamento, habilitado o Firewall do Azure em cada hub WAN Virtual fornecendo inspeção de segurança centralizada para tráfego entre filiais, centros de dados e redes virtuais do Azure, políticas de encaminhamento configuradas que implementam o encaminhamento de trânsito global, permitindo que as filiais se comuniquem com centros de dados locais através do backbone do Azure.

• Emparelhamento de VNet para conectividade entre regiões do Azure: Implementou emparelhamento de rede virtual conectando VNets spoke a VNets de hub WAN virtual em cada região, habilitou o emparelhamento global de VNet para conectividade de aplicativos entre regiões fornecendo baixa latência no backbone do Azure, configurou o trânsito de gateway permitindo que VNets spoke usem gateways VPN de hub WAN virtual/ExpressRoute sem implantar gateways adicionais reduzindo custos e complexidade, implementou grupos de segurança de rede em sub-redes spoke controlando o fluxo de tráfego entre VNets emparelhadas com acesso com privilégios mínimos.

• Otimização e monitorização de tráfego: circuitos ExpressRoute configurados com marcações de QoS, priorizando o tráfego de transações financeiras em vez de transferências de dados em massa, com o Monitor de Conexão ativado para rastrear a latência, perda de pacotes e disponibilidade dos circuitos ExpressRoute e das conexões VPN, com alertas para degradação, pastas de trabalho do Azure Monitor implementadas para visualizar a topologia de conectividade global mostrando conexões ativas, utilização de largura de banda e eventos de redundância, estabelecidas linhas de base para desempenho aceitável com alertas automatizados em caso de incumprimento dos limiares.

Resultado: A conectividade privada foi alcançada para todas as transações financeiras, atendendo PCI-DSS requisitos. O ExpressRoute forneceu baixa latência consistente para negociação em tempo real. A WAN Virtual reduziu substancialmente a latência das filiais para o centro de dados. Funcionários remotos conectados com sucesso via VPN ponto a site com autenticação aprimorada. O emparelhamento global de redes virtuais permitiu uma recuperação eficiente de desastres entre regiões. Otimização de custos alcançada através da consolidação de WAN Virtual.

Nível de criticidade

Deve ter.

Mapeamento de controle

• NIST SP 800-53 Rev.5: SC-7, SC-7(4), SC-8
• PCI-DSS v4: 1.2.1, 2.2.7, 4.2.1
• Controles CIS v8.1: 12.8, 13.8
• NIST CSF v2.0: PR. AC-05, PR. DS-02
• ISO 27001:2022: A.8.21, A.8.22, A.5.14
• SOC 2: CC6.6, CC6.7

NS-10: Garanta a segurança do DNS (Sistema de Nomes de Domínio)

Princípio da segurança

Certifique-se de que a configuração de segurança do DNS (Sistema de Nomes de Domínio) protege contra riscos conhecidos:

• Use serviços DNS confiáveis, autoritativos e recursivos em seu ambiente de nuvem para garantir que o cliente (como sistemas operacionais e aplicativos) receba o resultado de resolução correto.
• Separe a resolução DNS pública e privada para que o processo de resolução DNS para a rede privada possa ser isolado da rede pública.
• Certifique-se de que sua estratégia de segurança de DNS também inclua mitigações contra ataques comuns, como DNS pendente, ataques de amplificação de DNS, envenenamento e falsificação de DNS e assim por diante.

Risco a mitigar

Os agentes de ameaças atacam os serviços DNS ou exploram serviços DNS vulneráveis para comprometer aplicações e redirecionar o tráfego.

• Falsificação/envenenamento de DNS: Os adversários forjam respostas de DNS ou caches de resolvedores corrompidos (por exemplo, ataque Kaminsky) para redirecionar clientes para servidores mal-intencionados, permitindo phishing ou intercetação de dados.
• Ataques de amplificação de DNS: Os atacantes exploram servidores DNS mal configurados para amplificar o tráfego DDoS (por exemplo, consulta de 60 bytes produzindo resposta de 4.000 bytes), sobrecarregando as redes de destino.
• Exploração de DNS Dangling: Os registros Dangling (por exemplo, CNAMEs obsoletos) permitem que os adversários sequestrem recursos desativados, redirecionando o tráfego para endpoints maliciosos para phishing ou malware.
• Exfiltração de dados via túnel DNS: Agentes mal-intencionados codificam dados em consultas DNS (por exemplo, data.exfil.evil.com) para exfiltrar secretamente informações confidenciais, ignorando firewalls.
• Entrega de phishing/malware: Os resolvedores comprometidos redirecionam domínios legítimos para IPs controlados por invasores, entregando páginas de phishing ou malware para clientes desavisados.

MITRE ATT&CK

• Comando e Controlo (TA0011): Use o túnel DNS para codificar comandos C2 em consultas (por exemplo, data.exfil.evil.com) ou resoluções falsas para se conectar a servidores mal-intencionados (por exemplo, T1071.004 - Application Layer Protocol: DNS).
• Coleção (TA0009): Colete dados falsificando o DNS para redirecionar os usuários para sites de phishing ou exfiltrando dados por meio de tunelamento (por exemplo, T1040 - Network Sniffing).
• Impacto (TA0040): Ataques de amplificação de DNS, envio de pequenas consultas para gerar grandes respostas, interrupção da disponibilidade do serviço (por exemplo, T1498.002 - Network Denial of Service: Reflection Amplification).
• Acesso inicial (TA0001): Explorar registos DNS pendentes ou resoluções falsificadas para disseminar malware ou phishing, conseguindo acesso aos sistemas (por exemplo, T1190 - Exploitar aplicação voltada para o público).

NS-10.1 Use o serviço DNS confiável

Use serviços de DNS confiáveis para garantir que os clientes recebam resultados de resolução corretos e protejam contra ataques baseados em DNS. O Azure fornece o serviço DNS recursivo em 168.63.129.16 (normalmente atribuído via DHCP ou pré-configurado) para resolução DNS de carga de trabalho no nível do sistema operacional ou aplicativo. Como alternativa, use servidores DNS externos confiáveis. Para organizações que hospedam seus próprios domínios, o DNS do Azure fornece hospedagem DNS autoritativa confiável. As organizações que criam servidores DNS personalizados devem seguir as diretrizes de implantação segura do NIST SP 800-81 Rev. 3:

• Use o DNS recursivo do Azure ou o DNS externo confiável: Configure cargas de trabalho para usar o DNS recursivo do Azure (168.63.129.16) ou servidores DNS externos confiáveis em sistemas operacionais VM ou configurações de DNS de aplicativos para garantir uma resolução de nomes confiável.

• Permitir o DNS do Azure em regras de firewall: Adicione 168.63.129.16 ao firewall e às listas de permissões do NSG para garantir a funcionalidade DNS adequada para os recursos do Azure.

• Hospedar domínios no DNS do Azure: Use o DNS do Azure para hospedar a resolução de domínios para necessidades de DNS autoritativo, fornecendo hospedagem de DNS confiável e escalável (Nota: O DNS do Azure não oferece serviço de registo de domínios).

• Siga as diretrizes de implantação de DNS seguro: Se estiver criando servidores DNS personalizados, siga o Guia de Implantação do Sistema de Nomes de Domínio Seguro (DNS) do NIST SP 800-81 Rev. 3 para implementar as práticas recomendadas de segurança.

NS-10.2 Usar DNS privado na rede virtual

Use o DNS Privado do Azure para estabelecer zonas DNS privadas onde a resolução DNS permanece na rede virtual, impedindo que consultas DNS atravessem redes públicas. Isso é essencial para configurações de ponto de extremidade privado, onde as zonas DNS privadas substituem a resolução DNS pública para rotear o tráfego de forma privada para os serviços do Azure. As soluções de DNS personalizadas podem restringir ainda mais a resolução apenas a fontes fidedignas, melhorando a segurança para cargas de trabalho privadas:

• Implante o DNS Privado do Azure para resolução privada: Use o DNS Privado do Azure para criar zonas DNS privadas que mantêm a resolução DNS dentro da rede virtual, garantindo que as consultas nunca saiam do limite da rede.

• Configurar DNS privado para pontos finais privados: Configure zonas DNS privadas para pontos finais privados de modo a substituir a resolução DNS pública e assegurar que os clientes resolvem os FQDNs dos pontos finais privados em endereços IP privados dentro da rede virtual.

• Implemente DNS personalizado para resolução restrita: Use servidores DNS personalizados para restringir a resolução DNS para permitir apenas fontes de resolução confiáveis para seus clientes, fornecendo controle adicional sobre a segurança da resolução de nomes.

Utilizar o Defender for DNS para proteção avançada

Use o Microsoft Defender para DNS para detetar e alertar sobre ameaças avançadas à segurança baseadas em DNS, incluindo exfiltração de dados por meio de tunelamento DNS, comunicação de comando e controle, interações de domínio mal-intencionadas (phishing, mineração de criptomoedas) e ataques DNS envolvendo resolvedores mal-intencionados. A proteção do Defender for DNS agora está incluída no Plano Defender for Servers. Além disso, use o Microsoft Defender for App Service para detetar registros DNS pendentes que podem habilitar ataques de invasão de subdomínio ao desativar sites:

• Habilite o Defender para proteção DNS: Use o Microsoft Defender for DNS (incluído no Defender for Servers Plan) para monitorar e alertar sobre atividades suspeitas de DNS, incluindo exfiltração de dados por meio de túnel DNS, comunicação de comando e controle de malware e interações com domínios mal-intencionados.

• Monitore atividades maliciosas de DNS: Configure alertas para detetar comunicação com resolvedores DNS mal-intencionados e ataques DNS que possam comprometer a segurança da carga de trabalho ou a disponibilidade do serviço DNS.

• Detetar registros DNS pendentes: Use o Microsoft Defender for App Service para identificar registros DNS pendentes ao desativar sites do Serviço de Aplicativo, evitando ataques de invasão de subdomínios garantindo que domínios personalizados sejam removidos dos registradores de DNS.

Exemplo de implementação

Desafio: Uma empresa precisava de segurança DNS abrangente, abrangendo serviços de resolução confiáveis, DNS de rede privada para recursos internos e deteção avançada de ameaças em infraestrutura de nuvem híbrida.

Abordagem da solução:

• Foi implantado o DNS recursivo do Azure (168.63.129.16) para todas as cargas de trabalho de VM do Azure com regras NSG que permitem tráfego DNS.
• Zonas autoritativas hospedadas no DNS do Azure para resolução de domínio público com distribuição geográfica
• Zonas DNS privadas do Azure implementadas para resolução de ponto final privado (privatelink.database.windows.net, privatelink.blob.core.windows.net) vinculadas a redes virtuais de produção
• Integração de DNS privado configurada garantindo a resolução de FQDNs de ponto de extremidade privado para IPs privados (por exemplo, sqlserver.database.windows.net → 10.0.2.4)
• Habilitado Microsoft Defender para DNS através do Defender for Servers Plan para monitorização de tunelamento DNS, comunicação C2 e interações com domínios maliciosos
• Implantado o Defender for App Service para detetar registros DNS pendentes durante a desativação do site

Resultado: A implementação de segurança de DNS garantiu uma resolução de nomes confiável para cargas de trabalho na nuvem, mantendo a privacidade dos recursos internos. As zonas DNS privadas impediam que consultas confidenciais atravessassem redes públicas, enquanto o Defender for DNS fornecia visibilidade sobre ameaças baseadas em DNS, incluindo tentativas de exfiltração de dados e atividade de comando e controle. A solução eliminou os riscos de aquisição de subdomínios por meio da deteção automatizada de DNS pendente durante as alterações do ciclo de vida dos recursos.

Nível de criticidade

Deve ter.

Mapeamento de controle

• NIST SP 800-53 Rev.5: SC-7, SI-4, SI-4(4), SI-4(5)
• PCI-DSS v4: 11.5.1, 12.10.1
• Controles CIS v8.1: 8.5, 13.6, 13.8
• NIST CSF v2.0: DE. CM-01, DE. CM-04, DE. AE-02
• ISO 27001:2022: A.8.16, A.8.22, A.5.24
• SOC 2: CC6.1, CC7.2, CC7.3