Cómo mantenemos seguros los servidores de ArduMaker, día a día

Publicado el 2026-09-12 por frfrand

La parte operativa, no la de diseño: qué se actualiza, qué se vigila, cómo se aíslan las cosas y qué pasa cuando algo se cae a las tres de la mañana.

Ya contamos cómo está diseñada la plataforma: puertos cerrados por defecto, SSH con vencimiento, aislamiento por Empresa. Eso define lo que es posible.

Pero la seguridad real no la define el diseño, la define la rutina. Un servidor bien diseñado y sin mantener termina siendo inseguro igual, sólo que más lento.

Esta es la parte operativa.

Actualizaciones que no dependen de nadie

Cada VPS tiene actualizaciones de seguridad automáticas activadas desde el momento en que se crea.

Suena obvio y es, estadísticamente, la medida que más ataques evita. La enorme mayoría de las intrusiones en servidores usan vulnerabilidades conocidas, con parche publicado hace meses. No hay nada sofisticado: hay un servidor que nadie actualizó.

Lo dejamos activado por defecto justamente porque es una tarea que nunca es urgente. Si depende de que alguien la agende, no se hace.

Vigilancia continua, con historial

Hay un sistema de estado que revisa hosts, VPS, dominios y servicios en ciclo continuo, y guarda 45 días de histórico.

El historial es la parte que más se subestima. Saber que algo está caído ahora es útil; poder responder "¿esto viene pasando hace cuánto?" es lo que permite encontrar la causa. Muchos problemas no son caídas: son degradaciones lentas que sólo se ven comparando contra semanas anteriores.

Y antes de escalar a una persona, el sistema intenta reparar solo las fallas conocidas. Un servicio que se cayó y que se resuelve reiniciándolo no necesita despertar a nadie a las tres de la mañana.

Copias en otro lado, y verificadas

Cada VPS tiene copia completa periódica, tomada en caliente, guardada en un host distinto del que corre el VPS.

Las dos partes importan y suelen fallar juntas:

• Un backup en el mismo disco que los datos no es un backup. Protege contra un borrado accidental y contra nada más.
• Un backup que no verificaste puede estar corrupto y no lo sabés hasta el peor momento. Por eso se guardan con su hash: se puede comprobar la integridad antes de necesitarlo.

Y cada copia viene con instrucciones de restauración. Es el detalle que separa un archivo guardado de un plan de recuperación.

Aislamiento que no depende de configurar bien

Cada VPS es una máquina separada, y cada Empresa está separada de las demás. No hay servidores compartidos entre clientes ni permisos cruzados que puedan quedar mal puestos.

Es más caro de operar que un servidor compartido bien configurado. La diferencia es que "bien configurado" hay que sostenerlo todos los días, y la separación estructural se sostiene sola.

Todo queda escrito

Cada comando ejecutado sobre un VPS desde la plataforma queda registrado con quién lo lanzó y cuándo. Cada apertura de acceso, también.

El valor no aparece en auditorías: aparece el martes, cuando algo dejó de andar y la pregunta es "¿qué cambió acá?". Con registro es una consulta. Sin registro es una reconstrucción de memoria entre varias personas.

Lo que esto no resuelve

Vale decirlo, porque prometer más de lo que se cumple es su propia forma de inseguridad.

Nada de esto protege tu aplicación de sus propios errores. Si tu código tiene una inyección SQL, si tus claves están en el repositorio, o si alguien de tu equipo usa la misma contraseña en todos lados, la plataforma no puede hacer mucho.

Lo que sí podemos garantizar es que la capa de abajo no sea el punto débil, y que los errores más comunes de infraestructura no dependan de que alguien se acuerde.