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

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

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

Este domínio abrange os primitivos de identidade, criptografia, segredos e auditoria que sustentam operações seguras e em conformidade na AWS. Ele se concentra em conceder o acesso correto (princípio do menor privilégio), proteger dados por meio do gerenciamento de chaves e criptografia, e criar trilhas de auditoria imutáveis para conformidade contínua. As responsabilidades diárias de SysOps incluem projetar roles do IAM e limites de confiança (trust boundaries), operar chaves e segredos do KMS, e usar o AWS Config e o CloudTrail para detectar desvios (drift) e violações de políticas.

IAM, roles, políticas e federação

A governança do IAM deve começar com a separação de funções (roles) e o princípio do menor privilégio: use roles separadas para administração, logging e cargas de trabalho de aplicações; evite anexar políticas amplas como a AdministratorAccess a principais (principals) de longa duração. Crie roles com uma política de confiança (trust policy) (pelo console ou CLI:

undefined

) e anexe políticas de permissão usando

undefined

ou políticas gerenciadas (managed policies). Use limites de permissão (permission boundaries) e Condições do IAM (

undefined

) para limitar onde e como os privilégios podem ser exercidos.

Para federação de identidade, prefira SAML/OIDC para emitir credenciais temporárias via STS. Para SAML, configure um provedor de identidade no IAM e use

undefined

. Para OIDC (Cognito, Auth0 ou outros provedores), crie um provedor OIDC no IAM e mapeie as claims para as roles; a federação de identidade da web usa

undefined

. Escolha roles federadas quando os usuários são externos ou quando serviços de diretório central gerenciam a autenticação; use o AWS IAM Identity Center (SSO) para acesso empresarial centralizado e gerenciamento de sessões.

KMS, gerenciamento de chaves e criptografia

O KMS é o serviço central para o ciclo de vida e controle de acesso de chaves. Escolha entre chaves gerenciadas pela AWS (simplicidade), chaves de propriedade da AWS e CMKs gerenciadas pelo cliente (controle granular). Crie CMKs com

undefined

e habilite a rotação automática com

undefined

. Use políticas de chave (key policies) para definir quem pode gerenciar as chaves e use concessões (grants) para delegação de acesso temporário (

undefined

), em vez de políticas do IAM amplas.

Critérios de decisão: use CMKs quando auditoria e controle do ciclo de vida da chave (rotação, janelas de exclusão) são necessários; use chaves gerenciadas pela AWS para conveniência automática em muitos serviços gerenciados. Proteja as chaves aplicando políticas do IAM + políticas de chave, restrinja o uso via

undefined

ou concessões do KMS para uso entre contas (cross-account), e evite agendar a exclusão imediata — use uma janela de espera mínima. Monitore o uso do KMS com logs do CloudTrail para operações de Encrypt/Decrypt e GenerateDataKey para detectar uso anômalo.

Gerenciamento de segredos e parameter stores

Use o AWS Secrets Manager para rotação de credenciais e automação do ciclo de vida, e o Systems Manager Parameter Store (SecureString) para segredos mais simples onde a rotação é manual. Crie segredos via

undefined

e habilite a rotação especificando uma função Lambda para rotação automática. Para o Parameter Store, use

undefined

Pontos de decisão:

Secrets Manager: rotação integrada, versionamento de segredos, replicação e modelos de rotação integrados no console; custo mais alto, mas melhor para credenciais de banco de dados e chaves de API.
Parameter Store SecureString: nível gratuito (free tier) para armazenamento básico de segredos, use uma CMK do KMS para criptografia e políticas do IAM para acesso. Sempre restrinja o acesso a segredos por meio de políticas do IAM de menor privilégio e prefira o acesso baseado em roles (roles de execução do EC2/ECS/Lambda), em vez de incorporar credenciais de longa duração no código ou em variáveis de ambiente.

AWS Config, auditoria e monitoramento de conformidade

O AWS Config fornece registro contínuo de recursos, histórico de alterações e avaliação de regras. Habilite um gravador (recorder) e um canal de entrega (pelo console ou

undefined

) e crie regras gerenciadas ou personalizadas com

undefined

. Combine o Config com o CloudTrail (

undefined

) e os CloudWatch Alarms para detecção e remediação quase em tempo real (use ações de remediação do Config ou documentos do Systems Manager Automation).

