Защита коммерческой тайны при заказе парсинга

Парсинг на заказ часто раскрывает не только “данные с сайтов”, но и вашу внутреннюю логику: каких конкурентов вы мониторите, какие SKU важнее, как часто обновляете, какие триггеры считаете критичными. Для многих компаний это и есть коммерческая тайна — ведь по ней можно понять стратегию, маржинальные зоны и приоритеты.

Хорошая новость: в большинстве случаев данные можно защитить без сложной бюрократии — если заранее настроить правила + доступы + минимизацию.

Что может быть коммерческой тайной в проектах парсинга

Чаще всего “секретом” оказывается не сам результат, а контекст и метаданные проекта:

• список конкурентов/источников и приоритеты (кто “главный”, кто “второстепенный”);
• перечень SKU/категорий (особенно маржинальные и “хиты”);
• частота мониторинга и расписание обновлений (по сути — карта вашей реакции на рынок);
• условия алертов (“если X ушёл в out of stock — включаем кампанию”, “если цена ниже на 3% — меняем прайс”);
• правила сопоставления товаров (ваши внутренние SKU/маппинги, “ключи” и справочники);
• формулы и логика пересчёта цен/маржи (даже если они косвенно отражены в ТЗ);
• данные о поставщиках, остатках, логистике (если вы объединяете это с мониторингом);
• схема интеграций: куда выгружается, какие таблицы/дашборды/эндпоинты используются.

Где обычно “утекает” информация

1. Обсуждения без NDA — источники, приоритеты и “зачем это вам” всплывают в переписке.
2. Лишние доступы — подрядчику дают доступ к внутренним системам, когда хватило бы выгрузок.
3. Избыточные поля — в выгрузке случайно появляются внутренние ID, заметки, маржинальность, сегменты.
4. Хранение без сроков — данные остаются у подрядчика “на всякий случай”.
5. Общие учётки — нет ролей, нет 2FA, неясно “кто именно заходил”.
6. Личные каналы передачи — мессенджеры и личные облака без контроля и TTL.
7. Нет финального “закрытия проекта” — не закрепили возврат/удаление данных и отключение доступов.

Документы и организационные меры

• NDA до передачи деталей (источники, частоты, приоритеты).
• Пункт о коммерческой тайне в договоре: что считается тайной, срок, ответственность, исключения (например, публичные факты).
• Запрет субподряда без согласия (или порядок согласования).
• Порядок передачи результатов: допустимые каналы, кто имеет доступ, как фиксируется выдача.
• Регламент хранения/удаления: сроки хранения у подрядчика и подтверждение удаления.
• Уведомление об инцидентах: кто сообщает, в какие сроки, что фиксируется.
• DPA/поручение на обработку — если в данных появляется ПДн (лучше по возможности не включать ПДн вообще).

Технические меры, которые дают максимум эффекта

Минимальные привилегии и контроль доступа

• доступ только к нужному объёму данных и только на время проекта;
• раздельные учётные записи, никаких “общих логинов”;
• 2FA для всего, где есть файлы/доступы.

Изоляция и “никаких ключей от прода”

• по возможности — отдельное окружение (staging/test);
• если доступ к внутренним сервисам нужен — только роль “read-only”, VPN/allowlist IP и временные токены;
• по умолчанию — модель “подрядчик получает данные, а не доступ к вашим системам”.

Безопасная передача данных

• SFTP/корпоративное облако/ссылки с TTL;
• шифрование при хранении и передаче;
• пароль на архив — отдельным каналом.

Хранение и “data retention”

• срок хранения у подрядчика фиксируется заранее (например, 30 дней после выдачи);
• журналирование: кто выгружал, когда, какой файл, куда передал;
• запрет на копирование в личные хранилища и устройства.

Минимизация полей и маскирование

• чётко определить поля “собираем” и “не собираем”;
• внутренние SKU/маппинги — по возможности маскировать (технические ключи вместо “говорящих”);
• разделять: “таблица соответствий” (самая чувствительная) — отдельный файл/доступ.

Что прописать в ТЗ на парсинг, чтобы защитить данные

Кроме стандартных “источники/поля/частота” добавьте пункты, которые прямо снижают риск утечек:

• Состав данных: список полей + запрет на лишние поля (“ничего сверх перечисленного”).
• Формат результата: где именно и как хранится итог (CSV/Excel/Sheets/API), кто может скачивать.
• Каналы коммуникаций: где обсуждаем (почта/таск-трекер), где передаём файлы (корп. канал).
• Политика хранения: срок хранения у подрядчика + процедура удаления/возврата.
• Логи доступа: требование фиксировать выдачу результатов и скачивания.
• Запрет использования данных подрядчиком: “не использовать в своих целях”, включая демонстрации, кейсы, обучение моделей.
• Инциденты: SLA реакции и контакт ответственного.

Мини-шаблон формулировки для ТЗ

• Разрешено: собирать поля A, B, C из источников X, Y, Z; хранить у подрядчика не более N дней; передавать через канал K.
• Запрещено: собирать любые иные поля; передавать третьим лицам; хранить дольше N дней; использовать данные вне проекта; подключать субподряд без согласия.

Таблица: риск → как снижать → что просить у подрядчика

Риск	Как снижать	Что просить у подрядчика
Утечка источников/конкурентов	NDA + ограничить детали	NDA до передачи списка источников
Лишние доступы	минимальные роли, 2FA	роль-модель, раздельные аккаунты
Данные “лежат вечно”	сроки хранения и удаление	retention + подтверждение удаления
Пересылка в мессенджерах	безопасные каналы	SFTP/корп. облако/TTL-ссылки
Утечка внутренних SKU/логики	маскирование, отдельные файлы	выдача маппинга отдельно/ограниченно
Инцидент не замечают	мониторинг и уведомления	регламент инцидентов + SLA
Субподряд без контроля	запрет/согласование	субподряд только с согласия

Pre-flight перед стартом

1. NDA подписан до передачи деталей.
2. В ТЗ есть поля “собираем” и “не собираем”.
3. В договоре закреплена коммерческая тайна и срок обязательств.
4. Согласованы каналы передачи (без личных облаков/чатов).
5. Доступы выданы по ролям, включён 2FA.
6. Нет доступа к прод-системам без необходимости.
7. Определены сроки хранения у подрядчика и процедура удаления.
8. Запрещён субподряд без согласия.
9. Есть регламент инцидентов и контакт ответственного.
10. Выдача выгрузок логируется (кто/когда/что получил).