Grupos de segurança de rede e grupos de segurança de aplicativos

Este artigo explica como controlar o tráfego de rede em redes virtuais Azure usando NSGs (grupos de segurança de rede) para filtragem de tráfego. Ele também abrange OSGs (grupos de segurança de aplicativos) para agrupamento lógico de interfaces de rede.

O que este artigo aborda

Os grupos de segurança de rede permitem filtrar o tráfego de entrada e saída para recursos em uma rede virtual Azure. Os grupos de segurança do aplicativo permitem agrupar interfaces de rede por função. Escreva regras NSG que fazem referência a grupos lógicos em vez de endereços IP individuais.

Quem precisa deste artigo

Leia este artigo se você:

  • Implante qualquer recurso que se conecte a uma rede virtual Azure.
  • Precisa controlar o tráfego que flui entre sub-redes, máquinas virtuais ou serviços de Azure.
  • Deseja simplificar o gerenciamento de regras para ambientes em que as VMs são dimensionadas com frequência ou os endereços IP são alterados.
  • Estão criando uma linha de base de segurança para uma nova carga de trabalho de Azure.

Foco de lift-and-shift: Recrie suas regras de firewall e segmentação locais como NSGs entre sub-redes, espelhando os fluxos de camada a camada que seus aplicativos já usam.

Modernizar o foco: Use grupos de segurança de aplicativos para expressar regras por função de carga de trabalho em vez de endereço IP e emparelhar NSGs de sub-rede com um firewall de hub e rotas definidas pelo usuário que forçam a saída inspecionada.

Foco multinuvem: Espelhe as regras dos grupos de segurança da AWS e do Google Cloud nos NSGs do Azure para que a política de tráfego permaneça consistente à medida que as cargas de trabalho se movem entre diferentes nuvens.

Azure serviços e recursos

A tabela a seguir descreve os serviços e os recursos usados para filtragem de tráfego de rede em redes virtuais Azure.

Serviço ou recurso O que ele fornece Quando usar isso
NSG (Grupo de segurança de rede) Um conjunto de regras de segurança de entrada e saída aplicadas a uma sub-rede ou interface de rede. As regras são avaliadas por prioridade: o menor número vence. Controlar o tráfego no nível da sub-rede ou da VM individual. Aplica-se a todas as cargas de trabalho que utilizam uma rede virtual.
Grupo de segurança do aplicativo (ASG) Um agrupamento lógico de interfaces de rede. Use ASGs como origem ou destino em regras NSG em vez de endereços IP. Você tem várias VMs que atendem à mesma função (servidores Web, servidores de aplicativos) e seus endereços IP mudam com o dimensionamento. Todas as NICs agrupadas devem estar na mesma rede virtual.
Etiquetas de serviço Grupos nomeados de prefixos de endereço IP para serviços Azure, gerenciados e atualizados automaticamente por Microsoft. Exemplos: AzureCloud, Storage, AzureLoadBalancer, Sql. Consulte serviços do Azure em regras de NSG sem definir intervalos de IP diretamente. Microsoft atualiza os intervalos de IP subjacentes automaticamente. Você não pode criar marcas de serviço personalizadas.

Etiquetas de serviço comuns

A tabela a seguir lista as marcas de serviço mais usadas nas regras NSG.

