Disclosure: This article may contain affiliate links. We may earn a commission if you purchase through these links, at no extra cost to you. We only recommend products we believe in.

Descubra como implementar gerenciamento de identidades AWS seguro. Guia técnico com melhores práticas, permissões granulares e compliance.

O Problema Real: 70% dos Vazamentos Cloud Começam com Permissões Mal Configuradas

Em 2023, o Gartner reportou que 70% das violações de dados em ambiente cloud происходят não por falhas em algoritmos de criptografia ou ataques sofisticados de APT, mas por configurações incorretas de permissões. Especificamente em ambientes AWS, o erro mais comum que encontramos em assessments de segurança é o uso indiscriminado da policy AdministratorAccess anexada a usuários e roles sem granularidade.

Recentemente, durante um pentest em uma empresa multinacional do setor financeiro, descobrimos que 23% das Lambdas tinham permissões excessivas — uma delas conseguia listar e copiar dados de qualquer S3 bucket da conta. O invasor interno nem precisava de credenciais privilegiadas; a própria arquitetura de permissões tinha sido o vetor de comprometimento.

Este guia é baseado em implementações reais para empresas que processam dados sensíveis no Brasil e na América Latina. Vou mostrar não apenas a teoria, mas as decisões práticas que separaram ambientes seguros dos que passaram em audits superficiais mas falhariam em um teste real.

O Que É IAM AWS e Por Que Sua Equipe Precisa Dominar

O IAM AWS (Identity and Access Management) é o serviço nativo da Amazon que controla autenticação e autorização em toda a plataforma. Diferente de soluções de terceiros que você instala por cima, o IAM é a camada fundamental — tudo na AWS passa por ele.

Componentes centrais que você precisa conhecer:

  • Users (Usuários IAM): Entidades permanentes para acesso humano. Devem ser exceção, não regra.
  • Groups (Grupos): Agregam usuários com permissões similares. Úteis para onboarding, mas não substituem roles dinâmicos.
  • Roles: Entidades temporárias com credenciais rotativas. O caminho certo para aplicações, serviços e acesso cross-account.
  • Policies: Documentos JSON que definem permissões em formato Allow ou Deny explícito.
  • Identity Providers: Integração com SAML 2.0, OIDC para federar identidades corporativas (AD, Okta, Azure AD).

A pergunta que always surge em treinamentos: "Posso usar um único usuário root da conta AWS para tudo?" A resposta é um resounding não. A conta root deve ter MFA forte habilitado e ser usada apenas para tarefas críticas de billing e account management. Para trabalho diário, você federará identidades.

Estratégias de Permissão: A Arquitetura do Least Privilege

Implementar gerenciamento de identidades AWS eficaz significa dominar três tipos de políticas que trabalham em conjunto:

1. Políticas Baseadas em Identidade (Identity-Based)

Anexadas diretamente a users, groups ou roles. São o primeiro nível de controle.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:GetObjectVersion"
      ],
      "Resource": "arn:aws:s3:::bucket-dados-financeiros/*"
    }
  ]
}

Recomendação prática: Evite ações genéricas como "s3:*" a menos que o caso de uso seja explicitamente justificado. Em uma implementação reciente para um cliente de healthcare, limitamos o acesso a buckets S3 a operações específicas por departamento — marketing viavia apenas GetObject, enquanto analytics tinha ListBucket e GetObject.

2. Políticas Baseadas em Recursos (Resource-Based)

Anexadas a recursos específicos como buckets S3, filas SQS, ou tabelas DynamoDB. Úteis para controle cross-account.

3. Permission Boundaries

O recurso mais subutilizado e mais valioso para segurança. Um permission boundary limita o escopo máximo de permissões que uma role pode ter, mesmo que outras políticas tentem expandir esses privilégios.

Por que isso importa? Imagine um cenário onde um developer recebe acesso amplo via inline policy durante um sprint, mas esquece de remover depois. Se você configurou um permission boundary no nível da organização limitando ações a determinados recursos, o dano potencial é contido.

4. Service Control Policies (SCPs)

Aplica-se no nível da AWS Organization. SCPs são o guardrail que impede que contas membros em qualquer circumstance obtenham privilégios além do aceitável.

