Microsoft AZ-500: Arquitetura de Segurança de Rede — Guia de estudos

By Laurynas Brazys · 11 August 2026 · #microsoft #az-500 #certification #exam-prep #study-guide

Faz parte do Microsoft Azure Security Engineer Associate AZ-500 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Microsoft, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

A arquitetura de segurança de rede do Azure impõe conectividade de menor privilégio, pressupõe a violação e instrumentaliza o monitoramento contínuo. Ela combina microssegmentação dentro de redes virtuais, planos de controle com estado (stateful) para tráfego leste-oeste e de saída (egress), proteções de borda para endpoints voltados para a internet e acesso privado a PaaS. Projetos sólidos priorizam o acesso ciente da identidade na camada de aplicação, mantendo ao mesmo tempo limites de rede robustos, roteamento explícito e telemetria verificável.

Controles e Segmentação da Rede Virtual

As sub-redes são o primeiro limite de segmentação. Coloque cargas de trabalho com confiança, ciclo de vida e políticas semelhantes na mesma sub-rede; separe as camadas (web, aplicação, dados) para que você possa aplicar políticas e rotas independentes. Evite sub-redes “compartilhadas” planas que misturam ferramentas de administração, jump hosts e cargas de trabalho de negócios; elas complicam as políticas e aumentam o raio de impacto (blast radius).

Os Network Security Groups (NSGs) aplicam filtragem com estado (stateful) de camadas L3–L4 por sub-rede ou por NIC. As regras de entrada e saída são avaliadas por prioridade (número menor primeiro), com um DenyAll (negar tudo) implícito no final. Os NSGs são stateful: as respostas a fluxos permitidos são autorizadas automaticamente, então você raramente precisará de regras para portas efêmeras. Operacionalmente, vincule os NSGs a sub-redes para controles amplos e, em seguida, refine em NICs críticas. Sempre documente o proprietário, o propósito e a expiração de qualquer permissão “temporária”.

Os Application Security Groups (ASGs) permitem que você referencie grupos de VMs por nome em vez de IP, para que as regras sobrevivam ao escalonamento e à rotatividade de IPs. Marque as VMs em ASGs baseados em função (por exemplo, asg-web, asg-app) e expresse políticas como “asg-web → asg-app TCP 443”. Isso reduz a proliferação de regras e o desvio operacional.

As regras de segurança efetivas resultam da fusão de NSGs aplicados tanto a uma NIC quanto à sua sub-rede. A permissão/negação correspondente mais específica (por prioridade) prevalece. Valide com as “Regras de segurança efetivas” no portal ou via verificação de fluxo de IP (IP flow verify) do Network Watcher para detectar entradas conflitantes antes das janelas de implantação.

As Marcas de Serviço (Service tags) (por exemplo, AzureLoadBalancer, Storage, Sql, Internet, VirtualNetwork) são mantidas pela Microsoft e agrupam espaços de IP grandes e dinâmicos em alvos de regra estáveis. Prefira as marcas de serviço a listas manuais de IP para evitar interrupções na rotação de IPs de serviço. Por exemplo, restrinja a saída para Storage e Sql enquanto nega o acesso amplo à Internet.

A microssegmentação e o Zero Trust são realizados por meio de:

Aplicação de NSGs com negação por padrão (deny-by-default) e abertura apenas de caminhos explícitos e mínimos.
Uso de ASGs para codificar a intenção da carga de trabalho.
Restrição da saída com marcas de serviço ou filtragem baseada em FQDN via Azure Firewall.
Imposição da regra “nenhum IP público em servidores” e roteamento de toda a saída através de um ponto de inspeção controlado.

Exemplo: crie uma regra de NSG permitindo a comunicação da camada web para a de aplicação sobre TLS com ASGs e negue todo o resto explicitamente com uma prioridade mais alta do que a negação implícita para documentar a intenção.

az network nsg rule create \
  --resource-group rg-sec \
  --nsg-name nsg-app \
  --name allow-web-to-app-443 \
  --priority 200 \
  --direction Inbound \
  --access Allow \
  --protocol Tcp \
  --source-asgs asg-web \
  --destination-asgs asg-app \
  --destination-port-ranges 443

Serviços de Segurança de Rede e Proteção de Borda

O Azure Firewall é um firewall de alta disponibilidade e totalmente com estado (stateful) com política central. Use-o para:

Controle leste-oeste e de saída quando os NSGs são insuficientes (nomes de domínio, inspeção de TLS).
DNAT para exposição de entrada limitada quando o Application Gateway não é adequado.
Registro centralizado e inteligência contra ameaças (threat intelligence).

Grupos de coleção de regras contêm coleções de regras (Rede, Aplicação, NAT) com prioridades que definem a ordem de avaliação. Dentro de um grupo, as coleções de menor prioridade são avaliadas primeiro; as regras são correspondidas pelo critério mais específico. Mantenha as regras de DNAT em seu próprio grupo com a maior prioridade de avaliação para capturar o tráfego de entrada de forma determinística.

