Назад к блогу

GDPR при веб-скрейпинге через прокси: как собирать данные и не получить штраф €20 млн

Разбираем требования GDPR для веб-скрейпинга: какие данные можно парсить, как правильно использовать прокси и защитить бизнес от штрафов до €20 млн

📅26 февраля 2026 г.

Если вы парсите маркетплейсы, мониторите цены конкурентов или собираете данные для аналитики — вопрос соблюдения GDPR (General Data Protection Regulation) напрямую влияет на ваш бизнес. Штрафы достигают €20 миллионов или 4% годового оборота компании, и европейские регуляторы активно их выписывают. В этом руководстве разберём, какие данные можно собирать легально, как правильно использовать прокси для compliance и какие меры защиты внедрить в процесс веб-скрейпинга.

Важно понимать: GDPR регулирует не сам скрейпинг, а обработку персональных данных граждан ЕС. Даже если ваша компания находится за пределами Европы, но вы собираете данные европейских пользователей — регламент применяется к вам.

Что такое GDPR и как он применяется к веб-скрейпингу

GDPR (General Data Protection Regulation) — европейский регламент о защите персональных данных, вступивший в силу в мае 2018 года. Он применяется к любой компании или физическому лицу, которое обрабатывает персональные данные граждан Европейского союза, независимо от местонахождения самой компании.

Для веб-скрейпинга это означает следующее: если вы парсите публичные сайты и собираете информацию о европейских пользователях (имена, email, телефоны, адреса, данные о поведении), вы автоматически становитесь субъектом регулирования GDPR. Это касается всех популярных задач:

  • Парсинг маркетплейсов (Wildberries, Ozon, Amazon EU) — если собираете данные продавцов или покупателей
  • Мониторинг цен конкурентов — если в данных есть информация о контактах компаний
  • Сбор контактов для B2B — email, телефоны, должности сотрудников компаний
  • Анализ социальных сетей — профили пользователей, комментарии, активность
  • Агрегация объявлений (недвижимость, вакансии, услуги) с контактными данными

Ключевой момент: GDPR не запрещает веб-скрейпинг как таковой. Он устанавливает правила обработки персональных данных. Если вы собираете только публичную неперсональную информацию (цены товаров, характеристики, описания без привязки к конкретным людям) — формально GDPR не применяется. Но как только в данных появляются имена, контакты или идентификаторы пользователей — вступают в силу требования регламента.

Важно: Штрафы за нарушение GDPR составляют до €20 млн или 4% годового оборота компании (применяется большая сумма). В 2023 году европейские регуляторы выписали штрафов на общую сумму более €2,5 млрд. Крупнейшие получили Meta (€1,2 млрд), Amazon (€746 млн), TikTok (€345 млн).

Какие данные считаются персональными по GDPR

GDPR определяет персональные данные очень широко: это любая информация, относящаяся к идентифицированному или идентифицируемому физическому лицу. На практике при веб-скрейпинге к персональным данным относятся:

Категория данных Примеры при скрейпинге Уровень риска
Прямые идентификаторы ФИО, email, телефон, адрес, фото профиля, username в соцсетях Высокий
Косвенные идентификаторы IP-адрес, cookie ID, device fingerprint, геолокация, история просмотров Средний
Специальные категории Расовое происхождение, политические взгляды, религия, здоровье, биометрия Критический
Деловая информация Должность, компания, рабочий email/телефон, профиль в LinkedIn Средний
Неперсональные данные Цены товаров, характеристики, описания, статистика без привязки к лицам Низкий

Частая ошибка: считать, что публично доступные данные можно свободно собирать и использовать. GDPR не делает исключений для публичной информации. Если вы парсите профили LinkedIn, контакты с корпоративных сайтов или объявления с телефонами — это персональные данные, и требования регламента применяются в полной мере.

Особое внимание — к IP-адресам. Европейский суд в 2016 году постановил, что динамические IP-адреса являются персональными данными, так как провайдер может идентифицировать пользователя. Это важно при использовании прокси: если вы логируете IP-адреса конечных пользователей при скрейпинге — это обработка персональных данных.

