Este artículo explica por qué el servidor autogestionado de ActivityInfo no es compatible con una implementación de dos niveles.
Diseñamos nuestro servidor autogestionado para que sea una plataforma potente, fiable y segura, fácil de instalar y mantener. Para lograrlo, utilizamos una arquitectura de instancia única. Este diseño es el más adecuado para las organizaciones, especialmente para aquellas con recursos informáticos limitados.
Muchos estándares de TI recomiendan una arquitectura de dos niveles, con la aplicación en un servidor y la base de datos (como MySQL o PostgreSQL) en otro. Aunque este modelo funciona para muchas aplicaciones, elegimos un diseño diferente para ActivityInfo. Este artículo explica nuestro diseño y cómo proteger su implementación de servidor único.
Por qué el servidor autogestionado evita una arquitectura de dos niveles
Una arquitectura de dos niveles puede mejorar la seguridad al colocar la base de datos en una máquina (virtual) separada detrás de un cortafuegos. Sin embargo, este modelo haría que ActivityInfo fuera más lento y difícil de mantener. Decidimos no utilizar un servidor de base de datos independiente por dos razones:
Las funciones que consumen muchos datos son lentas con servidores separados
Muchas funciones de ActivityInfo, como el escáner de registros duplicados, consumen muchos datos. Funcionan realizando comparaciones complejas de muchos registros.
En un modelo de dos niveles, la aplicación necesitaría extraer todo el conjunto de datos a través de la red desde el servidor de la base de datos para realizar este análisis. Esta gran transferencia de datos crea latencia en la red, lo que ralentiza la aplicación y consume mucho ancho de banda. El rendimiento de estas funciones sería mucho peor, especialmente para los clientes con grandes bases de datos.
Un único servidor es más fácil de mantener
Un objetivo clave de nuestro servidor autogestionado es la simplicidad para los equipos que no pueden dedicar un empleado a tiempo completo para gestionarlo. Una configuración de dos servidores requiere que usted configure, supervise y mantenga dos servidores, sus sistemas operativos, las reglas de red entre ellos y cuentas de usuario de base de datos separadas. Esta complejidad va en contra de nuestro objetivo de una solución de bajo mantenimiento y aumenta el riesgo de una configuración incorrecta.
Diseño de servidor único
La aplicación autogestionada de ActivityInfo es una única aplicación Java autónoma. Este único proceso incluye tanto el servidor web como un motor de base de datos SQLite integrado.
Una base de datos integrada es una biblioteca que forma parte de la aplicación ActivityInfo. Toda su base de datos se almacena en un único archivo en el mismo servidor.
Este modelo de servidor único ofrece varias ventajas:
- Alto rendimiento: La aplicación se comunica directamente con su archivo de base de datos en el disco local, por lo que el acceso a los datos es rápido. Esto evita los retrasos de la red y permite que las funciones complejas y con gran cantidad de datos, como el escáner de duplicados, se ejecuten de forma eficiente, incluso en grandes conjuntos de datos.
- Simplicidad: Solo necesita instalar, configurar, supervisar y hacer copias de seguridad de un componente. Esto reduce la complejidad y la posibilidad de errores de configuración.
- Fiabilidad: Con menos piezas y sin conexión de red entre la aplicación y sus datos, hay menos puntos de fallo.
Comparación con nuestro servicio alojado
Nuestro servicio alojado en ActivityInfo.org sí utiliza una arquitectura multinivel. Este servicio cuenta con el respaldo de un equipo completo de ingenieros y una supervisión 24/7, por lo que puede permitirse ser más complejo. Utilizamos un amplio almacenamiento en caché de varios niveles para superar el impacto de una arquitectura multinivel en las funciones que consumen muchos datos. Vea nuestro seminario web Presentación de la versión autogestionada de ActivityInfo para una comparación entre los dos productos.
Cómo proteger su servidor autogestionado de ActivityInfo
Una arquitectura de servidor único puede ser tan segura como una implementación de dos niveles si se configura correctamente. Si no cuenta con un equipo a tiempo completo que gestione su servicio de ActivityInfo, es probable que una implementación de servidor único sea más segura, ya que reduce el riesgo de errores de configuración.
A continuación, se indican los pasos que puede seguir para proteger su servidor autogestionado:
- Permita el acceso solo a los puertos 80 (http) y 443 (https). Estos son los únicos puertos que el servidor de ActivityInfo escucha, y las solicitudes http (inseguras) se redirigirán automáticamente a https. SQLite es un sistema de base de datos integrado y no admite conexiones de red.
- Desactive el acceso SSH o RDP al servidor, o restrinja el acceso SSH a un host "bastión" dentro de su propia red.
- Elija un sistema operativo mínimo para el servidor de ActivityInfo, como Alpine Linux, Ubuntu Minimal, o el SO optimizado para contenedores de Google Cloud, para minimizar la superficie de ataque de la máquina (virtual).
- Habilite las actualizaciones desatendidas del sistema operativo.
- Considere la posibilidad de implementar un cortafuegos de aplicaciones web (WAF) delante del servidor de ActivityInfo. Se sabe que el WAF de Cloudflare funciona bien con ActivityInfo.
Los puntos anteriores son pasos importantes a seguir al implementar específicamente la versión autogestionada de ActivityInfo. Sin embargo, los riesgos más importantes para cualquier base de datos de ActivityInfo provienen de los usuarios autenticados:
- Configure el inicio de sesión único (SSO) para reducir el riesgo de la fatiga de contraseñas y para garantizar que los miembros del personal pierdan el acceso a la base de datos cuando dejen su organización.
- Configure roles para sus bases de datos que sigan el principio de privilegio mínimo.