Статьи

Статьи

Деперсонализация данных на Битрикс

Деперсонализация данных на Битрикс

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

Чтобы стать оператором персональных данных, достаточно записать номер телефона пользователя — в этом случае компания обязана выполнять требования ФЗ № 152 «О персональных данных». За соблюдением закона следит Роскомнадзор, он же штрафует за нарушения — для юрлиц штрафы могут достигать 500 000 ₽.

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

Что касается 152 ФЗ, то есть и хорошая новость: степень инфраструктурных издержек прямо пропорциональна того типа данных с которыми вы работаете. Всего типов 4 (специальные, биометрические, иные, общедоступные). И возможно тот тип, с которым вы работаете, требует меньший уровень защищенности. Самую серьёзную защиту по обработке и хранению требует данные входящие в первую группу и соответствуют уровню защищенности УЗ-1. К этой группе относятся данные содержащие информацию о пользователе относящуюся к расе, национальности и религии, политических и философских взглядах, здоровье, подробностях личной жизни, судимостях.

Например интернет-магазин чаще всего хранит и обрабатывает персональную информацию относящуюся к УЗ-3, а именно: ФИО, номер телефона, электронная почта. А медицинская компания оперирует данными УЗ-1 относящуюся к здоровью пользователя.

Коммерческие компании решают этот вопросы по разному: кто-то выстраивает инфраструктуру в соответствии со 152 ФЗ, кто-то  отдает обработку персональных данных в специализированные сервисы обработки и хранения персональных данных. Например некоторые частные медицинские компании выносят обработку медицинских данных своих пациентов в специализированное Saas-решение  Инфоклиника.RU, тем самым сведя все издержки только на оплату данного сервиса. Другие используют проверку личности своих клиентов  в Sumsub, полностью избавляясь как от обработки персональных данных, так и ее хранения. Точнее в данном случае следует уменьшение с УЗ-2 – биометрические данные (фотография паспорта) на УЗ-3 - иные данные т.к. паспорт обрабатывался на стороннем сервисе и с этого сервиса пришел ответ «соответствует» и хранится это значение.

Что делать, если для вашей работы требуется хранить и обрабатывать данные относящиеся к специальным и/или биометрическим, а выстраивать инфраструктуру под это (юридическую, техническую, организационную) у вас не хватает ресурсов? Можно пойти на временное решение и воспользоваться юридической лазейкой – деперсонализировать данные. Т.е. обрабатывать информацию таким образом, чтобы никто из персонала не мог идентифицировать пользователя, а сами данные о пользователе и его данных относящихся к УЗ-2 или УЗ-1 хранить обезличено в другом месте. Например пользователь при регистрации вводит свое ФИО полностью, но сотрудники вашей организации обрабатывая данные пользователя и коммуницируя с ним видят только имя, отчество и первую букву фамилии данного пользователя – Иван Иванович И. вместо Ивана Ивановича Иванова. Диагноз Ивана Ивановича И., который видит вам сотрудник нельзя отнести к специальным медицинским данным  т.к. указанный диагноз не связан с конкретным человеком при обработке данных сотрудником. Что касается хранения пользовательской информации, то здесь нужно разнести две базы данных: с общей информацией о пользователе (тип Иная) хранить отдельно от медицинской информации (тип Специальная) и связывать их только по id пользователя в системе. И конечно медицинскую информацию нужно зашифровать и защитить дополнительно сертифицированным программным СКЗИ.

ВНИМАНИЕ: данное решение будет действовать до тех пор пока есть юридическая лазейка в законе.

 


К списку статей



Комментарии (17)

Анастасия П.

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

Студия Фонарь
Ответ на комментарий Анастасия П.

Анастасия, добрый день! Реализация через форму поиска по email (с капчей или подтверждением кодом) и списком согласий с кнопкой “Отозвать”. Отзыв фиксируем новой записью в инфоблоке согласий (статус “отозвано”, дата, причина). В битрикс важно не отдавать лишние данные: показываем только тип согласия и дату, без внутренних ID. Если скажете, какие типы согласий у вас есть и как устроена авторизация, покажем структуру и пример кода компонента, который можно безопасно внедрить в публичную часть.

Сергей Владимирович

Мы хотим дать пользователям возможность скачать архив своих данных (выгрузку по 152‑ФЗ). Как в битрикс технически реализовать выгрузку в безопасном формате (например pdf) и ограничить доступ, чтобы пользователь мог скачать только свои данные?

Студия Фонарь
Ответ на комментарий Сергей Владимирович

Здравствуйте! Выгрузку делаем как отдельный компонент в личном кабинете: при запросе проверяем user_id сессии, собираем данные (заказы, подписки, обращения) в PDF и отдаём файл. Чтобы не хранить готовые архивы, генерируем на лету. В битрикс используем CFile::MakeFileArray и стандартные методы формирования PDF/JSON. Если скажете, какие типы данных нужно включать в архив и какой формат предпочтительнее, покажем пример компонента и как защитить ссылку на скачивание.

Константин

У нас сайт с личным кабинетом и историей заказов. Думаем по истечении 3 лет автоматически обезличивать старые заказы: убирать имя, телефон, адрес, оставлять только сумму, дату и состав. Как это автоматизировать в Битрикс и как протестировать, чтобы случайно не удалить нужное?

Студия Фонарь
Ответ на комментарий Константин

