Amazon CLF-C02: Segurança, Identidade e Conformidade — Guia de estudos

By Laurynas Brazys · 29 July 2026 · #amazon #clf-c02 #certification #exam-prep #study-guide

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

Identidade, controle de acesso e o princípio do menor privilégio

A identidade e o acesso na AWS são construídos em torno das construções do IAM: usuários, grupos, roles, políticas e federação. A melhor prática é evitar atribuir permissões à conta root e conceder privilégios por meio de roles e grupos para que as permissões sejam gerenciadas centralmente e auditáveis. Use IAM roles para serviços de computação e serverless (EC2 instance roles, Lambda execution roles) em vez de incorporar credenciais de longa duração. Para acesso humano, prefira uma solução de federação de identidade (IAM Identity Center ou um provedor SAML/OIDC) para centralizar a autenticação, usar MFA e impor o uso de credenciais de curta duração via STS para reduzir a exposição de credenciais. O design de políticas deve considerar políticas baseadas em identidade versus políticas baseadas em recursos e a ordem de avaliação da política: a negação explícita (explicit deny) prevalece, e permissões amplas com “*” são uma armadilha comum que quebra o princípio do menor privilégio. As Service Control Policies no AWS Organizations fornecem um guardrail de nível superior, impedindo que as contas executem atividades proibidas, independentemente das permissões do IAM no nível da conta. Os critérios de decisão dependem da escala e dos limites de confiança (trust boundaries): use roles cross-account com o menor privilégio para automação e administração centralizada; use IAM roles para serviços para evitar o vazamento de credenciais; use o IAM Access Analyzer para validar o acesso cross-account. Os profissionais da área frequentemente se esquecem de rotacionar chaves, remover permissões não utilizadas ou habilitar o MFA e a federação desde o início — essas lacunas criam o maior risco operacional.

Proteção de dados, criptografia e gerenciamento de chaves

Criptografe os dados em trânsito e em repouso por padrão. Para dados em trânsito, o TLS é a linha de base; para dados em repouso, a AWS oferece várias opções: criptografia do lado do servidor no S3 (SSE-S3, SSE-KMS, SSE-C), criptografia do EBS e do RDS, e criptografia do lado do cliente quando você precisa que o cliente tenha controle sobre as chaves. O AWS KMS é o principal serviço gerenciado de chaves para criptografia de envelope (envelope encryption), permitindo CMKs gerenciadas pelo cliente, rotação automática e controles de uso refinados por meio de políticas de chave (key policies) e do IAM. O KMS se integra a muitos serviços da AWS para fornecer auditoria do uso de chaves no CloudTrail, mas observe que as operações do KMS podem incorrer em cobranças por solicitação e têm escopo regional — arquiteturas cross-account ou cross-region exigem a configuração explícita de políticas de chave ou o uso de chaves multi-Region. Para necessidades de FIPS ou HSM dedicado, o AWS CloudHSM oferece hardware dedicado ao locatário (tenant-dedicated). Use o S3 Object Lock e o Glacier Vault Lock para imutabilidade e conformidade de retenção quando requisitos regulatórios exigirem arquivos inalteráveis. Uma armadilha comum é presumir que “criptografado” é o mesmo que “com acesso controlado”; a criptografia protege a confidencialidade do conteúdo, mas as políticas de acesso e o monitoramento ainda devem impedir o uso não autorizado. Escolha SSE-KMS quando precisar de logs de acesso à chave, controle granular do IAM ou decriptografia cross-account; use a criptografia do lado do cliente quando for imperativo impedir que a AWS tenha acesso ao texto plano (plaintext) a qualquer momento.

Detecção, monitoramento e resposta automatizada

Visibilidade e detecção são a força vital da segurança na nuvem. O CloudTrail fornece uma trilha de auditoria para chamadas de API (eventos de gerenciamento) e também pode capturar eventos de dados para o S3 e o Lambda; no entanto, muitas equipes negligenciam a habilitação de eventos de dados, criando pontos cegos. O AWS Config registra alterações na configuração de recursos e permite verificações contínuas de conformidade, enquanto o Security Hub agrega os achados (findings) do GuardDuty (detecção de ameaças), Inspector (verificação de vulnerabilidades) e Macie (descoberta de dados sensíveis). O GuardDuty usa várias fontes de telemetria (VPC Flow Logs, DNS, CloudTrail) para identificar atividades suspeitas; os achados devem alimentar uma conta de segurança central e ser acionáveis via EventBridge e playbooks automatizados (Lambda ou SSM Automation) para contenção. As decisões de logging e retenção afetam o custo: buckets S3 centralizados com regras de ciclo de vida (lifecycle rules) e criptografia reduzem a despesa de armazenamento e simplificam o acesso para auditoria. Integre com sistemas SIEM ou use integrações de parceiros para análises avançadas. Uma armadilha recorrente para os profissionais da área é armazenar logs na mesma conta ou não proteger o bucket S3 da trilha (trail), o que acarreta o risco de adulteração; sempre centralize e imponha a imutabilidade e o acesso restrito. Elabore runbooks de resposta a incidentes que mapeiem os achados do GuardDuty e do CloudTrail a passos concretos de contenção e teste-os regularmente.

