Права доступа и роли администраторов на сервере

MAATRIX GAMES

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

Почему нельзя раздавать root и RCON всей команде

RCON-доступ и панель хостинга — это ключи от всего сервера: файлы, бэкапы, консоль, возможность стереть мир одной командой. Модератору, который банит гриферов в чате, это не нужно вообще. Проблема не в том, что вы никому не доверяете — проблема в площади поражения. Один скомпрометированный аккаунт (слитый пароль, заражённый комп, обычная человеческая ошибка) не должен превращаться в инцидент уровня «весь сервер офлайн и бэкапы стёрты».

Практическое правило: доступ должен соответствовать задаче, а не статусу человека в команде. Если модератору для работы хватает команды /ban и /mute — у него не должно быть возможности зайти в SSH или перезапустить процесс сервера через панель. Это не про недоверие, это про то, что вы физически не сможете проверять каждого нового человека так же тщательно, как проверяли себя.

Отдельно стоит развести доступ к RCON и доступ к панели хостинга (в том числе к панели MAATRIX GAMES, если сервер у нас) — это два разных периметра. RCON даёт власть над игровым процессом (команды, кик, бан, иногда — рестарт), панель хостинга — власть над самой машиной: файлами, бэкапами, портами, переустановкой. Держите их отдельно даже для старших админов, если это не строго необходимо по роли.

Три уровня доступа: общий принцип для любой игры

Вне зависимости от того, что у вас — Minecraft, Rust, CS2 или ARK, — рабочая модель обычно строится на трёх уровнях.

Владелец (owner). Полный доступ: панель хостинга, FTP/SFTP, RCON, настройки биллинга, ключи API (если есть интеграции с Discord-ботами и т.п.). Обычно это один-два человека — вы сами и, может быть, доверенный со-владелец проекта. Больше двух владельцев — уже управленческий риск: слишком много точек, откуда можно снести конфиг или случайно перезаписать world-файл.

Старший админ (senior admin / co-admin). Игровые права высокого уровня: бан, кик, телепорты, выдача предметов/ресурсов для разбора ситуаций, доступ к консоли игры через RCON или встроенную admin-консоль, но без доступа к панели хостинга и без прав менять сами конфиги сервера (server.cfg, server.properties и т.д.) без согласования. Именно этот уровень чаще всего закрывает 90% реальной админской работы — жалобы, читеры, споры между игроками.

Модератор. Права ограничены чатом и базовой модерацией: мьют, варн, кик за нарушение правил чата, иногда — временный бан на короткий срок (скажем, до 24 часов, а постоянный бан — уже через старшего админа). Модератору не нужен RCON вообще — почти все игры с активным чатом позволяют выдать эти права через встроенную систему группы игроков или через плагин прав, о котором ниже.

Для крупных проектов иногда добавляют промежуточный уровень — например, «билдер» на строительных серверах Minecraft/Rust с правом на WorldEdit-команды, но без прав банить игроков. Смысл тот же: право = конкретная задача, не более.

Как это настраивается технически: permissions-плагины

Ручками раздавать команды через op (в ванильном Minecraft) или прописывать всех в один файл — рабочий вариант только для совсем маленького сервера на 2-3 админов. Как только людей больше — нужна система групп с гибкой настройкой прав. Мы уже разбирали конкретные плагины для этого в отдельной статье про Bukkit- и Spigot-плагины — здесь остановимся на организационной стороне, но напомним логику на примерах.

Minecraft (Paper/Spigot/Fabric). Стандарт индустрии — LuckPerms. Создаёте группы owner, admin, moderator, builder, каждой назначаете набор permission-нод (essentials.ban, worldedit.*, luckperms.admin и т.д.), а игроков просто добавляете в группу командой /lp user Nickname parent add moderator. Наследование групп (moderator наследует от default, admin наследует от moderator) экономит кучу времени — не нужно прописывать одни и те же права по кругу.

Rust (Oxide/uMod). Права выдаются через встроенную систему групп oxide.group: oxide.group add moderator, дальше oxide.grant group moderator kits.use и аналогично для каждого плагина. У Rust есть нюанс — если у вас стоит экономика через плагины (Economics, ServerRewards), убедитесь, что модераторы не получили случайно права начислять себе валюту вместе с правами кика — это частая дыра, когда права копируют «по образцу» с более высокой роли и забывают вычистить лишнее.

