Porque não existe migração de gestores de palavras-passe com um clique em 2026

«Posso migrar do [concorrente] com um único clique?» é uma das perguntas mais frequentes que os fornecedores ouvem em reuniões comerciais, sobretudo logo após a violação de dados de um concorrente ser notícia. Os fornecedores apresentam a migração com um clique como uma funcionalidade de conveniência. Em ambientes empresariais, é apenas o ponto de partida.

Uma migração de gestor de palavras-passe que funcione recria a hierarquia de cofres, a propriedade, as permissões, as contas de serviço, as automatizações e as integrações. A qualidade dessa reconstrução determina se os utilizadores, as aplicações e a infraestrutura continuam a funcionar em segurança após a transição.

Verizon, no Data Breach Investigations Report de 2026, concluiu que 39 % dos incidentes de System Intrusion envolveram credenciais roubadas, enquanto 84 % envolveram servidores. À medida que os gestores de palavras-passe passam a fazer parte do plano de controlo da infraestrutura, a precisão da migração afeta diretamente a fiabilidade operacional e a segurança.

Este artigo explica porque é que a migração empresarial é um projeto de engenharia e como executá-la sem interromper o acesso em produção pelo caminho.

A migração começa pelo mapeamento dos modelos de acesso

Nenhuma ferramenta de importação universal consegue recriar com rigor o modelo de acesso de uma organização, porque os modelos de segurança raramente coincidem entre plataformas.

Os diferentes gestores de palavras-passe implementam de forma distinta o controlo de acesso baseado em funções, a herança de permissões, a propriedade de cofres partilhados e a pertença a grupos. Mesmo quando dois sistemas admitem os mesmos conceitos, a implementação assenta frequentemente em pressupostos diferentes.

Veja-se o caso de três organizações:

• A empresa A organiza os cofres por função de negócio
• A empresa B organiza-os por equipas de produto
• A empresa C organiza-os por clientes e projetos

A hierarquia é apenas a parte visível do problema. O verdadeiro desafio consiste em traduzir a semântica de segurança entre sistemas.

A plataforma de origem pode herdar permissões através de grupos aninhados. O destino pode, em vez disso, exigir atribuições explícitas. A propriedade de cofres partilhados pode não ter equivalente direto. Uma função administrativa pode agregar privilégios que, após a migração, têm de ser distribuídos por várias funções. Os modelos RBAC quase nunca têm correspondência um para um.

Os tipos de cofre do próprio Passwork mostram porquê. Um cofre da empresa partilhado e um cofre de utilizador partilhado assentam em pressupostos diferentes sobre quem pode ver o quê. O importador tem de tomar essa decisão e não a inferir a partir do nome de uma pasta.

O mesmo princípio aplica-se ao tratamento da estrutura. Durante a importação, um administrador pode:

• Reconstruir a hierarquia de origem numa pasta existente
• Aplanar tudo num único destino
• Recriar a árvore completa de cofres na raiz

Cada opção é uma escolha deliberada sobre a forma como a organização pretende operar daqui em diante, e essa escolha depende da maneira como a organização realmente funciona.

Um importador genérico copia valores de campos. Decidir que permissões preservar, converter, fundir ou descartar exige um discernimento que um script não tem.

Os atacantes visam cada vez mais o acesso administrativo legítimo, precisamente o que está a ser migrado: contas de confiança e os caminhos que permitem as operações privilegiadas. Uma migração correta garante que esses caminhos continuam a comportar-se como previsto após a transição.

Alguns objetos podem ser copiados, outros têm de ser redesenhados

A migração de um gestor de palavras-passe empresarial remodela o modelo de acesso da organização em quatro camadas distintas: contexto de identidade, políticas de acesso, integrações operacionais e fronteiras de confiança. Cada camada introduz restrições técnicas que um ficheiro de importação plano não consegue representar.

A diferença entre copiado e redesenhado é bem visível nas ferramentas de migração reais. O importador oficial de Bitwarden do Passwork, por exemplo, move automaticamente itens de início de sessão, notas seguras, coleções, estrutura de pastas, URLs e códigos TOTP. Ignora deliberadamente os anexos e qualquer tipo de item que não reconheça, registando cada omissão em vez de tentar adivinhar um mapeamento. Trata-se de uma decisão de conceção, e não de uma limitação: alguns objetos podem ser copiados com segurança, e outros exigem que uma pessoa decida o que lhes acontece.