Regras de Rede filtram por 5-tupla (IP/porta/protocolo).
Regras de Aplicação filtram por FQDN, categorias de URL (Premium) e podem usar FQDN tags.
Regras de NAT traduzem endereços/portas públicos para privados em cenários de entrada.

A filtragem baseada em inteligência contra ameaças bloqueia IPs/domínios maliciosos conhecidos. Execute no modo Alerta (Alert) durante o levantamento inicial (baselining) e, em seguida, no modo Negar (Deny) assim que os falsos positivos forem resolvidos.

Os recursos Premium adicionam:

Inspeção de TLS com descriptografia de saída e entrada, permitindo visibilidade L7 e IDPS.
Detecção e Prevenção de Intrusão (IDPS) com assinaturas e priorização de vulnerabilidades.
Filtragem de URL e categorias da web para controle de saída granular.
Controles avançados de certificado e política de TLS.

Operacionalmente, isole o firewall em uma sub-rede dedicada (AzureFirewallSubnet), roteie todo o tráfego destinado à internet para ele com UDRs e habilite as Zonas de Disponibilidade (Availability Zones). Use a Firewall Policy (e não as regras clássicas) para administração escalável, herança e divergência entre Dev/Test com uma política base compartilhada.

O Web Application Firewall (WAF) mitiga ataques da camada L7 (SQLi, XSS).

No Application Gateway, o WAF protege aplicativos regionais com TLS de ponta a ponta e políticas por site; ele termina o TLS do cliente e, opcionalmente, recriptografa para o backend.
No Azure Front Door, o WAF protege aplicativos distribuídos globalmente na borda com CDN integrada, proteções contra bots e controles geográficos.

Crie políticas de WAF e associe-as a gateways, listeners ou rotas. Escolha o modo de Detecção inicialmente para ajustar e, em seguida, o modo de Prevenção para bloquear. Use conjuntos de regras gerenciadas (OWASP 3.x) e adicione regras personalizadas para limites de taxa (rate limits) ou intervalos de IP. Configure exclusões (por exemplo, campos JSON ou cabeçalhos específicos) para reduzir falsos positivos sem enfraquecer a proteção geral.

Negação de Serviço Distribuída (DDoS):

O Básico é uma proteção de plataforma sempre ativa, mas não oferece telemetria por recurso ou ajuste de mitigação.
DDoS Protection: O Network Protection adiciona ajuste adaptativo por IP público, mitigação automática, análise de ataques, alertas, crédito de proteção de custos e acesso ao DDoS Rapid Response.

Habilite o Network Protection nas VNets que hospedam IPs públicos (SKU Standard). Use a telemetria (Métricas, logs de Diagnóstico) para observar vetores de ataque, ciclo de vida da mitigação e eficácia. Arquiteture os recursos protegidos atrás de balanceadores de carga ou do Application Gateway para absorver a carga volumétrica e minimize a exposição pública direta. Combine WAF e DDoS para uma defesa em camadas.

Administração, Monitoramento e Telemetria Seguros

Conectividade administrativa segura:

O Azure Bastion fornece RDP/SSH sobre TLS a partir do portal ou de um cliente nativo sem expor os IPs públicos das VMs. Use o SKU Standard para escala, conexões baseadas em IP e links compartilháveis. Restrinja o acesso ao Bastion por meio de RBAC e Just-in-Time.
O acesso Just-in-Time a VMs (Defender for Cloud) fecha as portas de gerenciamento nos NSGs e as abre mediante solicitação com prazo definido, aprovação e limites de IP de origem. Combine com o Bastion para uma postura sem IPs públicos e uma trilha de auditoria precisa.

O Network Watcher fornece verificação operacional e análise forense:

Os logs de fluxo de NSG (v2) são gravados no armazenamento e podem ser enviados para o Traffic Analytics no Log Analytics para obter insights sobre os principais comunicadores (top talkers), fluxos permitidos/negados e geografia.
O Connection troubleshoot testa ativamente a conectividade de ponta a ponta e informa onde um caminho está bloqueado (NSG, UDR, DNS, firewall).
A captura de pacotes pode ser acionada sob demanda ou por alertas; use buffers circulares (ring buffers) para reduzir o armazenamento e capturar apenas as portas relevantes.
As rotas efetivas e a verificação de fluxo de IP mapeiam as decisões em tempo de execução entre UDRs, BGP e NSGs; automatize essas verificações na fase de preflight do CI/CD.

Habilite rapidamente os logs de fluxo de NSG e a análise:

az network watcher flow-log configure \
  --resource-group rg-sec \
  --nsg nsg-app \
  --enabled true \
  --traffic-analytics true \
  --storage-account saflowlogs \
  --workspace /subscriptions/<sub>/resourceGroups/rg-la/providers/Microsoft.OperationalInsights/workspaces/la-workspace

Cenário de Problema Prático

A Starbucks está modernizando uma plataforma de gerenciamento de pedidos para o Azure. Metas de segurança: nenhum IP público nas camadas de aplicação/dados, egresso restrito, proteção web global e visibilidade operacional.

Crie três sub-redes por região: web, app, data, cada uma com seu próprio NSG e ASGs alinhados à sua função.

Justificativa: A microssegmentação baseada em sub-redes com ASGs codifica os fluxos de menor privilégio (web→app 443, app→data 1433) e reduz o raio de impacto (blast radius). NSGs separados por camada evitam o acoplamento acidental de políticas.

Implante o Azure Front Door Standard/Premium com uma política de WAF no modo de Prevenção (Prevention) usando OWASP 3.x e regras personalizadas para limitação de taxa (rate limiting) e restrições geográficas.

Justificativa: A proteção de borda global absorve o tráfego volumétrico, bloqueia ataques L7 comuns antes que cheguem à região e reduz a latência via anycast. As políticas de WAF na borda fornecem aplicação consistente entre as regiões.

Posicione um Application Gateway com WAF v2 em cada região na frente da camada web; termine o TLS no App Gateway e recriptografe para o backend.

Justificativa: O roteamento L7 regional e o WAF complementam o Front Door, permitindo mTLS por aplicação para os backends, afinidade baseada em cookies e implantações blue/green, mantendo a capacidade de inspeção.

Habilite a Proteção contra DDoS: Network Protection nas VNets que contêm os IPs públicos do Application Gateway.

Justificativa: A mitigação adaptativa por IP, a telemetria e a proteção de custos reduzem o risco de ataques volumétricos direcionados aos pontos de entrada regionais. O escopo na VNet garante que todos os IPs públicos atuais e futuros sejam protegidos sem configuração por recurso.

Implante o Azure Firewall Premium em um hub seguro; roteie todo o tráfego de egresso das sub-redes de app e data para ele com UDRs. Habilite a inspeção de TLS e o IDPS para o tráfego de saída e configure regras de aplicação para permitir apenas os FQDNs necessários.

Justificativa: O controle de egresso centralizado com descriptografia e detecção baseada em assinatura previne o comando e controle (command-and-control) e a exfiltração de dados. As regras de aplicação reduzem a manutenção em comparação com as regras baseadas em IP e se alinham ao egresso Zero Trust.

Use o Private Link para o Azure SQL e o Storage; desabilite o acesso à rede pública e configure zonas de DNS privado vinculadas a todas as VNets. Para cargas de trabalho em contêineres, use o Azure CNI.

Justificativa: Os private endpoints mantêm os caminhos de dados no backbone e eliminam a exposição pública. O DNS privado garante a resolução de nomes transparente. O Azure CNI garante que os IPs dos pods se originem da sub-rede para que o Private Link e os service endpoints funcionem corretamente.

Estabeleça o ExpressRoute com circuitos duplos em modo ativo-ativo e anuncie as rotas on-premise com BGP; habilite o IPsec sobre ER para tráfego sensível. Não anuncie a rota 0/0 inicialmente; pilote o túnel forçado (forced tunneling) primeiro em uma sub-rede de homologação (staging).

Justificativa: O ER fornece conectividade privada e previsível; a criptografia em camadas protege os fluxos de alta sensibilidade. A implementação controlada do túnel forçado evita o bloqueio acidental do acesso à internet (internet blackholing) e valida as rotas de exceção.

Forneça acesso administrativo via Azure Bastion e imponha o Just-in-Time em todas as VMs; remova todos os IPs públicos dos servidores.

Justificativa: Elimina as superfícies de gerenciamento expostas, preservando o acesso auditável e com prazo definido, alinhado ao princípio do menor privilégio.

Ative os logs de fluxo de NSG e o Traffic Analytics, configure os diagnósticos do Firewall e do WAF para o Log Analytics e defina alertas para mitigações de DDoS e picos de bloqueio do WAF.

Justificativa: A telemetria unificada permite a detecção proativa, o planejamento de capacidade e a resposta rápida a incidentes. O alerta sobre padrões de anomalia detecta ataques e configurações incorretas precocemente.

Implemente o Azure Policy para negar IPs públicos em NICs, exigir NSGs em todas as sub-redes e auditar VNets sem a proteção contra DDoS habilitada; integre as verificações de política ao CI/CD.

Justificativa: Previne desvios de configuração (drift), impõe barreiras de proteção (guardrails) em escala e torna os padrões seguros repetíveis para cargas de trabalho futuras.

← Gerenciamento de Identidade e Acesso · Todos os domínios · Segurança de Computação →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →