Atualizado em
IAM (Identity and Access Management) é o conjunto de políticas, processos e ferramentas que controla quem pode acessar quais recursos em um ambiente cloud — e com quais permissões. É a fundação de qualquer estratégia de segurança: se o controle de identidades falha, todas as outras camadas ficam comprometidas.
O que é IAM e por que é tão crítico
Imagine que sua empresa tem 80 pessoas, cada uma com acesso a diferentes sistemas: ERP, repositório de código, ambiente de produção, sistema de RH, bucket de backup. Sem IAM estruturado, o que geralmente acontece é um crescimento orgânico caótico: alguém pede acesso, alguém concede, e ninguém revisa. Dois anos depois, o ex-desenvolvedor de um projeto encerrado ainda tem acesso ao banco de dados de produção. O analista de suporte tem permissão de administrador porque foi mais fácil do que configurar permissões granulares. A conta de serviço de uma aplicação legada tem acesso a todos os buckets de storage “para não dar erro”.
IAM é o sistema que previne exatamente esse cenário — gerenciando identidades, definindo o que cada uma pode fazer, aplicando políticas de forma consistente e auditando tudo.
Em ambientes cloud, IAM vai além de usuários humanos: inclui contas de serviço (processos automatizados que precisam se autenticar), roles (papéis que podem ser assumidos temporariamente), e chaves de API (credenciais usadas por aplicações e integrações). A superfície de identidades em cloud é muito maior que a gestão tradicional de usuários de Active Directory. É por isso que, no modelo Zero Trust, a identidade — e não a rede — passa a ser o novo perímetro.
Autenticação versus autorização — a diferença que fundamenta tudo
Esses dois conceitos são frequentemente confundidos, e a distinção é fundamental.
Autenticação responde: “Quem é você?” É o processo de verificar a identidade de quem está tentando acessar o sistema. Usuário e senha é o mecanismo mais básico. MFA adiciona um segundo fator — algo que você tem (token, app autenticador) além de algo que você sabe (senha). Certificados digitais, biometria e chaves SSH são outras formas de autenticação.
Autorização responde: “O que você pode fazer?” Depois de verificada a identidade, o sistema decide quais recursos essa identidade pode acessar e quais ações pode executar. Uma conta autenticada como “analista financeiro” pode acessar relatórios mas não pode deletar VMs. Uma conta autenticada como “desenvolvedor” pode fazer deploy em homologação mas não em produção.
A confusão entre os dois conceitos leva a erros como: “deixei o usuário entrar (autenticação), então está seguro” — mas sem controles adequados de autorização, o usuário autenticado pode acessar muito mais do que deveria.
Os conceitos centrais do IAM
Usuários: Identidades individuais — pessoas físicas ou contas de serviço. Cada usuário deve ter credenciais únicas. Contas compartilhadas (tipo “usuário_geral” com a senha distribuída para a equipe inteira) destroem a rastreabilidade — você não consegue saber quem fez o quê.
Grupos: Coleções de usuários com permissões comuns. Em vez de gerenciar permissões usuário por usuário, você cria grupos por função (desenvolvedores, analistas de suporte, gestores de backup) e atribui permissões ao grupo. Quando um novo colaborador entra, ele é adicionado ao grupo correto — e herda automaticamente as permissões adequadas.
Roles (papéis): Conjuntos de permissões que podem ser assumidos temporariamente — por usuários ou por serviços. Em vez de dar permissões permanentes a uma conta de serviço, você cria uma role com as permissões necessárias e a aplicação a assume quando precisa. Quando termina a tarefa, a role é descartada. Isso limita o tempo de exposição de permissões elevadas.
Políticas: As regras que definem o que pode ou não pode ser feito. Políticas são associadas a usuários, grupos ou roles e especificam: quais ações (ler, escrever, deletar), em quais recursos (bucket X, VM Y, banco de dados Z), sob quais condições (apenas do IP corporativo, apenas durante horário comercial).
Menor privilégio — o princípio que mais falha na prática
Least Privilege (menor privilégio) é o princípio de que cada identidade deve ter apenas as permissões necessárias para executar sua função — nada além. Parece óbvio. Na prática, é ignorado sistematicamente.
Por que é ignorado? Porque configurar permissões granulares leva tempo. Porque quando alguém não consegue fazer algo por falta de permissão, a solução rápida é adicionar mais permissão. Porque ninguém quer ser o responsável por travar um sistema crítico. O caminho de menor resistência leva para contas com permissão excessiva.
O problema real aqui é que permissão excessiva é explosivo de lento. Não causa dano imediato — mas quando uma conta comprometida tem acesso a tudo, o dano é total. É exatamente assim que campanhas de ransomware escalam de um endpoint para o ambiente inteiro. A contenção de um incidente é diretamente proporcional ao quanto você aplicou menor privilégio: uma conta com acesso limitado comprometida causa dano limitado.
Como implementar: mapeie o que cada função realmente precisa fazer, configure permissões mínimas, documente e revise trimestralmente. Ferramentas de IAM modernas têm funcionalidades de análise de permissões não usadas — “essa conta tem permissão de criar VMs mas nunca criou nenhuma nos últimos 90 dias” — que facilitam o processo de redução de privilégios.
Um caso em que menor privilégio é inegociável: as credenciais que acessam o sistema de backup. A conta que grava cópias não deve poder apagá-las — é isso que impede um atacante com credenciais de produção de destruir a sua última linha de defesa.
RBAC versus ABAC
RBAC (Role-Based Access Control): Permissões são atribuídas com base no papel (role) do usuário. “Desenvolvedores podem acessar o repositório de código e o ambiente de homologação.” Simples de implementar e de entender. Limitação: não consegue expressar condições dinâmicas — “pode acessar, mas apenas do escritório, e apenas durante horário comercial.”
ABAC (Attribute-Based Access Control): Permissões são determinadas por atributos do usuário, do recurso e do contexto. “Pode acessar se: [departamento=financeiro] E [nível=gerente] E [localização=rede corporativa] E [horário=9h-18h].” Muito mais expressivo, muito mais complexo de implementar e manter. Adequado para ambientes com requisitos de controle de acesso granular e contexto dinâmico.
A maioria das empresas começa com RBAC e adiciona elementos de ABAC onde a granularidade é necessária — por exemplo, exigindo que acesso a dados sensíveis só ocorra de dispositivos conformes e de redes corporativas.
Erros comuns que comprometem o IAM
Usuários com permissão de admin desnecessária: Todo administrador de sistema tem um usuário de dia a dia para e-mail e navegação, e um usuário separado com privilégios elevados que usa apenas quando necessário. Se o mesmo usuário tem admin permanente, qualquer comprometimento da sessão é comprometimento de admin.
Chaves de API sem expiração e sem rotação: Chaves de API são credenciais de longa duração — e ao contrário de senhas, raramente são trocadas. Chaves criadas anos atrás, com permissões amplas, para projetos que já foram encerrados, ficam ativas. Política de expiração e rotação periódica é obrigatória — o mesmo raciocínio que se aplica às chaves de criptografia.
Sem revisão periódica de acessos: O colaborador que foi promovido ainda tem acesso ao sistema da função anterior. O fornecedor cujo contrato encerrou ainda tem credenciais ativas. Revisão de acessos — access review — precisa ser processo, não eventualidade. Um SIEM ajuda a detectar o uso anômalo dessas contas esquecidas antes que vire incidente.
Contas de serviço com permissão humana: Contas de serviço não precisam de permissão para fazer login interativo, não precisam de acesso ao console de administração, e não precisam de permissões além do que a aplicação usa. Tratar contas de serviço como contas humanas genéricas é um erro clássico.
IAM em cloud privada versus cloud pública
Em AWS, IAM é o serviço central de controle de acesso — com políticas em JSON, roles assumíveis por serviços, e integração com todos os serviços AWS. Em Azure, é o Microsoft Entra ID (antigo Azure AD) com RBAC nativo do Azure. Cada provider tem sua implementação específica — e onde termina a responsabilidade do provedor e começa a sua é o que define o modelo de responsabilidade compartilhada.
Em cloud privada como a Adentro, o IAM pode ser implementado via Active Directory/LDAP integrado à plataforma, via soluções de IAM dedicadas (Keycloak, HashiCorp Vault para secrets, etc.) ou via integrações com o Identity Provider já existente na empresa. A vantagem é que você traz seu modelo de identidade corporativo para o ambiente cloud sem depender da implementação proprietária de um provider público.
A Adentro pode ajudar a estruturar o modelo de identidade e controle de acesso para seu ambiente de cloud privada. Fale com nosso time de especialistas.