Arquiteturas seguras

Folha de revisão · 6 temas · AWS Solutions Architect Associate

Feita para a véspera. Imprimir esta página tira o menu e as abas.

IAM além do básico

IAM está em todo cenário do Domínio 1, que vale 30% da prova, e aparece escondido nos outros três: acesso entre contas, permissão de uma Lambda a um bucket, quem pode assumir o quê. A prova não pede a sintaxe da política; pede que você saiba qual mecanismo resolve cada cenário e o que uma negação explícita faz com todo o resto.

Como cai: Uma aplicação na conta A precisa ler um bucket na conta B com o menor privilégio. Qual é a solução?

Erros comuns

Achar que Allow numa política vence Deny em outra. Uma negação explícita vence qualquer permissão, em qualquer política: é a primeira regra da lógica de avaliação.
Tratar SCP como se concedesse permissão. SCP só limita o teto do que a conta pode fazer; a permissão em si vem das políticas de IAM dentro da conta.
Criar usuário IAM com chave de acesso para uma aplicação em EC2. O mecanismo certo é role de instância: credencial temporária, rotacionada pela AWS, sem chave no código.
Copiar credenciais entre contas para acesso cross-account. O desenho é uma role na conta de destino com política de confiança para a conta de origem, e AssumeRole via STS.
Confundir limite de permissão com política de identidade. O boundary define o máximo que a identidade pode receber; não dá permissão nenhuma sozinho.
Usar usuários IAM para pessoas quando a empresa tem um diretório. Para pessoas, a prova espera federação com o IAM Identity Center; usuário IAM é para exceções.

Vocabulário

SCP: — Service control policy: política do Organizations que define o máximo que qualquer identidade de uma conta pode fazer, inclusive o root. Não concede nada; só limita.
limite de permissão: — Permissions boundary: política anexada a um usuário ou role que define o teto do que ele pode receber. A permissão efetiva é a interseção com a política de identidade.

Segurança de rede na VPC

Rede é onde quem vem de desenvolvimento ou de dados perde ponto na SAA: a diferença entre grupo de segurança e NACL, por que uma instância privada não alcança a internet, e por que o tráfego para o S3 sai caro pelo NAT. A prova repete esses três cenários com roupas diferentes.

Como cai: Instâncias em sub-rede privada precisam acessar o S3 sem passar pela internet e com o MENOR custo. O que fazer?

Erros comuns

Confundir grupo de segurança com NACL. O grupo de segurança é da instância, tem estado (a resposta volta sozinha) e só tem regras de permitir. A NACL é da sub-rede, não tem estado (a resposta precisa de regra própria) e tem permitir e negar, avaliados em ordem.
Esquecer as portas efêmeras na NACL. Como ela não tem estado, o tráfego de resposta sai por uma porta alta aleatória; sem regra de saída para 1024–65535, a conexão abre e a resposta não volta.
Colocar o NAT Gateway numa sub-rede privada. Ele precisa estar numa sub-rede pública, com rota para o Internet Gateway; a sub-rede privada aponta a rota padrão para ele.
Um NAT Gateway só para várias zonas. Se a zona dele cair, todas as sub-redes privadas perdem saída. Resiliência é um NAT por zona, e a prova cobra isso.
Mandar tráfego de S3 e DynamoDB pelo NAT. Os dois têm endpoint de gateway, sem custo, que mantém o tráfego dentro da AWS. O NAT cobra por hora e por GB; é o custo escondido clássico.
Usar NACL para bloquear um IP quando a pergunta é 'de forma mais simples'. Bloquear IP específico é caso de NACL, sim, porque grupo de segurança não nega; mas para permitir acesso entre camadas, referenciar um grupo de segurança em outro é mais simples e mais seguro que faixa de IP.

Vocabulário

grupo de segurança: — Firewall da instância (na verdade, da interface de rede): só regras de permitir, com estado, todas as regras avaliadas. É o controle padrão da prova.
NACL: — Network ACL: firewall da sub-rede, sem estado, com regras de permitir e negar avaliadas em ordem numérica. É a resposta para bloquear IP e para defesa em profundidade.

Proteção de dados: KMS, criptografia e segredos

