Amazon SCS-C02: Segurança de Borda e de Aplicações — Guia de estudos

By Laurynas Brazys · 24 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

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

Restrição Geográfica do CloudFront e Bloqueio em Nível de País

O CloudFront oferece dois mecanismos para bloquear o tráfego por país, e a escolha entre eles é importante para o custo e a funcionalidade. O recurso integrado de restrição geográfica (também chamado de geobloqueio) é configurado diretamente na distribuição e avalia as requisições na borda (edge) com base em uma lista de permissões (allowlist) ou de bloqueio (blocklist) de países, derivada do IP do visualizador. É gratuito, não requer avaliação de regras e retorna HTTP 403 antes que qualquer busca na origem ocorra. Para cenários simples de conformidade — “bloquear visitantes do país X” — esta é a opção mais barata e simples.

A alternativa é uma declaração de correspondência geográfica do WAF (WAF geo match statement), que é mais flexível: você pode combinar correspondências de país com caminhos de URI, cabeçalhos, limites de taxa ou negá-los (“permitir o país A apenas para /admin”). O WAF é necessário quando a lógica é condicional; a restrição geográfica por si só não consegue expressar “bloquear o país X apenas para um caminho específico”. Escolha a restrição geográfica nativa quando o requisito for um bloqueio de país simples e direto e você quiser evitar o custo por requisição do WAF.

URLs Assinadas vs. Cookies Assinados para Conteúdo Privado

O CloudFront suporta duas maneiras de servir conteúdo privado autorizado, mantendo a origem (bucket S3, ALB ou origem de Mídia) oculta por trás de um controle de acesso à origem (origin access control) ou de um cabeçalho personalizado:

• URLs Assinadas: cada URL carrega uma assinatura e uma política. Ideal para o download de um único arquivo ou quando você precisa de controle de acesso por arquivo (por exemplo, um link único para um instalador de software).

• Cookies Assinados: o cliente recebe um conjunto de cookies CloudFront-Policy, CloudFront-Signature e CloudFront-Key-Pair-Id uma vez pelo seu serviço de autenticação. Todas as requisições subsequentes para padrões de caminho correspondentes são autorizadas automaticamente, sem a necessidade de reescrever as URLs.

Para streaming de vídeo HLS, onde uma única sessão de reprodução busca milhares de segmentos .ts referenciados por um manifesto, os cookies assinados são dramaticamente mais simples. Reescrever cada URL de segmento no manifesto com uma URL assinada distinta é possível, mas adiciona latência e complexidade. Defina o cookie depois que o assinante se autenticar em seu repositório de usuários interno, com escopo para o padrão de caminho do streaming.

Uma política canônica para um cookie assinado com curinga (wildcard) se parece com isto:

{
  "Statement": [{
    "Resource": "https://d123.cloudfront.net/videos/*",
    "Condition": {
      "DateLessThan": {"AWS:EpochTime": 1735689600},
      "IpAddress":    {"AWS:SourceIp": "203.0.113.0/24"}
    }
  }]
}

Combine isso com um controle de acesso à origem (OAC) ou um cabeçalho personalizado secreto validado pelo WAF na origem, para que os usuários não possam contornar o CloudFront e acessar a origem diretamente.

AWS WAF: Regras Gerenciadas, ATP e Regras Baseadas em Taxa

Anexe a Web ACL à distribuição do CloudFront em vez de a um ALB regional quando a carga de trabalho estiver por trás do CloudFront. A anexação na borda (edge) termina requisições maliciosas em um das centenas de POPs — mais perto do atacante — o que reduz a carga na origem durante um DDoS e diminui o egresso da origem, porque o tráfego bloqueado nunca atravessa sua VPC. Anexar o WAF apenas ao ALB significa que a inundação volumétrica ainda alcança o load balancer Regional e consome LCUs, e ataques entre Regiões são tratados por uma única Região em vez da rede de borda global.

Grupos de regras chave para combinar:

• Conjuntos de regras gerenciadas da AWS: AWSManagedRulesCommonRuleSet (estilo OWASP top-10), AWSManagedRulesKnownBadInputsRuleSet e AWSManagedRulesAmazonIpReputationList oferecem uma cobertura ampla com ajuste quase zero.

