Laboratório de Troubleshooting: Create an application security group (ASG)
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Um administrador criou um ASG chamado asg-frontend para segmentar o tráfego de entrada das VMs de apresentação de uma aplicação web. Após criar o ASG via Portal do Azure, ele tenta associá-lo a uma regra de NSG existente no NSG nsg-app-eastus2 para permitir tráfego HTTP na porta 80. Ao tentar salvar a regra com o ASG como destino, o Portal retorna o seguinte erro:
The application security group
'/subscriptions/a1b2c3d4/resourceGroups/rg-network-westus/providers/
Microsoft.Network/applicationSecurityGroups/asg-frontend'
cannot be used in region 'eastus2' because it is in region 'westus'.
O administrador confirma que todas as VMs da aplicação estão na região eastus2, que o NSG nsg-app-eastus2 está associado a uma subnet em eastus2, e que o Resource Group rg-network-westus foi criado intencionalmente na região westus para centralizar metadados de rede. O administrador menciona que outros recursos dentro de rg-network-westus, como tabelas de rotas, funcionam normalmente quando referenciados por subnets em eastus2.
Qual é a causa raiz do erro observado?
A) O Resource Group rg-network-westus está em uma região diferente de eastus2, e recursos de rede não podem ser referenciados entre Resource Groups de regiões distintas.
B) O ASG foi criado na região westus por herdar a região do Resource Group, e ASGs só podem ser usados em NSGs e NICs que estejam na mesma região do ASG.
C) O NSG nsg-app-eastus2 não suporta ASGs como destino em regras de entrada quando o ASG foi criado em um Resource Group diferente do NSG.
D) O erro ocorre porque o ASG asg-frontend ainda não tem NICs associadas, e o Azure exige pelo menos uma NIC associada antes de permitir o uso do ASG em regras de NSG.
Cenário 2 — Sequência de Diagnóstico
Uma equipe de infraestrutura recebe um chamado relatando que VMs de um novo ambiente não estão se comunicando conforme esperado após a criação de ASGs e regras de NSG. O administrador responsável suspeita que os ASGs foram criados corretamente, mas algo na associação ou nas regras está incorreto.
Os passos de investigação disponíveis são:
- Verificar se as NICs das VMs estão associadas aos ASGs corretos usando o Portal ou o comando
az network nic show - Confirmar que os ASGs referenciados nas regras do NSG existem e estão na mesma região do NSG
- Revisar as regras do NSG para verificar se os ASGs estão sendo usados corretamente como origem ou destino nas regras relevantes
- Usar o IP flow verify no Network Watcher para confirmar se o tráfego específico está sendo permitido ou bloqueado
- Confirmar que o NSG está associado à subnet ou às NICs das VMs afetadas
Qual é a sequência correta de investigação?
A) 2 -> 5 -> 3 -> 1 -> 4
B) 4 -> 2 -> 1 -> 3 -> 5
C) 1 -> 3 -> 2 -> 5 -> 4
D) 5 -> 2 -> 3 -> 1 -> 4
Cenário 3 — Decisão de Ação
Durante uma revisão de segurança, a equipe identificou que o ASG asg-db-tier foi criado na região brazilsouth, mas todas as VMs de banco de dados que deveriam ser associadas a ele estão na região eastus. A causa está confirmada: o script de provisionamento usou o parâmetro de localização do Resource Group em vez da localização explícita das VMs.
O ambiente tem as seguintes restrições:
- As VMs de banco de dados estão em produção e processando transações ativas
- Não há janela de manutenção disponível nas próximas 6 horas
- O ASG asg-db-tier ainda não tem NICs associadas e não está referenciado em nenhuma regra de NSG ativa
- A equipe de segurança exige que a segmentação por ASG esteja operacional antes da próxima janela de manutenção, que ocorre em 8 horas
- Criar um novo ASG na região correta não requer aprovação adicional
Qual é a ação correta a tomar agora?
A) Mover o ASG asg-db-tier de brazilsouth para eastus usando o recurso de relocação do Azure Resource Mover para preservar o nome e evitar retrabalho.
B) Criar um novo ASG na região eastus com o nome asg-db-tier-eastus, associar as NICs das VMs de banco de dados a ele e configurar as regras de NSG necessárias antes da janela de manutenção.
C) Associar as NICs das VMs de banco de dados ao ASG asg-db-tier existente em brazilsouth e atualizar o NSG para referenciar esse ASG, já que o NSG aceita ASGs de regiões diferentes quando as VMs estão na mesma VNet.
D) Aguardar a janela de manutenção em 8 horas para excluir o ASG incorreto e recriar tudo no ambiente de produção com impacto controlado.
Cenário 4 — Causa Raiz
Um administrador cria um ASG chamado asg-api-layer via Azure CLI com o seguinte comando:
az network asg create \
--resource-group rg-networking \
--name asg-api-layer \
--location eastus
A saída retorna sucesso. Em seguida, ele tenta criar uma regra no NSG nsg-backend que usa o asg-api-layer como origem e um endereço IP específico como destino:
az network nsg rule create \
--resource-group rg-networking \
--nsg-name nsg-backend \
--name Allow-API-to-DB \
--priority 300 \
--direction Inbound \
--source-asgs asg-api-layer \
--source-port-ranges '*' \
--destination-address-prefixes 10.2.1.5 \
--destination-port-ranges 1433 \
--access Allow \
--protocol Tcp
O comando retorna erro. O administrador verifica que o NSG nsg-backend existe no Resource Group rg-networking e está associado a uma subnet em eastus. O ASG asg-api-layer também está em eastus. O administrador menciona que criou o NSG há três semanas e que ele já contém 12 regras ativas sem problemas. A subscription está com 95% do limite de ASGs por região utilizado.
Ao executar az network nsg rule list --resource-group rg-networking --nsg-name nsg-backend, todas as 12 regras existentes aparecem corretamente.
O erro retornado pela CLI é:
(InvalidRequestFormat) Cannot mix ASG and non-ASG in source or destination.
Qual é a causa raiz do erro?
A) O limite de ASGs por região está próximo do esgotamento, impedindo a criação de novas regras que referenciam ASGs.
B) Uma regra de NSG não pode misturar ASG como origem com um endereço IP como destino; quando ASGs são usados, tanto origem quanto destino devem ser ASGs ou ambos devem ser endereços IP ou prefixos.
C) O parâmetro --source-asgs requer que o ASG esteja associado a pelo menos uma NIC antes de ser usado em uma regra de NSG, e o asg-api-layer ainda não tem NICs.
D) O NSG nsg-backend já atingiu o limite de regras que podem referenciar ASGs, e as 12 regras existentes esgotaram a cota de referências a ASGs por NSG.
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
O ponto central é que a região de um ASG é determinada no momento da criação e não pela região do Resource Group. Porém, na prática, quando um administrador cria um recurso pelo Portal sem especificar explicitamente a localização, o Portal pode usar a região do Resource Group como padrão. O erro da CLI confirma que o ASG está em westus e o NSG está em eastus2: ASGs só podem ser referenciados em NSGs e NICs que estejam na mesma região do ASG. Essa restrição é absoluta e não pode ser contornada.
A informação irrelevante é a menção de que tabelas de rotas em rg-network-westus funcionam quando referenciadas por subnets em eastus2. Tabelas de rotas têm uma relação de associação diferente com subnets e não seguem a mesma restrição de co-localização regional que ASGs têm com NSGs.
O principal erro de raciocínio dos distratores é confundir a restrição de região com restrição de Resource Group. A alternativa A sugere que o problema está na diferença de Resource Group entre regiões, o que não é o modelo correto. A alternativa D introduz um requisito de NIC prévia que não existe na plataforma: ASGs podem ser referenciados em regras de NSG antes de ter qualquer NIC associada.
O distrator mais perigoso é a alternativa A. Agir com base nela levaria o administrador a mover recursos entre Resource Groups desnecessariamente, sem resolver o problema real de região do ASG.
Gabarito — Cenário 2
Resposta: A
A sequência correta é: 2 -> 5 -> 3 -> 1 -> 4
- Passo 2 primeiro: confirmar que os ASGs existem e estão na região correta é o pré-requisito para qualquer uso válido deles. Um ASG em região errada invalida toda a cadeia seguinte.
- Passo 5 em seguida: verificar se o NSG está associado à subnet ou às NICs é o segundo pré-requisito. Um NSG desassociado não produz efeito algum, independentemente das regras que contém.
- Passo 3 depois: com NSG associado e ASGs válidos confirmados, revisar as regras para garantir que os ASGs estão sendo usados como origem ou destino corretos é o próximo passo lógico.
- Passo 1 após: verificar se as NICs das VMs estão efetivamente associadas aos ASGs referenciados nas regras é o que fecha o ciclo de configuração.
- Passo 4 por último: o IP flow verify é a ferramenta de validação final, usada para confirmar empiricamente o comportamento depois de todos os itens de configuração terem sido verificados.
A alternativa B começa pelo IP flow verify, o que inverte a lógica: usar uma ferramenta de validação antes de verificar as configurações produz resultados que podem ser difíceis de interpretar sem o contexto de configuração estabelecido.
A alternativa C começa pela associação de NICs, que é um detalhe de configuração interno, antes de verificar os pré-requisitos estruturais como região e associação de NSG.
Gabarito — Cenário 3
Resposta: B
O enunciado estabelece que o ASG incorreto não tem NICs associadas e não está referenciado em nenhuma regra ativa, o que significa que excluí-lo e criar um novo não causa impacto operacional algum. A restrição crítica é o prazo: a segmentação precisa estar operacional em menos de 8 horas, e a janela de manutenção ocorre exatamente nesse período. Criar um novo ASG na região correta e configurar as regras dentro da janela é a única alternativa que respeita simultaneamente o prazo, a restrição de produção ativa e a ausência de risco.
A alternativa A é o distrator mais perigoso: ASGs não são recursos relocáveis pelo Azure Resource Mover. Tentar usar essa abordagem consumiria tempo precioso para descobrir que a operação não é suportada, comprometendo o prazo da janela de manutenção.
A alternativa C está tecnicamente incorreta: NSGs não aceitam ASGs de regiões diferentes. Essa configuração resultaria no mesmo erro visto no Cenário 1.
A alternativa D adia a ação para a janela de manutenção sem necessidade, pois o ASG incorreto não tem dependências ativas e pode ser tratado imediatamente sem risco.
Gabarito — Cenário 4
Resposta: B
O erro Cannot mix ASG and non-ASG in source or destination é explícito e direto: em uma única regra de NSG, não é permitido combinar um ASG com um endereço IP ou prefixo no mesmo campo de origem ou destino, nem usar ASG em um campo e endereço IP no outro. Quando uma regra usa ASG como origem, o destino deve ser também um ASG ou o campo deve ser configurado como * (qualquer). A combinação de ASG como origem com endereço IP específico como destino viola essa restrição da plataforma.
A informação irrelevante é o percentual de utilização do limite de ASGs por região (95%). Esse dado foi incluído para induzir o leitor à alternativa A. O limite de ASGs por região controla quantos ASGs podem ser criados, não se regras podem referenciar ASGs existentes.
O principal erro de raciocínio dos distratores é atribuir o problema a limites de capacidade ou a pré-requisitos de configuração como NICs associadas. Nenhum desses fatores é relevante para o erro retornado. A alternativa C é especialmente enganosa porque cria um requisito inexistente: ASGs podem ser usados em regras de NSG antes de ter qualquer NIC associada.
O distrator mais perigoso é a alternativa A. Agir com base nela levaria a equipe a investigar limites de subscription e abrir chamados com a Microsoft, sem nunca corrigir a regra de NSG.
Árvore de Troubleshooting: Create an application security group (ASG)
Legenda de cores:
- Azul escuro: sintoma inicial, ponto de entrada da investigação
- Azul: pergunta diagnóstica objetiva com resposta verificável
- Vermelho: causa identificada e confirmada
- Verde: ação recomendada ou resolução a executar
- Laranja: validação ou verificação intermediária antes de prosseguir
Como percorrer a árvore diante de um problema real: parta do nó raiz e identifique imediatamente se o problema ocorre na criação do ASG ou no seu uso posterior em regras de NSG ou associação a NICs. Essa primeira bifurcação determina o caminho de investigação. Responda cada pergunta azul com base no que é verificável diretamente no Portal ou via CLI. Ao chegar em um nó laranja, execute a verificação antes de avançar. Ao atingir um nó vermelho, a causa está confirmada; siga para o nó verde correspondente e execute a ação. Use o IP flow verify como validação final após qualquer correção de configuração.