El ransomware ataca un viernes por la noche. El equipo pregunta al anfitrión: ¿quién ha iniciado sesión en nuestro VPS en las últimas 48 horas? Respuesta: tickets de soporte con capacidad de búsqueda, sin correlación SSH, retención del panel durante 7 días. La investigación interna está bloqueada. El DPO está a la espera de un cronograma para la notificación a la CNIL.
El acceso de administrador es el punto débil menos documentado del hosting. La producción cifrada, el firewall activado y, sin embargo, una clave raíz compartida, un acceso a los medios imposible de rastrear o registros borrables son suficientes para invalidar meses de cumplimiento mostrado.
Dos perímetros que nunca deben confundirse
Acceso al host (soporte, NOC, hipervisor). No los controlas directamente. Podrá solicitar en la DPA: registro, notificación en caso de acceso sin ticket, tiempo de transmisión del registro, prohibición de acceso sin justificación.
Acceso de cliente (SSH, panel de aplicaciones, CI/CD, base de datos de administración). Usted es responsable de esto. Cuentas con nombre, MFA, sin raíz compartida, rotación de claves API. Los registros deben dejar el servidor en un almacenamiento que el administrador comprometido no pueda borrar.
| Fuente | Ejemplos | Propietario | Prueba esperada |
|---|---|---|---|
| Anfitrión | Consola en la nube, modo de rescate, hipervisor | Proveedor de servicios | Exportación en 72 horas bajo petición |
| Cliente | SSH, sudo, implementación | Tú | Cuchara SIEM o WORM |
| Solicitud | Administrador de WordPress, back office | Tú + editor | Registros de aplicaciones + IP |
Un registro de auditoría creíble vincula la identidad, la acción, la marca de tiempo y el ticket de problema, no solo el "inicio de sesión exitoso".
Construya una línea de tiempo que se ajuste frente al oyente
Comience enumerando los escenarios a reconstruir: sospecha de compromiso, error humano, acceso al soporte durante una interrupción, migración nocturna.
Para cada escenario, verifique:
- Marca de tiempo sincronizada (NTP) en máquinas virtuales y servicios de registro.
- Identidad única: no
admin@nideploycompartida entre diez personas. - Inmutabilidad: registros copiados fuera del servidor comprometido (Bloqueo de objetos S3, syslog remoto).
- Correlación: alerta si el acceso del administrador está fuera del rango habitual o sin ticket asociado.
Solicite al anfitrión un registro de medios de muestra (anónimo) que muestre el formato y la retención. Si la respuesta es “confidencial”, negocie una cláusula de auditoría o un informe de un tercero.
Errores que hacen que las auditorías fallen
Confunda los registros web y los registros de administración. Apache access.log no muestra quién se ha convertido en root.
Retención demasiado breve con el anfitrión. Descubres la intrusión después de 30 días; Los registros del panel solo llegan hasta 14.
Modo de rescate sin notificación. El host monta un disco de rescate para "ayudarlo", sin seguimiento contractual ni alerta al cliente.
Cuenta permanente de emergencia. La cuenta de emergencia permanece activa durante todo el año en lugar de ser activada, utilizada, desactivada y registrada.
Cada punto se corrige mediante una línea de contrato y una prueba anual: simular una solicitud de registros sobre un incidente ficticio.
La cumbre: sin registros administrativos, sin diligencia debida
Esto es lo que los SLA de disponibilidad no mencionan.
La cumbre: exigir capacidad de reconstrucción, no una promesa de “seguridad reforzada”. En una crisis, los minutos cuentan y los registros eliminados no regresan.
Decide y avanza sin puntos ciegos
Haga un inventario de todas las rutas de administración: panel de alojamiento, SSH, API en la nube, acceso a la base de datos, CI. Para cada uno: quién, dónde registra, cuánto de retención.
Agregar al DPA: tiempo de entrega de los registros del host, formato, contacto de escalada. Del lado del cliente, envíe registros a un almacenamiento inmutable esta semana, no después del incidente.
Compare los hosts sobre la transparencia del soporte a través de nuestro directorio y el comparador. Enlace con Mínimo privilegio para reducir la superficie antes de iniciar sesión.
Preguntas frecuentes
¿Debería el host registrar su propio acceso de administrador?
Sí, para un proyecto sensible: el acceso al hipervisor, el panel, el soporte escalado y las intervenciones de emergencia deben rastrearse, marcarse la hora y comunicarse bajo contrato.
¿Qué eventos mínimos hay en el lado del cliente?
Conexiones SSH/RDP, escalada de privilegios, modificaciones de IAM, acceso a bases de datos de administración, implementaciones y acceso a secretos, con identidad nominativa.
¿Cuánto tiempo se deben conservar los registros de administración?
Dependiendo del riesgo; a menudo un mínimo de 6 a 12 meses para la investigación interna. Alinee el host y el cliente en duraciones compatibles.
¿Son suficientes los registros del panel compartido?
Rara vez para un VPS o una nube. No siempre cubren SSH, claves API o acceso al hipervisor L3.
En cumplimiento, la pregunta no es "¿tiene un administrador?" » — es "¿puedes probar lo que hizo?" »