Как защитить персональные данные пользователей интернет-ресурса

Если сайт собирает имя, телефон, e-mail, cookie, данные из форм обратной связи или любую другую информацию, по которой можно прямо или косвенно идентифицировать человека, он уже работает с персональными данными и должен соблюдать требования 152-ФЗ. Для владельца интернет-ресурса это не формальность: ошибки в обработке ПДн быстро превращаются в претензии пользователей, риски блокировок и штрафы. Причём блокировка может прилететь не только за спорный контент, но и за грубые нарушения правил обработки данных — Роскомнадзор умеет включать ресурсы в реестр запрещённых сайтов и по этой причине.

Что считается персональными данными на сайте

Под персональными данными понимают любую информацию, которая помогает определить конкретного человека напрямую или через совокупность признаков. На практике это не только ФИО и паспортные данные. Судебная практика и разъяснения регулятора давно расширили толкование: всё, что может быть сопоставлено с конкретным пользователем, становится объектом защиты.

К персональным данным на сайте обычно относятся:

• имя и фамилия;
• номер телефона;
• e-mail;
• адрес доставки;
• IP-адрес в связке с другими данными;
• cookie и идентификаторы браузера, если они позволяют выделить пользователя;
• сообщения из формы обратной связи;
• комментарии, заявки, анкеты, подписки.

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

Кто несёт ответственность

Ответственным лицом считается оператор персональных данных — обычно это владелец сайта, ИП или компания, которая определяет цели и способы обработки ПДн. Неважно, маленький это лендинг, интернет-магазин или медиа с комментариями: если данные собираются, оператор обязан обеспечить их защиту. В моей практике был случай, когда владелец одностраничного сайта искренне удивлялся претензии: «У меня даже базы нет, просто заявки на почту приходят». Но именно эти письма, хранящиеся на стороннем почтовом сервере без контроля доступа, уже образуют обработку, за которую отвечает оператор.

Типичная ошибка — считать, что «сайт маленький, нас это не касается». На практике именно небольшие проекты часто нарушают правила: ставят формы без политики конфиденциальности, не ограничивают доступ к базе, используют сторонние плагины без проверки передачи данных. А потом удивляются, когда хостинг-провайдер по требованию Роскомнадзора блокирует аккаунт.

Базовые требования закона, которые нельзя игнорировать

Для сайта в России минимум выглядит так:

• нужно законно собирать и обрабатывать данные, а цели обработки должны быть понятны пользователю;
• на сайте должна быть политика конфиденциальности или политика обработки персональных данных в открытом доступе;
• согласие пользователя должно быть получено там, где оно требуется, и не должно быть «спрятано» в нечитабельных условиях;
• обработка должна быть ограничена заявленными целями, нельзя собирать лишнее «на всякий случай»;
• необходимо обеспечивать защиту данных от утечки, изменения, удаления и несанкционированного доступа;
• при работе с ПДн граждан РФ важно соблюдать требования о хранении и систематизации данных на территории России;
• в большинстве случаев требуется уведомить Роскомнадзор о начале обработки персональных данных (исключения перечислены в ч. 2 ст. 22 152-ФЗ, но они не так широки, как кажется).

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

Что нужно сделать на практике

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

1. Провести инвентаризацию данных

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

Проверьте:

• формы заявки, заказа, подписки;
• онлайн-чат;
• личный кабинет;
• комментарии;
• cookie и пиксели аналитики;
• интеграции с CRM, e-mail-рассылками, коллтрекингом, мессенджерами;
• резервные копии и логи сервера.

Полезный вопрос: «Если завтра пользователь запросит удаление своих данных, мы вообще знаем, где они лежат?» Если ответа нет, защита не выстроена. По опыту, именно бэкапы и логи становятся слепой зоной: о них забывают, а при компрометации сервера они утекают вместе с актуальной базой.

2. Определить законные цели обработки

