Grupos de segurança de rede e grupos de segurança de aplicações

Este artigo explica como controlar o tráfego de rede em redes virtuais do Azure utilizando grupos de segurança de rede (NSGs) para filtragem de tráfego. Abrange também grupos de segurança de aplicações (ASGs) para agrupamento lógico de interfaces de rede.

O que este artigo aborda

Os grupos de segurança de rede permitem-lhe filtrar o tráfego de entrada e saída para obter recursos numa rede virtual Azure. Os grupos de segurança de aplicações permitem agrupar interfaces de rede por função. Escreva regras NSG que referenciam grupos lógicos em vez de endereços IP individuais.

Quem precisa deste artigo

Leia este artigo se:

  • Implemente qualquer recurso que se ligue a uma rede virtual do Azure.
  • É necessário controlar o tráfego que flui entre sub-redes, máquinas virtuais ou serviços do Azure.
  • Quero simplificar a gestão de regras para ambientes onde VMs escalam frequentemente ou onde os endereços IP mudam.
  • Estão a construir uma linha base de segurança para uma nova carga de trabalho no Azure.

Foco em levantar e deslocar: Recrie o firewall local e as regras de segmentação como NSGs entre sub-redes, espelhando os fluxos de nível a nível que as suas aplicações já utilizam.

Modernizar o foco: Usar grupos de segurança de aplicações para expressar regras por função de carga de trabalho em vez de endereço IP, e emparelhar NSGs de sub-redes com um firewall hub e rotas definidas pelo utilizador que forçam a inspeção da saída.

Foco multicloud: Espelhe as regras dos grupos de segurança da AWS e do Google Cloud nos grupos de segurança de rede (NSG) do Azure para que a política de tráfego se mantenha consistente à medida que as cargas de trabalho se movem entre nuvens.

Serviços e funcionalidades do Azure

A tabela seguinte descreve os serviços e funcionalidades usados para a filtragem de tráfego de rede nas redes virtuais do Azure.

Serviço ou funcionalidade O que oferece Quando usar
Grupo de segurança de rede (NSG) Um conjunto de regras de segurança de entrada e saída aplicava-se a uma sub-rede ou interface de rede. As regras são avaliadas por prioridade: o menor número vence. Controla o tráfego ao nível da sub-rede ou da VM individual. Candidate-se a todas as cargas de trabalho que utilizam uma rede virtual.
Grupo de segurança de aplicações (ASG) Um agrupamento lógico de interfaces de rede. Use ASGs como origem ou destino nas regras NSG em vez de endereços IP. Tens várias VMs que desempenham a mesma função (servidores web, servidores de aplicações) e os seus endereços IP mudam com a escalabilidade. Todas as NICs agrupadas devem estar na mesma rede virtual.
Etiquetas de serviço Grupos nomeados de prefixos de endereços IP para serviços do Azure, geridos e atualizados automaticamente pela Microsoft. Exemplos: AzureCloud, Storage, AzureLoadBalancer, Sql. Referenciar serviços Azure nas regras NSG sem codificar fixamente os intervalos de IP. A Microsoft atualiza automaticamente os intervalos de IP subjacentes. Não podes criar etiquetas de serviço personalizadas.

Etiquetas de serviço comuns

A tabela seguinte lista as etiquetas de serviço mais frequentemente usadas nas regras NSG.