As contas de serviço sem proprietários claros, as permissões herdadas, as integrações obsoletas e os cofres partilhados esquecidos há muito tempo pertencem à segunda categoria. Uma migração bem-sucedida preserva apenas o que ainda reflete o modelo de acesso pretendido pela organização.

Qualquer um destes elementos, se tratado incorretamente, cria uma lacuna: uma integração órfã, um prestador de serviços que mantém acesso à produção ou uma conta de automatização que se autentica no destino errado. Nenhuma destas situações surge como erro de importação. Normalmente manifestam-se semanas depois sob a forma de incidentes.

O modelo mental certo para a migração e como o Passwork o aplica

Quando a migração é tratada como uma transformação arquitetural, a implementação segue naturalmente os mesmos princípios de engenharia aplicados noutros projetos de infraestrutura: tornar cada passo explícito, revisável e reproduzível.

Em vez de depender de um importador de caixa negra para interpretar a estrutura de uma organização, o processo de migração deve expor cada transformação sob a forma de código. Os engenheiros devem poder inspecionar os dados exportados, definir como são convertidos e controlar exatamente como cada objeto é recriado no sistema de destino.

O Passwork disponibiliza três caminhos de migração, escolhidos em função da origem e do volume, e não da conveniência:

Os dois primeiros cobrem a maioria das migrações reais. O terceiro torna visível o princípio da «transformação como código». Um script de migração construído sobre o conector Python do Passwork autentica-se, cria explicitamente o cofre de destino e a estrutura de pastas e grava cada item com exatamente os campos que a organização pretende preservar:

from passwork_client import PassworkClient

passwork = PassworkClient("https://passwork.example.com")
passwork.set_tokens(access_token, refresh_token)
passwork.set_master_key(master_key)

vault_type = passwork.find_vault_type(code="company")
vault_id = passwork.create_vault("Migrated – IT", vault_type["id"])
vault = passwork.get_vault(vault_id)

folder = passwork.call("POST", "/api/v1/folders", {
    "name": "Databases",
    "vaultId": vault["id"],
})

passwork.create_item({
    "name": "Postgres primary",
    "login": "app_rw",
    "password": "...",
    "urls": ["https://db.internal"],
    "description": "Imported from Bitwarden",
    "vaultId": vault["id"],
    "folderId": folder["id"],
    "customs": [
        {"name": "TOTP", "value": "otpauth://...", "type": "totp"},
    ],
})

Nada chega a um cofre, a uma pasta ou a um conjunto de permissões sem que o script o determine. Numa migração completa de Passwork para Passwork, a mesma lógica escala para os endpoints REST em massa vaults/import, folders/import e items/import, que devolvem um mapa sourceId → id para que os objetos-pai sejam criados antes dos objetos-filho e todas as relações se mantenham intactas.

A fase de transformação é onde a migração se torna previsível. Os engenheiros podem codificar explicitamente as regras de migração: renomear cofres, reatribuir proprietários, dividir funções administrativas, aplanar permissões herdadas ou excluir por completo registos obsoletos. Estas decisões passam a ser código revisável, e não pressupostos escondidos num assistente de importação genérico. Se for necessário repetir ou auditar a migração mais tarde, a lógica de transformação mantém-se transparente e reproduzível.

Isto altera também a forma como a própria migração é protegida. As importações tradicionais com um clique geram, normalmente, uma exportação intermédia em texto em claro, muitas vezes um CSV, que é depois processada por um analisador genérico com conhecimento limitado do ambiente de destino. Cada fase introduz as suas próprias considerações de segurança.

Se algo correr mal a meio de um lote, a recuperação é manual: eliminar ou enviar para a reciclagem o cofre afetado e voltar a executar o script no ambiente de teste (staging). É precisamente por isso que uma execução de teste (dry run) justifica a hora extra antes de uma transição para produção.

Validar o comportamento, e não apenas os registos importados

A importação e a migração são dois pontos de controlo distintos. A importação confirma que as credenciais existem no cofre de destino. A migração confirma que o ambiente se comporta exatamente como previsto quando as cargas de trabalho de produção passam a depender dele.