• Prevenção de Tomada de Controle de Conta (ATP): AWSManagedRulesATPRuleSet inspeciona o endpoint de login que você designa, rastreia padrões de credential stuffing, verifica as credenciais enviadas em um banco de dados de credenciais comprometidas e bloqueia bots que reutilizam senhas vazadas. Configure-o com o caminho de login exato e os nomes dos campos do corpo JSON para o nome de usuário e a senha.

• Regras baseadas em taxa: limitam o número de requisições de um único IP em uma janela de 5 minutos (por exemplo, 2.000 requisições). Defina o escopo delas por URI ou método para que a raspagem (scraping) de /search não afete a navegação anônima de /. As regras de taxa mitigam ataques volumétricos da Camada 7 e enumeração por força bruta.

Um bloco de regra WAF resumido:

Rules:
  - Name: RateLimitLogin
    Priority: 1
    Action: { Block: {} }
    Statement:
      RateBasedStatement:
        Limit: 500
        AggregateKeyType: IP
        ScopeDownStatement:
          ByteMatchStatement:
            SearchString: /api/login
            FieldToMatch: { UriPath: {} }
            PositionalConstraint: STARTS_WITH
            TextTransformations: [{ Priority: 0, Type: LOWERCASE }]

Certificados do ACM, Validação por DNS e o CloudFront

Para o CloudFront, o certificado deve ser provisionado no ACM em us-east-1 (N. Virginia), independentemente de onde sua origem resida — este é um requisito rígido porque o CloudFront é um serviço global que lê certificados dessa Região. Serviços regionais como o ALB leem da própria Região do ALB.

Sempre use a validação por DNS com um registro CNAME no Route 53 para qualquer certificado público que você queira renovar automaticamente. O ACM renova automaticamente certificados validados por DNS, desde que o CNAME de validação permaneça publicado; o Route 53 torna isso trivial (o console oferece a opção “Criar registros no Route 53” durante a solicitação). A validação por e-mail, por outro lado, envia uma confirmação para cinco endereços no domínio (admin@, administrator@, hostmaster@, postmaster@, webmaster@) mais o contato do WHOIS. Essas caixas de e-mail frequentemente não existem ou são colocadas em quarentena por filtros de e-mail corporativos, fazendo com que as renovações falhem 60 dias antes da expiração e causem interrupções evitáveis. Não há como automatizar os cliques de validação por e-mail.

O padrão de renovação correto para ALBs multi-regionais é: solicitar um certificado ACM validado por DNS por Região, publicar o CNAME de validação no Route 53 uma vez, anexar o certificado ao listener do ALB e deixar o ACM cuidar da renovação e da reimplementação. A intervenção humana termina na emissão.

DNSSEC e Route 53

Habilite a assinatura DNSSEC na zona hospedada do Route 53 para prevenir falsificação de DNS (DNS spoofing) e envenenamento de cache (cache poisoning) contra seu domínio. O Route 53 gerencia a KSK no KMS (chave ECC assimétrica em us-east-1); você deve publicar o registro DS no seu registrador de domínio (registrar). Note que a assinatura DNSSEC protege a resolução da sua zona — ela não criptografa o tráfego DNS (isso é DoH/DoT) e não afeta o TLS do CloudFront.

Cabeçalhos de Resposta: Políticas versus Lambda@Edge

O CloudFront não injeta automaticamente cabeçalhos de segurança como Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options ou Content-Security-Policy. Se sua origem não puder ser modificada (um site S3 legado, uma origem de terceiros), você tem duas opções:

• Política de cabeçalhos de resposta (Response headers policy): um recurso nativo e declarativo do CloudFront. Anexe uma política gerenciada ou personalizada a um comportamento de cache (cache behavior) para adicionar cabeçalhos HSTS, CORS, de segurança e personalizados. Esta deve ser a escolha padrão — sem código, sem cold starts, sem custo por invocação.

• Lambda@Edge (viewer response ou origin response): use quando precisar de lógica dinâmica, como variar nonces de CSP por requisição ou reescrever cabeçalhos com base em atributos da requisição. Troca a simplicidade pela flexibilidade e adiciona um custo por requisição.