Etiqueta de serviço Description
Internet Todo o espaço de endereços IP públicos fora da sua rede virtual. Corresponde a qualquer tráfego com origem na Internet pública ou com destino à mesma.
VirtualNetwork O seu espaço de endereçamento de rede virtual, todos os espaços de endereçamento ligados (VNets emparelhadas), as redes no local ligadas por VPN/ExpressRoute e quaisquer pontos finais de serviço. Inclui rotas padrão.
AzureLoadBalancer Balanceador de carga de infraestrutura Azure. Traduz-se para o IP virtual do host onde se originam as sondas de saúde do Azure. Usado nas regras de entrada para permitir o tráfego de sondas de saúde.
Storage Espaço de endereços IP do serviço Armazenamento do Azure. Suporta variantes regionais como Storage.WestUS2. Use para permitir ou restringir o acesso ao Armazenamento do Azure a partir do VNet.
AzureCloud Todos os endereços IP públicos dos centros de dados Azure. Suporta variantes regionais como AzureCloud.EastUS. Útil para permitir tráfego de saída para serviços do Azure em geral.
Sql Base de Dados SQL do Azure, Base de Dados do Azure para MySQL, Base de Dados do Azure para PostgreSQL, Azure Database for MariaDB e Azure Synapse Analytics, prefixos de endereços IP. Suporta variantes regionais.
Regras de segurança aumentadas Regras NSG estendidas que aceitam múltiplos endereços IP, intervalos de IP e portas numa única regra. Reduza o número de regras quando for necessário permitir ou negar tráfego para muitos IPs ou intervalos de portas. Suporta múltiplos IPs e intervalos de portas por regra, e até 10 grupos de segurança de aplicação, mas apenas uma etiqueta de serviço por regra.

Como escolher

Use as seguintes orientações para selecionar a estrutura de segurança certa para o seu caso.

Limites e quotas do NSG

O Azure aplica os seguintes limites padrão sobre recursos NSG. Para aumentar a maioria dos limites, solicite um aumento através do suporte do Azure.

Resource Limite predefinido Limite máximo
Regras por NSG 2,000 2,000
NSGs por subscrição 5,000 5,000
NSGs por sub-rede 1 1
NSGs por NIC 1 1
ASGs por subscrição 3,000 3,000
NIC por ASG Varia consoante a subscrição Contacte o suporte
ASGs referenciados como origem ou destino em cada regra 10 10

Note

O limite de 2.000 regras para cada NSG inclui tanto regras personalizadas como regras padrão. Se se aproximar deste limite, use regras de segurança aumentadas para combinar múltiplos IPs ou intervalos de portas em menos regras.

NSG versus ASG: quando usar

Use a tabela seguinte para determinar a estrutura de segurança que se adequa ao seu cenário.

Scenario Use Porquê
Controla o tráfego para todas as VMs numa sub-rede NSG ao nível da sub-rede Um NSG aplica-se a todos os recursos na sub-rede. A forma mais simples de gerir políticas uniformes.
Controla o tráfego para uma VM específica independentemente da sua sub-rede NSG no nível da NIC Permite exceções sem afetar outras VMs. Útil para jump boxes ou bastiões hosts.
Muitas VMs desempenham o mesmo papel e os endereços IP mudam frequentemente ASG Adiciona VMs a um grupo por função (web, app, dados). Escreva regras contra o nome do grupo. Não são necessárias atualizações quando as VMs escalam ou recebem novos IPs.
Referência aos serviços Azure (Storage, SQL, Key Vault) como origem ou destino NSG com etiquetas de serviço Evite codificar de forma fixa intervalos de IP que a Microsoft possa atualizar. As etiquetas de serviço mantêm-se atualizadas automaticamente.

O diagrama seguinte 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 aplicações por função, com regras NSG que permitem a porta 443 da web para a aplicação e a porta 1433 da aplicação para os servidores de dados.

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

Valide a sua configuração NSG com esta lista de verificação antes de implementar para produção.

Requisito Action Reference
Postura de negação por omissão Confirme que se baseia na regra padrão DenyAllInbound (prioridade 65500). Não crie regras gerais que permitam tudo e que ignorem a política de negação por omissão. Considerações de segurança
Sem acesso à internet nas portas de administrador Bloquear o tráfego de entrada proveniente de 0.0.0.0/0 nas portas SSH (22) e RDP (3389). Use o Azure Bastion ou uma VPN para acesso administrativo. Considerações de segurança
Combine com o Azure Firewall para uma inspeção aprofundada Os NSGs filtram apenas na camada 3/4. Adicione o Azure Firewall para filtragem na camada de aplicação (camada 7), inspeção TLS e inteligência de ameaças. Azure Firewall e segmentação de rede
Ativar registos de fluxo para diagnósticos Utilize registos de fluxo VNet para recolher dados de tráfego para investigação de segurança e conformidade. Monitorização e diagnóstico de rede

