Migrando a fonte de identidade no AWS IAM Identity Center: guia completo do Active Directory para Okta

Por que trocar a fonte de identidade é um momento crítico

O AWS IAM Identity Center é o serviço central de gerenciamento de acesso da AWS para contas AWS e aplicações integradas. Uma das decisões mais impactantes que uma organização pode tomar nesse contexto é mudar a fonte de identidade — ou seja, o sistema que define quem são os usuários e grupos que têm acesso ao ambiente AWS.

Essa mudança costuma acontecer quando a empresa troca de provedor de identidade (IdP), consolida sua infraestrutura de identidade, adota novas capacidades de Single Sign-On (Logon Único) ou migra de sistemas legados on-premises. O problema é que uma transição sem planejamento adequado pode resultar em perda temporária de acesso a contas e aplicações AWS até que as permissões sejam restauradas.

A AWS publicou um guia técnico detalhado que explica como fazer essa transição com segurança, incluindo um runbook passo a passo para migrar do Active Directory para o Okta como IdP externo via SAML 2.0 (Linguagem de Marcação para Asserções de Segurança). O material também disponibiliza scripts de automação no repositório aws-samples no GitHub.

As três fontes de identidade disponíveis no IAM Identity Center

Cada instância do IAM Identity Center se conecta a uma única fonte de identidade por vez. A AWS suporta três opções:

• Identity Center Directory: o armazenamento de identidade padrão. Usuários e grupos são criados e gerenciados diretamente no IAM Identity Center, sem dependência de um provedor externo. Indicado para organizações sem um diretório corporativo existente ou que preferem uma configuração que use apenas serviços AWS.
• Active Directory: integração com um Microsoft Active Directory on-premises ou com o AWS Managed Microsoft AD via AWS Directory Service. Permite reutilizar identidades, associações a grupos e políticas de acesso já existentes no AD.
• IdP Externo: integração com provedores terceiros que suportam SAML 2.0, como Okta Universal Directory, Microsoft Entra ID (antigo Azure AD), Ping Identity, entre outros.

O que é destruído na troca de fonte de identidade

Esse é o ponto mais crítico do guia: transições que envolvem o Active Directory são destrutivas. Ao confirmar a troca da fonte de identidade do AD para um IdP externo, o IAM Identity Center imediatamente exclui todos os usuários, grupos e suas respectivas atribuições — tanto de contas quanto de aplicações.

Já a transição entre um IdP externo e o diretório local do Identity Center preserva usuários, grupos e atribuições. A tabela abaixo resume o comportamento:

• Troca do AD para IdP externo: usuários, grupos, atribuições de contas e atribuições de aplicações são excluídos e precisam ser recriados.
• Troca de IdP externo para o diretório local: tudo é preservado.

Um ponto de atenção adicional: aplicações gerenciadas pela AWS que mantêm sua própria referência à fonte de identidade — como o Amazon SageMaker Studio e o Amazon OpenSearch Service — podem não ter o acesso totalmente restaurado apenas pela API CreateApplicationAssignments. Essas aplicações têm dependências do ID da fonte de identidade original e precisam ser tratadas caso a caso. Para mais detalhes sobre considerações ao trocar a fonte de identidade, a AWS mantém documentação específica sobre o tema.

O processo em cinco etapas

O guia da AWS estrutura a migração em cinco etapas fundamentais, que se aplicam a qualquer transição de fonte de identidade no IAM Identity Center:

• Etapa 1 — Backup: antes de qualquer mudança, exporte todos os dados de identidade: usuários, grupos e atribuições. O script de precheck gera arquivos CSV com todas as atribuições e principais do Identity Center.
• Etapa 2 — Preparar e validar usuários na nova fonte: confirme que os usuários e grupos existem na nova fonte de identidade antes de fazer a troca. Divergências em campos como UserName ou DisplayName podem impedir que os usuários se conectem após a migração.
• Etapa 3 — Trocar a fonte de identidade: atualize o IAM Identity Center para apontar para a nova fonte. Para IdPs externos, isso envolve fazer upload dos metadados SAML e configurar o SCIM (Sistema de Gerenciamento de Identidade entre Domínios) para provisionamento automatizado. Atenção: ao confirmar essa mudança, todas as atribuições do AD são imediatamente excluídas.
• Etapa 4 — Restaurar atribuições: após o provisionamento dos usuários e grupos na nova fonte, restaure todas as atribuições de contas usando o script de restauração. Um comando adicional verifica se há atribuições faltando ou em excesso.
• Etapa 5 — Validar o acesso: teste o acesso para uma amostra representativa de usuários com diferentes perfis e níveis de permissão antes de declarar a migração concluída.

Os scripts e detalhes estão disponíveis no GitHub. Bugs e solicitações de funcionalidades podem ser reportados via GitHub Issues. Clientes com Enterprise Support podem contatar seu Gerente Técnico de Contas (TAM) para dúvidas adicionais.