GDPR требует наличия законного основания для обработки персональных данных. Для веб-скрейпинга применимы следующие основания (статья 6 GDPR):

1. Согласие субъекта данных (Consent)

Самое очевидное, но наименее применимое к скрейпингу основание. Согласие должно быть:

  • Добровольным и осознанным
  • Конкретным (для определённой цели)
  • Информированным (пользователь понимает, что вы делаете с данными)
  • Отзываемым (можно легко отозвать)

При скрейпинге получить такое согласие практически невозможно — вы собираете данные автоматически, без взаимодействия с пользователями. Поэтому это основание редко применяется.

2. Законные интересы (Legitimate Interests)

Наиболее часто используемое основание для веб-скрейпинга. Вы можете обрабатывать данные, если это необходимо для ваших законных интересов, при условии что интересы субъекта данных не перевешивают ваши. Примеры законных интересов:

  • Мониторинг цен конкурентов — для формирования собственной ценовой стратегии
  • Анализ рынка — для бизнес-аналитики и исследований
  • Выявление мошенничества — сбор данных для защиты от фрода
  • Улучшение сервиса — агрегация публичных данных для создания полезного продукта

Важно провести тест на балансировку интересов (Legitimate Interest Assessment, LIA): документально обосновать, почему ваш интерес перевешивает интересы пользователей. Например, если вы парсите цены товаров на маркетплейсе — это обоснованный интерес. Но если собираете email для спама — это нарушение.

3. Выполнение договора или публичная задача

Эти основания применяются редко при скрейпинге. Выполнение договора актуально, если вы собираете данные для оказания услуги по договору с пользователем (например, агрегатор вакансий собирает данные для показа пользователям). Публичная задача — для государственных органов.

Практический совет:

Документируйте законное основание для каждого типа собираемых данных. Создайте внутренний документ (Data Processing Record), где опишите: какие данные собираете, для каких целей, на каком основании, как храните и защищаете. Это первое, что запросят регуляторы при проверке.

Роль прокси в соблюдении GDPR: защита и анонимизация

Прокси-серверы играют двойную роль в контексте GDPR-compliance при веб-скрейпинге. С одной стороны, они помогают минимизировать сбор персональных данных и защитить конфиденциальность. С другой — сами могут создавать риски, если используются неправильно.

Как прокси помогают соблюдать GDPR

1. Анонимизация запросов. Когда вы используете резидентные прокси для скрейпинга, целевой сайт видит IP-адрес прокси-сервера, а не ваш реальный IP. Это означает, что сайт не может напрямую идентифицировать вашу компанию как источник запросов. Для GDPR это важно, если вы хотите минимизировать раскрытие собственных данных.

2. Географическое распределение. Резидентные и мобильные прокси позволяют делать запросы с IP-адресов разных стран. Это полезно для сбора данных, специфичных для региона (например, цены в разных странах ЕС), без необходимости физического присутствия. При этом вы соблюдаете принцип минимизации — собираете только данные, доступные в конкретном регионе.

3. Ротация IP для минимизации следов. Автоматическая ротация IP-адресов через прокси помогает избежать создания профиля вашей скрейпинг-активности на целевом сайте. Это снижает риск того, что сайт соберёт и сохранит ваши метаданные (время запросов, паттерны поведения), которые сами могут быть персональными данными.

Риски использования прокси в контексте GDPR

1. Логирование данных провайдером прокси. Если ваш провайдер прокси логирует ваши запросы и IP-адреса целевых пользователей — он становится обработчиком персональных данных (Data Processor) по GDPR. Вы обязаны заключить с ним Data Processing Agreement (DPA), где прописаны обязательства по защите данных. Выбирайте провайдеров, которые предлагают no-log политику или готовы подписать DPA.

