Какие данные являются секретами
Ключ доступа сервера, seed публикации, пароли txAdmin и SQL, cookie, токены сессий и резервные копии приватного состояния должны быть доступны только уполномоченным администраторам. ID сервера и публичная ссылка подключения секретами не являются.
publisher.json описывает конфигурацию публикации и связан с ключом; не раздавайте рабочую пару файлов игрокам. Нельзя публиковать .seed, файл admission, txData или приватный конфиг вместе со сборкой ресурсов. Общий ZIP для игроков и резервная копия владельца — разные артефакты.
Учётная запись процесса и NTFS
Запускайте сервер под выделенной учётной записью Windows с доступом только к нужным каталогам. Мастер защищает локальное состояние ACL; после ручного копирования или миграции права нужно проверить снова. Ограничьте запись посторонних пользователей в движок и ресурсы: подмена скрипта равнозначна выполнению кода от имени сервера.
Не используйте постоянный запуск от администратора для исправления любой ошибки доступа. Найдите конкретный файл и выдайте минимально необходимое право. Не размещайте приватное состояние в общедоступной сетевой папке или каталоге, синхронизируемом в публичное облако.
Панель управления
Панель txAdmin даёт управление процессом, консолью и игроками. Не публикуйте её порт на маршрутизаторе без отдельного продуманного защищённого доступа. Используйте локальный доступ или защищённый туннель/административную сеть. Публичный игровой шлюз панель не проксирует.
Создавайте отдельные учётные записи для сотрудников и выдавайте права по обязанностям через Admin Manager. Не передавайте всем пароль master. Привязка OpenM-аккаунта не должна подменяться совпадением ника; используйте штатный процесс входа и привязки.
Ресурсы и серверные события
Клиентские скрипты и NUI доступны игроку и не подходят для хранения секретов. Данные, присланные клиентом в серверное событие, требуют проверки: права, типы, допустимые значения, принадлежность объектов и частота запросов. Проверку денег или администраторской роли нельзя выполнять только на клиенте.
Сохраняйте версии и источник ресурсов. Проверяйте код до установки, особенно динамическое выполнение, внешние загрузчики и команды ОС. Ограничивайте ACE-права конкретными командами и субъектами. Разрешение широкого command неизвестному ресурсу требует понимания всех последствий.
Сеть и скрытый IP
Открывайте только необходимые игровые TCP/UDP-порты. SQL, RDP, панели и служебные API не должны становиться публичными вследствие общего правила «разрешить всё». Скрытие адреса карточки ограничивает его отображение в каталоге, но не гарантирует анонимность сетевого хоста от подключённого игрока.
Не отключайте admission и не публикуйте серверный ключ в клиентском конфиге ради исправления входа. Авторизация сервера и игрока — разные части протокола.
Действия при утечке
- Определите, какой секрет раскрыт, где и когда; сохраните доступные журналы без дальнейшей публикации.
- При утечке admission замените или отзовите ключ доступа в карточке и сохраните новый через мастер. Отзыв блокирует последующие проверки этим ключом, но не обещает немедленного разрыва всех уже установленных игровых соединений.
- При утечке seed отзовите ключ публикации и импортируйте новую пару. Доступность каталога может временно прерваться.
- При утечке пароля SQL смените его, обновите приватный конфиг и проверьте историю доступа/изменений БД.
- При утечке административного доступа смените пароль, проверьте сотрудников, сессии и изменённые ресурсы.
- Удалите секрет из публичных файлов и истории там, где это возможно, но всё равно считайте прежнее значение раскрытым.
Не восстанавливайте скомпрометированный ключ из старой резервной копии. Проверьте новые настройки реальным запуском и сохраните время восстановления.
Журналы и обращения в поддержку
Перед отправкой фрагмента лога ищите строки подключения, заголовки Authorization/Cookie, токены и содержимое ключевых файлов. Достаточно ID, версии, времени, текста ошибки и обезличенного контекста. Доступ к полным логам и резервным копиям ограничивайте сроком и кругом получателей.
Обновления и пределы защиты
Обновляйте Windows, СУБД и ресурсы после тестирования совместимости. Наличие проверок OpenM не делает произвольный игровой ресурс безопасным и не заменяет резервное копирование. Для публичного сервера заранее подготовьте процедуру изоляции, восстановления и уведомления сотрудников при инциденте.