IAM (Identity and Access Management) é a camada que decide quem pode fazer o quê em um ambiente cloud. Pesquisas de mercado e relatórios de resposta a incidentes convergem: configuração incorreta de IAM é o vetor número 1 de comprometimento em AWS, Azure e GCP. Entender least privilege, RBAC e o ciclo de vida de identidades não é opcional — é a base de qualquer postura de segurança em nuvem.

O que é IAM em cloud

Em provedores de nuvem pública, IAM é o serviço centralizado que autentica identidades e autoriza ações sobre recursos. No AWS, o IAM define quem pode chamar quais APIs e em quais recursos; no Azure, o Entra ID (antigo Azure AD) gerencia autenticação enquanto o Azure RBAC controla autorização; no GCP, o Cloud IAM unifica os dois em um modelo único de bindings por projeto, pasta ou organização.

Toda ação em cloud — subir uma instância, ler um objeto no storage, invocar uma função serverless — passa pelo mecanismo de avaliação de IAM. O provedor verifica a identidade da requisição, localiza as políticas aplicáveis e decide Allow ou Deny. Esse fluxo ocorre em milissegundos, mas a qualidade das políticas que guiam a decisão determina se sua infraestrutura é resiliente ou frágil.

Identidades em ambientes cloud

Existem quatro classes de identidade que precisam ser gerenciadas de forma diferente:

  • Usuários humanos — colaboradores que acessam consoles e CLIs. Devem usar SSO federado (SAML/OIDC) vinculado ao diretório corporativo, sem credenciais cloud locais de longa duração.
  • Roles assumidas — identidades temporárias geradas pelo AWS STS, Azure Managed Identity ou GCP Service Account impersonation. Emitem tokens de curta duração e são o padrão recomendado para acesso programático.
  • Service accounts — identidades de carga de trabalho usadas por aplicações, pipelines de CI/CD e funções serverless. Devem ter o menor conjunto possível de permissões e nunca compartilhar credenciais entre serviços distintos.
  • Workload Identity — mecanismo moderno que associa identidades de carga de trabalho a atributos verificáveis do ambiente de execução (cluster Kubernetes, pipeline GitHub Actions, runner GitLab), eliminando o uso de chaves estáticas em pipelines.

Least privilege: o princípio e o blast radius

Least privilege significa conceder a cada identidade apenas as permissões estritamente necessárias para realizar suas tarefas, pelo tempo mínimo necessário. A razão técnica mais importante para adotar o princípio é o conceito de blast radius: o quanto de dano uma identidade comprometida consegue causar.

Uma role com AdministratorAccess comprometida pode deletar toda a infraestrutura, exfiltrar segredos do Secrets Manager, criar backdoors via novos usuários IAM e modificar logs de auditoria. Uma role restrita a s3:GetObject em um único bucket específico, se comprometida, expõe apenas aquele conjunto de objetos. A diferença entre os dois cenários é a diferença entre um incidente catastrófico e um contenível.

Na prática, least privilege é difícil de implementar de início porque os times preferem conceder permissões amplas para evitar fricção operacional. A estratégia recomendada é começar com políticas permissivas e usar ferramentas de análise — AWS IAM Access Analyzer, GCP Recommender, Azure Advisor — para identificar permissões concedidas mas nunca exercidas em um período de observação de 90 dias, removendo-as em seguida.

RBAC, ABAC e PBAC: modelos de controle de acesso

Três modelos dominam o controle de acesso em cloud. A tabela a seguir compara suas características centrais:

Critério RBAC ABAC PBAC
Baseado em Papéis atribuídos ao usuário Atributos do usuário, recurso e contexto Políticas declarativas com condições compostas
Granularidade Média Alta Alta a muito alta
Complexidade de gestão Baixa Alta Média a alta
Auditabilidade Alta (roles visíveis) Média (avaliação dinâmica) Alta (políticas versionadas)
Suporte nativo em cloud Azure RBAC, GCP basic roles AWS IAM conditions, GCP IAM conditions AWS IAM policies, Cedar (AWS Verified Access)
Caso de uso ideal Estruturas organizacionais estáveis Controle sensível a contexto (horário, IP, tag) Ambientes multi-conta com políticas de organização

Na prática, os três modelos coexistem. Uma empresa pode usar RBAC para definir papéis funcionais (Desenvolvedor, SRE, Auditor), ABAC para adicionar condições de contexto (acesso a produção apenas de IPs corporativos) e PBAC por meio de SCPs (Service Control Policies) para impor limites invioláveis em nível de organização.

Riscos críticos de IAM mal configurado

A Verizon DBIR e relatórios de Cloud Security Alliance apontam configuração incorreta de IAM como causa raiz na maioria dos incidentes cloud. Os riscos mais frequentes são:

Credenciais long-lived expostas

