Безопасность и защита данных в Evalife

Версия: 1.0

Дата обновления: 15 июля 2026 года

Адрес публикации: https://evalife.ru/legal/security

1. Подход Evalife

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

Настоящая страница описывает меры в пределах Evalife Platform и Evalife Forms. Она не заменяет договор, DPA, Политику обработки персональных данных или индивидуальный SLA.

2. Распределение ответственности

2.1. Evalife

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

2.2. Клиент

Клиент является оператором данных, которые собирает через свои формы, и отвечает за законность целей и полей, тексты политики и согласий, пользователей workspace, выгрузки и копии, подключенные CRM и дальнейшее использование данных после передачи из Evalife.

Домен forms.evalife.ru является техническим адресом и не изменяет распределение ролей.

3. Размещение данных

Основные production-базы, резервные копии и журналы, содержащие персональные данные, размещаются в Российской Федерации.

Фактические поставщики, их роли и места обработки раскрываются в реестре поставщиков.

Интеграция, которую Клиент подключает к внешней системе, относится к внешнему контуру Клиента. Клиент самостоятельно определяет передаваемые поля и получателя.

4. Защита передачи и хранения

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

Защита данных в хранилищах и резервных копиях: контактные значения и чувствительные данные Forms шифруются через Vault Transit; секреты хранятся в Vault/External Secrets; защита дисков и резервных копий проверяется по инфраструктурному реестру.

Пароли пользователей хранятся в виде стойких криптографических хешей: пароли хэшируются Argon2 с индивидуальной солью и не хранятся в открытом виде.

API tokens, webhook secrets, ключи и инфраструктурные credentials не должны храниться в открытом виде в исходном коде или журналах. Доступ к ним ограничивается, а ротация выполняется планово и при подозрении на компрометацию.

5. Аутентификация и доступ

Evalife применяет уникальные учетные записи, роли и permissions, принцип минимально необходимых привилегий, ограниченные API tokens, отзыв сессий и журналирование изменений доступа.

Режим многофакторной аутентификации: MFA предусмотрена для привилегированных и критичных операций; обязательность включается по роли и политике доступа.

Критичные действия, включая массовый экспорт, управление ролями, интеграциями и API, требуют повышенной проверки в соответствии с риск-профилем операции.

6. Изоляция Клиентов

Объекты связываются с конкретным workspace. Backend проверяет tenant scope при запросах, фоновых задачах, экспортах и интеграциях.

Evalife тестирует попытки доступа пользователя или сервиса к данным другого workspace. Raw data разных Клиентов не объединяются для рекламы, внешнего AI/ML или cross-client scoring.

7. Доступ поддержки

Поддержка по умолчанию работает с техническими метаданными без постоянного доступа к исходным ответам форм.

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

Поддержка не использует ответы форм для собственных продаж или коммуникаций с Респондентами.

8. Журналирование и мониторинг

Evalife ведет журналы действий, согласий, доступа, доставки, событий безопасности, доступа поддержки и удаления.

Пароли, tokens, webhook secrets, ключи и полный raw payload формы штатно не записываются в журналы.

9. Резервное копирование и восстановление

Резервные копии создаются в РФ-контуре, защищаются и доступны ограниченным ролям. Публичное описание режима: ежедневный базовый цикл, срок хранения 30 календарных дней; восстановление и удаление контролируются журналом операций.

Резервные копии предназначены для восстановления сервиса после сбоя или инцидента и не являются обычным архивом удаленных записей.

Восстановление проверяется по графику не реже одного раза в квартал после ввода production backup-профиля. RPO и RTO публикуются только после подтверждения фактическими тестами и включения в применимый SLA.

10. Удаление и жизненный цикл

Evalife поддерживает удаление отдельных ответов, массовое удаление уполномоченной ролью, блокирование workspace, deletion journal, повторное применение удаления после восстановления и очистку временных экспортов.

После закрытия workspace доступ блокируется. В течение 90 календарных дней возможен возврат при отсутствии оснований для отказа. После этого доступ не восстанавливается, а данные активного контура удаляются или блокируются по регламенту, если отсутствует законное основание для хранения.

Резервные копии очищаются по установленному циклу ротации; мгновенное физическое удаление из всех backup не обещается.

11. Безопасная разработка

Процесс разработки включает code review, проверку зависимостей и secrets, разделение сред, ограничение production data в тестах, контроль инфраструктурных изменений, тестирование permissions и tenant isolation и исправление уязвимостей по уровню риска.

12. Инциденты

Evalife использует процесс обнаружения, классификации, ограничения распространения, сохранения доказательств, устранения причины, восстановления, уведомления и post-incident review.

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

13. Поставщики

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

Поставщик получает только необходимые данные и права.

14. Ограничения текущего режима

Публичный self-service MVP не предназначен для медицинских анкет и карт, биометрии, политических данных, паспортных и медицинских файлов, чувствительных данных детей и автоматических юридически значимых решений.

Загрузка файлов Респондентами, рекламные pixels и внешняя аналитика на страницах форм выключены.

15. Сообщение об уязвимости

Описание возможной уязвимости направляется на security@evalife.ru. Укажите затронутый URL или компонент, безопасные шаги воспроизведения и возможное влияние.

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

Целевой срок подтверждения получения: первичное подтверждение получения в течение одного рабочего дня. Этот контакт не является публичной bug bounty и не означает обещания вознаграждения.

16. Связанные документы и контакты

• Политика обработки персональных данных: https://evalife.ru/legal/personal-data-processing;
• Политика cookies: https://evalife.ru/legal/cookies;
• DPA: https://evalife.ru/legal/dpa;
• поставщики: https://evalife.ru/legal/subprocessors;
• персональные данные: privacy@evalife.ru;
• безопасность: security@evalife.ru;
• поддержка: support@evalife.ru.

Страница обновляется при существенном изменении описанных мер или после очередной проверки доказательств.