Amazon DVA-C02: Segurança, IAM, KMS e Gerenciamento de Segredos (Cognito, Secrets Manager, SSM) — Guia de estudos
Faz parte do AWS Developer Associate DVA-C02 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.
IAM, Roles, Policies e Acesso Entre Contas
O gerenciamento de identidade e acesso deve ser projetado em torno do princípio do menor privilégio, credenciais de curta duração e uma separação clara entre identidades de serviço e humanas. Para aplicações executando em EC2, ECS ou Lambda, prefira roles de instância/tarefa/função em vez de incorporar chaves de acesso; os SDKs da AWS usam automaticamente a cadeia de provedores de credenciais fornecida pelo ambiente e atualizam as credenciais temporárias. O acesso entre contas (cross-account) deve usar o AWS STS AssumeRole (API: sts:AssumeRole) com uma política de confiança (trust policy) explícita na conta de destino e uma política do IAM na conta de origem que limita quais ARNs de role podem ser assumidos. Quando você exigir MFA para operações sensíveis, imponha-o com uma condição na política da role ou do recurso usando aws:MultiFactorAuthPresent ou exija sts:GetSessionToken para usuários humanos. Para clientes web ou móveis, use AssumeRoleWithWebIdentity (sts:AssumeRoleWithWebIdentity) via Cognito Identity ou provedores federados para evitar credenciais de longa duração. Cuidado com armadilhas comuns: ações/recursos com wildcards excessivamente permissivos, depender de políticas baseadas em recursos sem condições de principal correspondentes e esquecer de incluir as condições SourceAccount ou aws:SourceVpc para acesso cross-account ao S3 ou KMS. Use o IAM policy simulator e o sts:GetCallerIdentity para depurar. Considere usar service control policies (SCPs) no nível da organização para impor barreiras de proteção (guardrails) e negações explícitas (explicit deny) para ações de risco como kms:CreateGrant ou iam:CreateAccessKey, quando apropriado.
KMS, Padrões de Criptografia e Controle de Acesso a Chaves
Use o AWS KMS para criptografia de envelope (envelope encryption): chame GenerateDataKey/GenerateDataKeyWithoutPlaintext para produzir uma chave de dados (data key) para criptografia no lado do cliente (client-side) ou no lado do servidor (server-side) e, em seguida, chame Encrypt/Decrypt para cargas pequenas (payloads) ou use a chave de dados para criptografia em massa (bulk encryption). Escolha a CMK correta: AWS owned para conveniência, AWS managed (aws/*) para integração com serviços, ou customer-managed para controle total e rotação. As políticas de chave (key policies) são o controle principal para o KMS; anexe políticas do IAM que permitam kms:Decrypt, kms:Encrypt e use grants quando precisar de uso de chave temporário e delegado para serviços como operações baseadas no CloudHSM ou invocação de Lambda entre contas. Inclua um EncryptionContext para vincular o texto cifrado (ciphertext) ao contexto de uso e exija-o por meio de uma condição kms:EncryptionContextEquals para maior garantia. O uso do KMS entre contas exige entradas explícitas na política da chave que concedam permissão ao principal ou à role externa e, em alguns casos, permissões de CreateGrant/RetireGrant. Para auditoria e forense, habilite eventos de dados (data events) do CloudTrail para o KMS e S3 para capturar chamadas GenerateDataKey e Decrypt; os logs do CloudTrail incluirão o arn:aws:kms e detalhes sobre qual principal usou a chave. Pegadinhas comuns incluem esquecer de permitir kms:CreateGrant para serviços que usam grants nos bastidores, falhar em rotacionar chaves gerenciadas pelo cliente e presumir que as políticas do IAM sozinhas podem autorizar operações do KMS sem as entradas adequadas na política da chave.
Gerenciamento de Segredos: Secrets Manager vs Parameter Store
O Secrets Manager e o Systems Manager Parameter Store oferecem armazenamento criptografado de segredos, mas diferem em recursos e perfil de custo: o Secrets Manager suporta rotação automática (com templates de rotação Lambda), versionamento integrado e replicação integrada, e cobra por segredo; o Parameter Store (SecureString) tem um nível gratuito (free-tier) para muitos parâmetros e é melhor para configurações simples. O acesso é controlado por políticas do IAM que concedem secretsmanager:GetSecretValue ou ssm:GetParameter com WithDecryption=true, e a chave KMS subjacente deve permitir a descriptografia (decrypt) para o principal. Use políticas baseadas em recursos no Secrets Manager para segredos entre contas, ou use a replicação de segredos. Ao usar os SDKs, chame secretsmanager.getSecretValue({ SecretId }) ou ssm.getParameter({ Name, WithDecryption: true }) e evite registrar os valores dos segredos em logs; configure as variáveis de ambiente do Lambda para usar referências ao Secrets Manager ou Parameter Store com resolução dinâmica no CloudFormation ou SAM, ou use o SDK para buscar os valores na inicialização. Erros comuns de desenvolvedores incluem armazenar segredos em texto plano (plaintext) no controle de versão, confiar em variáveis de ambiente do Lambda para dados muito sensíveis sem a proteção do KMS, e políticas do IAM excessivamente permissivas, como conceder secretsmanager:* para roles amplas. Para a rotação, garanta que a função Lambda de rotação tenha as permissões corretas de secretsmanager:RotateSecret e kms:GenerateDataKey e que o código da aplicação possa reinicializar conexões de forma transparente quando as credenciais mudarem.
Autenticação, Autorização e Integração de API com o Cognito
O Amazon Cognito fornece grupos de usuários (user pools) para autenticação e grupos de identidades (identity pools) para credenciais temporárias da AWS. Use os Cognito User Pools para gerenciar inscrições, autenticação multifator e emissão de JWTs (tokens de ID, acesso e atualização). Aplicativos de página única (SPAs) baseados em navegador devem usar clientes de aplicativo (app clients) sem um segredo de cliente (client secret) e devem usar a UI hospedada ou o SDK do Amazon Cognito (amazon-cognito-identity-js) implementando o fluxo SRP para evitar a exposição de senhas. Verifique os JWTs no servidor ou no API Gateway buscando o URI do JWKS do grupo de usuários e validando a assinatura, o emissor (issuer), o público (audience/aud) e a expiração do token; autorizadores JWT do API Gateway ou autorizadores personalizados do Lambda podem realizar essa validação. Para autenticação de servidor para servidor, troque o token do grupo de usuários por credenciais temporárias via Cognito Identity Pool com
undefined
. As armadilhas comuns incluem URLs de callback ou de logout mal configuradas, não validar escopos ou grupos do token e esperar que os tokens de ID possam ser usados diretamente para chamadas de API da AWS (você deve trocá-los por meio de um grupo de identidades). Para autorização de granularidade fina, use grupos ou claims personalizadas e combine o Cognito com políticas baseadas em recursos e chaves de condição do IAM, como
undefined
ou
undefined
, ao mapear a identidade para funções da AWS. Audite as ações de login e administrativas via CloudTrail e habilite os recursos de segurança avançada no Cognito para detecção de credenciais comprometidas.
Problema Prático: Cenário de Caso de Uso
Cenário: A PixelForge, um estúdio de jogos, executa um backend serverless em uma única conta da AWS com Lambda, API Gateway, S3, DynamoDB e Cognito user pools. Chaves de API e credenciais de banco de dados sensíveis são armazenadas para múltiplos estágios de implantação, e uma equipe de auditoria terceirizada precisa acessar subconjuntos de imagens de produção no S3 por períodos de 1 a 24 horas.
Desafio: Fornecer acesso seguro, de curta duração e auditável às imagens de produção para auditores externos, garantir que os segredos da aplicação sejam rotacionados e acessados de forma segura pelo Lambda, e impor o uso de MFA para acesso administrativo entre contas (cross-account).
Abordagem Recomendada:
- Crie uma chave do KMS gerenciada pelo cliente (customer-managed key) com uma política de chave (key policy) que permita a descriptografia para a conta da PixelForge e conceda permissões (grants) para uma função do IAM de auditor; habilite a rotação de chaves e exija o uso de
undefined
durante as operações de descriptografia. 2. Armazene as credenciais no Secrets Manager (segredos separados por estágio) e anexe uma função do IAM aos Lambdas com a permissão mínima de
undefined
e
undefined
para a chave do KMS; implemente um código de inicialização no Lambda para chamar
undefined
usando o AWS SDK. 3. Para o acesso do auditor, crie uma função em uma conta da AWS separada para o auditor e permita a ação
undefined
a partir da conta do auditor em uma política de bucket do S3 baseada em recursos, limitada por
undefined
e por um mapeamento de função pré-configurado e com prazo definido; gere credenciais de curta duração via
undefined
e imponha o uso de MFA com a condição
undefined
ao assumir a função. 4. Registre todos os acessos com o CloudTrail (eventos de gerenciamento e de dados para S3 e KMS) e habilite o registro em nível de objeto do S3 e o Amazon Macie ou os S3 Access Logs para análise forense adicional; exija que as sessões temporárias do auditor usem um
undefined
específico e marque objetos/requisições com tags para rastreabilidade.
Justificativa: O uso do Secrets Manager com o KMS e credenciais de curta duração do STS impõe o princípio do menor privilégio, permite a rotação automatizada e evita embutir segredos no código. Padrões de assunção de função (assume-role) com prazo definido, MFA e eventos de dados do CloudTrail fornecem acesso auditável e revogável para terceiros, preservando a separação de responsabilidades.
← Implantação e CI · Todos os domínios · Monitoramento →
Pratique estas questões → · Prática cronometrada no ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Passe no seu exame →