Access keys da AWS, chaves de service account do GCP e secrets de client do Azure armazenados em repositórios de código, variáveis de ambiente de CI/CD ou arquivos de configuração são o caminho mais direto para comprometimento. Ferramentas de escaneamento como truffleHog, GitGuardian e Gitleaks detectam esse tipo de vazamento, mas a prevenção real é eliminar o uso de credenciais estáticas substituindo-as por roles e workload identity.

Roles excessivamente permissivas

Políticas com wildcards — "Action": "*" ou "Resource": "*" — são equivalentes a dar chave mestra. Mesmo quando motivadas por conveniência temporária de desenvolvimento, tendem a permanecer em produção indefinidamente. O princípio do menor privilégio exige que cada ação e cada recurso sejam especificados explicitamente.

Privilege escalation por caminhos indiretos

Um atacante com permissão de iam:PassRole e ec2:RunInstances pode criar uma instância com uma role mais privilegiada que a sua e usar essa instância para escalar privilégios. Existem dezenas de caminhos de privilege escalation documentados em ambientes AWS, Azure e GCP. Ferramentas como Cloudsplaining (AWS) e Praetorian Graph analisam esses caminhos automaticamente.

Ausência de MFA em contas críticas

Conta root da AWS sem MFA, conta Global Admin do Azure sem MFA ou Owner de projeto GCP sem MFA são bombas de tempo. O NIST SP 800-63B classifica MFA como controle obrigatório para contas com acesso a sistemas de alto impacto. Em cloud, toda conta com permissão de modificar IAM ou deletar recursos se enquadra nessa categoria.

IAM mal configurado como vetor de persistência

Após o comprometimento inicial, atacantes frequentemente criam novos usuários IAM, adicionam policies permissivas a roles existentes ou configuram trust relationships maliciosas para manter acesso mesmo após a troca de credenciais. Monitorar eventos de modificação de IAM em tempo real — via CloudTrail, Azure Monitor ou Cloud Audit Logs — é a única forma de detectar esse comportamento.

Boas práticas de IAM por provedor

AWS IAM

A AWS recomenda nunca usar a conta root para tarefas operacionais. Toda identidade humana deve ser gerenciada via AWS IAM Identity Center (SSO), federada com o diretório corporativo via SAML 2.0 ou OIDC. Roles de instância EC2 e funções Lambda devem usar execution roles com políticas gerenciadas pelo cliente (não as managed policies da AWS, que tendem a ser excessivamente permissivas). SCPs aplicadas via AWS Organizations criam guardrails invioláveis — por exemplo, impedir que qualquer conta membro desative o CloudTrail. O AWS IAM Access Analyzer identifica acessos excessivos e exposições de recursos a entidades externas.

Azure RBAC

O Azure usa o Entra ID como plano de identidade e o Azure RBAC como plano de autorização. Custom roles permitem granularidade além dos papéis built-in (Owner, Contributor, Reader). Managed Identities — system-assigned ou user-assigned — eliminam credenciais em aplicações Azure. Privileged Identity Management (PIM) implementa just-in-time access: usuários solicitam elevação temporária para roles privilegiadas, que é concedida por tempo limitado com aprovação e auditoria. Azure Policy impõe conformidade em nível de subscription e management group.

GCP IAM

O GCP IAM opera com bindings que associam membros (identidades) a roles em recursos. O Google recomenda usar grupos do Cloud Identity em vez de vincular roles diretamente a usuários individuais. Workload Identity Federation permite que cargas de trabalho externas — GitHub Actions, GitLab CI, AWS — obtenham credenciais GCP temporárias sem usar chaves de service account. O GCP Recommender analisa padrões de uso e sugere substituição de roles amplas por roles mais específicas. Org-level policies bloqueiam ações sensíveis independentemente das permissões de projeto.

CIEM: gestão de entitlements em escala

Em ambientes com centenas de contas cloud e milhares de roles, a revisão manual de permissões é inviável. CIEM (Cloud Infrastructure Entitlement Management) é a categoria de ferramentas que automatiza essa análise: mapeia todas as permissões efetivas (não apenas as concedidas, mas as que realmente podem ser exercidas após avaliar policies, SCPs e permission boundaries), detecta caminhos de privilege escalation, identifica entitlements não utilizados e gera relatórios de conformidade com CIS Benchmarks e frameworks regulatórios.

Ferramentas de referência incluem AWS IAM Access Analyzer (nativo, gratuito), Wiz CIEM, Ermetic, Sonrai Security e Tenable Cloud Security. A adoção de CIEM é uma das principais diferenças entre organizações com postura de segurança cloud madura e aquelas que descobrem misconfigurações apenas após incidentes.

Revisão periódica de acessos