Ordem de avaliação das regras

As regras da NSG usam a semântica da primeira vitória no jogo:

  1. O Azure avalia as regras por ordem de prioridade: primeiro o número mais baixo (prioridade mais alta).
  2. O Azure avalia cada regra em função de cinco tuplas: fonte, porta de origem, destino, porta de destino e protocolo.
  3. Quando o tráfego corresponde a uma regra, o processamento é interrompido. O Azure não avalia regras adicionais.
  4. Se nenhuma regra personalizada corresponder, aplicam-se as regras padrão. Não podes eliminar regras padrão, mas podes sobrepê-las criando regras personalizadas com prioridade entre 100 e 4096.

Regras padrão (seis no total):

Direction Nome da regra Prioridade Action
Inbound AllowVNetInBound 65000 Allow
Inbound AllowAzureLoadBalancerInBound 65001 Allow
Inbound DenyAllInbound 65500 Deny
Outbound AllowVnetOutBound 65000 Allow
Outbound PermitirSaídaParaInternet 65001 Allow
Outbound DenyAllOutBound 65500 Deny

Restrições ASG

Ao utilizar grupos de segurança de aplicações, esteja ciente das seguintes restrições:

  • Todas as interfaces de rede num ASG devem existir na mesma rede virtual da primeira interface de rede atribuída ao ASG.
  • Se referenciar ASGs tanto na origem como no destino de uma regra, as interfaces de rede em ambos os grupos devem estar na mesma rede virtual.
  • Pode referenciar até 10 ASGs na origem ou destino de uma regra.

NSGs ao nível de subrede e de interface de rede em conjunto

Pode associar um NSG tanto a uma sub-rede como a uma interface de rede numa VM dentro dessa subrede. Quando o fazes, o Azure avalia ambos os NSGs e o tráfego tem de passar por ambos. A combinação mais restritiva vence.

Direction Avaliado pela primeira vez Segunda avaliação
Inbound NSG da sub-rede NIC NSG
Outbound NIC NSG NSG da sub-rede

Dica

Para uma resolução de problemas mais simples, associe um NSG à sub-rede ou à interface de rede, mas não a ambos. Se precisar de ambos, documente claramente a interação pretendida entre as regras.

Exemplo prático: camada web com um servidor de salto

Considere uma sub-rede com um NSG ao nível da sub-rede que permite tráfego HTTPS de entrada (porta 443) proveniente da Internet e nega tudo o resto. Uma VM jump box nessa sub-rede tem um NSG ao nível da interface de rede que também permite SSH de entrada (porta 22) a partir de uma faixa específica de IP de gestão.

  • Tráfego da Web (porta 443): O NSG da sub-rede permite esse tráfego. O NSG da interface de rede nas VMs Web não tem nenhuma regra de bloqueio para 443 (por predefinição, AllowVNetInBound permite). O trânsito flui.
  • SSH para a jump box (porta 22 do IP de gestão): A sub-rede NSG nega o tráfego na porta 22 proveniente da internet. Apesar de a interface de rede NSG permitir SSH a partir do intervalo de gestão, a sub-rede NSG bloqueia-a primeiro. Resolução: Adicionar uma regra no NSG da sub-rede para permitir a porta 22 a partir do intervalo de IP de gestão, ou usar o Azure Bastion para contornar completamente o caminho público da internet.

Este exemplo ilustra porque é que os NSGs duplos acrescentam complexidade. Ambos devem permitir o tráfego de forma independente.

O diagrama seguinte mostra o caminho de avaliação do tráfego de entrada quando se associa tanto um NSG de sub-rede como um NSG de NIC. O tráfego deve passar por ambos os NSGs. A combinação mais restritiva vence.

