Amazon SCS-C02: Proteção de Dados e S3 — 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 Bucket do S3, ARNs de Recursos e Negações Explícitas

Uma política de bucket do S3 é um documento JSON baseado em recursos que é avaliado junto com políticas baseadas em identidade. Duas regras dominam seu comportamento. Primeiro, uma negação (Deny) explícita sempre prevalece: não importa quantas declarações de permissão (Allow) existam, uma negação (Deny) correspondente bloqueia a solicitação. Segundo, o elemento Resource deve corresponder precisamente ao padrão de ARN da ação. Ações no nível do bucket, como s3:ListBucket, operam em arn:aws:s3:::my-bucket, enquanto ações no nível do objeto, como s3:GetObject e s3:PutObject, operam em arn:aws:s3:::my-bucket/*. Uma configuração incorreta comum é conceder s3:GetObject em arn:aws:s3:::my-bucket sem o sufixo /* — a chamada de API visa um ARN de objeto, nenhuma declaração corresponde e a solicitação é negada por padrão.

A política a seguir nega qualquer acesso que não seja TLS e concede permissão de leitura para uma role específica, usando ambas as formas de ARN corretamente.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyInsecureTransport",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::reports",
        "arn:aws:s3:::reports/*"
      ],
      "Condition": { "Bool": { "aws:SecureTransport": "false" } }
    },
    {
      "Sid": "AllowAnalyticsRead",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::111122223333:role/Analytics" },
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::reports/*"
    }
  ]
}

Uma armadilha frequente é tentar “abrir uma exceção” adicionando um Allow posterior após um Deny amplo. As declarações de política não são sensíveis à ordem, e a lógica de avaliação do IAM retorna Deny no momento em que qualquer negação correspondente existe. A correção correta é restringir o Deny — por exemplo, por meio de um NotPrincipal ou uma Condition — em vez de anexar uma declaração permissiva abaixo dele.

Regras de Ciclo de Vida, Expiração de Objetos e Vault Lock

As regras de ciclo de vida (Lifecycle) do S3 automatizam as transições de classes de armazenamento e a expiração de objetos. Para atender a requisitos de retenção — como remover PII 30 dias após a ingestão — anexe uma regra que expire as versões atuais dos objetos após 30 dias e exclua permanentemente as versões não atuais logo em seguida. Para metadados relacionados gravados no DynamoDB, habilite o atributo TTL do DynamoDB para que os itens se autoexcluam no mesmo cronograma; combinar esses dois mecanismos é operacionalmente eficiente porque não é necessário nenhum Lambda, agendador ou código de limpeza personalizado.

LifecycleConfiguration:
  Rules:
    - Id: ExpirePIIAfter30Days
      Status: Enabled
      Filter: { Prefix: "ingest/" }
      Expiration: { Days: 30 }
      NoncurrentVersionExpiration: { NoncurrentDays: 1 }

Para dados arquivados com retenção regulatória, o S3 Glacier Vault Lock fornece um controle WORM separado no nível do cofre (vault). Uma vez que a política do Vault Lock é efetivada (um processo de duas etapas de iniciar/completar dentro de 24 horas), ela não pode ser alterada, nem mesmo pelo usuário root da conta. Isso é diferente do Object Lock, que opera no nível do objeto do S3.

Block Public Access e CloudFront OAC

O S3 Block Public Access (BPA) é um conjunto de quatro configurações no nível da conta e do bucket que sobrepõem qualquer ACL ou política que, de outra forma, concederia acesso público. Habilite todas as quatro no nível da conta e imponha isso com uma SCP, como negar s3:PutBucketPublicAccessBlock quando a ação for relaxar as configurações. Essa defesa em profundidade impede que um engenheiro reexponha acidentalmente um bucket por meio de uma ACL permissiva.

Para conteúdo voltado ao público servido através do CloudFront, o padrão correto é o Origin Access Control (OAC). O OAC assina as solicitações do CloudFront para o S3 usando SigV4; a política do bucket então permite apenas o principal de serviço (service principal) da distribuição do CloudFront. Confiar apenas no CloudFront sem OAC (ou o antigo OAI) deixa a URL do S3 diretamente acessível, anulando os controles de acesso e o WAF do CDN. O bucket deve permanecer privado, com o BPA habilitado, e a política deve ter o escopo definido para o ARN da distribuição:

{
  "Effect": "Allow",
  "Principal": { "Service": "cloudfront.amazonaws.com" },
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::site-assets/*",
  "Condition": {
    "StringEquals": {
      "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/E1ABCXYZ"
    }
  }
}

S3 Object Lock e Replicação entre Regiões (Cross-Region Replication)

O Object Lock impõe a semântica WORM em objetos individuais e exige que o versionamento esteja habilitado e que o Object Lock seja ativado na criação do bucket (ele não pode ser adicionado posteriormente a um bucket existente sem contatar a AWS). Existem dois modos de retenção:

• Modo Governança (Governance mode): principais com privilégios com a permissão s3:BypassGovernanceRetention podem encurtar ou remover a retenção.

• Modo Conformidade (Compliance mode): nenhum usuário — incluindo o usuário root da conta AWS — pode excluir ou sobrescrever o objeto ou reduzir seu período de retenção até que ele expire. Uma retenção legal (legal hold) pode ser adicionalmente aplicada e removida de forma independente por usuários com a permissão s3:PutObjectLegalHold.

O modo Conformidade é a escolha correta quando o requisito é imutabilidade absoluta contra todas as identidades. Para estender essa garantia entre Regiões, combine o Object Lock com a S3 Replication. Os objetos replicados preservam sua configuração de bloqueio no bucket de destino (que também deve ter o Object Lock habilitado), de modo que um evento em toda a Região ou uma tentativa de exclusão mal-intencionada não possa comprometer a cópia retida.

Macie e Athena para Descoberta e Investigação

O Amazon Macie usa identificadores de dados gerenciados e personalizados para escanear objetos do S3 em busca de PII, PHI, credenciais e outros padrões de dados sensíveis. Ele reporta os achados (findings) para o Security Hub e o EventBridge, permitindo a remediação automatizada, como colocar objetos em quarentena com uma política de bucket restritiva baseada em tags. Habilite o Macie em todas as Regiões que armazenam dados de clientes e delegue a administração através do AWS Organizations para centralizar os achados.

O Amazon Athena fornece SQL serverless sobre dados no S3 e é a ferramenta padrão para consultar eventos de dados no nível do objeto do CloudTrail. Para investigar quem acessou um objeto específico do S3, habilite os eventos de dados do CloudTrail para o bucket, entregue os logs a um bucket S3 central e consulte com o Athena:

SELECT eventTime, userIdentity.arn, sourceIPAddress, requestParameters
FROM cloudtrail_logs
WHERE eventName IN ('GetObject','DeleteObject')
  AND requestParameters LIKE '%reports/q3-financials.pdf%'
  AND eventTime > '2024-01-01T00:00:00Z';

Armadilhas Comuns e Suas Causas Raiz

• Falta de /* nos ARNs de objetos: Chamadas de API em nível de objeto são avaliadas em relação a bucket/key, não ao ARN do bucket. Sem /*, nenhuma declaração corresponde e o IAM retorna uma negação implícita — manifestando-se como erros 403 inesperados em GetObject, mesmo quando o “bucket” parece ser permitido.

• Adicionar um Allow após um Deny explícito: A avaliação do IAM não depende da ordem; qualquer Deny correspondente resulta em uma negação imediata. A correção é restringir o escopo do Deny (via Condition, NotPrincipal ou NotResource), e não adicionar declarações permissivas.

• CloudFront sem OAC ou uma política de bucket restritiva: A URL de origem do S3 permanece acessível diretamente, contornando URLs assinadas, regras do WAF e restrições geográficas. Sempre habilite o BPA no bucket de origem e restrinja s3:GetObject ao principal de serviço do CloudFront via AWS:SourceArn.

• Presumir que o Object Lock pode ser habilitado em um bucket existente: O Object Lock deve ser configurado na criação do bucket. A adaptação posterior exige a criação de um novo bucket com o Object Lock habilitado e a migração dos dados.

• Confundir os modos de governança (governance) e conformidade (compliance): O modo de governança não impede que um usuário privilegiado remova a retenção; apenas o modo de conformidade bloqueia até mesmo a conta root.

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

Cenário: A Meridian Financial armazena extratos de clientes, logs de transações e arquivos de conformidade de longo prazo em múltiplos buckets S3 em duas regiões da AWS. Seu ambiente usa o CloudFront para portais de clientes, logging entre contas e transições de ciclo de vida automatizadas para classes de armazenamento de arquivamento para retenção regulatória.

Desafio: Uma auditoria interna recente encontrou vários buckets com políticas inconsistentes expondo PII, sem retenção imutável para registros arquivados e sem uma forma centralizada de descobrir onde objetos sensíveis residem entre contas e regiões.

Abordagem Recomendada:

1. Habilitar o S3 Block Public Access no nível da conta e do bucket e implantar o CloudFront Origin Access Control (OAC); restringir a política do bucket para permitir GetObject apenas do principal do OAC do CloudFront, usando ARNs de recurso precisos, e adicionar negações explícitas para qualquer solicitação que não venha através do OAC.
2. Impor a criptografia do lado do servidor com o AWS KMS, exigindo kms:Encrypt/kms:GenerateDataKey em uma política de bucket e adicionar negações explícitas para solicitações PutObject que não incluam x-amz-server-side-encryption e o kms:context necessário para impedir uploads não criptografados.
3. Configurar o S3 Object Lock no modo de conformidade (compliance) para buckets que devem ser imutáveis e habilitar a Cross-Region Replication (CRR) com regras de replicação que preservem os metadados do Object Lock, para que os objetos replicados permaneçam imutáveis na região de DR.
4. Criar regras de ciclo de vida (Lifecycle Rules) do S3 para transicionar objetos antigos para as classes de armazenamento do S3 Glacier e definir a expiração de objetos para janelas de retenção permitidas; para arquivos que devem ser legalmente imutáveis, colocá-los em cofres (vaults) do Amazon S3 Glacier e aplicar políticas de Glacier Vault Lock para impor a retenção do tipo “write-once” (gravação única).
5. Implantar o Amazon Macie entre contas para descobrir e classificar PII, habilitar o S3 Inventory e consultar os resultados com o Amazon Athena para consultas investigativas, e acionar a remediação automatizada (Lambda/Step Functions) para marcar, colocar em quarentena ou mover objetos sensíveis para buckets bloqueados e criptografados.

Justificativa: Essa abordagem em camadas impõe o menor privilégio e a criptografia, fornece retenção imutável e durabilidade entre regiões para conformidade, e usa o Macie/Athena para descoberta centralizada e remediação automatizada — alinhando-se com as melhores práticas da AWS para proteção de dados e gerenciamento do ciclo de vida.

Amazon Macie: Descoberta Automatizada, Trabalhos de Classificação e Listas de Permissão

O Amazon Macie é um serviço gerenciado de segurança de dados que usa machine learning e correspondência de padrões para descobrir dados sensíveis — informações de identificação pessoal (PII), números de cartão de pagamento (PANs), credenciais e tipos de dados personalizados definidos por regex — armazenados no Amazon S3. O Macie opera em dois modos complementares que são frequentemente confundidos.

A descoberta automatizada de dados sensíveis é um processo de baixo custo e execução contínua que amostra objetos em todos os buckets da conta (ou em uma organização quando o Macie é delegado a uma conta de Segurança). Ele constrói um inventário e uma pontuação de sensibilidade por bucket. Este é o ponto de partida correto quando você tem milhares de buckets e ainda não sabe onde os dados sensíveis residem, pois minimiza o custo e a sobrecarga administrativa ao amostrar em vez de escanear cada objeto.

Os trabalhos de classificação (trabalhos de descoberta de dados sensíveis) são varreduras profundas, únicas ou agendadas, direcionadas a buckets específicos. Uma vez que a descoberta automatizada sinaliza um bucket como contendo dados sensíveis, você cria um trabalho de classificação com escopo nesse bucket para uma análise exaustiva. O padrão canônico é, portanto: habilitar a descoberta automatizada em toda a organização e, em seguida, prosseguir com trabalhos de classificação apenas nos buckets sinalizados.

As listas de permissão (Allow lists) são o mecanismo para suprimir correspondências sabidamente benignas. Se um data lake contém PANs de teste sintéticos (por exemplo, o conhecido intervalo de cartões de teste 4111 1111 1111 1111), o Macie sinalizará cada ocorrência. Reescrever ou mover os dados é caro e disruptivo; a abordagem correta é definir uma lista de permissão no Macie — seja uma lista de texto simples com valores exatos ou uma regex — e associá-la aos seus trabalhos de classificação e à configuração de descoberta automatizada. As correspondências com a lista de permissão são excluídas dos resultados (findings), enquanto PANs genuínos continuam a disparar alertas.

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

Cenário: A Meridian Financial opera um ambiente AWS com várias contas e centenas de buckets S3 que armazenam logs de transações, documentos de clientes e arquivos de longo prazo movidos para o S3 Glacier. A equipe de segurança possui criptografia e logging básicos, mas não tem descoberta centralizada de dados sensíveis nem controles de retenção consistentes entre as contas.

Desafio: Um bucket público descoberto recentemente continha registros de clientes arquivados com PII após uma política de bucket incorreta e uma transição de ciclo de vida para o S3 Glacier, e a Meridian precisa encontrar todos os dados sensíveis, remediar as exposições e impor uma retenção de arquivamento em conformidade daqui para frente.

Abordagem Recomendada:

1. Habilitar o Amazon Macie em toda a AWS Organization e ativar a descoberta automatizada de S3 para que o Macie avalie continuamente buckets e objetos em busca de dados sensíveis e configurações de risco.
2. Criar jobs de classificação do Macie que visam todos os buckets S3; configurar identificadores de dados sensíveis personalizados para SSNs e números de conta e configurar listas de permissão (allow lists) para excluir dados de teste conhecidos, arquivos de fornecedores e contas de serviço.
3. Usar o S3 Inventory para enumerar objetos no S3 Glacier e, em seguida, executar o S3 Batch Operations para restaurar temporariamente apenas os objetos sinalizados pelo inventário para escaneamento do Macie, para que os jobs de classificação possam inspecionar o conteúdo arquivado no Glacier.
4. Automatizar a remediação enviando os achados (findings) do Macie para o Amazon EventBridge e o Security Hub; acionar funções Lambda para aplicar políticas de bucket S3 seguras, habilitar o S3 Block Public Access, remover ACLs públicas e marcar buckets para revisão.
5. Implementar retenção durável e prevenção: habilitar o S3 Versioning e o S3 Object Lock (modos governance/compliance) em buckets críticos, impor SSE-KMS com CMKs via política de bucket e implantar SCPs do AWS Organizations para bloquear ACLs públicas e exigir criptografia e Object Lock quando aplicável.
6. Habilitar eventos de dados do CloudTrail para S3 e alimentar os achados em um SIEM para alertas e agendamento periódico de jobs de classificação do Macie para garantir cobertura contínua.

Justificativa: Essa abordagem usa o Macie para descoberta automatizada e classificação direcionada (com listas de permissão), restaura objetos do Glacier apenas quando necessário para inspeção, automatiza a remediação via EventBridge/Lambda e impõe retenção imutável e criptografia com Object Lock e KMS — alinhando-se com as melhores práticas da AWS para detecção, remediação e controles preventivos.

# Example allow list (regex form) matching common test PANs
Type: Regex
Regex: '^4111[- ]?1111[- ]?1111[- ]?1111$|^5555[- ]?5555[- ]?5555[- ]?4444$'
Name: synthetic-test-pans

Tratar os achados brutos do Macie como verdade absoluta, sem configurar listas de permissão (allow lists) ou de supressão, gera fadiga de alertas e pode mascarar incidentes reais em meio ao ruído de dados sintéticos — é por isso que simplesmente “confiar nos achados” é a resposta errada para ambientes com muitos falsos positivos.

Integrando Achados do Macie com o EventBridge

O Macie publica cada achado no Amazon EventBridge na origem aws.macie. Isso permite que você roteie os achados sem precisar consultar a API do Macie. Uma regra típica encaminha achados de Policy para o SNS para acionar a equipe de plantão (on-call) e envia achados de SensitiveData para o AWS Security Hub para agregação.

{
  "source": ["aws.macie"],
  "detail-type": ["Macie Finding"],
  "detail": { "severity": { "description": ["High"] } }
}

Os alvos (targets) da regra são tópicos do SNS, o Security Hub ou uma função Lambda para remediação personalizada (por exemplo, aplicando automaticamente uma política de bucket restritiva no bucket infrator).

Condições de Política de Bucket para Limites de Organization

O S3 Block Public Access (BPA) bloqueia apenas o acesso originado da internet pública ou de principais anônimos. Ele não impede que um principal autenticado em uma conta AWS diferente ou em uma AWS Organization diferente acesse o bucket se uma política de bucket ou ACL conceder tal acesso. Confiar apenas no BPA é, portanto, incorreto quando o requisito é impedir o acesso entre organizations — você deve combinar políticas de bucket com Service Control Policies (SCPs) no nível do Organizations.

Duas chaves de condição do IAM tornam a imposição de limites de organization precisa:

• aws:ResourceOrgID: o ID da Organization que possui o recurso sendo acessado. Usado em políticas de identidade/SCPs para negar que principais acessem recursos fora da sua Org.

• aws:PrincipalOrgID: o ID da Org do principal que está fazendo a chamada. Usado em políticas de bucket para negar acesso de principais de fora da sua Org.

• aws:SourceOrgPaths: o caminho da OU do principal de origem, permitindo limitar o escopo a uma OU específica (por exemplo, apenas a OU “Production” pode gravar em um bucket de conformidade).

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyOutsideOrg",
    "Effect": "Deny",
    "Principal": "*",
    "Action": ["s3:GetObject", "s3:DeleteObject"],
    "Resource": "arn:aws:s3:::acme-compliance/*",
    "Condition": {
      "StringNotEqualsIfExists": {
        "aws:PrincipalOrgID": "o-abcd1234",
        "aws:SourceOrgPaths": "o-abcd1234/r-root/ou-prod-xyz/"
      }
    }
  }]
}

Combine isso com uma SCP que nega s3:DeleteObject* em recursos onde aws:ResourceOrgID não corresponde à sua Org, e a exfiltração ou exclusão entre Orgs se torna impossível, mesmo que uma política de bucket seja acidentalmente flexibilizada.

S3 Object Lock: Modo Compliance e Versionamento

O Object Lock impõe a semântica write-once-read-many (WORM) em versões individuais de objetos. Ele exige que o S3 Versioning esteja habilitado no bucket (o Object Lock sem versionamento não é possível — o bloqueio protege um ID de versão específico, não a chave).

• Modo Governance: usuários com a permissão s3:BypassGovernanceRetention podem encurtar ou remover a retenção. Adequado para a aplicação de políticas internas.

• Modo Compliance: nenhum principal, incluindo o root da conta AWS, pode encurtar, remover ou excluir a versão do objeto até que o período de retenção expire. Esta é a escolha correta para requisitos regulatórios de imutabilidade (arquivamento para SEC 17a-4, FINRA, HIPAA).

A retenção pode ser definida por objeto (data Retain-Until) ou por meio de uma configuração de retenção padrão no nível do bucket. As Retenções Legais (Legal Holds) são bloqueios separados e indefinidos que persistem até serem explicitamente removidos por um principal com a permissão s3:PutObjectLegalHold.

aws s3api put-object-retention \
  --bucket acme-audit-logs \
  --key 2024/transactions.parquet \
  --retention '{"Mode":"COMPLIANCE","RetainUntilDate":"2031-01-01T00:00:00Z"}'

S3 Glacier Vault Lock: Corrigindo Erros de Política Antes da Conclusão do Bloqueio

O Vault Lock no S3 Glacier impõe políticas de acesso imutáveis ao vault. O processo tem duas chamadas: initiate-vault-lock coloca a política em um estado em andamento com uma janela de 24 horas, e complete-vault-lock a torna permanente. Se um erro de digitação for descoberto durante a janela de 24 horas — por exemplo, um Principal excessivamente permissivo — a remediação correta e mais barata é:

aws glacier abort-vault-lock --account-id - --vault-name compliance-archive
aws glacier initiate-vault-lock --account-id - --vault-name compliance-archive \
  --policy file://corrected-policy.json

abort-vault-lock cancela o bloqueio em andamento sem custo, permitindo que você o reinicie com a política corrigida. As “correções” alternativas — excluir e recriar o vault (o que exige a exclusão de todos os 10 TB de arquivos e o reenvio, incorrendo em cobranças de recuperação e transferência), ou esperar que o bloqueio seja concluído para então contorná-lo — são um desperdício ou impossíveis. Uma vez que complete-vault-lock é executado, a política se torna imutável para sempre; o aborto só é válido durante a janela em andamento.

Armadilha Adjacente: Cadeia de Confiança do DNSSEC

Uma armadilha comum entre domínios diz respeito ao DNSSEC do Route 53. Habilitar a assinatura DNSSEC em uma zona hospedada para um subdomínio gera uma Key Signing Key (KSK) e um registro DS correspondente. Esse registro DS deve ser publicado na zona pai; sem ele, os resolvedores não conseguem validar a cadeia de confiança e tratam as respostas como falsas ou recorrem à resolução insegura, quebrando o DNS para clientes que fazem a validação. Habilitar a assinatura sem exportar o registro DS e inseri-lo no registrador ou na zona pai é um estado de configuração incompleta, não uma implementação funcional do DNSSEC.

← Criptografia · Todos os domínios · Redes e Segurança de VPC →

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

Navegar Amazon →