Здесь описано, как устроена защита данных и доступность платформы Разум на самом деле: без общих слов, только то, что настроено и проверяется. Если у вас остались вопросы, напишите нам, контакты внизу страницы.
1. Где хранятся данные
Данные аккаунтов, настроек, чатов и маркировки лежат на выделенном сервере платформы в дата-центре в Германии (хостинг Fornex). Аналитические данные продаж живут в отдельном хранилище и доступны приложению только на чтение.
Резервные копии дополнительно хранятся в независимом объектном хранилище в России (Timeweb Cloud), чтобы потеря сервера не означала потерю данных.
2. Резервные копии
База платформы копируется каждую ночь, база маркировки каждые 6 часов. Каждая копия проходит проверку целостности, повреждённая копия отбрасывается, и команда получает уведомление.
На сервере хранится 14 последних копий базы платформы и неделя копий базы маркировки.
Копии ежедневно отправляются в независимое хранилище в другой стране и у другого провайдера. Там они хранятся 30 дней и зашифрованы на нашей стороне до отправки: провайдер хранилища содержимое прочитать не может.
Если копия в хранилище не обновилась больше 36 часов, команда получает уведомление.
Восстановление из копии проверяется на практике, а не на бумаге: последняя проверка 12 октября 2026 г., полное восстановление базы платформы заняло около 7 минут.
3. Доступность и обновления
Обновления выходят без остановки сервиса. Новая версия собирается рядом с работающей, проходит проверку и переключается атомарно. Если проверка не пройдена, система сама возвращает предыдущую версию за секунды.
Приложение работает в нескольких параллельных процессах, которые перезапускаются по очереди, поэтому пользователи переключения версий не замечают.
Доступность проверяется каждые 2 минуты изнутри и независимым внешним монитором снаружи. Состояние памяти, диска, нагрузки и частоты ошибок контролируют отдельные сторожа. Все сигналы приходят команде в Telegram круглосуточно.
Текущее состояние сервиса и история инцидентов открыты на статус-странице: status.onescreen.business.
4. Защита доступа
Весь трафик идёт по HTTPS (TLS 1.2 и 1.3), сертификаты продлеваются автоматически. Браузеру предписано обращаться к платформе только по защищённому соединению (HSTS).
Приложение доступно только через защищённый шлюз. Прямой доступ к серверу извне закрыт, административный вход на сервер возможен только по криптографическим ключам, подбор паролей блокируется автоматически.
Пароли пользователей хранятся в виде необратимого хеша (bcrypt). Число попыток входа ограничено.
Сессия живёт в защищённой cookie, недоступной скриптам страницы, и истекает через 7 дней. Запросы с чужих сайтов отклоняются по проверке источника.
5. Ключи ваших кабинетов
Токены Wildberries, Ozon, Яндекс Маркета, Честного знака, МойСклада и ключи ИИ-провайдеров хранятся в базе в зашифрованном виде (AES-256-GCM). Ключ шифрования хранится отдельно от базы.
Доступ к данным каждого клиента ограничен его рабочим пространством. Каждый запрос к данным продаж выполняется только в рамках проекта и кабинетов, выданных пользователю.
Все действия платформы во внешних кабинетах записываются в журнал аудита: кто, когда, с какого адреса и по какой настройке. По любой операции можно восстановить полную хронологию.
6. ИИ и ваши данные
ИИ-чат и агенты обращаются к данным продаж только на чтение: запросы проходят через валидатор, который пропускает исключительно чтение, а соединение с хранилищем открыто в режиме «только чтение». Изменить или удалить данные ИИ не может.
В модель уходит только то, что нужно для ответа на конкретный запрос. По условиям API провайдеров (Anthropic, OpenAI, Google) переданные данные не используются для обучения моделей.
Действия, которые меняют что-то во внешних кабинетах (цены, ответы на отзывы, отгрузки), выполняются только по вашим настройкам или подтверждению и попадают в журнал аудита.
7. Как мы разрабатываем
Каждое изменение кода проходит автоматические проверки и тесты до попадания на сервер.
На рабочий сервер попадает только код, прошедший ревью и слияние через проверенный процесс. Система выкладки отдельно проверяет происхождение каждой версии.
Ошибки приложения собираются в журнал с привязкой к запросу, и команда разбирает их, не дожидаясь обращения клиента.