Uma fase de validação prática deve responder a perguntas como:

• Todos os utilizadores autorizados conseguem aceder aos cofres que se espera que utilizem?
• Os utilizadores não autorizados veem o acesso corretamente negado?
• Os pipelines de CI/CD, a automatização da infraestrutura e as integrações de API obtêm segredos sem modificações?
• As contas de serviço funcionam com as permissões esperadas?
• Os registos de auditoria captam corretamente os eventos de autenticação, as alterações de permissões e as ações administrativas?

Estas verificações revelam muitas vezes problemas que só surgem depois de a importação terminar. Uma credencial migrada pode estar na pasta correta e, ainda assim, continuar inacessível à automatização que dela depende. Um erro na conversão de funções pode conceder silenciosamente um acesso mais amplo do que o pretendido e passar sem problemas na validação da importação.

O registo de atividade do Passwork (eventos como item_imported e vault_imported) fornece aos auditores um rasto documental para precisamente este tipo de verificação, e o Security Dashboard (painel de segurança) assinala as palavras-passe fracas ou duplicadas que vieram do cofre antigo, para que possam ser substituídas em vez de transitarem para o novo ambiente. Vale também a pena rever os registos sem URL: o preenchimento automático não funcionará neles até que alguém corrija o campo.

O êxito de uma migração mede-se pelo comportamento operacional. O sistema de destino deve aplicar o mesmo modelo de segurança que anteriormente, ou um modelo deliberadamente melhorado, e não limitar-se a conter os mesmos segredos.

Transformar a migração do gestor de palavras-passe numa auditoria de segurança

A migração é muitas vezes o único momento em que uma organização revê em simultâneo todas as credenciais armazenadas e todas as permissões.

A administração quotidiana tende a ser incremental: adicionam-se utilizadores, os projetos evoluem, as integrações acumulam-se e os direitos de acesso expandem-se gradualmente. Uma migração interrompe esse processo e obriga cada objeto a justificar o seu lugar no novo ambiente. Por isso, uma migração estruturada funciona frequentemente como a revisão de acessos mais abrangente que uma organização realizou em anos.

Durante esta revisão, as equipas descobrem tipicamente:

• Segredos órfãos pertencentes a colaboradores que saíram há meses
• Credenciais duplicadas do mesmo serviço armazenadas em vários cofres
• Utilizadores inativos que mantêm acesso à produção
• Chaves de API que expiraram mas nunca foram removidas
• Credenciais pessoais armazenadas em cofres da empresa
• Credenciais de sistemas desativados há muito tempo mas nunca eliminadas

Uma importação em massa transporta silenciosamente estes problemas para a nova plataforma. Uma migração baseada em transformação expõe-nos, porque cada credencial, cada proprietário e cada permissão têm de ser avaliados antes de serem recriados.

Verizon, no DBIR de 2026, refere que 27 % das vítimas de ransomware tinham indícios de um infostealer ou de uma fuga de credenciais durante o ano anterior e que, entre essas organizações, metade ficou exposta nos 95 dias anteriores ao incidente de ransomware. A migração é uma das poucas oportunidades para revogar credenciais expostas ou obsoletas antes de passarem a fazer parte de uma cadeia de ataque.

O mesmo relatório refere também que a resolução de palavras-passe fracas e de configurações incorretas de permissões em ambientes cloud de terceiros demora, em média, quase oito meses às organizações. Efetuar essa revisão durante a migração comprime esses oito meses numa atividade de engenharia planeada, em vez de um esforço de correção prolongado.

Ao abrigo do artigo 32.º do RGPD, as organizações têm de aplicar medidas técnicas e organizativas adequadas aos riscos do tratamento de dados pessoais. A remoção de acessos obsoletos e de credenciais órfãs durante a migração demonstra esses controlos na prática, em vez de apenas os documentar.

Sete passos para reduzir o risco da migração antes da produção

O fluxo de migração do Passwork trata a migração como um projeto de engenharia com pontos de controlo explícitos, e não como uma única operação de importação.

1. Inventário

Documente os cofres, as contas de serviço, as integrações, as automatizações e as dependências externas existentes antes de escrever qualquer código de migração.

2. Exportação

