Amazon DOP-C02: Segurança, Compliance e Governança — Guia de estudos

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

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

Visão Geral

Segurança, conformidade e governança na AWS dependem de controles determinísticos que escalam entre contas e Regiões sem desacelerar a entrega. Um design robusto combina camadas de controles de identidade (IAM, limites de permissão e políticas de controle de serviço), governança multi-contas (AWS Organizations e Control Tower), avaliação e remediação contínuas (AWS Config), detecção de ameaças (Security Hub, GuardDuty, Inspector), higiene de segredos, criptografia com AWS KMS e isolamento de rede (VPC security groups, NACLs, endpoints e PrivateLink). O objetivo é minimizar o raio de impacto (blast radius), comprovar a conformidade continuamente e automatizar a prevenção e a remediação, preservando o privilégio mínimo e a autonomia do desenvolvedor.

Identidade, Política e Governança Multi-Contas

IAM roles, políticas, limites de permissão e SCPs trabalham em conjunto para formar o conjunto de permissões efetivas. As políticas baseadas em identidade de uma IAM role definem as ações permitidas; a política de confiança (trust policy) da role define quem pode assumi-la. Os limites de permissão (permission boundaries) estabelecem um teto para o que um principal pode fazer, independentemente do que as políticas de identidade dizem. As SCPs no AWS Organizations definem o máximo absoluto para qualquer principal em uma conta-membro (incluindo o usuário root). Políticas baseadas em recursos (para S3, KMS, Secrets Manager, etc.) podem permitir acesso entre contas, mas também não podem exceder os limites impostos por SCPs ou permission boundaries. A permissão efetiva é a interseção de: políticas de identidade ∩ limite de permissão ∩ políticas de sessão (se presentes) ∩ política de recurso (se aplicável) ∩ SCPs, com qualquer Negação (Deny) explícita tendo precedência.

Use limites de permissão para habilitar o autoatendimento (self-service) seguro em uma única conta. Por exemplo, um pipeline de provisionamento para desenvolvedores pode criar roles apenas se anexar um limite que negue iam:PassRole, exceto para padrões específicos, negue kms:Decrypt em chaves sensíveis e limite os tipos de instância EC2. Os limites só podem ser anexados por principais que já possuem a permissão iam:PutRolePermissionsBoundary; proteja esse direito rigorosamente.

SCPs são barreiras de proteção (guardrails) para toda a organização. Guardrails comuns incluem proibir a desativação do AWS Config ou do CloudTrail, impedir convites de fora da Organização, negar alterações no administrador delegado do IAM Identity Center e restringir Regiões. Prefira padrões de permissão explícita por exceção com condições (por exemplo, permitir alterações por uma role de administração central) para minimizar o atrito. Sempre permita a criação e o uso das service-linked roles necessárias (por exemplo, para GuardDuty, Inspector, Config), ou suas SCPs bloquearão inadvertidamente a configuração de serviços.

O AWS Organizations fornece OUs hierárquicas para separar ambientes (ex: Sandbox, Dev, Prod), tipos de workload e vias de exceção. Herde SCPs das OUs-pai para evitar desvios de política (policy drift). Use o provisionamento de contas (account vending) para padronizar a configuração de contas: o Account Factory do AWS Control Tower (console) ou o Account Factory for Terraform (AFT) para integrar em CI/CD. O AFT adiciona fluxos de trabalho no estilo GitOps, detecção de desvios (drift detection) e feature flags (ex: provisionamento de Enterprise Support), e escala para centenas de contas com guardrails de base consistentes.

O AWS Control Tower automatiza uma landing zone com guardrails prescritivos. Os guardrails preventivos são SCPs que o Control Tower gerencia; os guardrails detectivos são regras do AWS Config que ele implanta. O Control Tower integra o IAM Identity Center para SSO e conjuntos de permissões (permission sets). Use permission sets baseados em ABAC com atributos para controle de acesso para definir o escopo das ações por aws:PrincipalTag ou atributos de identidade. Estenda a linha de base com Customizations for AWS Control Tower (CfCT) para implantar CloudFormation, SCPs e pacotes do Config por OU/conta automaticamente. Mantenha OUs de exceção para hospedar workloads que precisam de políticas personalizadas sem enfraquecer os guardrails globais.

Conformidade Contínua e Remediação Automatizada

Habilite o AWS Config em toda a organização a partir de uma conta de administrador delegado. Ative a gravação para todos os recursos em todas as Regiões e agregue a configuração de toda a Organização com um agregador organizacional. Use regras gerenciadas para controles comuns (ex: ebs-encryption-by-default, restricted-ssh, s3-bucket-level-public-access-prohibited) e crie regras personalizadas baseadas em Lambda para lógicas específicas (ex: verificar a cadência de rotação de chaves KMS em relação a uma política de 90 dias ou forçar tags e valores padrão). Pacotes de conformidade (conformance packs) agrupam regras, parâmetros e remediações em pacotes versionados e implantáveis por OU; mantenha-os em controle de versão e distribua via StackSets ou CfCT para consistência e auditabilidade.