A política gerenciada de cabeçalhos de resposta SecurityHeadersPolicy cobre a linha de base comum em um único anexo.

Armadilhas Comuns Explicadas

Solicitar certificados públicos do ACM com validação por e-mail é frágil precisamente porque a renovação depende de humanos lendo e-mails enviados para endereços genéricos que a maioria das organizações não monitora ou que são direcionados para o spam. A validação por DNS com o Route 53 remove completamente a intervenção humana.

Anexar o WAF apenas ao ALB parece equivalente na teoria, mas força o tráfego de ataque para dentro da sua Região e consome a capacidade do ALB. O WAF anexado na borda (edge) no CloudFront bloqueia em centenas de POPs, de modo que uma inundação distribuída é absorvida globalmente e a saída de dados (egress) da origem permanece baixa — o que é crítico durante um DDoS.

Assumir que o CloudFront adiciona cabeçalhos de segurança automaticamente leva a falhas em testes de penetração. A distribuição atua como proxy para quaisquer cabeçalhos que a origem envia; você deve anexar explicitamente uma política de cabeçalhos de resposta ou uma função Lambda@Edge para injetar X-Frame-Options: DENY, HSTS e CSP.

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

Cenário: A Meridian Financial opera um portal de clientes distribuído globalmente e um portal de relatórios interno na AWS. O tráfego público é roteado através do Amazon CloudFront para Application Load Balancers para APIs dinâmicas e para origens S3 para relatórios privados; o DNS está no Route 53 e os certificados TLS são emitidos pelo AWS Certificate Manager (ACM).

Desafio: Atacantes estão realizando scraping e ataques de preenchimento de credenciais (credential stuffing) em contas de vários países, contornando o CloudFront ao acessar os endpoints da origem diretamente para baixar relatórios privados, causando sobrecarga na origem e exposição de dados.

Abordagem Recomendada:

1. Configure o CloudFront como o único ponto de entrada público e aplique a Restrição Geográfica (Geo Restriction) do CloudFront para bloquear os países de origem dos ataques; habilite o Origin Access Control (OAC) e restrinja as políticas de origem do S3/ALB para que apenas o CloudFront possa buscar o conteúdo da origem.
2. Sirva relatórios privados por usuário com URLs assinadas (signed URLs) do CloudFront (com TTL curto) em vez de cookies assinados (signed cookies), para que cada download seja autorizado e auditável individualmente.
3. Anexe o AWS WAF à distribuição do CloudFront usando as Regras Gerenciadas da AWS (AWS Managed Rules), habilite o AWS WAF Bot Control (proteção avançada contra ameaças) e crie regras baseadas em taxa (rate-based) e desafios CAPTCHA para mitigar o scraping e o preenchimento de credenciais.
4. Provisione certificados TLS no ACM (em us-east-1 para distribuições do CloudFront) usando a validação por DNS via Route 53 e publique registros Alias do Route 53 para a distribuição do CloudFront.
5. Habilite o DNSSEC na zona hospedada (hosted zone) do Route 53, habilite os logs de acesso do CloudFront e do WAF para o S3 e crie alarmes do CloudWatch e, opcionalmente, o AWS Shield Advanced para visibilidade e alertas de DDoS.

Justificativa: Forçar todo o tráfego através do CloudFront com OAC e WAF impõe o acesso à origem com privilégio mínimo (least-privilege), a Restrição Geográfica e as proteções baseadas em taxa/WAF barram o tráfego abusivo, as URLs assinadas fornecem autorização por objeto, e a validação ACM+DNS com DNSSEC garante a confiança do TLS e a integridade do DNS, de acordo com as melhores práticas da AWS.

Regras do AWS WAF e Integração com ALB e CloudFront

