Separe la titularidad del acceso diario
Decida quién posee cada cuenta de hosting, dominio, DNS y terceros, quién paga sus facturas y quién controla la recuperación. Esos roles pueden pertenecer a personas diferentes. El mantenedor que sube una versión no debería convertirse en la única persona capaz de recuperar el proyecto del cliente.
Enumere el identificador de la cuenta, el responsable de negocio, el responsable de contacto de recuperación y los administradores autorizados. Registre dónde se guarda el material de recuperación sin incluir el material en sí en esta hoja. Confirme que la continuidad del negocio no depende del correo electrónico personal ni del dispositivo de un contratista que se marcha.
Complete una matriz de responsabilidades en conjunto
El ejemplo siguiente es una propuesta para debatir, no una declaración de las obligaciones contractuales de PrivateHostLab. El cliente posee las decisiones de negocio, la agencia asume el trabajo técnico que acepta, y las obligaciones del proveedor provienen del acuerdo de servicio real. Reemplace los roles por personas nombradas o un contacto documentado del proveedor.
Para cada fila, añada un límite de aprobación y el método de contacto acordado. Un suplente debe aceptar el rol y tener el acceso necesario. Un suplente en blanco o una ruta de escalado del proveedor desconocida es una acción abierta, no una cobertura asumida.
Desplace horizontalmente para ver todas las columnas de la tabla.
| Responsabilidad | Principal propuesto | Suplente a nombrar | Escalar cuando |
|---|---|---|---|
| Presupuesto de hosting y renovación | Responsable del presupuesto del cliente | Suplente autorizado por el cliente | Una decisión de pago o renovación no está asignada |
| Control de dominio y DNS | Propietario cliente; la agencia cambia solo por acuerdo | Operador de dominio autorizado | El acceso falla o los registros dirigen a los usuarios incorrectamente |
| Mantenimiento del sistema operativo y de las aplicaciones | Mantenedor de la agencia dentro del alcance acordado | Reemplazo de agencia calificada | Falla una actualización o un componente no compatible requiere una decisión |
| Verificaciones de copia de seguridad y recuperación | Agencia designada u operador de datos del cliente | Operador de recuperación capacitado | Falta una copia o falla una verificación de restauración |
| Problemas de infraestructura | Proveedor dentro de su límite de servicio verificado | Ruta indicada en el acuerdo real | La evidencia apunta fuera del control de la aplicación |
| Actualizaciones de incidentes al cliente | Contacto del proyecto acordado | Reemplazo aprobado por el cliente | Se interrumpe un flujo de trabajo crítico o corresponde la siguiente actualización |
Dé a los operadores el acceso que su tarea requiere
Use identidades individuales cuando el sistema correspondiente las admita. Mantenga distintos los permisos de publicación, despliegue, facturación y recuperación de cuentas cuando sea práctico. OWASP recomienda conceder los privilegios mínimos necesarios y revisar los permisos para detectar accesos acumulados. Traduzca ese principio en una tarea con nombre y una fecha de revisión para cada cuenta del proyecto. Hoja de referencia de autorización de OWASP.
Acuerde quién puede añadir o eliminar claves SSH y quién verifica el resultado. Antes de cambiar la configuración de SSH, conserve una sesión en funcionamiento conocida y una ruta de recuperación confirmada; valide la configuración antes de aplicarla y luego compruebe una nueva conexión autorizada antes de cerrar la sesión anterior. Ubuntu aconseja explícitamente verificar la configuración antes de reiniciar OpenSSH para evitar perder el acceso. Documentación del servidor Ubuntu OpenSSH.
El documento de traspaso debe contener huellas de claves o referencias de registros de acceso, nunca claves privadas, contraseñas ni frases de recuperación de carteras.
Defina el escalado según el impacto en el negocio
Separe una solicitud de contenido rutinaria, un cambio de mantenimiento planificado y un incidente que afecta a un flujo de trabajo crítico del cliente. Escriba el horario de cobertura, la zona horaria, el primer contacto, el reemplazo y el siguiente punto de control de comunicación. No convierta un canal de mensajería conveniente en una garantía implícita de tiempo de respuesta.
Las alertas deben conducir a una acción que alguien pueda tomar. La guía de monitoreo de Google distingue los síntomas visibles de las posibles causas y pregunta si una página es urgente y accionable. Para este proyecto, «no se pueden enviar consultas» es una descripción de incidente más clara que «el servidor parece inusual». Guía de monitoreo de Google SRE.
Una nota de escalamiento útil registra el flujo de trabajo afectado, la hora de la primera observación, el último éxito conocido, el cambio reciente y las acciones ya realizadas. Elimine los datos personales y los secretos de los registros de respaldo.
Asigne la decisión de recuperación y también la tarea de copia de seguridad
Acuerden en qué momento deben recuperarse los datos y cuánto puede tardar la recuperación antes de que el negocio se vea materialmente afectado. Son preguntas de planificación distintas, reflejadas por los objetivos de punto de recuperación y y de tiempo de recuperación de NIST.
Nombren a la persona que mantiene las copias, a la persona que las prueba y a quien aprueba una restauración en producción. Realicen un ensayo en un destino separado. Registren el punto de datos restaurado, las verificaciones funcionales, el tiempo transcurrido y las lagunas; un ensayo exitoso es evidencia para ese ejercicio, no una garantía sobre cada incidente futuro.
Entregue un registro de proyecto utilizable
Imaginen a un cliente que cambia a su mantenedor habitual después de una campaña. La agencia saliente entrega la versión actual, el inventario de dependencias, los pasos de despliegue, el procedimiento de recuperación de base de datos y cargas, los detalles del programador, el mapa DNS y el registro de cuentas de terceros. El cliente confirma qué cuentas y trabajos en curso pasan al reemplazo.
El operador receptor debe realizar un ejercicio controlado con los documentos: localizar la versión aprobada, restaurar datos de muestra de forma aislada, encontrar el siguiente trabajo programado e identificar al responsable de renovaciones. Registren lo que no pudo completarse y resuélvanlo antes de depender de ese operador para un incidente.
- Confirmen el acceso autorizado del reemplazo antes de retirar el acceso de la persona saliente.
- Roten las credenciales que fueron compartidas, o revoquen identidades individuales cuando ese sea el control adecuado.
- Eliminen claves obsoletas, tokens de despliegue y concesiones de acceso en todo el inventario del proyecto.
- Confirmen el destino de las copias restantes y del trabajo abierto según los términos de traspaso acordados.
Acepte la hoja y luego manténgala
Marquen cada verificación de traspaso como aceptada, bloqueada o pendiente de seguimiento, con el revisor y la ubicación de la evidencia. Un contacto de recuperación sin resolver debe permanecer visible en lugar de desaparecer en un mensaje general de «traspaso completado».
Revisen la hoja siempre que cambien el cliente, la agencia, el alcance del proveedor o la aplicación. Enlácenla con el presupuesto de alojamiento aprobado y registro de migración. Esta hoja de trabajo prepara un acuerdo operativo; no sustituye los términos reales del vendedor ni crea compromisos de soporte del proveedor. Compárenla con el alcance del servicio publicado y resuelvan explícitamente los detalles faltantes.
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.