Extraia os dados do sistema de origem num formato estruturado. O JSON é, em geral, preferível porque preserva as relações hierárquicas: a exportação JSON do próprio Passwork mantém intactas a estrutura de cofres e pastas, enquanto o CSV reduz tudo a uma tabela.

3. Revisão

Identifique as credenciais obsoletas, duplicadas, órfãs ou com privilégios excessivos antes de serem migradas.

4. Transformação

Implemente regras de migração que mapeiem o ambiente de origem para a hierarquia de destino, o modelo de propriedade, a configuração RBAC e as convenções de nomenclatura.

5. Importação de teste

Execute a migração num ambiente de teste (staging) para verificar se os objetos são criados corretamente antes de tocar na produção. A orientação do próprio Passwork para o script do Bitwarden é explícita neste ponto: fazer uma cópia de segurança da base de dados de destino e executar um teste (dry run) no staging antes de uma transição real.

6. Validação de permissões

Confirme que:

• os utilizadores autorizados têm acesso;
• os utilizadores não autorizados não têm;
• as contas de serviço se autenticam com êxito;
• os pipelines de CI/CD e as integrações continuam a funcionar;
• os registos de auditoria captam os eventos de segurança esperados.

7. Migração para produção

Execute a migração para produção por fases e não de uma só vez: primeiro as credenciais partilhadas de TI e infraestrutura, depois os cofres dos departamentos, uma equipa de cada vez, e por fim os cofres privados, quando os utilizadores estiverem ativados. Mantenha os sistemas antigo e novo em paralelo durante duas a quatro semanas, faça verificações pontuais com o responsável de cada departamento e só desative a plataforma de origem quando a adoção for real, e não presumida.

Saltar qualquer uma das fases de teste ou de validação de permissões não elimina, normalmente, o trabalho. Apenas o adia para o momento em que os utilizadores de produção ou os sistemas automatizados começam a falhar após a transição.

Acertar na migração

As migrações mais fáceis movem palavras-passe. As migrações bem-sucedidas recriam a forma como uma organização funciona: quem é o proprietário de cada credencial, como as permissões são herdadas, que sistemas dependem de segredos partilhados e que caminhos de acesso já não devem existir.

As importações com um clique otimizam a velocidade. As migrações empresariais otimizam a correção, a auditabilidade e um comportamento previsível após a transição. Estes objetivos raramente apontam na mesma direção.

Se há uma ação que vale a pena executar antes de agendar uma migração, é o primeiro passo do fluxo acima: elaborar um inventário rigoroso dos cofres, das contas de serviço, das integrações e do modelo de permissões antes de escrever uma única linha de lógica de migração.

Os melhores scripts de migração documentam cada decisão de migração ao longo do processo. Muito depois da transição, estas regras de transformação passam a ser um registo do motivo pelo qual o acesso foi mapeado de determinada forma, o que facilita significativamente futuras auditorias, a resolução de problemas e novas migrações.

As equipas que migram de outro gestor de palavras-passe obtêm um desconto de 10 % no Passwork. Consultar a documentação para saber como mudar para o Passwork a partir dos gestores de palavras-passe mais populares.

Perguntas frequentes sobre a migração de gestores de palavras-passe

Soberania de dados e gestão de palavras-passe: Manter as credenciais onde pertencem

A soberania de dados das credenciais exige três controlos (localização, cifragem e acesso), e não apenas conformidade com o RGPD. Compara modelos on-premise, com isolamento físico (air gap) e de cloud na UE, mostrando onde uma arquitetura zero-knowledge como a do Passwork realmente fecha a lacuna de soberania.

PassworkPasswork Team

Políticas de cofre do Passwork: guia do CIO para a segurança empresarial

Os tipos de cofre (Vault Types) do Passwork associam os direitos de administração à própria política do cofre, e não a quem o criou, eliminando uma lacuna que a maioria das empresas nem sabe que existe. Este guia oferece a CIOs e CISOs um modelo prático de governação de cofres, alinhado com os requisitos da NIS2 e da ISO 27001.

PassworkPasswork Team

Passwork 7.7: modo offline seguro para aplicações desktop e móveis

As palavras-passe passam também a funcionar offline. O Passwork 7.7 traz acesso offline seguro com supervisão administrativa completa, controlos de anexos de ficheiros ao nível da organização e cinco novos guias de integração por função, para uma implementação mais simples.

PassworkPasswork Team