IAM e least privilege na cloud — policies, roles, SCPs e erros comuns

Identity and Access Management (IAM) é o controle de acesso central da cloud. Configurado de forma permissiva — seja por pressa, desconhecimento ou conveniência — vira a principal porta de entrada para ataques. O princípio do menor privilégio (least privilege) exige que cada identidade tenha acesso apenas ao que precisa, quando precisa.

Conceitos fundamentais — AWS IAM como referência

Principal  → quem solicita acesso (usuário, role, serviço, conta)
Policy     → documento JSON que define Allow/Deny em Actions e Resources
Role       → identidade assumível sem senha — usada por serviços e workloads
SCP        → Service Control Policy — limite máximo de permissões em orgs/OUs
Permission Boundary → limite máximo que uma policy pode conceder a uma role

Policy bem escrita vs policy perigosa

// RUIM — acesso total ao S3 para qualquer recurso
{
  "Effect": "Allow",
  "Action": "s3:*",
  "Resource": "*"
}

// BOM — acesso de leitura somente ao bucket específico e prefixo
{
  "Effect": "Allow",
  "Action": [
    "s3:GetObject",
    "s3:ListBucket"
  ],
  "Resource": [
    "arn:aws:s3:::financeiro-prod",
    "arn:aws:s3:::financeiro-prod/relatorios/*"
  ],
  "Condition": {
    "StringEquals": {
      "aws:RequestedRegion": "us-east-1"
    }
  }
}

Roles para workloads — nunca use access keys hardcoded

# Ruim: chave de acesso no código ou variável de ambiente
export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

# Certo: EC2 assume uma Instance Profile (role)
# Lambda usa uma Execution Role
# EKS usa IRSA (IAM Roles for Service Accounts)
# Nenhuma chave persistente — credenciais são temporárias e rotacionadas automaticamente

Exemplo de trust policy para uma role usada por Lambda:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Service": "lambda.amazonaws.com" },
    "Action": "sts:AssumeRole"
  }]
}

SCPs — guardrails organizacionais

SCPs não concedem permissão — elas limitam o teto. Mesmo que uma role tenha s3:*, se a SCP bloquear s3:DeleteBucket, a ação é negada.

// SCP: impede deleção de buckets S3 em toda a OU de produção
{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyS3BucketDelete",
    "Effect": "Deny",
    "Action": [
      "s3:DeleteBucket",
      "s3:DeleteBucketPolicy"
    ],
    "Resource": "*"
  }]
}

// SCP: restringe regiões permitidas
{
  "Effect": "Deny",
  "NotAction": [
    "iam:*", "sts:*", "cloudfront:*", "route53:*"
  ],
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {
      "aws:RequestedRegion": ["us-east-1", "sa-east-1"]
    }
  }
}

Erros comuns e como evitar

1. AdministratorAccess em roles de aplicação
   Fix: use Access Analyzer para gerar policy com least privilege baseada em logs reais

2. Usuários IAM com access keys para automação
   Fix: roles + STS AssumeRole ou OIDC federation

3. Policies inline em usuários
   Fix: policies gerenciadas, reutilizáveis, versionadas

4. Sem condições de contexto (IP, MFA, horário)
   Fix: adicione Condition blocks para acesso sensível

5. Roles com trust policy aberta ("Principal": "*")
   Fix: sempre especifique o principal exato

Auditoria de IAM

# Gerar credential report (quem tem o quê)
aws iam generate-credential-report
aws iam get-credential-report --query 'Content' --output text | base64 -d

# IAM Access Analyzer — detecta acesso externo indevido
aws accessanalyzer list-findings --analyzer-arn arn:aws:access-analyzer:us-east-1:123456789:analyzer/meu-analyzer

# Simular permissões de uma role
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::123456789:role/minha-role \
  --action-names s3:DeleteBucket \
  --resource-arns arn:aws:s3:::financeiro-prod