Безопасность и ответственное раскрытие

Этот документ описывает публичные принципы безопасности TradeStat и правила добросовестного сообщения об уязвимостях. Он не раскрывает конфигурации, ключи, внутренние адреса или иные сведения, которые могли бы ослабить защиту.

Сейчас сайт остаётся preview без реальных биржевых подключений. Текстовый редакционный backend и переходный вход через центральный AuthServer уже работают, но бесшовный browser SSO, refresh/revocation центральной сессии и торговый production-контур ещё не подключены.

Меры выбираются исходя из риска, чувствительности данных и актуальных угроз. В работающем preview подтверждены защищённая передача, ограниченный SSH-доступ, security headers и базовые health-checks. Пункты ниже задают обязательный production-baseline; разделение контуров, private networking, off-site backup, мониторинг и регулярный аудит нельзя считать завершёнными до отдельной проверки.

• Минимизация данных и запрет секретов в URL, продуктовой аналитике и обычных логах.
• Разделение production и staging, приватные сети для баз и очередей, отсутствие публичных портов PostgreSQL и Redis.
• Принцип наименьших привилегий, отдельные роли пользователя и администратора, серверная проверка каждого защищённого действия.
• Шифрование передачи, управление секретами вне репозитория и проверяемое резервное копирование вне основного сервера.
• Журналирование критических событий без содержимого ключей, паролей, токенов и торговых payload.

В переходном входе форма TradeStat передаёт логин и пароль своему same-origin серверу по HTTPS. Сервер немедленно отправляет их центральному AuthServer только в памяти запроса и не сохраняет и не журналирует пароль. Полученный token не передаётся браузеру, не декодируется для назначения ролей и не хранится в базе.

После успешной проверки браузер получает только случайную HttpOnly-сессию TradeStat сроком до 30 минут; в PostgreSQL хранятся только keyed HMAC сессии и псевдонимный identity HMAC. Кабинет проверяет сессию на сервере, а админка дополнительно требует локально назначенную роль superadmin. Это общий аккаунт с отдельной сессией TradeStat, а не бесшовный browser SSO.

До подключения реальных источников TradeStat должен принимать только минимально необходимые read-only ключи без права вывода и, если функция не требует иного, без торговли. Права ключа проверяются при подключении; неподходящий ключ отклоняется.

Секреты шифруются на уровне приложения, а ключ шифрования хранится отдельно от базы. Расшифрование разрешается только выделенным worker-процессам на время запроса. Значения ключей, токены, полные ответы бирж и финансовые данные запрещены в аналитике, URL и незащищённых логах.

Публичный адрес и зашифрованный канал для security-сообщений будут опубликованы до production-запуска. Пока такой канал не указан, сайт не предоставляет разрешение на активное тестирование; пожалуйста, не пытайтесь обходить доступ, сканировать чужие аккаунты или извлекать данные.

После публикации канала полезное сообщение должно содержать затронутый URL или компонент, понятные шаги воспроизведения, оценку влияния и безопасный proof of concept без персональных данных. TradeStat подтвердит получение, проведёт проверку и будет сообщать статус по мере возможности. Отдельная программа вознаграждений не действует, если она прямо не объявлена.

• Не применять социальную инженерию, фишинг, физические атаки и отказ в обслуживании.
• Не изменять и не удалять данные, не сохранять чужую информацию и остановиться при первом признаке доступа к ней.
• Не публиковать детали до согласования разумного срока исправления.
• Не выдавать автоматический отчёт сканера за подтверждённую уязвимость без проверки влияния.

Для production должны действовать внутренний план реагирования, ответственные лица, журнал инцидентов, резервные каналы связи и проверенные процедуры восстановления. Команда классифицирует событие, ограничивает воздействие, сохраняет необходимые доказательства, устраняет причину и проверяет восстановление.

Если инцидент затрагивает персональные данные, уведомления пользователям и надзорным органам направляются в объёме и сроки, требуемые применимым правом. Публичная политика не заменяет внутренний runbook и не раскрывает детали, полезные атакующему.

Используйте уникальный пароль в центральном аккаунте, включите многофакторную защиту, проверяйте домен перед входом и не передавайте коды, токены и ключи поддержки. Для бирж создавайте отдельный read-only ключ с минимальными разрешениями и регулярно отзывайте неиспользуемые ключи.

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

Ни одна система не может гарантировать абсолютную безопасность. TradeStat обязан поддерживать меры соразмерно риску, проверять их эффективность и исправлять подтверждённые недостатки, но настоящий документ не является гарантией отсутствия инцидентов.

Политика обновляется при изменении архитектуры, каналов сообщения или программы раскрытия. Существенные редакции получают новую версию и дату; предыдущие версии должны храниться в архиве документов.