Identity Provider centralizado
Lição 7 · Módulo 2 — Autenticação e segredos
O problema de N identidades
Uma empresa tem 200 pessoas e 30 contas AWS. Se cada pessoa tem um IAM User em cada conta, você gerencia 6 mil identidades, 6 mil senhas e 6 mil MFAs. Quando alguém sai, precisa desativar 30 usuários. Inviável.
A solução é uma identidade por pessoa, vinda de um Identity Provider (IdP) central, que concede acesso às contas AWS sob demanda — com credenciais temporárias.
IAM Identity Center
O AWS IAM Identity Center (antigo AWS SSO) é a solução recomendada para acesso humano a múltiplas contas AWS. Funciona assim:
- Você conecta um IdP (Microsoft Entra ID, Okta, Google Workspace, ou o diretório nativo do Identity Center).
- Usuários autenticam uma vez no IdP.
- Veem um portal com todas as contas AWS que podem acessar.
- Ao clicar numa conta, recebem credenciais temporárias STS para a role apropriada.
Sem IAM Users. Sem access keys. Sem proliferação.
Permission Sets
Em vez de criar policies dentro de cada conta, você define
permission sets
no Identity Center (ex.: DeveloperRO, BillingAdmin) e
aplica-os a grupos do IdP em contas específicas.
Por baixo, o Identity Center cria automaticamente uma IAM Role
AWSReservedSSO_<permission-set>_<hash> em cada conta alvo.
Você nunca mexe nessa role manualmente.
Federação direta (sem Identity Center)
Antes do Identity Center existir, a federação era configurada manualmente com IAM Identity Providers. Existem dois tipos principais:
SAML 2.0
corporativo
Usado com IdPs corporativos tradicionais (Active Directory Federation Services,
Okta SAML clássico). O usuário autentica no IdP, recebe uma asserção SAML e
chama sts:AssumeRoleWithSAML para obter credenciais AWS temporárias.
OIDC
moderno
Padrão para IdPs modernos e cargas não-humanas (GitHub Actions, Kubernetes/IRSA,
Cognito). A identidade traz um JWT, a AWS valida com o IdP e concede
credenciais via sts:AssumeRoleWithWebIdentity.
Caso de uso especialmente relevante: OIDC em CI/CD — GitHub Actions assume uma role diretamente, sem nenhuma access key guardada no repo.
Cognito — caso diferente
Não confunda com Amazon Cognito: enquanto Identity Center gerencia acesso dos funcionários à AWS, Cognito gerencia identidade dos usuários da sua aplicação (clientes finais). Propósitos diferentes.
Teste rápido
Sua empresa usa Microsoft Entra ID e tem 12 contas AWS. Qual a abordagem recomendada para dar acesso aos 80 devs?
Resumo
Para humanos em múltiplas contas: IAM Identity Center conectado ao seu IdP corporativo. Para CI/CD: OIDC federation. Para usuários finais da sua aplicação: Cognito. O ponto comum: sempre credenciais temporárias, nunca access keys de IAM User.
Referência Well-Architected
Esta lição está alinhada com a boa prática Rely on a centralized identity provider do Well-Architected Framework.
Referências
Terminou esta lição?
Seu progresso fica salvo apenas neste navegador.