Etiqueta de serviço Description
Internet Todo o espaço de endereço IP público fora da rede virtual. Corresponde a todo tráfego proveniente da Internet pública ou destinado a ela.
VirtualNetwork Seu espaço de endereçamento de rede virtual, todos os espaços de endereçamento conectados (VNets emparelhadas), redes locais (on-premises) conectadas via VPN/ExpressRoute e quaisquer extremidades de serviço. Inclui rotas padrão.
AzureLoadBalancer Azure balanceador de carga de infraestrutura. Traduz para o IP virtual do host, no qual as investigações de integridade do Azure se originam. Usado em regras de entrada para permitir o tráfego da sonda de integridade.
Storage Espaço de endereços IP do serviço Armazenamento do Azure. Dá suporte a variantes regionais como Storage.WestUS2. Use para permitir ou restringir o acesso a Armazenamento do Azure de dentro da VNet.
AzureCloud Todos os endereços IP públicos do datacenter do Azure. Dá suporte a variantes regionais como AzureCloud.EastUS. Útil para permitir o tráfego de saída para os serviços do Azure em geral.
Sql Prefixos de endereços IP do Banco de Dados SQL do Azure, do Banco de Dados do Azure para MySQL, do Banco de Dados do Azure para PostgreSQL, do Banco de Dados do Azure para MariaDB e do Azure Synapse Analytics. Dá suporte a variantes regionais.
Regras de segurança aumentadas Regras NSG estendidas que aceitam vários endereços IP, intervalos de IP e portas em uma única regra. Reduza a contagem de regras quando precisar permitir ou negar o tráfego para muitos IPs ou intervalos de portas. Dá suporte a vários IPs e intervalos de portas por regra e até 10 grupos de segurança de aplicativos, mas apenas uma marca de serviço por regra.

Como escolher

Use as diretrizes a seguir para selecionar o constructo de segurança correto para seu cenário.

Limites e cotas do NSG

Azure impõe os seguintes limites padrão em recursos NSG. Para aumentar a maioria dos limites, solicite um aumento por meio de Suporte do Azure.

Recurso Limite padrão Limite máximo
Regras por NSG 2.000 2.000
NSGs por assinatura 5,000 5,000
NSGs por sub-rede 1 1
NSGs por NIC 1 1
ASGs por assinatura 3,000 3,000
NICs por ASG Varia de acordo com a assinatura Contate o suporte
ASGs referenciados como origem ou destino em cada regra 10 10

Note

O limite de 2.000 regras para cada NSG inclui regras personalizadas e regras padrão. Se você se aproximar desse limite, use regras de segurança aumentadas para combinar vários IPs ou intervalos de portas em menos regras.

NSG versus ASG: quando usar

Use a tabela a seguir para determinar o constructo de segurança que se ajusta ao seu cenário.

Scenario Utilização Por que
Controlar o tráfego de todas as VMs em uma sub-rede NSG no nível da sub-rede Um NSG se aplica a todos os recursos na sub-rede. Mais simples de gerenciar para políticas uniformes.
Controlar o tráfego de uma VM específica independentemente de sua sub-rede NSG no nível de NIC Permite exceções sem afetar outras VMs. Útil para jump boxes ou hosts de bastiões.
Muitas VMs atendem à mesma função e endereços IP são alterados com frequência ASG Adicione VMs a um grupo por função (Web, aplicativo, dados). Defina regras para o nome do grupo. Nenhuma atualização é necessária quando as VMs são dimensionadas ou recebem novos IPs.
Serviços de Azure de referência (Armazenamento, SQL, Key Vault) como origem ou destino NSG com marcas de serviço Evite codificar intervalos de IP diretamente no código, pois a Microsoft pode atualizá-los. As tags de serviço são atualizadas automaticamente.

O diagrama a seguir mostra como os ASGs permitem agrupar VMs por função e escrever regras NSG entre grupos lógicos em vez de endereços IP individuais.

Diagrama que mostra VMs agrupadas em três grupos de segurança de aplicativos por função, com regras NSG permitindo a porta 443 da Web para o aplicativo e a porta 1433 do aplicativo para os servidores de dados.

Lista de verificação de postura de segurança

Valide a configuração do NSG nessa lista de verificação antes de implantar em produção.

Requirement Ação Referência
Postura de negação padrão Confirme se você depende da regra padrão DenyAllInbound (prioridade 65500). Não crie regras de permissão amplas que ignorem a negação padrão. Considerações de segurança
Sem acesso à Internet em portas de administração Bloqueie o tráfego de entrada de 0.0.0.0/0 nas portas SSH (22) e RDP (3389). Use Azure Bastion ou UMA VPN para acesso administrativo. Considerações de segurança
Combinar com Firewall do Azure para inspeção profunda Os NSGs filtram apenas nas camadas 3 e 4. Adicione Firewall do Azure para filtragem de camada de aplicativo (camada 7), inspeção de TLS e inteligência contra ameaças. Firewall do Azure e segmentação de rede
Habilitar logs de fluxo para diagnóstico Use logs de fluxo de VNet para capturar dados de tráfego para investigação e conformidade de segurança. Monitoramento e diagnóstico de rede

