Amazon SCS-C02: Redes e Segurança de VPC — 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.

Endpoints de VPC e Políticas de Endpoint

Endpoints de VPC mantêm o tráfego para serviços da AWS na rede da AWS, evitando a internet pública, NAT gateways e internet gateways. Existem dois tipos estruturalmente diferentes, e confundi-los é um dos erros de design mais comuns.

Endpoints do tipo gateway existem apenas para o Amazon S3 e o DynamoDB. Eles são entradas na tabela de rotas — você associa o endpoint a tabelas de rotas, e o tráfego destinado à lista de prefixos do serviço (por exemplo, pl-63a5400a para o S3 em us-east-1) é silenciosamente redirecionado através do endpoint. Eles não têm custo e não podem ser acessados de fora da VPC à qual estão anexados.

Endpoints do tipo interface (baseados no AWS PrivateLink) são ENIs com endereços IP privados alocados em suas subnets. Eles são necessários para todos os serviços que não são o S3 ou o DynamoDB — Secrets Manager, KMS, STS, SSM, CloudWatch Logs, ECR API/DKR e centenas de outros. Se uma instância EC2 em uma subnet privada sem um NAT gateway precisar executar GetSecretValue no Secrets Manager, um endpoint do tipo gateway não ajudará; você deve criar um endpoint de interface com.amazonaws.<region>.secretsmanager e habilitar o DNS Privado para que o hostname padrão do serviço resolva para o IP privado do endpoint.

Políticas de endpoint restringem o que pode ser feito através do endpoint, independentemente das políticas do IAM no chamador. As duas chaves de condição mais importantes para prevenir a exfiltração de dados são aws:PrincipalOrgID (a identidade que faz a chamada deve pertencer à sua Organization) e aws:ResourceOrgID (o bucket S3, a chave KMS, etc. que está sendo acessado deve pertencer à sua Organization). Aplicar ambas fecha o caminho clássico de exfiltração onde uma instância comprometida com permissões legítimas de S3 grava em um bucket controlado por um invasor fora da sua organização — as credenciais ainda funcionam contra o S3, mas o endpoint se recusa a encaminhar a solicitação.

{
  "Statement": [{
    "Effect": "Allow",
    "Principal": "*",
    "Action": "s3:*",
    "Resource": "*",
    "Condition": {
      "StringEquals": {
        "aws:PrincipalOrgID": "o-abc123",
        "aws:ResourceOrgID":  "o-abc123"
      }
    }
  }]
}

A política de endpoint padrão é totalmente permissiva ("Action":"*" em "Resource":"*"), e é por isso que uma subnet com apenas um endpoint do tipo gateway e IAM de privilégio mínimo ainda pode ser abusada para exfiltração, a menos que você restrinja a própria política do endpoint.

Conectividade Híbrida: VPN e Direct Connect

A Site-to-Site VPN estabelece dois túneis IPsec entre um virtual private gateway (ou um Transit Gateway) e um dispositivo de customer gateway. É rápido de provisionar, criptografado por padrão e atravessa a internet pública — portanto, a vazão e a latência dependem do caminho do seu provedor de internet (ISP).

O AWS Direct Connect provisiona um circuito físico dedicado através de uma localidade do Direct Connect. Ele fornece baixa latência previsível e largura de banda alta e consistente (1/10/100 Gbps), o que é importante para tráfego de banco de dados on-premises que é muito comunicativo (“chatty”). O Direct Connect não é criptografado na camada 3 por si só; os frames trafegam em fibra privada. Para workloads que exigem tanto baixa latência quanto IPsec, a resposta canônica é Direct Connect mais uma Site-to-Site VPN rodando sobre uma VIF pública (ou um Transit Gateway com MACsec em portas DX mais novas). A VPN sozinha também é o backup criptografado recomendado para um link Direct Connect primário, fornecendo resiliência caso o circuito falhe.

Apenas Direct Connect: baixa latência, privado, mas não criptografado na camada de IP.
Apenas VPN: criptografado, rápido de implantar, mas com latência e jitter do caminho da internet.
Direct Connect + VPN: baixa latência e criptografia IPsec; também é o padrão de alta disponibilidade (HA).

Security Groups, NACLs, DHCP e Verificações de Origem/Destino

Security groups são stateful (com estado): se você permite uma solicitação de entrada, a resposta é automaticamente permitida na saída. Eles suportam apenas regras de permissão (allow) e são avaliados por ENI.