O AWS WAF é um firewall de Camada 7 que avalia requisições HTTP(S) em relação a uma Web ACL composta por regras ordenadas. Cada regra inspeciona atributos da requisição (URI, cabeçalhos, corpo, query string, IP de origem) e retorna uma ação de terminação (Allow, Block, Challenge, CAPTCHA) ou uma ação de não terminação (Count). As Web ACLs são anexadas a distribuições do CloudFront, Application Load Balancers, API Gateway, AppSync, grupos de usuários do Cognito e serviços do App Runner. Quando anexada ao CloudFront, a ACL é executada na borda (edge) e deve ser criada no escopo us-east-1 (Global); para o ALB, ela deve estar na mesma Região do load balancer.

Regras baseadas em taxa (rate-based) rastreiam o número de requisições provenientes de um único IP (ou de um cabeçalho de IP encaminhado, ou de uma chave agregada como uma combinação de URI + IP) em uma janela móvel de cinco minutos. Quando a contagem excede o limite configurado, a ação da regra é acionada até que a taxa caia novamente abaixo do limite. Como o AWS WAF atualiza continuamente a lista de infratores em segundos, as regras baseadas em taxa são a solução canônica para abusos de alto volume de um conjunto pequeno e rotativo de IPs — você não precisa fazer a curadoria manual de um conjunto de IPs, e a sobrecarga operacional é essencialmente zero após a implantação da regra inicial.

{
  "Name": "RateLimitPerIP",
  "Priority": 10,
  "Statement": {
    "RateBasedStatement": {
      "Limit": 2000,
      "AggregateKeyType": "IP"
    }
  },
  "Action": { "Block": {} },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "RateLimitPerIP"
  }
}

IP sets são listas reutilizáveis de intervalos CIDR referenciadas por regras com um IPSetReferenceStatement. Eles são o primitivo correto quando você tem uma lista de bloqueio/permissão determinística — por exemplo, endpoints de administração com restrição geográfica ou intervalos maliciosos conhecidos de feeds de inteligência de ameaças. Regras personalizadas (custom rules) combinam múltiplas declarações com operadores lógicos AndStatement, OrStatement e NotStatement, permitindo que você expresse condições como “bloquear requisições para /login de países que não sejam os EUA e que também não possuam um cabeçalho específico”.

CloudFront como uma Camada de Mitigação de DDoS e Proteção de Origem

O CloudFront absorve ataques volumétricos e de exaustão de estado na borda da AWS, muito antes que o tráfego chegue ao seu ALB ou à sua frota de EC2. Cada edge location executa o AWS Shield Standard automaticamente, fornecendo mitigação de ataques SYN flood e de reflexão sem custo adicional. Colocar o CloudFront na frente de um ALB reduz a superfície de ataque para a rede de borda e habilita WAF no escopo da borda, restrição geográfica e terminação TLS.

A mitigação só é eficaz se os atacantes não puderem contornar o CloudFront acessando o nome DNS do ALB diretamente. Dois mecanismos reforçam esse caminho. Primeiro, configure o CloudFront para injetar um cabeçalho de origem personalizado e secreto (por exemplo, X-Origin-Verify: <valor-aleatório>) e configure uma regra no listener do ALB que retorne 403 para qualquer requisição que não contenha exatamente esse valor no cabeçalho. Rotacione o segredo periodicamente através do AWS Secrets Manager. Segundo, restrinja o security group do ALB à lista de prefixos gerenciada pela AWS com.amazonaws.global.cloudfront.origin-facing, que contém os intervalos de IP da borda do CloudFront.

ALBListenerRule:
  Type: AWS::ElasticLoadBalancingV2::ListenerRule
  Properties:
    Actions:
      - Type: fixed-response
        FixedResponseConfig: { StatusCode: "403", ContentType: text/plain }
    Conditions:
      - Field: http-header
        HttpHeaderConfig:
          HttpHeaderName: X-Origin-Verify
          Values: ["!Ref OriginSecret"]
      - Field: http-header
        HttpHeaderConfig: { HttpHeaderName: X-Origin-Verify, Values: ["*"] }
    Priority: 1

Simplesmente anexar uma ACL do WAF ao ALB sem forçar o tráfego através do CloudFront deixa o endpoint do ALB publicamente resolvível. Atacantes que descobrem o nome DNS (através de logs de transparência de certificados, DNS histórico ou enumeração de subdomínios) podem atacá-lo diretamente, contornando todas as proteções de borda. Este é o erro de arquitetura mais comum em projetos “CloudFront + ALB”.

