Acordar a janela de transferência e os responsáveis
Confirme quem está autorizado a aprovar transferências e revogar acessos. Nomeie o responsável pela conta do cliente, o prestador que sai, o operador substituto e a pessoa que pode ajudar se o acesso falhar. Acorde um prazo limite, as alterações permitidas durante a sobreposição e as evidências necessárias antes da conclusão.
Tenha um inventário atual do projeto, o escopo de trabalho acordado e acesso ao sistema seguro de credenciais do cliente. Estabeleça como funciona a recuperação de contas antes de remover o operador que sai. Se a transferência ocorrer após suspeita de comprometimento, o responsável pela resposta a incidentes deve determinar o momento da contenção; a sequência normal de sobreposição pode ser inadequada.
Inventariar a propriedade separadamente do acesso de login
Liste, para cada serviço, o responsável pela conta, os operadores atuais, as identidades de automação, o responsável pela recuperação e a ação de transferência necessária. Um login de administrador não define quem controla o faturamento ou a recuperação. Registre apenas referências de credenciais ou impressões digitais de chave pública; nunca coloque senhas, tokens, chaves privadas ou códigos de recuperação neste registro.
Role horizontalmente para ver todas as colunas da tabela.
| Ativo do projeto | Questão de propriedade | Evidência de conclusão |
|---|---|---|
| Domínio e DNS | Quem controla o registrador, a renovação e o contato de recuperação? | O responsável confirma o acesso e os registros atuais. |
| Hospedagem e servidor | Quem controla a conta, o console e os usuários privilegiados? | O substituto verifica de forma independente o acesso necessário. |
| Repositório e implantação | Quem é dono do repositório, da automação e das credenciais de implantação? | Versão aprovada implantada em um alvo isolado. |
| Aplicação e integrações | Quem administra o CMS, o e-mail, as APIs e as tarefas agendadas? | Verificações de função e integração registradas. |
| Backups e recuperação | Quem controla o armazenamento de backup e qualquer material de descriptografia necessário? | O substituto conclui um exercício de recuperação isolado. |
Transferir propriedade e conhecimento operacional
Use o mecanismo de transferência ou convite suportado pelo serviço e depois faça o responsável receptor verificar o controle a partir da própria conta. Evite adotar a identidade pessoal do prestador como login compartilhado. Reemita as credenciais do projeto pelo sistema seguro aprovado onde uma conta pessoal as fornecia anteriormente.
Para repositórios no GitHub, uma transferência mantém os secrets associados, as deploy keys e os webhooks, e os colaboradores existentes podem permanecer. Revise esses itens explicitamente após a transferência. O comprovante de transferência estabelece uma mudança de propriedade, não a conclusão da remoção de acessos.
Forneça a referência da versão, as versões de runtime, os locais de configuração, as tarefas agendadas, as dependências externas, o escopo de backup e o procedimento de recuperação. Adicione falhas conhecidas e a próxima tarefa de manutenção. Explique onde as credenciais são obtidas com segurança sem copiar seus valores para a documentação.
Deixar o substituto executar o trabalho
Peça ao substituto que siga o procedimento escrito sem usar a sessão do prestador. Ele deve obter a origem aprovada, implantar em um alvo de teste isolado, localizar logs úteis e demonstrar a tarefa de administração da aplicação permitida. Registre cada etapa ausente, depois atualize as instruções e repita a verificação afetada.
Peça que restaurem um backup acordado para um destino de teste separado, com integrações de saída desativadas ou redirecionadas. Verifique registros representativos, uploads e o comportamento da aplicação. Registre o identificador do backup, o alvo, o tempo decorrido e as lacunas não resolvidas. Não sobrescreva a produção para demonstrar a recuperação e não interprete um job de backup bem-sucedido como um teste de restauração concluído.
Remover o acesso do prestador que sai em todas as rotas
Depois que o acesso substituto e a recuperação forem verificados, remova o contratado das equipes, repositórios, contas de hospedagem e funções de aplicativo relevantes. Revise as sessões ativas e revogue tokens de projeto, integrações e credenciais que ele possa reter. Quando uma credencial for compartilhada, emita sua substituição, atualize os serviços dependentes e teste-os antes de aposentar o valor antigo. Repita a tarefa do substituto após a revogação para detectar dependências ocultas de uma credencial antiga.
As chaves de implantação do GitHub permanecem ativas quando seu criador é removido de um repositório. Inspecione-as separadamente, incluindo permissões de gravação e a máquina que usa cada chave. Para aplicativos OAuth autorizados, o proprietário da conta deve revisar a lista de aplicativos e revogar autorizações obsoletas usando os controles do GitHub.
Para acesso SSH, identifique a configuração real de autorização de chave pública. OpenSSH documenta que AuthorizedKeysFile seleciona os arquivos usados para autenticação de chave pública; não presuma que todo servidor usa um único arquivo padrão. Mantenha um caminho de recuperação verificado e teste a nova conexão do substituto e os privilégios necessários antes de encerrar a sessão de manutenção.
Exemplo: o repositório foi movido, mas a implantação não
Neste cenário fictício, a Cedar Workshop troca o contratado de seu site. O repositório chega à organização do cliente, mas o job de implantação ainda usa uma credencial pertencente ao contratado que está saindo. O substituto pode editar código, mas não consegue publicar a build aprovada. A transferência permanece incompleta.
O proprietário providencia uma credencial de implantação controlada pelo projeto com as permissões necessárias para esse job. O substituto verifica a implantação e a recuperação no alvo de teste. A equipe então aposenta a credencial antiga, revisa as chaves de implantação restantes e reexecuta as verificações permitidas. O registro de encerramento contém links para esses resultados sem conter valores de credenciais.
Encerrar com evidências e propriedade agendada
Registre o proprietário que aceitou a transferência, cada referência de acesso revogada, o horário de conclusão, os resultados dos testes do substituto e as exceções pendentes. Confirme quem agirá na próxima falha de job agendado, renovação de domínio e tarefa de manutenção. Acorde como dados temporários de teste e cópias do projeto em posse do contratado são tratados sob o contrato existente.
A remoção de acesso não pode provar que cópias históricas nunca foram retidas. Um exercício de recuperação prova o cenário testado, não todos os modos de falha. Mantenha esses limites visíveis e transfira o trabalho não resolvido para o registro de responsabilidade operacional com um responsável nomeado e prazo.
Fontes e revisão
As referências técnicas foram verificadas em setembro de 12, 2026. Os exemplos são exercícios de planejamento; a documentação de software referenciada não estabelece capacidades de serviço PrivateHostLab.