Diagrama mostrando o fluxograma de avaliação das regras NSG para tráfego de entrada através dos níveis de sub-rede e NIC para permitir ou negar

Interação com Azure Virtual Network Manager

Se a sua organização utiliza as regras de administração de segurança do Azure Virtual Network Manager (AVNM), o Azure avalia essas regras antes das regras NSG. As regras de administrador de segurança podem Permitir (prosseguir para a avaliação da NSG), Permitir sempre (ignorar a NSG) ou Negar (bloquear antes da avaliação da NSG). Para gestão centralizada de segurança de rede, veja Azure Virtual Network Manager e gestão centralizada.

Considerações de design

Foco da conceção de NSG e ASG para lift-and-shift

  • Traduza a sua segmentação no local em NSGs ao nível da sub-rede: permita apenas os fluxos entre camadas que a sua aplicação já utiliza (por exemplo, da Web para a aplicação e da aplicação para a base de dados) e negue tudo o resto.
  • Comece pelo conjunto atual de regras da firewall e torne-o mais restritivo após a migração, usando registos de fluxos da NSG para confirmar de quais realmente necessita.
  • Aplicar os NSGs primeiro ao nível da sub-rede para simplificar; adicionar regras ao nível da NIC apenas onde as VMs individuais precisam de exceções.
  • Use etiquetas de serviço (como VirtualNetwork e AzureLoadBalancer) em vez de endereços IP codificados fixamente para que as regras sobrevivam ao reendereçamento durante a migração.

Modernizar a orientação do design do NSG e do ASG

  • Use grupos de segurança de aplicações para agrupar interfaces de rede por função (web, app, dados) para que as regras descrevam a intenção e se adaptem automaticamente à medida que as instâncias escalam.
  • Combinar NSGs de sub-redes com um hub Azure Firewall: Os NSGs tratam da microsegmentação entre níveis, enquanto o firewall inspeciona o tráfego que ultrapassa limites de confiança.
  • Permitir apenas que a sub-rede privada do endpoint aceda aos serviços PaaS e forçar o tráfego de saída através do firewall do hub com rotas definidas pelo utilizador.
  • Se utilizar as regras de administrador de segurança do Azure Virtual Network Manager, planeie a sua precedência (são avaliadas antes dos NSGs) para que os mecanismos de proteção da plataforma não entrem em conflito com os NSGs das cargas de trabalho.

Foco da conceção multicloud de NSG e ASG

  • Espelhe as regras de grupos de segurança da AWS e 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 aplicações cross-cloud, e encaminhar esse tráfego através de túneis IPsec inspecionados.
  • Padronize os nomes dos grupos de segurança de aplicações entre as clouds para que as equipas de operações possam correlacionar cargas de trabalho equivalentes ao resolverem problemas.
  • Associe os NSGs a um firewall seguro do hub da WAN Virtual, para que o tráfego entre clouds e de filiais seja simultaneamente filtrado pelos NSGs e inspecionado pelo firewall.

Pré-requisitos

Antes de implementar NSGs e ASGs, certifique-se de que tem:

  • Uma rede virtual com sub-redes: Os NSGs ligam-se a sub-redes ou NICs dentro de uma rede virtual. Consulte Redes virtuais e sub-redes para orientações de planeamento.
  • Um plano de endereçamento IP: As regras NSG referem-se a endereços e intervalos IP. Um plano de propriedade intelectual garante que pode escrever regras precisas. Consulte planeamento de endereços IP para orientações.
  • Uma lista dos fluxos de tráfego obrigatórios: Documente quais os recursos que precisam de comunicar, em que portas e em que direção antes de escrever regras.

Considerações de segurança

Importante

Negar por predefinição é a abordagem correta. As regras padrão de entrada no Azure negam todo o tráfego de internet que não é explicitamente permitido. Não enfraqueça esta posição ao criar regras de permissão demasiado abrangentes.

