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

By Laurynas Brazys · 31 July 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

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

Gerenciamento de Identidade e Acesso: controle baseado em princípios e federação

O gerenciamento de identidade deve ser projetado em torno de credenciais de curta duração e com o menor privilégio, e com uma separação clara entre a confiança da identidade e a concessão de permissões. Use IAM roles para todo acesso de computação e entre contas, evite chaves de acesso de longa duração de usuários IAM e utilize o STS para credenciais temporárias. Para federação empresarial com SAML ou OIDC, configure um provedor de identidade (IdP) centralizado e habilite o acesso baseado em atributos usando tags de sessão, para que as permissões acompanhem usuários e grupos sem a necessidade de gerenciar usuários em cada conta. O IAM Identity Center (IAM Identity Center) fornece conjuntos de permissões para toda a organização, provisionamento SCIM para replicar grupos na AWS e se integra com a imposição de MFA do IdP para atender aos requisitos de autenticação forte. Complemente os controles de identidade com limites de permissão (permission boundaries) e políticas gerenciadas para limitar o escalonamento de privilégios, e execute o IAM Access Analyzer para detectar acessos não intencionais a recursos. As Políticas de Controle de Serviço (SCPs) no AWS Organizations oferecem barreiras de proteção (guardrails) ao negar categorias inteiras de ações em todas as OUs, mas elas não concedem permissões — políticas de confiança e políticas de permissão continuam sendo necessárias. Armadilhas comuns incluem ações ou principais (principals) com curingas (wildcards) muito amplos, depender da conta raiz (root), a falta de IDs externos para acesso de terceiros e o encadeamento de roles (role chaining) que estende o escopo da sessão efetiva. Os trade-offs são o custo operacional versus uma granularidade mais rígida: roles altamente granulares exigem mais gerenciamento, mas reduzem significativamente o raio de alcance do impacto (blast radius).

Chaves, segredos e criptografia: ciclo de vida e padrões entre contas

A criptografia é fundamental para controles tanto em repouso (at-rest) quanto em trânsito (in-transit); as decisões devem equilibrar a propriedade da chave, o controle operacional e o desempenho. Use CMKs gerenciadas pelo cliente (customer-managed) do AWS KMS quando precisar de políticas de chave granulares, concessões entre contas, auditabilidade ou rotação automática. Para a conveniência do gerenciamento pelo serviço, as chaves gerenciadas pela AWS (AWS-managed) reduzem o custo operacional, mas limitam o controle sobre as políticas. A criptografia de envelope (envelope encryption) mitiga o impacto no desempenho para cargas de dados grandes, usando uma chave de dados (data key) para a criptografia em massa e o KMS para “envelopar” (wrapping) essa chave. O uso entre contas ou entre Regiões exige políticas de chave e Grants explícitos; evite conceder apenas permissões do IAM sem a política de chave correspondente. O Secrets Manager oferece fluxos de trabalho de rotação e integração nativa com o RDS e outros serviços, enquanto o SSM Parameter Store (SecureString) é uma opção de menor custo para necessidades menores; ambos devem usar endpoints da VPC para evitar a saída para a internet pública. Armadilhas comuns de arquitetura incluem conceder kms:* ou direitos de Decrypt muito amplos nas políticas de chave, esquecer de permitir que as execution roles do Lambda tenham permissões tanto de IAM quanto de KMS, e negligenciar a replicação multirregional para chaves usadas por cargas de trabalho distribuídas globalmente. Os trade-offs de custo-desempenho incluem o custo por requisição do KMS e uma pequena latência adicional versus os benefícios de segurança do controle de chaves gerenciadas pelo cliente.

Detecção, monitoramento e auditoria: telemetria, controles de detecção e automação

Controles de detecção são tão importantes quanto os preventivos; a instrumentação deve ser centralizada, imutável e pesquisável. Habilite o AWS CloudTrail multirregional e para múltiplas contas com validação de arquivos de log e entregue os logs a uma conta S3 centralizada, com acesso controlado e políticas de ciclo de vida. Envie os logs do CloudTrail, VPC Flow Logs e DNS para um pipeline de análise centralizado — CloudWatch Logs, Kinesis Data Firehose e um SIEM — para retenção e alertas. O GuardDuty fornece detecção gerenciada de ameaças para comportamentos da conta e da carga de trabalho; designe um administrador delegado para agregar os achados (findings) de toda a Organization e automatizar a resposta via EventBridge para acionar playbooks do Lambda ou o Systems Manager Automation. O Security Hub agrega padrões e achados (findings) (CIS, PCI, regras personalizadas) e pode orquestrar a remediação priorizada. O AWS Config e as Config Rules permitem verificações contínuas de conformidade e detecção de desvios (drift), com remediação usando o SSM Automation. Armadilhas típicas incluem CloudTrail em uma única região, retenção insuficiente ou logs não imutáveis, alertas ruidosos sem ajuste fino e a falta de administradores delegados para escalar a detecção. Os trade-offs dependem dos custos de retenção versus as necessidades forenses e de conformidade: uma retenção mais longa ajuda nas investigações, mas aumenta os custos de S3 e de consulta.

