Terceiro post do Nível Avançado da série AWS IAM. Como dar acesso a dezenas ou centenas de pessoas sem criar um usuário IAM para cada uma — e sem virar refém de senhas espalhadas? A resposta moderna é federação de identidades com o IAM Identity Center.
📚 O que você vai aprender neste post:
- O que é federação de identidades e os protocolos envolvidos;
- O que o IAM Identity Center oferece;
- Como funcionam os permission sets;
- Um exemplo prático de onboarding de uma pessoa nova;
- A recomendação atual: federação x usuários IAM.
O que é federação de identidades?
Federação é permitir que identidades gerenciadas fora da AWS — no seu Active Directory, Google Workspace, Okta, Microsoft Entra ID, etc. — acessem a AWS sem precisar de usuários IAM dedicados. As pessoas fazem login com as credenciais que já usam no dia a dia, e recebem credenciais temporárias na AWS.
Os protocolos por trás disso costumam ser SAML 2.0 e OIDC. O provedor de identidade (IdP) autentica a pessoa e emite uma “asserção” confiável; a AWS confia nesse IdP e troca essa asserção por credenciais temporárias. A grande vantagem é ter um único ponto de verdade para identidades, com desligamento centralizado — ao remover a pessoa do diretório corporativo, o acesso à AWS cai junto, automaticamente.
IAM Identity Center (antigo AWS SSO)
O IAM Identity Center é o serviço recomendado pela AWS para gerenciar acesso humano, especialmente em ambientes com múltiplas contas. Ele oferece:
- Login único (SSO) para todas as contas da sua organização, com um portal de acesso central.
- Integração com seu provedor de identidade externo ou um diretório próprio embutido.
- Permission sets — conjuntos de permissões reutilizáveis aplicados a grupos de usuários em contas específicas.
- Credenciais sempre temporárias, sem chaves de longo prazo.
Permission sets na prática
Um permission set é como um “molde” de acesso. Você o define uma vez e o atribui a combinações de grupo + conta. Nos bastidores, o Identity Center provisiona automaticamente as roles IAM correspondentes em cada conta — você não gerencia essas roles manualmente, o que elimina uma enorme fonte de trabalho repetitivo e erro.
🛠️ Mão na massa: onboarding de uma pessoa
Uma nova analista financeira entrou na empresa. Com o Identity Center integrado ao diretório corporativo, o acesso dela à AWS se resume a:
- A pessoa já existe no diretório corporativo (criada pelo RH/TI) e faz parte do grupo
Financeiro. - Existe um permission set
Leitura-Financeiroatribuído ao grupoFinanceirona conta de produção. - Nada mais a fazer: ela abre o portal de acesso, faz login com as credenciais corporativas (com MFA) e já vê as contas/permissões a que tem direito.
E o desligamento é igualmente simples: ao ser removida do diretório, ela perde o acesso à AWS na mesma hora — sem ninguém precisar lembrar de “apagar o usuário IAM”. Menos trabalho manual, menos contas órfãs, menos risco.
Federação x usuários IAM: a recomendação atual
- Pessoas → IAM Identity Center / federação (credenciais temporárias, gestão centralizada).
- Serviços e aplicações AWS → roles IAM (como vimos no nível intermediário).
- Usuários IAM tradicionais → apenas casos específicos e legados.
A direção é inequívoca: menos credenciais permanentes, mais identidade centralizada e temporária. Isso reduz o esforço operacional e, ao mesmo tempo, eleva a segurança — uma das raras situações em que os dois andam juntos.
💡 Fechamento do Nível Avançado
Você agora domina permission boundaries, acesso cross-account e federação — as ferramentas para operar IAM em escala, com múltiplas contas e muitas pessoas, sempre com credenciais temporárias.
SAML x OIDC: quando cada um aparece
Vale distinguir os dois protocolos mais comuns de federação. O SAML 2.0 é tradicional no mundo corporativo e integra bem com diretórios como Active Directory e provedores como Okta e Entra ID — típico para acesso humano ao console. Já o OIDC (baseado em OAuth 2.0) é mais comum em cenários modernos e de aplicações, incluindo a federação de cargas de trabalho, como pipelines de CI/CD (por exemplo, o GitHub Actions assumindo uma role via OIDC, sem guardar chaves da AWS no repositório).
Esse último caso é especialmente valioso: ele estende o princípio de “credenciais temporárias, zero segredos” para fora da AWS, eliminando aquelas chaves de acesso que antes ficavam guardadas em segredos de pipeline — uma fonte histórica de vazamentos.
ABAC: permissões que seguem atributos
A federação abre a porta para o ABAC (Attribute-Based Access Control): em vez de escrever uma policy por equipe, você usa atributos vindos do provedor de identidade (como “departamento” ou “projeto”) como session tags e escreve políticas que comparam a tag do usuário com a tag do recurso. Assim, uma única política do tipo “acesse recursos cujo projeto seja igual ao seu” atende a toda a organização.
O ABAC reduz drasticamente o número de políticas a manter e escala naturalmente: quando um novo projeto surge, não é preciso criar novas regras — basta que as tags estejam corretas na identidade e no recurso.
No próximo post
Começamos o Nível Especialista, mergulhando na lógica de avaliação de policies da AWS — como, exatamente, um pedido é permitido ou negado. 🔴
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.