Хранение персональных данных игроков и приватность

MAATRIX GAMES

Рано или поздно у любого админа, который держит публичный сервер дольше пары месяцев, возникает вопрос: а что вообще происходит с данными игроков, которые крутятся у меня в логах, вайтлисте и на веб-панели? Спойлер — данных там больше, чем кажется, и большая часть из них никому не нужна дольше пары недель. Разберём, что реально собирает игровой сервер, как это хранить без риска слить чужие данные и где заканчивается здравый смысл админа и начинается территория юриста.

Какие данные вообще собирает игровой сервер

Если честно посмотреть на типичный игровой сервер — Minecraft, Rust, CS2, ARK, не важно — набор персональных данных у него довольно скромный, но он есть:

• Игровой никнейм и внутриигровой ID — для Minecraft это UUID, для Steam-игр (Rust, CS2, ARK) — SteamID64. Формально это идентификатор, который позволяет связать активность с конкретным человеком, даже если настоящее имя нигде не фигурирует.
• IP-адрес подключения — почти всегда попадает в логи сервера при коннекте. В logs/latest.log у Minecraft, в консольном выводе Rust и CS2, в логах SRCDS — IP светится регулярно, часто вместе с портом и временем подключения (подробнее о том, как вообще читать эти логи — в статье про логи и крэш-репорты).
• Email — если у сообщества есть форум, сайт с личным кабинетом или веб-панель вроде Pterodactyl/Pufferpanel с регистрацией, email обычно требуется при создании аккаунта.
• Discord ID и данные из бота — если сервер завязан на Discord-бота для линковки аккаунтов, бана по Discord ID или логирования модерации, это тоже персональные данные, хоть и менее чувствительные.
• Платёжные данные — если на сервере донат-магазин, сам сервер обычно платёжные реквизиты не хранит (это задача платёжного шлюза), но в логах платформы могут остаться email и сумма транзакции.

Важный момент: IP-адрес во многих юрисдикциях (включая страны под GDPR) официально считается персональными данными, даже если это "просто цифры". Это стоит держать в голове при любом разговоре о логах.

Принцип минимизации: не собирай лишнего

Базовое правило, которое закрывает половину потенциальных проблем: не собирай и не храни больше данных, чем реально нужно для работы сервера. На практике это значит пересмотреть несколько привычных вещей:

• Если регистрация на форуме сообщества не обязательна для игры на сервере — не делай email обязательным полем "на всякий случай". Каждое лишнее поле — это лишняя ответственность.
• Если плагин логирования (например, CoreProtect для Minecraft или различные admin-мод логгеры для Rust) пишет избыточно подробные данные — посмотри в конфиге, можно ли отключить то, что реально не используется в модерации.
• Не дублируй одни и те же данные в нескольких местах без необходимости — если IP уже есть в системных логах, не обязательно ещё раз складывать их в отдельную БД плагина статистики, если этим никто не пользуется.
• Периодически смотри, какие плагины и моды вообще стоят на сервере и что они логируют — часто оказывается, что забытый плагин полтора года пишет подробные логи чатов и подключений, которые никто не читает.

Минимизация — это не про параноидальную зачистку всего, а про честный вопрос "а зачем мне это хранить" применительно к каждому типу данных.

Защита логов с IP-адресами на уровне ОС

Логи с IP-адресами — самая частая точка утечки, потому что про них обычно просто забывают. Сервер крутится на VPS, логи копятся годами в открытом на чтение каталоге, и доступ к ним фактически есть у любого, кто получил доступ к машине (в том числе через уязвимость в другом сервисе на том же хосте).

Практические шаги:

• Отдельный пользователь под игровой сервер. Не гоняй сервер от root и не держи логи в каталоге, доступном всем пользователям системы. Заведи выделенного пользователя (например, mcserver или gameserver) и держи логи в его домашнем каталоге.
• Права доступа к файлам логов. Минимум — убрать доступ на чтение для "остальных":

