Amazon SAA-C03: Segurança, IAM, KMS e Governança — Guia de estudos

By Laurynas Brazys · 18 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Faz parte do AWS SAA-C03 — Guia de estudos completo. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.

Fundamentos de Identidade: Usuários, Root, Grupos e Roles

O Identity and Access Management é o plano de controle pelo qual toda carga de trabalho passa, e seu princípio norteador é o de menor privilégio: conceda apenas o que é necessário, somente pelo tempo que for necessário, e prefira identidades que produzem credenciais de curta duração em vez daquelas que mantêm segredos estáticos.

O usuário root é o dono da conta, possui permissões irrestritas e não pode ser limitado por políticas do IAM ou SCPs. Isso a torna a credencial mais sensível do ambiente, e deve ser tratada como um acesso de emergência (break-glass). Em uma nova conta: habilite um dispositivo MFA de hardware ou virtual no root, defina uma senha longa e única, remova quaisquer chaves de acesso do root históricas e registre contatos alternativos de faturamento/operações/segurança para que a recuperação seja possível. Após a configuração inicial — criar uma identidade de administrador no IAM, configurar o faturamento e definir o alias da conta — o root não é mais usado, exceto para o conjunto restrito de tarefas para as quais a AWS explicitamente o exige (fechar a conta, alterar o nome da conta, restaurar permissões do IAM excluídas, habilitar o MFA Delete e um punhado de operações do S3/CloudFront assinadas pelo root). Usar o root para o trabalho diário é incorreto porque ele não pode ter seu escopo definido por políticas, é difícil de atribuir no CloudTrail quando compartilhado e um único comprometimento concede controle irrevogável.

O acesso humano do dia a dia flui através de identidades do IAM com escopo definido por políticas de menor privilégio. Anexe políticas gerenciadas a grupos, não a usuários individuais: um grupo Administrators com a política AdministratorAccess anexada, e usuários nomeados inseridos nele, resulta em um único ponto de alteração e evita o antipadrão de colar políticas idênticas em cada usuário. Defina o escopo dos recursos com ARNs explícitos em vez de *.

Roles servem a um propósito totalmente diferente. Elas são assumidas por principais (principals) — serviços, instâncias EC2, funções Lambda, usuários federados, chamadores de outras contas — e produzem credenciais temporárias do STS que são rotacionadas automaticamente. Como essas credenciais não podem vazar em um commit do Git e expiram em minutos ou horas, em vez de persistirem até serem rotacionadas manualmente, as roles são a identidade padrão para qualquer coisa não humana.

Duas Políticas por Role: Permissões e Confiança

Toda role é governada por dois documentos independentes, e esquecer qualquer um deles é um modo de falha clássico.

A política de permissões (baseada em identidade) declara o que a role pode fazer uma vez assumida. A política de confiança (baseada em recurso, anexada à própria role) declara quem pode assumi-la. Anexar AmazonS3ReadOnlyAccess a uma role não adianta nada se nenhum principal tiver permissão para chamar sts:AssumeRole nela e, inversamente, uma política de confiança permissiva sem uma política de permissões produz uma role que pode ser assumida, mas não faz nada útil.

Uma role de execução do Lambda mostra o padrão de principal de serviço (service-principal) — o próprio serviço, e não o dono da conta, é o chamador:

AssumeRolePolicyDocument:              # trust policy
  Version: "2012-10-17"
  Statement:
    - Effect: Allow
      Principal: { Service: lambda.amazonaws.com }
      Action: sts:AssumeRole
Policies:                              # permissions
  - PolicyName: ReadOrders
    PolicyDocument:
      Statement:
        - Effect: Allow
          Action: dynamodb:GetItem
          Resource: arn:aws:dynamodb:*:*:table/Orders

Identidade de Carga de Trabalho: Instance Profiles, Task Roles, IRSA, Roles Anywhere

Toda credencial que reside em um template, variável de ambiente ou em um laptop é uma futura violação de segurança. O padrão canônico da AWS substitui chaves de acesso estáticas por credenciais de curta duração, rotacionadas automaticamente, entregues através de roles.

