Gestão do ciclo de vida de credenciais na AWS: como reduzir sua exposição a eventos de segurança baseados em identidade

Por Paulo Cesar Barbosa, Technical Account Manager na AWS.

Credenciais expostas continuam sendo o vetor mais recorrente em incidentes de segurança cloud. O Verizon 2026 DBIR identificou credential abuse presente em 39% dos incidentes quando considerado em qualquer estágio da cadeia de comprometimento. Em ambientes cloud, credenciais operam remotamente por design, já que não dependem de um perímetro de rede. Isso significa que uma credencial exposta pode ser usada de qualquer localização, exigindo controles de detecção e restrição por origem.

Neste post, você aprenderá como eventos de segurança baseados em identidade funcionam em ambientes AWS, quais técnicas do MITRE ATT&CK threat actors utilizam para obter, escalar e persistir com credenciais expostas, e quais contramedidas implementar em cada estágio. O post também cobre a migração de remediação reativa para um processo contínuo de gestão de ciclo de vida que reduz sua superfície de ataque por design.

Por que credenciais são o alvo principal

Credenciais de longa duração em ambientes cloud têm um perfil de risco distinto:

• Persistência silenciosa — Uma access key exposta funciona indefinidamente até ser revogada. Diferente de sessões que expiram, uma key ativa dá acesso contínuo.
• Remoto por design — Credenciais cloud não estão vinculadas a uma localização. A proteção depende da identidade, não do perímetro de rede.
• Alcance lateral — Uma credencial com permissões excessivas pode dar acesso a outras contas e serviços além do escopo original do workload.
• Dificuldade de detecção — O uso de credenciais legítimas comprometidas gera atividades indistinguíveis do acesso autorizado, tornando alertas baseados em assinatura ineficazes.

Essas características tornam o comprometimento de credenciais especialmente impactante em organizações com múltiplas contas, access keys de longa duração e service accounts com privilégios excessivos.

Como threat actors (agentes de ameaça) obtêm e utilizam credenciais cloud

As seções a seguir descrevem as principais técnicas que threat actors utilizam para comprometer credenciais cloud, mapeadas ao MITRE ATT&CK. Compreender essas técnicas ajuda a priorizar contramedidas.

Exposição de credenciais em código e configuração

Access keys embutidas em código-fonte são a fonte mais comum de acesso não autorizado em ambientes AWS. Mesmo removidas em commits posteriores, elas permanecem no histórico do repositório. Scanners automatizados varrem repositórios públicos procurando prefixos como AKIA (keys de longa duração) e ASIA (credenciais temporárias de STS, que podem vazar em logs de debug ou outputs de pipelines).

** Referência MITRE ATT&CK: T1552.001 — Unsecured Credentials: Credentials in Files **

Threat actors buscam em sistemas de arquivos e compartilhamentos remotos por arquivos contendo credenciais armazenadas de forma insegura, incluindo arquivos de configuração, código-fonte e repositórios compartilhados de credenciais.

Pontos comuns de exposição incluem:

• Arquivos de ambiente (.env, terraform.tfvars, docker-compose.yml)
• Sistemas de documentação interna (wikis, documentos compartilhados, plataformas de mensagens)
• Backups não criptografados, snapshots de disco e machine images compartilhadas
• Logs de aplicação quando o modo debug imprime variáveis de ambiente

Account takeover (tomada de conta) via recuperação de credencial root

O endereço de e-mail associado a uma conta root AWS é um ponto crítico de controle. Se um usuário não autorizado obtiver acesso a esse email (via phishing, acesso indevido ao servidor de email ou engenharia social), pode iniciar a recuperação de senha e acessar a conta com privilégios irrestritos

** Referência MITRE ATT&CK: T1078.004 — Valid Accounts: Cloud Accounts **

Threat actors obtêm e abusam de credenciais de contas cloud como meio de obter acesso inicial, persistência, escalação de privilégios ou evasão de defesas.