2. Использование прокси для обхода защиты. Некоторые сайты блокируют скрейпинг через технические меры (rate limiting, CAPTCHA, IP-блокировки). Использование прокси для обхода этих мер может нарушать не GDPR, а другие законы (например, Computer Fraud and Abuse Act в США или Директиву об электронной коммерции в ЕС). GDPR здесь не при чём, но юридические риски есть.

3. Прокси от ненадёжных провайдеров. Если вы используете дешёвые публичные прокси или прокси с неизвестным источником IP-адресов — есть риск, что эти IP скомпрометированы или используются для незаконной деятельности. Это может привести к тому, что собранные данные будут считаться полученными незаконным путём.

Тип прокси Преимущества для GDPR Риски
Резидентные прокси Реальные IP домашних пользователей, высокая анонимность, низкий риск блокировки Необходимо убедиться, что владельцы IP дали согласие провайдеру
Мобильные прокси IP мобильных операторов, идеальны для соцсетей, редко блокируются Высокая стоимость, меньше контроля над геолокацией
Дата-центр прокси Высокая скорость, низкая цена, полный контроль провайдера Легко детектируются, чаще блокируются, не подходят для чувствительных задач

Принцип минимизации данных: собирайте только необходимое

Один из ключевых принципов GDPR — data minimization (статья 5). Вы должны собирать только те персональные данные, которые действительно необходимы для достижения заявленной цели. Это прямо влияет на настройку скрейпинга.

Практические шаги по минимизации

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

# Плохо — сохраняем всё
product_data = {
    'title': title,
    'price': price,
    'seller_name': seller_name,  # Персональные данные!
    'seller_email': seller_email,  # Персональные данные!
    'seller_rating': seller_rating,
    'reviews': reviews  # Могут содержать имена покупателей!
}

# Хорошо — только необходимое
product_data = {
    'title': title,
    'price': price,
    'sku': sku,
    'availability': availability
}

2. Анонимизируйте или псевдонимизируйте данные. Если вам нужно отслеживать динамику (например, изменение цен у конкретного продавца), не храните имя продавца — создайте хеш от его ID. Это псевдонимизация: данные нельзя прочитать напрямую, но можно сопоставить.

import hashlib

# Псевдонимизация ID продавца
seller_id_hash = hashlib.sha256(seller_id.encode()).hexdigest()

product_data = {
    'title': title,
    'price': price,
    'seller_hash': seller_id_hash  # Невозможно восстановить исходный ID
}

3. Удаляйте данные после использования. GDPR требует хранить данные не дольше, чем необходимо (storage limitation). Если вы собираете цены для ежедневного отчёта — удаляйте данные старше 30-60 дней. Настройте автоматическую очистку базы данных.

4. Не собирайте специальные категории данных. Избегайте сбора данных о расе, здоровье, политических взглядах, религии (статья 9 GDPR). Для них требуется явное согласие или очень веские основания. При скрейпинге это почти невозможно обосновать.

Пример из практики: Компания парсила LinkedIn для сбора контактов HR-специалистов. Собирали ФИО, email, фото профиля, текущую должность, предыдущие места работы. По GDPR это избыточно — для рассылки достаточно email и должности. Фото, история работы и ФИО — лишние персональные данные, увеличивающие риски.

Безопасное хранение собранных данных

GDPR требует обеспечить безопасность персональных данных (статья 32). Если вы собираете данные через скрейпинг, вы обязаны защитить их от утечек, несанкционированного доступа и потери. Вот минимальный набор мер:

Технические меры защиты

  • Шифрование данных в покое (at rest). Храните базу данных с собранными данными в зашифрованном виде. Используйте AES-256 или аналогичные стандарты. Облачные провайдеры (AWS, Google Cloud, Azure) предлагают автоматическое шифрование дисков.
  • Шифрование данных в движении (in transit). Все запросы к API, базам данных и прокси должны идти по HTTPS/TLS. Никогда не передавайте персональные данные по незашифрованным каналам.
  • Контроль доступа. Ограничьте доступ к базе данных: только авторизованные сотрудники должны видеть собранные данные. Используйте role-based access control (RBAC) и логируйте все обращения к данным.
  • Регулярные бэкапы. Делайте резервные копии, но храните их так же безопасно, как основные данные. Зашифрованные бэкапы, доступ по двухфакторной аутентификации.
  • Мониторинг и аудит. Настройте систему мониторинга для выявления подозрительной активности (например, массовая выгрузка данных). Регулярно проводите аудит безопасности.

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

  • Политика конфиденциальности. Создайте внутренний документ, описывающий как вы собираете, храните и используете данные. Это основа для compliance.
  • Обучение персонала. Все сотрудники, имеющие доступ к данным, должны понимать требования GDPR и последствия нарушений.
  • Назначение DPO (Data Protection Officer). Если ваша основная деятельность — регулярный и систематический мониторинг субъектов данных в больших масштабах, GDPR требует назначить ответственного за защиту данных.
  • План реагирования на утечки. Подготовьте процедуру на случай data breach. GDPR требует уведомить регулятора в течение 72 часов после обнаружения утечки.

Чек-лист безопасности хранения данных:

  • ✅ База данных зашифрована (AES-256 или выше)
  • ✅ Доступ по паролю + 2FA для всех пользователей
  • ✅ Логирование всех обращений к данным
  • ✅ Регулярные бэкапы (зашифрованные, в отдельном хранилище)
  • ✅ Автоматическое удаление данных старше N дней
  • ✅ Firewall и защита от SQL-инъекций
  • ✅ Регулярные обновления ПО и патчи безопасности

Как обрабатывать запросы на удаление данных

GDPR даёт субъектам данных (людям, чьи данные вы собрали) ряд прав. Для веб-скрейпинга наиболее актуальны:

  • Право на доступ (Right to Access). Пользователь может запросить копию всех данных, которые вы о нём храните. Вы обязаны предоставить их в течение 30 дней.
  • Право на удаление (Right to Erasure / "Right to be Forgotten"). Пользователь может потребовать удалить все его данные. Вы обязаны выполнить запрос, если нет законных оснований для хранения.
  • Право на исправление (Right to Rectification). Если данные неточны, пользователь может потребовать их исправить.
  • Право на ограничение обработки (Right to Restriction). Временная заморозка обработки данных до разрешения спора.

Проблема при скрейпинге: вы часто не знаете, чьи данные собрали. Пользователи не регистрировались у вас, не давали email для связи. Как они могут отправить запрос? Как вы их идентифицируете?

Практические решения

1. Создайте публичную форму для запросов. Разместите на своём сайте страницу "GDPR Data Subject Requests" с формой, где пользователь может указать свой email, описать какие данные хочет удалить/получить. Укажите, что вы ответите в течение 30 дней.

2. Верифицируйте запросы. Убедитесь, что запрос пришёл от реального владельца данных. Попросите подтверждение (например, отправьте код на email, который пользователь указал как свой). Это защитит от фальшивых запросов.

3. Автоматизируйте удаление. Создайте скрипт, который по email или другому идентификатору удаляет все связанные данные из базы. Важно: удаление должно быть полным — из основной базы, бэкапов, логов.

# Пример скрипта удаления данных по email
def delete_user_data(email):
    # Удаление из основной базы
    db.execute("DELETE FROM scraped_contacts WHERE email = ?", (email,))
    
    # Удаление из логов (если храните)
    db.execute("DELETE FROM activity_logs WHERE user_email = ?", (email,))
    
    # Пометка в бэкапах (если нельзя удалить немедленно)
    db.execute("INSERT INTO deletion_queue (email, requested_at) VALUES (?, NOW())", (email,))
    
    # Логирование запроса на удаление (для compliance)
    log_gdpr_request('deletion', email)
    
    return "Data deleted successfully"

4. Документируйте все запросы. Ведите журнал всех GDPR-запросов: кто запросил, когда, что было сделано. Это понадобится при проверке регулятором.

5. Отвечайте в срок. У вас есть 30 дней на ответ (можно продлить до 60 в сложных случаях, но нужно уведомить заявителя). Пропуск дедлайна — нарушение GDPR.