Exemplo de SCP restritivo:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PreventSecurityGroupAllTraffic",
      "Effect": "Deny",
      "Action": [
        "ec2:AuthorizeSecurityGroupIngress",
        "ec2:AuthorizeSecurityGroupEgress",
        "ec2:RevokeSecurityGroupIngress",
        "ec2:RevokeSecurityGroupEgress"
      ],
      "Resource": "*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "0.0.0.0/0"
        }
      }
    }
  ]
}

Como Implementar IAM AWS Seguro: Passo a Passo

Passo 1: Habilite MFA em Todas as Contas e Users Críticos

Parece óbvio, mas em assessments encontramos frequentemente:

  • Contas root sem MFA ou com MFA virtual (soft tokens) em vez de hardware tokens
  • MFA desabilitado em usuários com permissões elevadas
  • MFA configurado apenas no papel, não enforced via policy

Configuração enforce:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowManageOwnPasswordAndMFA",
      "Effect": "Allow",
      "Action": [
        "iam:*LoginProfile",
        "iam:ChangePassword",
        "iam:CreateVirtualMFADevice",
        "iam:EnableMFADevice",
        "iam:GetUser",
        "iam:ListMFADevices",
        "iam:ListVirtualMFADevices",
        "iam:ResyncMFADevice"
      ],
      "Resource": "arn:aws:iam::*:user/${aws:username}"
    },
    {
      "Sid": "DenyAllExceptMFAAccessUnless MFA",
      "Effect": "Deny",
      "NotAction": [
        "iam:ChangePassword",
        "iam:CreateVirtualMFADevice",
        "iam:EnableMFADevice",
        "iam:GetUser",
        "iam:ListMFADevices",
        "iam:ListVirtualMFADevices",
        "iam:ResyncMFADevice"
      ],
      "Resource": "arn:aws:iam::*:user/${aws:username}",
      "Condition": {
        "Bool": {
          "aws:MultiFactorAuthPresent": "false"
        }
      }
    }
  ]
}

Passo 2: Configure AWS IAM Access Analyzer

Lançado em 2020 e continuamente mejorado, o Access Analyzer analisa políticas e identifica recursos compartilhados externamente. Em um ambiente de produção típico, você provavelmente encontrará:

  • Buckets S3 com acesso público acidental
  • Roles que permitem acesso de qualquer conta AWS
  • Policies que concedem privilégios beyond business justification

CLI para análise contínua:

aws accessanalyzer list-analyzers
aws accessanalyzer list-findings --analyzer-name ProductionAnalyzer

Passo 3: Implemente Role Assumption com Condições

Roles são temporários por design — credenciais expiram em 1-12 horas. Isso é bom. Mas você precisa adicionar conditions para limitar de onde e quando uma role pode ser assumida.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/DeveloperRole"
      },
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": [
            "10.0.0.0/8",
            "172.16.0.0/12"
          ]
        },
        "Bool": {
          "aws:MultiFactorAuthPresent": "true"
        },
        "NumericLessThan": {
          "aws:RequestTimeGreaterThan": "2024-01-01T00:00:00Z"
        }
      }
    }
  ]
}

Passo 4: Automatize a Rotação de Credenciais

Credenciais estáticas (access keys) são um risco. Para aplicações:

  1. Prefira roles attached diretamente ao recurso (EC2 instance profile, Lambda execution role)
  2. Se precisar de access keys para legacy systems, use AWS Secrets Manager com rotação automática de 30-90 dias
  3. Implemente Service Last Accessed Data para identificar credenciais não utilizadas

Para identificar credenciais inativas:

aws iam generate-credential-report
aws iam get-credential-report --query 'Content' --output text | base64 -d | cut -d, -f1,2,4,5,6,11,15

Monitoramento e Compliance: Não É Opcional

AWS CloudTrail: Sua Fonte de Verdade

CloudTrail registra todas as chamadas de API AWS. Para ambientes regulados (LGPD, PCI-DSS, SOC 2), configure:

  • Multi-Region trail habilitado com log validation
  • CloudTrail Logs entregues para um bucket S3 dedicado com Object Lock (WORM) por 7 anos
  • Alertas SNS para ações sensíveis: DeleteUser, AttachUserPolicy, DisableAWSAccount

