Cómo segregar la red de la base de datos de tu servidor de MU Online

La base de datos es el activo más crítico de cualquier servidor de MU Online privado: en ella viven las cuentas, contraseñas (con hash), personajes, ítems, historial de transacciones y logs de moderación. Una filtración o compromiso de la base de datos no es solo un incidente técnico —es el fin de la confianza de la comunidad en el servidor. Segregar la red de la base de datos significa tratarla con un nivel de aislamiento y control por encima del resto de la infraestructura, incluso si la red general ya está segmentada. Este tutorial detalla cómo hacerlo en la práctica: aislamiento de red, cuentas de servicio con privilegio mínimo, cifrado en tránsito y backup seguro.

Por qué la base de datos merece aislamiento adicional

Incluso en una infraestructura ya segmentada (ConnectServer público, GameServer interno, base de datos interna), la base de datos suele ser el único componente donde un compromiso tiene un impacto catastrófico e irreversible —los ítems y el Zen pueden recrearse, pero los datos de cuenta filtrados (aunque con hash) y el historial de compras, no. Por eso la base de datos justifica una capa extra: red propia, cuentas de acceso más restringidas que las usadas por el GameServer para otros fines, y auditoría más rigurosa de quién accede y cuándo.

Aislando la base de datos en su propia subred

Incluso dentro de una VPC ya segmentada, coloca la base de datos en una subred dedicada, sin ruta de salida a internet (egress bloqueado por defecto, excepto hacia destinos de backup explícitamente liberados):

VPC: 10.0.0.0/16
├── Subred Pública:      10.0.1.0/24
├── Subred Aplicación:   10.0.2.0/24  → GameServer
└── Subred Base de Datos: 10.0.3.0/24  → MSSQL/MySQL (sin ruta a internet)

La ausencia de ruta de salida a internet significa que, aunque la base de datos sea comprometida, un atacante no puede exfiltrar datos fácilmente hacia afuera —primero necesitaría comprometer otro componente con ruta de salida, lo que agrega un paso extra de dificultad.

Reglas de firewall específicas para la base de datos

Ninguna regla debe liberar el puerto de la base de datos a 0.0.0.0/0 (cualquier origen) bajo ninguna circunstancia —ese es el error de configuración más común y más grave encontrado en servidores privados comprometidos.

Cuentas de servicio con privilegio mínimo

Un error frecuente es usar la cuenta de administrador de la base de datos (sa en MSSQL, root en MySQL) directamente en la configuración del GameServer. En su lugar, crea cuentas de servicio dedicadas por finalidad:

-- MSSQL: cuenta de servicio para el GameServer, con permisos específicos
CREATE LOGIN gameserver_svc WITH PASSWORD = 'SenhaForteAleatoria!2026';
CREATE USER gameserver_svc FOR LOGIN gameserver_svc;
ALTER ROLE db_datareader ADD MEMBER gameserver_svc;
ALTER ROLE db_datawriter ADD MEMBER gameserver_svc;
-- Sin permiso de DROP, ALTER ni control del servidor

-- Cuenta separada, solo lectura, para el sitio/ranking
CREATE LOGIN site_readonly WITH PASSWORD = 'OutraSenhaForte!2026';
CREATE USER site_readonly FOR LOGIN site_readonly;
ALTER ROLE db_datareader ADD MEMBER site_readonly;

Con esta separación, aunque la credencial del sitio se filtre (por ejemplo, por una vulnerabilidad en el CMS), el atacante solo podrá leer datos, nunca alterar personajes, ítems o saldo de Zen.

Diferenciando cuenta de aplicación y cuenta de administración

Nunca reutilices la misma credencial entre finalidades diferentes —esto elimina la posibilidad de rastrear qué componente realizó qué acción en caso de incidente.

Cifrando la conexión en tránsito

Activa TLS en la conexión entre el GameServer/sitio y la base de datos, especialmente si los componentes no están en la misma máquina física. Para MSSQL, esto se configura en el SQL Server Configuration Manager (Force Encryption) y en la cadena de conexión del GameServer:

[Database]
Server=10.0.3.10
Database=MuOnline
User=gameserver_svc
Password=SenhaForteAleatoria!2026
Encrypt=yes
TrustServerCertificate=no

Para MySQL, usa require_secure_transport=ON en la configuración del servidor y ssl-mode=REQUIRED en la cadena de conexión del cliente. El costo de rendimiento de TLS es bajo comparado con el riesgo de que credenciales y datos viajen en texto claro dentro de la red interna.

Backup seguro y aislado

El job de backup debe correr dentro del mismo segmento privado de la base de datos, nunca ser extraído desde afuera por una conexión de entrada. El flujo recomendado:

1. El servidor de base de datos (o un servidor de backup interno en el mismo segmento) ejecuta el backup localmente, generando el archivo .bak/dump.
2. Una regla de firewall de salida (egress), no de entrada, permite que ese servidor envíe el archivo a un destino externo (storage en la nube, otro centro de datos).
3. El destino externo tiene control de acceso propio (cifrado en reposo, versionado, retención).

#!/bin/bash
# Ejecutado localmente en el segmento de la base de datos
BACKUP_FILE="/backups/mu_$(date +%Y%m%d).bak"
sqlcmd -S localhost -Q "BACKUP DATABASE MuOnline TO DISK='$BACKUP_FILE'"

# Envío a storage externo vía egress liberado específicamente para este destino
aws s3 cp "$BACKUP_FILE" s3://mu-backups-privado/ --sse AES256

Nunca abras un puerto de entrada en el segmento de la base de datos solo para permitir que un script externo "extraiga" el backup —eso reintroduce exactamente la exposición que la segregación debería eliminar.

Auditoría de acceso a la base de datos

Activa el registro de conexiones y consultas sensibles (login, DDL, permisos alterados) en la propia base de datos:

-- MSSQL: auditoría de login
CREATE SERVER AUDIT MuServerAudit
TO FILE (FILEPATH = 'C:\AuditLogs\')
WITH (ON_FAILURE = CONTINUE);

CREATE SERVER AUDIT SPECIFICATION MuLoginAudit
FOR SERVER AUDIT MuServerAudit
ADD (FAILED_LOGIN_GROUP), ADD (SUCCESSFUL_LOGIN_GROUP)
WITH (STATE = ON);

Revisa estos logs periódicamente (idealmente con alerta automática) para detectar intentos de login con cuentas inesperadas o desde IPs fuera de lo habitual.

Separando ambientes (producción, staging, desarrollo)

Nunca compartas la misma base de datos entre producción y ambientes de prueba. Una base de staging debe correr en su propia subred, con datos sintéticos o una copia anonimizada de producción (sin contraseñas reales, sin datos de pago), evitando que un error en un script de prueba afecte a jugadores reales.

Errores comunes y soluciones

Lista de verificación de segregación de la red de base de datos

• Base de datos en subred propia, sin ruta de salida por defecto a internet.
• Firewall liberando solo orígenes específicos (GameServer, backup, sitio solo lectura).
• Cuentas de servicio con privilegio mínimo, separadas por finalidad.
• TLS habilitado en la conexión entre la aplicación y la base de datos.
• Backup ejecutado localmente en el segmento, enviado vía egress controlado.
• Auditoría de login y acciones sensibles habilitada en la base de datos.
• Ambientes de producción, staging y desarrollo totalmente separados.

Con la base de datos debidamente aislada, revisa también la segmentación de los demás componentes de la infraestructura —consulta el tutorial de segmentación de la red del GameServer para garantizar que toda la cadena, desde el cliente hasta el dato más sensible, esté protegida de forma consistente.

Preguntas frecuentes