Нельзя писать абстрактно: «для улучшения сервиса». Цели должны быть конкретными и проверяемыми. Роскомнадзор при проверке будет смотреть, соответствуют ли фактически собираемые данные заявленным целям, и если вы просите дату рождения «для улучшения сервиса», а на деле используете её для таргетинга рекламы, это прямое нарушение.

Хорошие формулировки:

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

Плохие формулировки:

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

3. Подготовить документы

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

Минимальный пакет:

• политика обработки персональных данных;
• согласие на обработку ПДн;
• уведомление о cookie, если используются трекеры;
• регламент хранения и удаления данных внутри компании;
• порядок обработки запросов субъектов ПДн.

Если на сайте есть корзина, оплата, реклама, аналитика и рассылка, одного шаблона политики обычно недостаточно — документ нужно адаптировать под реальные процессы. Лучше потратить время на аудит и составление документов вместе с юристом, понимающим IT-специфику, чем потом объяснять регулятору, почему в политике написано одно, а по факту — другое.

4. Разместить политику и согласия в доступном месте

Документы должны быть легко доступны до отправки формы. Пользователь не должен искать их в футере три клика или пролистывать десять экранов. Это не только требование закона, но и вопрос доверия: если согласие запрятано, посетитель вправе заподозрить недобросовестность.

Лучший вариант:

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

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

5. Ограничить сбор лишних данных

Чем меньше данных собирается, тем ниже риск утечки и тем проще соблюдать закон. Это не просто рекомендация, а принцип минимизации, заложенный в 152-ФЗ.

Принцип простой:

• если для ответа на заявку нужен телефон и e-mail, не просите дату рождения и адрес;
• если доставка не нужна, не собирайте адрес;
• если не требуется идентификация, не просите паспорт.

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

Техническая защита: что должно быть настроено

Юридические документы сами по себе не спасают. Если база данных открыта, пароль слабый, а доступ к админке есть у всех подряд, защита формальна. Техническая и правовая стороны должны работать в связке: политика описывает, что вы делаете, а настройки сервера и кода подтверждают, что это действительно выполняется.

Обязательный технический минимум

• HTTPS для всего сайта, а не только для формы;
• сложные уникальные пароли и двухфакторная аутентификация для админки;
• ограничение прав доступа по ролям;
• регулярное обновление CMS, плагинов и серверного ПО;
• резервное копирование с отдельным доступом;
• журналирование действий в админ-панели;
• антивирусная защита и контроль уязвимостей;
• шифрование хранимых данных, если это возможно по архитектуре;
• защита от брутфорса, SQL-инъекций, XSS и CSRF.

Таблица: что защищать и как

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

Cookie, аналитика и трекеры: частая зона риска

Многие владельцы сайтов считают cookie «технической мелочью», но в реальности именно они часто становятся спорной зоной. Если cookie используются для идентификации, аналитики, рекламного профилирования или связки действий пользователя с его аккаунтом, их нужно учитывать в политике и уведомлениях. Регулятор обращает на это внимание: были случаи, когда сайты получали предписания из-за отсутствия информации об использовании файлов cookie, даже если сами данные не покидали пределов РФ.

Что стоит проверить:

• какие cookie используются;
• какие из них обязательные, а какие аналитические и рекламные;
• какие сторонние сервисы получают данные;
• есть ли баннер или уведомление о cookie;
• можно ли отказаться от необязательных трекеров.

Технически важно, чтобы отказ от необязательных cookie действительно прекращал их установку, а не просто скрывал баннер. Иначе это введение в заблуждение.

Передача данных третьим лицам

Если сайт передаёт данные в CRM, e-mail-сервисы, доставку, платёжные системы, коллтрекинг или облачную аналитику, это нужно отражать в документах и договорах. Пользователь должен понимать, кому и зачем уходят его данные. Причём согласие на передачу должно быть отдельным, если это не необходимо для исполнения договора.

Особое внимание стоит уделить подрядчикам:

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

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

Хранение данных в России

