Cómo implementar un log de auditoría de acciones admin en el servidor de MU Online

Los servidores de MU Online con equipo de Game Masters y administradores necesitan algo que muchos descuidan hasta que algo sale mal: un log de auditoría confiable de cada acción administrativa ejecutada. Cuando aparece de la nada un ítem de altísimo valor, cuando se banea una cuenta sin justificación clara o cuando un GM abusa de comandos de spawn, la única forma de investigar con precisión es tener un registro inmutable de quién hizo qué, cuándo y con qué parámetros. Este tutorial muestra cómo estructurar ese sistema, desde la captura de los comandos GM hasta el almacenamiento seguro y la consulta de los registros.

Por qué un log de auditoría es indispensable

Sin un log de auditoría, cualquier investigación sobre abuso administrativo se convierte en "palabra contra palabra" — el administrador no tiene forma de probar lo que pasó, y el jugador afectado no tiene forma de refutar una decisión injusta. Además del aspecto de confianza con la comunidad, el log de auditoría también protege al propio equipo de GMs: un administrador honesto acusado injustamente de abuso puede probar su inocencia mostrando el registro exacto de las acciones ejecutadas. En servidores con un equipo grande, este sistema también ayuda a identificar patrones de uso excesivo de comandos por parte de un GM específico, antes de que se convierta en un problema mayor.

Qué debe registrarse

Estructura de tabla de log en la base de datos

Un enfoque común es crear una tabla dedicada, separada de las tablas del juego, para almacenar los registros de auditoría:

CREATE TABLE admin_audit_log (
    id BIGINT IDENTITY(1,1) PRIMARY KEY,
    admin_account VARCHAR(50) NOT NULL,
    admin_ip VARCHAR(45) NULL,
    action_type VARCHAR(50) NOT NULL,
    target_account VARCHAR(50) NULL,
    target_character VARCHAR(50) NULL,
    command_raw VARCHAR(500) NULL,
    previous_value VARCHAR(500) NULL,
    new_value VARCHAR(500) NULL,
    reason VARCHAR(500) NULL,
    created_at DATETIME NOT NULL DEFAULT GETDATE()
);

Esta estructura cubre tanto comandos in-game como acciones del panel web, siempre que ambos sistemas escriban en esta misma tabla (o en tablas espejadas con formato compatible para consulta unificada).

Capturando comandos GM en el GameServer

La mayoría de los emuladores procesa los comandos GM en una función central que interpreta el texto escrito en el chat (algo como HandleGMCommand o equivalente). El punto de interceptación ideal es justo después de la validación de permiso del comando y antes (o justo después) de la ejecución, para garantizar que solo se registren comandos realmente aceptados y ejecutados — evitando saturar el log con intentos inválidos, que pueden manejarse en un log separado de "intentos denegados".

[GMCommand] Recibido: /additem 14 6 13 255 255 0 0
[GMCommand] Autorizado para cuenta: GMADMIN01
[Audit] INSERT admin_audit_log (action_type='ADD_ITEM', admin_account='GMADMIN01', command_raw='/additem 14 6 13 255 255 0 0', target_character='PlayerX', created_at=NOW())

Capturando acciones del panel administrativo web

En el lado del panel web (generalmente PHP, Node.js o similar), cada ruta administrativa sensible debe llamar a una función central de auditoría antes de confirmar la acción al usuario. Un ejemplo simplificado en PHP:

function logAdminAction($adminAccount, $actionType, $targetAccount, $reason = null) {
    $stmt = $pdo->prepare(
        "INSERT INTO admin_audit_log (admin_account, admin_ip, action_type, target_account, reason, created_at)
         VALUES (?, ?, ?, ?, ?, NOW())"
    );
    $stmt->execute([$adminAccount, $_SERVER['REMOTE_ADDR'], $actionType, $targetAccount, $reason]);
}

// Uso en la ruta de baneo
logAdminAction($_SESSION['admin_user'], 'BAN_ACCOUNT', $targetAccount, $_POST['ban_reason']);

Toda acción irreversible o sensible (baneo, edición de saldo, eliminación de personaje) debe exigir el llenado de un motivo antes de ejecutarse — eso mejora drásticamente la calidad de los registros para investigaciones futuras.

Permisos y protección contra manipulación

El usuario de base de datos utilizado por el GameServer y por el panel web para insertar logs debe tener permiso solo de INSERT en la tabla de auditoría, nunca UPDATE ni DELETE. Esto impide que un GM con acceso a comandos de base de datos (o un atacante que comprometa una cuenta de GM) borre su propio rastro. Idealmente, la eliminación de registros antiguos (dentro de la política de retención) debe hacerla un proceso administrativo separado, ejecutado solo por el administrador raíz del sistema, con registro de la propia limpieza en un log de nivel aún más alto.

Consultando y analizando los logs

Un panel de consulta simple, con filtros por cuenta de admin, tipo de acción, cuenta afectada e intervalo de fecha, ya resuelve la mayoría de las investigaciones. Para servidores más grandes, vale la pena considerar alertas automáticas: por ejemplo, notificar al liderazgo cuando un mismo GM ejecuta un volumen inusual de comandos de ítem en poco tiempo, o cuando se ejecuta una acción de alto impacto (agregar Zen en masa) fuera del horario normal de actividad de ese administrador.

Política de retención y archivado

Define un período de retención activa (por ejemplo, 90 a 180 días) en el que los logs quedan totalmente accesibles para consulta rápida, y un proceso de archivado para los registros más antiguos, moviéndolos a almacenamiento comprimido en vez de borrarlos. Esto mantiene la tabla principal de log con buen rendimiento para las consultas del día a día, sin perder el historial completo para investigaciones que involucren eventos antiguos.

Buenas prácticas de comunicación con el equipo

Un sistema de auditoría solo funciona bien si el equipo de GMs sabe que existe y entiende su propósito como protección mutua, no como vigilancia hostil. Comunicar esto claramente en la incorporación de nuevos administradores, y reforzar que el motivo de cada acción sensible debe llenarse con honestidad, crea una cultura de responsabilidad que reduce los abusos incluso antes de que sea necesaria cualquier investigación.

Errores comunes y soluciones

Lista de verificación de implementación del log de auditoría

• Tabla de auditoría creada y separada de las tablas del juego.
• Comandos GM in-game capturados y registrados en el log.
• Acciones del panel administrativo web también registradas en el mismo sistema.
• Cuenta de base de datos restringida a INSERT en la tabla de log.
• Campo de motivo obligatorio para acciones sensibles.
• Política de retención y archivado definida y documentada.
• Panel de consulta con filtros básicos disponible para el liderazgo.

Con el log de auditoría implementado, tu equipo administrativo gana una capa de rendición de cuentas que protege tanto a los jugadores como a los propios GMs, y el siguiente paso natural es revisar las demás prácticas de seguridad y configuración general del servidor en el tutorial de creación de servidor de MU Online.

Preguntas frecuentes