Fundamentação Teórica: Create and Configure Network Security Groups (NSGs) and Application Security Groups

1. Intuição Inicial

Imagine o prédio de um escritório moderno. Na entrada principal, existe um segurança que verifica quem pode entrar e quem pode sair, com uma lista de regras: "visitantes só entram pelo lobby", "fornecedores só podem ir ao depósito", "funcionários do financeiro não acessam o servidor de TI". Cada andar pode ter suas próprias regras adicionais.

Um Network Security Group (NSG) é exatamente esse segurança: um conjunto de regras que controla qual tráfego de rede pode entrar e sair de recursos no Azure. Cada regra define: de onde vem o tráfego, para onde vai, qual protocolo e porta, e se é permitido ou bloqueado.

Um Application Security Group (ASG) é uma extensão elegante desse conceito: em vez de escrever regras baseadas em endereços IP individuais, você agrupa VMs por função (como "servidores web", "servidores de banco de dados") e escreve regras usando esses grupos. Quando uma nova VM entra no grupo, ela herda automaticamente todas as regras associadas ao grupo.

2. Contexto

2.1 NSGs e ASGs no ecossistema Azure

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

2.2 Por que NSGs e ASGs existem

Antes dos NSGs, controlar tráfego de rede em nuvem era feito apenas com firewalls tradicionais em appliances dedicados. NSGs democratizaram o controle de rede ao torná-lo declarativo, gratuito (sem custo adicional além da infraestrutura) e gerenciável como código.

ASGs surgiram para resolver o problema de escala: em ambientes com centenas de VMs, manter regras baseadas em IPs individuais era inviável. Um ASG desacopla a identidade de segurança (o grupo) do endereçamento IP.

2.3 O que depende de NSGs

Acesso SSH/RDP a VMs: Controlado por regra inbound de NSG
Comunicação entre tiers (web, app, banco): Controlada por regras entre NSGs/ASGs
Azure Bastion: Requer regras específicas no NSG da subnet do Bastion
Load Balancer probes: Requer permissão explícita do IP 168.63.129.16
Service Endpoints: Trabalham em conjunto com regras de NSG

3. Construção dos Conceitos

3.1 Anatomia de uma regra de NSG

Cada regra de NSG tem cinco atributos obrigatórios e um resultado:

Atributo	Descrição	Exemplo
Priority	Número de 100 a 4096; menor número = maior prioridade	100
Name	Identificador único da regra no NSG	Allow-HTTP-Inbound
Protocol	TCP, UDP, ICMP ou * (qualquer)	TCP
Source	IP, CIDR, Service Tag, ou ASG de onde vem o tráfego	Internet
Destination	IP, CIDR, Service Tag, ou ASG de destino	10.0.1.0/24
Source Port Range	Porta de origem (geralmente *)	*
Destination Port Range	Porta de destino	80, 443, 3389-3400
Action	Allow ou Deny	Allow
Direction	Inbound ou Outbound	Inbound

Por que Source Port Range geralmente é *? Conexões TCP iniciam com uma porta de origem efêmera (escolhida pelo sistema operacional, geralmente acima de 1024). Você raramente conhece essa porta de antemão, por isso usa * na origem e especifica apenas a porta de destino.

3.2 Regras padrão (default rules)

Todo NSG é criado com um conjunto de regras padrão que não podem ser deletadas, apenas sobrescritas por regras de maior prioridade:

Regras Inbound padrão:

Priority	Name	Source	Destination	Port	Action
65000	AllowVnetInBound	VirtualNetwork	VirtualNetwork	*	Allow
65001	AllowAzureLoadBalancerInBound	AzureLoadBalancer	*	*	Allow
65500	DenyAllInBound	*	*	*	Deny

Regras Outbound padrão:

Priority	Name	Source	Destination	Port	Action
65000	AllowVnetOutBound	VirtualNetwork	VirtualNetwork	*	Allow
65001	AllowInternetOutBound	*	Internet	*	Allow
65500	DenyAllOutBound	*	*	*	Deny

Comportamento não óbvio: Por padrão, todo tráfego entre VMs na mesma VNet é permitido (AllowVnetInBound e AllowVnetOutBound). E todo tráfego saindo para a internet também é permitido. Para ambientes seguros, você precisa adicionar regras de Deny explícitas com prioridade menor que 65000 para sobrescrever esses padrões.

