Segurança e conformidade
Folha de revisão · 5 temas · AWS Cloud Practitioner
Feita para a véspera. Imprimir esta página tira o menu e as abas.
O modelo de responsabilidade compartilhada
É a tarefa 2.1 do guia e abre o domínio de maior peso da prova. O formato é sempre o mesmo: o enunciado cita um serviço e uma atividade e pergunta de quem é a responsabilidade. Quem não sabe que a linha se move conforme o serviço responde no chute.
Como cai: Uma empresa executa uma aplicação em instâncias EC2. Quem é responsável por aplicar as correções de segurança do sistema operacional convidado?
Erros comuns
- Achar que a linha é fixa. Ela se move com o serviço: no EC2 o cliente cuida do sistema operacional convidado; no RDS quem corrige o sistema operacional e o motor do banco é a AWS.
- Concluir que a AWS cuida da segurança dos dados porque cuida da infraestrutura. O conteúdo dos dados, a classificação deles e quem tem acesso são sempre do cliente.
- Confundir segurança da nuvem com segurança na nuvem. Da nuvem é a infraestrutura que a AWS opera; na nuvem é o que o cliente coloca em cima dela.
- Supor que serviço gerenciado significa nenhuma responsabilidade. Mesmo em S3 e Lambda o cliente continua responsável por permissões, configuração de acesso e criptografia do que grava.
- Esquecer os controles compartilhados. Gestão de correções, gestão de configuração e conscientização existem dos dois lados, cada um na sua camada.
- Tratar descarte de hardware e segurança física como algo configurável. São responsabilidades exclusivas da AWS e o cliente não participa delas.
IAM: usuários, grupos, roles e políticas
É a tarefa 2.3 do guia e o tema mais denso do domínio de maior peso. A prova não pede política escrita em JSON: ela descreve uma necessidade de acesso em duas linhas e pergunta qual componente do IAM atende. Usuário, grupo e role parecem intercambiáveis para quem nunca separou os três.
Como cai: Uma aplicação em uma instância EC2 precisa ler objetos de um bucket do S3. Qual é a forma recomendada de conceder esse acesso?
Erros comuns
- Dar chave de acesso a uma aplicação que roda na AWS. O recomendado é uma role: a credencial vira temporária e ninguém precisa guardar segredo no código.
- Confundir grupo com role. Grupo junta usuários para herdarem a mesma política; role é uma identidade sem senha que alguém ou algum serviço assume por um tempo.
- Usar o usuário raiz no dia a dia. Ele deve ficar protegido com MFA e ser usado só nas poucas tarefas que exigem a conta, como fechar a conta ou mudar o plano de suporte.
- Achar que MFA substitui senha. MFA é um segundo fator somado à senha, não um troca-troca.
- Confundir política gerenciada com política inline. A gerenciada é um objeto reutilizável, anexável a vários; a inline vive presa a uma única identidade e some junto com ela.
- Tratar IAM Identity Center como substituto do IAM. Ele centraliza o acesso de pessoas a várias contas com login único; as permissões dentro da conta continuam sendo políticas do IAM.
- Achar que negar exige apagar a permissão. Uma negação explícita em qualquer política vence qualquer permissão concedida em outra.
Conformidade e governança na AWS
É a tarefa 2.2 do guia. As questões são curtas e sempre do mesmo tipo: um auditor pede um documento ou um registro, e você aponta o serviço. Os candidatos trocam Artifact por Audit Manager e CloudTrail por Config porque nunca separaram o que cada um entrega.
Como cai: Um auditor externo pede o relatório de certificação de conformidade da infraestrutura da AWS. Onde a empresa obtém esse documento?
Erros comuns
- Confundir Artifact com Audit Manager. Artifact entrega os relatórios de conformidade que a AWS produz sobre a própria infraestrutura; Audit Manager coleta evidências do ambiente do cliente para uma auditoria dele.
- Confundir CloudTrail com Config. CloudTrail registra quem chamou qual API e quando; Config registra como o recurso estava configurado e se isso viola uma regra.
- Achar que a certificação da AWS cobre a aplicação do cliente. A certificação cobre a infraestrutura; o que o cliente construiu em cima dela é auditado à parte.
- Confundir Control Tower com Organizations. Organizations agrupa contas e aplica políticas de controle de serviço; Control Tower usa o Organizations para montar um ambiente de várias contas já com as barreiras configuradas.
- Tratar política de controle de serviço como concessão de permissão. Ela define o teto do que pode ser permitido; quem concede continua sendo o IAM.
- Supor que o dado circula entre regiões sozinho. O cliente escolhe a região, e o conteúdo dele não é movido para outra região pela AWS sem que ele configure isso.
Os serviços de segurança e o que cada um detecta
É a tarefa 2.4 do guia e a maior fonte de distrator sutil da prova. Os serviços têm nomes parecidos e todos dizem proteger; o que separa um do outro é o objeto que cada um observa. Quem não fixa essa palavra fica entre GuardDuty e Inspector em toda questão.
Como cai: Uma empresa quer descobrir automaticamente se há dados pessoais armazenados sem controle em buckets do S3. Qual serviço atende a essa necessidade?
Erros comuns
- Confundir GuardDuty com Inspector. GuardDuty procura atividade suspeita acontecendo agora; Inspector procura vulnerabilidade conhecida em instâncias, imagens de contêiner e funções.
- Confundir Macie com GuardDuty. Macie olha o conteúdo do dado no S3 em busca de informação sensível; GuardDuty olha comportamento e telemetria de ameaça.
- Achar que Security Hub detecta alguma coisa sozinho. Ele agrega e prioriza achados de outros serviços e mede a postura contra padrões; a detecção continua com quem detecta.
- Trocar Shield por WAF. Shield protege contra ataque de negação de serviço em volume; WAF filtra requisições da camada de aplicação, como injeção de SQL e cross-site scripting.
- Confundir security group com lista de controle de acesso de rede. O security group é do recurso, avalia estado e só permite; a lista é da sub-rede, não avalia estado e tem regras de permitir e negar.
- Esperar que o Trusted Advisor substitua um serviço de segurança. Ele verifica boas práticas da conta em várias dimensões e aponta lacunas, sem monitorar ameaça continuamente.
- Confundir Detective com GuardDuty. GuardDuty gera o achado; Detective ajuda a investigar a origem e o encadeamento dele.
Criptografia em repouso e em trânsito
Fecha a tarefa 2.4 do guia e é onde a prova separa dois estados do dado que o candidato costuma tratar como um só. As alternativas erradas são sempre serviços vizinhos que também lidam com chave ou segredo, e cada um resolve um problema diferente.
Como cai: Uma empresa precisa criar e controlar as próprias chaves de criptografia para os dados armazenados na AWS, com registro de cada uso da chave. Qual serviço atende a esse pedido?
Erros comuns
- Tratar em repouso e em trânsito como a mesma proteção. Em repouso protege o dado gravado em disco ou objeto; em trânsito protege o dado enquanto viaja pela rede, com TLS.
- Confundir KMS com CloudHSM. O KMS é gerenciado e multilocatário, integrado aos serviços da AWS; o CloudHSM entrega módulos de hardware dedicados sob controle exclusivo do cliente.
- Confundir Secrets Manager com KMS. O KMS gerencia chaves de criptografia; o Secrets Manager guarda e rotaciona segredos de aplicação, como senha de banco.
- Achar que Parameter Store e Secrets Manager são a mesma coisa. O Parameter Store guarda parâmetros de configuração e segredos simples; o Secrets Manager foi feito para segredo, com rotação automática integrada.
- Usar o ACM para dado em repouso. O ACM emite e renova certificados para TLS, que é proteção em trânsito.
- Supor que criptografar o volume dispensa controlar acesso. Quem tem permissão de usar a chave lê o dado normalmente; criptografia não substitui privilégio mínimo.
- Achar que chave gerenciada pela AWS pode ser auditada e controlada como a do cliente. Quem precisa definir política da chave, rotação e registro de uso escolhe chave gerenciada pelo cliente.