IAM Identity Center e MFA: boas práticas para acesso seguro na AWS
Acesso humano com sessões temporárias e MFA reduz o ativo mais perigoso da AWS: as credenciais de longa duração.
Credenciais de longa duração são o ativo mais perigoso de qualquer ambiente AWS, porque vazam e não expiram sozinhas. O IAM Identity Center resolve grande parte desse problema para o acesso humano: ele oferece login único federado com sessões temporárias, organizadas por grupos e permission sets, em vez de usuários IAM com access keys espalhados pelas contas.
Este guia mostra como estruturar acesso humano com o IAM Identity Center e MFA de forma defensiva: modelar permission sets por função, exigir MFA resistente a phishing, controlar duração de sessão, planejar acesso de emergência e ligar o ciclo de vida ao provedor de identidade. O objetivo é eliminar credenciais permanentes para pessoas e tornar o acesso auditável.
Grupos, permission sets e contas
No IAM Identity Center, o acesso é modelado por grupos de usuários e permission sets, que definem o conjunto de permissões atribuído a um grupo em uma ou mais contas. Em vez de gerenciar permissões pessoa por pessoa, você atribui pessoas a grupos e grupos a contas, o que escala muito melhor e reduz erro.
Modele os permission sets por função real, aplicando menor privilégio, e evite um permission set administrativo amplo usado no dia a dia. Sessões geram credenciais temporárias, então um vazamento tem janela curta de validade, ao contrário de uma access key permanente.
Duração de sessão e boundary
A duração da sessão de um permission set é um controle de segurança direto: sessões longas são convenientes, mas ampliam a janela em que uma credencial temporária vazada ainda funciona. Prefira durações curtas para permission sets sensíveis e reserve sessões mais longas para acesso de baixo privilégio. Você também pode anexar uma permissions boundary ao permission set, definindo um teto que a política do dia a dia não ultrapassa, o que contém o efeito de um erro de configuração.
MFA obrigatório e resistente a phishing
Exija MFA para toda autenticação humana. Contas sem MFA são alvo direto de phishing e reutilização de senha vazada. Configure o Identity Center para pedir MFA sempre, não apenas quando o contexto parecer novo, e desative a opção de registrar o fator depois, que deixa uma janela sem proteção.
Fatores que resistem a phishing
Nem todo MFA é igual. Códigos de aplicativo autenticador e SMS ajudam, mas ainda podem ser capturados por um site de phishing que retransmite o código em tempo real. Fatores baseados em FIDO2 e WebAuthn, como chaves de segurança físicas e passkeys, amarram a autenticação ao domínio legítimo e não funcionam em um site falso, o que os torna resistentes a phishing. Prefira esses fatores para acesso privilegiado e ofereça-os como padrão sempre que possível.
- Exigir MFA para todo acesso humano, sem exceção
- Preferir FIDO2 e passkeys a códigos de aplicativo e SMS
- Modelar acesso por grupos e permission sets, não por pessoa
- Aplicar menor privilégio e boundary nos permission sets
- Definir duração de sessão curta para acesso sensível
- Integrar ao provedor de identidade para ciclo de vida automático
Ciclo de vida e acesso de emergência
Integrar o Identity Center a um provedor de identidade corporativo permite que o ciclo de vida do usuário, admissão e desligamento, controle automaticamente o acesso à AWS. O desligamento é um ponto crítico: um acesso que não é revogado quando a pessoa sai vira uma porta esquecida. Centralizar no Identity Center facilita revogar o acesso a todas as contas de uma vez.
Se o acesso humano depende de um provedor de identidade externo, planeje o que acontece quando ele fica indisponível. Um caminho de acesso de emergência, ou break-glass, evita ficar trancado para fora do ambiente durante um incidente. Ele deve ser raro, protegido por MFA forte, com credenciais guardadas de forma segura e uso auditado, de modo que qualquer acionamento gere alerta e revisão.
Reduzir credenciais de longa duração
O ganho central do Identity Center é reduzir, e idealmente eliminar, usuários IAM com access keys para pessoas. Acesso de máquina continua usando roles, mas o acesso humano migra para sessões temporárias federadas. Isso encolhe drasticamente a quantidade de credenciais permanentes que podem vazar e dar acesso persistente. Como a atividade passa a chegar por um único ponto federado, ela também fica mais fácil de auditar no CloudTrail.
Checklist prático
- Exigir MFA para todo acesso humano
- Preferir fatores de MFA resistentes a phishing, como FIDO2 e passkeys
- Modelar acesso por grupos e permission sets
- Aplicar menor privilégio e permissions boundary nos permission sets
- Definir duração de sessão curta para acesso sensível
- Evitar uso cotidiano de permission set administrativo amplo
- Integrar a um provedor de identidade corporativo
- Automatizar admissão e desligamento de acesso
- Revogar acesso imediatamente no desligamento
- Planejar um acesso de emergência auditado para falha do provedor
- Eliminar usuários IAM com access keys para pessoas
- Revisar atribuições de grupo periodicamente
Boas práticas
- Trate MFA como obrigatório, não opcional, para humanos
- Prefira MFA resistente a phishing para acesso privilegiado
- Use sessões temporárias no lugar de credenciais permanentes
- Ajuste a duração de sessão ao nível de privilégio
- Escale acesso por grupos, não por pessoa
- Integre o ciclo de vida ao provedor de identidade
- Mantenha acesso de máquina em roles, separado do humano
Erros comuns
Contas humanas sem MFA
Alvo direto de phishing e de reutilização de senha vazada.
MFA apenas por SMS ou código de aplicativo para acesso crítico
Um site de phishing pode retransmitir o código e passar pelo segundo fator.
Usuários IAM com access keys para pessoas
Credenciais permanentes que vazam e dão acesso persistente.
Permission set administrativo no dia a dia
Qualquer comprometimento de sessão vira acesso amplo.
Sessões muito longas para acesso privilegiado
Amplia a janela em que uma credencial temporária vazada ainda funciona.
Acesso não revogado no desligamento
Portas esquecidas continuam abertas após a saída da pessoa.
Quando procurar apoio especializado
Migrar acesso humano para federação com MFA e modelar permission sets por função é parte do serviço de Segurança AWS e Cloud Security da GUARDIASEC, que ajuda a reduzir credenciais de longa duração e a estruturar o acesso de forma auditável.
Perguntas frequentes
Qual a diferença entre IAM Identity Center e usuários IAM?
Usuários IAM têm credenciais de longa duração e são geridos conta a conta. O IAM Identity Center oferece login federado com sessões temporárias, centralizado, com acesso modelado por grupos e permission sets. Para acesso humano, o Identity Center é mais seguro porque reduz credenciais permanentes e facilita a gestão do ciclo de vida.
Preciso de MFA mesmo usando o Identity Center?
Sim, e é justamente um dos maiores ganhos. O Identity Center permite exigir MFA para todo acesso humano de forma centralizada. Sem MFA, uma senha vazada ou um phishing bem-sucedido dão acesso direto. Com MFA, especialmente fatores resistentes a phishing, o roubo de senha sozinho não é suficiente para entrar.
Por que preferir MFA resistente a phishing?
Códigos de aplicativo autenticador e SMS podem ser capturados por um site de phishing que retransmite o código em tempo real para o serviço verdadeiro. Fatores baseados em FIDO2 e WebAuthn, como chaves de segurança e passkeys, amarram a autenticação ao domínio legítimo e não funcionam em um site falso. Por isso são a escolha mais forte, sobretudo para acesso privilegiado.
Como escolho a duração da sessão de um permission set?
Equilibre conveniência e exposição. Sessões longas evitam relogins frequentes, mas mantêm credenciais temporárias válidas por mais tempo caso vazem. A prática é usar durações curtas para permission sets sensíveis, com acesso administrativo ou a dados críticos, e reservar sessões mais longas para acesso de baixo privilégio, onde o impacto de um vazamento é menor.
O que fazer se o provedor de identidade ficar indisponível?
Se o acesso humano depende de um provedor externo, uma queda dele pode trancar a equipe para fora justamente durante um incidente. Por isso vale manter um caminho de acesso de emergência, ou break-glass, raro, protegido por MFA forte, com credenciais guardadas de forma segura e uso auditado. Qualquer acionamento deve gerar alerta e revisão posterior.
O Identity Center serve para acesso de máquina?
Ele é voltado ao acesso humano federado. Acesso de máquina, como aplicações e serviços, deve continuar usando roles do IAM, que geram credenciais temporárias para a carga. A separação é saudável: humanos usam sessões federadas com MFA, máquinas assumem roles, e ninguém depende de access keys permanentes.
Como o ciclo de vida do usuário ajuda na segurança?
Integrando o Identity Center a um provedor de identidade corporativo, a admissão e o desligamento de pessoas controlam automaticamente o acesso à AWS. Isso evita o problema clássico do acesso que continua ativo depois que a pessoa sai. Centralizar também permite revogar o acesso a todas as contas de uma vez quando necessário.
Guias relacionados
Próximo passo
Vamos avaliar os riscos do seu ambiente?
Conte seu cenário e definimos juntos o escopo certo. O objetivo é reduzir caminhos prováveis de ataque e elevar a maturidade de segurança, sem promessas absolutas.