Константин, здравствуйте! Автоматизацию делаем через агент: раз в сутки он ищет заказы старше 3 лет, проверяет статус и заменяет персональные поля на обезличенные значения. Перед запуском обязательно тестируем на копии и делаем бэкап. В Битрикс агент пишем как отдельный PHP файл в /local/php_interface/agents.php и регистрируем через API. Если скажете, в каком инфоблоке у вас хранятся заказы и какие поля нужно обезличить, покажем готовый код агента и чек‑лист проверки.

Юлия Михайловна

Мы передаём данные в колл‑центр и службу доставки. Как правильно в CMS оформить передачу третьим лицам, чтобы у нас был юридически значимый след: кто, когда и что передал, и можно ли автоматизировать фиксацию таких событий?

Студия Фонарь
Ответ на комментарий Юлия Михайловна

Здравствуйте, Юлия Михайловна! Фиксацию делаем через отдельный инфоблок “Журнал передачи ПДн” с полями: получатель, тип данных, дата, комментарий, ID исходного элемента. При каждой передаче скрипт создаёт запись в этом журнале. Для юридической значимости добавляем подпись/токен или хотя бы IP и логин оператора. В CMS это реализуем в обработчике экспорта/API. Если скажете, кому и какие данные вы передаёте (колл‑центр, доставка, CRM), покажем структуру журнала и пример кода, который можно вставить в ваш существующий модуль.

Виктор Николаевич Т.

Здравствуйте! Можно ли в Битрикс сделать кнопку “Удалить мои данные” в личном кабинете, чтобы пользователь сам мог инициировать удаление или обезличивание? Как это реализовать, чтобы нельзя было удалить чужие данные и не сломать сайт?

Студия Фонарь
Ответ на комментарий Виктор Николаевич Т.

Здравствуйте, Виктор Николаевич! Такую кнопку можно сделать: в личном кабинете добавляем форму “Запрос на удаление/обезличивание”, которая создаёт задачу администратору или сразу запускает безопасный скрипт очистки. Проверка прав: скрипт проверяет, что user_id из сессии совпадает с запрашиваемым. В CMS логику размещаем в отдельном компоненте, а не в шаблонах, чтобы не затронуть ядро. Если скажете, какие данные у вас есть (заказы, отзывы, подписки), покажем, в каком порядке и какие таблицы/инфоблоки нужно очищать и как логировать такие запросы.

Павел Ю.

У нас много форм на сайте: заказ звонка, заявка на расчёт, подписка, обратная связь. Хочется единый механизм: пользователь один раз даёт согласие, и оно применяется ко всем формам. Как это грамотно сделать в CMS и где хранить флаг согласия, чтобы это было надёжно и проверяемо?

Студия Фонарь
Ответ на комментарий Павел Ю.

Здравствуйте, Павел! Флаг согласия лучше хранить в отдельном инфоблоке “Согласия” с полями: user_id/cookie_id, дата, тип согласия, источник. При отправке любой формы проверяем наличие актуального согласия и, если его нет, показываем модальное окно. В CMS это удобно реализовать через общий JS‑модуль и PHP‑сервис, который вызывается из всех форм. Чтобы не дублировать код, делаем один компонент “баннер согласия” и подключаем его в header. Если скажете, сколько у вас форм и какие типы согласий нужны (рассылка, обработка, куки), покажем структуру инфоблока и пример кода проверки.

Павел Ю.
Ответ на комментарий Студия Фонарь

Благодарю! Я так понял, что без программиста не реализовать...

Марина И.

Хотим сделать на сайте форму заявки на консультацию, где пользователь вводит телефон и выбирает удобное время. Как технически в Битриксе сделать так, чтобы телефон не хранился в публичной части и был доступен только менеджеру в админке, причём только по запросу?

Студия Фонарь
Ответ на комментарий Марина И.

Здравствуйте, Марина! Можно реализовать так: в публичной части форма собирает данные и сохраняет в инфоблок со статусом “на проверке”, а поле телефона по умолчанию скрыто для всех. В админке показываем телефон только пользователям из группы “Менеджеры” через проверку прав в шаблоне компонента. Дополнительно можно добавить подтверждение по SMS/коду: телефон появляется только после ввода кода. Если скажете, какая у вас структура прав и какие компоненты форм используются, подскажем, где разместить проверку и как не сломать кэширование списка заявок.

Дмитрий Андреевич

У нас корпоративный сайт с формой обратной связи и подпиской на рассылку. Там просят имя и email. Можно ли вообще не хранить эти данные на сайте, а сразу передавать в CRM и тут же удалять из Битрикса? Как это сделать технически в CMS, чтобы не было следов?

Студия Фонарь
Ответ на комментарий Дмитрий Андреевич

Дмитрий Андреевич, здравствуйте! Технически в битрикс это делается так: форма отправляет данные через AJAX в обработчик, который сразу пишет в CRM (через API) и не сохраняет в инфоблок. Если нужно логировать факт отправки для техподдержки, пишем только обезличенный лог: время, IP, код формы, статус. В коде это реализуется в result_modifier.php или отдельном компоненте без правки ядра. Если пришлёте структуру вашей формы и CRM, покажем пример безопасного обработчика и как настроить права доступа к логам.

Наши клиенты

 

© Студия Фонарь, 2009-2026.
info@fonarstudio.ru