Identidade e acesso

Na nuvem, identidade é o perímetro. Não há sala trancada nem cabo a desconectar: quem tem a credencial tem o recurso, de qualquer lugar do mundo. Por isso, a maior parte dos incidentes graves em nuvem começa por credencial vazada ou permissão exagerada, e não por falha de software.

O modelo em cada nuvem

Os nomes mudam, a estrutura é a mesma: um principal (pessoa, serviço, workload) recebe uma permissão sobre um recurso, dentro de um escopo.

	AWS	Azure	GCP
Identidade de workload	IAM Role	Managed Identity	Service Account
Conjunto de permissões	Policy	Role Definition	Role
Vínculo	Role/attachment	Role Assignment	IAM Binding
Escopo	Conta, OU, recurso	Assinatura, RG, recurso	Organização, pasta, projeto
Pessoas	IAM Identity Center	Entra ID	Cloud Identity

Duas regras valem nas três: pessoas entram por SSO — usuário local com senha é exceção a eliminar — e workload usa identidade própria, nunca credencial de pessoa.

Menor privilégio na prática

Começar por “acesso total, depois a gente restringe” nunca chega ao “depois”. Comece pelo mínimo e amplie com base em uso real.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:PutObject"],
    "Resource": "arn:aws:s3:::empresa-relatorios-prod/loja/*",
    "Condition": {
      "StringEquals": { "aws:PrincipalTag/ambiente": "prod" },
      "Bool": { "aws:SecureTransport": "true" }
    }
  }]
}

Três detalhes que separam uma política real de uma decorativa: ações específicas (não s3:*), recurso com caminho (não *) e condição que restringe contexto. Verifique antes de aplicar:

# quais permissões são de fato usadas — a base para reduzir sem quebrar
aws iam generate-service-last-accessed-details --arn arn:aws:iam::000000000000:role/loja
aws iam simulate-principal-policy --policy-source-arn <role> --action-names s3:DeleteObject
gcloud policy-troubleshoot iam <recurso> --principal-email [email protected]

Use também os limites de cima para baixo: SCP na AWS Organizations, Azure Policy e Organization Policy no GCP negam o que nenhuma política de baixo pode conceder — proibir região fora das permitidas, impedir desligar log de auditoria, bloquear criação de usuário com chave estática.

Roles e assunção de identidade

Prefira assumir papel temporário a carregar credencial. As permissões vêm do papel, a sessão expira, e a auditoria registra quem assumiu o quê.

aws sts assume-role --role-arn arn:aws:iam::000000000000:role/leitura-prod \
  --role-session-name investigacao-incidente-482
aws sts get-caller-identity      # confirme SEMPRE em qual conta você está

Para acesso humano a produção, o padrão que funciona é acesso just-in-time: papel de leitura por padrão, elevação temporária mediante justificativa e registro. Isso reduz o risco do clique errado e produz a trilha de auditoria que a LGPD e a auditoria interna vão pedir.

OIDC: CI sem chave de longa duração

Chave de acesso guardada como segredo do repositório é o item mais roubado do ecossistema. A federação OIDC elimina o segredo: o pipeline apresenta um token de identidade assinado pelo provedor de CI e recebe credencial temporária.

# GitHub Actions → AWS, sem nenhuma chave armazenada
permissions:
  id-token: write
  contents: read
steps:
  - uses: aws-actions/configure-aws-credentials@v4
    with:
      role-to-assume: arn:aws:iam::000000000000:role/deploy-loja-prod
      aws-region: sa-east-1

A parte crítica é a condição de confiança do papel. Sem restringir repositório e referência, qualquer workflow do GitHub assume o seu papel:

{
  "Effect": "Allow",
  "Principal": { "Federated": "arn:aws:iam::000000000000:oidc-provider/token.actions.githubusercontent.com" },
  "Action": "sts:AssumeRoleWithWebIdentity",
  "Condition": {
    "StringEquals": { "token.actions.githubusercontent.com:aud": "sts.amazonaws.com" },
    "StringLike": { "token.actions.githubusercontent.com:sub": "repo:empresa/loja:ref:refs/heads/main" }
  }
}

O mesmo mecanismo existe para Azure (federated credentials no Entra ID), GCP (Workload Identity Federation) e para Pods no Kubernetes (IRSA, Workload Identity) — em todos, o cuidado é o mesmo: restrinja o subject.

Auditoria de acesso

Sem revisão periódica, a permissão só cresce. O ciclo mínimo, trimestral:

• Liste credenciais estáticas que ainda existem e elimine as que dão para federar.
• Encontre papéis e chaves sem uso há 90 dias e remova.
• Revise quem tem privilégio administrativo — a lista costuma surpreender.
• Confira que o log de auditoria (CloudTrail, Activity Log, Cloud Audit Logs) está ativo em todas as contas, com destino em conta separada e imutável.

aws iam get-credential-report --output text --query Content | base64 -d | \
  awk -F, '$9=="true" && $11!="N/A"'      # chaves ativas e quando foram usadas

E monitore em tempo real o pequeno conjunto de eventos que quase sempre significa problema: uso da conta raiz, criação de chave de acesso, mudança de política de confiança, desativação de log, e login sem MFA.

Próximo passo: organize contas, guardrails e baseline em Landing zone. Para eliminar chaves do CI passo a passo, veja Deploy sem chave com OIDC.