AWS IAM para quem só queria publicar uma aplicação

Em algum momento entre “a aplicação funciona no ambiente local” e “a aplicação está rodando na AWS”, aparece uma tela pedindo permissão para alguma coisa que parecia óbvia demais para precisar de permissão. É aí que IAM deixa de ser um conceito abstrato e vira o obstáculo real do dia.

Usuário não é a mesma coisa que papel (role)

Um usuário IAM representa uma identidade de longo prazo, tipicamente associada a uma pessoa, com credenciais que continuam válidas até alguém revogá-las. Um papel, ou role, é diferente: é uma identidade temporária, assumida por tempo limitado, geralmente por um serviço da AWS, uma aplicação ou outro papel, via credenciais de curta duração emitidas pelo AWS STS.

A prática recomendada hoje é minimizar usuários IAM de longa duração. Para pessoas, prefere-se acesso via AWS IAM Identity Center, sucessor do antigo AWS SSO. Para uma aplicação rodando em EC2, Lambda ou ECS, o caminho recomendado é atribuir um papel ao recurso, não embutir uma credencial de usuário fixa dentro do código ou de um arquivo de configuração.

Política é onde a permissão é realmente escrita

Um papel ou usuário, por si só, não concede nenhuma permissão. Quem concede é a política, um documento JSON que especifica quais ações são permitidas ou negadas, sobre quais recursos, sob quais condições:

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

Essa política, por exemplo, permite apenas leitura de objetos dentro de um bucket específico, nada além disso. Anexada a um papel, ela define exatamente o que qualquer identidade usando aquele papel pode fazer.

Menor privilégio: fácil de recitar, chato de praticar

O princípio do menor privilégio diz que uma identidade deveria ter apenas as permissões estritamente necessárias para a tarefa que executa, nada a mais. Em teoria, ninguém discorda disso. Na prática, é comum ver políticas amplas demais, com ações usando * como atalho, porque descobrir a lista exata de permissões necessárias exige mais paciência do que abrir uma política genérica e seguir em frente.

A AWS oferece o Access Analyzer, que pode observar o uso real de uma identidade ao longo do tempo, via logs do CloudTrail, e sugerir uma política mais restrita baseada no que aquele papel de fato usou, em vez do que ele tinha permissão para usar.

Um obstáculo comum não é sinal de estar fazendo errado

Errar a primeira política, esquecer uma permissão que só aparece quando o código tenta fazer algo específico, ou descobrir que um papel está permissivo demais depois de já estar em produção, é bastante comum para qualquer pessoa configurando IAM pela primeira vez. Isso não é sinal de que a AWS é hostil de propósito, é sinal de que permissão granular exige iteração, não acerto de primeira.

O ponto de partida razoável é: comece restritivo, adicione permissão quando o erro apontar exatamente o que falta, e resista à tentação de resolver um erro de permissão simplesmente abrindo tudo.