A remediação automatizada fecha o ciclo. Mapeie a avaliação de não conformidade de cada regra para um runbook do SSM Automation que impõe a linha de base: anexe um instance profile padrão, aplique uma tag com um valor padrão, ative o Bloqueio de Acesso Público do S3 ou reinicie uma instância EC2 para manutenção. Use documentos parametrizados e entradas dinâmicas (ex: do achado do Config) para manter os runbooks genéricos. Para recursos de alto risco, configure a remediação para execução automática; para ações sensíveis, exija uma aprovação de mudança ou invocação manual via EventBridge e ChatOps. Proteja o próprio Config com SCPs que neguem a interrupção do gravador (recorder) ou a exclusão de canais de entrega, exceto por um administrador central.

O Firewall Manager complementa essa camada para política como serviço (policy-as-a-service) entre contas, usando o Organizations. Delegue um administrador central e crie políticas para associações de web ACLs do WAF em ALBs/API Gateway voltados para a internet, auditoria e limpeza de security groups de VPC ou propagação de regras do DNS Firewall. Isso muda a aplicação futura de detecção/remediação para prevenção.

Detecção de Ameaças, Higiene de Segredos e Gerenciamento de Vulnerabilidades

O Security Hub serve como o painel central (pane of glass) para descobertas (findings) entre contas e Regiões. Habilite-o com um administrador delegado, agregue as descobertas e ative os padrões relevantes (AWS Foundational Security Best Practices, CIS, PCI DSS quando aplicável). As descobertas fluem para o AWS Security Finding Format (ASFF), normalizando as entradas do GuardDuty, Inspector, IAM Access Analyzer, Config, Macie e ferramentas de parceiros. Configure padrões do EventBridge para rotear descobertas críticas para automações de remediação (SSM Automation, Lambda) e notificações (SNS, chat).

O GuardDuty fornece detecção de ameaças gerenciada sem exigir que você gerencie pipelines de logs do plano de dados. Ele analisa eventos de gerenciamento e de dados do CloudTrail, VPC Flow Logs, logs de consulta DNS do Route 53 Resolver e logs de auditoria do EKS para detectar comportamento anômalo, exfiltração de credenciais, mineração de criptomoedas, exfiltração de DNS e muito mais. Habilite o Malware Protection para escaneamento de S3 e EC2/EBS em caso de atividade suspeita. Use a habilitação automática em toda a organização e arquive sistematicamente as descobertas de baixo sinal com regras de supressão para focar naquilo que é acionável.

O Amazon Inspector avalia continuamente o EC2 (via agente SSM) em busca de CVEs de pacotes, imagens de contêiner do ECR em busca de vulnerabilidades antes da implantação, e funções Lambda em busca de CVEs em pacotes de código. O Inspector exige que as instâncias EC2 tenham o SSM Agent instalado, que o perfil da instância (instance profile) permita permissões de SSM e que haja saída (egress) para os endpoints do SSM/KMS (via VPC endpoints se a internet for restrita). Configure o Inspector para enviar as descobertas (findings) para o Security Hub e acionar fluxos de trabalho de patch com o Systems Manager Patch Manager ou remediação orientada por runbooks. Use tags para definir o escopo de quais recursos serão escaneados e para separar cargas de trabalho de sandbox daquelas regulamentadas.

O Secrets Manager centraliza o armazenamento, a rotação e o acesso entre contas a segredos (secrets) com forte capacidade de auditoria. Prefira o Secrets Manager em vez de parameter stores para credenciais que exigem rotação, aproveitando a rotação integrada para RDS/Aurora ou a rotação baseada em Lambda para sistemas externos. Rótulos de versionamento (Staging labels) (AWSCURRENT, AWSPREVIOUS) permitem rotação sem tempo de inatividade (zero-downtime). Execute as Lambdas de rotação em VPCs com os endpoints necessários (Secrets Manager, RDS, KMS) e restrinja a saída (egress). Para consumo entre contas, anexe uma política baseada em recursos que concede a entidades principais (principals) em outras contas a permissão GetSecretValue; garanta que a política da chave KMS para a CMK do segredo permita que as entidades principais (principals) do consumidor descriptografem e, se necessário, criem grants. Para recuperação de desastres ou controles de localidade, replique os segredos entre Regiões e alinhe as janelas de rotação.

Proteção de Dados e Segurança de Rede

