IAM Básico #1: O que é IAM? Usuários, grupos e a diferença entre autenticação e autorização

Este é o primeiro post do Nível Básico da nossa série sobre AWS Identity and Access Management (IAM). Se você chegou agora, comece por aqui: vamos construir a base que sustenta todo o controle de acesso na nuvem — com exemplos práticos, uma comparação lado a lado dos conceitos e os erros mais comuns a evitar.

📚 O que você vai aprender neste post:

O que é o IAM e qual problema ele resolve;
A diferença entre autenticação e autorização;
Os quatro blocos fundamentais (usuários, grupos, roles e policies) — com uma tabela comparativa;
Um exemplo prático passo a passo;
O princípio do menor privilégio e por que ele é inegociável;
Erros comuns de iniciantes e um checklist de boas práticas.

O que é o IAM?

O AWS Identity and Access Management (IAM) é o serviço que controla quem pode acessar o quê na sua conta AWS, e sob quais condições. Ele é gratuito, global (não pertence a uma região específica) e está no centro de qualquer arquitetura segura na AWS.

Toda vez que uma pessoa ou um serviço tenta realizar uma ação — ler um arquivo no S3, iniciar uma instância EC2, gravar em um banco DynamoDB — é o IAM que decide, em milissegundos, se aquela requisição é permitida ou negada.

Por que isso importa tanto? Segundo diversos relatórios de segurança da indústria, uma parcela enorme dos incidentes na nuvem tem origem em configuração indevida de acesso: uma chave exposta em um repositório público, um bucket S3 aberto para a internet, um usuário com permissões de administrador que não deveria ter. O IAM é a sua principal linha de defesa contra essa classe de problemas.

Autenticação x Autorização: não confunda

Esses dois conceitos são a espinha dorsal do IAM, e entender a diferença é essencial:

Autenticação (quem é você?) — é a prova de identidade. Ao fazer login com usuário e senha, ou ao usar uma chave de acesso, você está se autenticando.
Autorização (o que você pode fazer?) — depois de autenticado, o IAM verifica quais permissões você possui para decidir se a ação solicitada é permitida.

Uma analogia: pense em um prédio corporativo. A autenticação é mostrar seu crachá na portaria e provar que você é quem diz ser. A autorização é o que o seu crachá efetivamente abre: talvez ele libere o 3º andar, mas não o data center no subsolo. Você pode estar perfeitamente autenticado e, ainda assim, não ter autorização para entrar em determinada sala.

Os blocos fundamentais do IAM

Usuários (IAM Users)

Representam uma pessoa ou aplicação com credenciais de longo prazo (senha e/ou chaves de acesso). Cada usuário deve ser individual — nunca compartilhe um mesmo usuário entre pessoas, pois isso destrói a rastreabilidade de quem fez o quê. Se cinco pessoas usam o mesmo login e algo dá errado, você não consegue saber quem foi responsável.

Grupos (IAM Groups)

São coleções de usuários. Em vez de conceder permissões a cada pessoa individualmente, você atribui permissões ao grupo (ex.: “Desenvolvedores”, “Financeiro”) e adiciona usuários a ele. Quando um novo desenvolvedor entra, basta adicioná-lo ao grupo — ele herda todas as permissões corretas na hora. Importante: grupos não podem ser aninhados (um grupo não contém outro grupo) e não podem ser usados como principal em uma policy.

Roles (Funções)

São identidades assumíveis temporariamente, sem senha ou chave fixa. Serviços (como uma instância EC2 ou uma função Lambda), usuários de outra conta ou identidades federadas assumem uma role para obter credenciais temporárias. É o mecanismo mais seguro — e vamos dedicar o próximo post inteiro a ele.

Policies (Políticas)

São documentos JSON que definem as permissões. Uma policy diz, por exemplo, “permitir leitura no bucket X”. Você anexa policies a usuários, grupos ou roles. Veja um exemplo simples que permite listar um bucket S3:

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

Comparação rápida

Para fixar, veja os quatro conceitos lado a lado:

👤 Usuário

Identidade de uma pessoa ou aplicação. Credencial de longo prazo. Use em casos específicos/legados.