Métricas, Alarmes e Notificações do Shield Advanced

O Shield Advanced adiciona detecção aprimorada, acesso 24/7 à Shield Response Team, proteção de custos para escalabilidade durante ataques e visibilidade de ataques na camada de aplicação. No entanto, ele não envia e-mails ou SMS automaticamente quando um ataque ocorre. As notificações devem ser configuradas explicitamente através do CloudWatch.

O Shield Advanced publica a métrica DDoSDetected (valor 1 enquanto um ataque está em andamento) e as métricas DDoSAttackBitsPerSecond, DDoSAttackPacketsPerSecond e DDoSAttackRequestsPerSecond por recurso protegido no namespace AWS/DDoSProtection. Crie um alarme do CloudWatch em DDoSDetected >= 1 com um tópico SNS como a ação do alarme; o SNS então distribui (fan-out) para e-mail, SMS, chat ou um responder Lambda.

aws cloudwatch put-metric-alarm \
  --alarm-name ShieldDDoSDetected \
  --namespace AWS/DDoSProtection \
  --metric-name DDoSDetected \
  --statistic Maximum --period 60 --threshold 1 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --evaluation-periods 1 \
  --alarm-actions arn:aws:sns:us-east-1:111122223333:secops-alerts

Assumir que o Shield Advanced “simplesmente vai te enviar um e-mail” é um equívoco frequente — sem o alarme do CloudWatch mais a inscrição no SNS, o único sinal é o console do Shield e o evento no AWS Health Dashboard.

AWS Network Firewall com Bloqueio Automatizado por Lambda

O Network Firewall é um firewall stateful, anexado a uma VPC, de Camada 3 a 7, que inspeciona o tráfego que atravessa as tabelas de rotas de sub-redes. Sua política consiste em grupos de regras stateless e stateful; os grupos de regras stateful usam uma sintaxe compatível com Suricata. Como os grupos de regras são gerenciados por API, eles são alvos ideais para automação orientada a eventos.

Um padrão comum responde a achados (findings) do GuardDuty (por exemplo, UnauthorizedAccess:EC2/RDPBruteForce ou Backdoor:EC2/C&CActivity). O Security Hub agrega o achado, o EventBridge corresponde a um padrão de evento e invoca uma função Lambda, e a Lambda chama UpdateRuleGroup para inserir uma regra de descarte (drop) visando o IP infrator ou a ENI da instância comprometida.

def handler(event, _):
    ip = event["detail"]["findings"][0]["ProductFields"]["aws/guardduty/service/action/networkConnectionAction/remoteIpDetails/ipAddressV4"]
    new_rule = f'drop ip {ip} any -> any any (msg:"GD-block"; sid:{sid()}; rev:1;)'
    rg = nfw.describe_rule_group(RuleGroupArn=RG_ARN)
    rules = rg["RuleGroup"]["RulesSource"]["RulesString"] + "\n" + new_rule
    nfw.update_rule_group(
        RuleGroupArn=RG_ARN,
        UpdateToken=rg["UpdateToken"],
        RulesSource={"RulesString": rules})

O Network Firewall é a escolha correta quando você precisa bloquear tráfego bidirecional de/para uma instância EC2 ou um CIDR na borda da VPC — o WAF inspeciona apenas requisições HTTP destinadas a endpoints de Camada 7 suportados, portanto, não pode parar o tráfego C2 de saída ou protocolos não-HTTP.

Logging, Monitoramento e Implantação Segura com Count

Habilite o logging do WAF em cada Web ACL e transmita para o CloudWatch Logs, S3 ou Kinesis Data Firehose. Os logs incluem a regra correspondida, a ação, os cabeçalhos da requisição e (com regras de redação) os corpos higienizados. As requisições amostradas no console oferecem uma visão rápida, mas retêm apenas as últimas 3 horas e 100 amostras por regra; logs completos são necessários para auditoria e análise forense.

