Почему нельзя выдавать всем полный доступ
Полные административные права позволяют менять карту, выполнять команды, управлять игроками и иногда редактировать критические настройки. Если такие права получает каждый модератор, одна ошибка способна остановить сервер.
Безопасная система строится по принципу минимально необходимых разрешений. Человек получает только те возможности, которые нужны для его задач.
Основные роли
Владелец
Имеет доступ к серверу, хостингу, платежам, базе данных и настройке прав. Такая роль должна быть одна или максимально ограниченное число.
Технический администратор
Обновляет сервер, плагины, конфигурации и резервные копии. Ему может потребоваться SSH, но не обязательно доступ к платежам.
Старший администратор
Рассматривает жалобы, управляет модераторами и принимает сложные решения.
Модератор
Следит за порядком, предупреждает игроков, использует mute, kick и ограниченные блокировки.
Помощник
Может сообщать о нарушениях или использовать минимальный набор команд без возможности выдавать серьёзные наказания.
Привязка к SteamID
Права должны назначаться по устойчивому идентификатору, а не по отображаемому нику. Ник легко изменить или скопировать.
Перед добавлением проверьте SteamID несколькими способами. Ошибка в одной цифре может выдать права другому человеку.
Не храните административные записи без комментариев. Указывайте имя сотрудника, роль, дату выдачи и основание.
Разделение команд
Модератору обычно не нужны:
- перезапуск сервера;
- изменение конфигурации;
- доступ к RCON;
- управление другими администраторами;
- выполнение произвольных серверных команд;
- редактирование базы данных.
Создайте отдельные наборы разрешений для каждой роли. Не используйте один универсальный флаг полного доступа.
Временные права
Стажёру или организатору события можно выдать временные права. Обязательно укажите дату окончания и удалите запись после завершения задачи.
Временный доступ, забытый на несколько месяцев, становится постоянной уязвимостью.
Журнал действий
Все важные административные команды должны попадать в журнал:
- блокировки;
- снятие наказаний;
- kick;
- mute;
- смена карты;
- изменение игровых параметров;
- выдача прав;
- удаление прав.
Журнал нужен не для постоянного недоверия к команде, а для разрешения спорных ситуаций.
Правила для администрации
Подготовьте внутренний регламент:
- когда можно вмешиваться;
- какие доказательства нужны;
- максимальный срок наказания;
- кто рассматривает апелляции;
- как действовать при конфликте;
- можно ли наказывать знакомого;
- запрещено ли использовать команды ради преимущества.
Администратор не должен менять правила во время конкретного конфликта.
Отзыв доступа
Когда сотрудник уходит, удалите:
- игровые права;
- SSH-ключ;
- аккаунт панели;
- доступ к базе;
- токены;
- общий пароль, если он использовался;
- доступ к резервным копиям.
Не откладывайте отзыв до следующего планового обслуживания.
Защита конфигурации
Файл с администраторами не должен быть доступен через сайт или публичный архив. Ограничьте права чтения и сохраняйте резервные копии.
Если права хранятся в базе данных, защитите подключение и не публикуйте пароль в репозитории.
Работа с жалобами
Администратор, участвовавший в конфликте, не должен единолично рассматривать собственную жалобу. Передавайте спор старшему сотруднику.
Храните доказательства: журналы, демо, видео или сообщения. Решение без объяснения снижает доверие игроков.
Проверка после изменений
После добавления новой роли войдите под тестовым аккаунтом и проверьте каждую разрешённую и запрещённую команду.
Не ограничивайтесь тем, что нужная команда работает. Убедитесь, что опасные команды действительно недоступны.
Контроль команды
Проводите ревизию прав хотя бы раз в месяц. Сравнивайте список сотрудников с фактическими записями.
Публичная страница проекта может содержать актуальный состав администрации, чтобы игроки понимали, к кому обращаться.
Итог
Безопасная админка строится на ролях, SteamID, минимальных разрешениях и журнале действий.
Не выдавайте полный доступ ради удобства. Чем точнее разделены права, тем меньше вероятность случайного или намеренного ущерба серверу.