Network ACLs (NACLs) são stateless (sem estado) e operam na fronteira da subnet. Cada fluxo requer duas regras — uma para a direção inicial e outra para o tráfego de retorno no intervalo de portas efêmeras (Linux tipicamente 32768–60999, Windows 49152–65535, e NLBs/ELBs usam 1024–65535). Uma NACL que permite TCP 443 de entrada, mas esquece do TCP 1024–65535 de saída, quebrará silenciosamente o TLS. ICMP não é TCP/UDP: pacotes de retorno “echo reply” devem ser permitidos explicitamente, e o Path MTU Discovery depende do ICMP tipo 3 código 4, que é fácil de ser descartado inadvertidamente. As regras da NACL também são avaliadas em ordem numérica, a primeira correspondência prevalece (first-match wins), com uma negação implícita no final.

DHCP option sets controlam o que uma VPC entrega às instâncias na inicialização: domain-name-servers, domain-name, servidores NTP, NetBIOS. Substituir o AmazonProvidedDNS padrão por um resolvedor on-premises personalizado pode ser legítimo, mas tem consequências reais de segurança. Serviços como o GuardDuty derivam achados (findings) baseados em DNS (por exemplo, as detecções de “cryptocurrency” e “C&C domain”) de consultas que atravessam o Route 53 Resolver. Uma vez que você aponta as instâncias para um servidor DNS de terceiros, o GuardDuty para de ver as consultas e esses tipos de achados desaparecem — uma maneira fácil de cegar acidentalmente a detecção.

A verificação de origem/destino (source/destination checking) é um atributo da ENI que descarta qualquer pacote cuja origem ou destino de IP não corresponda à ENI. Esse padrão é correto para instâncias comuns, mas quebra qualquer appliance cuja função é encaminhar tráfego — instâncias NAT, firewalls virtuais (Palo Alto, Fortinet, Check Point), roteadores de trânsito, concentradores de VPN. Para essas ENIs, desabilite a verificação:

aws ec2 modify-instance-attribute \
  --instance-id i-0abc123 \
  --no-source-dest-check

VPC Peering, VPCs Compartilhadas com RAM e Design de NAT

O VPC peering é um link de camada 3, um-para-um e não transitivo. Se A faz peering com B e B faz peering com C, A não consegue alcançar C — você deve fazer o peering A–C diretamente ou usar um Transit Gateway. As tabelas de rotas em ambos os lados devem conter rotas para o CIDR do peer, e os security groups podem referenciar IDs de security groups do peer apenas dentro de uma Região.

VPCs compartilhadas via AWS Resource Access Manager (RAM) permitem que uma conta de rede seja proprietária de uma VPC e compartilhe sub-redes individuais com contas participantes. Os participantes lançam recursos nas sub-redes compartilhadas, mas não podem modificar a VPC, as tabelas de rotas ou os endpoints — o proprietário mantém o controle da política de conectividade. Isso geralmente é mais barato e simples do que fazer peering de muitas VPCs.

Para acesso de saída para a internet a partir de sub-redes privadas, implante um NAT gateway por Zona de Disponibilidade e roteie cada sub-rede privada para o NAT em sua própria AZ. Um único NAT gateway é uma dependência entre AZs e um gargalo de escala/disponibilidade. Quando sua carga de trabalho chama um terceiro que utiliza listas de permissão de IP (IP-allow-lists) para seu tráfego de saída (um processador de pagamentos, por exemplo), o Elastic IP do NAT gateway é o que você registra, e como as instâncias por trás de um Auto Scaling group saem todas por esse EIP fixo, o IP de origem não muda conforme o grupo escala. Colocar as instâncias EC2 e o banco de dados RDS em sub-redes privadas e terminar apenas HTTP/HTTPS no ALB completa o padrão.

Route 53 Resolver: Encaminhamento e Log de Consultas

O Route 53 Resolver (o endereço .2 em toda VPC) é o pivô para o DNS híbrido. Endpoints de resolvedor de saída encaminham nomes de domínio especificados da AWS para servidores DNS on-premises por meio de regras de encaminhamento condicional — usado, por exemplo, para que corp.example.internal seja resolvido em seu Active Directory. Endpoints de resolvedor de entrada fazem o inverso, fornecendo aos hosts on-premises um IP privado em sua VPC que eles podem consultar para resolver *.eu-west-1.compute.internal e Private Hosted Zones.

O log de consultas do Resolver (Resolver query logging) escreve cada consulta DNS feita a partir da VPC para o CloudWatch Logs, S3 ou Kinesis Firehose. É o registro autoritativo para investigar suspeitas de exfiltração ou uso indevido e complementa — mas não substitui — o GuardDuty. Lembre-se de que se um conjunto de opções DHCP (DHCP option set) redireciona as instâncias para um resolvedor que não seja da Amazon, tanto o log de consultas quanto os achados de DNS do GuardDuty ficam sem visibilidade, porque as consultas nunca chegam ao Route 53 Resolver.

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