Ordem de avaliação das regras

As regras NSG usam a semântica em que a primeira correspondência prevalece:

  1. Azure avalia as regras em ordem de prioridade: número mais baixo (prioridade mais alta) primeiro.
  2. Azure avalia cada regra em relação a uma tupla de cinco: origem, porta de origem, destino, porta de destino e protocolo.
  3. Quando o tráfego corresponde a uma regra, o processamento é interrompido. Azure não avalia regras adicionais.
  4. Se nenhuma regra personalizada corresponder, as regras padrão se aplicarão. Você não pode excluir regras padrão, mas pode substituí-las criando regras personalizadas com números de prioridade entre 100 e 4096.

Regras padrão (seis no total):

Direction Nome da regra Prioridade Ação
Inbound AllowVNetInBound 65000 Permitir
Inbound AllowAzureLoadBalancerInBound 65001 Permitir
Inbound DenyAllInbound 65500 Deny
Saída AllowVnetOutBound 65000 Permitir
Saída AllowInternetOutBound 65001 Permitir
Saída DenyAllOutBound 65500 Deny

Restrições de ASG

Ao usar grupos de segurança de aplicativos, lembre-se das seguintes restrições:

  • Todos os adaptadores de rede em um ASG devem existir na mesma rede virtual que o primeiro adaptador de rede atribuído ao ASG.
  • Se você fizer referência a ASGs na origem e no destino de uma regra, as interfaces de rede em ambos os grupos deverão estar na mesma rede virtual.
  • Você pode fazer referência a até 10 ASGs na origem ou no destino de uma regra.

NSGs em nível de sub-rede e de interface de rede combinados

Você pode associar um NSG a uma sub-rede e a um adaptador de rede em uma VM dentro dessa sub-rede. Quando você faz isso, o Azure avalia ambos os NSGs, e o tráfego deve passar por ambos. A combinação mais restritiva vence.

Direction Avaliado pela primeira vez Segundo item avaliado
Inbound NSG da sub-rede NIC NSG
Saída NIC NSG NSG da sub-rede

Tip

Para solução de problemas mais simples, associe um NSG à sub-rede ou ao adaptador de rede, mas não a ambos. Se você precisar dos dois, documente claramente a interação pretendida entre as regras.

Exemplo prático: camada da Web com uma caixa de salto

Considere uma sub-rede com um NSG no nível da sub-rede que permite tráfego HTTPS de entrada (porta 443) proveniente da Internet e nega todo o restante. Uma VM de jump box nessa sub-rede tem um NSG no nível da interface de rede que também permite conexões SSH de entrada (porta 22) a partir de um intervalo específico de IPs de gerenciamento.

  • Tráfego da Web (porta 443): O NSG da sub-rede permite isso. O NSG da interface de rede nas VMs da Web não tem nenhuma regra de bloqueio para 443 (o padrão AllowVNetInBound permite). Fluxos de tráfego.
  • Conecte-se via SSH ao jump box (porta 22 a partir do IP de gerenciamento): O NSG da sub-rede nega o tráfego na porta 22 proveniente da internet. Embora o NSG da interface de rede permita o SSH do intervalo de gerenciamento, o NSG da sub-rede o bloqueia primeiro. Resolução: Adicione uma regra no NSG de sub-rede para permitir a porta 22 a partir do intervalo de IPs de gerenciamento ou use o Azure Bastion para contornar totalmente o tráfego pela Internet pública.

Este exemplo ilustra por que NSGs duplos adicionam complexidade. Ambos devem permitir o tráfego de forma independente.

O diagrama a seguir mostra o caminho de avaliação do tráfego de entrada quando você associa ambos um NSG de sub-rede e um NSG de NIC. O tráfego deve passar pelos dois NSGs. A combinação mais restritiva vence.

Diagrama que mostra o fluxograma de avaliação das regras de NSG para tráfego de entrada nos níveis de sub-rede e NIC para permitir ou negar

Interação com o Gerenciador de Rede Virtual do Azure