CS2 (SourceMod/Metamod). Права прописываются в addons/sourcemod/configs/admins_simple.ini (или через SQL-админку, если используете MySQL-бэкенд SourceMod) — там задаются admin-флаги (b — бан, c — кик, d — изменение карты и т.д.) для каждого SteamID. Тонкость: не выдавайте флаг z (root) никому, кроме себя — это полный доступ, включая rcon_password изнутри игры.

FiveM (GTA V, ESX/QBCore). Права построены на ACE permissions (add_ace group.moderator command allow в server.cfg) плюс группы игроков в самом фреймворке. Если стоит ESX или QBCore, права модерации обычно идут через отдельный ban/admin-ресурс (например, txAdmin, если сервер развёрнут через него) — там же удобно смотреть лог банов, о котором дальше.

Общий принцип для любого движка: заведите шаблон группы один раз, тестируйте на тестовом аккаунте («а точно ли модератор не может открыть консоль сервера?»), и только потом раздавайте роли реальным людям.

Таблица: что доступно каждой роли

Таблица — это шаблон, не догма: подгоняйте под размер команды и специфику игры. Главное — держать столбец «панель хостинга» пустым для всех, кроме владельца, если только вы не доверяете человеку так же, как самому себе.

Лог действий администраторов: зачем и как вести

Рано или поздно у вас случится спор: игрок утверждает, что его забанили несправедливо, а админ говорит, что «всё по делу». Без лога это превращается в слово против слова. С логом — три минуты на разбор.

Большинство систем прав уже логируют бан/кик/мьют сами:

• LuckPerms и связанные с ним плагины модерации (LiteBans, AdvancedBan) пишут лог в базу с полями «кто, кого, когда, за что, на какой срок» — команда /banlist или веб-панель LiteBans показывают историю по каждому игроку.
• В SourceMod похожая функциональность есть в SM Advertisements / встроенных банах через sm_ban — история хранится в SQL-базе, если она подключена, иначе только в текстовом логе.
• В Rust плагин BetterChat или встроенный лог сервера (oxide/logs/) фиксирует команды админов, включая noclip и godmode — полезно смотреть, если подозреваете злоупотребление правами.

Если встроенного лога банов у вашего движка нет или он слишком скудный, минимальный вариант — завести общий канал в Discord-сервере команды (кстати, Discord-сервер для команды тоже можно поднять отдельно), куда бот дублирует каждое действие модерации через webhook, либо просто договориться о ручном формате: каждый бан — сообщение в канал #admin-log с ником, причиной и пруфом (скриншот чата, демка). Звучит как лишняя бюрократия, но именно это спасает, когда через месяц кто-то спросит «а почему меня забанили».

Регулярный пересмотр списка админов

Команда меняется: кто-то теряет интерес к проекту, кто-то уходит в другую игру, кто-то просто пропадает на полгода. Аккаунт с активными правами бана, который никто не трогал два месяца, — это не «на всякий случай пригодится», а забытая дверь в доме.

Практика, которая реально работает: раз в 1-3 месяца (зависит от размера команды) проходитесь по списку через /lp group moderator listmembers (или аналог для вашей системы) и сверяете с активностью — когда человек последний раз заходил на сервер, действовал ли как модератор. Неактивных — сначала предупреждаете в личке, затем понижаете в правах или убираете полностью. Это не наказание, а гигиена доступа: чем меньше активных учёток с высокими правами висит без присмотра, тем меньше площадь для случайной утечки или обиженного бывшего модератора, который решит напоследок нашкодить.

Отдельно проверяйте это после конфликтов в команде — если модератор уволен или ушёл со скандалом, его права снимаются в тот же день, а не «когда будет время». Смена паролей RCON и панели хостинга после ухода человека с высоким уровнем доступа — тоже не паранойя, а стандартная процедура: даже если человек ушёл мирно, лучше перестраховаться, чем потом разбираться, кто слил конфиг конкурентам.

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