Query prática via Athena:

SELECT useridentityarn, eventname, sourceipaddress, eventtime
FROM cloudtrail_logs
WHERE eventname IN ('AssumeRole', 'ConsoleLogin', 'CreateUser')
AND eventtime > date_add('day', -1, current_timestamp)
ORDER BY eventtime DESC

AWS Config + Security Hub para Visualização Centralizada

AWS Config oferece conformance packs pré-configurados para padrões como:

  • Operational Best Practices for IAM
  • CIS AWS Foundations Benchmark (versions 1.4 e 2.0)
  • PCI DSS 3.2.1 requirements

Em um cliente do setor público, implementamos uma integration entre Security Hub e Splunk que reduziu o tempo médio de detecção de misconfigurações de 72 horas para 15 minutos.

Armadilhas Comuns e Como Evitá-las

Erro #1: Uso de Credenciais Root

O problema: A conta root tem privilégios irrestritos e credenciais não expiram. Se comprometida, todo o ambiente está perdido.

Solução:

  • Habilite MFA hardware (YubiKey ou Gemalto) na root
  • Armazene credenciais root em um cofre físico (literalmente)
  • Use root apenas para criar a primeira account via Organizations

Erro #2: Políticas Inline Excessivamente Permissivas

O problema: Adicionar policy AdministratorAccess ou PowerUserAccess "temporariamente" durante debugging que nunca é removida.

Solução:

  • Use customer managed policies com versioning
  • Implemente review quarterly de políticas inline
  • Automatize detecção via AWS Config rules

Erro #3: Ignorar Service-Linked Roles

O problema: Service-linked roles são criadas automaticamente por serviços como AWS Config, GuardDuty, Security Hub. Deletá-las incorretamente pode corromper esses serviços.

Solução:

  • Liste service-linked roles: aws iam get-role --role-name AWSServiceRoleFor...
  • Entenda que elas não aparecem em lists convencionais
  • Nunca delete manualmente sem remover dependências

Erro #4: Permissões Cross-Account Mal Configuradas

O problema: Permitir que qualquer conta AWS assuma uma role sem conditions.

Solução:

  • Sempre especifique allowed sources: aws:PrincipalAccount
  • Use aws:PrincipalOrgID para permitir toda a organização
  • Valide assumptions com dry-run antes de production deploy

Ferramentas e Recursos Recomendados

Para Auditoria e Hardening

Ferramenta Uso Principal Custo
AWS IAM Access Analyzer Análise de acessos externos Included
Prowler Open-source security scanning Free
Cloudsploit Detecção de misconfigurações Free tier / SaaS
ScoutSuite Multi-cloud security auditing Free

Para Gestão Centralizada

  • AWS IAM Identity Center (antigo SSO): Para federar identidades corporativas com SCIM provisioning automático. Pricing: Included with AWS Organizations Standard ($0 per account per month).
  • AWS Control Tower: Para landing zone com guardrails pré-configurados. Pricing: Based on number of accounts + active controls.
  • Terraform + AWS Provider: Para infrastructure as code com state locking via S3+DynamoDB.

Conclusão: Segurança IAM É Processo, Não Checklist

Implementar gerenciamento de identidades AWS não é projeto que você termina — é postura de segurança contínua. As organizações mais maduras que avaliamos têm:

  1. Revisões trimestrais de permissões com owners de negócio
  2. Automação para provisioning/deprovisioning de acessos
  3. Métricas de tempo médio de acesso, credenciais inativas, e incidents relacionados a IAM
  4. Treinamento contínuo para devs sobre princípio do menor privilégio

A AWS oferece todos os controles necessários — o trabalho da sua equipe de segurança é implementá-los com discipline e mantê-los com rigor. As ameaças evoluem, mas a foundation permanece: autenticação forte, autorização mínima, monitoramento constante.

Precisa de ajuda para avaliar sua postura IAM atual? A equipe Ciro Cloud oferece assessments de segurança que identificam gaps críticos em políticas, roles e configurações de compliance. Entre em contato para um evaluation personalizado para seu ambiente.

Weekly cloud insights — free

Practical guides on cloud costs, security and strategy. No spam, ever.

Comments

Leave a comment