Cloud IAM: identidades, permissões e segurança sem compartilhar chaves
Entenda IAM em Cloud por conceitos transferíveis: autenticação, autorização, identidades humanas e de workload, roles, policies, least privilege, credenciais temporárias e auditoria.
Uma arquitetura Cloud pode ter compute, storage, banco e rede perfeitamente desenhados e ainda assim ser insegura por uma pergunta mal respondida:
quem pode fazer o quê em qual recurso?
Essa é a pergunta central de IAM — Identity and Access Management.
IAM não é “a tela de usuários da cloud”.
É o sistema que transforma identidade em permissão.
Ele precisa responder coisas como:
- quem está fazendo a requisição?
- essa identidade é uma pessoa ou um workload?
- em qual contexto ela foi autenticada?
- qual ação deseja executar?
- em qual recurso?
- qual política autoriza ou bloqueia?
- por quanto tempo a credencial é válida?
- como essa decisão será auditada?
Os nomes mudam entre AWS, Google Cloud e Azure.
O modelo mental permanece.
Autenticação e autorização são problemas diferentes
Autenticação responde:
quem é você?
Autorização responde:
o que você pode fazer?
Uma pessoa pode se autenticar corretamente e ainda não ter permissão para excluir um bucket.
Uma aplicação pode provar sua identidade e receber somente acesso de leitura.
Essa separação parece básica, mas evita vários erros.
Quando equipes dizem “ele tem acesso”, normalmente falta precisão.
Acesso a quê?
Para fazer qual ação?
Em qual escopo?
Com qual identidade?
Por quanto tempo?
IAM torna essas perguntas explícitas.
Identidade humana e identidade de workload
Cloud precisa representar dois tipos de atores muito diferentes.
Pessoas
Desenvolvedores, operadores, analistas e administradores precisam entrar em consoles, chamar APIs ou operar recursos.
Essas identidades deveriam estar ligadas a pessoas reais e, idealmente, a um provedor de identidade corporativo.
O objetivo é evitar:
- contas compartilhadas;
- usuários genéricos;
- credenciais que ninguém sabe de quem são;
- contas que permanecem ativas após a saída de alguém.
Workloads
Aplicações também precisam acessar recursos.
Uma VM pode ler objetos.
Um worker pode publicar numa fila.
Uma função pode consultar um banco.
Um pipeline pode fazer deploy.
Esses workloads não deveriam fingir ser pessoas.
Eles precisam de identidades próprias.
AWS usa roles como mecanismo central para workloads em vários cenários.
Google Cloud usa service accounts e formas mais novas de workload identity.
Azure usa service principals, managed identities e o conceito mais amplo de workload identity.
O princípio é:
software deve autenticar como software, não reutilizar credencial humana.
Principal: a identidade que participa da decisão
Documentações usam termos como principal, member, identity ou security principal.
O conceito é parecido: existe uma entidade reconhecida pelo sistema de identidade.
Ela pode ser:
- usuário;
- grupo;
- role assumida;
- service account;
- managed identity;
- workload federado;
- aplicação;
- serviço da própria plataforma.
Essa entidade participa de uma avaliação de autorização.
Quanto melhor modelamos identidades, menos precisamos distribuir segredos manualmente.
Role: um conjunto de permissões com significado
Uma role agrupa permissões.
Em vez de conceder dezenas de ações uma por uma para cada pessoa, você pode expressar uma responsabilidade.
Exemplos conceituais:
- leitor de objetos;
- operador de rede;
- administrador de banco;
- deployer;
- auditor;
- executor de backup.
Google Cloud usa roles predefinidas e custom roles.
Azure RBAC usa role definitions e role assignments.
AWS usa policies associadas a identities/roles e recursos; o termo “role” também representa uma identidade assumível.
Os modelos não são idênticos.
Mas a intenção é comum:
transformar permissões técnicas em capacidades gerenciáveis.
Policy: a regra que autoriza ou nega
Policy é uma forma de declarar permissões.
Ela pode considerar:
- ação;
- recurso;
- identidade;
- condição;
- contexto;
- origem;
- tags;
- tempo;
- atributos.
Na AWS, policies são centrais ao modelo IAM e podem estar associadas a identities ou recursos.
No Google Cloud, IAM policies vinculam principals a roles em recursos.
No Azure, RBAC combina security principal, role definition e scope através de role assignments.
Não tente traduzir cada estrutura campo por campo entre provedores.
Aprenda primeiro:
identidade
+
permissão
+
escopo
+
condições
=
decisão de autorização
Least privilege: só o necessário
Princípio do menor privilégio significa conceder apenas o necessário para uma tarefa.
Não “Contributor porque funciona”.
Não “Admin para resolver rápido”.
Não “: enquanto estamos testando”.
Permissão ampla acelera a primeira execução e aumenta o blast radius de qualquer erro ou comprometimento.
Imagine um worker que só precisa ler objetos de um bucket.
Ele não precisa necessariamente:
- apagar objetos;
- criar usuários;
- alterar rede;
- acessar outro projeto;
- administrar banco;
- modificar IAM.
Se essa identidade vazar, o impacto deveria ser limitado ao mínimo possível.
AWS, Google Cloud e Azure tratam least privilege como prática fundamental.
Escopo importa tanto quanto a role
Uma permissão pode ser razoável num recurso e excessiva numa organização inteira.
“Storage reader” num único bucket é diferente de storage reader em todos os projetos.
“Contributor” num resource group é diferente de contributor na subscription inteira.
A mesma role pode ser segura ou perigosa dependendo do escopo.
Por isso autorização deve ser pensada como:
capacidade × escopo
Quanto mais alto o escopo, maior o impacto potencial.
Credenciais de longa duração são dívida operacional
Uma access key copiada para um arquivo pode funcionar por meses.
Esse é justamente o problema.
Credenciais long-lived precisam ser:
- armazenadas;
- protegidas;
- distribuídas;
- rotacionadas;
- revogadas;
- rastreadas.
Cada cópia cria uma nova oportunidade de vazamento.
Uma chave que termina em:
- repositório;
- log;
- backup;
- laptop antigo;
- imagem de VM;
- variável de CI esquecida;
pode permanecer utilizável por muito tempo.
Cloud moderna oferece alternativas melhores para muitos workloads.
Roles e credenciais temporárias na AWS
AWS recomenda o uso de IAM roles para workloads como aplicações em EC2.
A aplicação não precisa carregar access key permanente.
A instância recebe uma role e consegue obter credenciais temporárias através do mecanismo da plataforma.
Essas credenciais:
- expiram;
- são renovadas;
- herdam as permissões da role;
- evitam distribuir segredos estáticos para cada VM.
Isso não torna a role segura automaticamente.
Se ela tiver permissões excessivas, as credenciais temporárias também terão.
O ganho é eliminar a gestão de segredo de longa duração, não eliminar a necessidade de least privilege.
Service accounts no Google Cloud
Google Cloud usa service accounts como identidades de workloads.
Uma VM pode ter uma service account associada.
A aplicação executada nessa VM consegue usar as credenciais fornecidas pela plataforma para chamar APIs autorizadas.
As permissões vêm das roles concedidas à service account.
Isso permite separar workloads.
Por exemplo:
- API web com leitura em um bucket;
- worker com acesso à fila;
- job de backup com permissão em storage;
- processo de deploy com capabilities diferentes.
Usar uma única service account poderosa para tudo elimina boa parte desse isolamento.
Workload Identity reduz chaves estáticas
Google Cloud também oferece Workload Identity Federation e mecanismos relacionados.
O objetivo é permitir que workloads externos ou executados em plataformas como Kubernetes obtenham acesso baseado em identidade federada, em vez de carregar service account keys.
Isso cria um padrão importante:
o workload prova quem é no ambiente onde roda e troca essa prova por acesso temporário à Cloud.
Esse modelo é mais forte que distribuir um JSON de credenciais para cada aplicação.
Managed identities no Azure
Azure oferece managed identities para recursos.
A plataforma cria ou associa uma identidade no Microsoft Entra ID e o workload pode obter tokens sem que você armazene credenciais no código.
Depois, Azure RBAC controla o que essa identidade pode acessar.
Managed identity não é permissão.
É identidade.
Você ainda precisa atribuir roles no escopo correto.
Microsoft também recomenda least privilege para managed identities, justamente porque qualquer permissão da identidade fica disponível ao recurso que a utiliza.
System-assigned e user-assigned identity
Azure diferencia identidades gerenciadas cujo lifecycle acompanha o recurso e identidades criadas separadamente.
O detalhe varia por caso, mas o conceito é útil:
- identidade acoplada ao recurso simplifica lifecycle;
- identidade independente pode ser reutilizada e sobreviver a recursos específicos.
Essa escolha afeta blast radius e governança.
Uma identidade compartilhada por muitos workloads cria uma superfície maior.
Identidades separadas aumentam granularidade e trabalho de gestão.
O princípio continua sendo equilíbrio entre isolamento e complexidade.
Identidade de workload deve ser específica
Um erro comum é dar à aplicação a mesma identidade usada pela equipe de operações.
Isso mistura:
- acesso humano;
- acesso de runtime;
- deploy;
- administração.
Depois fica difícil responder:
quem fez esta ação?
Se todos usam a mesma identidade, auditoria perde valor.
Uma arquitetura melhor separa:
pessoa
→ identidade humana
pipeline
→ identidade de automação
aplicação
→ workload identity
serviço gerenciado
→ service identity quando aplicável
Cada uma com permissões diferentes.
Rede não substitui IAM
“Está numa subnet privada” não é política de autorização suficiente.
Rede responde se um pacote consegue chegar.
IAM responde se uma identidade pode executar uma ação.
Um banco pode estar numa rede privada e ainda aceitar credenciais excessivamente poderosas.
Um bucket pode não usar rede privada e ainda estar fortemente protegido por IAM.
Um endpoint interno pode ser chamado por qualquer workload comprometido dentro da rede se não houver autorização adequada.
A defesa vem de camadas.
rede
+
identidade
+
autorização
+
aplicação
Nenhuma substitui completamente as outras.
IAM também não substitui segurança de rede
O inverso também é verdadeiro.
Ter roles perfeitas não significa que você deve expor serviços administrativos para a Internet.
Alguns protocolos e sistemas possuem controles próprios que não usam o IAM do provedor.
Uma VM com IAM rigoroso ainda pode executar um serviço vulnerável numa porta pública.
IAM protege chamadas e recursos integrados ao sistema de identidade.
Rede continua controlando caminhos de conectividade.
Secrets: quando ainda existe um segredo real
Workload identity reduz muito a necessidade de secrets estáticos.
Ainda assim, aplicações podem precisar de:
- token de API externa;
- senha de serviço legado;
- certificado;
- chave privada;
- webhook secret;
- credencial de sistema fora da Cloud.
Esses dados precisam de lifecycle próprio.
O ideal é usar um secret manager ou mecanismo equivalente em vez de espalhar valores no código.
Mas guardar segredo em cofre não resolve tudo.
Você ainda precisa definir:
- quem pode ler;
- quem pode alterar;
- como rotaciona;
- como audita;
- como revoga;
- como a aplicação recebe.
IAM e secret management trabalham juntos.
KMS e chaves são outra camada
Key management trata de chaves criptográficas e operações como encrypt/decrypt/sign.
Isso não é o mesmo que IAM, embora IAM controle quem pode usar chaves.
Uma chave protegida num serviço KMS pode ser muito mais segura que um arquivo privado copiado entre servidores.
Mas permissões excessivas para usar essa chave podem anular parte do benefício.
Segurança Cloud frequentemente combina:
- identidade;
- autorização;
- secrets;
- key management;
- network controls;
- logging.
Audit logs: quem fez o quê
IAM fica muito mais útil quando decisões e ações deixam trilha.
Audit logs podem mostrar:
- identidade;
- ação;
- recurso;
- horário;
- origem;
- resultado;
- mudanças em políticas.
Isso permite investigar perguntas como:
- quem removeu este firewall?
- qual role criou esta VM?
- quando a permissão foi ampliada?
- qual workload acessou este storage?
- quem alterou esta policy?
Sem identidade individualizada, o log pode mostrar apenas uma conta genérica.
Auditoria depende de boas identidades.
Permissão excessiva vira dívida invisível
Permissões tendem a crescer.
Alguém recebe acesso temporário para resolver incidente.
Depois não é removido.
Uma role ganha nova ação porque “faltou permissão”.
Outro time reutiliza a mesma role.
Meses depois ninguém sabe mais qual acesso é realmente necessário.
Essa deriva precisa de manutenção.
Práticas úteis incluem:
- revisar roles;
- remover identidades antigas;
- reduzir escopo;
- analisar permissões não utilizadas;
- evitar wildcard amplo;
- expirar acessos temporários;
- separar ambientes.
IAM é operação contínua.
Break-glass não deveria virar conta diária
Ambientes críticos podem precisar de uma identidade de emergência com privilégios elevados.
Ela serve para situações excepcionais.
Se todo mundo usa a conta break-glass diariamente, ela deixou de ser break-glass.
Acesso privilegiado deveria ser:
- raro;
- auditado;
- protegido;
- temporário quando possível;
- revisado após uso.
A rotina deveria funcionar com roles menores.
Desenvolvimento local sem copiar credencial de produção
Um desafio aparece quando o desenvolvedor precisa chamar Cloud APIs localmente.
A solução mais frágil é copiar a mesma key usada em produção.
Alternativas incluem:
- login federado;
- SSO;
- identidade de desenvolvimento separada;
- credencial temporária;
- ambiente sandbox;
- impersonation controlada quando suportada.
O objetivo é manter produção e desenvolvimento com identidades distintas.
Se uma chave local vazar, o impacto não deveria equivaler à aplicação de produção.
CI/CD também é um workload
Pipelines são software.
Eles fazem deploy, publicam imagens e alteram infraestrutura.
Portanto precisam de workload identity própria.
Um padrão moderno é federação entre GitHub Actions, GitLab ou outro CI e o provedor Cloud.
O pipeline prova sua identidade e recebe credencial temporária.
Isso reduz a necessidade de guardar uma access key permanente no secret do repositório.
Ainda assim, a role do pipeline precisa ser mínima.
Deploy não precisa necessariamente poder administrar billing ou IAM global.
IAM é uma linguagem de risco
Uma forma útil de ler qualquer configuração IAM é perguntar:
quem?
identidade
pode fazer o quê?
ação
em quê?
recurso
onde?
escopo
sob quais condições?
policy
por quanto tempo?
credencial / sessão
Esse modelo funciona nos três provedores.
A sintaxe muda.
O risco é comparável.
Uma regra prática: identidade antes do segredo
Sempre que uma aplicação precisar acessar um recurso Cloud, pergunte nesta ordem:
- existe workload identity nativa?
- existe federação?
- existe credencial temporária?
- somente então preciso de secret estático?
Essa ordem evita criar dívida de chaves quando a plataforma já oferece identidade.
Outra regra: permissão começa pequena
Ao criar uma role:
- defina a tarefa;
- identifique ações necessárias;
- limite recursos;
- use condições quando fizer sentido;
- teste;
- amplie apenas com evidência.
É mais trabalhoso que conceder admin.
É muito mais fácil de defender depois.
O ponto de IAM não é impedir trabalho
IAM ruim cria dois extremos.
No primeiro, tudo é liberado e o ambiente fica inseguro.
No segundo, ninguém consegue fazer nada e surgem atalhos, contas compartilhadas e bypass.
O objetivo é permitir o trabalho correto com o menor privilégio compatível.
Boa autorização é uma ferramenta de velocidade sustentável.
Ela reduz medo de mudanças porque blast radius é menor.
O mapa mental que vale levar
Quando você olhar para IAM em qualquer Cloud, ignore primeiro o nome do produto.
Procure:
identidades humanas
↓
groups / federation / SSO
identidades de workload
↓
roles / service accounts / managed identities
permissões
↓
policies / RBAC
escopo
↓
organization / account / subscription / project / resource
credenciais
↓
temporárias preferencialmente
auditoria
↓
quem fez o quê
Se você entende esse mapa, consegue aprender a sintaxe específica depois.
Segurança Cloud é composição
IAM não é uma feature isolada.
Ele se conecta a:
- rede;
- compute;
- storage;
- banco;
- CI/CD;
- secrets;
- KMS;
- observabilidade;
- governança.
Uma identidade poderosa pode atravessar várias camadas.
Uma identidade mínima limita o impacto de falhas nessas mesmas camadas.
Por isso IAM é parte da arquitetura, não uma configuração que fica para o final.
Depois de escolher onde o workload roda e onde seus dados vivem, a próxima pergunta deve ser:
qual identidade precisa acessar cada recurso e qual é a menor permissão capaz de realizar a tarefa?
Essa pergunta é muito mais importante que decorar onde o botão “Add role” fica em cada console.