Когда клиент проектирует продукт в вашем конфигураторе, он не просто рассматривает витрину - он делится предпочтениями, создаёт интеллектуальную собственность и во многих случаях передаёт персональные данные. Эти данные нужно обрабатывать с той же строгостью, что и платёжную информацию и клиентские аккаунты. И всё же вопросы безопасности и приватности часто упускаются при оценке конфигуратора - их затмевают разговоры о качестве 3D-рендера и логике ценообразования.
Цена небрежности в России заметно выросла. С 30 мая 2025 года за утечку персональных данных предусмотрены многомиллионные штрафы, а за повторное нарушение - оборотные, рассчитываемые от годовой выручки компании; за незаконный оборот персональных данных в Уголовном кодексе появилась отдельная статья 272.1. При этом ответственность перед клиентом несёт оператор, то есть вы, а не встроенная вами платформа. Для бизнеса, который ставит на витрину сторонний конфигуратор, утечка на стороне вендора - это утечка ваших клиентских данных и ваш штраф. Этот гид охватывает вопросы безопасности и защиты персональных данных, которые должны быть частью любой оценки платформы конфигуратора.
Какие данные собирают конфигураторы?
Продуктовые конфигураторы собирают больше данных, чем осознаёт большинство бизнесов. Напрямую они фиксируют: созданные клиентом дизайны и спецификации, контактную информацию (если она сохраняется или ею делятся), расчёты цены и данные заказа, а также загруженные файлы (логотипы, иллюстрации, референсные изображения). Косвенно они фиксируют: поведение и паттерны взаимодействия, информацию об устройстве и IP-адреса, данные сессии и cookie, а также географию по IP или настройкам браузера.
Для B2B-конфигураторов чувствительность данных ещё выше. Спецификации продукта могут содержать проприетарные размеры, кастомные инженерные параметры или конфиденциальные ценовые соглашения. B2B-конфигуратор, сливающий конкурентам кастомные спецификации продукта клиента, - это событие, способное обанкротить бизнес, а не просто комплаенс-вопрос.
Что требует 152-ФЗ
Как только покупатель оставляет в конфигураторе имя, телефон, почту или адрес доставки, вы становитесь оператором персональных данных со всем набором обязанностей по Федеральному закону № 152-ФЗ. Ключевые из них:
- Уведомление Роскомнадзора. До начала обработки оператор подаёт уведомление о намерении осуществлять обработку персональных данных (ст. 22). Исключений, на которые раньше опирались интернет-магазины, с сентября 2022 года практически не осталось.
- Согласие. Оно должно быть конкретным, предметным, информированным, сознательным и однозначным (ст. 9). Заранее проставленная галочка «согласен со всем» под формой заказа этому не отвечает, а на публикацию клиентских данных - например, готовых проектов в галерее - требуется отдельное согласие на распространение (ст. 10.1).
- Локализация баз данных. Запись, систематизация, накопление, хранение, уточнение и извлечение персональных данных граждан РФ выполняются с использованием баз данных, находящихся на территории России (ст. 18 ч. 5).
- Поручение на обработку. Передавая данные вендору конфигуратора, вы поручаете ему обработку. Поручение оформляется договором или отдельным документом, где перечислены разрешённые действия с данными, цели обработки, обязанность соблюдать конфиденциальность и требования к защите (ст. 6 ч. 3). Ответственность перед клиентом при этом остаётся на вас.
- Реакция на инцидент. Уведомить Роскомнадзор об утечке нужно в течение 24 часов, а о результатах внутреннего расследования - в течение 72 часов (ст. 21).
Отсюда конкретные вопросы к платформе конфигуратора: где физически находятся базы данных, у кого из сотрудников вендора есть к ним доступ, каковы сроки хранения и порядок уничтожения данных, готов ли вендор подписать поручение на обработку по ст. 6 ч. 3 и как быстро он сообщит вам об инциденте, чтобы вы успели уложиться в свои 24 часа.
Практики безопасного встраивания
Большинство конфигураторов встраиваются на сторонние сайты через iframe. Эта модель встраивания вносит специфические соображения безопасности. iframe должен раздаваться по HTTPS с валидными TLS-сертификатами. Заголовки Content Security Policy (CSP) должны ограничивать действия встроенного контента - не давая ему доступ к DOM, cookie или local storage родительской страницы. Атрибут sandbox должен ограничивать возможности iframe только тем, что необходимо (разрешая скрипты и доступ same-origin, но блокируя навигацию верхнего уровня и отправку форм на внешние URL).
Кросс-доменное общение между iframe и родительской страницей должно использовать API postMessage со строгой проверкой origin. Конфигуратор, требующий отключения CSP-заголовков или удаления sandbox у iframe, - это красный флаг. Headless-подход, при котором конфигуратор рендерится в пределах вашего домена, снимает часть этих опасений, но данные всё равно уходят на серверы платформы конфигуратора - а значит, вопрос о том, где эти серверы стоят, никуда не девается.
Шифрование данных
Шифрование данных должно быть необсуждаемым на двух уровнях: при передаче и в покое. При передаче - означает, что все данные, обмениваемые между браузером клиента, вашим сайтом и платформой конфигуратора, шифруются по TLS 1.2 или выше. В покое - означает, что данные, хранящиеся на серверах платформы конфигуратора, шифруются с использованием AES-256 или эквивалента. Это включает данные конфигурации, загрузки клиентов и любые кэшированные рендеры.
Для особо чувствительных применений - военных подрядчиков, производителей медицинских изделий, премиальных люксовых брендов - может потребоваться сквозное (end-to-end) шифрование, при котором сама платформа конфигуратора не может расшифровать клиентские данные. Это нишевое требование, но его стоит понимать при оценке платформ для чувствительных отраслей.
Защита интеллектуальной собственности
Продуктовые конфигураторы показывают миру ваши дизайны продуктов, инженерные параметры и логику ценообразования. Это создаёт IP-вопросы, выходящие за рамки приватности. Может ли конкурент использовать ваш конфигуратор, чтобы реверс-инжинирить ваши спецификации? Может ли кто-то спарсить ваш конфигуратор и извлечь вашу ценовую модель?
Меры противодействия включают: обфускацию параметрических правил, чтобы исходные формулы не выгружались в браузер, ограничение скорости (rate limiting) API-доступа для предотвращения автоматизированного скрейпинга, нанесение водяных знаков на 3D-рендеры для сдерживания копирования через скриншоты и ограничение экспорта конфигурации для аутентифицированных пользователей. Решение между no-code и кастомной разработкой тоже влияет на защиту IP - кастомные конфигураторы могут реализовывать проприетарную логику на стороне сервера, тогда как no-code-платформы могут раскрывать больше логики на стороне клиента.
Требования крупных заказчиков и госсектора
Крупный российский заказчик оценивает платформу по своим формальным рамкам. Уровень защищённости персональных данных (от УЗ-4 до УЗ-1) определяется по постановлению Правительства № 1119 - исходя из категории обрабатываемых данных, типа актуальных угроз и числа субъектов; от уровня зависит обязательный набор мер защиты. Сами меры описаны в приказе ФСТЭК России № 21, а если для защиты применяется криптография, используются средства криптографической защиты, сертифицированные ФСБ России, класс которых определяется той же моделью угроз.
Отсюда список вопросов вендору: какой уровень защищённости обеспечивает его инфраструктура и чем это подтверждено, какие сертифицированные средства защиты применяются, кто субподрядчики, тоже получающие доступ к вашим данным, как устроены реагирование на инциденты, резервное копирование и восстановление, проводится ли независимое тестирование на проникновение и как часто.
SOC 2 Type II и ISO/IEC 27001 остаются полезным сигналом зрелости процессов у вендора, но российских требований они не закрывают: международный аудит не заменяет ни базы данных на территории России, ни мер по приказу № 21, ни уведомления Роскомнадзора. Гид по выбору платформы подробно покрывает остальные критерии оценки.
Локализация: где физически лежит база
Российское требование устроено не так, как европейское: закон предписывает не столько то, куда данные нельзя вывозить, сколько то, где должна находиться первичная база. Персональные данные граждан РФ записываются, систематизируются, накапливаются, хранятся, уточняются и извлекаются в базах данных на территории России (ст. 18 ч. 5 152-ФЗ). По позиции Роскомнадзора зарубежная копия возможна как вторичная - но только после того, как первичная запись сделана в российской базе, и при условии, что о трансграничной передаче вы уведомили регулятора (ст. 12); по отдельным странам передачу могут ограничить или запретить.
Для встроенного конфигуратора это переводится в предметные вопросы вендору: в какой стране стоит сервер, куда уходит форма заявки; где хранятся загруженные покупателем файлы и сгенерированные рендеры; попадают ли IP-адрес и данные сессии в зарубежную аналитику; фиксируется ли расположение базы в договоре. Ответ вида «наш дата-центр в Европе, а это одна из самых строгих юрисдикций по защите данных» требованию ст. 18 ч. 5 не удовлетворяет: строгость чужого регулятора российской базы не заменяет.
Как к этому подходит Фабрикод
Фабрикод отдаёт весь контент по HTTPS с TLS 1.3, шифрует данные в покое, поддерживает безопасное встраивание iframe с корректными CSP-заголовками и аутентификацию API через OAuth 2.0. Практики обращения с данными описаны в нашей политике конфиденциальности.
Вопросы размещения баз данных, оформления поручения на обработку и требуемого вам уровня защищённости мы разбираем предметно под конкретный проект, а не общими формулировками. Напишите нам, опишите свой контур требований - и мы ответим по существу вашего сценария.