Nunca permitir 0.0.0.0/0 nas portas administrativas

Atenção

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 atacantes verificam continuamente a internet à procura de portas de administrador abertas. Em vez disso, use Azure Bastion, uma VPN ou Azure Private Link para aceder a máquinas virtuais de forma segura.

Combinar NSGs com Azure Firewall

Os NSGs operam na camada 3 e camada 4 (rede e transporte). Filtram com base em endereços IP, portas e protocolos, mas não inspecionam o conteúdo dos pacotes. Para cargas de trabalho que requerem filtragem à camada de aplicação, inteligência de ameaças ou inspeção TLS, implemente o Azure Firewall juntamente com os NSGs. Veja Azure Firewall e segmentação de rede.

Use os registos de fluxo VNet para visibilidade do tráfego

Note

Os registos de fluxo do NSG estão agendados para serem retirados a 30 de setembro de 2027. Não podem ser criados novos registos de fluxo NSG após 30 de junho de 2025. Migre para os registos de fluxo VNet, que fornecem as mesmas capacidades e análise de tráfego ao nível da rede virtual.

Os registos de fluxo VNet capturam dados de estado por fluxo e de rendimento para todas as cargas de trabalho numa rede virtual. Use-os para:

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

Para configuração de monitorização e diagnóstico, consulte Monitorização e diagnóstico de rede.

Erros comuns a evitar

Erro Porque é que é um problema Abordagem melhor
Criação de regras de entrada que permitem tudo (prioridade 100, origem *, destino *) Ignora a postura de negação por defeito e expõe todos os recursos ao tráfego da internet. Permita apenas combinações específicas de origem/destino/porta. Usa os números de prioridade mais elevados possíveis para as regras de autorização.
Esquecer-se de que existe a negação por omissão As equipas criam regras de permissão para tráfego conhecido, mas não testam se tudo o resto está bloqueado. Portas abertas não intencionais podem passar despercebidas. Após implementar os NSGs, verifique, através dos registos de fluxos da VNet ou dos diagnósticos do NSG, que apenas circula o tráfego esperado. Teste explicitamente caminhos com acesso negado.
Não usar ASGs para cargas de trabalho dinâmicas As regras baseadas em IP quebram-se quando as VMs expandem ou ganham novos IPs. As equipas acabam por atualizar regras constantemente. Agrupar VMs por função usando ASGs. As regras que referenciam ASGs mantêm-se válidas à medida que VMs são adicionadas ou removidas do grupo.
Ignorar registos de fluxo até um incidente de segurança Sem os registos de fluxo ativados, não tem dados históricos de tráfego para investigação ou auditorias de conformidade. Ativa os registos de fluxo do VNet desde o primeiro dia. Configure o Traffic Analytics para visualização e alerta sobre anomalias.
Aplicar NSGs da sub-rede e da NIC em simultâneo sem documentação Os NSGs duplos criam interações confusas onde o tráfego é negado inesperadamente. A resolução de problemas torna-se demorada. Escolha NSGs ao nível de subrede ou NIC como padrão. Se ambos forem necessários, documente a interação pretendida para cada sub-rede.

Saiba mais

Passos seguintes

Dica

Explorar sozinho? Volte ao navegador de visão geral para encontrar o seu próximo artigo por capacidade.

A seguir na sua jornada de levantar e deslocar:

Desenhe a sua topologia hub-and-spoke: Centralize serviços partilhados como DNS, firewall e Gateway de VPN entre as suas cargas de trabalho migradas.

Próximo passo na sua jornada de modernização:

Conceba a sua topologia hub-and-spoke: Configure uma topologia de dois hubs com hubs geridos pela TI e spokes geridos pela equipa de aplicações para as suas cargas de trabalho PaaS.

A seguir na sua jornada através da cloud:

Configure túneis encriptados para as suas outras nuvens: Configure ligações do Gateway de VPN ao Amazon Web Services (AWS) Virtual Private Gateway e ao Google Cloud VPN para trânsito entre nuvens.