Se sua organização usar regras de administrador de segurança Gerenciador de Rede Virtual do Azure (AVNM), Azure avaliará essas regras antes das regras do NSG. As regras de administrador de segurança podem ser Allow (prosseguir para a avaliação do NSG), Always Allow (ignorar a avaliação do NSG) ou Deny (bloquear antes da avaliação do NSG). Para gerenciamento centralizado de segurança de rede, consulte Gerenciador de Rede Virtual do Azure e gerenciamento centralizado.

Considerações sobre o design

Foco do design de NSG e ASG para lift-and-shift

  • Traduza sua segmentação local em NSGs de nível de sub-rede: permita apenas os fluxos de camada a camada que seu aplicativo já usa (por exemplo, web-to-app e app-to-database) e negue todo o resto.
  • Parta da base atual de regras do firewall e torne-a mais restritiva após a migração, usando os logs de fluxo do NSG para confirmar quais fluxos são realmente necessários.
  • Aplique NSGs no nível da sub-rede primeiro para simplificar; adicione regras de nível NIC somente em que as VMs individuais precisam de exceções.
  • Use marcas de serviço (como VirtualNetwork e AzureLoadBalancer) em vez de endereços IP codificados para que as regras sobrevivam ao endereçamento durante a migração.

Modernizar o foco de design de NSG e ASG

  • Use grupos de segurança de aplicativos para agrupar interfaces de rede por função (Web, aplicativo, dados) para que as regras descrevam a intenção e se adaptem automaticamente à medida que as instâncias são dimensionadas.
  • Combine NSGs de sub-rede com um Firewall do Azure de hub: os NSGs lidam com a microssegmentação entre as camadas, enquanto o firewall inspeciona o tráfego que ultrapassa os limites de confiança.
  • Permita que apenas a sub-rede do endpoint privado acesse os serviços PaaS e force o tráfego de saída pela firewall do hub com rotas definidas pelo usuário.
  • Se você usar as regras de administrador de segurança do Gerenciador de Rede Virtual do Azure, planeje a precedência delas (elas são avaliadas antes dos NSGs) para que as proteções em toda a plataforma não entrem em conflito com os NSGs das cargas de trabalho.

Foco do design de NSG e ASG entre nuvens

  • Replique as regras dos grupos de segurança da AWS e do Google Cloud nos NSGs do Azure para que os níveis equivalentes apliquem a mesma política após a migração.
  • Permitir apenas as portas e fontes específicas necessárias para dependências de aplicativos entre nuvens e rotear esse tráfego por meio de túneis IPsec inspecionados.
  • Padronizar nomes de grupos de segurança de aplicativos entre nuvens para que as equipes de operações possam correlacionar cargas de trabalho equivalentes quando solucionarem problemas.
  • Emparelhe NSGs com um firewall de hub WAN Virtual protegido para que o tráfego entre nuvens e ramificações seja filtrado por NSGs e inspecionado pelo firewall.

Pré-requisitos

Antes de implementar NSGs e ASGs, verifique se você tem:

  • Uma rede virtual com sub-redes: Os NSGs são associados a sub-redes ou NICs dentro de uma rede virtual. Consulte redes virtuais e sub-redes para obter diretrizes de planejamento.
  • Um plano de endereçamento IP: As regras NSG fazem referência a intervalos e endereços IP. Um plano IP garante que você possa escrever regras precisas. Consulte o planejamento de endereço IP para obter diretrizes.
  • Uma lista de fluxos de tráfego necessários: Documente quais recursos precisam se comunicar, em quais portas e em qual direção antes de escrever regras.

Considerações de segurança

Importante

Negar por padrão é a postura correta. As regras de entrada padrão em Azure negam todo o tráfego da Internet que não é explicitamente permitido. Não enfraqueça essa postura criando regras de permissão amplas.

Nunca permitir 0.0.0.0/0 em portas administrativas

Caution

Nunca crie uma regra de NSG que permita tráfego de entrada de 0.0.0.0/0 (qualquer origem na Internet) para portas administrativas, como SSH (porta 22) ou RDP (porta 3389). Os invasores verificam continuamente a Internet em busca de portas de administrador abertas. Em vez disso, use Azure Bastion, uma VPN ou Link Privado do Azure para acessar máquinas virtuais com segurança.

