Gestão de identidade e acesso: como IAM mal configurado vira a maior vulnerabilidade

Por que IAM é a superfície de ataque mais explorada

O Verizon Data Breach Investigations Report 2024 aponta que credenciais comprometidas são o vetor de ataque inicial em mais de 80% dos incidentes de segurança em ambientes cloud. A razão é simples: explorar uma vulnerabilidade de aplicação requer conhecimento técnico e esforço. Usar credenciais válidas com permissões excessivas é trivial.

IAM (Identity and Access Management) é o controle que determina quem pode fazer o quê em quais recursos. Quando esse controle é frouxo, comprometer qualquer credencial — de um desenvolvedor, de uma aplicação, de um serviço de CI/CD — pode dar acesso a dados de produção, secrets de segurança ou capacidade de alterar infraestrutura crítica.

Princípio do menor privilégio na prática

O princípio do menor privilégio (PoLP) afirma que qualquer identidade — humana ou de serviço — deve ter apenas os acessos estritamente necessários para realizar sua função. Na prática, isso requer:

• Granularidade de permissão — evitar políticas genéricas como AdministratorAccess ou PowerUser em AWS IAM. Criar roles com o conjunto mínimo de actions para cada caso de uso.
• Escopo de recursos explícito — permissões devem especificar exatamente quais recursos podem ser acessados, não usar * como wildcard exceto quando estritamente necessário e documentado.
• Separação de ambientes — credenciais de desenvolvimento não devem ter acesso a produção. Identidades separadas por ambiente com políticas separadas.

Identidades de serviço versus identidades humanas

Identidades de serviço — contas usadas por aplicações, pipelines de CI/CD e scripts automatizados — são frequentemente o elo mais fraco em IAM porque recebem permissões amplas "para garantir que funcionará" e nunca são revisadas.

• Service accounts devem ser tratadas como identidades de primeira classe — com o mesmo rigor de permissão que identidades humanas, mas com políticas baseadas exatamente no que a aplicação precisa fazer.
• Rotação automática de credenciais — credenciais estáticas de longa duração são risco. Use roles assumidas temporariamente (AWS STS, GCP Workload Identity) em vez de access keys permanentes.
• Evitar credenciais em código ou CI/CD environment variables expostas — use secrets managers (AWS Secrets Manager, HashiCorp Vault) para injetar credenciais no runtime.

MFA como controle não-negociável

Multi-Factor Authentication (MFA) é o controle de maior ROI em segurança de identidade. Elimina a categoria inteira de ataques baseados em senha comprometida — phishing, credential stuffing, força bruta. Para identidades humanas com acesso a sistemas críticos, MFA não é opcional.

Implementação mínima: MFA obrigatório para acesso ao console cloud (AWS, GCP, Azure), acesso a ferramentas de infra (Terraform, kubectl), acesso a produção via VPN e acesso a cofres de segredos. Ferramentas de gestão como Okta, Azure AD e AWS IAM Identity Center centralizam a aplicação de políticas de MFA e simplificam a auditoria de compliance.

Revisão periódica de permissões: o controle que ninguém faz

Permissões tendem a acumular ao longo do tempo — pessoas mudam de função, projetos terminam, aplicações são descontinuadas, mas as permissões permanecem. Uma revisão trimestral de identidades e permissões deve verificar: identidades inativas há mais de 90 dias, permissões de alto privilégio sem uso nos últimos 30 dias, service accounts de projetos encerrados e acessos cross-account sem documentação de justificativa.