Fundamentação Teórica: Evaluate Effective Security Rules in NSGs

1. Intuição Inicial

Imagine que você trabalha num prédio corporativo com dois pontos de controle de segurança: o primeiro na entrada do andar e o segundo na porta da sala específica. Cada ponto tem sua própria lista de regras. Para chegar à sua mesa, você precisa passar pelos dois pontos. Se qualquer um bloquear, você não entra.

Agora imagine que você precisa explicar para alguém por que ele não consegue entrar na sala. Você precisaria consultar ambas as listas de regras simultaneamente, na ordem em que são verificadas, para encontrar exatamente qual regra está bloqueando.

Effective Security Rules é a ferramenta do Azure que faz exatamente isso: consolida e exibe, numa visão única e ordenada, todas as regras de todos os NSGs que se aplicam a uma interface de rede específica, tanto as regras do NSG da subnet quanto as do NSG da NIC. É o diagnóstico definitivo para entender o comportamento real de segurança de uma VM.

2. Contexto

2.1 Por que Effective Security Rules existe

No módulo anterior sobre NSGs, vimos que um fluxo de tráfego pode ser avaliado por até dois NSGs simultaneamente: um associado à subnet e outro associado à NIC. Cada NSG pode ter dezenas de regras, incluindo regras padrão e regras customizadas.

Quando um administrador precisa responder "por que o tráfego na porta 8080 está sendo bloqueado para esta VM?", olhar os dois NSGs separadamente e mentalmente combinar as regras é complexo, propenso a erros e lento.

Effective Security Rules resolve isso computando automaticamente a visão consolidada e ordenada de todas as regras que realmente se aplicam ao tráfego de entrada e saída de uma NIC específica.

2.2 Ferramentas complementares no ecossistema

100%

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

3. Construção dos Conceitos

3.1 O que são Effective Security Rules exatamente

As Effective Security Rules de uma NIC são o resultado de combinar e ordenar todas as regras de todos os NSGs que se aplicam a ela:

Regras do NSG associado à subnet onde a VM está
Regras do NSG associado diretamente à NIC
Regras padrão de cada NSG (as três regras de prioridade 65000-65500)

A combinação resulta em uma lista única, separada por direção (inbound e outbound), ordenada por prioridade. A lógica de avaliação para tráfego inbound é:

NSG da subnet é avaliado primeiro
Se permitido, NSG da NIC é avaliado
Se ambos permitirem, o tráfego passa
Se qualquer um negar, o tráfego é bloqueado

Effective Security Rules não "funde" os dois NSGs num único. Ela exibe as regras de cada NSG separadamente, mas organizadas de forma que você entenda qual é avaliada primeiro e em que contexto.

3.2 O que é exibido em Effective Security Rules

A visualização mostra, para cada regra, os seguintes campos:

Campo	Descrição
Priority	Número de prioridade da regra (menor = mais prioritária)
Name	Nome da regra
Port	Porta(s) de destino
Protocol	TCP, UDP, ICMP ou Any
Source	IP, CIDR, Service Tag ou ASG de origem
Destination	IP, CIDR, Service Tag ou ASG de destino
Action	Allow ou Deny
Source (NSG)	Indica de qual NSG a regra vem (subnet NSG ou NIC NSG)

Esse último campo é crucial: ele permite identificar se a regra vem do NSG da subnet ou do NSG da NIC, o que é essencial para saber onde fazer a correção.

3.3 A ordem de avaliação: inbound vs outbound

A ordem de avaliação dos NSGs muda dependendo da direção do tráfego:

100%

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

3.4 IP Flow Verify: o complemento prático

Enquanto Effective Security Rules mostra todas as regras, o IP Flow Verify responde uma pergunta específica: "se um pacote vier de IP X, porta Y, para minha VM na porta Z, ele seria permitido ou negado, e por qual regra?"

IP Flow Verify simula o processo de avaliação de um fluxo específico e retorna:

Se o fluxo seria Allowed ou Denied
O nome exato da regra que tomou a decisão
O NSG que contém essa regra

Esta é a ferramenta mais direta para diagnóstico de conectividade específica.

3.5 Connection Troubleshoot: diagnóstico end-to-end

Connection Troubleshoot vai além de NSGs: ele verifica a conectividade completa entre dois endpoints, considerando rotas, firewalls dentro das VMs e NSGs. Retorna:

Status da conexão (Reachable/Unreachable)
Latência e hop count
Qual componente está causando o problema (NSG, rota, firewall da VM)

4. Visão Estrutural

4.1 Cenário completo de diagnóstico

100%

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

5. Funcionamento na Prática

5.1 Acessando Effective Security Rules no Portal

Caminho 1: Via NIC da VM

VM > Settings > Networking > Inbound/Outbound port rules > Effective security rules

Caminho 2: Via NIC diretamente

Network Interfaces > [NIC] > Support + troubleshooting > Effective security rules

Caminho 3: Via Network Watcher

Network Watcher > Network diagnostic tools > NSG diagnostics

A interface exibe duas seções:

Inbound rules (com subseções para NSG da subnet e NSG da NIC)
Outbound rules (com subseções para NSG da NIC e NSG da subnet, nessa ordem)

5.2 Interpretando o resultado

Considere este cenário: uma VM tem dois NSGs associados.

NSG da Subnet (NSG-WebSubnet):

Priority	Name	Source	Dest Port	Action
100	Allow-HTTPS	Internet	443	Allow
200	Allow-HTTP	Internet	80	Allow
65000	AllowVnetInBound	VirtualNetwork	*	Allow
65001	AllowAzureLBInBound	AzureLoadBalancer	*	Allow
65500	DenyAllInBound	*	*	Deny

NSG da NIC (NSG-VM01-NIC):

Priority	Name	Source	Dest Port	Action
100	Deny-SSH	*	22	Deny
65000	AllowVnetInBound	VirtualNetwork	*	Allow
65001	AllowAzureLBInBound	AzureLoadBalancer	*	Allow
65500	DenyAllInBound	*	*	Deny

Pergunta: Um cliente externo tenta SSH (porta 22) na VM. O que acontece?

Análise com Effective Security Rules:

NSG da Subnet avalia primeiro. A porta 22 não é coberta pelas regras 100 ou 200. AllowVnetInBound (65000) cobre VirtualNetwork como source, mas este tráfego vem da Internet. O DenyAllInBound (65500) bloqueia... mas espere: não há regra de Deny explícita antes de 65500 para porta 22 na subnet NSG.
Na verdade, AllowVnetInBound não se aplica (source é Internet, não VirtualNetwork). O tráfego chega à regra 65500 (DenyAllInBound) e seria bloqueado.
Resultado: Bloqueado pela subnet NSG antes mesmo de chegar ao NSG da NIC.

Agora imagine que a subnet NSG tivesse permitido SSH:

Se a subnet NSG tivesse Allow SSH from Internet com prioridade 150, o tráfego passaria pela subnet NSG. Então o NSG da NIC avaliaria: sua regra 100 (Deny-SSH) bloquearia o tráfego. O resultado final seria Deny, mas agora pelo NSG da NIC.

Esta distinção importa porque as correções são em NSGs diferentes.

5.3 Usando IP Flow Verify

IP Flow Verify está no Network Watcher e requer:

VM de destino (ou origem para outbound)
Direção: Inbound ou Outbound
Protocolo: TCP ou UDP
Local IP e Porta: IP e porta locais da VM
Remote IP e Porta: IP e porta do cliente externo

O resultado retorna:

Access: Denied
Rule Name: DenyAllInBound
Rule Priority: 65500
NSG Name: NSG-WebSubnet
NSG Resource Group: myRG

Este resultado preciso elimina a necessidade de analisar manualmente todas as regras.

6. Formas de Implementação

6.1 Portal Azure

Quando usar: Diagnóstico visual, troubleshooting interativo, quando você precisa navegar pelas regras e entender o contexto completo.

Effective Security Rules:

Navegue até a VM > Networking > Effective security rules. A interface mostra as regras em formato tabular com filtros por direção.

IP Flow Verify:

Network Watcher > IP Flow Verify

Preencha os campos e obtenha resultado imediato.

Limitação: Não é scriptável, não gera relatórios em massa para múltiplas VMs.

6.2 Azure CLI

Listando Effective Security Rules via CLI:

# Identificar o nome da NIC da VM
az vm show \
  --resource-group myRG \
  --name myVM \
  --query "networkProfile.networkInterfaces[].id" \
  --output tsv

# Obter effective security rules da NIC
az network nic show-effective-nsg \
  --name myVM-NIC \
  --resource-group myRG \
  --output json

