APRENDER. PRATICAR. EVOLUIR.1. Desenhar o caminho antes de alterar a regra
Começa por um fluxo concreto: origem, destino, protocolo, porta e sentido de retorno. Numa firewall central, a existência do recurso não prova que o tráfego o atravessa. Network Firewall precisa de receber os dois sentidos no mesmo endpoint; appliance mode no attachment da VPC de inspeção e rotas coerentes são parte do desenho com Transit Gateway. A seguir, observa a passagem entre motores: uma ação stateless Pass termina a inspeção, enquanto Forward to stateful rules permite continuar no motor stateful. Num diagnóstico, mudar uma assinatura de aplicação sem confirmar este percurso pode consumir a janela sem tocar na causa. Regista uma hipótese por camada e a observação que a pode refutar.
2. Delimitar a origem e o critério de correspondência
Uma lista de domínios pode estar correta e não abranger a origem esperada. HOME_NET por omissão representa a VPC da firewall; um desenho central precisa de declarar as outras redes abrangidas. A lista usa SNI para HTTPS e Host para HTTP. Isto não é uma consulta DNS externa nem demonstra, por si só, que o IP pertence ao parceiro. Numa revisão de integração, separa o nome apresentado, a identidade autenticada e o caminho autorizado. Pede à equipa que explique qual destes requisitos cada controlo demonstra. Para a passagem a produção, inclui uma origem abrangida, outra que deveria ser abrangida e um destino que deve ser recusado. Estes ensaios autorizados verificam a fronteira que a política pretende criar.
3. Ler a ordem que o motor realmente aplica
No modo action order, a ação tem precedência sobre priority: pass é avaliada antes de drop. Não uses apenas a posição visual ou o número para explicar um resultado. Em strict order, os grupos seguem prioridade crescente e as regras seguem a sequência definida dentro de cada grupo. A ação por omissão também faz parte da política. Se Drop all descarta o SYN, uma regra que espera SNI não chega a observar ClientHello. O desenho tem de permitir a fase necessária para identificar o protocolo e bloquear o restante tráfego segundo os requisitos. O exercício local abaixo classifica observações sintéticas de encaminhamento. Não interpreta pacotes, não executa Suricata e não substitui testes da política real.
4. Distinguir bytes entregues de bytes inspecionados
WAF observa apenas o conteúdo que o serviço lhe encaminha dentro dos limites aplicáveis. Num ALB, o limite do corpo é 8 KB; a opção de chegar a 64 KB noutros serviços não deve ser transposta para este desenho. Continue avalia a parte disponível. Match considera o excesso uma correspondência, mas a ação da regra continua relevante: Count não se transforma em Block. Se o pedido for autorizado, pode chegar completo à aplicação. Num upload operacional de 24 KB, a aceitação precisa de demonstrar a validação integral exigida antes do processamento, através de um desenho suportado. Um teste de entrega bem-sucedido só prova entrega. Regista tamanho, caminho, mecanismo de validação e resultado esperado antes de aceitar o fluxo.
5. Confirmar a configuração efetiva do compute
No IMDS, distingue default, valor efetivo e enforcement. O valor de lançamento tem precedência sobre o default da conta, que precede a configuração da AMI; enforcement de IMDSv2 é avaliado depois. Um template com optional pode falhar quando a conta exige tokens. Mudar apenas o default não modifica instâncias existentes. Planeia a descoberta da frota e valida compatibilidade antes de alterar opções. Em contentores, um hop limit de 1 pode impedir a resposta PUT de chegar ao consumidor, mesmo quando o host obtém tokens. Investiga esse percurso sem reduzir automaticamente a exigência de IMDSv2. O critério de fecho deve incluir a configuração observada em instâncias representativas e o funcionamento dos agentes que dependem de metadata.
6. Converter controlos em aceitação operacional
Para Inspector em modo exclusivamente agent-based, confirma que a instância é gerida por SSM e fornece inventário. Um agente instalado não prova execução, conectividade ou permissões suficientes. A ausência de findings precisa de ser lida juntamente com cobertura e momento da última análise. No cenário de fim de semana, prepara uma matriz com origem, controlo, observação, responsável e condição de reversão. O gestor técnico coordena networking, segurança, aplicação e RUN para que cada equipa saiba o que deve demonstrar. Resume ao sponsor o que passou e o que continua por demonstrar. A regra prática desta aula é percorrer as dependências por ordem: caminho, âmbito, avaliação, observação e aceitação. Isso evita usar um estado administrativo como substituto de funcionamento comprovado.
# Original diagnostic model for fictional observations, not a firewall emulator.
# No credentials, network calls, or AWS changes.
def gaps(row):
missing = []
if row["outbound_endpoint"] != row["return_endpoint"]:
missing.append("asymmetric")
if row["stateless_action"] != "forward":
missing.append("not-forwarded")
if not row["source_in_scope"]:
missing.append("source-scope")
return missing
baseline = dict(outbound_endpoint="a", return_endpoint="a",
stateless_action="forward", source_in_scope=True)
assert gaps(baseline) == []
assert gaps({**baseline, "return_endpoint": "b"}) == ["asymmetric"]
assert gaps({**baseline, "stateless_action": "pass"}) == ["not-forwarded"]
assert gaps({**baseline, "source_in_scope": False}) == ["source-scope"]
assert gaps({**baseline, "return_endpoint": "b", "source_in_scope": False}) == ["asymmetric", "source-scope"]
print("five path-scope cases passed; no gaps is not proof of security")
Um piloto numa VPC passa, mas a segunda tem retorno assimétrico e falta em HOME_NET; a expansão aguarda correção e ensaio representativo.
Armadilhas comuns
Pass stateless como continuação; nome como identidade; Count como Block; entrega como inspeção; default como alteração de toda a frota.
Tópicos relacionados: Telemetria e âmbito de investigação · Passagem a operação e critérios de aceitação
A proteção só sustenta a decisão quando o percurso, a população e os limites de inspeção foram demonstrados.
Referência: Network Firewall rule actions · SCS-C03