Como implementar um log de auditoria de ações admin no servidor de MU Online

Servidores de MU Online com equipe de Game Masters e administradores precisam de uma coisa que muitos negligenciam até que algo dê errado: um log de auditoria confiável de cada ação administrativa executada. Quando um item de altíssimo valor aparece do nada, quando uma conta é banida sem justificativa clara ou quando um GM abusa de comandos de spawn, a única forma de investigar com precisão é ter um registro imutável de quem fez o quê, quando e com quais parâmetros. Este tutorial mostra como estruturar esse sistema, desde a captura dos comandos GM até o armazenamento seguro e a consulta dos registros.

Por que um log de auditoria é indispensável

Sem log de auditoria, qualquer investigação sobre abuso administrativo vira "palavra contra palavra" — o administrador não tem como provar o que aconteceu, e o jogador afetado não tem como contestar uma decisão injusta. Além do aspecto de confiança com a comunidade, o log de auditoria também protege a própria equipe de GMs: um administrador honesto acusado injustamente de abuso pode provar sua inocência mostrando o registro exato das ações executadas. Em servidores com equipe grande, esse sistema também ajuda a identificar padrões de uso excessivo de comandos por um GM específico, antes que isso vire um problema maior.

O que deve ser registrado

Estrutura de tabela de log no banco de dados

Uma abordagem comum é criar uma tabela dedicada, separada das tabelas de jogo, para armazenar os registros de auditoria:

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()
);

Essa estrutura cobre tanto comandos in-game quanto ações do painel web, desde que ambos os sistemas gravem nessa mesma tabela (ou em tabelas espelhadas com formato compatível para consulta unificada).

Capturando comandos GM no GameServer

A maioria dos emuladores processa comandos GM em uma função central que interpreta o texto digitado no chat (algo como HandleGMCommand ou equivalente). O ponto de interceptação ideal é logo após a validação de permissão do comando e antes (ou logo depois) da execução, para garantir que só comandos realmente aceitos e executados sejam logados — evitando poluir o log com tentativas inválidas, que podem ser tratadas em um log separado de "tentativas negadas".

[GMCommand] Recebido: /additem 14 6 13 255 255 0 0
[GMCommand] Autorizado para conta: 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 ações do painel administrativo web

No lado do painel web (geralmente PHP, Node.js ou similar), cada rota administrativa sensível deve chamar uma função central de auditoria antes de confirmar a ação ao usuário. Um exemplo simplificado em 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 na rota de banimento
logAdminAction($_SESSION['admin_user'], 'BAN_ACCOUNT', $targetAccount, $_POST['ban_reason']);

Toda ação irreversível ou sensível (banimento, edição de saldo, exclusão de personagem) deve exigir preenchimento de um motivo antes de ser executada — isso melhora drasticamente a qualidade dos registros para investigação futura.

Permissões e proteção contra adulteração

O usuário de banco de dados usado pelo GameServer e pelo painel web para inserir logs deve ter permissão apenas de INSERT na tabela de auditoria, nunca UPDATE ou DELETE. Isso impede que um GM com acesso a comandos de banco (ou um invasor que comprometa uma conta de GM) apague seu próprio rastro. Idealmente, a exclusão de registros antigos (dentro da política de retenção) deve ser feita por um processo administrativo separado, executado apenas pelo administrador raiz do sistema, com registro da própria limpeza em um log de nível ainda mais alto.

Consultando e analisando os logs

Um painel de consulta simples, com filtros por conta de admin, tipo de ação, conta afetada e intervalo de data, já resolve a maioria das investigações. Para servidores maiores, vale considerar alertas automáticos: por exemplo, notificar a liderança quando um mesmo GM executa um volume incomum de comandos de item em curto espaço de tempo, ou quando uma ação de alto impacto (adicionar Zen em massa) é executada fora do horário normal de atividade daquele administrador.

Política de retenção e arquivamento

Defina um período de retenção ativa (por exemplo, 90 a 180 dias) em que os logs ficam totalmente acessíveis para consulta rápida, e um processo de arquivamento para registros mais antigos, movendo-os para armazenamento compactado em vez de apagá-los. Isso mantém a tabela principal de log performática para consultas do dia a dia, sem perder o histórico completo para investigações que envolvam eventos antigos.

Boas práticas de comunicação com a equipe

Um sistema de auditoria só funciona bem se a equipe de GMs souber que ele existe e entender seu propósito como proteção mútua, não como vigilância hostil. Comunicar isso claramente na integração de novos administradores, e reforçar que o motivo de cada ação sensível deve ser preenchido com honestidade, cria uma cultura de responsabilidade que reduz abusos antes mesmo de qualquer investigação ser necessária.

Erros comuns e soluções

Checklist de implementação do log de auditoria

• Tabela de auditoria criada e separada das tabelas de jogo.
• Comandos GM in-game capturados e gravados no log.
• Ações do painel administrativo web também gravadas no mesmo sistema.
• Conta de banco de dados restrita a INSERT na tabela de log.
• Campo de motivo obrigatório para ações sensíveis.
• Política de retenção e arquivamento definida e documentada.
• Painel de consulta com filtros básicos disponível para a liderança.

Com o log de auditoria implementado, sua equipe administrativa ganha uma camada de accountability que protege tanto os jogadores quanto os próprios GMs, e o próximo passo natural é revisar as demais práticas de segurança e configuração geral do servidor no tutorial de criação de servidor de MU Online.

Perguntas frequentes