Si tu empresa usa un ERP, CRM o cualquier aplicación crítica instalada en un servidor local — on-premise — hay tres preguntas que deberías poder responder hoy mismo:
¿Está ese servidor en una red DMZ separada del resto de tu empresa?
¿Tienes un respaldo que alguien ha probado restaurar?
¿Hay un plan documentado de qué hacer si ese servidor no arranca mañana lunes?
Si la respuesta a cualquiera de las tres es "no sé" o "no", este artículo es para ti.
¿Por qué el servidor de tu ERP no debería estar en la misma red que los computadores de los empleados?
Cuando un servidor crítico — ERP, CRM, sistema de facturación, base de datos SAP — comparte la misma red plana que los computadores de los empleados, estás creando un escenario de riesgo innecesario y evitable.
Imagina que un empleado abre un archivo adjunto malicioso en su correo. El malware se instala en su computador y comienza a explorar la red en busca de recursos a los que puede acceder. Si el servidor del ERP está en la misma red sin segmentación, ese malware puede alcanzarlo directamente — copiar datos, cifrarlos con ransomware o simplemente dañar los archivos de base de datos.
La arquitectura correcta para proteger servidores críticos on-premise utiliza una red DMZ (Zona Desmilitarizada) — una red segmentada separada de la LAN corporativa, controlada por el firewall, que define exactamente quién puede acceder al servidor y desde dónde.
¿Qué es una red DMZ y cómo protege tu ERP?
Una DMZ es una zona de red intermedia, separada físicamente o lógicamente de la red de usuarios y de internet. El firewall controla todo el tráfico que entra y sale de esa zona con reglas específicas:
- Solo los equipos autorizados de la red corporativa pueden conectarse al servidor ERP, y solo por los puertos necesarios
- El servidor ERP no puede iniciar conexiones hacia la red de usuarios — solo responder solicitudes autorizadas
- Nadie desde internet puede alcanzar el servidor directamente, ni siquiera por error
- Si un equipo de la red de usuarios se infecta, el malware no puede saltar al servidor crítico
Esta arquitectura aplica el principio de mínimo privilegio: cada componente accede solo a lo que necesita, nada más. En términos prácticos, significa que un incidente en la red de usuarios no se convierte automáticamente en un incidente en el servidor crítico.
Los errores más comunes en instalaciones on-premise en Chile
Servidor en la misma red plana que los usuarios
Es la configuración más frecuente en PYMEs chilenas. El servidor del ERP está conectado al mismo switch que los computadores, sin ninguna segmentación. Todo el mundo ve al servidor en la red y el servidor puede ver a todo el mundo. Para un atacante que ya está dentro de la red, llegar al servidor es trivial.
Acceso remoto directo al servidor sin VPN
Para permitir trabajo remoto o acceso del proveedor del ERP, se abre un puerto directo desde internet hacia el servidor — RDP, TeamViewer permanente, o puertos de la aplicación expuestos directamente. Esto convierte al servidor en un objetivo visible desde cualquier lugar del mundo, escaneable y atacable.
La forma correcta es VPN obligatoria: el acceso remoto al servidor solo es posible después de autenticarse en la VPN corporativa con doble factor. El servidor nunca es directamente accesible desde internet.
Puerto de base de datos expuesto en la red
El puerto de SQL Server (1433), MySQL (3306) u Oracle (1521) no debería ser accesible desde los computadores de los usuarios — solo desde la aplicación que los usa. Si cualquier equipo de la red puede conectarse directamente a la base de datos, el riesgo de extracción de datos o manipulación directa es alto.
Credenciales de administrador compartidas
El usuario "sa" de SQL Server con contraseña "123456" o la cuenta de administrador del servidor con la misma contraseña de hace 5 años son vulnerabilidades críticas en instalaciones on-premise. Las credenciales de acceso al servidor y la base de datos deben ser únicas, complejas y rotarse periódicamente.
El respaldo: la parte que todos tienen pero nadie ha probado
Aquí está la verdad incómoda: la mayoría de las empresas chilenas con ERP on-premise tienen algún tipo de respaldo configurado. Pero una fracción muy pequeña de esas empresas ha probado restaurar ese respaldo alguna vez.
Un backup no probado no existe.
¿Por qué? Porque el día que necesitas restaurar el backup — después de una falla de disco, un ransomware o un error humano — es el peor momento para descubrir que el archivo de respaldo está corrupto, que el proceso de restauración tarda 6 horas en vez de 30 minutos, o que el backup solo guardaba los archivos de la aplicación pero no la base de datos.
Qué debe incluir el respaldo de un ERP on-premise
- Base de datos completa: No solo los archivos de la aplicación. El backup de la base de datos (SQL Server, MySQL, Oracle) debe ser independiente y verificado.
- Archivos de configuración: Configuración del servidor, parámetros de la aplicación, certificados digitales, integraciones con otros sistemas.
- Imagen del sistema operativo: Un snapshot o imagen del servidor completo permite restaurar todo el entorno, no solo los datos.
- Copia offsite: Al menos una copia en una ubicación diferente al servidor — nube, disco externo en otra ubicación física. Si hay un incendio o robo, el backup local desaparece junto con el servidor.
Con qué frecuencia respaldar
Depende de cuántos datos puede perder tu empresa sin consecuencias graves (RPO). Como referencia:
- ERP con transacciones diarias: backup diario como mínimo, idealmente cada 4-8 horas
- CRM con actividad constante: backup diario con log shipping de base de datos
- Sistema de facturación: backup antes y después de cada proceso de facturación masivo
La prueba de restauración: obligatoria, no opcional
Al menos una vez por trimestre, alguien debe tomar el backup más reciente y restaurarlo en un entorno de prueba — no en producción — verificando que:
- El archivo de backup no está corrupto
- La restauración completa toma el tiempo documentado
- La aplicación arranca correctamente después de la restauración
- Los datos son coherentes y corresponden al momento del backup
Este proceso debe documentarse con fecha, hora, responsable y resultado. Sin documentación, no existe.
Continuidad operativa: ¿qué pasa si el servidor no arranca el lunes?
Esta es la pregunta que nadie quiere responder hasta que ocurre. Un servidor on-premise puede fallar por muchas razones: disco duro defectuoso, falla de fuente de poder, error en una actualización del sistema operativo, corrupción de base de datos, ransomware o simplemente fin de vida útil del hardware.
Si no hay un plan documentado, lo que ocurre es caos: nadie sabe exactamente qué hacer, se llama a personas que no están disponibles, se intenta restaurar sin procedimiento claro, y el tiempo de inactividad se multiplica.
Qué debe incluir el plan de continuidad para un ERP on-premise
- RTO definido: ¿Cuánto tiempo máximo puede estar caído el sistema? ¿2 horas? ¿4 horas? ¿Un día? Ese número determina el nivel de inversión en recuperación.
- Procedimiento paso a paso: Qué hacer exactamente cuando el servidor no arranca. Con qué herramientas, en qué orden, quién lo hace.
- Servidor de contingencia: Para sistemas críticos con RTO bajo, se necesita un servidor de respaldo listo para activar — físico o en la nube como Azure Site Recovery.
- Operación manual de emergencia: ¿Puede la empresa operar aunque sea parcialmente sin el sistema? ¿Qué procesos pueden hacerse en papel o planilla mientras se recupera?
- Contactos de escalada: Proveedor del ERP, proveedor de hardware, equipo TI — con números de contacto fuera de horario.
Lista de verificación: ¿tu ERP on-premise está protegido?
- ☐ El servidor está en una red DMZ separada de los usuarios por firewall
- ☐ El acceso remoto al servidor requiere VPN con doble factor
- ☐ Los puertos de base de datos no son accesibles desde la red de usuarios
- ☐ Las credenciales de administrador son únicas y complejas
- ☐ El backup incluye base de datos + archivos + configuración
- ☐ Existe copia offsite del backup (nube o ubicación física diferente)
- ☐ El backup se ha probado restaurar en los últimos 3 meses
- ☐ El tiempo real de restauración está documentado
- ☐ Existe un plan documentado de qué hacer si el servidor falla
- ☐ El RTO está definido y el plan permite cumplirlo
Si marcaste menos de 7, tu servidor crítico tiene brechas de seguridad o de continuidad que vale la pena resolver hoy — no después del primer incidente.
¿Cuánto cuesta implementar esta arquitectura correctamente?
Para una empresa con un servidor ERP o CRM on-premise de tamaño mediano en Chile:
- Segmentación DMZ y configuración de firewall: $200.000 – $400.000 CLP
- Implementación de backup automatizado con copia offsite: $150.000 – $300.000 CLP + costo mensual de almacenamiento cloud
- Diseño y documentación del plan BCP/DRP: $200.000 – $500.000 CLP
- Prueba de restauración y ajustes: incluido en el plan
El costo total de implementar todo correctamente está entre $550.000 y $1.200.000 CLP — una inversión que se justifica completamente con evitar un solo incidente grave.
En Union-TI revisamos instalaciones on-premise de ERP y CRM en empresas chilenas, identificamos las brechas de seguridad y continuidad, y las corregimos. Solicita una revisión gratuita — en 48 horas sabes exactamente en qué estado está tu servidor crítico.