Acordar la ventana de traspaso y los responsables
Confirmar quién está autorizado a aprobar transferencias y revocar acceso. Nombrar al propietario de la cuenta del cliente, al contratista saliente, al operador de reemplazo y a la persona que puede ayudar si se rompe el acceso. Acordar un corte, los cambios permitidos durante el solapamiento y la evidencia requerida antes de completar.
Disponer de un inventario actual del proyecto, el alcance de trabajo acordado y acceso al sistema seguro de credenciales del cliente. Establecer cómo funciona la recuperación de cuentas antes de eliminar al operador saliente. Si el traspaso sigue a una sospecha de compromiso, el responsable de respuesta a incidentes debe determinar el momento de la contención; la secuencia normal de solapamiento puede no ser apropiada.
Inventariar la propiedad por separado del acceso de inicio de sesión
Enumerar el propietario de la cuenta de cada servicio, los operadores actuales, las identidades de automatización, el responsable de recuperación y la acción de transferencia requerida. Un inicio de sesión de administrador no determina quién controla la facturación o la recuperación. Registrar solo referencias de credenciales o huellas de claves públicas; nunca poner contraseñas, tokens, claves privadas o códigos de recuperación en este registro.
Desplace horizontalmente para ver todas las columnas de la tabla.
| Activo del proyecto | Pregunta de propiedad | Evidencia de finalización |
|---|---|---|
| Dominio y DNS | ¿Quién controla el registrador, la renovación y el contacto de recuperación? | El propietario confirma el acceso y los registros actuales. |
| Alojamiento y servidor | ¿Quién controla la cuenta, la consola y los usuarios privilegiados? | El reemplazo verifica de forma independiente el acceso necesario. |
| Repositorio y despliegue | ¿Quién posee el repositorio, la automatización y las credenciales de despliegue? | Versión aprobada desplegada en un destino aislado. |
| Aplicación e integraciones | ¿Quién administra el CMS, el correo, las API y las tareas programadas? | Comprobaciones de roles e integraciones registradas. |
| Copias de seguridad y recuperación | ¿Quién controla el almacenamiento de copias de seguridad y cualquier material de descifrado necesario? | El reemplazo completa un ejercicio de recuperación aislado. |
Transferir la propiedad y el conocimiento operativo
Usar el mecanismo de transferencia o invitación admitido por el servicio, y luego hacer que el propietario receptor verifique el control desde su propia cuenta. Evitar adoptar la identidad personal del contratista como inicio de sesión compartido. Reemitir las credenciales del proyecto a través del sistema seguro aprobado cuando una cuenta personal las haya proporcionado anteriormente.
En los repositorios de GitHub, una transferencia conserva los secretos asociados, las claves de despliegue y los webhooks, y los colaboradores existentes pueden permanecer. Revisar esto explícitamente después de la transferencia. El recibo de transferencia establece un cambio de propiedad, no la finalización de la eliminación de accesos.
Proporcionar la referencia de la versión, las versiones de tiempo de ejecución, las ubicaciones de configuración, las tareas programadas, las dependencias externas, el alcance de las copias de seguridad y el procedimiento de recuperación. Añadir los fallos conocidos y la próxima tarea de mantenimiento. Explicar dónde se obtienen las credenciales de forma segura sin copiar sus valores en la documentación.
Dejar que el reemplazo realice el trabajo
Pedir al reemplazo que siga el procedimiento escrito sin tomar prestada la sesión del contratista. Debe obtener la fuente aprobada, desplegar en un destino de prueba aislado, localizar registros útiles y demostrar la tarea de administración de la aplicación permitida. Registrar cada paso faltante y luego actualizar las instrucciones y repetir la comprobación afectada.
Hacer que restauren una copia de seguridad acordada en un destino de prueba separado con las integraciones salientes deshabilitadas o redirigidas. Comprobar registros, cargas y comportamiento representativos de la aplicación. Registrar el identificador de la copia de seguridad, el destino, el tiempo transcurrido y las brechas no resueltas. No sobrescribir producción para demostrar la recuperación, y no interpretar una tarea de copia de seguridad exitosa como una prueba de restauración completada.
Eliminar el acceso del que se va en todas las rutas
Una vez verificados el acceso sustituto y la recuperación, elimine al contratista de los equipos, repositorios, cuentas de alojamiento y roles de aplicación correspondientes. Revise las sesiones activas y revoque los tokens de proyecto, integraciones y credenciales que pueda retener. Cuando una credencial sea compartida, emita su reemplazo, actualice los servicios dependientes y pruébelos antes de retirar el valor antiguo. Repita la tarea del sustituto tras la revocación para detectar dependencias ocultas de una credencial antigua.
Las claves de despliegue de GitHub siguen activas cuando su creador se elimina de un repositorio. Inspecciónelas por separado, incluidos los permisos de escritura y la máquina que usa cada clave. Para las aplicaciones OAuth autorizadas, el propietario de la cuenta debe revisar la lista de aplicaciones y revocar las autorizaciones obsoletas usando los controles de GitHub.
Para el acceso SSH, identifique la configuración real de autorización de clave pública. La documentación de OpenSSH indica que AuthorizedKeysFile selecciona los archivos usados para la autenticación de clave pública; no asuma que todos los servidores usan un único archivo predeterminado. Mantenga una ruta de recuperación verificada y pruebe la conexión nueva del sustituto y los privilegios requeridos antes de cerrar la sesión de mantenimiento.
Ejemplo: el repositorio se movió, pero el despliegue no
En este escenario ficticio, Cedar Workshop cambia el contratista de su sitio web. El repositorio llega a la organización de la clienta, pero el trabajo de despliegue sigue usando una credencial propiedad del contratista saliente. El sustituto puede editar el código, pero no publicar la compilación aprobada. El traspaso queda incompleto.
La propietaria organiza una credencial de despliegue controlada por el proyecto con los permisos necesarios para ese trabajo. El sustituto verifica el despliegue y la recuperación en el destino de prueba. Después, el equipo retira la credencial antigua, revisa las claves de despliegue restantes y vuelve a ejecutar las comprobaciones permitidas. El registro de cierre enlaza estos resultados sin contener valores de credenciales.
Cerrar con evidencia y propiedad programada
Registre quién aceptó el traspaso, cada referencia de acceso revocado, la hora de finalización, los resultados de las pruebas del sustituto y las excepciones pendientes. Confirme quién actuará ante el siguiente fallo de trabajo programado, la renovación de dominio y la tarea de mantenimiento. Acuerde cómo se gestionan los datos de prueba temporales y las copias del proyecto en poder del contratista según el acuerdo existente.
La eliminación de accesos no puede demostrar que nunca se conservaron copias históricas. Un ejercicio de recuperación prueba el escenario probado, no todos los modos de fallo. Mantenga visibles esos límites y traslade el trabajo sin resolver al registro de responsabilidad operativa con un responsable designado y una fecha límite.
Fuentes y revisión
Las referencias técnicas se verificaron en septiembre de 12, 2026. Los ejemplos son ejercicios de planificación; la documentación de software referenciada no establece capacidades de servicio de PrivateHostLab.