Amazon SCS-C02: Segurança de Contêineres e Serverless — 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.

ECS Exec e Inspeção de Runtime Sem SSH

O ECS Exec fornece um shell interativo em um contêiner em execução — incluindo tarefas do Fargate — sem expor SSH, bastion hosts ou IPs públicos. Ele funciona utilizando o agente do SSM que a AWS injeta no ambiente de execução sidecar da tarefa. Como não há daemon SSH, nenhum material de chave e nenhum caminho de rede de entrada para proteger, a sobrecarga operacional é mínima e cada sessão é auditável através do CloudTrail e (opcionalmente) registrada em logs no S3 ou CloudWatch Logs.

Três requisitos devem ser atendidos para que o ECS Exec funcione:

• Permissões da task role: a task role (não a execution role) precisa de ssmmessages:CreateControlChannel, ssmmessages:CreateDataChannel, ssmmessages:OpenControlChannel e ssmmessages:OpenDataChannel. A execution role apenas baixa imagens e escreve logs; o tráfego do SSM em tempo de execução flui através da task role porque essa é a identidade que o processo do contêiner assume.

• Configuração do serviço ou da tarefa: o serviço deve ser criado ou atualizado com --enable-execute-command. Essa flag ativa enableExecuteCommand em novas tarefas; as tarefas existentes devem ser substituídas.

• Suporte da imagem do contêiner: o contêiner precisa ter um shell (/bin/sh ou /bin/bash) presente na imagem.

Um fluxo de inspeção típico se parece com isto:

aws ecs update-service --cluster prod --service api \
  --enable-execute-command --force-new-deployment

aws ecs execute-command --cluster prod \
  --task 5f8c...c2 --container api \
  --interactive --command "/bin/sh"

A partir desse shell, um engenheiro pode copiar logs para o S3, acionar um heap dump ou ler o /proc para análise forense. A alternativa — tentar acessar o contêiner por SSH ou reiniciar a tarefa para habilitar um agente de depuração — ou falha no Fargate ou destrói a evidência que você estava tentando coletar.

Bloqueando o Acesso ao IMDS de Contêineres no EC2

Um equívoco comum é que as configurações de hop-limit do IMDSv2 na instância EC2 protegem os contêineres nessa instância. Elas não protegem, pelo menos não por padrão nos modos de rede bridge ou host: os contêineres compartilham o namespace de rede do host ou uma ponte NAT e podem alcançar 169.254.169.254 e recuperar as credenciais do instance profile, que são tipicamente muito mais privilegiadas do que a task role. Isso anula completamente o princípio do menor privilégio.

A correção, quando a migração para o Fargate não é possível, tem duas partes:

• Use o modo de rede awsvpc para as tarefas. Cada tarefa obtém sua própria ENI e seu próprio namespace de rede. O tráfego do IMDS não alcança mais de forma transparente o endpoint link-local do host.

• Defina ECS_AWSVPC_BLOCK_IMDS=true em /etc/ecs/ecs.config na instância do contêiner. Isso instrui o agente do ECS a instalar uma regra de iptables que descarta pacotes de tarefas awsvpc destinados a 169.254.169.254.

echo 'ECS_AWSVPC_BLOCK_IMDS=true' >> /etc/ecs/ecs.config
systemctl restart ecs

Combine isso com um instance profile mínimo (essencialmente apenas o que o agente do ECS precisa: AmazonEC2ContainerServiceforEC2Role) e IAM roles por tarefa para as permissões da aplicação. Definir o hop limit do IMDS da instância como 1 com IMDSv2 obrigatório é uma medida útil de defesa em profundidade, mas não é um substituto — contêineres em modo bridge ainda podem alcançar o IMDS no hop 1 porque a requisição se origina do host.

Monitoramento de Runtime do GuardDuty, EKS Protection e Logs do Control Plane

O GuardDuty oferece detecção de contêineres em camadas:

• EKS Protection analisa os logs de auditoria do EKS para detectar atividades suspeitas na API do Kubernetes — acesso anônimo, criação de pods privilegiados, exec em pods do sistema.

• Runtime Monitoring implanta um sensor baseado em eBPF (como um add-on gerenciado para EKS, ou um agente gerenciado pelo SSM para ECS/Fargate) que observa a atividade de processos, arquivos e rede dentro dos contêineres. Ele revela findings como reverse shells, binários de criptomineração e exfiltração de credenciais de dentro de um Pod ou tarefa.

O EKS Protection é inútil a menos que o log de auditoria do control plane do EKS esteja de fato sendo emitido para o CloudWatch Logs. Habilite pelo menos os tipos de log audit e authenticator no cluster:

aws eks update-cluster-config --name prod \
  --logging '{"clusterLogging":[{"types":["api","audit","authenticator","controllerManager","scheduler"],"enabled":true}]}'

Sem isso, o GuardDuty não tem plano de dados para inspecionar em busca de findings do EKS Protection — uma armadilha que aparece com frequência porque os operadores habilitam o recurso do GuardDuty, mas deixam a configuração de logs do cluster desativada, e depois se perguntam por que nenhum finding do Kubernetes aparece.

Análise de Imagens com o ECR Enhanced Scanning

O ECR Enhanced Scanning é alimentado pelo Amazon Inspector e fornece análise contínua de imagens de contêiner em busca de CVEs de SO e de pacotes de linguagem (Python, Node, Java, Go, Ruby). A análise básica é executada uma única vez no momento do push e cobre apenas pacotes do SO; a avançada (enhanced) é contínua e inclui dependências da aplicação, que é onde a maioria das vulnerabilidades modernas reside.

Os findings fluem automaticamente para o Security Hub quando ambos os serviços estão habilitados, fornecendo um painel único (single pane of glass) para conformidade e permitindo que você escreva regras no EventBridge que reprovam builds de CI/CD. Um padrão de aplicação típico:

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

Cenário: A NovaTech Corp executa microsserviços para clientes em um ambiente de computação misto: vários clusters ECS no EC2, um cluster EKS para processamento de dados e Lambdas serverless para manipulação de eventos. As imagens são armazenadas no ECR, as operações usam o SSM para acesso aos hosts, e o GuardDuty/CloudWatch estão habilitados, mas a visibilidade é desigual entre os contêineres e os componentes do control plane.

Desafio: Um contêiner em produção exibiu conexões de saída suspeitas e um engenheiro descobriu que um pod conseguia alcançar o serviço de metadados da instância EC2, arriscando o vazamento de credenciais; vulnerabilidades de imagem e logs insuficientes do control plane podem ocultar a causa raiz.

Abordagem Recomendada:

1. Habilitar o ECS Exec para tarefas e exigir o AWS Systems Manager Session Manager para inspeção do host e do tempo de execução do contêiner (ECS Exec + SSM), removendo a necessidade de SSH e garantindo que a atividade da sessão seja registrada no CloudTrail e no CloudWatch Logs.
2. Forçar o uso do IMDSv2 nas instâncias EC2 (Instance Metadata Service HttpTokens=required, hop limit=1) e aplicar regras de rede no nível do host para bloquear o acesso a 169.254.169.254 a partir dos namespaces de rede dos contêineres, para que eles não possam consultar os metadados da instância.
3. Ativar o monitoramento de tempo de execução (runtime monitoring) e a proteção contra malware (Malware Protection) do Amazon GuardDuty para contêineres e Lambda, encaminhando os resultados (findings) para o Security Hub e o EventBridge para playbooks de contenção automatizados.
4. Fortalecer o EKS habilitando os logs do control plane (audit, authenticator, controllerManager, scheduler) para o CloudWatch Logs, adotar IAM Roles for Service Accounts (IRSA) e aplicar controles de admissão (Pod Security ou OPA Gatekeeper) para limitar capacidades de risco.
5. Ativar a varredura aprimorada de imagens (enhanced image scanning) do Amazon ECR (Inspector/ECR scanning) com varredura no push (scan-on-push) e integrar os resultados ao CI para bloquear/colocar em quarentena imagens via EventBridge + Lambda para imposição.
6. Centralizar a telemetria: enviar os resultados do CloudTrail, GuardDuty, logs do control plane do EKS e resultados de varredura do ECR para um pipeline centralizado com S3/Lambda/Security Hub e alimentar as regras do AWS Config para conformidade contínua.

Justificativa: Esta sequência remove o acesso baseado em SSH, previne o roubo de credenciais de metadados, fornece detecção em tempo de execução e resposta automatizada, impõe a higiene das imagens e oferece visibilidade do control plane — alinhando-se com as melhores práticas da AWS de privilégio mínimo, defesa em profundidade e observabilidade centralizada.

# CodeBuild buildspec fragment
post_build:
  commands:
    - aws ecr describe-image-scan-findings \
        --repository-name api --image-id imageTag=$TAG \
        --query 'imageScanFindings.findingSeverityCounts' > findings.json
      CRIT=$(jq '.CRITICAL // 0' findings.json)
      if [ "$CRIT" -gt 0 ]; then echo "Critical CVEs present"; exit 1; fi

A integração no pipeline é o que transforma a varredura de um exercício de painel em um controle real.

Lambda: Autorizadores, Segredos e Funções de Execução

