Como segregar a rede do banco de dados do seu servidor de MU Online

O banco de dados é o ativo mais crítico de qualquer servidor de MU Online privado: nele vivem as contas, senhas (com hash), personagens, itens, histórico de transações e logs de moderação. Um vazamento ou comprometimento do banco não é apenas um incidente técnico — é o fim da confiança da comunidade no servidor. Segregar a rede do banco de dados significa tratá-lo com um nível de isolamento e controle acima do resto da infraestrutura, mesmo que a rede geral já esteja segmentada. Este tutorial detalha como fazer isso na prática: isolamento de rede, contas de serviço com privilégio mínimo, criptografia em trânsito e backup seguro.

Por que o banco merece isolamento adicional

Mesmo em uma infraestrutura já segmentada (ConnectServer público, GameServer interno, banco interno), o banco costuma ser o único componente onde um comprometimento tem impacto catastrófico e irreversível — itens e Zen podem ser recriados, mas dados de conta vazados (mesmo com hash) e histórico de compras não. Por isso o banco justifica uma camada extra: rede própria, contas de acesso mais restritas que as usadas pelo GameServer para outras finalidades, e auditoria mais rigorosa de quem acessa e quando.

Isolando o banco em sua própria subnet

Mesmo dentro de uma VPC já segmentada, coloque o banco em uma subnet dedicada, sem rota de saída para a internet (egress bloqueado por padrão, exceto para destinos de backup explicitamente liberados):

VPC: 10.0.0.0/16
├── Subnet Pública:    10.0.1.0/24
├── Subnet Aplicação:  10.0.2.0/24  → GameServer
└── Subnet Banco:      10.0.3.0/24  → MSSQL/MySQL (sem rota à internet)

A ausência de rota de saída para a internet significa que, mesmo que o banco seja comprometido, um invasor não consegue facilmente exfiltrar dados diretamente para fora — ele precisaria antes comprometer outro componente com rota de saída, o que adiciona uma etapa extra de dificuldade.

Regras de firewall específicas para o banco

Nenhuma regra deve liberar a porta do banco para 0.0.0.0/0 (qualquer origem) em hipótese alguma — esse é o erro de configuração mais comum e mais grave encontrado em servidores privados comprometidos.

Contas de serviço com privilégio mínimo

Um erro frequente é usar a conta de administrador do banco (sa no MSSQL, root no MySQL) diretamente na configuração do GameServer. Em vez disso, crie contas de serviço dedicadas por finalidade:

-- MSSQL: conta de serviço para o GameServer, com permissões específicas
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;
-- Sem permissão de DROP, ALTER ou controle de servidor

-- Conta separada, somente leitura, para o site/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;

Com essa separação, mesmo que a credencial do site vaze (por exemplo, por uma vulnerabilidade no CMS), o invasor só consegue ler dados, nunca alterar personagens, itens ou saldo de Zen.

Diferenciando conta de aplicação e conta de administração

Nunca reutilize a mesma credencial entre finalidades diferentes — isso elimina a possibilidade de rastrear qual componente fez qual ação em caso de incidente.

Criptografando a conexão em trânsito

Ative TLS na conexão entre GameServer/site e o banco de dados, especialmente se os componentes não estiverem na mesma máquina física. Para MSSQL, isso é configurado no SQL Server Configuration Manager (Force Encryption) e na connection string do GameServer:

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

Para MySQL, use require_secure_transport=ON na configuração do servidor e ssl-mode=REQUIRED na string de conexão do cliente. O custo de performance do TLS é baixo comparado ao risco de credenciais e dados trafegando em texto claro dentro da rede interna.

Backup seguro e isolado

O job de backup deve rodar dentro do mesmo segmento privado do banco, nunca puxado de fora por uma conexão de entrada. O fluxo recomendado:

1. O servidor de banco (ou um servidor de backup interno no mesmo segmento) executa o backup localmente, gerando o arquivo .bak/dump.
2. Uma regra de firewall de saída (egress), não de entrada, permite que esse servidor envie o arquivo para um destino externo (storage em nuvem, outro datacenter).
3. O destino externo tem controle de acesso próprio (criptografia at-rest, versionamento, retenção).

#!/bin/bash
# Executado localmente no segmento do banco
BACKUP_FILE="/backups/mu_$(date +%Y%m%d).bak"
sqlcmd -S localhost -Q "BACKUP DATABASE MuOnline TO DISK='$BACKUP_FILE'"

# Envio para storage externo via egress liberado especificamente para este destino
aws s3 cp "$BACKUP_FILE" s3://mu-backups-privado/ --sse AES256

Nunca abra uma porta de entrada no segmento do banco só para permitir que um script externo "puxe" o backup — isso reintroduz exatamente a exposição que a segregação deveria eliminar.

Auditoria de acesso ao banco

Ative logging de conexões e queries sensíveis (login, DDL, permissões alteradas) no próprio banco:

-- MSSQL: auditoria 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);

Revise esses logs periodicamente (idealmente com alerta automático) para detectar tentativas de login com contas inesperadas ou de IPs fora do padrão.

Separando ambientes (produção, staging, desenvolvimento)

Nunca compartilhe o mesmo banco entre produção e ambientes de teste. Um banco de staging deve rodar em sua própria subnet, com dados sintéticos ou uma cópia anonimizada de produção (sem senhas reais, sem dados de pagamento), evitando que um erro em um script de teste afete jogadores reais.

Erros comuns e soluções

Checklist de segregação da rede do banco de dados

• Banco em subnet própria, sem rota de saída padrão à internet.
• Firewall liberando apenas origens específicas (GameServer, backup, site somente leitura).
• Contas de serviço com privilégio mínimo, separadas por finalidade.
• TLS habilitado na conexão entre aplicação e banco.
• Backup executado localmente no segmento, enviado via egress controlado.
• Auditoria de login e ações sensíveis habilitada no banco.
• Ambientes de produção, staging e desenvolvimento totalmente separados.

Com o banco de dados devidamente isolado, revise também a segmentação dos demais componentes da infraestrutura — veja o tutorial de segmentação da rede do GameServer para garantir que toda a cadeia, do cliente até o dado mais sensível, está protegida de forma consistente.

Perguntas frequentes