Runbook detalhado: do Active Directory para o Okta

O guia apresenta um runbook com sete fases para a migração do AD para o Okta como IdP SAML 2.0. Abaixo, um resumo de cada fase:

Fase 1: Planejamento pré-migração

Envolve quatro componentes: engajamento dos stakeholders (responsável pelo AD, administrador AWS, administrador Okta), inventário do estado atual com o script de precheck, definição da janela de cutover em período de baixo uso, e confirmação dos acessos necessários.

python -m idc_migration_tool precheck --output-dir ./export

Esse comando gera dois arquivos: assignments.csv (uma linha por conta, permission set e atribuição de principal) e principals.csv (todos os usuários e grupos do identity store).

Fase 2: Validação pré-cutover

Validar que os arquivos de backup estão presentes e não vazios, comunicar o impacto aos usuários (incluindo o novo fluxo de login pelo Okta), e realizar testes em ambiente sandbox com um usuário de teste para confirmar o provisionamento SCIM e o fluxo de autenticação de ponta a ponta.

Fase 3: Execução do cutover

Esta fase inclui a configuração do aplicativo Okta (obtendo o arquivo de metadados SAML), a troca da fonte de identidade no console do IAM Identity Center (com upload do XML de metadados e do certificado de assinatura SAML), a habilitação do provisionamento automático via SCIM, a configuração da integração SCIM no Okta com as URLs de endpoint e token gerados, e a configuração das URLs de ACS (Serviço de Asserção ao Consumidor) e Issuer no Okta.

Atenção: o downtime começa no momento em que a troca da fonte de identidade é confirmada. Usuários perdem acesso imediatamente e só recuperam após a conclusão da Fase 4.

Fase 4: Reconstrução das atribuições

Verificar que todos os usuários e grupos do Okta foram sincronizados via SCIM no IAM Identity Center, e então executar o script de restauração:

python -m idc_migration_tool cutover --csv ./export/assignments.csv

O script faz o match dos nomes de principais na nova fonte de identidade, cria as atribuições e reporta sucesso ou falha para cada uma. Aguarde de 5 a 10 minutos para a propagação das permissões antes de iniciar os testes.

Fase 5: Validação pós-migração

Teste o acesso de ponta a ponta com um usuário Okta de teste, validando login no dashboard, acesso ao portal AWS, assunção de role e navegação no console. Faça spot-check com usuários de diferentes perfis (Administrador, Desenvolvedor, Somente Leitura). Use o script de validação para detectar atribuições faltando ou em excesso:

python -m idc_migration_tool validate --csv ./export/assignments.csv --output-dir ./export

Se houver divergências, o script gera um arquivo drift_report.csv com entradas MISSING e EXTRA.

Fase 6: Limpeza e monitoramento pós-migração

Remova recursos obsoletos (roles IAM sincronizadas pelo AD que não foram limpas automaticamente), monitore o SCIM nos dias seguintes, revise os logs do IAM Identity Center e do AWS CloudTrail para tentativas de login com falha, e atualize toda a documentação interna (SOPs, guias de onboarding, mapeamentos de grupos para permission sets). O comando abaixo identifica usuários desativados, grupos vazios e permission sets sem atribuição:

# Apenas relatório
python -m idc_migration_tool cleanup

# Relatório com prompt para exclusão
python -m idc_migration_tool cleanup --delete

Importante: não descomissione os domain controllers do Active Directory até ter certeza de que a migração está estável e que o rollback não será mais necessário.

Fase 7: Rollback (se necessário)

O IAM Identity Center não retém usuários, grupos ou atribuições do AD após a troca de fonte de identidade. Um rollback exige trocar manualmente a fonte de identidade de volta para o Active Directory e reconstruir todas as atribuições a partir dos arquivos de backup. Não há desfazer automático.

O processo envolve: navegar até as configurações do IAM Identity Center, selecionar Active Directory como fonte de identidade, confirmar que o AD ainda está acessível, aguardar a ressincronização dos usuários e grupos, e então executar novamente o script de restauração:

python -m idc_migration_tool cutover --csv ./export/assignments.csv

Para dicas de troubleshooting, a AWS mantém documentação sobre resolução de problemas no IAM Identity Center.

Conclusão

A migração de fonte de identidade no IAM Identity Center é uma operação de alto impacto que exige planejamento cuidadoso. O guia publicado pela AWS oferece uma estrutura completa — desde o backup inicial até o rollback de emergência — para que times de identidade e segurança executem essa transição com previsibilidade e controle.

Os scripts de backup e restauração estão disponíveis no repositório aws-samples no GitHub. Para aprofundar o conhecimento sobre configuração do IAM Identity Center e gerenciamento de permission sets, a AWS recomenda o AWS Security Blog e a documentação oficial do AWS IAM Identity Center.

Fonte

Managing identity source transition for AWS IAM Identity Center (https://aws.amazon.com/blogs/security/managing-identity-source-transition-for-aws-iam-identity-center/)