MMotrix ← Все документы

Технические и организационные меры защиты данных

Редакция от 29 августа 2026 г. · Сервис Motrix (motrix.autos)

Документ описывает меры, которые Motrix применяет для защиты персональных данных. Он является приложением к Соглашению об обработке персональных данных и выполняет роль Приложения II к стандартным договорным условиям Европейской комиссии (Решение 2021/914). Меры приняты во исполнение ст. 32 Регламента (ЕС) 2016/679 и ст. 19 Федерального закона № 152-ФЗ.

1. Защита передаваемых данных

• Весь обмен между браузером и Сервисом идёт по протоколу HTTPS (TLS 1.2 и 1.3). Обращения по незащищённому протоколу перенаправляются на защищённый.
• Сертификаты выпускаются удостоверяющим центром Let's Encrypt и обновляются автоматически по расписанию, без ручного участия — это исключает истечение срока действия как класс отказа.
• Обращения к внешним поставщикам (телефония, мессенджеры, каталоги запчастей, поставщики моделей ИИ) выполняются только по защищённым каналам.
• Заголовки безопасности ответов устанавливаются централизованно на уровне приложения (Helmet): запрет определения типа содержимого по содержимому, защита от встраивания в чужие страницы, строгая политика источника перехода.
• Кросс-доменные обращения к API разрешены только с домена Сервиса; произвольный сайт не может обратиться к API от имени вошедшего пользователя.

2. Защита хранимых данных

• Пароли не хранятся. Хранится только необратимое значение, вычисленное алгоритмом bcrypt с индивидуальной солью. Восстановить исходный пароль из базы невозможно — в том числе нам.
• Токены доступа к внешним сервисам (OAuth-токены календарей и почты, ключи интеграций) хранятся в зашифрованном виде, алгоритм AES-256. Ключ шифрования хранится отдельно от базы данных, в переменных окружения приложения, и не попадает в репозиторий и резервные копии базы.
• Служебные СУБД и кеш недоступны из интернета. Порты PostgreSQL, Redis и сервиса генерации документов привязаны к локальному интерфейсу сервера; обратиться к ним можно только с самого сервера.
• Файлы пользователей хранятся в объектном хранилище без публичного доступа. Ссылка на файл выдаётся временная, подписанная и с ограниченным сроком жизни: по прямому адресу файл получить нельзя.

3. Разграничение доступа

• Изоляция компаний. Данные каждой компании отделены от данных остальных на уровне запросов к базе: принадлежность компании проверяется в каждом обращении, а не только в интерфейсе. Пользователь одной компании не может получить запись другой, даже подставив её идентификатор напрямую.
• Права по группам доступа. Каждое действие в Сервисе защищено именованным правом. Права выдаются группам, группы — сотрудникам. Проверка выполняется на сервере: скрытая кнопка в интерфейсе не является мерой защиты, и мы на неё не полагаемся.
• Ограничение по филиалу. Группа доступа может действовать в пределах одного филиала. В этом случае сотрудник видит только записи своего филиала, а его права не могут превышать прав группы уровня компании.
• Двухфакторное подтверждение входа по коду на электронную почту — включается владельцем учётной записи в профиле.
• Управление сессиями. В профиле виден список активных сессий с устройством, адресом и временем последней активности; любую сессию можно завершить, что немедленно прекращает доступ с этого устройства.

4. Устойчивость к атакам

• Ограничение частоты обращений. Действует общее ограничение на все обращения к API и отдельные, более строгие, — на вход, восстановление пароля и публичные формы. Это делает бесперспективным перебор паролей и кодов подтверждения.
• Проверка входных данных. Каждое обращение к API описано схемой: тип, длина и формат каждого поля проверяются до того, как данные дойдут до бизнес-логики. Незаявленные поля отбрасываются.
• Защита от внедрения SQL. Обращения к базе строятся через типизированный слой доступа с параметризацией запросов; конкатенация пользовательского ввода в текст запроса не применяется.
• Публичные формы (онлайн-запись, обратная связь) дополнительно защищены скрытым полем-ловушкой, минимальным временем заполнения и проверкой содержимого — так отсекается автоматизированный спам без капчи, ухудшающей доступность.
• Защита рекламного бюджета. Счётчик Motrix Pixel выявляет автоматизированный трафик на сайтах клиентов; порядок обработки описан в разделе 4a Политики конфиденциальности.

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

• Полная резервная копия базы данных снимается ежесуточно в автоматическом режиме.
• Копии хранятся 14 суток, после чего удаляются; глубина хранения позволяет вернуться к состоянию до незамеченной сразу ошибки, а не только до последней.
• Копии хранятся отдельно от базы данных и в зашифрованном хранилище, доступ к ним имеет ограниченный круг лиц.
• Файлы пользователей хранятся в объектном хранилище с собственным резервированием на стороне поставщика инфраструктуры.
• Целевое время восстановления работоспособности после отказа — не более 24 часов с момента обнаружения.

6. Журналирование и контроль

• Ведутся журналы системных событий и ошибок приложения; они используются для диагностики отказов и разбора инцидентов безопасности.
• Обращения к публичному API компании фиксируются отдельно: метод, адрес, код ответа, время обработки и учётная запись, от имени которой выполнено обращение.
• Записи фиксируют автора: у ключевых объектов сохраняется сотрудник, создавший запись, и время создания.
• Журналы не содержат паролей, кодов подтверждения и токенов доступа — эти значения исключаются из вывода.

7. Организационные меры

• Доступ к рабочим серверам предоставляется по принципу минимальной достаточности — только тем, кому он необходим для сопровождения Сервиса, и только на время, пока он необходим.
• Лица, имеющие доступ к данным, связаны обязанностью соблюдать конфиденциальность; обязанность сохраняется и после прекращения работы с Сервисом.
• Мы не просматриваем содержимое данных клиентов. Обращение к данным конкретной компании допускается только для устранения неисправности по её обращению либо когда это прямо предписано законом.
• Изменения в рабочую систему поступают через систему контроля версий: каждое изменение зафиксировано, автор и время известны, откат возможен. Развёртывание выполняется автоматически, из проверенной ветки, с автоматическим прогоном тестов и проверок типов.
• Обновления безопасности серверного программного обеспечения и зависимостей устанавливаются по мере выхода.

8. Локализация и размещение

Серверы приложения, база данных, объектное хранилище и почтовый узел размещены на территории Российской Федерации. Первичные запись, систематизация, накопление, хранение, уточнение и извлечение персональных данных граждан Российской Федерации осуществляются в базах данных, расположенных в Российской Федерации, что соответствует ч. 5 ст. 18 Закона № 152-ФЗ.

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

9. Действия при инциденте

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

1. Локализация: пресечение доступа, отзыв скомпрометированных ключей и сессий.
2. Оценка: состав и объём затронутых данных, круг затронутых лиц, причина.
3. Уведомление затронутых клиентов — без неоправданной задержки, но не позднее 24 часов с момента, когда инцидент стал нам известен. Уведомление содержит характер инцидента, категории и примерный объём данных, вероятные последствия и принятые меры.
4. Содействие клиенту в исполнении его собственных обязанностей по уведомлению надзорного органа и субъектов данных — в том числе уведомление Роскомнадзора в сроки ч. 3.1 ст. 21 Закона № 152-ФЗ и надзорного органа ЕЭЗ в срок 72 часов по ст. 33 GDPR.
5. Устранение причины и меры, предотвращающие повторение.

10. Сообщить об уязвимости

11. Контакты