Amazon ANS-C01: Segurança de Rede e Conformidade — Guia de estudos

By Laurynas Brazys · 3 August 2026 · #amazon #ans-c01 #certification #exam-prep #study-guide

Faz parte do AWS Advanced Networking Specialty ANS-C01 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.

Conceito principal

A segurança de rede na AWS é em camadas: controles de perímetro, controles no nível da VPC, controles no nível do host e da aplicação, e monitoramento/inspeção. No perímetro da VPC, você usa security groups (firewalls virtuais stateful, centrados no host e aplicados a ENIs) e network ACLs (filtragem stateless no nível da sub-rede, avaliada pelo número da regra) para aplicar controles de acesso mais amplos. Os security groups rastreiam o estado da conexão, de modo que um fluxo de resposta estabelecido é permitido automaticamente, tornando-os ideais para permitir conexões iniciadas pelo cliente para pods ou instâncias. As NACLs exigem entradas de permissão (allow) explícitas em ambas as direções ou regras complementares para o tráfego de retorno; elas são avaliadas em ordem crescente do número da regra e, portanto, são apropriadas para um reforço de segurança (hardening) amplo no nível da sub-rede, como eliminar intervalos CIDR inteiros ou aplicar rotas de escape efêmeras para listas de bloqueio de emergência.

A inspeção e a aplicação centralizada de políticas são fornecidas por serviços gerenciados e autogerenciados. O AWS Network Firewall pode implementar proteções stateful do tipo Suricata, filtragem de listas de domínios e assinaturas no estilo de prevenção de intrusão no perímetro da VPC com políticas de firewall e grupos de regras explícitos. O Web Application Firewall (AWS WAF) é focado em aplicações para proteção na camada HTTP(S) e se integra com o Application Load Balancer, Amazon CloudFront e API Gateway para aplicar proteções OWASP, regras baseadas em taxa (rate-based rules) e verificações de cabeçalhos personalizados. As proteções contra DDoS são fornecidas pelo AWS Shield (o Standard é automático e gratuito; o Shield Advanced oferece engenharia de tráfego, proteção de custos e integração com o WAF para mitigação na camada de aplicação). Serviços de detecção como o Amazon GuardDuty analisam VPC Flow Logs, logs de DNS e CloudTrail para expor atividades de reconhecimento (reconnaissance), varreduras de portas (port scans) e comportamento de instâncias comprometidas.

Visibilidade e captura de pacotes completam o modelo. Os VPC Flow Logs registram metadados de fluxo por ENI e podem ser entregues ao CloudWatch Logs, Amazon S3 ou Kinesis Data Firehose para análise com o Athena. Para captura completa de pacotes ou inspeção mais profunda, o Traffic Mirroring permite espelhar o tráfego de uma ENI para um appliance de IDS/captura de pacotes (um sensor EC2 com uma ENI espelhada ou um alvo de Network Load Balancer) onde ferramentas como Suricata ou Zeek são executadas. Juntos, esses controles permitem uma postura de defesa em profundidade (defense-in-depth), na qual prevenção, detecção e análise forense estão presentes.

Principais serviços e configuração

Vários serviços da AWS são centrais para a segurança de rede e cada um tem padrões de configuração e APIs específicos que você deve conhecer:

• Security Groups
• Network ACLs (NACLs)
• AWS Network Firewall
• AWS WAF
• AWS Shield (Standard e Advanced)
• Amazon GuardDuty
• VPC Flow Logs
• Traffic Mirroring

Os security groups são configurados por ENI através da API do EC2 ou do Console; para adicionar uma regra de entrada (ingress), use

undefined

. Lembre-se de usar CIDRs com o menor privilégio possível e de anexar SGs separados para load balancers e pods de backend para evitar regras excessivamente permissivas. Crie NACLs via

undefined

e adicione entradas numeradas com

undefined

, especificando rule-number, rule-action, protocol, port-range e a flag egress.

O AWS Network Firewall usa grupos de regras (rule groups) e políticas de firewall (firewall policies) vinculados a um recurso de firewall criado em uma sub-rede da VPC. Use

undefined

para definir regras stateless ou stateful,

undefined

para compô-las e

undefined