A saída JSON contém dois arrays: effectiveNetworkSecurityGroups para as regras aplicadas, com a origem de cada regra (subnet NSG ou NIC NSG).

Exemplo de parsing da saída:

# Listar apenas regras Deny efetivas
az network nic show-effective-nsg \
  --name myVM-NIC \
  --resource-group myRG \
  --query "effectiveNetworkSecurityGroups[].effectiveSecurityRules[?access=='Deny'].{Name:name, Priority:priority, Direction:direction, Port:destinationPortRange}" \
  --output table

IP Flow Verify via CLI:

az network watcher test-ip-flow \
  --resource-group myRG \
  --vm myVM \
  --direction Inbound \
  --protocol TCP \
  --local 10.0.1.4:22 \
  --remote 203.0.113.1:* \
  --out table

Saída:

Access    DirectionEnum    RuleName           TargetNicId
--------  ---------------  -----------------  ------------
Deny      Inbound          Deny-SSH           /subscriptions/.../networkInterfaces/myVM-NIC

Connection Troubleshoot via CLI:

az network watcher test-connectivity \
  --resource-group myRG \
  --source-resource myVM \
  --dest-address 10.0.2.5 \
  --dest-port 1433 \
  --protocol Tcp

6.3 Azure PowerShell

# Effective Security Rules
$nic = Get-AzNetworkInterface `
  -Name "myVM-NIC" `
  -ResourceGroupName "myRG"

$effectiveNSG = Get-AzEffectiveNetworkSecurityGroup `
  -NetworkInterfaceName "myVM-NIC" `
  -ResourceGroupName "myRG"

# Ver regras Deny inbound
$effectiveNSG.EffectiveNetworkSecurityGroups |
  ForEach-Object { $_.EffectiveSecurityRules } |
  Where-Object { $_.Access -eq "Deny" -and $_.Direction -eq "Inbound" } |
  Select-Object Name, Priority, SourcePortRange, DestinationPortRange |
  Sort-Object Priority

# IP Flow Verify
$networkWatcher = Get-AzNetworkWatcher `
  -ResourceGroupName "NetworkWatcherRG" `
  -Name "NetworkWatcher_eastus"

$vm = Get-AzVM `
  -ResourceGroupName "myRG" `
  -Name "myVM"

Test-AzNetworkWatcherIPFlow `
  -NetworkWatcher $networkWatcher `
  -TargetVirtualMachineId $vm.Id `
  -Direction Inbound `
  -Protocol TCP `
  -RemoteIPAddress "203.0.113.1" `
  -LocalIPAddress "10.0.1.4" `
  -LocalPort "22" `
  -RemotePort "12345"

6.4 NSG Diagnostics no Network Watcher (Portal)

Uma ferramenta mais completa que o IP Flow Verify básico:

Network Watcher > NSG diagnostics

Permite especificar:

VM ou NIC de destino
Protocolo, IP source, IP destination, porta

Retorna não apenas Allow/Deny, mas também quais NSGs foram avaliados, em que ordem, e qual regra específica tomou a decisão final. Exibe visualmente o caminho de avaliação.

7. Controle e Segurança

7.1 Permissões necessárias

Operação	Role mínima
Ver Effective Security Rules	Network Contributor ou Reader com Network Watcher Reader
Usar IP Flow Verify	Network Watcher Contributor
Usar Connection Troubleshoot	Network Watcher Contributor
Modificar regras NSG após diagnóstico	Network Contributor

7.2 Auditoria de mudanças em NSGs

Sempre que uma mudança em NSG é necessária após um diagnóstico, ela deve ser documentada e auditada:

# Ver histórico de mudanças em NSGs via Activity Log
az monitor activity-log list \
  --resource-group myRG \
  --caller "user@company.com" \
  --start-time "2025-01-01T00:00:00Z" \
  --query "[?contains(operationName.value, 'networkSecurityGroups')].{Time:eventTimestamp, Operation:operationName.value, Status:status.value}" \
  --output table

7.3 Armadilhas de diagnóstico

Armadilha 1: A regra correta no NSG errado

Um administrador adiciona Allow SSH no NSG da NIC mas esquece que o NSG da Subnet tem Deny SSH com prioridade menor (mais alta). Para inbound, a subnet NSG é avaliada primeiro e bloqueia antes mesmo de chegar ao NSG da NIC.