A ação Count é essencial para a implantação segura de regras. Implante novos grupos de regras gerenciadas (por exemplo, AWSManagedRulesCommonRuleSet ou o grupo Bot Control) com as substituições de ação de regra definidas primeiro como Count. Observe a métrica CountedRequests do CloudWatch e as entradas de log em busca de falsos positivos — tráfego legítimo que teria sido bloqueado. Somente após ajustar as exclusões, você deve mudar as ações para Block. Implantar regras gerenciadas diretamente com a ação Block, sem uma fase de Count, rotineiramente causa interrupções quando uma regra como SizeRestrictions_BODY bloqueia um endpoint legítimo de upload de arquivos grandes, ou quando CrossSiteScripting_BODY dispara em uma carga útil de um editor de rich-text. A remediação não é desabilitar o grupo inteiro, mas adicionar uma declaração de restrição de escopo (scope-down statement) ou uma substituição de ação de regra para a regra específica que dispara incorretamente.

Combine as métricas do WAF (BlockedRequests, AllowedRequests, CountedRequests) com alarmes do CloudWatch para que um pico repentino de bloqueios — ou uma queda súbita no tráfego permitido — acione o engenheiro de plantão, fechando o ciclo entre a proteção de borda e a consciência operacional.

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

Cenário: A Meridian Financial opera uma aplicação web voltada para o cliente em uma VPC multi-AZ usando Application Load Balancers (ALBs) como front-end para serviços ECS, e distribui conteúdo estático e dinâmico via CloudFront. A equipe usa o AWS WAF, mas tem automação limitada para ameaças na camada de rede e logging inconsistente entre os serviços.

Desafio: Um pico recente de tráfego volumétrico e na camada de aplicação visou os endpoints de login e causou o esgotamento da CPU do ALB enquanto sondava em busca de credential stuffing; a equipe de segurança precisa de mitigação rápida de DDoS, proteção de origem consistente, bloqueio automatizado de IPs maliciosos e implantações seguras de regras mais rigorosas.

Abordagem Recomendada:

1. Habilite o CloudFront na frente do ALB para mitigação de borda global, configure o ALB para aceitar tráfego apenas do CloudFront validando um cabeçalho de origem personalizado e restringindo o acesso de entrada com uma lista de prefixos gerenciada pelo CloudFront ou intervalos de IP conhecidos.
2. Implante o AWS WAFv2 com conjuntos de regras gerenciadas pela AWS, além de regras personalizadas baseadas em taxa e de detecção de bots; associe o WAF tanto à distribuição do CloudFront quanto ao ALB. Inicialmente, defina as novas regras personalizadas para o modo COUNT para coletar telemetria.
3. Inscreva a conta no AWS Shield Advanced e associe a distribuição do CloudFront e o ALB; crie alarmes de métricas do CloudWatch usando as métricas do Shield/DDoS e encaminhe os alarmes para um tópico SNS para notificações de plantão e acionadores de runbook.
4. Centralize os logs: transmita os logs do CloudFront, ALB, WAF e AWS Network Firewall para o Kinesis Data Firehose → S3 e habilite métricas/dashboards do CloudWatch para monitorar as contagens de correspondência de regras do modo COUNT.
5. Implante o AWS Network Firewall na VPC com grupos de regras stateful e habilite seu logging; crie filtros de métricas do CloudWatch para padrões suspeitos e uma função Lambda que é acionada por alarmes para atualizar automaticamente o grupo de regras do Network Firewall para adicionar IPs infratores a uma lista de negação.
6. Após observar o tráfego no modo COUNT e nos dashboards por uma janela de observação acordada, mude as regras do WAF de alta confiança para BLOCK e mantenha as atualizações automatizadas do Network Firewall com rollbacks seguros e versionamento dos grupos de regras.

Justificativa: Usar o CloudFront como a camada de borda com o WAF e o Shield Advanced fornece proteção DDoS em camadas, enquanto o logging centralizado, a validação de regras no modo COUNT e as atualizações automatizadas do Network Firewall orientadas por Lambda oferecem uma defesa de rede segura, observável e automatizada, consistente com as melhores práticas da AWS.

← Redes e Segurança de VPC · Todos os domínios · Governança →

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

Navegar Amazon →