3.3 Service Tags: simplificando regras de IP

Service Tags são rótulos que representam conjuntos de prefixos de IP de serviços Azure. Em vez de manter listas de IPs que mudam, você usa o service tag e a Microsoft mantém a lista atualizada automaticamente.

Tags mais usadas em NSGs:

Service Tag	Representa
`Internet`	Todo tráfego da/para internet pública
`VirtualNetwork`	Toda a VNet e VNets pareadas
`AzureLoadBalancer`	IPs de probe do Azure Load Balancer
`AzureCloud`	Todos os IPs públicos do Azure
`Storage`	IPs do Azure Storage (todos os endpoints)
`Sql`	IPs dos servidores Azure SQL
`AppService`	IPs do Azure App Service
`AzureActiveDirectory`	IPs dos endpoints do Azure AD
`GatewayManager`	IPs do gerenciamento de VPN/ExpressRoute Gateways

3.4 Application Security Groups (ASGs)

Um ASG é um objeto Azure que agrupa NICs (interfaces de rede) de VMs. Você então referencia esses grupos nas regras de NSG em vez de IPs individuais.

Analogia: Um ASG é como um "cargo" numa empresa. Em vez de escrever uma regra dizendo "João, Maria e Pedro podem acessar o servidor financeiro", você diz "funcionários do cargo 'Analista Financeiro' podem acessar". Quando um novo analista é contratado, basta colocá-lo no grupo e ele automaticamente ganha acesso.

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

3.5 Restrições dos ASGs

Para usar ASGs, há restrições importantes:

Uma NIC pode ser associada a múltiplos ASGs
Todos os ASGs referenciados em uma regra devem estar na mesma VNet
Todos os ASGs usados como source e destination numa regra devem estar na mesma VNet
Você não pode combinar ASG com endereço IP na mesma regra (source ou destination precisa ser um tipo só: ASG, IP/CIDR, ou Service Tag)

4. Visão Estrutural

4.1 Fluxo de avaliação de tráfego (dupla verificação)

Quando tráfego chega a uma VM, o Azure avalia dois NSGs em sequência, na ordem correta:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Para tráfego Outbound, a ordem se inverte: NSG da NIC é avaliado primeiro, depois NSG da Subnet.

Regra fundamental: Para que tráfego passe, ambos os NSGs precisam permitir. Se qualquer um bloquear, o tráfego é negado.

4.2 Onde NSGs podem ser associados

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Melhor prática: Associe NSGs às subnets, não às NICs individuais. Isso é mais simples de gerenciar. Use NSG em NIC apenas para exceções específicas que a subnet NSG não deve cobrir.

5. Funcionamento na Prática

5.1 Cenário completo: arquitetura de três camadas

Considere uma aplicação com três tiers: Web, App e Database.

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Neste modelo:

NSG-Web é associado à subnet Web e permite apenas HTTP/HTTPS da internet
NSG-App permite apenas tráfego na porta 8080 proveniente do ASG-WebServers
NSG-DB permite apenas SQL (porta 1433) proveniente do ASG-AppServers
Movimento lateral entre tiers é bloqueado por padrão

5.2 Effective Security Rules: diagnóstico de regras efetivas

Uma funcionalidade poderosa do Azure é a capacidade de ver as regras efetivas combinadas de NSGs em uma NIC específica:

No portal: NIC da VM > Effective Security Rules

Isso mostra as regras de todos os NSGs associados (subnet + NIC) em uma visão consolidada, na ordem de avaliação. É a ferramenta principal para diagnosticar por que um tráfego está sendo bloqueado ou permitido.

5.3 Network Watcher: IP Flow Verify

Para diagnosticar conectividade de forma mais direta:

Azure Network Watcher > IP Flow Verify

Você especifica:

VM de origem
Endereço IP de destino
Porta e protocolo
Direção (inbound/outbound)

O Azure simula o fluxo e informa se seria permitido ou negado, e qual regra específica seria responsável pela decisão.

6. Formas de Implementação

6.1 Portal Azure

Quando usar: Criação inicial, visualização de regras efetivas, troubleshooting visual.

