Pular para o conteúdo principal

Laboratório Técnico: Create and implement Azure Firewall Manager policies

Questões​

Questão 1 — Múltipla Escolha​

Uma organização mantém uma Firewall Policy pai chamada policy-global com regras de rede e de aplicação que se aplicam a todos os ambientes. Uma equipe de desenvolvimento cria uma política filha chamada policy-dev que herda de policy-global. O engenheiro responsável pela equipe de desenvolvimento deseja adicionar uma regra na policy-dev que permita tráfego que a policy-global nega explicitamente. Qual é o comportamento esperado?

A) A regra de allow na policy-dev prevalece sobre a regra de deny na policy-global porque políticas filhas têm precedência sobre políticas pai.

B) As regras da política pai são avaliadas antes das regras da política filha; portanto, a regra de deny na policy-global bloqueará o tráfego antes que a regra de allow na policy-dev seja alcançada.

C) O Azure Firewall Manager detecta o conflito e desabilita automaticamente a regra conflitante na política filha até que a inconsistência seja resolvida manualmente.

D) A regra de allow na policy-dev é avaliada primeiro porque políticas filhas são mais específicas e o Azure Firewall prioriza especificidade sobre herança.

Questão 2 — Cenário Técnico​

Uma empresa usa o Azure Firewall Manager para gerenciar firewalls em uma topologia hub-and-spoke. O administrador precisa bloquear o acesso a uma categoria de URLs maliciosas em todos os firewalls gerenciados, mas também permitir exceções específicas para um conjunto de domínios que estão incorretamente classificados. A política base já contém regras de aplicação para tráfego geral.

policy-base (pai)
  └── Regra de aplicação: block-malicious
        Destino: Web categories = Malicious
        Ação   : Deny

policy-regional (filha de policy-base)
  └── Regra de aplicação: allow-exception
        Destino: legitimate-partner.com
        Ação   : Allow

Qual é o comportamento resultante para requisições ao domínio legitimate-partner.com?

A) O domínio será permitido porque a regra de allow na política filha é avaliada antes das regras herdadas da política pai.

B) O domínio será bloqueado porque as regras da política pai são avaliadas primeiro e a regra block-malicious corresponde ao tráfego antes que a exceção da política filha seja alcançada.

C) O comportamento depende da prioridade numérica atribuída às coleções de regras; sem ver os números de prioridade, não é possível determinar o resultado.

D) O domínio será permitido porque regras de allow sempre têm precedência sobre regras de deny quando ambas correspondem ao mesmo destino, independentemente da origem da política.

Questão 3 — Múltipla Escolha​

Ao criar uma Firewall Policy no Azure Firewall Manager, um engenheiro precisa decidir entre usar Rule Collections organizadas em Rule Collection Groups e entender como a prioridade entre eles afeta a avaliação. Qual afirmação descreve corretamente a hierarquia de avaliação dentro de uma única Firewall Policy?

A) As regras são avaliadas na ordem: tipo de regra (DNAT, rede, aplicação) primeiro, e dentro de cada tipo, por prioridade do Rule Collection Group e depois por prioridade da Rule Collection.

B) As regras são avaliadas exclusivamente pela prioridade numérica atribuída a cada regra individualmente, sem considerar o agrupamento em Rule Collections ou Rule Collection Groups.

C) Os Rule Collection Groups são avaliados por prioridade, mas dentro de cada grupo todas as Rule Collections são avaliadas simultaneamente, e a ação mais restritiva prevalece.

D) As Rule Collections são avaliadas por prioridade global entre todos os grupos, sem hierarquia entre Rule Collection Groups e Rule Collections individuais.

Questão 4 — Cenário Técnico​

Um administrador cria uma Firewall Policy Premium associada a um Azure Firewall Premium e habilita a inspeção TLS. Para que a inspeção funcione, ele configura um certificado CA intermediário armazenado no Azure Key Vault. Após a configuração, ele verifica que conexões HTTPS para alguns destinos continuam sem inspeção, enquanto outras são inspecionadas normalmente.

Qual é a causa mais provável para esse comportamento seletivo?

A) O Azure Firewall só inspeciona conexões TLS quando o destino está listado explicitamente em uma regra de aplicação com a opção de inspeção TLS habilitada na coleção de regras.

B) Alguns destinos estão na lista de bypass de inspeção TLS configurada na política, que permite excluir categorias ou FQDNs específicos da inspeção sem desabilitá-la globalmente.

C) A inspeção TLS falha silenciosamente para destinos que utilizam certificate pinning, e o Azure Firewall os trata como tráfego permitido sem inspeção para evitar falsos bloqueios.

D) O certificado CA intermediário não foi distribuído para todos os clientes; destinos cujos clientes não confiam no certificado intermediário têm suas conexões ignoradas pelo mecanismo de inspeção.

Questão 5 — Verdadeiro ou Falso​

Uma Firewall Policy do tipo Standard pode ser convertida para o tipo Premium diretamente no portal do Azure, permitindo habilitar recursos como inspeção TLS e IDPS em firewalls existentes sem necessidade de recriar a política ou o firewall associado.

Gabarito e Explicações​