Quase todo cenário do Domínio 1 termina com 'os dados devem ser criptografados' ou 'a chave deve ser controlada pela empresa'. A prova não pede algoritmo; pede que você escolha entre SSE-S3, SSE-KMS e SSE-C, saiba qual tipo de chave do KMS dá auditoria e rotação, e não confunda Secrets Manager com Parameter Store.

Como cai: Uma empresa exige que as chaves de criptografia do S3 sejam gerenciadas por ela e que cada uso seja auditado. Qual opção atende?

Erros comuns

Achar que SSE-S3 dá controle da chave. Dá criptografia, mas a chave é da AWS e você não a audita nem a rotaciona. Controle e auditoria por uso é SSE-KMS com chave gerenciada pelo cliente.
Confundir chave gerenciada pela AWS com chave gerenciada pelo cliente no KMS. As duas moram no KMS; só a do cliente tem política de chave editável, rotação configurável e pode ser desabilitada ou compartilhada entre contas.
Usar Parameter Store quando o cenário pede rotação automática de credencial de banco. Rotação integrada com RDS é do Secrets Manager; o Parameter Store guarda, mas não rotaciona sozinho.
Achar que dá para ligar criptografia num volume EBS ou numa instância RDS existente. Não dá: cria-se um snapshot, copia-se com criptografia e restaura-se. A prova adora esse detalhe.
Esquecer que o Macie descobre dados sensíveis, não os criptografa nem os protege. Ele classifica o que está no S3; a ação é sua.
Escolher CloudHSM sem o enunciado pedir. CloudHSM só é a resposta com exigência explícita de hardware dedicado ou de nível de conformidade que o KMS não cobre; fora isso, é o distrator caro.

Vocabulário

KMS: — AWS Key Management Service: cria e guarda chaves de criptografia e registra cada uso delas. Os serviços da AWS usam o KMS para criptografar em repouso.
criptografia de envelope: — A chave do KMS não cifra o dado; cifra uma chave de dados, que cifra o dado. O KMS só manipula chaves pequenas, e o dado grande nunca sai do serviço onde está.

Proteção de borda: WAF, Shield e Firewall Manager

É o cenário 'a aplicação está sob ataque' do Domínio 1, e ele tem sempre a mesma armadilha: WAF e Shield parecem sinônimos e não são. Quem sabe que WAF é camada 7 com regra e Shield é camada 3 e 4 contra volume elimina duas alternativas antes de ler o resto. A segunda armadilha é onde anexar: WAF não vai em EC2 nem em NLB.

Como cai: Uma aplicação atrás de um ALB sofre injeção de SQL e um pico de requisições de um mesmo IP. Qual serviço resolve com o MENOR esforço operacional?

Erros comuns

Usar Shield para injeção de SQL. Shield olha volume e padrão de rede, não o conteúdo da requisição HTTP; inspeção de conteúdo é WAF.
Anexar WAF a uma instância EC2 ou a um NLB. WAF se anexa a CloudFront, ALB, API Gateway, AppSync e Cognito; NLB e EC2 direto não têm WAF.
Achar que Shield Standard precisa ser ligado ou pago. Está ativo em toda conta, de graça, e cobre os ataques de rede mais comuns; a prova só pede Advanced quando há exigência explícita de resposta dedicada, proteção contra custo do ataque ou visibilidade avançada.
Tentar bloquear IP no WAF com regra normal quando o problema é volume de um mesmo cliente. A regra certa é a de taxa (rate-based), que bloqueia sozinha quem passa de N requisições em 5 minutos.
Configurar WAF conta por conta numa organização. Regras iguais em várias contas é Firewall Manager, que também aplica Shield Advanced e grupos de segurança em escala.
Esquecer que um grupo de segurança não substitui nada disso. Grupo de segurança filtra porta e origem; não lê HTTP nem absorve DDoS.

Vocabulário

WAF: — Web Application Firewall: inspeciona requisições HTTP e HTTPS e aplica regras de permitir, bloquear ou contar. Trabalha com Web ACLs anexadas a CloudFront, ALB, API Gateway, AppSync ou Cognito.
Shield: — Proteção contra DDoS. O Standard é automático e gratuito; o Advanced acrescenta equipe de resposta, proteção contra o custo gerado pelo ataque e detecção mais fina.
Firewall Manager: — Serviço que aplica políticas de WAF, Shield Advanced, grupos de segurança e Network Firewall em todas as contas do Organizations, inclusive nas criadas depois.