chmod 750 /home/gameserver/logs
chmod 640 /home/gameserver/logs/*.log
chown -R gameserver:gameserver /home/gameserver/logs

• Права на конфиги с данными игроков. Файлы вроде whitelist.json, ops.json, banned-ips.json (Minecraft) или аналогичные списки в Rust/ARK тоже стоит закрыть от чтения посторонним пользователям той же машины тем же принципом 640.
• Веб-панель управления. Если используешь Pterodactyl, Pufferpanel или похожую панель — проверь, что файловый менеджер панели не даёт скачивать логи всем подряд по прямой ссылке, и что доступ к разделу с логами есть только у админов, а не у любого пользователя с аккаунтом на панели.
• Бэкапы тоже логи. Если бэкапишь сервер целиком (включая папку логов), убедись, что архив бэкапа хранится не в публично доступном облачном каталоге и, желательно, зашифрован — иначе вся защита прав доступа на живом сервере обнуляется одной случайно расшаренной ссылкой на бэкап. Как выстроить само расписание бэкапов — отдельная тема, разобрана в статье про автобэкапы игрового сервера.
• Ограничь сетевой доступ к портам управления. Если на сервере открыт RCON, SSH или порт панели управления, не держи их открытыми всему интернету — базовая настройка портов и файрвола закрывает заодно и часть рисков утечки данных через случайно доступный извне интерфейс.
• Не гоняй логи в открытые каналы Discord. Соблазн подключить лог-канал сервера прямо в Discord для удобства мониторинга велик, но если туда сыпятся IP подключений — подумай дважды, кто состоит в этом канале и не расшарен ли он шире, чем нужно.

Email и данные на форуме или веб-панели сообщества

Если у сообщества есть отдельный сайт, форум или личный кабинет с регистрацией — это отдельная точка ответственности, часто более серьёзная, чем сам игровой сервер:

• Используй хеширование паролей средствами самого движка форума/CMS (это почти всегда включено по умолчанию в актуальных версиях), никогда не храни пароли в открытом виде в собственных таблицах.
• Ограничь, кто из модераторов/админов реально видит email пользователей в админке форума — часто права выставлены слишком широко просто по инерции с момента установки.
• Если используешь связку с Discord через OAuth для входа на сайт — внимательно проверь, какие права (scopes) запрашивает интеграция, и не запрашивай больше, чем нужно для линковки аккаунта.
• Регулярно обновляй движок форума/панели — уязвимости в устаревших версиях CMS остаются одним из самых частых источников утечек данных у небольших игровых сообществ.
• Включи двухфакторную аутентификацию для аккаунтов с доступом к панели управления — это резко снижает шанс, что чужой взломанный пароль администратора превратится в утечку базы email всех игроков.

Это не то, чем занимается напрямую сам игровой процесс, но с точки зрения приватности игроков это часть той же истории — и часто более уязвимая, чем сам сервер.

Политика хранения: сколько держать логи

Логи с личными данными не должны жить вечно просто потому, что "диск не жалко". У большинства логов практическая ценность резко падает уже через пару недель — а риск от их накопления только растёт. Разумный подход — задать себе срок ротации и настроить его технически, а не полагаться на память.

Пример конфига logrotate для логов игрового сервера на Linux (/etc/logrotate.d/gameserver):

/home/gameserver/logs/*.log {
    weekly
    rotate 4
    compress
    missingok
    notifempty
    su gameserver gameserver
}

Это хранит примерно 4 недели логов со сжатием старых файлов и автоматически подчищает то, что старше. Конкретные цифры — ориентир, а не догма: если для разбора читерских инцидентов тебе реально нужно 60 дней истории — держи 60, но осознанно, а не потому что никто не настроил ротацию с момента установки сервера три года назад.

То же самое касается плагинов статистики и античит-логов — многие из них по умолчанию не чистят старые записи в базе вообще. Стоит проверить конфиг плагина (например, у популярных Minecraft-плагинов логирования обычно есть параметр вроде data-retention-days или аналогичный) и выставить разумный срок, а не оставлять "бесконечно".

GDPR и подобное законодательство: когда точно нужен юрист

Важная оговорка сразу и прямо: всё, что написано в этой статье — практические технические советы админа, а не юридическая консультация. Если твой сервер ориентирован на аудиторию из ЕС или другого региона с законодательством вроде GDPR (или локальными аналогами — CCPA в Калифорнии, и так далее), формальные требования к обработке персональных данных выходят далеко за рамки "закрыть права на файл логов". Там есть понятия вроде правового основания обработки данных, права на удаление по запросу пользователя, обязательного уведомления при утечке в определённый срок — и это зона, где самодеятельность может быть дороже, чем консультация специалиста.

Что можно сделать без юриста уже сейчас, вне зависимости от юрисдикции:

• Минимизировать сбор данных (см. выше) — это снижает риски при любом раскладе.
• Иметь понятную политику: где хранятся данные, кто имеет доступ, сколько хранятся.
• Уметь технически удалить данные конкретного игрока по запросу — если человек просит удалить его из вайтлиста, логов и БД плагинов, у тебя должна быть возможность это сделать, а не "email разбросан по десяти таблицам, ищи сам".

А вот формулировать публичную политику конфиденциальности для сайта сообщества, ориентированного на аудиторию под GDPR, или отвечать на официальный запрос регулятора — это уже к юристу, который разбирается в конкретной юрисдикции. Экономить на этом, если сообщество действительно большое и международное, не стоит.

Частые вопросы