Segurança de Rede

A segurança de rede protege cargas de trabalho de nuvem contra ameaças como acesso não autorizado, violações de dados e interrupção de serviço controlando o tráfego em vários limites. Ao contrário das defesas tradicionais focadas em perímetro, os ambientes de nuvem modernos exigem estratégias de defesa detalhada 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 movimento lateral irrestrito e exposição prolongada a ameaças.

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

Proteger limites de rede: Imponha controles estritos nas bordas de rede e entre segmentos por meio de uma defesa em profundidade em camadas múltiplas que inclui firewalls, proteção contra DDoS, firewalls de aplicativos web e conectividade privada, seguindo o princípio do menor privilégio para negar o tráfego não autorizado por padrão.

Controles relacionados:

• NS-2: Proteger serviços de nuvem com controles de rede
• NS-3: implantar o firewall na borda da rede corporativa
• NS-5: implantar a proteção contra DDOS
• NS-6: implantar o firewall do aplicativo Web
• NS-9: conectar a rede local ou de nuvem privadamente

Aplicar isolamento de rede: Divida 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 a movimentação lateral não autorizada.

Controles relacionados:

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

Monitore e responda: Mantenha a visibilidade contínua da atividade de rede por meio de monitoramento abrangente, detecção de intrusão e segurança de protocolo para identificar comportamento suspeito, violações de política e ameaças ativas rapidamente.

Controles relacionados:

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

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

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

Princípio de 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 recursos de nuvem para reduzir o raio de explosão.

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

• Separar o Corpnet usando redes de aplicações
• Redes de aplicativos separadas
• Separar redes 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 movimento lateral irrestrito, permitindo que os invasores percorram infraestruturas de rede e comprometam ativos de alto valor.

• Exposição de rede simples: A ausência de segmentação permite a movimentação lateral irrestrita, 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 do usuário por meio do acesso a sub-redes confidenciais e cargas de trabalho.
• Propagação de malware: A segmentação insuficiente permite a rápida disseminação de código mal-intencionado, como ransomware entre nós interconectados, ampliando a superfície de ataque e o impacto operacional.
• Cegueira do tráfego leste-oeste: O tráfego inter segmentado irrestrito dificulta a detecçã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): pivoteamento de ataque por VNets e tráfego não restrito entre sub-redes (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 por canal C2).
• Comando e controle (TA0011): propagação de malware por comunicação com IPs mal-intencionados ou domínios por meio de regras de firewall e inteligência contra ameaças (por exemplo, T1071 – Application Layer Protocol).

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

O isolamento de rede virtual estabelece limites de segurança fundamentais 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 impede a movimentação lateral irrestrita e reduz o raio de explosão quando ocorrem violações, alinhando a arquitetura de rede com estratégias de segmentação empresarial e princípios de confiança zero.

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

• Projetar topologia de 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 estrito (por exemplo, bancos de dados de produção, sistemas de processamento de pagamento) e implante-as em VNets dedicadas e isoladas para minimizar a exposição e evitar contaminação cruzada.

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

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

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

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

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

• Definir regras de permissão e negação explícitas: 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 ao negar 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 ASGs (grupos de segurança de aplicativos) 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 manutenção e reduzindo a complexidade da configuração.

• Monitorar e otimizar com logs de fluxo: Habilite o registro em log de fluxo de rede virtual para monitorar o tráfego permitido ou negado pelas regras do NSG, identificando o tráfego frequentemente negado que pode indicar configuração incorreta ou tráfego com frequência permitido que poderia informar a otimização da regra e reduzir o ruído de registro em log.

Exemplo de implementação

Uma organização precisava proteger um aplicativo de várias camadas com ambientes separados de produção, desenvolvimento e teste, impedindo a movimentação lateral não autorizada e o acesso externo.

Desafio: A organização tinha um aplicativo de três camadas (Web, aplicativo, banco de dados) com todos os recursos em um único segmento de rede grande, permitindo a comunicação irrestrita entre todas as camadas e ambientes. Isso criou riscos significativos de segurança, incluindo movimentação lateral potencial entre produção e não produção, acesso irrestrito à Internet 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: Criaram redes virtuais separadas para produção (10.0.0.0/16), desenvolvimento (10.1.0.0/16) e ambientes de 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 de sub-rede por camada: Na VNet de produção, criamos 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) - habilitando o controle de tráfego granular entre as camadas.
• Regras de NSG para controle de 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 à Internet de saída a apenas destinos confiáveis, com regras específicas permitindo apenas conexões externas necessárias para a camada da Web, bloqueando todo o acesso à Internet da camada de banco de dados.
• Regras de NSG para controle de tráfego leste-oeste: Políticas de negação por padrão implementadas com regras explícitas de permissão entre camadas – a camada da Web é permitida para tráfego de saída para a camada de aplicações apenas nas portas necessárias, a camada de aplicações é permitida para tráfego de saída para a camada de banco de dados somente na porta 1433 (SQL), e a camada de banco de dados nega todo o tráfego de entrada, exceto o proveniente da sub-rede da camada de aplicações.
• Acesso de gerenciamento remoto: Portas de gerenciamento remoto restritas (RDP 3389/TCP, SSH 22/TCP) para aceitar conexões somente da sub-rede de host de bastião confiável (10.0.0.0/26), eliminando o acesso direto à Internet para interfaces de gerenciamento.

Resultado: A organização eliminou a movimentação lateral irrestrita entre camadas de aplicativos e ambientes, reduziu significativamente a superfície de ataque removendo o acesso direto à Internet de sistemas de back-end e estabeleceu limites de rede imposição alinhados com princípios de confiança zero. Os registros de fluxo habilitaram o monitoramento contínuo do tráfego permitido e negado para a otimização contínua e a validação da postura 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: Proteger serviços nativos de nuvem com controles de rede

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

Princípio de 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. Esses recursos incluem:

• Estabeleça 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 em que você pode restringir a VNet para estabelecer um ponto de acesso privado para o serviço.
• Configure firewalls nativos de serviço para restringir o tráfego de entrada ou desabilitar o acesso à rede pública.

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

Risco a mitigar

Os atores de ameaça exploram serviços de nuvem expostos publicamente para realizar exfiltração de dados, ataques de camada de aplicativo e interceptação de tráfego.

• Exfiltração de dados por meio de pontos de extremidade públicos: Os invasores 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 habilitando o roubo de dados em larga escala.
• Ataques de camada de aplicativo contra pontos de extremidade públicos: Ataques de DDoS (Negação Distribuída de Serviço), injeção de SQL e outras explorações de aplicativos têm como destino serviços Web, APIs e bancos de dados expostos publicamente, sobrecarregando recursos ou explorando vulnerabilidades para causar interrupção de serviço ou comprometimento de dados.
• Ataques de homem no meio: Os invasores interceptam o tráfego que flui pelas redes públicas para serviços expostos publicamente, capturando credenciais, tokens de sessão ou dados confidenciais transmitidos sem criptografia adequada ou conectividade privada, o que pode resultar na tomada de controle da conta ou roubo de dados.

MITRE ATT&CK

• Acesso Inicial (TA0001): acesso não autorizado por exposição à Internet pública de serviços de nuvem (por exemplo, serviços de armazenamento em nuvem, serviços de banco de dados), exploração direcionada a pontos de extremidade públicos (por exemplo, T1190 – Exploit Public-Facing Application).
• Exfiltração (TA0010): exfiltração de dados roteando o tráfego em conexões de rede virtual privada, reduzindo o risco de vazamento de dados para servidores externos (por exemplo, T1041 – Exfiltração por canal C2).
• Movimento Lateral (TA0008): deslocamento de invasores entre serviços em redes virtuais, acesso não autorizado entre recursos em 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 de nuvem estabelecendo caminhos de rede diretos em sua infraestrutura virtual. O Link Privado cria pontos de extremidade privados com endereços IP dedicados dentro de suas redes virtuais, garantindo que o tráfego para serviços de nuvem nunca percorra a Internet pública, mantendo padrões de acesso baseados em DNS. Essa abordagem reduz significativamente a superfície de ataque e impede 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:

• Implantar pontos de extremidade privados para serviços com suporte: Crie pontos de extremidade privados em sua rede virtual para recursos do Azure que dão suporte ao Link Privado (por exemplo, Armazenamento do Azure, Banco de Dados SQL do Azure, Azure Key Vault), estabelecendo endereços IP privados (por exemplo, 10.0.2.4) acessíveis somente na sua VNet.

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

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

Nota: Determinados serviços do Azure também podem permitir a comunicação privada por meio do recurso de ponto de extremidade de serviço , embora o Link Privado do Azure seja recomendado para acesso seguro e privado aos serviços hospedados na plataforma do 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 Azure Load Balancer como o front-end para acesso ao serviço.

Implantar o serviço NS-2.2 na VNet

A integração de rede virtual permite que os serviços de nuvem operem dentro dos limites de rede privada, estabelecendo conectividade direta com recursos hospedados pela VNet sem exposição pública à Internet. Ao implantar serviços em redes virtuais, as organizações ganham 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 suportado.

• Implantar serviços em redes virtuais: Para serviços que dão suporte à integração de VNet (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 da VNet.

• Configurar 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 a destinos específicos (por exemplo, sub-redes de banco de dados, pontos de extremidade de armazenamento) enquanto nega todo o tráfego.

NS-2.3 Configurar firewall nativo do serviço

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

Configurar firewalls de serviço para restringir o acesso:

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

• Definir regras baseadas em IP ou VNet: Configure regras de firewall para permitir o acesso somente de intervalos de IP públicos específicos (por exemplo, redes corporativas de escritório) ou sub-redes de rede virtual específicas do Azure, implementando o acesso de menor privilégio negando todas as outras fontes.

• Desabilite o acesso público quando possível: Quando os serviços exigem acesso somente de redes privadas, use a opção de alternância para desabilitar completamente o acesso à rede pública, garantindo que o serviço seja inacessível da Internet, independentemente das regras baseadas em IP.

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

O Perímetro de Segurança de Rede estabelece um limite de rede lógica em torno de vários recursos de PaaS, permitindo a comunicação de serviço a serviço seguro dentro de um perímetro confiável explícito, evitando a exfiltração de dados não autorizada. 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 intra-perímetro sem regras de acesso individuais, bloqueando o acesso externo por padrão.

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

• Criar e associar recursos: Estabeleça um perímetro de segurança de rede e adicione recursos de PaaS com suporte (Armazenamento do Azure, Banco de Dados SQL, Key Vault, Hubs de Eventos, Cosmos DB) por meio de associações de recursos, permitindo a comunicação intra-perímetro em que os recursos associados podem se comunicar livremente.

• Configurar os modos de acesso e as regras: Comece com o modo transição para entender os padrões de acesso antes de fazer a transição para o modo imposto para proteção máxima. 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.

• Habilitar o monitoramento e a integração com o Private Link: Configure logs de diagnóstico para capturar tentativas de acesso e violações de política. O tráfego de endpoint privado é automaticamente permitido no perímetro, complementando a conectividade de VNet para 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 back-end e os recursos de armazenamento, permitindo o acesso a partir dos serviços de aplicativos sem expor esses recursos à internet pública.

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

Abordagem da solução:

• Pontos de extremidade de Link Privado para serviços de PaaS: Pontos de extremidade privados implantados para o Banco de Dados SQL do Azure (IP privado atribuído 10.0.2.4) e a conta de Armazenamento do Azure (IP privado atribuído 10.0.2.5) em uma sub-rede de ponto de extremidade privado dedicada (10.0.2.0/24), estabelecendo conectividade privada que roteia o tráfego pela rede de backbone do Azure sem exposição à Internet.
• Zonas DNS privadas para resolução de nomes: Zonas DNS Privadas do Azure foram criadas para substituir a resolução DNS pública, garantindo que os FQDNs das aplicações (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, assegurando conectividade contínua para aplicações que utilizam 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 a necessidade de endereços IP públicos ou roteamento da 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 de VNet específicas (sub-rede de aplicativo 10.0.1.0/24) e serviços confiáveis da Microsoft, desabilitando completamente o acesso à rede pública no nível de serviço do Banco de Dados SQL do Azure para impor a conectividade somente privada.
• Regras NSG para defesa detalhada: As regras NSG aplicadas à sub-rede do aplicativo permitem o tráfego de saída somente para a sub-rede do ponto de extremidade privado (10.0.2.0/24) em portas necessárias (443 para Armazenamento, 1433 para SQL), implementando o 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) forneceram proteção de defesa em profundidade alinhada com 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: implantar firewall na borda da rede corporativa

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

Princípio de 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 internos.

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

• Bloquear sites e endereços IP inválidos conhecidos.
• Restrinja protocolos de alto risco, como protocolos de gerenciamento remoto e protocolos de intranet em redes de borda para impedir o acesso não autorizado ou a movimentação lateral.
• Imponha 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 por meio de protocolos expostos: Protocolos publicamente acessíveis, 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 explorações como força bruta ou ataques direcionados a CVE.
• Malware e phishing por meio de domínios/IPs mal-intencionados: Domínios mal-intencionados e IPs facilitam a entrega de malware ou campanhas de phishing, colocando em risco pontos de extremidade e dados confidenciais por meio de ataques de comando e controle ou engenharia social.
• Exfiltração de dados por meio do tráfego de saída irrestrito: A saída descontrolada para destinos não aprovados permite que os adversários exfiltram dados confidenciais, arriscando violações e violações de conformidade por meio de canais secretos como POSTs HTTPS.
• Movimento lateral devido à segmentação ruim: A segmentação de rede insuficiente permite que os invasores pivotem internamente, explorando o tráfego entre segmentos (por exemplo, SMB, Kerberos) para se propagar a partir de sistemas comprometidos.
• Vulnerabilidades de aplicativos/URLs não confiáveis: O acesso a URLs e aplicativos arriscados ou não confiáveis aumenta a exposição a explorações, elevando os riscos de incidentes e a não conformidade com os padrões regulatórios.

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 mal-intencionados (por exemplo, T1190 – Exploit Public-Facing Application).
• Comando e Controle (TA0011): malware que se conecta a IPs/domínios maliciosos (por exemplo, T1071 – Protocolo de Camada de Aplicação).
• Exfiltração (TA0010): transferências de dados não autorizadas por meio do tráfego de saída para destinos não aprovados (por exemplo, T1041 – Exfiltração por canal C2).
• Movimento Lateral (TA0008): inibe o pivotamento interno por meio de tráfego intersregião não filtrado (por exemplo, SMB/TCP 445, Kerberos/TCP 88) (por exemplo, T1021 – Serviços Remotos).

Preparação do NS-3.1 para implantação do Firewall do Azure

A implantação do Firewall do Azure requer uma topologia de rede adequada, permitindo a inspeção de tráfego centralizada entre limites de rede. As arquiteturas hub-and-spoke posicionam o firewall no núcleo de rede, roteando todo o tráfego spoke por meio de um ponto de inspeção central, enquanto as rotas definidas pelo usuário garantem que o fluxo de tráfego siga os caminhos pretendidos. Essa preparação estabelece a base para a proteção abrangente de borda e a filtragem entre segmentos.

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

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

• Participe de redes virtuais do tipo spoke: Use o emparelhamento VNet para conectar cada VNet do tipo spoke à VNet do hub onde o Azure Firewall está implantado, permitindo a comunicação entre os spokes por meio do hub, mantendo o isolamento da rede.

• Configurar UDRs (rotas definidas pelo usuário): Crie tabelas de rotas direcionando o tráfego de rede de VNets spoke por meio do Firewall do Azure na rede hub, incluindo rotas para saída da Internet (0.0.0.0/0) e opcionalmente para tráfego entre spokes, se a comunicação spoke-to-spoke exigir 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 estado com gerenciamento de política centralizado entre segmentos de rede corporativa. Combinando regras de rede, regras de aplicativo e inteligência contra ameaças, os firewalls inspecionam fluxos de tráfego em várias camadas, enquanto a filtragem de URL e a inspeção de TLS permitem o controle granular sobre comunicações HTTP/HTTPS. O design de política adequado equilibra os requisitos de segurança com as necessidades operacionais por meio de hierarquias de regras estruturadas e filtragem baseada em categoria.

Implantar e configurar 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 associado à Internet e endereços IP privados para roteamento interno de VNets spoke.

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

• Configurar 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 configurar a filtragem baseada em categoria para bloquear categorias de site inteiras (por exemplo, Hacking, Mídias Sociais) ao mesmo tempo em que permite categorias relacionadas ao trabalho.

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

Exemplo de implementação

Uma organização com várias cargas de trabalho de aplicativos em VNets spoke distintos precisava de inspeção centralizada de segurança de rede para todo o tráfego com destino à Internet e comunicações entre VNets spoke, impedindo o acesso a domínios maliciosos e categorias de websites não autorizados.

Desafio: A organização tinha cargas de trabalho implantadas em VNets spoke separadas com acesso direto à Internet, criando políticas de segurança inconsistentes e incapacidade de inspecionar centralmente o tráfego. Cada spoke tinha suas próprias regras de NSG, levando à descompasso da política e lacunas de segurança. Não havia visibilidade de conexões de saída para domínios potencialmente mal-intencionados, nenhuma capacidade de bloquear categorias de sites de risco (mídia social, compartilhamento de arquivos) e nenhuma inspeção do conteúdo de tráfego HTTPS. O tráfego entre spokes fluiu livremente sem inspeção, permitindo a movimentação lateral potencial após o comprometimento.

Abordagem da solução:

• Topologia hub-and-spoke com firewall centralizado: Implantado Firewall do Azure Premium em uma VNet central (10.0.0.0/16) com AzureFirewallSubnet dedicada (10.0.1.0/26, IP privado de firewall 10.0.1.4), estabelecendo um ponto único de aplicação para todo o gerenciamento de políticas e inspeção de tráfego de rede.
• Emparelhamento VNet para conectividade com spoke: O emparelhamento VNet é usado 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 de tráfego centralizado através do firewall.
• Rotas definidas pelo usuário para a direção de tráfego: Criaram tabelas de rotas em cada VNet spoke redirecionando todo o tráfego associado à Internet (0.0.0.0/0) e tráfego entre spokes para o IP privado do Firewall do Azure (10.0.1.4), forçando todas as saídas por meio do ponto de inspeção central.
• Políticas de firewall com filtragem de várias camadas: Definiu políticas abrangentes do Firewall do Azure , incluindo regras de rede (permitir DNS UDP/53 ao DNS do Azure, negar todos os outros protocolos por padrão), regras de aplicativo (permitir FQDNs comercialmente críticos como *.microsoft.com, negar domínios de compartilhamento de arquivos como *.torrent) e regras de inteligência contra ameaças (bloquear IPs mal-intencionados conhecidos de feeds de ameaças do Microsoft Defender).
• Filtragem de URL e bloqueio baseado em categoria: Implementou regras de aplicativo baseadas em FQDN para controle de domínio preciso e filtragem baseada em categoria para bloquear categorias de site inteiras (Hacking, Mídia Social, Jogo) ao mesmo tempo em que permite categorias relacionadas ao trabalho (Negócios/Economia, Tecnologia/Internet), impondo políticas de uso aceitáveis na borda da rede.
• Inspeção do TLS para tráfego HTTPS: Habilitou a inspeção do TLS com certificados armazenados no Azure Key Vault, permitindo que o firewall descriptografe, inspecione e recriptografe o tráfego HTTPS para filtragem de URL mais profunda e detecção de ameaças além da inspeção baseada em SNI, excluindo domínios bancários confidenciais da descriptografia por requisitos de conformidade.

Resultado: A organização estabeleceu visibilidade centralizada e controle sobre todo o tráfego entre os hubs e com destino à Internet, eliminando a deriva das políticas e os pontos cegos de segurança. A inspeção do TLS habilitou a detecção de ameaças ocultas no tráfego HTTPS criptografado, enquanto a filtragem baseada em categoria reduziu substancialmente a exposição ao conteúdo da Web arriscado. A arquitetura hub-and-spoke forneceu uma postura de segurança escaloná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: implantar IDS/IPS (sistemas de detecção/prevenção de intrusões)

Princípio de segurança

Use sistemas de detecção e prevenção de intrusão de rede (IDS/IPS) para inspecionar o tráfego da rede e de carga para ou das suas redes virtuais. Verifique se o IDS/IPS está sempre ajustado para fornecer alertas de alta qualidade para sua solução SIEM.

Observação: para uma funcionalidade de detecção e prevenção de nível de host mais aprofundada, use IDS/IPS baseado em host ou uma solução EDR (detecção e resposta de ponto de extremidade) 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 mal-intencionadas.

• 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 explorações como ataques direcionados à CVE.
• Comunicações de comando e controle (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 aplicações: Ataques como injeção de SQL, falsificação de scripts entre sites (XSS) ou estouro de buffer exploram vulnerabilidades em aplicações para roubar dados ou executar código arbitrário.
• Movimento lateral: Tráfego interno anômalo, como a enumeração SMB (TCP 445) ou o abuso de tíquete Kerberos (TCP 88), sinaliza a movimentação do invasor dentro da rede.
• Exfiltração de dados: Transferências de dados não autorizadas ocorrem em canais criptografados (por exemplo, POSTs HTTPS) ou saída de alto volume, usando ofuscação para evitar a detecção.

MITRE ATT&CK

• Acesso Inicial (TA0001): invasões não autorizadas por meio de explorações direcionadas a vulnerabilidades de rede (por exemplo, T1190 – Exploit Public-Facing Application).
• Execução (TA0002): execução de código malicioso de explorações de vulnerabilidade ou cargas úteis C2 (por exemplo, T1059 – Interpretador de Comando e Script).
• Comando e controle (TA0011): comunicações de malware C2 utilizando as consultas DNS ou callbacks baseados em IP (por exemplo, T1071 – Protocolo de Camada de Aplicação).
• Movimento Lateral (TA0008): tráfego interno anômalo (por exemplo, enumeração SMB) indicativo de movimentação (por exemplo, T1021 – Serviços Remotos).
• Exfiltração (TA0010): transferências de dados não autorizadas por canais criptografados ou ofuscados (por exemplo, T1041 – Exfiltração por canal C2).

NS-4.1 Implantar o Firewall do Azure Premium para IDPS

Os sistemas de detecção e prevenção de intrusões fornecem identificação de ameaças baseada em assinatura, correspondendo a padrões de tráfego de rede em relação a assinaturas de ataque conhecidas, permitindo o bloqueio em tempo real de tentativas de exploração e comunicações mal-intencionadas. O recurso IDPS do Firewall Premium do Azure oferece bibliotecas de assinaturas continuamente atualizadas, abrangendo categorias de explorações, malware, comando e controle e phishing, ao mesmo tempo em que oferece suporte aos modos apenas de alerta e de prevenção. A seleção e o ajuste de assinatura adequados garantem a detecção de alta fidelidade, minimizando falsos positivos.

Implantar e configurar o IDPS por meio do Firewall do Azure Premium:

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

• Selecione regras de assinatura IDPS: Escolha regras de assinatura IDPS na biblioteca de assinaturas com base em prioridades de ameaça, começando com assinaturas de alta severidade em categorias críticas como "Malware", "Explorações" e "Phishing" que se alinham com o perfil de ameaça e tolerância a riscos da sua organização.

• Configurar o modo IDPS: Defina o modo IDPS como modo de alerta inicialmente para testar e ajustar para observar correspondências de assinatura sem bloquear o tráfego e, em seguida, fazer a transição para o modo alerta e negação para ambientes de produção para evitar ativamente ameaças detectadas, mantendo alertas para monitoramento de segurança.

• Ajustar assinaturas: Ajuste regras de assinatura individuais com base na experiência operacional, desabilitando ou reduzindo a prioridade de assinaturas gerando falsos positivos excessivos, garantindo que as assinaturas de alta prioridade permaneçam ativas, otimizando a taxa de sinal para 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 vulnerabilidades exploradas e ataques de zero-day, mantendo a visibilidade sobre a atividade de ameaças sem interromper as operações legítimas de negócios.

Desafio: A organização operava um aplicativo Web de várias camadas processando transações financeiras sem detecção de ameaças baseadas 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 aos servidores de aplicativos, não tinham capacidade para detectar comunicações de comando e controle e experimentavam alertas falsos positivos de soluções IDS genéricas que exigiam ajuste extensivo.

Solution:

• Firewall do Azure Premium com IDPS: Implantação do Firewall do Azure Premium na VNet do hub para habilitar recursos do IDPS, além de inspeção de TLS e filtragem de URL, estabelecendo detecção centralizada de ameaças baseadas em assinaturas para todo o tráfego de VNet spoke.

• Seleção de regra de assinatura:Assinaturas IDPS de alta severidade selecionadas 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 ajuste: IDPS configurado no modo de alerta para testes iniciais a fim de observar combinações de assinaturas sem bloquear o tráfego, analisando alertas para identificar falsos positivos das ferramentas legítimas de DevOps e chamadas de API de parceiros, e em seguida criou exceções de assinatura para cenários conhecidos como seguros, mantendo as assinaturas CVE de alta prioridade ativas.

• Transição do modo de prevenção: IDPS foi transferido para o modo de Alerta e Negação para produção após validação, bloqueando ativamente as ameaças detectadas, incluindo tentativas de exploração de PaperCut, ataques do Log4Shell e comunicações de C2.

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

Resultado: Tentativas de exploração foram bloqueadas com êxito impedindo a execução remota de código. A exploração de vulnerabilidade crítica foi eliminada antes do comprometimento ocorrer. As taxas de falsos positivos diminuíram substancialmente, mantendo uma cobertura CVE abrangente. As equipes de segurança obtiveram 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 proteção contra DDOS

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

Princípio de segurança

Implante a proteção contra DDoS em várias camadas para reduzir efetivamente os ataques direcionados a diferentes serviços e protocolos nas camadas de rede e aplicativo.

Risco a mitigar

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

• Ataques volumetricos (inundações de rede): Os invasores inundam interfaces de rede com volumes de tráfego maciços (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. Exemplos incluem inundações UDP, inundações de ICMP ou ataques de reflexão DNS amplificados aproveitando protocolos como NTP ou SSDP.
• Ataques de protocolo (esgotamento de estado): Os invasores exploram vulnerabilidades de protocolo de Camada 3/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 semifechadas, ou inundações de ACK visando dispositivos com estado.
• Ataques na camada de recursos (sobrecarga de aplicativo): Ataques limitados na Camada 7, como ataques de inundação HTTP GET/POST, visam recursos de aplicativo (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 invasores exploram servidores configurados incorretamente (por exemplo, servidores DNS, NTP ou Plex Media no UDP 32414) para ampliar o tráfego, enviando pequenas consultas que geram respostas grandes direcionadas ao destino, sobrecarregando a capacidade da rede. Exemplos incluem amplificação 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 – Negação de Serviço de Rede).
• Desenvolvimento de Recursos (TA0042): aproveita sistemas comprometidos para realizar ataques de amplificação (como reflexão DNS/NTP) para aumentar o impacto do ataque (por exemplo, T1584 – Comprometimento da Infraestrutura).

NS-5.1 Implementar proteção contra DDOS na camada de rede apropriada

Implante a proteção contra DDoS em camadas de rede e de aplicativo para se defender contra ataques volumetricos e específicos do aplicativo. O Azure fornece várias camadas de proteção: Proteção de Rede DDoS para cobertura abrangente de VNet com suporte de resposta rápida, Proteção de IP DDoS para proteção econômica de IPs individuais e proteção de camada de aplicativo 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 os ataques:

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

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

• Configurar monitoramento e 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 os 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 experimentavam tentativas de ataque de camada de aplicativo e volume crescentes durante as temporadas de compras de pico.

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 distribuição de conteúdo expostas à Internet. Durante os eventos de pico, a plataforma experimentou vários ataques de DDoS, incluindo inundações UDP, inundações TCP SYN esgotando tabelas de conexão do balanceador de carga, inundações HTTP direcionadas a 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: Habilitou a Proteção de Rede do Azure DDoS em redes virtuais de produção que hospedam aplicativos voltados para o cliente, fornecendo proteção abrangente no nível da VNet com ajuste adaptável, detecção automática de ataque nas Camadas 3 e 4 e mitigação em tempo real.

• Proteção da camada de aplicativo: Implantado 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 da Camada 7 com limitação de taxa, detecção de inundações HTTP e regras de proteção contra bot.

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

• Monitoramento e alertas: Os logs de diagnóstico de DDoS configurados enviam dados de telemetria de ataque para o espaço de trabalho do Log Analytics; criaram alertas do Azure Monitor que disparam notificações imediatas quando ataques são detectados; o workbook do Sentinel foi estabelecido, correlacionando ataques DDoS com métricas de desempenho do aplicativo; e o Application Insights foi configurado para monitorar a saúde do aplicativo durante a mitigação.

• Compromisso de resposta rápida:Resposta Rápida de DDoS ativada fornecendo acesso direto a especialistas em proteção contra DDoS durante ataques ativos para análise de ataque em tempo real, desenvolvimento de estratégia de mitigação personalizada e perícia pós-ataque.

Resultado: Os ataques de DDoS durante o pico da temporada de compras foram mitigados com êxito com zero interrupções de serviço. Inundações volumétricas, inundações SYN e inundações HTTP foram automaticamente bloqueadas, mantendo a disponibilidade da plataforma. A Resposta Rápida forneceu análise especializada para ataques sofisticados. Os períodos críticos de compras mantiveram a alta disponibilidade sem latência nas transações dos clientes durante a 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: implantar firewall do aplicativo Web

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

Princípio de segurança

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

Risco a mitigar

Os invasores exploram vulnerabilidades de aplicativo Web para obter acesso não autorizado, executar código mal-intencionado, 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 Web, permitindo acesso de banco de dados não autorizado, exfiltração de dados ou comprometimento do sistema. A injeção de SQL (SQLi) manipula consultas de back-end (por exemplo, acrescentando ' OR '1'='1 a um formulário de login), enquanto a injeção de comando executa comandos arbitrários do sistema operacional (por exemplo, ; rm -rf / por meio de um campo de formulário).
• Violações de protocolo HTTP e solicitações malformadas: Os invasores enviam solicitações HTTP malformadas (por exemplo, cabeçalhos inválidos, conteúdos superdimensionados ou métodos não padrão como TRACE) para explorar vulnerabilidades em servidores Web ou aplicativos, potencialmente causando falhas ou acesso não autorizado. Esses ataques têm como alvo servidores mal configurados ou estruturas sem correção.
• Ataques conduzidos por bots (por exemplo, preenchimento forçado de credenciais, raspagem de dados): bots automatizados iniciam ataques de preenchimento forçado de credenciais (por exemplo, forçando pontos de extremidade de logon com credenciais roubadas) ou raspam conteúdo sensível (por exemplo, informações de preços), sobrecarregando servidores ou comprometendo contas de usuário. 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 invasores exploram vulnerabilidades para incluir arquivos mal-intencionados (por exemplo, incluir 'http://evil.com/shell.php') ou acessar arquivos de servidor local (por exemplo, .. /.. /etc/passwd) por meio de parâmetros de URL manipulados ou entradas de formulário, habilitando a execução de código ou a exposição de dados.

MITRE ATT&CK

• Acesso Inicial (TA0001): Explora a injeção de SQL, XSS ou inclusão de arquivo remoto para obter entrada (por exemplo, T1190 – Exploit Public-Facing Application).
• Execução (TA0002): Executa código mal-intencionado por meio de injeção de comando, RFI ou XSS (por exemplo, T1059 – Interpretador de Comando e Script).
• Acesso à credencial (TA0006): Rouba credenciais por meio de XSS ou recheio de credencial (por exemplo, T1539 – Roubar Cookie de Sessão da Web, T1110 – Força Bruta).
• Coleção (TA0009): Coleta dados por meio de injeção de SQL ou raspagem (por exemplo, T1213 – Dados de Repositórios de Informações).

NS-6.1 Configurar o WAF do Azure com as regras apropriadas

Habilite os recursos de WAF (firewall de aplicativo Web) no Gateway de Aplicativo do Azure, no Azure Front Door ou na CDN (Rede de Distribuição 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 do 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 de serviço:

• Selecione o serviço WAF apropriado: Escolha o Gateway de Aplicativo do Azure para aplicativos hospedados por VNet, o Azure Front Door para entrega de borda global ou a CDN do Azure para cargas de trabalho voltadas para conteúdo pesado, com base nos requisitos e na arquitetura do aplicativo.

• Configurar políticas do WAF com regras internas e personalizadas: Comece com conjuntos de regras internos comuns, como crs 3.2 (conjunto de regras do OWASP Core) e regras de proteção contra 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 do WAF: Use o modo de detecçã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. Alterne para o modo de prevenção para aplicativos críticos depois que as regras forem validadas para bloquear solicitações mal-intencionadas.

• Associe a política do WAF ao ponto de extremidade de serviço: Associe a política do WAF ao Gateway de Aplicativo, ao Front Door ou ao ponto de extremidade CDN para garantir que todo o tráfego HTTP/HTTPS seja roteado por meio 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 stuffing de credenciais executado por bots, mantendo o desempenho para usuários legítimos.

Desafio: A organização tinha aplicativos web implantados globalmente sem proteção contra as 10 principais vulnerabilidades da OWASP, resultando em múltiplas tentativas de injeção de SQL, ataques controlados por bots sobrecarregando pontos de acesso de login e sem visibilidade sobre os padrões de tráfego mal-intencionados. Os aplicativos não tinham controles de limitação de taxa, permitindo o abuso de API e ataques de recheio de credenciais, e não havia mecanismo para distinguir usuários legítimos de bots mal-intencionados.

Abordagem da solução:

• Seleção do serviço WAF: Implantado o Gateway de Aplicativo do Azure com WAF para aplicativos hospedados por VNet 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 internos: Habilitou o CRS (Conjunto de Regras Principais do OWASP) 3.2 para proteger contra injeção de SQL, XSS (script entre sites), inclusão remota de arquivos e outras vulnerabilidades comuns da Web e ativou regras do Microsoft Bot Manager para identificar e bloquear bots mal-intencionados, permitindo rastreamentos e serviços de monitoramento legítimos do mecanismo de pesquisa.
• Regras personalizadas para ameaças específicas: Regras de limitação de taxa implementadas bloqueando clientes que excedem 100 solicitações por minuto para evitar abuso de API e recheio de credenciais, regras de filtragem geográfica bloqueando o tráfego de regiões de alto risco em que os serviços estão indisponíveis e regras baseadas em reputação ip bloqueando solicitações de intervalos ip mal-intencionados conhecidos identificados por meio de feeds de inteligência contra ameaças.
• Gerenciamento de exclusão: Criamos exclusões direcionadas para cenários de negócios legítimos, como endpoints /checkout com entradas de formulário complexas que disparavam falsos positivos em regras OWASP, endpoints /upload que lidam com o envio de arquivos grandes e endpoints /api com padrões de cabeçalho incomuns, mas válidos, de aplicativos móveis.
• Transição de detecção para prevenção: Iniciou o WAF no modo de detecção por duas semanas para identificar falsos positivos, e, em seguida, as regras foram refinadas e as exclusões baseadas em padrões de tráfego legítimos, depois passou para o modo de prevenção em aplicativos de produção para bloquear ativamente as ameaças enquanto mantém a continuidade dos negócios.

Resultado: A organização eliminou a injeção de SQL e as tentativas de exploração do XSS, reduziu substancialmente os ataques controlados por bot por meio de regras do gerenciador de bots e estabeleceu uma visibilidade abrangente das ameaças do aplicativo Web. Os controles de limitação de taxa impediram o abuso de API e o recheio de credenciais, enquanto a transição em fases da detecção para o modo de prevenção garantiu que os usuários legítimos não experimentassem nenhuma interrupção no 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: Gerenciar a segurança de rede de forma central e eficaz

Princípio de segurança

Para reduzir o risco operacional e a configuração incorreta no ambiente de rede complexo e fragmentado, use os recursos de gerenciamento de rede nativa de 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 ignoradas ou desatualizadas, aumentando o risco de exploração.

• Imposição de política inconsistente e configurações incorretas: O gerenciamento descentralizado geralmente leva a conjuntos de regras fragmentados e lacunas de política, facilitando a descoberta e exploração de pontos fracos pelos invasores. Configurações incorretas 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 gerenciamento unificada, o monitoramento e a resposta a incidentes tornam-se mais lentos e menos eficazes. Isso pode atrasar a detecção de atividades mal-intencionadas, permitindo aos invasores mais tempo para escalonar ataques ou exfiltrar dados.
• Dificuldade para manter a conformidade: O gerenciamento central inadequado complica os esforços para atender consistentemente aos padrões regulatórios e do setor, arriscando a não conformidade e possíveis penalidades.

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 os conjuntos de regras fragmentados e a falta de monitoramento centralizado para evitar a detecção (por exemplo, T1562 – Defesas prejudicadas).
• Movimento Lateral (TA0008): Movendo-se lateralmente pela rede explorando lacunas de política ou segmentação desatualizada (por exemplo, T1021 – Serviços Remotos).
• Comando e controle (TA0011): Usando caminhos de rede não monitorados ou mal configurados para estabelecer e manter canais C2 (por exemplo, T1071 – Protocolo de Camada de Aplicativo).

NS-7.1 Gerenciar a segurança de rede de forma central e eficaz

Use as ferramentas centralizadas do Azure e as práticas padronizadas para simplificar e dimensionar o gerenciamento de segurança de rede, garantindo a imposição consistente, a redução da configuração incorreta e o monitoramento aprimorado. Implemente a imposição de política centralizada, padronizar o firewall e o gerenciamento de roteamento, habilitar monitoramento e análise abrangentes e manter a consistência de recursos por meio de práticas de governança:

• Implementar a imposição de política centralizada: Use o AVNM (Virtual Network Manager) do Azure para definir regras de administrador de segurança que se aplicam consistentemente entre assinaturas e regiões. Retenha NSGs para micro segmentação no nível da carga de trabalho. Aplique políticas por meio de grupos de rede (por exemplo, por ambiente: produção, não-produção).

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

• Habilite o monitoramento e a 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-se à Análise de Tráfego, ao Log Analytics e ao Microsoft Sentinel. Utilize a Análise de Política de Firewall e a contagem de acertos de regra para eliminar regras não utilizadas ou duplicadas.

• Manter a consistência e a governança de recursos: Aplique convenções de nomenclatura de CAF e marcas de recurso obrigatórias a todas as VNets, NSGs, regras de firewall e grupos. Use o Endurecimento de Rede Adaptável do Defender para Nuvem para refinar regras excessivamente permissivas.

Exemplo de implementação

Caso de uso: Plataforma de pagamento de várias regiões consolida a segurança de rede em escala

Contexto: Um processador de pagamento de médio porte que opera no Leste dos EUA e Oeste da Europa com quatro assinaturas (Prod, Non-Prod, Shared Services, SecOps) em um único locatário precisa de segmentação PCI-DSS, menos incidentes de desvios de regras e monitoramento centralizado.

Imposição de política centralizada com o Gerenciador de Rede Virtual do Azure:

• Projetar: Crie a AVNM no nível do grupo de gerenciamento. Defina dois Grupos de Rede: ng-prod e ng-nonprod com associação dinâmica por etiqueta subscriptionId. Elaborar SARs (Regras de Administração de Segurança) para impor diretrizes organizacionais que são avaliadas antes da implementação de NSGs (Grupos de Segurança de Rede): Deny-Inbound-Internet-to-Spokes (bloqueia entradas não solicitadas da Internet para todas as sub-redes spoke), Allow-Hub-Infra (permite serviços do hub - Firewall/Bastion - nos spokes), Allow-Platform-DNS (permite DNS de resolvedores do hub para os spokes).
• Limites da equipe de aplicativo: As cargas de trabalho mantêm NSGs para micro segmentação (por exemplo, web to api :443, api to db :1433) em cada spoke. Alterações de NSG são responsabilidade das equipes de aplicativos; SARs são responsabilidade da equipe de segurança da plataforma.
• Resultado: Os guardrails 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.

Gerenciamento de firewall e roteamento com o Gerenciador de Firewall e a WAN Virtual:

• Projetar: Implantar hubs seguros de WAN Virtual em cada região (Leste dos EUA, Oeste da Europa). Anexe spokes ao hub mais próximo e habilite a intenção de roteamento para que todas as saídas da Internet sejam inspecionadas. Utilize o Gerenciador de Firewall com uma Política de Firewall global (Camada: Premium) e duas políticas filhas (Produção/Não-Produção) para substituições de ambiente.
• Estrutura de política: A política base (global) inclui Inteligência de Ameaças definida como Alerta + Denegar, inspeção TLS habilitada para HTTPS de saída, IDPS ativado no modo balanceado e regras de permissão de saída usando Marcas de Serviço (Armazenamento, KeyVault, AzureMonitor) e Grupos de IP para pontos de extremidade de parceiro. A política de produção infantil tem filtragem de URL mais rigorosa (bloquear não categorizados) e lista de permissões para gateways de pagamento usando Grupos de IP. A política secundária não-produtiva tem acesso mais amplo à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 todas as saídas são inspecionadas com descriptografia TLS, quando permitido.

Monitoramento e análise com os Logs de Fluxo v2 e Sentinel:

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

Consistência e governança de recursos com CAF e Defender para Nuvem:

• Padrões: Aplique nomenclatura de 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 do Azure Policy para exigir NSG em cada sub-rede, exigir configurações de diagnóstico em VNets e Firewall para o workspace central de LA e negar a criação sem marcas obrigatórias. Habilite o Defender para Cloud – Proteção de Rede Adaptável em todos os spokes com itens de ação revisados semanalmente no SecOps CAB.
• Resultado: O desvio da plataforma é detectado rapidamente; regras excessivamente permissivas são apertadas usando as recomendações orientadas por dados do Defender.

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

• Estabelecer hubs seguros vWAN, anexar ramificações, habilitar a intenção de roteamento (somente ramificações piloto). Critérios de aceitação: saída dos spokes piloto por meio do firewall; nenhum IP público acessível diretamente.
• Implante SARs AVNM em ng-nonprod, verifique se não houve interrupção e depois implante em ng-prod. Critérios de aceitação: probes sintéticos confirmam que os serviços de hub (DNS/Bastion) ainda alcançam os spokes; o acesso à Internet de entrada ainda está negado.
• Habilitar logs de fluxo de vNet v2 e todos os diagnósticos de firewall; integrar a pasta de trabalho do Sentinel. Critérios de aceitação: painéis mostram fluxos, negações, ocorrências de IDPS por região.
• Aplicar iniciativas de políticas; corrigir itens não compatíveis; habilitar o fortalecimento adaptativo. Critérios de aceitação: a conformidade atinge 95%, lista de pendências de itens de aperto NSG/firewall criados.
• Primeira revisão da Análise de Políticas; remova regras não utilizados por meio da janela de alteração. Critérios de aceitação: contagem de regras reduzida em 15% sem impacto no cliente.

Exemplos de runbook operacional:

• SARs do Gerenciador de Rede Virtual do Azure: Negar Internet de Entrada para Spokes (Prioridade 100), Permitir Infra de Hub para Spokes (Prioridade 200: intervalos de hub src 10.0.0.0/16)
• Estrutura de Política de Firewall: azfw-policy-global-01 (Premium) com conjuntos de regras Allow-Azure-Platform-ST (Tags de Serviço) e Allow-Partners-IPs (Grupos de IP: ipg-payment-gws), além de políticas filhas azfw-policy-prd-01 e azfw-policy-npd-01
• Diagnostics: Destino: law-secops-01, Categories: 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: Detectar e desabilitar serviços e protocolos inseguros

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

Princípio de segurança

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

Risco a mitigar

Os atores 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 de interceptação (por exemplo, POODLE, BEAST), o que permite que adversários decifrem dados confidenciais, como tokens de sessão, por meio de ataques de oracle de preenchimento ou de criptografia escolhida.
• Acesso não autorizado por meio de 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 o acesso não autenticado, habilitando as bases iniciais.
• Roubo de credenciais: LM/NTLMv1 e wDigest são suscetíveis a armazenar hashes fracos ou credenciais em texto puro, tornando-os vulneráveis a ataques de pass-the-hash ou à extração de memória (por exemplo, o Mimikatz, que extrai dados da memória LSASS).
• Movimento Lateral: As sessões e explorações não criptografadas 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 explorações conhecidas, bloqueando a entrada não autorizada (por exemplo, T1190 – Exploit Public-Facing Application).
• Acesso à credencial (TA0006): Roubo de credenciais explorando LM/NTLMv1 e wDigest, que armazenam credenciais em formatos reversíveis ou hashes fracos, frustrando o ataque pass-the-hash ou raspagem de memória (por exemplo, T1003 – Despejo de Credenciais do Sistema Operacional).
• Movimento Lateral (TA0008): Inibe o movimento lateral dos atacantes, que utilizam SMBv1 vulnerável a explorações como EternalBlue, impedindo a propagação entre redes (por exemplo, T1021 – Serviços Remotos).

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

Use a pasta de trabalho de protocolo inseguro interna do Microsoft Sentinel para descobrir e atenuar serviços e protocolos inseguros em seu ambiente do 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 associação LDAP não assinada. Após a identificação, desabilite esses protocolos e serviços inseguros. Quando a desabilitaçã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 Inseguro do Microsoft Sentinel para identificar o uso de criptografias SSL/TLSv1, SSHv1, SMBv1, LM/NTLMv1, wDigest, codificações Kerberos fracas e associações LDAP não assinados em seu ambiente.

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

Implementar controles de compensação: Se não for possível desabilitar serviços ou protocolos inseguros devido a requisitos comerciais 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 saúde precisava eliminar protocolos inseguros em seu ambiente do Azure para atender aos requisitos de conformidade do HIPAA e reduzir a superfície de ataque para obter informações de integridade protegidas.

Desafio: A organização operava uma infraestrutura híbrida com aplicativos herdados que exigem 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 atendem portais de pacientes, SMBv1 habilitado em servidores de arquivos para software de imagem médica herdado, autenticação LM/NTLMv1 em controladores de domínio e servidores de aplicativos, autenticação wDigest armazenando credenciais em formato reversível, associações LDAP não assinados em controladores do Active Directory e criptografia Kerberos fraca em contas de serviço. A organização não tinha visibilidade sobre o uso de protocolos e enfrentava possíveis violações de compatibilidade com a HIPAA.

Solution:

• Implantação da Pasta de Trabalho de Protocolo Inseguro do Sentinel: Implantou o Microsoft Sentinel e instalou a Pasta de Trabalho de Protocolo Inseguro do hub de conteúdo, fontes de dados conectadas, incluindo logs de eventos de segurança do Windows, logs do Azure Monitor, logs do Active 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: Usou a Pasta de Trabalho de Protocolo Inseguro para identificar o uso de SSL/TLSv1.0 em servidores Web, tráfego SMBv1 de estações de trabalho de imagens médicas herdadas, padrões de autenticação LM/NTLMv1, wDigest habilitado em servidores Windows, associações LDAP não assinados de aplicativos herdados e criptografia Kerberos RC4 fraca em contas de serviço.

• Desabilitação sistemática de protocolos: Criou-se um plano de correção em fases validado por meio do conselho consultivo de alterações, TLSv1.0/1.1 foi desabilitado em servidores web após confirmar que os usuários do portal do paciente operavam navegadores modernos com suporte a TLS 1.2+, SMBv1 foi desabilitado após coordenar com o fornecedor de software de imagem médica para atualizações, controladores de domínio passaram da autenticação NTLMv1 para NTLMv2, wDigest foi desabilitado por meio da Política de Grupo, imposição da assinatura LDAP nos controladores de domínio, e criptografia Kerberos da conta de serviço foi atualizada para AES256.

• Controles de compensação para exceções: Implementou controles de compensação baseados em rede para sistemas que exigem suporte temporário de protocolo inseguro, incluindo VLAN isolada para estações de trabalho de imagens médicas legadas que exigem SMBv1, regras NSG restringindo o tráfego SMBv1 exclusivamente à VLAN isolada, Firewall do Azure negando o tráfego SMBv1 de saída das sub-redes de produção, jump host dedicado para aplicativos de RH legados e monitoramento aprimorado através do Defender para Endpoint sinalizando o uso do protocolo fora das sub-redes de exceção aprovadas.

• Monitoramento contínuo: Estabeleceu a higiene contínua do protocolo por meio das regras de análise do Microsoft Sentinel que disparam alertas para novas conexões de protocolo inseguras fora das exceções aprovadas, o Azure Policy negando a implantação sem o requisito mínimo do TLS 1.2 e revisões semanais da Pasta de Trabalho de Protocolo Inseguro acompanhando o progresso da correção.

Resultado: Conexões TLS fracas foram eliminadas dos portais do paciente. O SMBv1 foi desabilitado após atualizações de imagens médicas, eliminando a vulnerabilidade EternalBlue e alcançando a conformidade com a HIPAA. NTLMv1 fez a transição para NTLMv2, impedindo ataques de passagem de hash. O desativamento do wDigest mitigou o roubo de credenciais. A assinatura LDAP bloqueou consultas não assinadas. Kerberos foi atualizado para AES256, reduzindo o risco de Kerberoasting. Os controles de compensação continham sistemas herdados sem movimento lateral. Conformidade completa do HIPAA obtida.

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 a rede local ou na nuvem de forma privada

Princípio de segurança

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

Risco a mitigar

Quando os dados viajam por redes públicas, eles são vulneráveis à interceptação, ao acesso não autorizado e à adulteração.

• Interceptação de dados: Quando os dados viajam por redes públicas como a Internet, eles passam por vários roteadores, comutadores e provedores de serviços, qualquer um dos quais pode ser comprometido ou monitorado por atores mal-intencionados. Os invasores podem implantar ferramentas de detecção de pacotes (por exemplo, Wireshark) para capturar pacotes de dados. Se os dados não forem criptografados ou criptografados fracamente, informações confidenciais , como credenciais de logon, detalhes financeiros ou dados comerciais proprietários, poderão ser expostas.
• Ataques do MitM (Man-in-the-Middle): Em um ataque do MitM, um invasor intercepta secretamente e potencialmente altera a comunicação entre duas partes que acreditam estar se comunicando diretamente entre si. 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 protegidas inadequadamente aumentam a probabilidade de usuários não autorizados obterem acesso ou adulteração em sistemas ou recursos privados. Os invasores podem explorar pontos fracos de rede para alcançar a infraestrutura interna que deve permanecer inacessível de fora.

MITRE ATT&CK

• Acesso Inicial (TA0001): Exploração de protocolos não criptografados ou criptografados fracamente (por exemplo, versões HTTP ou TLS desatualizadas) vulneráveis a ataques de detecção de pacotes ou MitM, permitindo entrada não autorizada em sistemas (por exemplo, T1190 – Exploit Public-Facing Application).
• Acesso à credencial (TA0006): Roubo de credenciais por meio do tráfego de rede interceptado, explorando protocolos cleartext (por exemplo, Telnet ou FTP) ou criptografia fraca suscetível à descriptografia, facilitando o acesso não autorizado (por exemplo, T1040 – Detecção de Rede).
• Movimento Lateral (TA0008): Propagação dentro de redes explorando serviços configurados incorretamente ou expostos (por exemplo, RDP não corrigido ou SMB), permitindo que os invasores pivotem usando credenciais roubadas ou vulnerabilidades (por exemplo, T1021 – Serviços Remotos).

NS-9.1 Usar VPN (rede virtual privada) do Azure para conectividade site a site leve 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 leves de conectividade. A VPN do Azure fornece uma solução econômica para conectividade site a site (conectando redes inteiras) ou conectividade ponto a site (conectando dispositivos individuais) sem a necessidade de infraestrutura dedicada:

• Implantar VPN site a site: Use a 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.

• Implantar VPN ponto a site: Use VPN ponto a site para habilitar dispositivos de usuário final individuais (laptops, estações de trabalho) para se conectarem com segurança à rede virtual do Azure 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 de baixa latência entre datacenters do Azure e infraestrutura local em ambientes de colocação. 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 críticas 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 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.

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

NS-9.3 Use a VNet ou o emparelhamento de sub-rede para ingressar em redes virtuais

Use emparelhamento de rede virtual ou 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:

• Implantar emparelhamento de rede virtual: Use o emparelhamento de rede virtual para conectar redes virtuais inteiras do Azure, permitindo que os 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 globalmente, exigindo conectividade com aplicativos hospedados no Azure que processam transações financeiras e dados do cliente. A arquitetura inicial usava VPN site a site pela Internet, enfrentando 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 que atravessam a Internet pública, apesar da criptografia e requisitos de conformidade que exigem conectividade privada para PCI-DSS e RGPD. Os funcionários remotos que se conectam por meio de VPN ponto a site tiveram problemas inconsistentes de desempenho e autenticação. 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 primário: Circuitos do Azure ExpressRoute implantados em data centers primários por meio de instalações de co-localização com provedores de conectividade do ExpressRoute, estabelecendo conectividade privada de Camada 3 com rede de backbone do Azure com baixa latência consistente, configuração do ExpressRoute com emparelhamento da Microsoft para serviços de PaaS do Azure e emparelhamento privado para recursos hospedados pela VNet, roteamento BGP implementado com configuração ativa-ativa para alta disponibilidade e failover automático.

• Site-to-site VPN para conectividade de filial: Site-to-site VPN implantado para filiais sem acesso a instalações de co-localização, criando o Gateway de VPN na VNet do hub com configuração ativa-ativa para alta disponibilidade, configuração de túneis IPsec/IKE com criptografia forte atendendo aos padrões de segurança do setor financeiro, implementou o roteamento BGP para seleção de caminho dinâmico, permitindo que as filiais se conectem ao hub regional mais próximo, túneis redundantes estabelecidos 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, com a autenticação baseada em certificado habilitada como método alternativo para cenários sem acesso à Internet ao Azure AD. Os endereços IP de cliente são atribuídos a partir de um pool dedicado e roteados para recursos da VNet do Azure por meio de rotas definidas pelo usuário. Protocolos OpenVPN foram implementados para clientes macOS/Linux e IKEv2/SSTP para clientes Windows, fornecendo ampla compatibilidade de dispositivos. Configurado o split tunneling, permitindo que o tráfego não corporativo acesse a Internet diretamente, enquanto o tráfego direcionado ao Azure é roteado pelo túnel VPN, otimizando a largura de banda.

• Virtual WAN para conectividade de malha global: Implantação da Azure Virtual WAN com hubs seguros em várias regiões, fornecendo arquitetura de trânsito global, circuitos do ExpressRoute conectados a hubs de Virtual WAN, permitindo conectividade any-to-any entre data centers e regiões do Azure sem roteamento por meio de hubs locais, conexões VPN site a site integradas de filiais para o hub de Virtual WAN mais próximo com otimização de roteamento automático, Azure Firewall habilitado em cada hub de Virtual WAN fornecendo inspeção de segurança centralizada para o tráfego entre filiais, data centers e VNets do Azure, configuradas políticas de roteamento implementando o roteamento de trânsito global, permitindo que as filiais se comuniquem com data centers on-premises por meio do backbone do Azure.

• Emparelhamento de VNet para conectividade entre regiões do Azure: Implementou o emparelhamento de rede virtual, conectando VNets spoke aos VNets de Hub WAN Virtual em cada região. Permitido o emparelhamento de VNet global para conectividade de aplicativos entre regiões, proporcionando baixa latência sobre o backbone do Azure. Configurado o trânsito de gateway, o que permite que VNets spoke utilizem os gateways VPN/ExpressRoute do Hub WAN Virtual sem a necessidade de implantar gateways adicionais, reduzindo custos e complexidade. Implementados grupos de segurança de rede nas sub-redes spoke para controlar o fluxo de tráfego entre VNets emparelhadas, com acesso de privilégio mínimo.

• Otimização e monitoramento de tráfego: Circuitos do ExpressRoute configurados com marcações de QoS priorizando o tráfego de transações financeiras em transferências de dados em massa, latência de rastreamento do Monitor de Conexão habilitada, perda de pacotes e disponibilidade para circuitos do ExpressRoute e conexões VPN com alertas de degradação, pastas de trabalho do Azure Monitor implementadas visualizando topologia de conectividade global mostrando conexões ativas, utilização de largura de banda e eventos de failover, linhas de base estabelecidas para desempenho aceitável com alertas automatizados para violações de limite.

Resultado: A conectividade privada foi obtida para todas as transações financeiras, atendendo aos requisitos de PCI-DSS. O ExpressRoute forneceu baixa latência consistente para negociação em tempo real. O Virtual WAN reduziu substancialmente a latência de filial para o centro de dados. Funcionários remotos conectados com êxito por meio de VPN ponto a site com autenticação aprimorada. O emparelhamento VNet global habilitou uma recuperação eficiente de desastre entre regiões. Otimização de custo obtida por meio da consolidação da 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
• CIS Controls 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: garantir a segurança do DNS (Sistema de Nomes de Domínio)

Princípio de segurança

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

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

Risco a mitigar

Os atores de ameaça atacam serviços DNS ou exploram serviços DNS vulneráveis para comprometer aplicativos e redirecionar o tráfego.

• Falsificação/envenenamento de DNS: Os adversários forjam respostas DNS ou caches de resolvedores corrompidos (por exemplo, ataque kaminsky) para redirecionar clientes para servidores mal-intencionados, habilitando phishing ou interceptação de dados.
• Ataques de amplificação DNS: Os invasores exploram servidores DNS configurados incorretamente para ampliar o tráfego de DDoS (por exemplo, consulta de 60 bytes que gera resposta de 4.000 bytes), sobrecarregando as redes de destino.
• Exploração de DNS parasitário: Registros parasitas (por exemplo, CNAMEs obsoletos) permitem que os adversários apoderem-se de recursos desativados, redirecionando o tráfego para endereços maliciosos destinados ao phishing ou à disseminação de malware.
• Exfiltração de dados por meio de túnel DNS: Atores mal-intencionados codificam dados em consultas DNS (por exemplo, data.exfil.evil.com) para exfiltrar informações confidenciais secretamente, ignorando firewalls.
• Entrega de phishing/malware: Resolvedores comprometidos redirecionam domínios legítimos para IPs controlados por invasores, fornecendo páginas de phishing ou malware para clientes desavisados.

MITRE ATT&CK

• Comando e Controle (TA0011): Use o tunelamento DNS para codificar comandos de C2 em consultas DNS (por exemplo, data.exfil.evil.com) ou resoluções DNS falsificadas para se conectar a servidores mal-intencionados (por exemplo, T1071.004 – Protocolo de Camada de Aplicativo: DNS).
• Coleção (TA0009): Colete dados falsificando DNS para redirecionar usuários para sites de phishing ou exfiltração de dados por meio de túnel (por exemplo, T1040 – Detecção de Rede).
• Impacto (TA0040): Ataques de amplificação de DNS, enviando pequenas consultas para gerar respostas grandes, interrompendo a disponibilidade do serviço (por exemplo, T1498.002 – Negação de Serviço de Rede: Amplificação de Reflexão).
• Acesso Inicial (TA0001): Explorar registros DNS pendentes ou resoluções falsificadas para fornecer malware/phishing, obtendo entrada em sistemas (por exemplo, T1190 – Exploração de Aplicação Voltada para o Público).

NS-10.1 Usar serviço DNS confiável

Use serviços 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 do 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 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 de VM ou configurações de DNS de aplicativo para garantir a resolução de nomes confiáveis.

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

• Hospedar domínios no Azure DNS: Use o Azure DNS para hospedar domínios para necessidades de DNS autoritário, fornecendo hospedagem DNS confiável e escalonável (observação: o Azure DNS não fornece serviço de registro de domínio).

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

NS-10.2 Usar DNS Privado em Rede Virtual

Use o DNS Privado do Azure para estabelecer zonas DNS privadas em que a resolução DNS permanece dentro da rede virtual, impedindo que as consultas DNS percorram redes públicas. Isso é essencial para configurações de ponto de extremidade privado, em que zonas DNS privadas substituem a resolução DNS pública para rotear o tráfego privadamente para os serviços do Azure. As soluções DNS personalizadas podem restringir ainda mais a resolução apenas a fontes confiáveis, aprimorando a segurança para cargas de trabalho privadas:

• Implantar 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 de rede.

• Configurar o DNS privado para pontos de extremidade privados: Configurar zonas DNS privadas para pontos de extremidade privados a fim de substituir a resolução DNS pública e garantir que os clientes resolvam FQDNs de ponto de extremidade privado para endereços IP privados na rede virtual.

• Implemente o 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 de resolução de nomes.

NS-10.3 Usar o Defender para DNS para proteção avançada

Use o Microsoft Defender para DNS para detectar e alertar sobre ameaças avançadas de segurança baseadas em DNS, incluindo exfiltração de dados por meio de túnel DNS, comunicação de comando e controle, interações de domínio mal-intencionadas (phishing, mineração de criptografia) e ataques DNS envolvendo resolvedores mal-intencionados. A proteção do Defender para DNS agora está incluída no Plano do Defender para Servidores. Além disso, use o Microsoft Defender para Serviço de Aplicativo para detectar registros DNS pendentes que possam habilitar ataques de aquisição de subdomínio ao desativar sites:

• Habilitar a proteção do Defender para DNS: Use o Microsoft Defender para DNS (incluído no Plano do Defender para Servidores) para monitorar e alertar sobre atividades DNS suspeitas, 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 a atividade DNS mal-intencionada: Configure alertas para detectar a comunicação com resolvedores DNS mal-intencionados e ataques DNS que podem comprometer a segurança da carga de trabalho ou a disponibilidade do serviço DNS.

• Detectar registros DNS pendentes: Use o Microsoft Defender para Serviço de Aplicativo para identificar registros DNS pendentes ao desativar sites do Serviço de Aplicativo, impedindo ataques de aquisição de subdomínio, garantindo que domínios personalizados sejam removidos dos registradores DNS.

Exemplo de implementação

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

Abordagem da solução:

• Implantado o DNS recursivo do Azure (168.63.129.16) para todas as cargas de trabalho de máquinas virtuais do Azure com regras NSG que permitem o tráfego DNS
• Zonas autoritativas hospedadas no DNS do Azure para resolução de domínio público com distribuição geográfica
• As zonas Azure Private DNS foram implementadas para a resolução de endpoint privado (privatelink.database.windows.net, privatelink.blob.core.windows.net) vinculadas a VNets de produção.
• A integração de DNS privado foi configurada para garantir que os FQDNs de pontos de extremidade privados sejam resolvidos em IPs privados (por exemplo, sqlserver.database.windows.net → 10.0.2.4)
• Habilitado o Microsoft Defender para DNS por meio do Plano Defender para Servidores para monitorar o tunelamento DNS, a comunicação C2 e interações de domínio mal-intencionado
• Implantado Defender for App Service para detectar registros DNS pendentes durante o descomissionamento do site

Resultado: A implementação de segurança DNS garantiu a resolução de nomes confiáveis 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 para DNS forneceu 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ínio por meio da detecção de DNS pendente automatizada durante as alterações no ciclo de vida do recurso.

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