Armadilha 2: Regras para outbound no NSG errado

Para tráfego outbound, o NSG da NIC é avaliado primeiro. Uma regra no NSG da Subnet não tem efeito se o NSG da NIC já negou o tráfego.

Armadilha 3: Tráfego permitido pelo NSG mas bloqueado dentro da VM

Effective Security Rules e IP Flow Verify analisam apenas o NSG. Se o Windows Firewall ou iptables dentro da VM estiver bloqueando, essas ferramentas retornarão "Allowed" mas o tráfego ainda não chegará ao serviço.

8. Tomada de Decisão

8.1 Qual ferramenta usar para cada cenário

Situação	Ferramenta	Motivo
"Quais regras se aplicam a essa VM?"	Effective Security Rules	Visão completa de todas as regras
"Por que a porta 8080 está bloqueada para esse IP?"	IP Flow Verify	Diagnóstico direto para fluxo específico
"A VM consegue se conectar ao banco de dados?"	Connection Troubleshoot	Teste end-to-end com resposta de conectividade
"Qual rota o tráfego está usando?"	Next Hop	Diagnóstico de roteamento
"O tráfego está chegando à VM mas a aplicação não responde?"	Packet Capture	Análise de pacotes dentro da rede
"Múltiplas VMs com problema, preciso analisar em massa"	CLI + az network nic show-effective-nsg	Scriptável e automatizável

8.2 Quando a subnet NSG é suficiente vs quando NIC NSG é necessário

Situação	Abordagem
Regra que deve se aplicar a todas as VMs da subnet	Subnet NSG
Exceção para uma VM específica (mais permissiva)	NIC NSG com regra Allow de menor prioridade que Deny da subnet
Exceção para uma VM específica (mais restritiva)	NIC NSG com regra Deny adicional
Microsegmentação complexa com ASGs	Subnet NSG com regras usando ASG

9. Boas Práticas

Use IP Flow Verify como primeiro passo quando houver problema de conectividade específico. É mais rápido e direto que navegar manualmente pelas Effective Security Rules.
Use Effective Security Rules para auditoria quando precisar entender todo o contexto de segurança de uma VM, não apenas um fluxo específico.
Sempre verifique a direção correta ao usar IP Flow Verify: inbound para tráfego chegando à VM, outbound para tráfego saindo.
Após identificar o problema com IP Flow Verify, use Effective Security Rules para localizar a regra no contexto completo e confirmar onde fazer a correção.
Automatize auditorias de segurança em múltiplas VMs via CLI com az network nic show-effective-nsg e scripts que identificam VMs com regras de alta permissividade (ex: portas 22/3389 abertas para *).
Documente todas as mudanças feitas após diagnóstico no Activity Log e em sistema de tickets para rastreabilidade.
Habilite NSG Flow Logs para ter dados históricos de quais fluxos foram permitidos ou negados, permitindo análise forense retroativa.

10. Erros Comuns

Erro	Por que acontece	Como evitar
Adiciona Allow no NSG da NIC mas continua bloqueado	NSG da Subnet bloqueia antes para inbound	Verificar a ordem de avaliação: subnet primeiro para inbound
IP Flow Verify retorna "Allowed" mas serviço não responde	Firewall dentro da VM (Windows Firewall/iptables) bloqueando	Combinar IP Flow Verify com diagnóstico dentro da VM
Confunde inbound e outbound no IP Flow Verify	Lógica de direção não intuitiva	Para tráfego entrando na VM: inbound. Para tráfego saindo: outbound.
Adiciona Allow no NSG mas esquece porta de resposta	TCP requer resposta (outbound) além de request (inbound)	NSGs são stateful: conexões estabelecidas têm resposta permitida automaticamente
Diagnóstico feito na VM errada	Múltiplas VMs com nomes similares	Confirmar IP e Resource ID da VM antes do diagnóstico
Regra aplicada em NSG desassociado	NSG existe mas não está associado à subnet ou NIC	Verificar associations do NSG em `Overview > Subnets` e `Network interfaces`

11. Operação e Manutenção

11.1 Auditoria automatizada de Effective Security Rules

Script para verificar se alguma VM tem SSH/RDP aberto para qualquer IP:

#!/bin/bash
# Verificar VMs com SSH ou RDP abertos para Internet

RESOURCE_GROUP="myRG"

