Защита персональных данных на сайте строится на четырёх опорах: корректный сбор согласия, шифрование канала передачи, изолированное хранение резервных копий и разграничение доступа к базе. Минимальный технический уровень — HTTPS на всех страницах, где пользователь что-либо вводит. Юридический минимум — согласие, выраженное активным действием: пользователь сам ставит галочку, а не снимает уже проставленную. Ответственность за утечку в любом случае лежит на владельце сайта, а не на хостинг-провайдере, и это меняет логику принятия решений: делегировать инфраструктуру можно, делегировать ответственность — нет.
Какие данные вы собираете на самом деле
Персональные данные делятся на четыре категории, и большинство владельцев сайтов недооценивают две последние. Общие — ФИО, телефон, e-mail, адрес. Биометрические — фотографии для идентификации, отпечатки, слепок голоса. Специальные — сведения о здоровье, вероисповедании, судимости, национальности. Технические — IP-адрес, cookie, идентификаторы устройства, данные систем веб-аналитики.
Техническая категория коварна тем, что попадает на сайт без участия администратора: счётчик аналитики, пиксель рекламной сети, чат-виджет — каждый из них уже пишет идентификаторы. Часто, но не всегда, такие данные считаются обезличенными: как только IP связывается с профилем зарегистрированного пользователя, обезличивание перестаёт работать.
| Категория | Примеры на сайте | Где обычно собирается | Требование |
|---|---|---|---|
| Общие | ФИО, телефон, e-mail | Формы заявки, регистрация, оформление заказа | Согласие активным действием + политика обработки |
| Биометрические | Фото для верификации, скан лица | Личный кабинет, KYC-процедуры | Отдельное письменное согласие, повышенный уровень защиты |
| Специальные | Диагноз, данные о здоровье | Запись к врачу, анкеты, медицинские сервисы | Отдельное согласие, шифрование хранилища |
| Технические | IP, cookie, ID устройства | Счётчики аналитики, рекламные пиксели, виджеты | Cookie-баннер, HTTPS, уведомление о трекинге |
Согласие: где чаще всего рушится юридическая конструкция
Чекбокс, установленный по умолчанию, регулятор трактует как отсутствие согласия — а значит, вся собранная через такую форму база формально получена с нарушением. Молчание пользователя, продолжение просмотра страницы, «нажимая кнопку, вы соглашаетесь» без отдельного элемента управления — всё это слабые конструкции. Надёжный вариант один: пустой чекбокс, который пользователь отмечает сам, со ссылкой на политику обработки персональных данных рядом.
Согласие должно быть конкретным, информированным и сознательным. Если пользователь не может объяснить, на что именно он согласился, документ не работает — даже если галочка стоит.
Отдельный нюанс — цели обработки. Согласие на обработку для исполнения заказа не покрывает рассылку маркетинговых писем: это разные цели и в идеале разные чекбоксы. Обзоры практики и материалы по цифровым проектам можно найти, например, на https://reachproject.kz/.
Технический контур защиты
HTTPS — обязательный минимум. Без него логин, пароль и содержимое формы уходят по открытому каналу, и перехват возможен на любом промежуточном узле. Проверьте, что редирект с http на https стоит на уровне сервера, а не только в CMS, и что нет смешанного контента (скрипты и картинки, подгружаемые по http, ломают защиту страницы целиком).
Бэкапы хранятся отдельно от основного сервера — на другом физическом хосте или в отдельном хранилище с независимыми учётными данными. Резервная копия в соседней директории того же сервера защищает только от неудачного обновления; при компрометации хоста или шифровальщике она уничтожается вместе с боевой базой. Дампы БД желательно шифровать: незашифрованный SQL-дамп — это готовая к продаже база.
Дальше — разграничение прав. Учётная запись MySQL для сайта не должна иметь привилегий DROP и GRANT; администраторские панели закрываются двухфакторной аутентификацией и, если позволяет инфраструктура, ограничением по IP. Логи доступа хранят и просматривают: без них факт утечки обнаруживается уже по объявлению на форуме. На практике чаще срабатывает не изощрённый взлом, а связка «устаревший плагин + учётка с полными правами».
Типичные ошибки
- Предзаполненный чекбокс согласия. Регулятор считает такое согласие неполученным — обработка всей базы, собранной через форму, становится незаконной, а формы приходится переделывать задним числом.
- Бэкапы в папке /backup на том же сервере. При взломе или атаке шифровальщика злоумышленник получает и рабочую базу, и архив; восстанавливать оказывается нечего, а утёкший дамп содержит всю историю клиентов.
- Ставка на «хостинг всё защитит». Ответственность за утечку несёт владелец сайта — претензии пользователей и внимание регулятора придут к нему, а не к провайдеру, даже если дыра была в чужой инфраструктуре.
- Смешанный контент при формально включённом HTTPS. Часть ресурсов грузится по http, браузер помечает страницу как небезопасную, а передаваемые данные перестают быть защищёнными — сертификат есть, толку нет.
- Аналитика и виджеты без упоминания в политике. Cookie и идентификаторы устройства собираются сторонними скриптами, а в документе о них ни слова — расхождение между реальным сбором данных и заявленным всплывает при первой же проверке или жалобе.
- Одна общая админская учётка на всех. После ухода подрядчика или сотрудника доступ остаётся живым, а по логам невозможно установить, кто именно выгрузил базу.