para implantar. Escolha grupos de regras stateful para inspeção ciente do protocolo e regras de assinatura compatíveis com Suricata; use regras stateless para filtragem de primeira passagem com altíssima performance.

O AWS WAF anexa uma Web ACL a um ALB e pode aplicar correspondências de conjuntos de IPs (IP sets), correspondência de strings em cabeçalhos ou regras baseadas em taxa (rate-based). Use

undefined

e especifique regras que verificam cabeçalhos (por exemplo, para bloquear requisições que não contenham um cabeçalho personalizado que você injeta em sua porta de entrada confiável). O AWS Shield Advanced é habilitado por conta e fornece acesso à equipe de resposta a DDoS e proteções adicionais para recursos registrados no Shield Advanced.

Habilite o GuardDuty via

undefined

e integre os achados (findings) com o CloudWatch Events ou o EventBridge para automação. Para telemetria, crie VPC Flow Logs via

undefined

. Para captura de pacotes, use

undefined

,

undefined

e

undefined

para direcionar o tráfego espelhado para uma ENI de appliance ou um NLB.

Padrões de design e trade-offs

A criptografia de ponta a ponta com mTLS (mutual TLS), em que o load balancer não deve encerrar o TLS, exige um padrão de pass-through de Camada 4. Use um Network Load Balancer (NLB) na frente dos pods de backend para que a sessão TLS seja negociada diretamente com os endpoints do serviço. No Kubernetes no EKS, implante um Service do tipo LoadBalancer com um NLB como backend e registre os pods como targets por IP; o AWS Load Balancer Controller ou as anotações de Service legadas garantem que o tipo de target seja IP e que o protocolo do target group seja TCP. Para a alta concorrência característica do gRPC e de muitas conexões HTTP/2 de longa duração, o NLB preserva os IPs de origem e impõe uma sobrecarga menor por conexão do que os proxies L7. Se a terminação TLS no ALB for necessária (por exemplo, para roteamento baseado em URL), você deve encerrar o TLS no ALB usando um certificado do ACM e, em seguida, encaminhar para os backends; preserve o IP do cliente usando o cabeçalho X-Forwarded-For (ALB) ou usando um NLB compatível com Proxy Protocol v2 para backends que precisam do IP de origem original na L4.

Para arquiteturas escaláveis multi-account e multi-VPC onde serviços centrais são necessários, o PrivateLink (AWS VPC Endpoint Services) é a escolha mais segura e escalável. Exponha os serviços centrais da VPC de serviços compartilhados como um serviço de endpoint do AWS PrivateLink. Cada conta consumidora cria um interface VPC endpoint para esse serviço; o proprietário do serviço pode exigir a aceitação do endpoint e aplicar controles baseados em security groups nas ENIs do endpoint. Este modelo mantém o tráfego na rede da AWS, evita os limites de escala do peering e fornece segurança granular por consumidor. O Transit Gateway com segmentação e o Network Firewall podem ser usados para trânsito em nível de rede e inspeção centralizada, mas é mais apropriado quando é necessária conectividade totalmente roteada com políticas de roteamento complexas, em vez de isolamento por serviço.

Ao diagnosticar o uso de largura de banda em múltiplas VIFs no Direct Connect, priorize primeiro os metadados: habilite e consulte os VPC Flow Logs agregados no S3 ou CloudWatch e analise via Athena para mapear fluxos de IP de alto volume para VPCs e subnets específicas. Complemente os flow logs com as métricas do CloudWatch para as interfaces virtuais do Direct Connect e, se precisar de inspeção no nível do payload ou de protocolos heterogêneos, implante o Traffic Mirroring para capturar pacotes para um IDS baseado em EC2. O Traffic Mirroring é pesado e gera custos; use-o apenas para sessões/janelas em que os flow logs e os achados do GuardDuty forem insuficientes.

Armadilhas comuns e critérios de decisão