Важно: Если вы не можете идентифицировать пользователя в своей базе (например, вы собирали только агрегированные данные без email), вы имеете право отказать в запросе. Но это нужно обосновать: "Мы не храним персональные данные, позволяющие вас идентифицировать". Это ещё один аргумент в пользу минимизации данных.

Практический чек-лист GDPR-compliance для скрейпинга

Используйте этот чек-лист перед запуском любого проекта веб-скрейпинга, связанного с персональными данными граждан ЕС:

Этап 1: Планирование

  • ☐ Определите, содержат ли собираемые данные персональную информацию (ФИО, email, IP, телефоны и т.д.)
  • ☐ Если да — определите законное основание для сбора (чаще всего: legitimate interests)
  • ☐ Проведите тест на балансировку интересов (LIA) и задокументируйте результат
  • ☐ Определите минимальный набор данных, необходимый для вашей цели
  • ☐ Установите срок хранения данных (например, 30 дней)

Этап 2: Настройка инфраструктуры

  • ☐ Выберите провайдера прокси с no-log политикой или готовностью подписать DPA
  • ☐ Настройте шифрование базы данных (AES-256)
  • ☐ Настройте контроль доступа (RBAC) к собранным данным
  • ☐ Включите логирование всех обращений к данным
  • ☐ Настройте автоматическое удаление данных старше установленного срока
  • ☐ Настройте зашифрованные бэкапы

Этап 3: Разработка скрейпера

  • ☐ Реализуйте фильтрацию данных на этапе сбора (не сохраняйте лишние поля)
  • ☐ Используйте псевдонимизацию или анонимизацию, где возможно
  • ☐ Не собирайте специальные категории данных (раса, здоровье, религия и т.д.)
  • ☐ Используйте HTTPS для всех запросов
  • ☐ Настройте ротацию IP через прокси для минимизации следов

Этап 4: Документация

  • ☐ Создайте Data Processing Record: какие данные, для чего, на каком основании, как долго храните
  • ☐ Подготовьте Privacy Policy (политику конфиденциальности) для вашего сайта
  • ☐ Если используете подрядчиков (провайдер прокси, облачное хранилище) — подпишите DPA
  • ☐ Создайте план реагирования на data breach

Этап 5: Обработка запросов субъектов данных

  • ☐ Создайте публичную форму для GDPR-запросов на вашем сайте
  • ☐ Настройте процесс верификации запросов
  • ☐ Автоматизируйте удаление данных по запросу
  • ☐ Ведите журнал всех GDPR-запросов
  • ☐ Отвечайте на запросы в течение 30 дней

Этап 6: Мониторинг и аудит

  • ☐ Регулярно проверяйте, какие данные фактически собираются (могут появиться новые поля)
  • ☐ Проводите аудит безопасности хранилища данных (раз в квартал/полгода)
  • ☐ Обучайте сотрудников требованиям GDPR
  • ☐ Следите за обновлениями законодательства и судебной практики

Рекомендация по типу прокси:

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

Заключение

GDPR-compliance при веб-скрейпинге — это не препятствие для бизнеса, а набор правил, которые защищают и вас, и пользователей. Ключевые принципы: собирайте только необходимые данные, обосновывайте законное основание, защищайте собранную информацию и будьте готовы удалить данные по запросу. Штрафы за нарушения достигают €20 миллионов, но их можно полностью избежать, следуя описанным в статье практикам.

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

Если вы планируете масштабный веб-скрейпинг с обработкой персональных данных граждан ЕС, рекомендуем проконсультироваться с юристом, специализирующимся на GDPR. Инвестиции в compliance на старте проекта обходятся в разы дешевле, чем штрафы и репутационные потери при нарушении.

Для безопасного и анонимного веб-скрейпинга рекомендуем использовать резидентные прокси — они обеспечивают высокий уровень анонимности, минимизируют риск блокировок и помогают соблюдать принципы минимизации данных. Выбирайте провайдеров с прозрачной политикой конфиденциальности и готовностью подписать Data Processing Agreement.