A segurança no nível da função Lambda tem três planos que são frequentemente confundidos:

• Política de recurso (política da função): controla quais principais (API Gateway, EventBridge, outras contas) podem invocar a função. Os Lambda Authorizers no API Gateway são o portão de identidade para chamadores HTTP — eles retornam uma política do IAM que o API Gateway armazena em cache e aplica antes de invocar a função de backend.

• Função de execução (Execution role): a identidade que o código da função assume em tempo de execução. Sua política de confiança (trust policy) deve incluir lambda.amazonaws.com, e deve conceder logs:CreateLogGroup, logs:CreateLogStream e logs:PutLogEvents para que o CloudWatch Logs funcione. Se os logs estiverem ausentes, a correção quase sempre está na função de execução — não no console do Lambda, que apenas renderiza quaisquer logs que o CloudWatch tenha recebido. Confiar apenas nos “logs do console” é uma armadilha de diagnóstico: a falta de permissão na função de execução significa que não haverá stream de logs, e o console não mostrará nada.

• Recuperação de segredos: nunca insira credenciais em texto plano nas variáveis de ambiente. Armazene-as no Secrets Manager ou no SSM Parameter Store SecureString e busque-as no cold start:

import boto3, os, json
_ssm = boto3.client("ssm")
_cached = None

def get_db_password():
    global _cached
    if _cached is None:
        r = _ssm.get_parameter(Name=os.environ["DB_PWD_PARAM"], WithDecryption=True)
        _cached = r["Parameter"]["Value"]
    return _cached

A função de execução precisa das permissões ssm:GetParameter e kms:Decrypt na CMK. Faça o cache no escopo do módulo para que as invocações “warm” (quentes) evitem a chamada de API; use a extensão do Secrets Manager para Lambda para um cache automático ciente da rotação em funções de maior throughput.

Criptografia e Proteção de Repositório no ECR

O Amazon ECR criptografa todas as imagens em repouso (at rest) por padrão usando AES-256 com uma chave gerenciada pela AWS, mas cargas de trabalho regulamentadas geralmente exigem uma chave KMS gerenciada pelo cliente para que a rotação de chaves, as políticas de chave e a auditabilidade do CloudTrail estejam sob o controle do cliente. A criptografia KMS é configurada apenas no momento da criação do repositório; um repositório ECR existente não pode ser alterado de AES-256 para KMS após sua criação. A migração, portanto, requer a criação de um novo repositório criptografado com KMS, a replicação ou o reenvio (re-pushing) das imagens, a atualização dos consumidores downstream e a exclusão do repositório antigo. Consumidores de outras contas que fazem ‘pull’ de um repositório criptografado com KMS devem receber a permissão kms:Decrypt na CMK, além das permissões de leitura do ECR, ou o ‘pull’ falhará com um erro de acesso ao KMS, mesmo que a política do repositório permita o principal.

{
  "encryptionConfiguration": {
    "encryptionType": "KMS",
    "kmsKey": "arn:aws:kms:us-east-1:111122223333:key/abcd-...-ef01"
  },
  "imageScanningConfiguration": { "scanOnPush": true },
  "imageTagMutability": "IMMUTABLE"
}

Tags imutáveis previnem ataques de ’tag-hijack’, onde uma tag v1.2.3 validada é silenciosamente sobrescrita por uma imagem maliciosa após a varredura.

Escaneamento de Imagens: Básico, Aprimorado e Inspector

O ECR oferece dois modos de escaneamento. O escaneamento básico usa o banco de dados de CVEs de código aberto Clair, é executado apenas no push (ou por invocação manual) e retorna os achados no console do ECR. É gratuito, mas não realiza reescaneamentos contínuos, não cobre pacotes de SO e de linguagens de programação juntos e não tem integração nativa com o Security Hub. O escaneamento aprimorado é potencializado pelo Amazon Inspector e cobre tanto pacotes do sistema operacional quanto pacotes de linguagens de aplicação (Python, Java, Node.js, Go, Ruby, .NET). O Inspector monitora continuamente as imagens enviadas (pushed) em busca de inteligência de vulnerabilidade atualizada, de modo que uma CVE divulgada uma semana após o push da imagem ainda gera um achado sem a necessidade de um novo build.