👥 Grupo

Coleção de usuários. Sem credencial própria. Use para gerir permissões em escala.

🎭 Role

Identidade assumível. Credencial temporária. Use para serviços, cross-account e federação.

📜 Policy

Documento JSON de permissões. Define o que é permitido — anexada a usuários, grupos ou roles.

🛠️ Mão na massa: um exemplo do começo ao fim

Vamos juntar as peças em um cenário real. Imagine que a analista Ana acabou de entrar no time de dados e precisa ler relatórios armazenados em um bucket S3. O fluxo ideal seria:

Criar um grupo chamado Analistas-Dados.
Criar uma policy gerenciada que permite apenas leitura no bucket de relatórios (as ações s3:GetObject e s3:ListBucket).
Anexar a policy ao grupo, não à Ana diretamente.
Criar o usuário da Ana e adicioná-lo ao grupo Analistas-Dados.
Ativar o MFA para o login dela.

Resultado: quando outra analista, a Beatriz, for contratada, você só a adiciona ao grupo — sem recriar permissões. E se o time deixar de precisar daquele acesso, você ajusta a policy em um único lugar e a mudança vale para todos. É gestão de acesso escalável e auditável.

O princípio mais importante: menor privilégio

Se você guardar apenas uma ideia deste post, guarde esta: conceda somente as permissões necessárias para a tarefa, e nada além. Esse é o princípio do menor privilégio. Ele reduz drasticamente o impacto de uma credencial vazada ou de um erro humano.

Na prática, isso significa começar restritivo e ir abrindo conforme a necessidade real aparece — o oposto de conceder acesso amplo “para não dar trabalho” e nunca mais revisar. Uma permissão a mais hoje é uma porta aberta amanhã.

⚠️ Erros comuns de quem está começando

Usar a conta root no dia a dia — o root tem poder absoluto e deve ficar guardado. Falaremos disso no post 3.
Conceder AdministratorAccess “para agilizar” — é a receita para o desastre. Prefira permissões específicas.
Compartilhar um mesmo usuário entre pessoas — elimina a rastreabilidade.
Colar chaves de acesso no código — uma das principais causas de vazamento. Use roles.
Anexar permissões direto ao usuário em vez de usar grupos — vira um caos de manutenção.

✅ Checklist de boas práticas para começar

✅ Proteja a conta root com MFA e não a use no cotidiano;
✅ Crie usuários individuais e organize permissões por grupos;
✅ Aplique o princípio do menor privilégio desde o início;
✅ Prefira roles a chaves de acesso permanentes;
✅ Ative MFA para todos os acessos humanos.

💡 Resumo dos pontos-chave

O IAM controla quem faz o quê na AWS. Autenticação prova quem você é; autorização define o que você pode fazer. Os blocos fundamentais são usuários, grupos, roles e policies. E a regra que guia tudo é o menor privilégio.

No próximo post

Vamos aprofundar em Roles vs. Usuários: quando usar cada um, por que roles com credenciais temporárias são mais seguras e como isso se aplica no dia a dia. Até lá! 🚀

Informações sobre o autor

Dennis Silva atua com Segurança da Informação e Cibersegurança há +18 anos e iniciou sua carreira em uma das Big Four em auditoria de sistemas.

Atualmente, atua como Consultor de Cibersegurança no time de Professional Services da AWS na América Latina (Brasil), função que exerce há mais de 4 anos, com foco no atendimento a instituições financeiras.

Trabalhou como Coordenador de Segurança da Informação na maior empresa de desenvolvimento de software na América Latina. Anteriormente, atuou como consultor de Segurança da Informação, com foco em identificar e avaliar os riscos inerentes ao negócio e validar os controles existentes por meio de testes de invasão em infraestrutura interna/externa, aplicações Web e ERPs como SAP e TOTVS.

Foi responsável pela implementação da certificação ISO/IEC 27001:2013 na maior empresa de desenvolvimento de software da América Latina, potencializando a principal oferta de comercialização de software como serviço (SaaS) em datacenter próprio.

Posted in Cloud ·