Projete a criptografia usando o KMS com políticas de chave (key policies) explícitas. As políticas de chave, e não apenas as políticas do IAM, são as que autorizam em última instância os principals para operações criptográficas em uma CMK. Adote um modelo de política de chave baseado em funções (role-based) e de privilégio mínimo: delegue a administração a uma função (role) de administrador central do KMS; conceda direitos de uso de forma restrita às funções de workload; não permita o uso do curinga kms:* para evitar escalonamento acidental. Use chaves de condição (condition keys) (kms:EncryptionContext:*) para vincular a descriptografia a contextos esperados. Chaves Multi-Region permitem criptografia ativo-ativo onde os dados são replicados entre Regiões.

Grants são a ferramenta correta para delegar o uso de chaves de forma temporária ou com escopo restrito sem editar a política da chave, e são necessários para alguns fluxos de serviço (por exemplo, EC2 Auto Scaling usando launch templates criptografados, uso de AMI entre contas). Para permitir que outra conta crie grants, a política da chave deve permitir kms:CreateGrant para os principals daquela conta; o beneficiário da grant (grantee) deve fornecer um token de grant para uso imediato no mesmo caminho de chamada. Para AMIs criptografadas entre contas, copie e criptografe a AMI com uma CMK, compartilhe a AMI, permita que a conta de destino crie grants na CMK e faça com que a função vinculada ao serviço (service-linked role) de destino receba uma grant.

A criptografia de envelope (envelope encryption) é o padrão default: gere uma chave de dados com o KMS, criptografe os dados localmente com a chave de dados em texto plano e, em seguida, armazene apenas o texto cifrado e a chave de dados criptografada. Na leitura, chame a operação Decrypt do KMS para recuperar a chave de dados em texto plano na memória. Isso minimiza as chamadas ao KMS para payloads grandes e limita a exposição da chave em texto plano. Onde houver suporte, use o SSE-KMS gerenciado pelo serviço (S3, EBS, RDS) para simplicidade operacional, mas ainda assim alinhe as políticas de chave para produtores/consumidores entre contas.

A segurança da VPC começa com security groups de privilégio mínimo. Security groups são stateful; o tráfego de retorno é implícito. Prefira referências a security groups em vez de regras baseadas em CIDR para evitar listas de permissão de IP (allow-lists) frágeis e para manter a intenção com o código da infraestrutura. As permissões de saída (outbound) padrão são arriscadas; restrinja explicitamente o tráfego de saída (egress) para os destinos necessários e use endpoints da VPC para acesso a serviços da AWS. As NACLs são stateless e avaliadas primeiro; mantenha-as como controles de granularidade grossa no nível da sub-rede, com retornos explícitos para portas efêmeras apenas quando você precisar implementar uma fronteira adicional ou atender a requisitos regulatórios; caso contrário, prefira os security groups pela sua capacidade de gerenciamento.

Elimine dependências da internet usando endpoints da VPC. Endpoints de gateway (S3, DynamoDB) roteiam o tráfego de forma privada pela rede da AWS; associe uma política de endpoint para restringir os buckets ou tabelas acessíveis. Endpoints de interface (AWS PrivateLink) expõem serviços da AWS (Secrets Manager, KMS, SSM, ECR, CloudWatch) por meio de IPs privados; implante-os em sub-redes com os security groups corretos e habilite o DNS Privado para que os nomes de serviço padrão resolvam para endereços privados. Para microsserviços produtor-consumidor entre contas/VPCs, publique um serviço de endpoint baseado em NLB e faça com que os consumidores criem endpoints de interface para ele via PrivateLink, evitando peering ou transit gateways e mantendo o tráfego fora da internet pública. Combine esses controles com sub-redes sem NAT e sem IGW, e com inspeção de saída (egress) centralizada onde o acesso à internet for necessário.

Cenário de Problema Prático

O Expedia Group está se expandindo para centenas de contas AWS em múltiplas Regiões e precisa impor uma linha de base de segurança (baseline) rigorosa: sem saída para a internet para workloads, remediação automatizada de configurações incorretas, detecção de ameaças centralizada, rotação de segredos (secrets) e compartilhamento controlado entre contas de AMIs criptografadas para imagens padrão (golden images).

Estabelecer governança multi-contas com AWS Organizations e AWS Control Tower

Ação: Criar OUs para Sandbox, Dev, Prod e Security. Implantar o Control Tower para estabelecer a landing zone, habilitar guardrails obrigatórios e integrar o IAM Identity Center. Usar o Account Factory for Terraform (AFT) para fornecer contas via GitOps.
Por quê: O Control Tower fornece guardrails prontos para uso (turnkey) e aplicados continuamente (SCPs e regras do Config). O AFT padroniza o provisionamento de contas em escala e codifica as baselines em controle de versão.

Criar SCPs para impor guardrails globais com exceções