Defesa na camada de aplicação, WAF, Shield e governança multi-contas

A proteção de aplicações voltadas para a internet exige controles em camadas e gerenciamento centralizado de políticas. Posicione o AWS WAF na borda (CloudFront) e/ou em ALBs regionais para filtrar ameaças da classe OWASP, tráfego de bots e para implementar limitação de taxa (rate limiting). Para o gerenciamento de regras em múltiplas contas, use o AWS Firewall Manager com uma conta de segurança delegada para implantar grupos de regras do WAFv2, assinaturas do Shield Advanced e políticas de segurança centralizadas em todas as OUs. O Shield Advanced oferece mitigação de DDoS e proteção de custos para eventos de grande escala, mas é caro; pondere o SLA e a exposição a DDoS da sua aplicação em relação ao preço da assinatura. Use Web ACLs centralizadas, grupos de regras gerenciadas (managed rule groups) e atualizações refinadas de conjuntos de IPs (IP sets) para reduzir a sobrecarga operacional e evitar proteções inconsistentes. As armadilhas de arquitetura incluem depender apenas de security groups na camada de rede, falhar em centralizar a implantação de regras (levando a desvios ou ‘drift’) ou posicionar o WAF apenas regionalmente quando a proteção global de CDN é necessária. As desvantagens de desempenho (trade-offs) incluem a possível latência adicionada pela inspeção e a complexidade de regras personalizadas em contraste com a resiliência obtida ao bloquear o tráfego malicioso antes que ele atinja os servidores de origem. Garanta que os logs e métricas do WAF estejam ativados e integrados com o Security Hub/GuardDuty para uma resposta a incidentes coesa.

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

Cenário: A OmniApps Ltd. possui uma AWS Organization com uma conta de gerenciamento (management account), uma conta de rede centralizada que hospeda um Transit Gateway e várias contas de carga de trabalho (workload) em eu-west-1 e us-east-1. Eles executam stacks de aplicações privadas em VPCs com ALBs em sub-redes privadas, expostos através do CloudFront, e precisam de controles centralizados de identidade e segurança.

Desafio: A OmniApps precisa centralizar o acesso com MFA corporativo baseado em SAML, aplicar barreiras de proteção (guardrails) de segurança em toda a organização, gerenciar regras de WAF e proteção contra DDoS entre as contas, e manter segredos e chaves acessíveis apenas por caminhos de rede privados.

Abordagem Recomendada:

Habilite o IAM Identity Center na conta de gerenciamento e conecte-o ao IdP SAML corporativo com MFA obrigatório; configure o provisionamento SCIM e crie conjuntos de permissões (permission sets) para acesso entre contas com o menor privilégio (least-privilege).
Implemente Service Control Policies (SCPs) no Organizations para negar ações de root não gerenciadas e exigir o CloudTrail/Config; designe uma conta de segurança como administrador delegado para o Security Hub, GuardDuty e Firewall Manager.
Use o AWS Firewall Manager a partir da conta de segurança para implantar Web ACLs do AWS WAFv2 e AWS Managed Rules nas distribuições do CloudFront e nos ALBs entre as contas; avalie a assinatura do Shield Advanced por aplicação crítica.
Centralize os logs do CloudTrail em uma conta de logging segura, criptografados com uma CMK multi-regional na conta de segurança, conceda a permissão de decriptografia por meio de uma política de chave (key policy) explícita do KMS e Grants para os processadores de log, e habilite VPC endpoints para o KMS e o Secrets Manager para acesso privado.

Justificativa: A identidade centralizada e a administração de segurança delegada reduzem o atrito administrativo e o raio de impacto (blast radius), enquanto o Firewall Manager e o logging centralizado fornecem aplicação consistente de políticas e capacidades forenses alinhadas com as melhores práticas de arquitetura profissional.

← Redes e Conectividade Híbrida · Todos os domínios · Computação e Auto Scaling →

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