Combinar NSGs com o Firewall do Azure

Os NSGs operam na camada 3 e na camada 4 (rede e transporte). Eles filtram com base em endereços IP, portas e protocolos, mas não inspecionam o conteúdo do pacote. Para cargas de trabalho que exigem filtragem de camada de aplicativo, inteligência contra ameaças ou inspeção do TLS, implante Firewall do Azure junto com NSGs. Consulte Firewall do Azure e segmentação de rede.

Usar logs de fluxo de VNet para visibilidade do tráfego

Note

Os logs de fluxo do NSG estão programados para serem desativados em 30 de setembro de 2027. Nenhum novo registro de fluxo NSG poderá ser criado após 30 de junho de 2025. Migre para os logs de fluxo da VNet, que fornecem os mesmos recursos, além de análise do tráfego no nível da rede virtual.

Os logs de fluxo da VNet capturam dados de estado por fluxo e taxa de transferência para todas as cargas de trabalho em uma rede virtual. Use-os para:

  • Investigação de segurança: identificar padrões de tráfego inesperados.
  • Auditoria de conformidade: prove que os fluxos de tráfego correspondem à política documentada.
  • Planejamento de capacidade: entenda o consumo de largura de banda entre sub-redes.

Para obter monitoramento e configuração de diagnóstico, consulte Monitoramento e diagnóstico de rede.

Erros comuns a serem evitados

Erro Por que é um problema Melhor abordagem
Criando regras de entrada allow-all (prioridade 100, origem *, destino *) Ignora a postura de negação padrão e expõe todos os recursos ao tráfego da Internet. Permitir apenas combinações específicas de origem/destino/porta. Use os maiores números de prioridade possíveis para as regras de permissão.
Esquecendo que a negação padrão existe As equipes criam regras de permissão para tráfego conhecido, mas não testam se todo o resto está bloqueado. Portas abertas não intencionais podem passar despercebidas. Depois de implantar os NSGs, verifique, por meio dos logs de fluxo da VNet ou dos diagnósticos de NSG, se somente o tráfego esperado está fluindo. Teste explicitamente os caminhos negados.
Não usar ASGs para cargas de trabalho dinâmicas As regras baseadas em IP são interrompidas quando as VMs escalam horizontalmente ou obtêm novos IPs. As equipes acabam atualizando regras constantemente. Agrupar VMs por função usando ASGs. As regras que fazem referência aos ASGs permanecem válidas à medida que as VMs são adicionadas ou removidas do grupo.
Ignorando logs de fluxo até que ocorra um incidente de segurança Sem os logs de fluxo habilitados, você não tem dados históricos de tráfego para investigações ou auditorias de conformidade. Habilite os logs de fluxo da VNet desde o primeiro dia. Configure a Análise de Tráfego para visualização e alertas sobre anomalias.
Aplicando os NSGs da sub-rede e da NIC sem documentação adequada NSGs duplos criam interações confusas em que o tráfego é negado inesperadamente. A solução de problemas torna-se demorada. Escolha NSGs de nível de sub-rede ou NIC como padrão. Se ambos forem necessários, documente a interação pretendida para cada sub-rede.

Saiba mais

Próximas Etapas 

Tip

Explorando por conta própria? Retorne ao navegador de visão geral para encontrar seu próximo artigo por funcionalidade.

A seguir, na sua jornada de lift-and-shift:

Crie sua topologia hub-and-spoke: centralize serviços compartilhados como DNS, firewall e Gateway de VPN em suas cargas de trabalho migradas.

A seguir, em sua jornada de modernização:

Projete sua topologia hub-and-spoke: configure uma topologia com dois hubs, com hubs de TI e spokes gerenciados pela equipe de aplicativos, para suas cargas de trabalho de PaaS.

A seguir, em sua jornada multinuvem:

Configure túneis criptografados para suas outras nuvens: Configure conexões de Gateway de VPN com o Virtual Private Gateway da Amazon Web Services (AWS) e o Google Cloud VPN para tráfego entre nuvens.

  • Last updated on