Ação: Anexar SCPs que neguem a desativação do CloudTrail e do AWS Config, restrinjam Regiões e impeçam ACLs públicas no S3. Incluir exceções baseadas em condição para uma função de administrador de segurança (security-admin role) na OU de Segurança. Permitir a criação/uso das funções vinculadas ao serviço (service-linked roles) necessárias.
Por quê: As SCPs limitam os privilégios de todos os principals, incluindo o root, prevenindo desvios de configuração (drift) e permitindo exceções controladas para operações centrais.

Implantar pacotes de conformidade (conformance packs) do Config com remediação automatizada

Ação: A partir da conta de administrador delegado de Segurança, habilitar o AWS Config em toda a organização e criar um agregador. Distribuir um pacote de conformidade que imponha a criptografia de EBS por padrão, SSH restrito, tags obrigatórias com valores padrão e WAF obrigatório em pontos de entrada públicos. Mapear cada regra para documentos do SSM Automation para correções automáticas (por exemplo, anexar o perfil de instância padrão, definir tags ausentes como ‘weekly’).
Por quê: Pacotes de conformidade entregam política como código (policy-as-code) consistente e auditável com auto-remediação que mantém os ambientes em um estado de conformidade sem a sobrecarga de tickets.

Centralizar a detecção com Security Hub, GuardDuty e Inspector

Ação: Habilitar o GuardDuty e o Inspector em toda a organização com um administrador delegado. Habilitar os padrões do Security Hub (AWS FSBP e CIS) e agregar os resultados (findings). Criar regras no EventBridge para rotear resultados de alta severidade para runbooks do SSM Automation e um tópico SNS para a equipe de plantão (on-call).
Por quê: A detecção gerenciada e a avaliação de vulnerabilidades fornecem cobertura contínua com sobrecarga operacional mínima, e o Security Hub consolida os sinais para triagem e resposta mais rápidas.

Impor privilégio mínimo no IAM com permission boundaries e ABAC

Ação: Nas contas provisionadas pelo AFT, exigir que as funções (roles) criadas por desenvolvedores anexem um permission boundary que negue iam:PassRole, exceto para funções selecionadas, e limite APIs de alto impacto. Usar conjuntos de permissões (permission sets) do IAM Identity Center com ABAC para definir o escopo das ações por tags de equipe.
Por quê: Permission boundaries permitem um autoatendimento seguro, prevenindo a escalada de privilégios; o ABAC reduz a proliferação de políticas e permanece alinhado com os atributos de identidade.

Fortalecer os caminhos de rede com endpoints da VPC e PrivateLink

Ação: Remover IGWs/NATs das sub-redes de aplicação. Criar endpoints de interface para KMS, Secrets Manager, SSM, ECR, CloudWatch e endpoints de gateway para S3/DynamoDB com políticas de endpoint restritivas. Publicar serviços de plataforma internos via NLBs com PrivateLink para consumo entre contas.
Por quê: A conectividade privada elimina a exposição à internet e garante que os serviços permaneçam acessíveis em ambientes restritos (locked-down).

Implementar estratégia de chaves KMS com grants para AMIs entre contas

Ação: Criar CMKs por ambiente com políticas de chave com escopo de função (role). Na conta de construção de imagens, criptografar as golden AMIs e compartilhá-las. Atualizar a política da CMK para permitir que as contas de destino criem grants e, em seguida, criar grants para as funções vinculadas ao serviço (service-linked roles) nessas contas de destino.
Por quê: Grants fornecem delegação com escopo definido e auditável sem a necessidade de editar as políticas de chave para cada consumidor, permitindo que o Auto Scaling inicie instâncias a partir de AMIs criptografadas entre contas.

Padronizar a rotação de segredos e o acesso entre contas

Ação: Armazenar credenciais de banco de dados e API no Secrets Manager. Implementar rotação via Lambda para alvos não-RDS e habilitar a rotação nativa para o RDS. Para segredos de plataforma compartilhados, anexar políticas baseadas em recursos concedendo GetSecretValue para as funções (roles) consumidoras em outras contas e garantir que as políticas da CMK permitam a descriptografia. Posicionar as Lambdas de rotação em VPCs com os endpoints necessários.
Por quê: A rotação automatizada reduz o risco de credenciais; políticas de recursos alinhadas com o KMS permitem o consumo seguro entre contas, preservando o privilégio mínimo e as trilhas de auditoria.

Essa arquitetura oferece ao Expedia Group guardrails aplicáveis, conformidade comprovável, correções automatizadas e caminhos de acesso a dados rigorosamente controlados, tudo isso enquanto preserva a velocidade do desenvolvedor por meio de autoatendimento seguro e conectividade privada.

← Monitoramento · Todos os domínios · Contêineres e Operações Serverless →

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