Criar NSG: Resource Groups > + Create > Network Security Group

Após criar, adicione regras em Settings > Inbound security rules ou Outbound security rules.

Associar a subnet: Virtual Network > Subnets > [subnet] > Network security group

Limitação: Não escalável para múltiplos NSGs ou regras complexas.

6.2 Azure CLI

Criando NSG:

az network nsg create \
  --name NSG-Web \
  --resource-group myRG \
  --location eastus

Adicionando regra inbound:

# Permitir HTTP e HTTPS da internet
az network nsg rule create \
  --nsg-name NSG-Web \
  --resource-group myRG \
  --name Allow-HTTP-HTTPS \
  --priority 100 \
  --protocol Tcp \
  --direction Inbound \
  --source-address-prefixes Internet \
  --source-port-ranges '*' \
  --destination-address-prefixes '*' \
  --destination-port-ranges 80 443 \
  --access Allow

# Negar todo o restante inbound (explícito)
az network nsg rule create \
  --nsg-name NSG-Web \
  --resource-group myRG \
  --name Deny-All-Inbound \
  --priority 4000 \
  --protocol '*' \
  --direction Inbound \
  --source-address-prefixes '*' \
  --source-port-ranges '*' \
  --destination-address-prefixes '*' \
  --destination-port-ranges '*' \
  --access Deny

Associando NSG a uma subnet:

az network vnet subnet update \
  --vnet-name myVNet \
  --name WebSubnet \
  --resource-group myRG \
  --network-security-group NSG-Web

Criando ASG:

az network asg create \
  --name ASG-WebServers \
  --resource-group myRG \
  --location eastus

Associando NIC de VM a um ASG:

az network nic update \
  --name myVM-NIC \
  --resource-group myRG \
  --application-security-groups ASG-WebServers

Criando regra NSG com ASG como source e destination:

az network nsg rule create \
  --nsg-name NSG-DB \
  --resource-group myRG \
  --name Allow-SQL-from-AppServers \
  --priority 100 \
  --protocol Tcp \
  --direction Inbound \
  --source-asgs ASG-AppServers \
  --source-port-ranges '*' \
  --destination-asgs ASG-DatabaseServers \
  --destination-port-ranges 1433 \
  --access Allow

Verificando regras efetivas:

az network nic show-effective-nsg \
  --name myVM-NIC \
  --resource-group myRG \
  --output table

6.3 Azure PowerShell

# Criar NSG
$nsg = New-AzNetworkSecurityGroup `
  -Name "NSG-Web" `
  -ResourceGroupName "myRG" `
  -Location "eastus"

# Criar regra e adicionar ao NSG
$rule = New-AzNetworkSecurityRuleConfig `
  -Name "Allow-HTTP-HTTPS" `
  -Protocol Tcp `
  -Direction Inbound `
  -Priority 100 `
  -SourceAddressPrefix Internet `
  -SourcePortRange '*' `
  -DestinationAddressPrefix '*' `
  -DestinationPortRange 80, 443 `
  -Access Allow

$nsg.SecurityRules.Add($rule)
Set-AzNetworkSecurityGroup -NetworkSecurityGroup $nsg