Gabarito — Questão 1​

Resposta: B

Explique:

  • No modelo de herança do Azure Firewall Manager, as regras da política pai são sempre avaliadas antes das regras da política filha. Isso garante que os administradores centrais mantenham controle efetivo sobre as políticas base. Uma política filha pode adicionar regras, mas não pode contornar ou sobrescrever decisões já tomadas pela política pai.
  • A alternativa A inverte a hierarquia: a especificidade da política filha não concede precedência de avaliação. A ordem é determinada pela posição na árvore de herança, não pelo escopo das regras.
  • A alternativa C descreve um comportamento inexistente: o Firewall Manager não detecta conflitos automaticamente nem desabilita regras conflitantes. A configuração é aceita, mas o resultado da avaliação pode surpreender quem não entende a ordem de avaliação.
  • A consequência prática de escolher A ou D seria assumir que equipes locais podem criar exceções às políticas corporativas, o que invalida o modelo de governança centralizada do Firewall Manager.

Gabarito — Questão 2​

Resposta: B

Explique:

  • A ordem de avaliação entre política pai e filha é determinística: as regras da política pai são avaliadas primeiro. A regra block-malicious na policy-base corresponde ao tráfego para legitimate-partner.com (se classificado como malicioso pela categoria de web), e a ação Deny é aplicada antes que a regra allow-exception na policy-regional seja considerada.
  • A alternativa A é o erro mais comum nesse tema: assumir que a política filha, por ser mais específica ou mais recente, tem precedência sobre a pai. Isso contradiz diretamente o modelo de herança do Firewall Manager.
  • A alternativa C seria verdadeira se ambas as regras estivessem na mesma política, onde a prioridade numérica das coleções determinaria a avaliação. Mas em políticas pai/filha, a hierarquia de herança supera a prioridade numérica.
  • A alternativa D descreve um comportamento inexistente: o Azure Firewall não possui lógica de "allow vence deny" baseada na ação isoladamente; a primeira regra correspondente encerra a avaliação.

Gabarito — Questão 3​

Resposta: A

Explique:

  • Dentro de uma única Firewall Policy, a avaliação segue uma hierarquia em dois níveis: primeiro, o tipo de regra (DNAT antes de rede, rede antes de aplicação); depois, dentro de cada tipo, as regras são avaliadas pela prioridade do Rule Collection Group (menor número = maior prioridade) e, dentro de cada grupo, pela prioridade da Rule Collection.
  • A alternativa B nega a estrutura de agrupamento, que é central no design do Firewall Manager para organização e delegação de políticas. Ignorar os grupos tornaria inviável a gestão de políticas complexas com múltiplas equipes.
  • A alternativa C introduz o conceito de avaliação simultânea com ação mais restritiva, que não existe no Azure Firewall: a primeira regra correspondente encerra a avaliação; não há comparação de ações entre múltiplas correspondências.
  • A alternativa D nega a hierarquia entre grupos e coleções, o que tornaria o conceito de Rule Collection Group irrelevante, contradizendo o propósito dessa estrutura no produto.

Gabarito — Questão 4​

Resposta: B

Explique:

  • O Azure Firewall Manager permite configurar uma lista de bypass de inspeção TLS dentro da Firewall Policy Premium. Essa lista especifica FQDNs, categorias de web ou intervalos de IP que devem ser excluídos da inspeção TLS, mesmo quando a inspeção está globalmente habilitada. Isso é usado para destinos como serviços financeiros, saúde ou parceiros que não aceitam man-in-the-middle, sem precisar desabilitar a inspeção para todo o tráfego.
  • A alternativa A descreve um comportamento incorreto: a inspeção TLS no Azure Firewall Premium é aplicada ao tráfego que corresponde a regras de aplicação que permitem o tráfego; não requer uma opção por regra individual para ser ativada.
  • A alternativa C descreve um comportamento que o Azure Firewall não implementa: não há lógica automática de detecção de certificate pinning com fallback para permitir sem inspeção. Conexões com certificate pinning podem falhar se o certificado intermediário for inserido.
  • A alternativa D descreve uma causa legítima de falha de TLS do ponto de vista do cliente, mas não explicaria por que o firewall inspeciona algumas conexões e ignora outras seletivamente; esse sintoma é característico de bypass configurado.

Gabarito — Questão 5​

Resposta: Falso

Explique:

  • Não é possível converter uma Firewall Policy Standard em Premium diretamente. As políticas Standard e Premium são tipos distintos e imutáveis após a criação. Para usar recursos Premium (inspeção TLS, IDPS, Web Categories), é necessário criar uma nova Firewall Policy do tipo Premium e associá-la a um Azure Firewall Premium.
  • Essa limitação tem impacto operacional relevante em migrações: tanto a política quanto o firewall precisam ser do tipo Premium para que os recursos exclusivos funcionem. Uma política Premium associada a um firewall Standard, ou vice-versa, não habilita os recursos Premium.
  • O equívoco comum é extrapolar o comportamento de outros recursos do Azure que suportam upgrade in-place (como SKUs de IP público ou VPN Gateway) para as Firewall Policies, onde essa operação não existe.