Cenário: A Meridian Financial opera um ambiente AWS multi-contas com uma rede hub-and-spoke: uma VPC de serviços compartilhados (shared-services VPC) compartilhada com RAM hospeda NAT Gateways centralizados, endpoints do Route 53 Resolver e anexos do Transit Gateway, enquanto várias VPCs de aplicação estão em peering ou anexadas ao Transit Gateway. Datacenters on-premises se conectam via Direct Connect com failover de VPN, e as equipes dependem de conjuntos de opções DHCP centralizados e endpoints de resolvedor compartilhados para a resolução de DNS híbrido.

Desafio: Um incidente recente mostrou que objetos sensíveis do S3 estavam sendo acessados pela internet pública porque os spokes roteavam para o NAT compartilhado em vez de para os VPC endpoints, consultas DNS para zonas internas vazaram para resolvedores públicos, e uma instância EC2 usada como um roteador ad-hoc (verificação de origem/destino desabilitada) permitiu movimento lateral.

Abordagem Recomendada:

Implantar Gateway VPC Endpoints para S3 e DynamoDB e Interface Endpoints (AWS PrivateLink) para Secrets Manager e KMS na VPC de serviços compartilhados, anexando políticas de endpoint explícitas que restrinjam o acesso a buckets e principals de serviço nomeados.
Reformular o design de NAT para que as sub-redes de aplicação usem VPC endpoints para APIs da AWS e S3; manter os NAT Gateways apenas para saída genuína para a internet com security groups de saída rigorosos e Flow Logs para CloudWatch/S3.
Reativar a verificação de origem/destino (source/dest check) em todas as instâncias EC2, exceto em appliances de roteamento documentados; mover o roteamento para anexos do Transit Gateway ou instâncias NAT gerenciadas e aplicar o princípio de menor privilégio nas tabelas de rotas.
Reforçar os Security Groups e as NACLs de sub-rede para uma postura de negação por padrão (deny-by-default), e aplicar baselines centralizados de IAM+SG por meio de SCPs do AWS Organizations e regras do AWS Config.
Fortalecer o DNS híbrido implantando endpoints de entrada/saída do Route 53 Resolver, configurar encaminhamento condicional e regras de DNS Firewall, habilitar o log de consultas do Resolver para o CloudWatch Logs e usar conjuntos de opções DHCP para forçar o uso de resolvedores internos para todas as VPCs compartilhadas via RAM.

Justificativa: Esta abordagem remove a saída desnecessária para a internet usando VPC endpoints com políticas de endpoint, centraliza e controla o roteamento via Transit Gateway/Direct Connect, restaura as proteções no nível da instância e previne o vazamento de DNS com endpoints do Resolver e logs — alinhando-se com as melhores práticas de rede e defesa em profundidade da AWS.

VPC Endpoints e Políticas de Endpoint

Endpoints de VPC permitem que workloads dentro de uma VPC alcancem APIs de serviços da AWS sem atravessar a internet pública ou um NAT gateway. Existem dois tipos de arquitetura, e escolher o errado é uma fonte comum de tráfego roteado incorretamente.

Endpoints de Gateway: Usados apenas para o Amazon S3 e DynamoDB. Eles são implementados como um alvo (target) em uma tabela de rotas (prefix list pl-xxxxxxxx apontando para vpce-xxxxxxxx). Nenhuma ENI é criada, nenhuma alteração de DNS é necessária e não há custo por hora.
Endpoints de Interface (PrivateLink): Usados para KMS, SQS, SNS, Secrets Manager, STS, EC2 API e a maioria dos outros serviços. Eles provisionam ENIs com IPs privados dentro de sub-redes escolhidas e são cobrados por hora mais por GB.

Para um job em lote entre contas (cross-account) onde instâncias EC2 na Conta B leem de um bucket S3 na Conta A criptografado com uma chave KMS na Conta A, o design correto é um endpoint de gateway para o S3 mais um endpoint de interface para o KMS. O endpoint de gateway mantém s3:GetObject, s3:PutObject, s3:PutObjectAcl e s3:ListBucket fora da internet; o endpoint de interface faz o mesmo para kms:Decrypt, kms:Encrypt e kms:GenerateDataKey. Como o ARN da chave KMS usa o hostname padrão kms.<region>.amazonaws.com, o endpoint de interface deve ter o DNS Privado habilitado (Private DNS enabled) para que o hostname não modificado do SDK resolva para a ENI do endpoint em vez do serviço KMS público. Sem o DNS Privado (ou sem os hostnames DNS e a resolução de DNS habilitados no nível da VPC), o cliente ainda acessaria o endpoint público — portanto, o requisito de “sem alterações no código” exige implicitamente o DNS Privado.

Políticas de endpoint são uma segunda camada de autorização independente. Existe uma política padrão permissiva, mas o reforço (hardening) para um bucket e chave específicos se parece com isto:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": "*",
    "Action": ["s3:GetObject","s3:PutObject","s3:PutObjectAcl","s3:ListBucket"],
    "Resource": ["arn:aws:s3:::acct-a-bucket","arn:aws:s3:::acct-a-bucket/*"]
  }]
}