Для данных граждан РФ действует требование о локализации: запись, систематизация и хранение должны вестись в базах, расположенных на территории России. На практике это означает, что серверы и базы данных нельзя выбирать «по удобству», не проверив правовой режим и инфраструктуру. Роскомнадзор активно проверяет соблюдение этого требования, и блокировка ресурса за отказ перенести данные в РФ — не миф, а рабочая процедура.

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

Как выстроить защиту по этапам

Пошаговый план

1. Составить список всех точек сбора данных.
2. Определить, какие данные действительно нужны.
3. Подготовить политику, согласия и уведомления.
4. Настроить хранение данных в российской инфраструктуре, если это требуется.
5. Закрыть доступ к админке и базе.
6. Обновить CMS, плагины и серверное ПО.
7. Проверить подрядчиков и интеграции.
8. Настроить резервное копирование и журналирование.
9. Назначить ответственного за обработку ПДн.
10. Регулярно проводить внутреннюю проверку.

Этот план — не единовременная акция, а цикл. После каждого обновления сайта или добавления нового сервиса стоит возвращаться к пункту 1.

Чек-лист для владельца сайта

• На сайте есть политика обработки персональных данных.
• Согласия на обработку данных оформлены корректно.
• Формы не собирают лишнюю информацию.
• Cookie и аналитика отражены в документах.
• База данных и сервер находятся в подходящей инфраструктуре.
• Доступы к админке ограничены.
• Используется HTTPS.
• Сайт и плагины обновляются.
• Есть резервные копии.
• Подрядчики и сервисы проверены на передачу данных.
• У компании есть порядок работы с запросами пользователей.

Типовые ошибки

• Собирать данные без понятной цели.
• Прятать согласие в длинном пользовательском соглашении.
• Использовать старые шаблоны политики без адаптации под сайт.
• Хранить все данные «в одной таблице».
• Давать полный доступ подрядчикам и подрядным агентствам.
• Игнорировать cookie и сторонние скрипты.
• Не обновлять CMS и плагины.
• Считать, что утечка с бэкапа — это не утечка.

К этому списку я бы добавил ещё одну распространённую ошибку: надеяться, что «пронесёт». Малый бизнес часто откладывает защиту данных до первого инцидента, но после утечки или блокировки восстановить репутацию гораздо сложнее и дороже, чем настроить всё сразу.

Когда нужен отдельный аудит

Отдельная проверка нужна, если:

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

Аудит желательно проводить силами специалистов, которые понимают и правовые, и технические аспекты. Чисто юридическая проверка может не заметить уязвимость в плагине, а чисто техническая — проигнорировать отсутствие нужных формулировок в политике. Именно на стыке этих двух зон чаще всего и возникают проблемы.

Вывод

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

FAQ

Нужно ли собирать согласие на обработку персональных данных?

Да, если для конкретного сценария обработки оно требуется. Согласие должно быть понятным, конкретным и не спрятанным в мелком тексте. Например, для отправки информационной рассылки согласие обязательно, а для обработки данных в рамках договора купли-продажи оно может не требоваться, но тогда это нужно чётко прописать в политике.

Достаточно ли просто разместить политику конфиденциальности?

Нет. Политика — это только один элемент. Нужны ещё техническая защита, ограничение доступа, корректная работа с подрядчиками и контроль хранения данных. Более того, наличие политики без реальных мер защиты может быть отягчающим обстоятельством при разбирательстве: оператор знал требования, но не выполнил их.

Считаются ли cookie персональными данными?

Могут считаться, если по ним можно идентифицировать пользователя или связать его действия с конкретным человеком. Например, идентификатор сессии, который позволяет восстановить корзину товаров, в сочетании с IP-адресом и историей просмотров часто признаётся персональными данными. Поэтому лучше по умолчанию относить все необязательные cookie к ПДн и получать согласие.

Можно ли хранить данные пользователей на зарубежном сервере?

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

Что делать, если сайт уже собирает данные, но документы не готовы?

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