# Listar todas as NICs
for NIC in $(az network nic list --resource-group $RESOURCE_GROUP --query "[].name" --output tsv); do
    echo "Verificando NIC: $NIC"
    
    # Verificar regras que permitem SSH/RDP da Internet
    az network nic show-effective-nsg \
      --name "$NIC" \
      --resource-group "$RESOURCE_GROUP" \
      --query "effectiveNetworkSecurityGroups[].effectiveSecurityRules[?access=='Allow' && direction=='Inbound' && (contains(destinationPortRange, '22') || contains(destinationPortRange, '3389')) && sourceAddressPrefix=='*'].{NIC:'$NIC', Rule:name, Port:destinationPortRange, Source:sourceAddressPrefix}" \
      --output table
done

11.2 NSG Flow Logs para análise retroativa

Se você precisa analisar retroativamente por que um tráfego foi bloqueado e Flow Logs estão habilitados:

# Consultar Flow Logs no Log Analytics (se Traffic Analytics habilitado)

No Log Analytics:

AzureNetworkAnalytics_CL
| where SubType_s == "FlowLog"
| where FlowDirection_s == "I"  // Inbound
| where FlowStatus_s == "D"     // Denied
| where DestPort_d == 22        // SSH
| project TimeGenerated, SrcIP_s, DestIP_s, DestPort_d, NSGName_s, NSGRules_s
| order by TimeGenerated desc
| take 100

11.3 Limites e considerações

Aspecto	Detalhe
Effective Security Rules disponível quando	VM está em estado Running
IP Flow Verify funciona quando	Network Watcher está habilitado na região
VM sem NSG associado	Effective Security Rules retorna vazio para esse nível
NSGs não exibidos	Se a VM não tem NIC ou a NIC não tem NSG, a seção correspondente fica vazia
Tempo de resposta do IP Flow Verify	Imediato (simulação, não tráfego real)

12. Integração e Automação

12.1 Relatório de segurança automatizado com Logic Apps

Crie um relatório diário de todas as VMs com regras permissivas:

{
  "trigger": "Recurrence (Daily 08:00)",
  "actions": [
    {
      "type": "Azure CLI",
      "command": "az network nic list + az network nic show-effective-nsg"
    },
    {
      "type": "Filter",
      "condition": "Rules with source=* and Action=Allow and Port in [22,3389,3306,1433]"
    },
    {
      "type": "Send Email",
      "to": "security-team@company.com",
      "body": "VMs com regras permissivas detectadas"
    }
  ]
}

12.2 Integração com Microsoft Defender for Cloud

O Defender for Cloud usa automaticamente as informações de Effective Security Rules para gerar recomendações de segurança como:

"Management ports should be closed on your virtual machines"
"Just-in-time network access control should be applied on virtual machines"

Configure alertas no Defender for Cloud para notificação automática quando VMs expõem portas sensíveis:

az security pricing create \
  --name VirtualMachines \
  --tier Standard

12.3 Azure Policy para prevenção

Combine diagnóstico reativo (Effective Security Rules) com prevenção proativa (Azure Policy):

# Policy: Negar criação de regras NSG que permitem SSH da Internet
az policy assignment create \
  --name "deny-ssh-from-internet" \
  --policy "5e1e7afc-2ffe-4a9f-a897-db51f019099c" \
  --scope "/subscriptions/<sub-id>"

Esta policy built-in nega criação de regras NSG que abrem SSH (22) ou RDP (3389) para qualquer fonte (* ou Internet).

13. Resumo Final

Conceitos essenciais:

Effective Security Rules exibe a visão consolidada de todas as regras de todos os NSGs aplicados a uma NIC, separados por direção (inbound/outbound) e pela origem (NSG da subnet ou NSG da NIC).
IP Flow Verify simula um fluxo específico e retorna Allow/Deny com o nome exato da regra e o NSG responsável pela decisão.
Connection Troubleshoot realiza diagnóstico end-to-end entre dois endpoints, considerando NSGs, rotas e conectividade geral.

A ordem de avaliação que precisa ser memorizada:

Inbound: NSG da Subnet → NSG da NIC. Ambos devem permitir.
Outbound: NSG da NIC → NSG da Subnet. Ambos devem permitir.

Diferenças críticas:

Effective Security Rules vs IP Flow Verify: Effective Security Rules mostra todas as regras para análise completa. IP Flow Verify testa um fluxo específico e retorna resultado binário com regra responsável.
NSG Stateful: Uma vez que uma conexão TCP é estabelecida (inbound permitido), o tráfego de retorno (outbound) é automaticamente permitido sem necessitar de regra outbound explícita. IP Flow Verify e Effective Security Rules refletem esse comportamento.
Bloqueio por NSG vs bloqueio dentro da VM: IP Flow Verify retornando "Allowed" mas serviço não respondendo indica problema dentro da VM (firewall local, serviço não iniciado), não no NSG.

O que precisa ser lembrado:

Effective Security Rules só funciona quando a VM está em estado Running.
Network Watcher precisa estar habilitado na região da VM para usar IP Flow Verify e Connection Troubleshoot.
Uma VM sem NSG associado (nem à subnet nem à NIC) permite todo o tráfego por padrão.
Para diagnóstico em massa de múltiplas VMs, use az network nic show-effective-nsg via script CLI.
A ferramenta mais rápida para identificar qual regra NSG causa um problema de conectividade específico é o IP Flow Verify, não a leitura manual das Effective Security Rules.

1. Intuição Inicial​

2. Contexto​

2.1 Por que Effective Security Rules existe​

2.2 Ferramentas complementares no ecossistema​

3. Construção dos Conceitos​

3.1 O que são Effective Security Rules exatamente​

3.2 O que é exibido em Effective Security Rules​

3.3 A ordem de avaliação: inbound vs outbound​

3.4 IP Flow Verify: o complemento prático​

3.5 Connection Troubleshoot: diagnóstico end-to-end​

4. Visão Estrutural​

4.1 Cenário completo de diagnóstico​

5. Funcionamento na Prática​

5.1 Acessando Effective Security Rules no Portal​

5.2 Interpretando o resultado​

5.3 Usando IP Flow Verify​

6. Formas de Implementação​

6.1 Portal Azure​

6.2 Azure CLI​

6.3 Azure PowerShell​

6.4 NSG Diagnostics no Network Watcher (Portal)​

7. Controle e Segurança​

7.1 Permissões necessárias​

7.2 Auditoria de mudanças em NSGs​

7.3 Armadilhas de diagnóstico​

8. Tomada de Decisão​

8.1 Qual ferramenta usar para cada cenário​

8.2 Quando a subnet NSG é suficiente vs quando NIC NSG é necessário​

9. Boas Práticas​

10. Erros Comuns​

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

11.1 Auditoria automatizada de Effective Security Rules​

11.2 NSG Flow Logs para análise retroativa​

11.3 Limites e considerações​

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

12.1 Relatório de segurança automatizado com Logic Apps​

12.2 Integração com Microsoft Defender for Cloud​

12.3 Azure Policy para prevenção​

13. Resumo Final​

1. Intuição Inicial

2. Contexto

2.1 Por que Effective Security Rules existe

2.2 Ferramentas complementares no ecossistema

3. Construção dos Conceitos

3.1 O que são Effective Security Rules exatamente

3.2 O que é exibido em Effective Security Rules

3.3 A ordem de avaliação: inbound vs outbound

3.4 IP Flow Verify: o complemento prático

3.5 Connection Troubleshoot: diagnóstico end-to-end

4. Visão Estrutural

4.1 Cenário completo de diagnóstico

5. Funcionamento na Prática

5.1 Acessando Effective Security Rules no Portal

5.2 Interpretando o resultado

5.3 Usando IP Flow Verify

6. Formas de Implementação

6.1 Portal Azure

6.2 Azure CLI

6.3 Azure PowerShell

6.4 NSG Diagnostics no Network Watcher (Portal)

7. Controle e Segurança

7.1 Permissões necessárias

7.2 Auditoria de mudanças em NSGs

7.3 Armadilhas de diagnóstico

8. Tomada de Decisão

8.1 Qual ferramenta usar para cada cenário

8.2 Quando a subnet NSG é suficiente vs quando NIC NSG é necessário

9. Boas Práticas

10. Erros Comuns

11. Operação e Manutenção

11.1 Auditoria automatizada de Effective Security Rules

11.2 NSG Flow Logs para análise retroativa

11.3 Limites e considerações

12. Integração e Automação

12.1 Relatório de segurança automatizado com Logic Apps

12.2 Integração com Microsoft Defender for Cloud

12.3 Azure Policy para prevenção

13. Resumo Final