Um erro comum é depender apenas de security groups para a aplicação de regras de perímetro amplas e não usar NACLs ou o Network Firewall onde a inspeção em nível de sub-rede ou stateful é necessária. Os security groups são por ENI e fáceis de gerenciar, mas não escalam bem como um plano de controle centralizado para muitas VPCs em contas diferentes; use o AWS Firewall Manager para centralizar as regras do WAF e do Network Firewall entre contas. Outra armadilha é terminar o TLS no load balancer sem levar em conta a preservação do IP do cliente; o ALB insere cabeçalhos X-Forwarded-For, mas o logging da aplicação deve ler explicitamente esse cabeçalho e a confiança deve ser estabelecida (por exemplo, apenas o ALB deve enviá-lo). Para uma garantia estrita de que apenas o Global Accelerator pode alcançar um ALB, evite depender apenas de DNS; em vez disso, restrinja os listeners do ALB por meio de security groups às faixas de IP publicadas do accelerator (automatize as atualizações com o ip-ranges.json ou managed prefix lists) ou use um ALB apenas interno sempre que possível e coloque-o atrás do endpoint do accelerator.

Decida entre o PrivateLink e o Transit Gateway ponderando a granularidade do serviço versus o roteamento full-mesh. O PrivateLink fornece controle de acesso por serviço com filtragem no nível de security group e escala sem sobrecarregar as tabelas de roteamento; o Transit Gateway é necessário quando você precisa de conectividade baseada em rotas entre muitas VPCs e redes on-premises e quando requer inspeção de pacotes centralizada com o AWS Network Firewall. Para alta taxa de transferência, favoreça regras stateless do Network Firewall no perímetro combinadas com grupos stateful direcionados para fluxos críticos; o processamento stateless escala, mas perde a consciência do protocolo.

Problema Prático: Cenário de Caso de Uso

Empresa fictícia: Meridian Payments — desafio: habilitar uma API de pagamentos baseada em gRPC no EKS que exige mTLS (mutual TLS) de ponta a ponta (sem terminação de TLS no caminho), suportar milhares de conexões simultâneas de longa duração, autoscaling de pods e identificação dos IPs de origem do cliente para logging e detecção de fraudes.

1. Abordagem: Implantar um Amazon Network Load Balancer na frente do Service do EKS configurado com o tipo de destino (target type) IP para que as ENIs dos pods sejam registradas diretamente nos target groups do NLB. Use o AWS Load Balancer Controller para criar um Service apoiado por um NLB com anotações para garantir que o protocolo do target group seja TCP na porta 443 e que os health checks usem TCP. Termine o mTLS nos pods de backend; configure o Istio ou uma biblioteca TLS em um sidecar se precisar de rotação padronizada de certificados, usando Kubernetes Secrets preenchidos a partir do AWS Certificate Manager Private Certificate Authority ou do AWS Secrets Manager. Preserve os IPs do cliente, pois o NLB preserva o IP de origem; garanta que as regras de networkPolicy e security group do pod de backend permitam as faixas de origem do NLB/clientes. Use HPA e Cluster Autoscaler para escalar os pods; garanta que o deregistration delay do target group seja ajustado para permitir a drenagem de conexões (graceful connection draining).

2. Abordagem de observabilidade e forense: Habilite os VPC Flow Logs para a VPC do EKS para o CloudWatch Logs e agregue no S3 via Kinesis Firehose para retenção e consultas com o Athena, mapeando fluxos de alta largura de banda. Habilite o GuardDuty para detecção de anomalias nos fluxos da VPC e DNS. Se uma inspeção de pacotes mais profunda for necessária durante janelas de suspeita de fraude, crie sessões de Traffic Mirror nas ENIs problemáticas para um sensor EC2 executando o Suricata; gerencie os filtros do espelhamento para capturar apenas o tráfego relevante para limitar o custo.

Justificativa da AWS: O NLB fornece passagem L4 (pass-through) para que o TLS e o mTLS sejam negociados de ponta a ponta e o backend veja o verdadeiro IP do cliente, o que satisfaz o requisito de que o tráfego não seja descriptografado por proxies intermediários e que a análise de logging/fraude veja a origem original. Registrar pods por IP e usar o AWS Load Balancer Controller se integra com o autoscaling do EKS. VPC Flow Logs, GuardDuty e Traffic Mirroring fornecem visibilidade gradual, desde metadados até a captura completa de pacotes, para conformidade e resposta a incidentes escaláveis e de custo-benefício.

← Balanceamento de Carga e Gerenciamento de Tráfego · Todos os domínios · Entrega de Conteúdo e Redes de Borda →

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

Navegar Amazon →