Amazon SCS-C02: Governança, Configuração e Automação — 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.

Políticas de Controle de Serviço e Barreiras de Proteção em Nível de Organização

As Políticas de Controle de Serviço (SCPs) formam o limite mais externo do que qualquer principal em uma AWS Organization pode fazer. Uma SCP não é uma política do IAM — ela não concede nada, apenas define as permissões máximas disponíveis para as contas sob uma OU ou para toda a organização. Um Allow em uma política do IAM, política de recurso ou limite de permissões (permissions boundary) é completamente inerte se uma SCP negar a ação. Essa assimetria é exatamente o motivo pelo qual as SCPs são a ferramenta correta para barreiras de proteção em toda a organização: restrições de Região, serviços proibidos, proteção de funções do IAM gerenciadas centralmente e imposição de criptografia na criação de recursos.

Uma SCP canônica que nega a criação de tabelas do DynamoDB e buckets do S3 não criptografados se parece com isto:

Version: "2012-10-17"
Statement:
  - Sid: DenyUnencryptedS3
    Effect: Deny
    Action: s3:CreateBucket
    Resource: "*"
    Condition:
      StringNotEquals:
        s3:x-amz-server-side-encryption-aws-kms-key-id: !Ref CmkArn
  - Sid: DenyUnencryptedDdb
    Effect: Deny
    Action: dynamodb:CreateTable
    Resource: "*"
    Condition:
      "Null":
        dynamodb:SSESpecificationEnabled: "true"

Uma armadilha comum é tentar impor “ninguém na organização pode usar us-east-2” ou “ninguém pode desabilitar o CloudTrail” por meio de políticas do IAM anexadas em cada conta. Mesmo com um limite de permissões e alinhamento de políticas de identidade, um administrador local pode conceder a si mesmo uma rota de fuga. Apenas uma SCP aplicada na raiz ou em uma OU é confiável, pois restringe até mesmo o usuário root das contas-membro (com a pequena exceção de um punhado de ações não restringíveis).

As SCPs também devem proteger funções de acesso de emergência (break-glass) e de administração delegada: adicione um Deny explícito em qualquer ação que vise uma função como OrganizationAccountAccessRole ou SecurityAudit, a menos que o aws:PrincipalArn do chamador corresponda a uma lista aprovada.

AWS Config, Pacotes de Conformidade e Aplicação Multi-Contas

O AWS Config fornece a camada de avaliação contínua que complementa as SCPs (que previnem) com a detecção (que observa e relata desvios). Um pacote de conformidade (conformance pack) é um conjunto de regras do Config — tanto regras gerenciadas como s3-bucket-server-side-encryption-enabled quanto regras personalizadas baseadas em Lambda ou Guard — empacotado como um único artefato YAML implantável com ações de remediação opcionais.

Para implementar uma linha de base padrão em toda a organização, dois mecanismos são combinados:

• CloudFormation StackSets a partir da conta de gerenciamento com permissões gerenciadas pelo serviço e AutoDeployment: Enabled para que qualquer nova conta que entre na organização receba automaticamente uma stack que ativa o gravador (recorder) e o canal de entrega (delivery channel) do Config. Isso resolve o problema de bootstrap: um pacote de conformidade não pode avaliar uma conta onde o Config não está habilitado.

• Pacotes de conformidade implantados a partir da conta de administrador delegado (por exemplo, security-01) usando PutOrganizationConformancePack. Isso propaga um conjunto de regras consistente para todas as contas atuais e futuras sem a necessidade de intervir em cada conta manualmente.

O padrão de administrador delegado + agregador é importante: ele permite que a equipe de segurança veja a conformidade de todas as contas em um único lugar, ao mesmo tempo que permite que as equipes de aplicação adicionem suas próprias regras localmente. Implantar as mesmas regras diretamente da conta de gerenciamento funcionaria, mas viola o princípio do menor privilégio e impede auditorias de separação de funções.

CloudFormation Guard, StackSets e Service Catalog

A prevenção deve ser antecipada (shift left). O CloudFormation Guard (cfn-guard) é um mecanismo de política como código (policy-as-code) que analisa templates do CloudFormation (ou qualquer JSON/YAML) e os avalia em relação a regras declarativas antes da implantação. Uma regra do Guard se parece com isto:

rule s3_encrypted {
  Resources.*[ Type == "AWS::S3::Bucket" ] {
    Properties.BucketEncryption exists
    Properties.BucketEncryption.ServerSideEncryptionConfiguration[*] {
      ServerSideEncryptionByDefault.SSEAlgorithm == "aws:kms"
    }
  }
}

