Uma migração de palavras-passe não é uma cópia de base de dados. Quando os utilizadores passam de um identity provider para outro, a origem muitas vezes não consegue fornecer uma palavra-passe que o destino possa reutilizar. Mesmo que uma exportação contenha hashes de palavras-passe, um hash produzido para uma plataforma não é automaticamente válido noutra.
Por vezes, os utilizadores podem manter a palavra-passe existente sem uma reposição forçada. O método seguro depende do que a origem pode exportar, da possibilidade de validar palavras-passe online, do tempo durante o qual pode permanecer disponível e de a migração conseguir associar cada conta a um identificador de origem estável.
Este artigo fornece um modelo de decisão para escolher entre importação compatível, validação gradual de palavras-passe, validação externa continuada e uma reposição controlada. Centra-se no percurso da palavra-passe. Os protocolos das aplicações, os claims, o registo da multi-factor authentication (MFA) e o plano completo de cut-over continuam a ter de ser tratados como linhas de trabalho de migração relacionadas.
Comece pela origem, não pela experiência de utilizador pretendida
«Sem reposição da palavra-passe» é um resultado desejável, mas ainda não é um método de migração. Antes de escolher uma abordagem, determine o que a origem consegue realmente suportar:
- Pode exportar palavras-passe em texto simples ou uma representação da palavra-passe explicitamente suportada pelo destino?
- Pode validar a palavra-passe atual de um utilizador através de uma API de validação protegida?
- Essa API pode permanecer disponível, monitorizada e suportada durante uma migração gradual e a janela de rollback?
- Existe um identificador de utilizador estável e imutável na origem que associe a mesma conta apesar de alterações aos identificadores?
- As alterações e reposições de palavras-passe podem manter-se coerentes enquanto estão envolvidos dois sistemas?
- A política de segurança, os contratos e a avaliação de risco permitem importar ou conservar material de palavras-passe?
Não utilize o endereço de e-mail, o número de telefone ou o nome de utilizador como única chave de migração. Esses identificadores podem mudar. Uma associação incorreta de contas é mais grave do que uma reposição, porque pode ligar credenciais e acesso à identidade errada.
Escolha um de quatro percursos para as palavras-passe
Diferentes grupos de utilizadores podem precisar de percursos diferentes. Por exemplo, os colaboradores ativos podem migrar gradualmente através de validação online, enquanto as contas externas inativas recebem uma reposição quando o utilizador regressa.
| Capacidade e limitação da origem | Percurso defensável | Principal benefício | Principal custo ou risco |
|---|---|---|---|
| Estão disponíveis palavras-passe ou uma representação compatível com o destino e podem ser tratadas em segurança | Importação em lote controlada | Os utilizadores podem autenticar-se imediatamente no destino | A exportação, o transporte e o tratamento de material de palavras-passe alargam a fronteira de segurança |
| A origem pode validar online as palavras-passe existentes e permanecer autoritativa durante a transição | Migração gradual com Directory Connector | Os utilizadores ativos passam após um login bem-sucedido sem uma reposição geral | A origem e o connector permanecem no percurso de authentication em produção até ao cut-over |
| Os utilizadores já estão provisionados no FoxIDs e apenas a validação de palavras-passe, a verificação da política ou a notificação de alterações permanecem externas | External Password API | Mantém uma integração mais limitada com o armazenamento de palavras-passe ou a política | Não oferece o mesmo fluxo de criação de utilizadores e sincronização de perfis que o Directory Connector |
| Não existe importação compatível segura nem validação online fiável | Reposição verificada da palavra-passe | Estabelece uma nova palavra-passe no destino com uma fronteira de trust clara | A comunicação com os utilizadores, os canais de recuperação e a capacidade de suporte tornam-se críticos |
A resposta, portanto, não é sempre «manter» nem sempre «repor». Escolha para cada grupo o percurso menos perturbador que continue a ser defensável técnica e operacionalmente.
Migração gradual com Directory Connector
O Directory Connector é o principal padrão do FoxIDs quando um diretório existente ou um repository personalizado tem de permanecer autoritativo durante a transição.
Quando um utilizador inicia sessão com uma palavra-passe, o FoxIDs chama a API do connector. Após uma validação bem-sucedida, o FoxIDs cria ou atualiza o utilizador interno a partir dos identificadores, propriedades e claims devolvidos. A resposta inclui um directoryUserId estável que associa o utilizador no FoxIDs à conta de origem, mesmo que o endereço de e-mail, número de telefone ou nome de utilizador mude posteriormente.
Isto cria um fluxo just-in-time prático:
- O utilizador inicia sessão numa aplicação através do FoxIDs com o identificador e a palavra-passe existentes.
- O FoxIDs pede ao diretório de origem que valide a palavra-passe.
- O connector devolve o identificador de origem estável e os dados de utilizador aprovados.
- O FoxIDs cria ou atualiza o utilizador interno e conclui a authentication.
- O utilizador pode continuar a usar a palavra-passe existente enquanto a origem permanecer autoritativa.
Por predefinição, o FoxIDs também guarda uma cópia local da palavra-passe após uma validação bem-sucedida do connector ou uma operação do ciclo de vida da palavra-passe através do connector. Essa cópia permite uma mudança posterior planeada para a validação de palavras-passe no FoxIDs sem repor a palavra-passe de todos os utilizadores que concluíram o fluxo gradual.
A fronteira é importante: enquanto o Directory Connector estiver ativado, o diretório externo permanece autoritativo. O FoxIDs não utiliza o hash local guardado como fallback automático se o connector estiver indisponível. Uma falha do connector é, por isso, uma falha do percurso de authentication e não uma indicação para contornar a origem.
O seletor de política de palavras-passe apresentado abaixo é uma terceira decisão independente. Controla se o FoxIDs verifica uma palavra-passe proposta em relação à política do ambiente FoxIDs antes de chamar o connector. O diretório externo continua responsável pela palavra-passe e pode rejeitá-la de acordo com a sua própria política. Se forem utilizadas ambas as verificações, os requisitos e as indicações ao utilizador têm de estar alinhados.
Defina critérios de saída antes de ativar o connector
Uma migração gradual precisa de uma condição de conclusão. Decida antes do rollout:
- Que grupos de utilizadores devem ter concluído um login bem-sucedido antes do cut-over?
- Como serão tratadas as contas inativas ou as contas de utilizadores que nunca regressem?
- Durante quanto tempo a origem e o connector devem permanecer disponíveis para rollback?
- Que latências e taxas de erro do connector devem parar ou reverter o rollout?
- Como serão investigados conflitos de identificadores, claims em falta e contas de origem desativadas ou eliminadas?
- Quando pode o connector ser desativado e o FoxIDs tornar-se autoritativo para as palavras-passe?
Guardar uma cópia local é opcional. Desative esta opção quando uma política exigir que a origem permaneça o único armazenamento de palavras-passe, mas reconheça que isso elimina o percurso para uma mudança posterior sem reposição.
Quando o External Password API é a opção mais limitada
O FoxIDs pode configurar um External Password API como verificação de palavras-passe para utilizadores internos. Pode validar uma palavra-passe atual, verificar uma nova palavra-passe em relação a uma política externa, notificar outro sistema sobre alterações de palavra-passe ou combinar estas responsabilidades.
Utilize esta opção quando os utilizadores já existirem no FoxIDs e a necessidade restante disser especificamente respeito ao armazenamento ou à política de palavras-passe. Não a trate como substituto do Directory Connector quando a migração também exigir criação de utilizadores just-in-time, uma associação estável a um diretório externo, atualizações de perfil ou gestão do ciclo de vida das contas externas.
Esta distinção torna explícita a fronteira de integração: o Directory Connector representa um diretório externo autoritativo. O External Password API representa uma dependência externa para validação, política ou notificações de palavras-passe para utilizadores internos.
Quando a importação em lote é justificável
A importação em lote pode eliminar a dependência runtime da origem, mas apenas quando os dados de entrada forem adequados ao destino e puderem ser protegidos durante toda a transferência.
O FoxIDs permite carregar utilizadores internos com palavras-passe conhecidas, com hashes de palavras-passe pré-calculados compatíveis com o FoxIDs ou sem palavras-passe. Um hash de uma plataforma de origem qualquer não pode ser simplesmente designado como hash FoxIDs. Confirme o algoritmo exato, o salt e o formato de destino antes de decidir que um hash exportado pode ser reutilizado.
Trate a exportação de palavras-passe em texto simples como uma decisão de segurança, não como uma conveniência. Limite o acesso, utilize um percurso de transferência controlado, impeça que as palavras-passe entrem em logs ou ficheiros de projeto comuns, verifique a eliminação de material temporário e documente quem aprovou a operação. Se esse tratamento não for defensável, escolha antes a validação online ou a reposição.
Quando a reposição da palavra-passe é mais segura
Uma reposição não demonstra necessariamente que a migração falhou. É o percurso correto quando manter a palavra-passe existente enfraqueceria o destino ou dependeria de pressupostos que a equipa não consegue verificar.
Prefira uma reposição controlada quando:
- a origem não puder exportar uma representação compatível nem validar online a palavra-passe atual;
- mover material de palavras-passe criar uma exposição inaceitável ou um problema contratual;
- a palavra-passe na origem estiver comprometida ou houver suspeita de compromisso;
- as contas não puderem ser correlacionadas com confiança suficiente a identidades de origem estáveis;
- a origem não puder manter-se fiável durante o período necessário de migração gradual e rollback; ou
- manter a palavra-passe antiga exigir controlos mais fracos no destino.
Os utilizadores no FoxIDs podem ser carregados sem palavras-passe e convidados a definir uma através de um código de verificação enviado por e-mail ou SMS. Isto só é seguro quando o identificador de recuperação pertence ao utilizador pretendido e o canal de entrega cumpre os requisitos de risco da organização. Antes de um rollout amplo, teste códigos expirados, caixas de correio ou números de telefone inacessíveis, identificadores duplicados, contas bloqueadas e escalamento para o suporte.
Comunique o motivo e o momento antes de os utilizadores encontrarem a reposição. Separe a decisão de segurança do plano de suporte: um desenho sólido de reposição pode ainda falhar operacionalmente se os canais de recuperação estiverem desatualizados ou o service desk não conseguir suportar a carga inicial.
Exija evidências antes do cut-over das palavras-passe
Teste o percurso escolhido num ambiente FoxIDs separado e transfira primeiro um grupo controlado de utilizadores. Um login bem-sucedido é necessário, mas não suficiente.
| Área de decisão | Evidência necessária antes de um rollout mais amplo |
|---|---|
| Associação de identidade | Identificadores de origem estáveis, alterações de identificadores testadas e tratamento definido de duplicados ou utilizadores em falta |
| Comportamento das palavras-passe | Palavras-passe aceites e rejeitadas, fluxo de palavra-passe expirada, alteração/reposição e erros de política |
| Disponibilidade | Monitorização do connector ou da API de validação, timeouts, tratamento de erros e responsável operacional nomeado |
| Migração de utilizadores | Resultados do piloto para contas representativas ativas, inativas, desativadas e restritas |
| Segurança | Tratamento aprovado de material de palavras-passe, secrets protegidos, logging de diagnóstico sem palavras-passe e retenção de dados revista |
| Cut-over | Critérios de saída por grupo, tratamento de utilizadores sem palavra-passe de destino guardada, condição de rollback e responsável pela retirada da origem |
Mantenha a origem disponível até o grupo de utilizadores necessário ter sido migrado e a janela de rollback estar fechada. Não desative o connector apenas porque o piloto foi bem-sucedido. Verifique o percurso da palavra-passe de destino para o grupo que deve funcionar após o cut-over e mantenha um percurso de reposição controlado para os restantes utilizadores.
Como o FoxIDs apoia a decisão
Utilize a documentação de migração para planear em conjunto aplicações, utilizadores, palavras-passe, cut-over e rollback. A documentação do Directory Connector, External Password API e carregamento de utilizadores contém os detalhes exatos de implementação.
Se as capacidades da origem, os grupos de utilizadores ou os critérios de cut-over ainda não forem claros, FoxIDs Identity Migration descreve como a equipa responsável pela plataforma pode ajudar a conceber e executar a migração.
Conclusão
Os utilizadores só podem manter uma palavra-passe existente quando a migração preserva um percurso de validação fiável ou estabelece em segurança uma palavra-passe de destino compatível. O Directory Connector oferece muitas vezes o percurso gradual menos perturbador, mas também mantém a origem no fluxo de authentication em produção até um cut-over deliberado.
Escolha a reposição quando não for possível demonstrar compatibilidade, associação de identidade ou tratamento seguro. A estratégia de palavras-passe correta torna explícitos a origem autoritativa, o comportamento perante falhas, o impacto nos utilizadores e os critérios de saída antes de transferir o tráfego de produção.