Decisões de design: use regras gerenciadas do Config para verificações padrão (bucket S3 com leitura pública, MFA na conta root) e regras personalizadas (Lambda) para controles específicos do domínio. Garanta a agregação de dados do Config de múltiplas regiões em um agregador e habilite o registro em múltiplas contas via AWS Organizations. Mantenha uma trilha de auditoria imutável enviando os logs do CloudTrail para um bucket S3 central criptografado (SSE-KMS) e habilite o CloudTrail Insights para atividades anômalas de API.

Proteção de dados, criptografia em trânsito e em repouso

A criptografia deve ser aplicada em camadas: em repouso (at rest) usando criptografia baseada no KMS para EBS, RDS, S3 (SSE-S3, SSE-KMS ou SSE-C) e em trânsito (in transit) usando TLS para o tráfego de aplicações (use o ACM para certificados públicos/privados e anexe-os a listeners de ALB/NLB:

undefined

). Use criptografia do lado do cliente (client-side) onde controle adicional é necessário e considere a criptografia de envelope (envelope encryption) com

undefined

ao criptografar grandes volumes de dados fora das cotas do KMS.

Aplique estes critérios de decisão:

Use SSE-KMS para objetos S3 quando precisar de auditoria e controles de acesso à chave; SSE-S3 é suficiente para criptografia básica do lado do servidor.
Use CMKs do KMS para EBS e RDS quando precisar de rotação de chaves e controle de acesso entre contas (cross-account).
Sempre imponha o uso de TLS para endpoints de serviço; use HSTS e cifras fortes (strong ciphers) nos load balancers.
Use VPC endpoints e políticas do IAM para reduzir a exposição pública das APIs do plano de dados (data-plane).

Armadilhas Comuns e Critérios de Decisão

Uso excessivo da conta raiz ou armazenamento de suas credenciais: em vez disso, crie funções de administrador com MFA e use o AWS SSO ou funções do IAM para tarefas diárias; guarde as credenciais da conta raiz em um cofre seguro e habilite o MFA.
Depender de chaves de acesso de longa duração: rotacione as chaves regularmente ou elimine-as em favor de credenciais temporárias via STS e encadeamento de funções (role chaining) (funções do EC2/ECS/Lambda).
Não rotacionar ou proteger indevidamente as chaves do KMS e os segredos: habilite a rotação automática para CMKs quando apropriado, use a rotação do Secrets Manager para credenciais de banco de dados e monitore o uso das chaves via CloudTrail.
Depender das permissões padrão do S3 ou de ACLs: aplique políticas de bucket (bucket policies), bloqueie o acesso público e use SSE-KMS para dados sensíveis; valide com regras do AWS Config.
Uso incorreto de políticas de chave (key policies) em vez de políticas do IAM (IAM policies): gerencie a administração da chave na política da chave do KMS (key policy) e conceda o uso por meio de grants ou do IAM quando apropriado; evite conceder a permissão Decrypt de forma ampla.
Esquecer de centralizar os logs e da agregação multirregional: configure trilhas multirregionais do CloudTrail e agregadores do Config para conformidade entre contas (cross-account).

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

A AcmeFin, uma empresa de fintech, precisa proteger seus bancos de dados e APIs de produção ao mesmo tempo em que fornece acesso temporário a prestadores de serviço (contractors) e mantém a auditabilidade para auditorias de conformidade (compliance).

Crie funções do IAM separadas para acesso de administrador, de aplicação e de prestador de serviço; exija o uso de MFA e use o IAM Identity Center para federação baseada em SAML para os prestadores de serviço.
Criptografe o RDS e o EBS com uma CMK gerenciada pelo cliente (aws kms create-key), habilite a rotação de chaves e restrinja o uso da chave por meio de uma política de chave (key policy) restrita, permitindo apenas as funções de banco de dados e de auditoria.
Armazene as credenciais do banco de dados no AWS Secrets Manager com rotação automatizada, usando o modelo de rotação do Lambda fornecido.
Habilite o CloudTrail (multirregional) e o gravador do AWS Config, envie os logs para um bucket S3 central criptografado com SSE-KMS e crie regras do Config para buckets S3 públicos e recursos não criptografados.
Use um ALB com certificados emitidos pelo ACM para HTTPS e posicione as APIs atrás de um WAF e de VPC endpoints quando apropriado.

Essa abordagem impõe o princípio do menor privilégio por meio da separação de funções, automatiza a rotação de credenciais e chaves para reduzir o raio de impacto (blast radius) e centraliza os logs e as avaliações do Config para que os auditores possam verificar os controles, enquanto as equipes de operações mantêm padrões de acesso seguros e temporários.

← Implantação · Todos os domínios · Redes e Entrega de Conteúdo →

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