O escaneamento aprimorado é habilitado no nível do registro (por Região), com filtros de inclusão por repositório usando padrões wildcard como prod-* ou team-a/*. Este é o controle correto para o requisito comum de “escanear a maioria dos repositórios, mas excluir os de sandbox/experimentação” — você define filtros positivos listando o que deve ser escaneado, em vez de exclusões negativas em repositórios individuais.

aws ecr put-registry-scanning-configuration \
  --scan-type ENHANCED \
  --rules '[{
    "scanFrequency": "CONTINUOUS_SCAN",
    "repositoryFilters":[{"filter":"prod-*","filterType":"WILDCARD"}]
  },{
    "scanFrequency": "SCAN_ON_PUSH",
    "repositoryFilters":[{"filter":"dev-*","filterType":"WILDCARD"}]
  }]'

Integração com o Inspector e Agregação no Security Hub

O Amazon Inspector deve ser habilitado em cada conta e Região onde o escaneamento é necessário. Em uma configuração do AWS Organizations, a conta de ferramentas de segurança é designada como o administrador delegado do Inspector, o que permite habilitar o escaneamento, configurar o registro automático para novas contas-membro e visualizar os achados agregados. Esquecer de delegar — ou de ativar o registro automático — é um modo de falha sutil: novas contas que entram na organização enviam contêineres para o ECR silenciosamente, que nunca são escaneados, quebrando as garantias de cobertura sem gerar nenhum erro visível.

Os achados do Inspector fluem para o AWS Security Hub automaticamente quando ambos os serviços estão habilitados e a integração do Inspector no Security Hub está ativada. O Security Hub então normaliza os achados para o formato AWS Security Finding Format (ASFF), correlaciona-os com os achados do GuardDuty, Macie e Config e — quando combinado com um administrador delegado do Security Hub e agregação entre Regiões — apresenta um painel de controle unificado. Regras do EventBridge sobre os achados do Security Hub podem rotear CVEs críticas para o Lambda para criação automatizada de tickets, marcar a imagem infratora com uma tag quarantine=true ou bloquear o deploy por meio de um portão (gate) no pipeline.

Escaneamento Centralizado e CI/CD entre Contas (Cross-Account)

O padrão recomendado para workloads de contêineres em múltiplas contas coloca uma conta de registro central fortalecida (hardened) no centro:

• Conta central: hospeda repositórios ECR criptografados com KMS, com escaneamento aprimorado, tags imutáveis e assinatura de imagem (via Notation/Sigstore integrado com o AWS Signer).
• Contas de build: executam jobs do CodeBuild/CodePipeline que constroem, enviam para o ECR central, aguardam os achados do Inspector e bloqueiam com base em limites de severidade.
• Contas de workload (dev/stage/prod): fazem o pull das imagens do registro central por meio de permissões entre contas (cross-account).

O acesso de leitura entre contas requer duas camadas: uma política do IAM na conta consumidora concedendo ecr:GetDownloadUrlForLayer, ecr:BatchGetImage e ecr:GetAuthorizationToken, mais uma política de repositório no repositório ECR na conta central permitindo a conta ou role consumidora específica.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "AllowProdPull",
    "Effect": "Allow",
    "Principal": {"AWS":"arn:aws:iam::444455556666:role/EcsTaskExecutionRole"},
    "Action": ["ecr:BatchGetImage","ecr:GetDownloadUrlForLayer"]
  }]
}

Como as políticas de repositório do ECR são baseadas em recursos, a interseção da política de identidade e da política de recurso determina o acesso — omitir qualquer uma das camadas produz uma AccessDeniedException. Quando o KMS está envolvido, a política da chave KMS também deve conceder kms:Decrypt ao principal (principal) da outra conta.

Logging e Observabilidade do Control Plane do EKS

No EKS, o control plane gerenciado não é diretamente acessível, então os eventos do Kubernetes relevantes para a segurança são expostos apenas quando o logging do control plane é explicitamente habilitado. Cinco tipos de log estão disponíveis: api, audit, authenticator, controllerManager e scheduler. O log de audit é o artefato de segurança de maior valor — ele registra cada chamada de API para o cluster com a identidade do chamador resolvida pelo autenticador do IAM — e o authenticator registra as decisões de mapeamento do IAM para o RBAC do Kubernetes. Todos os tipos são transmitidos para o CloudWatch Logs em um grupo de logs /aws/eks/<cluster>/cluster, de onde podem ser inscritos no Kinesis Data Firehose, encaminhados para o S3 ou enviados para um SIEM.

aws eks update-cluster-config --name prod-cluster \
  --logging '{"clusterLogging":[{"types":["api","audit","authenticator",
  "controllerManager","scheduler"],"enabled":true}]}'

Complemente os logs do control plane com o GuardDuty EKS Protection (detecção de ameaças em tempo de execução nos nós) e use IRSA (IAM Roles for Service Accounts) em vez de perfis de instância de nó, para que os logs de auditoria atribuam a atividade da API da AWS a pods específicos.

Armadilhas Comuns

Confiar apenas na varredura no momento do push (scan-on-push): A varredura básica no momento do push detecta vulnerabilidades conhecidas no momento do push, mas não faz nada em relação a CVEs divulgados posteriormente contra imagens que já estão no registro. Frameworks de auditoria como PCI DSS e FedRAMP exigem avaliação contínua de vulnerabilidades, o que impõe a varredura aprimorada com frequência CONTINUOUS_SCAN e a agregação no Security Hub. Um snapshot único por push não atende ao controle.

Ignorar o KMS no ECR quando a criptografia em repouso é necessária: A criptografia padrão AES-256 é uma criptografia real, mas regimes de conformidade que exigem chaves gerenciadas pelo cliente, registros de rotação de chaves e trilhas de auditoria de kms:Decrypt por principal não podem ser atendidos por chaves pertencentes à AWS. Como o tipo de criptografia é imutável por repositório, isso deve ser resolvido na criação — a ideia de “ativaremos mais tarde” é impossível sem a recriação do repositório.

Esquecer do administrador delegado do Inspector ou do registro automático: Sem um administrador delegado para o Inspector, o proprietário de cada conta deve habilitar a varredura e encaminhar os resultados (findings) de forma independente, o que é operacionalmente inviável e gera lacunas de cobertura. Sem a habilitação automática para novas contas-membro, toda nova conta criada via Control Tower ou Organizations começa com o Inspector desabilitado, de modo que suas imagens ECR não são escaneadas, embora o Security Hub na conta central não mostre nenhum resultado — um falso negativo silencioso em vez de um erro óbvio.

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

Cenário: A Meridian Financial opera um ambiente AWS de múltiplas contas com clusters EKS de produção, serviços ECS e múltiplos registros ECR distribuídos entre os ambientes de produção (prod), desenvolvimento (dev) e uma conta de segurança dedicada. Suas equipes de engenharia enviam imagens de contêiner por meio de pipelines de CI/CD para o ECR e as implantam no EKS/ECS, enquanto a equipe de segurança mantém uma conta centralizada para monitoramento e conformidade.

Desafio: Uma implantação recente entregou um contêiner com uma vulnerabilidade de alta severidade que não foi detectada antes da produção, e os investigadores encontraram logs limitados do painel de controle do EKS e resultados de varredura fragmentados entre as contas, atrasando a remediação.

Abordagem Recomendada:

1. Habilitar proteções no nível do repositório ECR: impor a imutabilidade de tags de imagem, aplicar políticas de repositório que limitem o push/pull por perfis (roles) IAM específicos e criptografar repositórios em repouso com uma chave gerenciada pelo cliente (CMK) do AWS KMS dedicada.
2. Ativar a varredura de imagens no push (básica) e habilitar a varredura aprimorada de imagens do Amazon Inspector para o ECR para produzir resultados de vulnerabilidade (findings); integrar o Inspector com o AWS Security Hub para agregação centralizada de severidades entre contas.
3. Implementar varredura centralizada entre contas (cross-account): configurar a replicação do ECR ou conceder permissões de pull entre contas a um perfil (role) do CodeBuild/CodePipeline da conta de segurança, para que a conta de segurança escaneie todas as imagens com o Inspector e quaisquer ferramentas adicionais de SCA/DAST, armazenando os artefatos em um bucket S3 centralizado e criptografado com a CMK da conta de segurança.
4. Aplicar barreiras (gating) no CI/CD: adicionar um estágio de varredura no pipeline (CodeBuild/CodePipeline ou GitHub Actions com STS assume-role) que consulta os resultados (findings) do Inspector/Security Hub e bloqueia automaticamente ou exige aprovação para imagens com resultados de severidade alta/crítica.
5. Melhorar a observabilidade do EKS: habilitar os logs do painel de controle do EKS (API, Audit, Authenticator, ControllerManager, Scheduler) para o CloudWatch Logs em uma conta de logging centralizada, habilitar o CloudTrail para eventos da API do EKS e usar o Container Insights e o GuardDuty para monitoramento em tempo de execução.

Justificativa: Esta abordagem aplica defesa em profundidade: criptografar e proteger os registros, automatizar a varredura aprimorada com o Inspector, centralizar os resultados (findings) no Security Hub para aplicação consistente de políticas, controlar as implantações no CI/CD com barreiras (gating) e habilitar os logs do painel de controle do EKS para detecção e análise forense rápidas, alinhando-se com as melhores práticas da AWS de privilégio mínimo e monitoramento centralizado.

← Vulnerabilidade · Todos os domínios · Resposta a Incidentes e Forense →

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

Navegar Amazon →