Proteção de perímetro, defesa contra DDoS e controles de conformidade

Controles de perímetro em camadas combinam controles de VPC, regras de ALB/WAF e defesas contra DDoS para reduzir a superfície de ataque. O AWS WAF fornece filtragem na camada de aplicação (L7) para aplicações web, protegendo contra exploits comuns e ataques de injeção. O AWS Shield Standard é aplicado automaticamente sem custo adicional para proteções básicas contra DDoS; o Shield Advanced oferece mitigação aprimorada, proteções de custo contra DDoS e uma equipe de resposta a incidentes em um nível pago, que deve ser considerado para serviços de alto risco e expostos à internet. O AWS Firewall Manager ajuda a gerenciar políticas do WAF, Shield Advanced e AWS Network Firewall em múltiplas contas. Para descoberta e monitoramento de dados sensíveis no S3, o Macie automatiza a detecção e classificação de PII (Informações de Identificação Pessoal). Artefatos de conformidade e avaliações de terceiros estão disponíveis via AWS Artifact para que os clientes possam obter relatórios SOC, ISO e outros. Armadilhas comuns incluem regras de WAF excessivamente permissivas, buckets S3 expostos devido a políticas mal configuradas e presumir que o Shield Advanced elimina a necessidade do WAF. Use defesa em profundidade: web ACLs no ALB, security groups e NACLs seguros no nível da sub-rede, VPC endpoints para evitar a saída de tráfego de serviço para a internet pública e orquestração com o Firewall Manager para impor padrões em toda a organização.

Comparações de serviços (alto nível)

AWS WAF: Mecanismo de regras na camada de aplicação para ALB/CloudFront/API Gateway; proteção baseada em regras e limitação de taxa (rate-limiting).
AWS Shield Standard: Proteções gratuitas contra DDoS para ataques comuns; aplicado automaticamente.
AWS Shield Advanced: Mitigação aprimorada de DDoS paga, equipe de resposta, proteção de custos e telemetria.
AWS Firewall Manager: Implantação centralizada de políticas do WAF, Shield Advanced e Network Firewall em todo o AWS Organizations.
Amazon Macie: Descoberta e classificação de dados sensíveis para o S3 com alertas automatizados.

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

Cenário: A AcmeRetail opera um AWS Organization com múltiplas contas. Sua loja virtual pública é executada em uma conta de frota (Fleet) por trás de um ALB, os logs de aplicação e backups são armazenados no S3, e eles têm uma conta de Segurança (Security) centralizada para ferramentas e auditoria.

Desafio: A AcmeRetail precisa de detecção e resposta centralizadas, criptografia forte para os dados dos clientes em todas as contas e proteções consistentes para aplicações web sem adicionar grande sobrecarga operacional.

Abordagem Recomendada:

Habilite o AWS Organizations e crie uma conta de Segurança (Security) dedicada; configure um CloudTrail em nível de organização que registre eventos de gerenciamento e de dados do S3 em um bucket S3 criptografado na conta de Segurança, usando uma KMS CMK pertencente à conta de Segurança.
Ative o GuardDuty, Security Hub, Macie e AWS Config na conta de Segurança e habilite a agregação em toda a organização para que as descobertas (findings) de todas as contas-membro fluam para a conta de Segurança para triagem.
Implante o AWS WAF no ALB com regras gerenciadas pela OWASP e habilite o AWS Firewall Manager para impor a mesma web ACL em todas as contas-membro; avalie o Shield Advanced para a loja virtual se o risco para a continuidade dos negócios for alto.
Use o IAM Identity Center (SSO federado) para acesso humano centralizado, imponha MFA e perfis de menor privilégio, e implemente playbooks de remediação automatizada (EventBridge -> Lambda) para descobertas (findings) de alta severidade do GuardDuty.

Justificativa: Centralizar logs e detecção em uma conta de segurança com trilhas criptografadas por CMK garante visibilidade resistente a adulterações e auditorias simplificadas, enquanto a imposição em nível de organização (Firewall Manager, SCPs) e a identidade federada reduzem o desvio de configuração (configuration drift) e os riscos relacionados a falhas humanas — alinhando-se com as melhores práticas de menor privilégio e defesa em profundidade.

← Redes e Entrega de Conteúdo · Todos os domínios · Faturamento →

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