Документация модуля "SenDev: 152-ФЗ Персональные данные" обновлена до версии 1.1.16. Идут работы по обновлению визуальных материалов

Безопасность обмена Monitor и Aggregator

Monitor передаёт технические данные по HTTPS и дополнительно подписывает запросы токеном агента.

[Скриншот 1: настройки токена и HTTPS]

Как подтверждается агент

В запросе передаются токен, идентификатор установки, временная метка и HMAC-SHA256 подпись тела. Aggregator ищет активного агента по токену, проверяет допустимое отклонение времени и подпись.

Что должен делать администратор

  • использовать только HTTPS;
  • создавать отдельный токен на каждую установку;
  • не публиковать токены в документации и скриншотах;
  • после утечки регенерировать токен;
  • следить за точным временем сервера;
  • предпочитать pull-команды прямым входящим вызовам.

[Скриншот 2: whitelist IP]

Whitelist для direct-доступа

Если используются входящие endpoint-ы Monitor, их можно дополнительно ограничить IP/CIDR. Ограничение должно соответствовать реальным адресам центрального сервера, включая возможный reverse proxy.

Что не выполняет канал команд

В стандартном CommandService нет произвольного выполнения PHP или shell-команд. Это полезное ограничение: удалённое обслуживание сведено к фиксированному набору операций, которые можно журналировать и проверять.

Для будущего SenDev Hub

Текущая схема достаточна как внутренний прототип, но для внешнего сервиса лицензирования и обновлений лучше перейти от общего HMAC-секрета к индивидуальной паре ключей установки, подписанным запросам, защите от повторов и подписанным пакетам обновлений. Эти изменения описаны в отдельной архитектурной записке.

Важно: Не пытайтесь «защитить» модуль обфускацией PHP, eval/base64 или скрытой расшифровкой кода. Такие техники ухудшают аудит и чаще вызывают подозрение у антивирусных сканеров.

Окно времени и replay

Текущий timestamp отклоняет слишком старые запросы, но корректно подписанный запрос теоретически можно повторить внутри допустимого окна. Для следующего протокола добавьте request_id/nonce и храните уже использованные идентификаторы на Hub несколько минут.

Хранение ключа

В будущей схеме приватный Ed25519-ключ установки должен создаваться и оставаться на клиентском сервере с файловыми правами, доступными только PHP-пользователю/администратору. Hub хранит публичный ключ. Это лучше масштабируется с точки зрения последствий утечки центральной БД.

Прозрачность для сканеров

Сетевой код должен быть обычным читаемым клиентом: фиксированный HTTPS-домен, понятный User-Agent, JSON, libsodium/OpenSSL, журнал запросов. Не используйте runtime-расшифровку, eval, обфускацию или скачивание исполняемого PHP с произвольных адресов.

[Скриншот 3: журнал успешного обмена]