Quando contas root não possuem multi-factor authentication (MFA), o processo de recuperação de senha por si só é suficiente para acesso total à conta. Service control policies (SCPs) podem restringir ações pós-login, mas não podem impedir o login em si.

Privilege escalation (escalação de privilégios) via misconfigurações IAM

Uma credencial com permissões IAM excessivas — particularmente iam:*, iam:CreateUser, iam:AttachUserPolicy, ou iam:PutRolePolicy — permite ao threat actor escalar seus próprios privilégios até acesso administrativo total. Existem mais de 20 caminhos documentados de privilege escalation no AWS IAM, catalogados por pesquisas públicas da comunidade de segurança cloud.

** Referência MITRE ATT&CK: T1098 — Account Manipulation **

Threat actors manipulam contas para manter ou elevar acesso, incluindo modificação de credenciais ou grupos de permissão.

Caminhos comuns de escalação incluem:

• iam:CreateUser + iam:AttachUserPolicy — Criar um novo usuário com acesso administrativo
• iam:CreateRole + iam:UpdateAssumeRolePolicy — Criar uma role que confia em uma conta externa
• iam:PutRolePolicy — Injetar uma política administrativa em uma role existente
• iam:AddUserToGroup — Adicionar um usuário a um grupo com AdministratorAccess
• lambda:CreateFunction + iam:PassRole + lambda:InvokeFunction — Criar e executar uma função com permissões de outra role
• iam:CreatePolicyVersion (com --set-as-default) — Substituir permissões de uma policy existente sem desanexá-la
• iam:CreateAccessKey — Criar access keys para outro usuário (incluindo usuários admin)
• sts:AssumeRole + trust policy mal configurada — Assumir uma role que confia em principals excessivamente amplos

Importante: Grupos IAM vazios com políticas administrativas anexadas representam um vetor de privilege escalation. Qualquer principal com permissão iam:AddUserToGroup pode silenciosamente se adicionar a tal grupo e herdar acesso administrativo total.

Lateral movement (movimento lateral) cross-account

Em organizações com múltiplas contas AWS, roles com trust policies permissivas permitem que um threat actor se mova entre contas assumindo roles em sequência. Uma credencial com sts:AssumeRole irrestrito pode encadear acesso entre contas da organização.

** Referência MITRE ATT&CK: T1550.001 — Use Alternate Authentication Material: Application Access Token **

Threat actors utilizam tokens de acesso roubados para contornar autenticação e acessar contas ou serviços restritos em sistemas remotos.

Nota: Este comportamento pode ser mapeado tanto para T1550.001 (uso de token alternativo) quanto T1078.004 (conta cloud válida). Ambos são aceitáveis — o ATT&CK ainda não tem sub-técnica dedicada para cross-account role chaining.

O padrão de ataque segue estes passos:

1. Threat actor compromete uma credencial com sts:AssumeRole em uma conta
2. Lista roles disponíveis em outras contas ou usa nomes de roles conhecidos (como AWSControlTowerExecution)
3. Assume uma role na conta B
4. Da conta B, assume uma role na conta C
5. Repete até alcançar a management account ou contas com dados sensíveis

Persistência via tokens de federação forjados

Quando uma organização utiliza federação SAML (como Active Directory Federation Services) para autenticação na AWS, o comprometimento do certificado de assinatura de tokens permite ao threat actor forjar SAML assertions para qualquer usuário e qualquer role, sem necessidade de senhas ou MFA.

** Referência MITRE ATT&CK: T1606.002 — Forge Web Credentials: SAML Tokens **

Um threat actor pode forjar tokens SAML com quaisquer claims e declarações de permissão e tempos de vida se possuir um certificado válido de assinatura de tokens SAML.

Esta técnica é particularmente impactante porque:

• Não requer senhas ou MFA — o token forjado é aceito diretamente pela AWS
• Não gera logs no identity provider — apenas na AWS (AssumeRoleWithSAML)
• Persiste mesmo após reset de todas as senhas de usuários
• Só é remediada com a rotação do certificado de assinatura do identity provider
• Quando um SAML provider legado coexiste com IAM Identity Center, o adversário threat actor tem um caminho alternativo que contorna completamente os controles modernos de SSO

Esta classe de ataque é conhecida na literatura de segurança como Golden SAML.

Contra-medidas: Defesa em profundidade para credenciais na nuvem

Implemente contramedidas em camadas. Um único controle isolado não é suficiente, a falha de uma camada deve ser compensada pelas demais.

Eliminar credenciais de longa duração

Eliminar access keys é uma contramedida altamente efetiva contra seu acesso não autorizado. Credenciais temporárias geradas via IAM Roles expiram automaticamente e não podem ser reutilizadas após expiração.

A tabela a seguir mostra a abordagem recomendada para cada tipo de workload. Para detalhes de configuração, consulte: Instance profiles for EC2, ECS Task Roles, EKS Pod Identity, OIDC identity providers, IAM Roles Anywhere.

Para configuração detalhada de OIDC federation por provider, consulte Creating OpenID Connect (OIDC) identity providers na documentação AWS e o repositório aws-actions/configure-aws-credentials no GitHub.

Importante: A trust policy da role deve restringir quais repositórios e branches podem assumi-la. Sem essa restrição, qualquer repositório no GitHub poderia obter credenciais da sua conta AWS. A seção Aplicando Roles Anywhere à segurança de pipelines CI/CD mostra a configuração completa.

Proteger credenciais root

Para reduzir o risco de acesso não autorizado a contas root, implemente os seguintes controles:

• Se você utiliza AWS Organizations, habilite centralized root access, isso remove credenciais de longa duração (senha e MFA) do root das member accounts. Mantenha MFA com hardware security key (FIDO2) apenas na management account.
• Se você não utiliza AWS Organizations, habilite MFA em toda conta root. Use hardware security key (FIDO2) para contas críticas e virtual MFA para as demais no mínimo.
• Deploy de SCPs como camada adicional. SCPs podem negar ações executadas pós-login em member accounts (inclusive pelo root), mas não podem bloquear o próprio ato de autenticação no console, o fechamento da conta pela management account, ou alterações de email/senha via fluxo de recuperação.
• Usar uma distribution list dedicada e monitorada como email do root, não um e-mail pessoal. Configurar também alternate contacts (security, operations, billing) para que notificações críticas da AWS cheguem às equipes corretas e não se percam em caixas individuais.

Implementar privilégio mínimo com limites de permissão

Para limitar o escopo de impacto de credenciais expostas:

• Usar IAM Access Analyzer para identificar credenciais e permissões sem utilização, e gerar políticas de least privilege baseadas no uso real registrado no CloudTrail.
• Aplicar permissions boundaries em todos os IAM users e roles criados por automação. Um boundary que nega iam:Create* e iam:Attach* com políticas administrativas previne escalação mesmo se o principal tiver permissões amplas. Adicionalmente, aplique boundaries como condição em políticas de delegação (usando a condition key iam:PermissionsBoundary) — isso impede que administradores delegados criem users ou roles sem boundary anexado.
• Deletar grupos vazios com políticas administrativas. São vetores de privilege escalation que não servem a nenhum propósito operacional.
• Restringir sts:AssumeRole a ARNs de roles específicas em identity-based policies e permission sets. Nunca permitir sts:* em Resource: *.
• Restringir o uso de credenciais por origem com conditions de aws:SourceIp ou aws:SourceVpc em políticas IAM ou SCPs. Isso limita a utilidade de uma credencial exposta fora do ambiente esperado.

Remover caminhos de federação duplicados

Se sua organização migrou para IAM Identity Center mas SAML providers legados permanecem ativos em member accounts, você tem dois caminhos de federação ativos, e duas superfícies de ataque. Para reduzir este risco:

1. Identifique quais roles possuem trust policies apontando para o SAML provider legado
2. Verifique no CloudTrail se há eventos AssumeRoleWithSAML recentes nessas roles
3. Se não houver uso nos últimos 90 dias, remova o SAML provider e as trust policies associadas
4. Se houver uso ativo, migre o workload para Identity Center antes de remover o provider

Estendendo credenciais temporárias para workloads fora da AWS

IAM Roles resolvem o problema de credenciais para workloads rodando dentro da AWS. Para workloads rodando fora da AWS, como servidores on-premises, ambientes híbridos e runners CI/CD self-hosted (os agentes de execução que processam jobs de pipeline, como tarefas de build, teste e deploy), o IAM Roles Anywhere oferece uma alternativa a access keys de longa duração.

Com IAM Roles Anywhere, workloads utilizam certificados X.509 emitidos por uma certificate authority (CA) confiável para obter credenciais AWS temporárias sob demanda. O processo funciona da seguinte forma:

1. Trust anchor: Você registra uma CA como trust anchor no IAM Roles Anywhere. Pode ser uma AWS Private CA ou uma CA corporativa existente.
2. Profile: Você define quais IAM Roles o workload pode assumir e quais session policies se aplicam. Também é possível configurar attribute mapping para mapear atributos do certificado X.509 (como Subject CN ou OU) para principal tags — habilitando attribute-based access control (ABAC) sem alterações de código.
3. Trust policy da role: A IAM Role deve confiar no service principal rolesanywhere.amazonaws.com com as ações sts:AssumeRole, sts:SetSourceIdentity e sts:TagSession.
4. Credential exchange: O workload apresenta seu certificado ao endpoint do Roles Anywhere, que o valida contra o trust anchor e retorna credenciais temporárias com duração configurável.

Para detalhes de configuração do credential helper, consulte a documentação de IAM Roles Anywhere.

Principais vantagens sobre access keys:

• Sem segredos estáticos na AWS: O certificado X.509 autentica o workload, mas as credenciais AWS retornadas são temporárias e expiram automaticamente.
• Revogação centralizada: Revogar o certificado na CA invalida imediatamente o acesso ao Roles Anywhere, sem necessidade de localizar e desativar keys individuais.
• Identidade auditável: Cada solicitação de credencial gera um evento no CloudTrail vinculado ao subject do certificado, fornecendo rastreabilidade completa.

Importante: Duas considerações ao avaliar IAM Roles Anywhere:

• Dependência de PKI: A efetividade do Roles Anywhere depende da maturidade da sua infraestrutura de PKI. As credenciais AWS temporárias expiram automaticamente, mas o ciclo de vida do certificado X.509 — emissão, renovação, revogação e monitoramento de expiração — depende das operações da sua CA. Se sua PKI não possui processos maduros de lifecycle management, avalie se a AWS Private CA pode simplificar isso para seu ambiente.
• Escopo de aplicabilidade: IAM Roles Anywhere se aplica a workloads onde você controla o ambiente de execução: servidores, containers, VMs e runners CI/CD self-hosted. Não se aplica nativamente a serviços SaaS de terceiros (como plataformas de monitoramento ou analytics) onde você não controla o runtime. Para esses cenários, use cross-account roles com ExternalId.

Aplicando Roles Anywhere à segurança de pipelines CI/CD

Pipelines CI/CD tipicamente possuem credenciais com permissões amplas para provisionar infraestrutura. Se um runner (o agente que executa jobs do pipeline) for comprometido, todas as credenciais disponíveis naquele ambiente ficam expostas.

Com access keys, credenciais expostas em um runner permanecem válidas até serem manualmente revogadas. Com IAM Roles Anywhere, o escopo de impacto é reduzido:

Nota: Para pipelines CI/CD rodando em providers hosted como GitHub Actions ou GitLab CI, OIDC Federation é a abordagem recomendada porque não requer secrets armazenados. IAM Roles Anywhere é a abordagem recomendada para runners self-hosted onde OIDC não está disponível.

Para limitar ainda mais o escopo de impacto de um runner com acesso não autorizado, combine Roles Anywhere com:

• Permissions boundaries na role assumida (deny iam:* e sts:* irrestrito)
• Session duration mínima (15 minutos para deployments em vez de 12 horas)
• IP address conditions na trust policy para restringir acesso a IPs conhecidos dos runners
• Monitoramento de eventos CreateSession fora de janelas esperadas de deployment

Detectar comprometimento de credenciais com Amazon GuardDuty e Amazon CloudWatch

Controles preventivos reduzem a probabilidade de acesso não autorizado, mas controles de detecção reduzem o tempo de resposta. O Amazon GuardDuty monitora continuamente padrões de abuso de credenciais e gera findings quando atividade anômala é detectada.

GuardDuty findings diretamente relacionados a exposição de credenciais incluem:

Nota: Habilite o Amazon GuardDuty em todas as contas e todas as Regions, incluindo Regions que você não utiliza ativamente. Habilitar cobertura multi-Region melhora a visibilidade sobre serviços globais como IAM. Threat actors também frequentemente operam em Regions não utilizadas para evitar detecção. Use GuardDuty com AWS Organizations para habilitá-lo centralmente em todas as member accounts.

Para visibilidade operacional sobre higiene de credenciais, use métricas e alarmes do Amazon CloudWatch para rastrear eventos relacionados a credenciais em tempo quase real:

# CloudWatch metric filter: Alertar sobre qualquer uso de conta root
  # (CIS AWS Foundations Benchmark — monitoramento de atividade root)
  aws logs put-metric-filter \
  --log-group-name CloudTrail/DefaultLogGroup \
  --filter-name RootAccountUsage \
  --filter-pattern '{ $.userIdentity.type = "Root" && $.userIdentity.invokedBy NOT EXISTS && $.eventType != "AwsServiceEvent" }' \
  --metric-transformations \
  metricName=RootAccountUsageCount,metricNamespace=SecurityMonitoring,metricValue=1
  
  # CloudWatch alarm: Disparar em qualquer uso de root
  aws cloudwatch put-metric-alarm \
  --alarm-name "CIS-RootAccountUsage" \
  --metric-name RootAccountUsageCount \
  --namespace SecurityMonitoring \
  --statistic Sum \
  --period 300 \
  --threshold 1 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --evaluation-periods 1 \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:SecurityAlerts

Importante: Detecção sem resposta é insuficiente. Combine GuardDuty findings e CloudWatch alarms com ações de resposta automatizadas usando regras do Amazon EventBridge que disparam funções Lambda para automaticamente desativar keys comprometidas, revogar sessões ativas, ou isolar recursos afetados.

Migrando de remediação reativa para gestão contínua de ciclo de vida

A maioria das organizações lida com credenciais de forma reativa — após um incidente ou durante uma auditoria. Essa abordagem é insuficiente porque o problema se regenera: você rotaciona as 10 keys mais antigas hoje, e amanhã as 10 seguintes assumem o posto.

Um programa sustentável de gestão de credenciais requer duas capacidades:

Visibilidade: Inventário contínuo de todas as credenciais

Antes de qualquer remediação, estabeleça visibilidade completa sobre seu inventário de credenciais. Isso significa saber, em tempo quase real:

• Quantas credenciais existem (access keys, passwords, certificados, tokens)
• Quem é o owner de cada credencial e qual workload a utiliza
• Quando cada credencial foi criada e usada pela última vez
• Quais permissões cada credencial concede se comprometida (escopo de impacto se exposta)
• Se cada credencial está em conformidade com sua política de rotação

A AWS fornece diversos serviços para visibilidade contínua de credenciais:

• IAM Credential Report — Status de todas as credenciais em uma conta
• IAM Access Analyzer — Identifica recursos acessíveis externamente e gera findings de acesso não utilizado
• AWS Config — Avaliação contínua de conformidade com managed rules como access-keys-rotated e iam-user-unused-credentials-check
• AWS Security Hub — Consolida findings e avalia contra CIS Benchmark automaticamente

Processo: Rotação como prática operacional

Rotação de credenciais deve ser um processo operacional, não um evento. Os seguintes princípios ajudam a estabelecer um programa de rotação sustentável:

1. Automação primeiro. Se a rotação depende de ação humana, não acontecerá consistentemente. Use AWS Secrets Manager com rotation functions, ou elimine a necessidade de rotação migrando para credenciais temporárias.
2. Política clara com enforcement automatizado. Defina a idade máxima aceitável (por exemplo, 90 dias para access keys) e implemente enforcement via AWS Config rules com remediação automática.
3. Ownership definido. Cada credencial deve ter um owner definido — não um time genérico, mas uma pessoa ou squad específico responsável pelo ciclo de vida. Credenciais sem owner são as primeiras candidatas a desativação.
4.  Implementar estágios de lifecycle:
   • Criação: Justificativa documentada, data de expiração definida, owner atribuído
   • Uso: Monitoramento contínuo de last-used date, alertas de anomalia
   • Rotação: Automatizada via Secrets Manager ou agendada com prazos definidos
   • Desativação: Automática após período sem uso (90 dias)
   • Deleção: Após período de quarentena (14 dias desativada sem incidentes)
5. Acompanhar métricas: Meça o percentual de keys em conformidade, número de keys stale, idade média das credenciais, taxa de migração para IAM Roles e cobertura de MFA.

Conclusão

Este post cobriu como threat actors obtêm, escalam e persistem com credenciais cloud expostas, mapeadas ao MITRE ATT&CK, e as contramedidas disponíveis em cada estágio, desde eliminar credenciais de longa duração até detectar acesso não autorizado via CloudTrail.

As três ações de maior impacto que você pode tomar hoje:

1. Ganhar visibilidade. Gere um credential report, identifique todas as keys ativas, e mapeie owners e permissões. Você não pode proteger o que não consegue ver.
2. Eliminar o desnecessário. Desative keys não usadas em 90+ dias, delete grupos administrativos vazios, e remova SAML providers legados. Reduzir superfície de ataque é uma das contramedidas mais efetivas.
3. Automatizar o processo. Implemente Config rules para detecção contínua, Secrets Manager para rotação automática, e migre workloads para IAM Roles. Use Kiro com MCP servers para acelerar a triagem de findings do Security Hub e investigar credenciais expostas diretamente do terminal. O objetivo é que conformidade seja o estado padrão — não uma exceção alcançada com esforço. Gestão de credenciais não é um projeto com data de início e fim. É uma prática operacional contínua, e ferramentas como Kiro ajudam a operacionalizar essa prática, integrando verificações de segurança diretamente no fluxo de desenvolvimento. Para saber mais, consulte: https://aws.amazon.com/blogs/security/five-ways-to-use-kiro-and-amazon-q-to-strengthen-your-security-posture/

Autor

Paulo Cesar Barbosa é um Technical Account Manager na AWS e reside em São Paulo, Brasil. Seu foco é ajudar clientes de diversos setores a aumentarem seus níveis de maturidade de segurança em cloud, apoiando-os também em diversos temas como otimização de custos e performance. Possui experiência em segurança ofensiva e defensiva, atua com tecnologia há mais de 26 anos.

Paulo Cesar Barbosa é um Technical Account Manager na AWS e reside em São Paulo, Brasil. Seu foco é ajudar clientes de diversos setores a aumentarem seus níveis de maturidade de segurança em cloud, apoiando-os também em diversos temas como otimização de custos e performance. Possui experiência em segurança ofensiva e defensiva, atua com tecnologia há mais de 26 anos.