Detecção e auditoria: CloudTrail, Config, GuardDuty e Security Hub

São cinco serviços com nomes parecidos e a prova monta o cenário para você confundir: 'quem apagou o bucket' é CloudTrail, 'o bucket está público' é Config, 'há uma instância minerando cripto' é GuardDuty. Quem tem a pergunta de cada serviço na cabeça responde em dez segundos; quem decorou descrições erra pelo menos uma.

Como cai: A equipe de segurança precisa saber quem alterou um grupo de segurança na semana passada e ser alertada se isso acontecer de novo. Quais serviços?

Erros comuns

Usar CloudTrail para saber se um recurso está conforme. CloudTrail registra chamadas de API, ou seja, ações; o estado e a conformidade do recurso são do Config.
Usar Config para descobrir quem fez uma alteração. Config mostra a linha do tempo de configuração do recurso; o 'quem' e o 'de onde' estão no evento do CloudTrail.
Confundir GuardDuty com Inspector. GuardDuty detecta comportamento suspeito a partir de logs (CloudTrail, VPC Flow Logs, DNS); Inspector procura vulnerabilidades conhecidas em instâncias, contêineres e funções Lambda.
Achar que o CloudTrail guarda tudo para sempre por padrão. O histórico de eventos gratuito cobre 90 dias; retenção longa exige uma trilha gravando no S3.
Deixar o log de auditoria desprotegido. Trilha em bucket sem versionamento, sem MFA delete e sem validação de integridade de arquivo pode ser apagada por quem está sendo auditado.
Ignorar a organização. Uma trilha por conta é trabalho repetido; a resposta para 'todas as contas' é a trilha de organização, criada na conta de gerenciamento.

Vocabulário

CloudTrail: — Registro de auditoria: cada chamada de API na conta, com identidade, origem, horário e parâmetros. É a resposta para toda pergunta que começa com "quem".
Config: — Inventário e histórico de configuração dos recursos, avaliado contra regras (conforme ou não), com remediação automática opcional. É a resposta para "como está" e "está conforme".
GuardDuty: — Detecção de ameaças: analisa continuamente CloudTrail, VPC Flow Logs e logs de DNS com inteligência de ameaças e aprendizado de máquina. Sem agente.
Inspector: — Varredura de vulnerabilidades: procura CVEs conhecidas e exposição de rede em instâncias EC2, imagens no ECR e funções Lambda.

Usuários de aplicação e acesso a APIs: Cognito, API Gateway e acesso privado

O Domínio 1 tem um cenário recorrente que não é sobre infraestrutura: 'a aplicação móvel precisa de login e de acesso ao S3'. A resposta errada mais comum é IAM para pessoas de fora da empresa. A prova quer Cognito, e quer que você saiba qual pool faz o quê. Depois vem a API: qual autorizador, e como manter tudo privado.

Como cai: Um aplicativo móvel precisa que usuários façam login com e-mail ou rede social e enviem fotos direto para o S3. Qual desenho atende com o MENOR esforço?

Erros comuns

Criar usuário IAM para cliente de aplicativo. Usuário IAM é para operar a conta; pessoas de fora, em número indefinido, entram por Cognito ou por federação.
Confundir user pool com identity pool. User pool autentica (login, cadastro, MFA, tokens JWT). Identity pool troca um token por credenciais temporárias da AWS para acessar S3, DynamoDB e afins.
Usar autorizador Lambda quando o Cognito basta. Autorizador Lambda é para lógica própria (token de terceiro, regra de negócio); com user pool do Cognito, o autorizador nativo é a resposta de menor esforço.
Achar que autorizador IAM serve para usuário final de aplicativo. Autorizador IAM (SigV4) é para chamadas de serviços, contas e identidades da AWS, não para o público.
Expor a API na internet quando só serviços internos a consomem. API privada com endpoint de interface na VPC mantém tudo fora da internet.
Ignorar que o API Gateway já limita taxa. Throttling e chaves de API com planos de uso resolvem 'limitar clientes' antes de qualquer WAF.

Vocabulário

user pool: — Diretório de usuários da aplicação. Faz cadastro, login, MFA e emite tokens JWT. Não dá acesso a serviços da AWS por si.
identity pool: — Troca um token de identidade por credenciais temporárias da AWS, com uma role. Aceita usuários autenticados e, opcionalmente, convidados.