Integrar isso a um estágio de CI/CD — geralmente como uma etapa de contêiner Docker que executa cfn-guard validate -r rules.guard -d template.yaml — falha o pipeline antes que qualquer recurso não conforme seja criado. Em caso de violação, o pipeline publica em um tópico SNS ao qual a equipe de segurança está inscrita, dando-lhes visibilidade sem se tornar um gargalo de aprovação manual. Confiar apenas em StackSets ou na revisão de change-sets do CloudFormation para notificar a equipe de segurança é uma armadilha: nenhum dos serviços emite resultados de conformidade por recurso, e no momento em que uma stack é criada, o recurso já existe na conta.

O Service Catalog complementa o Guard na etapa final. Em vez de permitir que os desenvolvedores escrevam CloudFormation arbitrário, a equipe de plataforma publica produtos validados (linhas de base de VPC, padrões de RDS, clusters EKS) como portfólios do Service Catalog compartilhados entre contas via AWS RAM. Os desenvolvedores os lançam com parâmetros restritos, e uma função do IAM de restrição de lançamento (launch constraint) provisiona recursos com permissões elevadas que o desenvolvedor pessoalmente não possui. Isso proporciona um modelo de implantação de autoatendimento (self-service) auditável, onde o template subjacente já passou pelas verificações do Guard.

Os próprios StackSets precisam da configuração correta: use o modelo de permissão SERVICE_MANAGED ao implantar a partir da conta de gerenciamento da organização, habilite o acesso confiável (trusted access) para o CloudFormation no Organizations e configure as funções de execução com cuidado. O par AdministrationRoleARN/ExecutionRoleName (no modo autogerenciado) ou as funções vinculadas ao serviço (service-linked roles) (no modo gerenciado pelo serviço) devem ter a permissão iam:PassRole para a função de serviço do CloudFormation que de fato cria os recursos. Esquecer de anexar uma função de serviço do CloudFormation e, em vez disso, depender das credenciais do usuário que está implantando, leva a erros intermitentes de AccessDenied em iam:PassRole — uma causa comum de falha nas operações de StackSet. O padrão correto é uma função de serviço dedicada por stack, com apenas as permissões necessárias para criar os tipos de recursos declarados.

AWS Config: Regras de Organização, Agregadores e Administração Delegada

O AWS Config é a base para a conformidade detectiva na AWS. Ele registra continuamente as configurações dos recursos e as avalia em relação a regras — sejam elas gerenciadas pela AWS (por exemplo, restricted-ssh, vpc-flow-logs-enabled, encrypted-volumes) ou personalizadas (com suporte do Lambda ou Guard). Em escala empresarial, três decisões de arquitetura são mais importantes do que as próprias regras: como as regras são implantadas, como os resultados são agregados e quem é o dono das ferramentas.

Para implantações multi-contas e multi-regiões no AWS Organizations, o padrão correto é designar uma conta de administrador delegado (geralmente a conta de segurança ou auditoria, não a conta de gerenciamento) via aws organizations register-delegated-administrator --service-principal=config-multiaccountsetup.amazonaws.com. A partir dessa conta, use PutOrganizationConfigRule ou PutOrganizationConformancePack para distribuir as regras para cada conta-membro e região. Ignorar a administração delegada força você a habilitar o Config manualmente em cada conta ou a executar tudo a partir da conta de gerenciamento — a última opção viola a separação de responsabilidades e a primeira não escala além de um punhado de contas.

As regras de organização enviam uma única definição de regra; os agregadores coletam as avaliações resultantes. Crie um agregador na conta de administrador delegado com um OrganizationAggregationSource que cubra todas as contas e regiões. O painel do agregador então responde a perguntas como “quais VPCs em 200 contas não têm Flow Logs?” sem a complexidade de alternar roles entre contas. Note que os agregadores são somente leitura: eles expõem o estado de conformidade, mas não realizam a remediação por si mesmos.

Pacotes de Conformidade para Aplicação de Linhas de Base

Um pacote de conformidade agrupa regras do Config e suas ações de remediação em um único modelo YAML. A AWS fornece pacotes mapeados para frameworks como PCI DSS, HIPAA, NIST 800-53 e CIS. Implantar um pacote de conformidade da organização a partir do administrador delegado permite direcionar OUs específicas — por exemplo, aplicando um pacote mais rigoroso à OU Prod do que à Sandbox. Esta é a maneira mais eficiente de aplicar uma linha de base consistente em centenas de contas, pois uma única chamada de API propaga o conjunto de regras e sua estrutura de remediação para todos os lugares de uma só vez.

