Модель безопасности

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

Что поставлено на карту

DumbMonit работает внутри вашей сети. Он хранит учётные данные, необходимые для опроса каждого монитора (строки сообщества SNMP, токены API, пароли), принимает измерения от агентов на ваших машинах и отправляет запросы по настроенным вами адресам. Компрометация раскрыла бы эти секреты и дала бы злоумышленнику плацдарм в наблюдаемой сети.

Границы доверия

Граница	Кто по другую сторону	Доверие
Браузер или скрипт — `/api/*`	Администраторы, операторы и наблюдатели	Аутентификация по сеансовому cookie или токену API; три роли ограничивают права каждого.
Агент — `/api/ingest`	Машины, на которые вы установили агент	Токен конкретной машины; утёкший токен можно отозвать отдельно.
Сервер — мониторы и сервисы	Сторонние системы	Без доверия: ответы разбираются с осторожностью, перенаправления остаются в пределах того же хоста.
Сервер — каналы уведомлений	Внешние сервисы	Учётные данные шифруются при хранении и никогда не возвращаются API.
Сервер — VictoriaMetrics	Дочерний процесс на loopback или внешний экземпляр	Встроенный экземпляр не имеет аутентификации и слушает только loopback; внешний — зона ответственности оператора.
Том `/data` и хост	Оператор	Доверенная сторона. Злоумышленник, контролирующий хост или том, вне модели угроз.

Применяемые принципы безопасного проектирования

Наименьшие привилегии. Контейнер запускается от непривилегированного пользователя без единой capability, с корневой файловой системой только для чтения и no-new-privileges. Три роли (наблюдатель, оператор, администратор) ограничивают то, что пользователь может менять (crates/server/src/auth/users.rs; тест operator_role_api.rs).
Безопасность по умолчанию. На свежем экземпляре до появления первого администратора отвечают только маршруты health, setup, login и статуса аутентификации (тест api_open_security_api.rs).
Экономичность механизма. Один бинарный файл, один файл SQLite, один дочерний процесс на loopback и единственный вход для всех клиентов: /api/*.
Безопасные значения по умолчанию. Проверка безопасности, для которой нет данных, получает статус unknown, но никогда не считается пройденной; недоступный монитор и ошибка конфигурации — разные состояния.
Полное посредничество. Один промежуточный слой аутентификации (crates/server/src/auth/middleware.rs) защищает маршруты API.
Разделение привилегий. Сеансы, токены API и токены агентов — разные учётные данные с разной областью действия.
Эшелонированная защита. Шифрование при хранении поверх контроля доступа, заголовок CSRF поверх флагов cookie, ограничение частоты поверх хеширования паролей.
Секреты не возвращаются. API возвращает has_secret и credential_kind, но не сам секрет; если при PUT секрет опущен, он сохраняется.
Только проверенная криптография. Пароли хешируются с помощью Argon2, секреты шифруются AES-256-GCM (crypto.rs), двухфакторная аутентификация использует TOTP с хешированными одноразовыми резервными кодами, OpenID Connect использует state, nonce и PKCE. Ничего самодельного.

Меры противодействия по классам уязвимостей

Класс (тема OWASP Top 10)	Меры
Нарушенный контроль доступа	Один слой аутентификации; роли; свежий экземпляр отклоняет всё, кроме setup, login, health и статуса аутентификации.
Криптографические сбои	AES-256-GCM при хранении, ключ хранится вне базы данных; хеши паролей Argon2; встроенный сервер работает по обычному HTTP, поэтому задокументирован обратный прокси с TLS.
Внедрение	SQL выполняется через `sqlx` с привязанными параметрами; прокси VictoriaMetrics пересылает только запросы на чтение (`tsdb/mod.rs`, `proxy_read`); парсеры покрыты модульными тестами.
Небезопасное проектирование	Приведённая выше модель угроз; секреты не возвращаются; экземпляр с единственным назначением.
Неправильная конфигурация безопасности	Усиленные файлы Compose, VictoriaMetrics только на loopback, рекомендации оператору по защите в политике безопасности.
Уязвимые компоненты	`cargo deny` проверяет лицензии, запреты и рекомендации RustSec; еженедельное сканирование опубликованных образов с помощью Trivy; Dependabot; GitHub Actions закреплены по коммиту.
Сбои идентификации и аутентификации	Ограничение частоты входа по адресу клиента и по учётной записи (`auth/rate_limit.rs`), необязательная двухфакторная аутентификация, OpenID Connect, администратор может сбросить второй фактор пользователя и завершить его сеансы.
Целостность программ и данных	Установщики агента проверяют SHA-256 загруженного бинарного файла; образы релизов собираются в CI.
Журналирование и мониторинг	Журнал безопасности входов и важных изменений (`auth/audit.rs`).
Подделка запросов со стороны сервера	Интеграции и каналы уведомлений следуют перенаправлениям только в пределах того же хоста, поэтому монитор не может перенаправить запрос и свой ключ API в другое место.
Межсайтовая подделка запросов	Изменяющие состояние запросы, опирающиеся на cookie, должны содержать `X-Requested-With: DumbMonit` или метаданные fetch того же источника, иначе `403`; запросы с токеном не несут cookie.

Проверка

Каждый push и pull request запускает clippy -D warnings, набор тестов Rust (включая тесты API, аутентификации и ролей в crates/server/tests/), веб-тесты в web/tests/, проверки зависимостей и анализ CodeQL. OpenSSF Scorecard запускается по расписанию. Исправления безопасности сопровождаются регрессионным тестом и перечисляются в примечаниях к релизу с идентификатором CVE или GHSA.

В обосновании надёжности приведены полная модель угроз, аргументация безопасного проектирования и подтверждения каждого утверждения.

Известные ограничения

Встроенный сервер работает по обычному HTTP; поставьте перед ним TLS.
Параметры мониторов хранятся в незашифрованном виде. Секреты следует помещать в поля учётных данных.
Встроенная VictoriaMetrics не имеет аутентификации.
DumbMonit находится в стадии до 1.0; маршруты и поля ещё могут измениться.