Apenas criar o endpoint não é suficiente. Dois modos de falha são recorrentes: (1) o endpoint existe, mas a tabela de rotas da sub-rede privada não tem uma entrada para a prefix list do S3, então o tráfego ainda sai pelo NAT gateway; (2) a política do endpoint omite uma ação como s3:PutObjectAcl ou aponta para o ARN do bucket errado, bloqueando silenciosamente chamadas que o IAM permitiria. Tanto a política do bucket quanto a política do endpoint devem permitir a requisição — elas são uma interseção, não uma união.

Security Groups, NACLs e Contenção Rápida

Security groups e NACLs resolvem problemas sobrepostos em camadas diferentes, e o exame frequentemente força uma escolha entre eles para resposta a incidentes.

Security groups: Stateful, avaliados na ENI. O tráfego de retorno é permitido automaticamente. Existem apenas regras de permissão (allow). Ideal para políticas no nível do host (“camada web pode alcançar a camada de aplicação na porta 8080”).
Network ACLs (NACLs): Stateless, avaliadas na fronteira da sub-rede. Existem regras de permissão (allow) e negação (deny), processadas na ordem do número da regra. Ideal para bloqueios gerais em toda a sub-rede — especialmente para colocar em lista de bloqueio (blocklisting) um intervalo de IP ou fechar uma porta específica em todas as instâncias de uma sub-rede.

Quando um surto de malware força o bloqueio de tráfego de saída na porta TCP/2905 para um conjunto de IPs de comando e controle (C2) em muitas instâncias, uma regra de negação (deny) na NACL é o instrumento correto. Security groups não podem expressar “deny” e exigiriam a enumeração e modificação de cada SG referenciado por cada ENI afetada. Uma única regra de negação (deny) na NACL no nível da sub-rede com um número de regra baixo (ex: 90) cobre todas as instâncias naquela sub-rede instantaneamente, preservando o tráfego não relacionado avaliado por regras de permissão (allow) posteriores.

Como as NACLs são stateless, lembre-se que ambas as direções precisam de regras. Bloquear a saída (egress) na porta 2905 não exige uma regra de entrada (ingress), mas se você também quiser rejeitar as respostas de entrada, deve adicionar uma entrada de entrada — e entradas de permissão (allow) de entrada para portas efêmeras (1024–65535) devem existir para permitir a passagem do tráfego de retorno legítimo.

NAT Gateways, Roteamento e Independência de AZ

Um NAT gateway é um recurso zonal. O padrão canônico é um NAT gateway por Zona de Disponibilidade (AZ), com a tabela de rotas de cada sub-rede privada apontando 0.0.0.0/0 para o NAT na mesma AZ:

PrivateRouteTable-AZ-a:  0.0.0.0/0 -> nat-aaaa (in subnet public-az-a)
PrivateRouteTable-AZ-b:  0.0.0.0/0 -> nat-bbbb (in subnet public-az-b)
PrivateRouteTable-AZ-c:  0.0.0.0/0 -> nat-cccc (in subnet public-az-c)

Um único NAT compartilhado entre AZs parece mais barato, mas introduz dois problemas: cobranças de transferência de dados entre AZs (cross-AZ) em cada pacote e uma dependência de disponibilidade rígida — se aquela AZ cair, todas as sub-redes privadas perdem a saída para a internet. O padrão de NAT zonal também evita anomalias de retorno assimétrico quando combinado com a inspeção do Transit Gateway (veja abaixo).

VPC Flow Logs para Investigação

Os Flow Logs capturam metadados de 5-tuplas (IP de origem/destino, porta, protocolo, ação ACCEPT/REJECT, bytes, pacotes) no nível da VPC, sub-rede ou ENI. Para caçar instâncias que estão se comunicando (beaconing) com hosts C2 na porta TCP/2905, habilite os Flow Logs na VPC com o tipo de tráfego definido como REJECT (já que a NACL agora está descartando o tráfego) e consulte no CloudWatch Logs Insights ou no Athena:

SELECT srcaddr, dstaddr, dstport, action, COUNT(*) AS hits
FROM vpc_flow_logs
WHERE dstport = 2905 AND action = 'REJECT'
GROUP BY srcaddr, dstaddr, dstport, action
ORDER BY hits DESC;

A coluna srcaddr revela os IPs das instâncias infectadas com esforço mínimo — sem capturas de pacotes, sem agentes nos hosts. Escolher o tráfego “ALL” funciona, mas produz mais dados e custo; escolher apenas “ACCEPT” perderia completamente as tentativas descartadas, que é precisamente o que você precisa ver.

← Proteção de Dados e S3 · Todos os domínios · Segurança de Borda e de Aplicações →

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