Permissões acumuladas ao longo do tempo — por mudanças de função, onboarding apressado ou projetos encerrados — são um risco silencioso. O CIS Benchmark para AWS recomenda revisão trimestral de usuários IAM, roles e policies. Na prática, o processo deve incluir: remoção de usuários inativos por mais de 90 dias; revogação de access keys não rotacionadas; revisão de trust policies de roles cruzadas entre contas; e auditoria de políticas inline que frequentemente escapam de revisões automatizadas.

Perguntas frequentes

As perguntas abaixo refletem as dúvidas mais comuns de times de segurança, engenharia e gestão ao implementar IAM em ambientes cloud corporativos.

O que é IAM em cloud e por que é considerado o vetor de ataque número 1?

IAM (Identity and Access Management) é o conjunto de políticas, roles e mecanismos que controla quem pode fazer o quê em um ambiente cloud. É o vetor número 1 de incidentes porque permissões excessivas ou credenciais mal protegidas permitem que um atacante explore toda a conta sem precisar de exploits de vulnerabilidade — basta ter acesso legítimo (porém indevido) à identidade comprometida.

Qual a diferença prática entre RBAC, ABAC e PBAC?

RBAC (Role-Based) vincula permissões a papéis fixos atribuídos a usuários; é simples e auditável, ideal para estruturas organizacionais estáveis. ABAC (Attribute-Based) decide o acesso dinamicamente com base em atributos do usuário, do recurso e do contexto; oferece granularidade maior, mas aumenta a complexidade de administração. PBAC (Policy-Based) é a abordagem mais expressiva, onde políticas declarativas combinam ação, recurso e condições em documentos versionáveis, podendo emular tanto RBAC quanto ABAC.

O que é blast radius e como o least privilege o reduz?

Blast radius é a extensão do dano que uma identidade comprometida consegue causar. Aplicando least privilege — concedendo apenas as permissões necessárias para a tarefa específica — o blast radius de qualquer credencial é contido ao mínimo operacional, limitando o impacto de phishing, roubo de token ou insider threat.

Quando devo usar uma role em vez de credenciais estáticas?

Sempre que possível. Credenciais estáticas são o principal alvo de vazamento em repositórios e logs. Roles assumidas via STS (AWS), Workload Identity Federation (GCP) ou Managed Identity (Azure) emitem tokens de vida curta — geralmente 1 hora — que expiram automaticamente, eliminando a necessidade de rotação manual.

O que é CIEM e por que empresas maduras o adotam?

CIEM (Cloud Infrastructure Entitlement Management) é uma categoria de ferramentas que analisa continuamente todas as permissões concedidas em ambientes cloud e identifica desvios do least privilege: roles nunca usadas, permissões atribuídas mas não exercidas nos últimos 90 dias, caminhos de privilege escalation e configurações que violam políticas internas ou frameworks como CIS. Empresas maduras adotam CIEM porque o volume de permissões em ambientes multi-cloud torna a revisão manual inviável.

Quais são os erros de IAM mais comuns que levam a incidentes reais?

Os cinco erros mais frequentes são: uso da conta root para tarefas cotidianas; access keys hardcoded em código-fonte versionado; roles com permissões wildcard em Action ou Resource; ausência de MFA em contas privilegiadas; e falta de revisão periódica de entitlements — usuários que mudaram de função mas mantêm acesso antigo.

Referências

  • AWS. Security best practices in IAM. AWS Documentation. Disponível em: https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html
  • Microsoft. Azure role-based access control (Azure RBAC) documentation. Microsoft Learn. Disponível em: https://learn.microsoft.com/en-us/azure/role-based-access-control/
  • Google Cloud. IAM overview. Google Cloud Documentation. Disponível em: https://cloud.google.com/iam/docs/overview
  • NIST. SP 800-207: Zero Trust Architecture. National Institute of Standards and Technology, 2020.
  • NIST. SP 800-63B: Digital Identity Guidelines — Authentication and Lifecycle Management. NIST, 2017 (rev. 2022).
  • CIS. CIS Amazon Web Services Foundations Benchmark v2.0. Center for Internet Security, 2023.
  • Cloud Security Alliance. Cloud Controls Matrix v4.0. CSA, 2021.

Hardening de IAM com a Decripte

A Decripte realiza hardening de IAM e revisão de postura cloud para empresas de todos os portes — de MEIs que rodam aplicações em cloud até organizações com mais de 100.000 colaboradores e ambientes multi-conta em AWS, Azure e GCP. O processo inclui inventário completo de identidades, análise de caminhos de privilege escalation, implementação de CIEM, revisão de SCPs e políticas de organização, e entrega de um relatório técnico com roadmap priorizado de remediação.

Para começar com uma análise gratuita de postura cloud ou conhecer os planos de gestão contínua de segurança, acesse decripte.com.br/planos ou inicie um diagnóstico gratuito.