Para o EC2, o mecanismo de entrega é o instance profile — um contêiner simples que vincula uma role do IAM a uma instância para que o Instance Metadata Service (IMDSv2) possa fornecer credenciais temporárias ao SDK. A cadeia de provedores de credenciais padrão as encontra sem configuração, então boto3.client('s3') simplesmente funciona e o código da aplicação nunca vê uma credencial. O IMDSv2 (HttpTokens: required) deve ser imposto para impedir a exfiltração de credenciais baseada em SSRF. As credenciais são rotacionadas aproximadamente a cada seis horas, e a revogação é uma simples edição na role.

AppRole:
  Type: AWS::IAM::Role
  Properties:
    AssumeRolePolicyDocument:
      Statement:
        - Effect: Allow
          Principal: { Service: ec2.amazonaws.com }
          Action: sts:AssumeRole
    Policies:
      - PolicyName: S3DocAccess
        PolicyDocument:
          Statement:
            - Effect: Allow
              Action: [s3:GetObject, s3:PutObject]
              Resource: arn:aws:s3:::docs-bucket/*
AppInstanceProfile:
  Type: AWS::IAM::InstanceProfile
  Properties:
    Roles: [!Ref AppRole]

Para o ECS, o análogo é a task role; para o Lambda, é a execution role; para pods do EKS, é o IRSA (IAM Roles for Service Accounts) ou EKS Pod Identity. Em todos os casos, a própria AWS intermedia as credenciais com base em uma role, e a carga de trabalho nunca vê um segredo de longa duração.

Incorporar chaves de acesso em uma AMI, script de user-data ou arquivo .env é incorreto por três razões concretas: as chaves nunca são rotacionadas automaticamente, seu escopo não pode ser limitado ao contexto da sessão, como um VPC endpoint de origem, e se a instância for comprometida ou uma AMI for compartilhada inadvertidamente, a credencial vaza permanentemente.

Para cargas de trabalho fora da AWS — servidores on-premises, outras nuvens, runners de CI — que precisam de credenciais temporárias da AWS sem chaves incorporadas, o IAM Roles Anywhere usa certificados X.509 de uma CA privada (AWS Private CA ou a sua própria) como âncora de confiança. A carga de trabalho apresenta seu certificado de cliente e recebe credenciais STS de curta duração:

aws_signing_helper credential-process \
  --certificate /etc/pki/client.pem \
  --private-key /etc/pki/client.key \
  --trust-anchor-arn arn:aws:rolesanywhere:...:trust-anchor/... \
  --profile-arn arn:aws:rolesanywhere:...:profile/... \
  --role-arn arn:aws:iam::111122223333:role/OnPremWorkload

Isso resolve o mesmo antipadrão que os instance roles e o Secrets Manager resolvem dentro da AWS.

Acesso Humano em Escala: Identity Center, SAML, Directory Service

Provisionar usuários IAM por conta em qualquer escala é impraticável. O AWS IAM Identity Center (sucessor do AWS SSO) é a porta de entrada recomendada para o acesso da força de trabalho: um diretório único que federa em todas as contas de uma Organization e emite sessões temporárias baseadas em roles através de permission sets — roles do IAM baseadas em templates e mapeadas para grupos do IdP. Os usuários se autenticam uma vez no portal do Identity Center e, em seguida, assumem os permission sets para acessar qualquer conta atribuída.

O Identity Center se integra com IdPs externos (Okta, Entra ID/Azure AD, Google Workspace, ADFS) via SAML 2.0 e SCIM para fluxos automatizados de provisionamento, movimentação e desprovisionamento de usuários (joiner/mover/leaver), e com o Active Directory on-premises através do AWS Directory Service AD Connector (um proxy) ou do AWS Managed Microsoft AD (uma réplica completa na AWS). Para aplicativos móveis ou web que precisam chamar a AWS a partir de usuários não autenticados ou autenticados por terceiros, o Amazon Cognito troca a identidade externa por credenciais temporárias do STS, novamente evitando chaves de longa duração incorporadas.

Acesso Entre Contas

O acesso entre contas é expresso com roles, não com usuários compartilhados, e ambos os lados devem concordar. A conta de destino (B) cria uma role cuja política de confiança (trust policy) nomeia a Conta A (ou um principal específico nela), e o chamador na Conta A também deve ter a permissão sts:AssumeRole direcionada ao ARN daquela role. Nenhum dos lados sozinho é suficiente. Isso produz credenciais de curta duração e uma trilha de auditoria clara do CloudTrail em ambas as contas.

Quando um terceiro (um fornecedor de SaaS) é o principal que assume a role, adicione uma condição ExternalId para evitar o problema do “confused deputy”, e considere exigir MFA:

{
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::222222222222:root" },
  "Action": "sts:AssumeRole",
  "Condition": {
    "StringEquals": { "sts:ExternalId": "a1b2c3-unique-token" },
    "Bool": { "aws:MultiFactorAuthPresent": "true" }
  }
}

Para invocações entre contas de serviço para serviço, as políticas de recurso fazem o trabalho. Para permitir que um tópico SNS na Conta A invoque uma Lambda na Conta B:

aws lambda add-permission \
  --function-name ProcessNotification \
  --statement-id AllowSNSInvoke \
  --action lambda:InvokeFunction \
  --principal sns.amazonaws.com \
  --source-arn arn:aws:sns:us-east-1:111111111111:my-topic

O --principal sns.amazonaws.com é o principal de serviço (o próprio SNS invoca a Lambda), e o --source-arn limita a confiança a um tópico específico para prevenir o problema do “confused deputy”.

Para compartilhamento de S3 entre contas de uma Organization, a abordagem ingênua — listar o ARN de cada conta na política de bucket — não escala e quebra sempre que uma nova conta é adicionada. O padrão correto é aws:PrincipalOrgID:

{
  "Effect": "Allow",
  "Principal": "*",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::reports-bucket/*",
  "Condition": {
    "StringEquals": { "aws:PrincipalOrgID": "o-abcd1234ef" }
  }
}

Qualquer principal em qualquer conta daquela organização é permitido; qualquer outro é negado. Note que Principal: "*" sem a condição tornaria o bucket público — a chave de condição é o que restringe o escopo. O lado da identidade ainda importa: usuários nas contas-membro também precisam da permissão s3:GetObject concedida por sua própria política do IAM (a menos que sejam o usuário root da conta), pois o acesso entre contas exige que ambos os lados permitam a chamada.

Especificamente para o S3, desde 2023 a configuração padrão de Propriedade de Objetos (Object Ownership), Proprietário do bucket imposto (Bucket owner enforced), desabilita completamente as ACLs, tornando as políticas de bucket o único mecanismo de autorização para o bucket. Quando objetos foram previamente carregados por outras contas, ACLs de objeto históricas ou a ACL predefinida bucket-owner-full-control ainda podem estar em jogo.

Organizations e Políticas de Controle de Serviço

O AWS Organizations agrega contas em uma árvore de OUs (Unidades Organizacionais) com uma conta de gerenciamento na raiz. As Políticas de Controle de Serviço (SCPs) são barreiras de proteção (guardrails) anexadas à raiz, a uma OU ou a uma conta individual. Elas se aplicam a todos os usuários e roles do IAM na conta — incluindo o usuário root da conta — mas não à própria conta de gerenciamento, e é por isso que cargas de trabalho (workloads) nunca devem ser executadas lá.

O modelo mental crítico é: SCPs nunca concedem permissões. Elas definem o conjunto máximo de ações permitidas em uma conta. Uma ação só é permitida se for concedida por uma política de identidade ou de recurso e não for bloqueada por nenhuma SCP no caminho da conta. Se um desenvolvedor tem AdministratorAccess, mas uma SCP nega ec2:RunInstances fora de ap-southeast-2, uma tentativa de lançamento em us-east-1 falhará. Por outro lado, uma SCP que permite s3:* não faz nada por si só — o usuário ainda precisa de uma política do IAM que conceda s3:*. SCPs filtram o que o IAM já permitiu; elas são tetos, não pisos.

Usos típicos de SCPs incluem o bloqueio de regiões (region lockdown), a proibição de desativar o CloudTrail ou o GuardDuty, a proibição da exclusão de chaves KMS fora de uma role de emergência (break-glass), e a imposição de criptografia. Para forçar a criptografia de EBS no lançamento, combine dois mecanismos: habilite a Criptografia de EBS por padrão na região (uma configuração de conta por região para que os usuários não precisem alterar scripts), mais uma SCP como a barreira de proteção auditável:

{
  "Effect": "Deny",
  "Action": "ec2:RunInstances",
  "Resource": "arn:aws:ec2:*:*:volume/*",
  "Condition": { "Bool": { "ec2:Encrypted": "false" } }
}

Como as SCPs se aplicam à conta inteira, elas não podem ser contornadas por um administrador comprometido em uma conta-membro. As Políticas de tags (Tag policies) impõem a padronização de chaves e do uso de maiúsculas/minúsculas em tags (CostCenter, não costcenter) para que a alocação de custos e o ABAC funcionem de forma confiável. O Organizations também suporta a administração delegada: em vez de executar serviços de segurança a partir da conta de gerenciamento, delega-se uma conta-membro (“segurança” ou “auditoria”) como administradora para o GuardDuty, Security Hub, IAM Access Analyzer ou Config — preservando a separação de responsabilidades.

KMS: Chaves, Políticas de Chave e Modelos de Propriedade

O KMS distingue o material da chave por propriedade e controle:

Uma CMK é governada por uma política de chave (key policy) — uma política baseada em recurso anexada à chave. Diferente de quase todos os outros recursos da AWS, as políticas do IAM por si sós não podem conceder acesso a uma chave do KMS, a menos que a política da chave primeiro delegue ao IAM:

{
  "Sid": "EnableIAMPolicies",
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
  "Action": "kms:*",
  "Resource": "*"
}

Sem essa declaração, nenhuma política do IAM torna a chave utilizável. Tanto a política da chave quanto a política do IAM do chamador devem permitir a operação — este é o erro de criptografia mais frequente. Conceder kms:Decrypt em uma política do IAM é necessário, mas não suficiente; se a política da chave não delegar ao IAM ou não nomear o principal (principal), a descriptografia falhará com AccessDenied mesmo para um administrador.

Para serviços que usam o KMS em seu nome (EBS, S3, RDS, Lambda), a role chamadora geralmente precisa de kms:GenerateDataKey, kms:Decrypt e, frequentemente, kms:CreateGrant. Para um grupo de nós gerenciado do EKS que criptografa volumes EBS com uma CMK, a service-linked role do Auto Scaling deve constar na política da chave com kms:CreateGrant, ou o lançamento de instâncias falhará silenciosamente.

A rotação de CMKs gerenciadas pelo cliente requer habilitação explícita — muitos profissionais assumem incorretamente que todas as chaves do KMS rotacionam automaticamente:

aws kms enable-key-rotation --key-id alias/my-cmk
aws kms get-key-rotation-status --key-id alias/my-cmk

A rotação preserva o mesmo ID e alias da chave; o material de suporte (backing material) muda, mas o texto cifrado anterior permanece descriptografável porque o KMS retém o material antigo para descriptografar os textos cifrados existentes, enquanto novas escritas usam material novo. O material importado nunca rotaciona automaticamente. O KMS impõe uma janela obrigatória de exclusão pendente de 7 a 30 dias; combine isso com uma regra do EventBridge que corresponda a ScheduleKeyDeletion ou DisableKey no CloudTrail e direcione para um tópico do SNS para um padrão de alerta sem servidor e sem polling:

{
  "source": ["aws.kms"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": { "eventName": ["ScheduleKeyDeletion", "DisableKey"] }
}

External Key Stores estendem o modelo quando reguladores exigem que o material da chave resida fisicamente em um HSM controlado pelo cliente. O KMS encaminha as operações criptográficas para um proxy XKS que se comunica com o HSM on-premise; se o HSM estiver offline, a descriptografia falha — a disponibilidade se torna responsabilidade do cliente.

Chaves Multi-Region (MRKs) compartilham o mesmo ID e material de chave entre Regiões, de modo que o texto cifrado produzido em us-east-1 pode ser descriptografado diretamente em eu-west-1. Este é o padrão correto para DynamoDB Global Tables, S3 Cross-Region Replication com SSE-KMS e DR, onde uma Região de standby deve ler backups criptografados. Chaves padrão de Região única exigiriam descriptografar e recriptografar no momento da replicação.

Compartilhamento de Recursos Criptografados entre Contas

O compartilhamento de AMIs e snapshots EBS criptografados entre contas é um dos modos de falha mais comuns, pois requer quatro ações coordenadas: (1) usar uma CMK gerenciada pelo cliente — chaves gerenciadas pela AWS não podem ser compartilhadas; (2) adicionar a conta de destino como um principal na política da chave com kms:Decrypt, kms:DescribeKey, kms:CreateGrant e kms:ReEncrypt*; (3) modificar as permissões de lançamento/compartilhamento da AMI ou do snapshot para incluir essa conta; e (4) garantir que o principal do IAM na conta de destino também tenha essas ações do KMS. A operação de compartilhamento parece ter sucesso se você pular o passo 2, mas a conta receptora não consegue descriptografar. Assumir que apenas o compartilhamento da AMI é suficiente é a armadilha clássica.

Modos de Criptografia do Lado do Servidor (Server-Side Encryption) no S3

Quando um requisito especifica rotação anual automática, auditabilidade no CloudTrail e minimização do custo da chave, a resposta é SSE-KMS com a chave gerenciada pela AWS aws/s3 — ela rotaciona anualmente sem custo e cada chamada GenerateDataKey/Decrypt é registrada. O SSE-S3 é mais barato, mas não deixa um rastro de uso da chave. Uma CMK gerenciada pelo cliente adiciona $1/mês e só rotaciona se você habilitar a rotação.

Confundir SSE-S3 e SSE-KMS é a armadilha clássica de PHI (Informações de Saúde Protegidas). O SSE-S3 criptografa os dados, mas não oferece política de chave, visibilidade no CloudTrail e nenhuma maneira para uma equipe de conformidade administrar a chave — portanto, ele falha em qualquer requisito que mencione “administrar”, “controlar”, “auditar” ou “revogar o acesso à” chave. Por outro lado, escolher SSE-KMS quando o requisito é apenas “criptografar em repouso com gerenciamento mínimo” é excesso de engenharia (over-engineering).

Habilitar o SSE-KMS não impede por si só leituras não autorizadas. Se a política do bucket permitir s3:GetObject e a política da chave conceder kms:Decrypt ao mesmo principal, o objeto será legível. A criptografia em repouso protege contra o comprometimento da mídia física e adiciona uma segunda verificação de autorização por meio da política da chave — ela não substitui políticas de bucket, políticas do IAM, políticas de endpoint de VPC e condições aws:PrincipalOrgID com escopo definido corretamente.

Impondo Criptografia e TLS no S3

Tornar um bucket “criptografado por padrão” não é suficiente — os clientes podem omitir ou substituir o cabeçalho de criptografia. Duas barreiras de proteção devem ser sobrepostas: a criptografia padrão do bucket (preenche o cabeçalho se o cliente o omitir) e uma política de bucket baseada em negação (deny) que rejeita PutObject sem o cabeçalho necessário, além de uma declaração que nega o acesso não-TLS:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnEncryptedObjectUploads",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::phi-bucket/*",
      "Condition": {
        "StringNotEquals": { "s3:x-amz-server-side-encryption": "aws:kms" }
      }
    },
    {
      "Sid": "DenyInsecureTransport",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": ["arn:aws:s3:::phi-bucket", "arn:aws:s3:::phi-bucket/*"],
      "Condition": { "Bool": { "aws:SecureTransport": "false" } }
    }
  ]
}

A condição aws:SecureTransport força o uso de HTTPS, satisfazendo a “criptografia em trânsito”. Combinado com SSE-KMS usando uma CMK de propriedade da equipe de conformidade, este é o padrão canônico para armazenamento de PHI (Informações de Saúde Protegidas).

Criptografia em Trânsito vs. em Repouso

Criptografia em repouso (EBS criptografado com KMS, armazenamento RDS, objetos S3) e criptografia em trânsito (TLS na rede) são controles independentes que abordam ameaças diferentes — roubo de disco versus interceptação de rede. Habilitar o KMS em uma instância RDS protege o armazenamento subjacente; isso não faz nada pela sessão do cliente com o banco de dados, que por padrão pode não ser criptografada. Para o RDS MySQL, a proteção em trânsito exige o download do pacote de CA do RDS, a configuração de require_secure_transport=ON no parameter group e a conexão dos clientes com --ssl-ca=rds-combined-ca-bundle.pem. Tratar “a criptografia em repouso está ativa” como suficiente é uma falha de auditoria frequente.

Secrets Manager e Parameter Store

Senhas de banco de dados estáticas em arquivos de configuração, variáveis de ambiente ou parâmetros do CloudFormation são o principal vetor de vazamento de credenciais. O AWS Secrets Manager armazena segredos criptografados com KMS, os expõe por meio da chamada GetSecretValue controlada pelo IAM e — ponto crítico — os rotaciona automaticamente por meio de uma função Lambda de rotação. Para RDS, Aurora, Redshift e DocumentDB, a AWS fornece uma Lambda de rotação gerenciada que se conecta ao banco de dados, gera uma nova senha, atualiza atomicamente tanto o segredo quanto o usuário do BD e suporta estratégias de usuário único ou multiusuário. Para outros sistemas, você cria uma Lambda que implementa o ciclo de vida de quatro etapas: createSecret, setSecret, testSecret, finishSecret.

import boto3, json
secret = json.loads(
    boto3.client('secretsmanager')
         .get_secret_value(SecretId='prod/aurora/app')['SecretString'])
conn = pymysql.connect(host=secret['host'],
                       user=secret['username'],
                       password=secret['password'])

As aplicações armazenam o valor em cache brevemente (usando a biblioteca de cache do AWS SDK) e se reconectam em caso de falha de autenticação. A rotação é invisível e nenhum deploy é necessário para alterar uma senha.

O SSM Parameter Store SecureString é a alternativa quando a rotação não é necessária e o custo é o fator dominante:

Quem recupera um parâmetro SecureString precisa das permissões ssm:GetParameter e kms:Decrypt na chave. Esquecer a permissão do KMS é uma das configurações incorretas mais comuns — a política do IAM parece correta, mas a chamada de API falha ao descriptografar.

Em EC2, ECS, EKS e Lambda, o código deve assumir uma IAM role e chamar GetSecretValue ou GetParameter; sem credenciais de longa duração em disco. Incorporar chaves de acesso de usuário IAM diretamente no código da aplicação — mesmo que criptografadas — viola o princípio do menor privilégio e complica a rotação.

Ferramentas de Auditoria e Forense

O CloudTrail registra cada chamada de API da AWS: quem, o quê, quando, de onde. Uma trilha organizacional (organization trail) habilitada a partir da conta de gerenciamento captura eventos de todas as contas em um único bucket S3, idealmente em uma conta de segurança restrita com S3 Object Lock e MFA Delete. Isso fornece uma linha do tempo forense imutável — qual principal excluiu um volume, qual role modificou um security group, qual chave de acesso chamou ec2:RunInstances às 03:17 UTC. Complemente com CloudWatch Logs e alarmes (login do usuário root, alterações de política do IAM) e AWS Config para o estado do recurso em um ponto no tempo e pacotes de conformidade (conformance packs). Impeça a adulteração com uma SCP que negue cloudtrail:StopLogging e cloudtrail:DeleteTrail.

O MFA Delete em um bucket S3 força o usuário root a apresentar um token MFA para excluir permanentemente uma versão de objeto ou desabilitar o versionamento. Só pode ser habilitado pelo root via CLI e fornece forte proteção contra ransomware e exclusão por insiders.

O Amazon Macie usa ML gerenciado para descobrir PII, PHI, credenciais e dados financeiros no S3, produzindo descobertas (findings) classificadas por severidade. É uma ferramenta de descoberta, não uma ferramenta de criptografia.

Detecção de Ameaças: GuardDuty, Security Hub, Detective

O Amazon GuardDuty analisa continuamente VPC Flow Logs, logs de DNS e eventos de gerenciamento e de dados do CloudTrail, com planos de proteção dedicados para logs de auditoria do EKS, eventos de dados do S3, varreduras de malware no EBS, atividade de rede do Lambda e eventos de login do RDS. O RDS Protection do GuardDuty revela tentativas de autenticação anômalas ou de força bruta contra o Aurora e o RDS — um comportamento que um security group não consegue capturar porque a conexão é legítima na camada L4. As descobertas (findings) fluem para os painéis do EventBridge, Security Hub e Detective.

Security groups operam apenas nas camadas L3-L4. Um grupo que permite 0.0.0.0/0 na porta 443 está fazendo seu trabalho ao encaminhar um payload de injeção de SQL — é precisamente para impedir isso que o WAF existe. Defesa em profundidade significa security groups mais WAF mais Shield mais GuardDuty, cada um cobrindo uma camada que os outros não conseguem ver.

DDoS: Shield Standard e Advanced

O AWS Shield Standard é automático e gratuito, defendendo todas as contas contra ataques comuns de L3/L4 (SYN floods, reflexão). Ele opera silenciosamente, sem visibilidade, sem mitigação personalizada e sem um caminho para intervenção humana.

O AWS Shield Advanced (US$ 3.000/mês por organização mais transferência de dados) é necessário sempre que o cenário menciona engajamento proativo, resposta dedicada, proteção de custos contra escalabilidade induzida por DDoS, ou visibilidade de ataques quase em tempo real. Ele cobre CloudFront, Global Accelerator, ALB, CLB, Route 53 e Elastic IPs, e fornece acesso 24/7 ao Shield Response Team (SRT) — pré-autorizado por meio de uma IAM role — para criar regras de WAF em seu nome durante um ataque ativo. Quando um design por trás de um ALB e do Route 53 precisa de detecção gerenciada e resposta humana, o Shield Standard sozinho é insuficiente; essa é a armadilha recorrente. O Advanced também concede proteção de custos para a escalabilidade acionada por ataques. Quando “MENOR esforço de implementação” é mencionado e a arquitetura já inclui o Global Accelerator ou um ALB, a resposta geralmente é habilitar o Shield Advanced e anexar os grupos de regras gerenciadas do WAF da AWS, e não criar um Lambda@Edge personalizado ou migrar de CDN.

Proteção da Camada de Aplicação: AWS WAF

O AWS WAF se anexa ao CloudFront, Application Load Balancers, API Gateway, AppSync, App Runner e user pools do Cognito. Ele não protege Network Load Balancers diretamente (coloque o CloudFront na frente). Ele inspeciona o tráfego L7 e aplica regras para SQL injection, XSS, restrições de tamanho, bloqueio geográfico, reputação de IP e limitação de taxa (rate limiting). As AWS Managed Rules fornecem grupos de regras selecionados, como AWSManagedRulesCommonRuleSet e AWSManagedRulesSQLiRuleSet, sem a necessidade de escrever regex.

Regras baseadas em taxa (rate-based rules) são a principal defesa contra HTTP floods e credential stuffing — elas contam as requisições por janela de cinco minutos por IP de origem (ou por cabeçalho encaminhado) e bloqueiam os infratores automaticamente:

Rules:
  - Name: RateLimitPerIP
    Priority: 1
    Statement:
      RateBasedStatement:
        Limit: 2000        # per 5-min window per IP
        AggregateKeyType: IP
    Action: { Block: {} }
    VisibilityConfig:
      CloudWatchMetricsEnabled: true
      MetricName: RateLimitPerIP
      SampledRequestsEnabled: true

O WAF não é um serviço de DDoS — essa é a função do Shield. O WAF complementa as políticas de recursos (políticas de bucket do S3 negando acesso não-TLS, políticas de endpoint de VPC limitando buckets acessíveis) e os controles de rede (security groups, NACLs) — uma configuração incorreta em qualquer camada não deve expor os dados.

Isolamento de Rede: Security Groups, NACLs, Network Firewall

Dentro de uma VPC, a defesa é em camadas:

• Security groups são stateful, aplicam-se a ENIs, permitem apenas regras de liberação (allow-only) e avaliam todas as regras em conjunto. O tráfego de retorno é permitido automaticamente, então as portas efêmeras não precisam ser abertas explicitamente.
• Network ACLs são stateless, aplicam-se a subnets, suportam tanto regras de liberação (allow) quanto de negação (deny) e as avaliam em ordem numérica. Por serem stateless, se você permite a entrada na porta 443, também deve permitir a saída nas portas efêmeras 1024–65535 para as respostas. Esquecer isso faz com que todas as respostas sejam descartadas de maneiras sutis. Security groups não têm esse problema.
• O AWS Network Firewall fornece inspeção profunda de pacotes (deep packet inspection), regras de IPS compatíveis com Suricata e filtragem de saída baseada em domínio, posicionando-se entre subnets e IGWs/TGWs para inspeção centralizada.

Assumir que apenas security groups são suficientes ignora ameaças no nível da subnet e controles de raio de alcance (blast-radius); assumir que apenas NACLs são suficientes ignora sua natureza stateless e sua granularidade mais grossa.

Catálogo de Armadilhas

Política de confiança (trust policy) esquecida. A política de permissões de uma role concede habilidades; apenas a política de confiança concede a capacidade de ser assumida. Ambas devem estar abertas para que o acesso cross-account ou de serviço para serviço funcione — o chamador recebe AccessDenied em sts:AssumeRole, independentemente de quão permissiva seja a política de identidade.

Política do IAM sem uma política de chave (key policy) correspondente. kms:Decrypt no IAM é necessário, mas não suficiente. A política da chave deve nomear o principal ou delegar ao IAM com Principal: {"AWS": "arn:aws:iam::ACCOUNT:root"}. O compartilhamento de AMIs/snapshots criptografados falha quando apenas o compartilhamento da AMI é feito e a política da chave não é atualizada.

SCPs tratadas como concessões. SCPs limitam, nunca concedem. Uma SCP com Allow s3:* não faz nada sem uma política de identidade correspondente. Por outro lado, uma política de identidade permissiva é limitada por qualquer SCP com Deny no caminho da conta.

Presumir a rotação automática do KMS. CMKs gerenciadas pelo cliente não rotacionam até que a opção seja habilitada; material importado nunca rotaciona automaticamente.

SSE-S3 escolhido para dados controlados por compliance. O SSE-S3 não tem política de chave, visibilidade no CloudTrail e nenhum caminho para revogação — ele falha em qualquer requisito que mencione “administrar”, “controlar”, “auditar” ou “revogar” a chave.

Criptografia em repouso tratada como suficiente. Em repouso e em trânsito são independentes. Um RDS com KMS ainda precisa de require_secure_transport=ON e validação de CA do cliente.

Política de bucket nomeando contas individualmente. Não escala e quebra com mudanças na organização. Use aws:PrincipalOrgID.

Chaves de acesso codificadas (hardcoded) em qualquer lugar. Em user data, arquivos .env, parâmetros do CloudFormation, Git — sempre errado. Use instance profiles, task roles, execution roles, IRSA/Pod Identity ou Roles Anywhere.

Usuário root para trabalho diário ou com políticas anexadas. O usuário root não pode ser restringido por IAM ou SCPs; adicionar uma política ao root não tem sentido. Qualquer resposta que faça isso está errada em sua essência.

Usuários IAM para acesso cross-account. Usuários IAM não podem ser assumidos entre contas; crie uma role na conta de destino e permita que o principal da conta de origem a assuma.

NLB atrás do WAF. O WAF não se anexa a NLBs. Coloque o NLB atrás do CloudFront se a filtragem L7 for necessária.

NACL sem a saída efêmera. NACLs stateless precisam de regras explícitas para o caminho de retorno. A falta da regra de saída para as portas 1024–65535 quebra silenciosamente todas as respostas de entrada na porta 443.

Shield Standard para engajamento gerenciado. O Standard é passivo e sem acesso ao SRT; apenas o Advanced satisfaz “engajamento proativo gerenciado” ou “proteção de custos”.

← Integração de Aplicações · Todos os domínios · Gerenciamento →

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

Navegar Amazon →