Resources:
  EncryptedVolumesRule:
    Type: AWS::Config::ConfigRule
    Properties:
      ConfigRuleName: encrypted-volumes
      Source:
        Owner: AWS
        SourceIdentifier: ENCRYPTED_VOLUMES
  EncryptedVolumesRemediation:
    Type: AWS::Config::RemediationConfiguration
    Properties:
      ConfigRuleName: encrypted-volumes
      TargetType: SSM_DOCUMENT
      TargetId: AWSConfigRemediation-EncryptS3BucketVolume
      Automatic: true
      MaximumAutomaticAttempts: 3
      RetryAttemptSeconds: 60

Padrões de Remediação Automática

Existem dois caminhos canônicos de remediação, e a escolha entre eles depende dos requisitos de latência e complexidade.

O caminho de remediação nativa do Config usa AWS::Config::RemediationConfiguration para invocar um runbook do SSM Automation sempre que uma regra reporta NON_COMPLIANT. A AWS fornece runbooks pré-construídos, como AWS-EnableVPCFlowLogs, AWSConfigRemediation-RemoveUnrestrictedSourceIngressRules e AWSConfigRemediation-EncryptSNSTopic. Este caminho é declarativo, integra-se bem com pacotes de conformidade e é ideal quando um atraso de vários minutos é aceitável.

O caminho orientado pelo EventBridge é necessário quando a latência é importante ou quando uma orquestração personalizada é necessária. O Config emite um evento Config Rules Compliance Change a cada transição de estado. Uma regra do EventBridge filtra por detail.newEvaluationResult.complianceType = NON_COMPLIANT e direciona para uma função Lambda (ou Step Function, ou diretamente para um runbook do SSM). Como o EventBridge dispara em segundos após a avaliação, janelas de remediação abaixo de um minuto se tornam viáveis.

{
  "source": ["aws.config"],
  "detail-type": ["Config Rules Compliance Change"],
  "detail": {
    "configRuleName": ["restricted-ssh"],
    "newEvaluationResult": { "complianceType": ["NON_COMPLIANT"] }
  }
}

O handler do Lambda então chama RevokeSecurityGroupIngress no SG infrator. Qualquer que seja o caminho escolhido, a automação deve assumir uma role do IAM com as permissões mínimas para modificar o recurso de destino. Um modo de falha frequente é uma regra do Config que mostra o status de conformidade alternando indefinidamente entre NON_COMPLIANT e COMPLIANT porque o runbook de remediação encontra um erro de AccessDenied — o Config registra a invocação, mas prossegue silenciosamente. Sempre inspecione o histórico de execução do SSM Automation e conceda à role do runbook as permissões de modificação específicas de que ela precisa (por exemplo, ec2:CreateFlowLogs, iam:PassRole para a role de entrega do flow-log e logs:CreateLogGroup).

Systems Manager Automation e Patch Manager

Os runbooks do SSM Automation são a principal ferramenta para remediação imperativa. Eles são documentos YAML/JSON versionados que descrevem passos — chamadas de API, aprovações, ramificações — executados por uma role do IAM que você especifica. Além da remediação acionada pelo Config, eles executam tarefas de higiene agendadas: rotacionar chaves de acesso, aplicar tags em volumes EBS não anexados ou terminar instâncias paradas após 30 dias.

O Patch Manager é um subsistema do SSM que mantém os sistemas operacionais em conformidade com uma linha de base de patches (um conjunto de patches aprovados, classificações e filtros de severidade). As instâncias são agrupadas em grupos de patches através da tag Patch Group; uma janela de manutenção agenda o documento AWS-RunPatchBaseline para ser executado neles. O status de conformidade retorna para o Config e o Security Hub, fechando o ciclo entre o estado no nível do sistema operacional e os relatórios organizacionais.

Service Catalog, CloudFormation StackSets e Guardrails Preventivos

Detecção e remediação são reativas. Para prevenir a não conformidade, use controles preventivos:

• Service Catalog publica templates do CloudFormation selecionados e parametrizados como produtos. Os desenvolvedores lançam padrões aprovados (uma VPC reforçada, um cluster RDS criptografado) sem precisar de permissões do IAM para os serviços subjacentes, o que impõe a separação de responsabilidades entre a equipe de plataforma e os consumidores.

• CloudFormation StackSets implantam stacks idênticos entre contas e Regiões. Com permissões gerenciadas pelo serviço e direcionamento por OU, uma única operação instala gravadores do Config, roles do IAM ou detectores do GuardDuty em todas as contas da organização, incluindo as recém-criadas, por meio da implantação automática.