# Criar ASG
$asg = New-AzApplicationSecurityGroup `
  -Name "ASG-WebServers" `
  -ResourceGroupName "myRG" `
  -Location "eastus"

# Associar NIC a ASG
$nic = Get-AzNetworkInterface `
  -Name "myVM-NIC" `
  -ResourceGroupName "myRG"

$nic.IpConfigurations[0].ApplicationSecurityGroups = @($asg)
Set-AzNetworkInterface -NetworkInterface $nic

6.4 Bicep

// Application Security Groups
resource asgWeb 'Microsoft.Network/applicationSecurityGroups@2023-05-01' = {
  name: 'ASG-WebServers'
  location: location
}

resource asgApp 'Microsoft.Network/applicationSecurityGroups@2023-05-01' = {
  name: 'ASG-AppServers'
  location: location
}

resource asgDb 'Microsoft.Network/applicationSecurityGroups@2023-05-01' = {
  name: 'ASG-DatabaseServers'
  location: location
}

// NSG para camada Web
resource nsgWeb 'Microsoft.Network/networkSecurityGroups@2023-05-01' = {
  name: 'NSG-Web'
  location: location
  properties: {
    securityRules: [
      {
        name: 'Allow-HTTP-HTTPS'
        properties: {
          priority: 100
          protocol: 'Tcp'
          access: 'Allow'
          direction: 'Inbound'
          sourceAddressPrefix: 'Internet'
          sourcePortRange: '*'
          destinationAddressPrefix: '*'
          destinationPortRanges: ['80', '443']
        }
      }
    ]
  }
}

// NSG para camada Database com regra usando ASG
resource nsgDb 'Microsoft.Network/networkSecurityGroups@2023-05-01' = {
  name: 'NSG-DB'
  location: location
  properties: {
    securityRules: [
      {
        name: 'Allow-SQL-from-App'
        properties: {
          priority: 100
          protocol: 'Tcp'
          access: 'Allow'
          direction: 'Inbound'
          sourceApplicationSecurityGroups: [{ id: asgApp.id }]
          sourcePortRange: '*'
          destinationApplicationSecurityGroups: [{ id: asgDb.id }]
          destinationPortRange: '1433'
        }
      }
      {
        name: 'Deny-All-Inbound'
        properties: {
          priority: 4000
          protocol: '*'
          access: 'Deny'
          direction: 'Inbound'
          sourceAddressPrefix: '*'
          sourcePortRange: '*'
          destinationAddressPrefix: '*'
          destinationPortRange: '*'
        }
      }
    ]
  }
}

7. Controle e Segurança

7.1 Permissões para gerenciar NSGs e ASGs

Operação	Role mínima
Criar/editar NSG e regras	Network Contributor
Associar NSG a subnet	Network Contributor na VNet e no NSG
Criar/editar ASG	Network Contributor
Associar NIC a ASG	Network Contributor na NIC e no ASG
Visualizar regras efetivas	Reader + Network Contributor

7.2 Regras para Azure Load Balancer

Um erro comum em ambientes com Load Balancer é bloquear as probes de saúde. O Load Balancer usa o IP 168.63.129.16 para verificar se as VMs estão saudáveis. Se o NSG bloquear esse IP, o LB marca as VMs como unhealthy e para de enviar tráfego para elas.

A regra padrão AllowAzureLoadBalancerInBound (priority 65001) permite isso, mas se você tiver uma regra Deny All com prioridade menor que 65001, ela sobrescreve a padrão.

Sempre inclua explicitamente:

az network nsg rule create \
  --nsg-name NSG-Web \
  --resource-group myRG \
  --name Allow-LB-HealthProbe \
  --priority 150 \
  --protocol '*' \
  --direction Inbound \
  --source-address-prefixes AzureLoadBalancer \
  --source-port-ranges '*' \
  --destination-address-prefixes '*' \
  --destination-port-ranges '*' \
  --access Allow

7.3 NSG Flow Logs

NSG Flow Logs registram informações sobre tráfego IP que passou ou foi bloqueado pelos NSGs. São fundamentais para auditoria, forensics e troubleshooting.

# Habilitar flow logs (requer Network Watcher e Storage Account)
az network watcher flow-log create \
  --location eastus \
  --name FlowLog-NSG-Web \
  --nsg NSG-Web \
  --resource-group myRG \
  --storage-account mystorageaccount \
  --enabled true \
  --retention 7 \
  --traffic-analytics true \
  --workspace <log-analytics-workspace-id>

Com Traffic Analytics habilitado, você pode visualizar padrões de tráfego, top talkers e flows bloqueados em um dashboard rico no Azure Monitor.

8. Tomada de Decisão

8.1 NSG em Subnet vs NSG em NIC

Situação	Melhor escolha	Motivo
Regras que se aplicam a todas as VMs de um tier	NSG na subnet	Uma única regra cobre todas as VMs
Exceção para uma VM específica dentro da subnet	NSG adicional na NIC	Não afeta outras VMs da subnet
Ambiente simples com poucas VMs	NSG na subnet	Menor complexidade operacional
VM que precisa de regras mais restritivas que a subnet	NSG na NIC em adição à subnet	Dupla verificação mais restritiva
Microsegmentação por workload	ASGs + NSG na subnet	Regras baseadas em função, não em IP

8.2 IP/CIDR vs Service Tag vs ASG

Situação	Use	Motivo
Tráfego de/para internet	Service Tag `Internet`	Cobre todos os IPs da internet
Comunicação entre tiers de aplicação	ASG	Regras baseadas em função, escala sem mudança
Tráfego de/para serviços Azure específicos	Service Tag (ex: `Storage`, `Sql`)	Microsoft mantém os IPs atualizados
IP específico de parceiro/cliente	IP/CIDR	Endereço fixo e específico
Grupo de VMs com mesmo propósito	ASG	Mais fácil de manter que lista de IPs

8.3 Quando usar ASGs obrigatoriamente

ASGs são especialmente necessários quando:

O número de VMs no grupo varia frequentemente (scale sets, deployments automáticos)
IPs das VMs são atribuídos dinamicamente (sem IPs estáticos)
A mesma VM precisa pertencer a múltiplos grupos de segurança
Você quer que regras de segurança sejam definidas pelo time de segurança independentemente do time de infra que gerencia IPs

9. Boas Práticas

Associe NSGs a subnets, não a NICs, para simplificar o gerenciamento. Use NSGs em NIC apenas para exceções específicas.
Sempre inclua uma regra Deny All explícita com prioridade alta (ex: 4000) em vez de depender apenas da regra padrão 65500. Isso deixa sua intenção clara e auditável.
Use Service Tags para tráfego Azure-to-Azure em vez de manter listas de IPs que mudam.
Use ASGs para microsegmentação em vez de IPs quando os recursos são dinâmicos ou mudam frequentemente.
Habilite NSG Flow Logs em todos os NSGs de produção para auditoria e troubleshooting.
Não bloqueie AzureLoadBalancer se houver Load Balancer na arquitetura.
Numere prioridades com intervalos (100, 200, 300) para permitir inserção de novas regras sem reorganização.
Nomeie regras descritivamente: Allow-HTTPS-from-Internet, Deny-SSH-from-All, Allow-SQL-from-AppTier.
Use tags de recursos em NSGs para identificar proprietário, ambiente e workload relacionado.
Revise periodicamente regras desnecessárias usando Network Watcher e Traffic Analytics para identificar regras nunca utilizadas.

10. Erros Comuns

Erro	Por que acontece	Como evitar
VMs fora de saúde no Load Balancer	Regra Deny All com prioridade menor que 65001 bloqueia probes do LB	Sempre incluir Allow AzureLoadBalancer com prioridade menor que o Deny All
SSH/RDP bloqueado inesperadamente	Regra Deny All sobrescreve Allow da subnet	Verificar a ordem de prioridades; usar IP Flow Verify
ASG não funciona entre VNets diferentes	ASGs devem estar na mesma VNet	Usar IPs/CIDRs para comunicação cross-VNet
Tráfego permitido indesejado por padrão	AllowVnetInBound permite todo tráfego intra-VNet	Adicionar regras Deny explícitas para microsegmentação
Regra com dois tipos de source	NSG não aceita ASG + IP na mesma regra	Separar em duas regras distintas
NIC associada a ASG de outra região	ASG e NIC devem estar na mesma região	Criar ASG na mesma região das VMs
Flow Logs não aparecem	Storage Account em região diferente do Network Watcher	Usar Storage Account na mesma região
Regra de maior prioridade (menor número) bloqueando	Esqueceu que menor número = maior prioridade	Sempre revisar a ordem de prioridades após adicionar regras

11. Operação e Manutenção

11.1 Diagnosticando conectividade

Passo 1: Use IP Flow Verify no Network Watcher para confirmar se o NSG está bloqueando.

Passo 2: Se bloqueado, use Effective Security Rules na NIC para ver qual regra específica está negando.

Passo 3: Se permitido pelo NSG mas o tráfego ainda não chega, o problema pode ser em firewall dentro da VM (Windows Firewall, iptables) ou em roteamento.

Passo 4: Use Connection Troubleshoot no Network Watcher para diagnóstico end-to-end incluindo latência e perdas de pacote.

11.2 Monitorando NSGs com Azure Monitor

# Criar alerta para mudanças em NSGs (via Activity Log)
az monitor activity-log alert create \
  --name "NSG-rule-change-alert" \
  --resource-group myRG \
  --condition category=Administrative \
  --condition operationName=Microsoft.Network/networkSecurityGroups/securityRules/write \
  --action-group myActionGroup

Configure também alertas para:

Fluxos bloqueados acima de um threshold (Traffic Analytics)
Tentativas de acesso a portas sensíveis (22, 3389) de IPs não autorizados

11.3 Limites importantes

Recurso	Limite
NSGs por subscription	5.000
Regras por NSG	1.000
NSGs por NIC	1
NSGs por subnet	1
ASGs por subscription	3.000
ASGs por NIC	20
ASGs por regra de NSG (source + destination)	10

12. Integração e Automação

12.1 Azure Policy para conformidade de NSG

# Policy built-in: Subnets sem NSG devem ser auditadas
az policy assignment create \
  --name "require-nsg-on-subnets" \
  --policy "e71308d3-144b-4262-b144-efdc3cc90517" \
  --scope "/subscriptions/<sub-id>"

Policy custom para negar criação de subnets sem NSG:

{
  "if": {
    "allOf": [
      {
        "field": "type",
        "equals": "Microsoft.Network/virtualNetworks/subnets"
      },
      {
        "field": "Microsoft.Network/virtualNetworks/subnets/networkSecurityGroup.id",
        "exists": false
      },
      {
        "not": {
          "field": "name",
          "in": ["GatewaySubnet", "AzureFirewallSubnet", "AzureBastionSubnet"]
        }
      }
    ]
  },
  "then": {
    "effect": "deny"
  }
}

Note que algumas subnets especiais (GatewaySubnet, AzureFirewallSubnet, AzureBastionSubnet) não suportam NSGs e devem ser excluídas da policy.

12.2 Terraform para NSG com ASG

resource "azurerm_application_security_group" "web" {
  name                = "ASG-WebServers"
  location            = var.location
  resource_group_name = var.resource_group
}

resource "azurerm_application_security_group" "db" {
  name                = "ASG-DatabaseServers"
  location            = var.location
  resource_group_name = var.resource_group
}

resource "azurerm_network_security_group" "db_nsg" {
  name                = "NSG-DB"
  location            = var.location
  resource_group_name = var.resource_group

  security_rule {
    name                                       = "Allow-SQL-from-Web"
    priority                                   = 100
    direction                                  = "Inbound"
    access                                     = "Allow"
    protocol                                   = "Tcp"
    source_port_range                          = "*"
    destination_port_range                     = "1433"
    source_application_security_group_ids      = [azurerm_application_security_group.web.id]
    destination_application_security_group_ids = [azurerm_application_security_group.db.id]
  }

  security_rule {
    name                       = "Deny-All-Inbound"
    priority                   = 4000
    direction                  = "Inbound"
    access                     = "Deny"
    protocol                   = "*"
    source_port_range          = "*"
    destination_port_range     = "*"
    source_address_prefix      = "*"
    destination_address_prefix = "*"
  }
}

13. Resumo Final

Conceitos essenciais:

Um NSG é uma lista de regras de segurança de rede que controla tráfego inbound e outbound de recursos Azure.
Cada regra tem prioridade, protocolo, source, destination, porta e ação (Allow/Deny). Menor número de prioridade = maior precedência.
NSGs podem ser associados a subnets (protege todas as VMs) ou a NICs (protege uma VM específica).
Quando ambos estão associados, ambos são avaliados: para inbound, subnet NSG primeiro; para outbound, NIC NSG primeiro.
Um ASG é um agrupamento lógico de NICs que pode ser usado como source ou destination em regras de NSG, eliminando a necessidade de manter listas de IPs.

Diferenças críticas:

NSG na subnet vs NSG na NIC: Subnet cobre todas as VMs; NIC cobre apenas uma. Ambos coexistem e ambos devem permitir para o tráfego passar.
Allow vs Deny: A primeira regra correspondente (por prioridade) é aplicada. As demais são ignoradas.
ASG vs Service Tag vs IP: ASG é para recursos internos Azure agrupados por função. Service Tag é para serviços Azure com IPs gerenciados pela Microsoft. IP/CIDR é para endereços externos específicos.
AllowVnetInBound padrão: Por padrão, todo tráfego entre VMs da mesma VNet é permitido. Para microsegmentação, adicione regras Deny explícitas.

O que precisa ser lembrado:

NSGs em GatewaySubnet, AzureFirewallSubnet e AzureBastionSubnet não são suportados.
Sempre inclua Allow AzureLoadBalancer antes de qualquer regra Deny All quando há Load Balancer.
ASGs devem estar na mesma VNet das NICs associadas.
Uma NIC pode pertencer a até 20 ASGs.
Use IP Flow Verify e Effective Security Rules para diagnosticar problemas de conectividade.
NSG Flow Logs são essenciais para auditoria e devem ser habilitados em produção.
Regras padrão (65000, 65001, 65500) não podem ser deletadas, apenas sobrescritas com prioridades menores.

1. Intuição Inicial​

2. Contexto​

2.1 NSGs e ASGs no ecossistema Azure​

2.2 Por que NSGs e ASGs existem​

2.3 O que depende de NSGs​

3. Construção dos Conceitos​

3.1 Anatomia de uma regra de NSG​

3.2 Regras padrão (default rules)​

3.3 Service Tags: simplificando regras de IP​

3.4 Application Security Groups (ASGs)​

3.5 Restrições dos ASGs​

4. Visão Estrutural​

4.1 Fluxo de avaliação de tráfego (dupla verificação)​

4.2 Onde NSGs podem ser associados​

5. Funcionamento na Prática​

5.1 Cenário completo: arquitetura de três camadas​

5.2 Effective Security Rules: diagnóstico de regras efetivas​

5.3 Network Watcher: IP Flow Verify​

6. Formas de Implementação​

6.1 Portal Azure​

6.2 Azure CLI​

6.3 Azure PowerShell​

6.4 Bicep​

7. Controle e Segurança​

7.1 Permissões para gerenciar NSGs e ASGs​

7.2 Regras para Azure Load Balancer​

7.3 NSG Flow Logs​

8. Tomada de Decisão​

8.1 NSG em Subnet vs NSG em NIC​

8.2 IP/CIDR vs Service Tag vs ASG​

8.3 Quando usar ASGs obrigatoriamente​

9. Boas Práticas​

10. Erros Comuns​

11. Operação e Manutenção​

11.1 Diagnosticando conectividade​

11.2 Monitorando NSGs com Azure Monitor​

11.3 Limites importantes​

12. Integração e Automação​

12.1 Azure Policy para conformidade de NSG​

12.2 Terraform para NSG com ASG​

13. Resumo Final​

1. Intuição Inicial

2. Contexto

2.1 NSGs e ASGs no ecossistema Azure

2.2 Por que NSGs e ASGs existem

2.3 O que depende de NSGs

3. Construção dos Conceitos

3.1 Anatomia de uma regra de NSG

3.2 Regras padrão (default rules)

3.3 Service Tags: simplificando regras de IP

3.4 Application Security Groups (ASGs)

3.5 Restrições dos ASGs

4. Visão Estrutural

4.1 Fluxo de avaliação de tráfego (dupla verificação)

4.2 Onde NSGs podem ser associados

5. Funcionamento na Prática

5.1 Cenário completo: arquitetura de três camadas

5.2 Effective Security Rules: diagnóstico de regras efetivas

5.3 Network Watcher: IP Flow Verify

6. Formas de Implementação

6.1 Portal Azure

6.2 Azure CLI

6.3 Azure PowerShell

6.4 Bicep

7. Controle e Segurança

7.1 Permissões para gerenciar NSGs e ASGs

7.2 Regras para Azure Load Balancer

7.3 NSG Flow Logs

8. Tomada de Decisão

8.1 NSG em Subnet vs NSG em NIC

8.2 IP/CIDR vs Service Tag vs ASG

8.3 Quando usar ASGs obrigatoriamente

9. Boas Práticas

10. Erros Comuns

11. Operação e Manutenção

11.1 Diagnosticando conectividade

11.2 Monitorando NSGs com Azure Monitor

11.3 Limites importantes

12. Integração e Automação

12.1 Azure Policy para conformidade de NSG

12.2 Terraform para NSG com ASG

13. Resumo Final