• Service Control Policies (SCPs) são o único mecanismo que pode negar explicitamente uma chamada de API na fronteira da organização. O Config e o SSM não podem impedir uma chamada RunInstances que não tenha criptografia — eles só podem detectar e remediar posteriormente. Tentar impor proibições rígidas (“nenhum bucket S3 público, nunca”) apenas com regras do Config deixa uma janela de tempo entre a criação do recurso e a remediação. Combine uma regra de detecção do Config com uma SCP, como a negação de s3:PutBucketPublicAccessBlock, para fechar essa lacuna.

Recuperação de Desastres: Backup, Templates e Controle de Versão

Atingir as metas de RPO/RTO exige que tanto os dados quanto as definições de infraestrutura sejam recuperáveis. O AWS Backup centraliza as políticas de backup entre EBS, RDS, DynamoDB, EFS e FSx; as políticas de backup da organização impõem planos entre as contas-membro, e cópias entre Regiões e entre contas protegem contra a perda de uma Região e o comprometimento de uma conta. O RPO é definido pela frequência do backup; o RTO depende da mecânica de restauração (uma restauração PITR do DynamoDB leva minutos; uma restauração de snapshot do RDS entre Regiões pode levar uma hora).

A recuperação da infraestrutura depende de templates do CloudFormation armazenados no CodeCommit (ou outro provedor Git) como a fonte única da verdade. Reimplantar um StackSet a partir de templates versionados reconstrói VPCs, IAM e stacks de aplicação em uma Região de recuperação em minutos. Manter os templates apenas no console — sem um repositório — torna o RTO imprevisível, pois não há um artefato reproduzível.

Análise de Armadilhas

Três equívocos consistentemente levam a respostas erradas. Primeiro, tratar o Config como um controle preventivo: ele avalia depois que o CloudTrail registra a mudança, então proibições genuínas exigem SCPs. Segundo, configurar a remediação sem uma role do IAM com escopo adequado — o documento do SSM existe e a regra do Config é acionada, mas o runbook falha silenciosamente por erros de permissão. Terceiro, executar serviços de toda a organização a partir da conta de gerenciamento em vez de registrar um administrador delegado, o que força a habilitação manual por conta e impede que os agregadores de toda a organização funcionem corretamente.

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

Cenário: A Meridian Financial opera um ambiente AWS multicon-tas com contas separadas de produção, desenvolvimento e segurança sob o AWS Organizations. A equipe de segurança deve comprovar a conformidade contínua com os controles internos e reguladores enquanto gerencia centenas de instâncias EC2, buckets S3 e funções Lambda em várias regiões.

Desafio: Uma auditoria recente encontrou instâncias EC2 sem patches, buckets S3 públicos e aplicação inconsistente da linha de base entre as contas; a remediação é manual e lenta, e os controles preventivos não são aplicados de forma uniforme.

Abordagem Recomendada:

1. Designar a conta de Segurança como o administrador delegado do AWS Config e implantar um AWS Config Aggregator via CloudFormation StackSets para coletar dados de configuração e conformidade de todas as contas e regiões.
2. Implantar AWS Config Conformance Packs em nível de organização a partir da conta de segurança (usando StackSets) para codificar os controles de linha de base (acesso público do S3, criptografia, tagueamento) para que as mesmas regras se apliquem de forma consistente.
3. Anexar ações de remediação automática do AWS Config a regras de alto risco que invocam documentos do AWS Systems Manager Automation (registrados como runbooks de remediação) para que as violações acionem automaticamente a remediação via SSM Automation ou Run Command.
4. Usar o AWS Systems Manager Patch Manager com SSM Patch Baselines e State Manager para definir grupos de patches e automatizar a aplicação de patches do SO entre contas; enviar os resultados de conformidade de patches para o Config Aggregator.
5. Publicar templates do CloudFormation aprovados no AWS Service Catalog e usar CloudFormation StackSets para implantar ou atualizar stacks em conformidade; impor guardrails preventivos com Service Control Policies do AWS Organizations para bloquear a criação de recursos não permitidos (por exemplo, desabilitar a criação de buckets S3 públicos).
6. Configurar o Amazon EventBridge (CloudWatch Events) e o SNS para notificar a equipe de segurança sobre não conformidades e para acionar fluxos de trabalho adicionais do SSM Automation para incidentes complexos.

Justificativa: Centralizar a detecção com o Config Aggregator e os conformance packs, automatizar a remediação através do SSM e impor guardrails preventivos via Service Catalog/StackSets e SCPs fornece controles consistentes e auditáveis e remediação rápida, em linha com as melhores práticas da AWS para segurança, conformidade e menor privilégio.

← Segurança de Borda e de Aplicações · Todos os domínios · Vulnerabilidade →

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

Navegar Amazon →