Деперсонализация данных на Битрикс
Все слышали о 152 ФЗ и о санкциях за его несоблюдение, однако подавляющее большинство российских организаций его не соблюдают. Как минимум в предписанном объеме работ, которые должны быть осуществлены любым оператором персональных данных. И это касается не только зарегистрированных операторов персональных данных, но и других лиц, которые непосредственно работают с данными пользователей.
Чтобы стать оператором персональных данных, достаточно записать номер телефона пользователя — в этом случае компания обязана выполнять требования ФЗ № 152 «О персональных данных». За соблюдением закона следит Роскомнадзор, он же штрафует за нарушения — для юрлиц штрафы могут достигать 500 000 ₽.
Пока не было прецендентов наказания за неисполнение 152 ФЗ для средних и мелких организаций и большинство из них нарушает закон надеясь, что Роскомнадзор на них не обратит внимания. Но ситуация может изменится в любой момент, а это значит, что те процедуры которые так долго избегают операторы персональных данных все равно придется исполнять и лучше начать работы уже сейчас т.к. кроме большого штрафа можно надолго парализовать собственную работу.
Что касается 152 ФЗ, то есть и хорошая новость: степень инфраструктурных издержек прямо пропорциональна того типа данных с которыми вы работаете. Всего типов 4 (специальные, биометрические, иные, общедоступные). И возможно тот тип, с которым вы работаете, требует меньший уровень защищенности. Самую серьёзную защиту по обработке и хранению требует данные входящие в первую группу и соответствуют уровню защищенности УЗ-1. К этой группе относятся данные содержащие информацию о пользователе относящуюся к расе, национальности и религии, политических и философских взглядах, здоровье, подробностях личной жизни, судимостях.
Например интернет-магазин чаще всего хранит и обрабатывает персональную информацию относящуюся к УЗ-3, а именно: ФИО, номер телефона, электронная почта. А медицинская компания оперирует данными УЗ-1 относящуюся к здоровью пользователя.
Коммерческие компании решают этот вопросы по разному: кто-то выстраивает инфраструктуру в соответствии со 152 ФЗ, кто-то отдает обработку персональных данных в специализированные сервисы обработки и хранения персональных данных. Например некоторые частные медицинские компании выносят обработку медицинских данных своих пациентов в специализированное Saas-решение Инфоклиника.RU, тем самым сведя все издержки только на оплату данного сервиса. Другие используют проверку личности своих клиентов в Sumsub, полностью избавляясь как от обработки персональных данных, так и ее хранения. Точнее в данном случае следует уменьшение с УЗ-2 – биометрические данные (фотография паспорта) на УЗ-3 - иные данные т.к. паспорт обрабатывался на стороннем сервисе и с этого сервиса пришел ответ «соответствует» и хранится это значение.
Что делать, если для вашей работы требуется хранить и обрабатывать данные относящиеся к специальным и/или биометрическим, а выстраивать инфраструктуру под это (юридическую, техническую, организационную) у вас не хватает ресурсов? Можно пойти на временное решение и воспользоваться юридической лазейкой – деперсонализировать данные. Т.е. обрабатывать информацию таким образом, чтобы никто из персонала не мог идентифицировать пользователя, а сами данные о пользователе и его данных относящихся к УЗ-2 или УЗ-1 хранить обезличено в другом месте. Например пользователь при регистрации вводит свое ФИО полностью, но сотрудники вашей организации обрабатывая данные пользователя и коммуницируя с ним видят только имя, отчество и первую букву фамилии данного пользователя – Иван Иванович И. вместо Ивана Ивановича Иванова. Диагноз Ивана Ивановича И., который видит вам сотрудник нельзя отнести к специальным медицинским данным т.к. указанный диагноз не связан с конкретным человеком при обработке данных сотрудником. Что касается хранения пользовательской информации, то здесь нужно разнести две базы данных: с общей информацией о пользователе (тип Иная) хранить отдельно от медицинской информации (тип Специальная) и связывать их только по id пользователя в системе. И конечно медицинскую информацию нужно зашифровать и защитить дополнительно сертифицированным программным СКЗИ.
ВНИМАНИЕ: данное решение будет действовать до тех пор пока есть юридическая лазейка в законе.
Наши клиенты
Виктор Николаевич Т.
Здравствуйте! Можно ли в Битрикс сделать кнопку “Удалить мои данные” в личном кабинете, чтобы пользователь сам мог инициировать удаление или обезличивание? Как это реализовать, чтобы нельзя было удалить чужие данные и не сломать сайт?
Студия Фонарь
Здравствуйте, Виктор Николаевич! Такую кнопку можно сделать: в личном кабинете добавляем форму “Запрос на удаление/обезличивание”, которая создаёт задачу администратору или сразу запускает безопасный скрипт очистки. Проверка прав: скрипт проверяет, что user_id из сессии совпадает с запрашиваемым. В CMS логику размещаем в отдельном компоненте, а не в шаблонах, чтобы не затронуть ядро. Если скажете, какие данные у вас есть (заказы, отзывы, подписки), покажем, в каком порядке и какие таблицы/инфоблоки нужно очищать и как логировать такие запросы.
Павел Ю.
У нас много форм на сайте: заказ звонка, заявка на расчёт, подписка, обратная связь. Хочется единый механизм: пользователь один раз даёт согласие, и оно применяется ко всем формам. Как это грамотно сделать в CMS и где хранить флаг согласия, чтобы это было надёжно и проверяемо?
Студия Фонарь
Здравствуйте, Павел! Флаг согласия лучше хранить в отдельном инфоблоке “Согласия” с полями: user_id/cookie_id, дата, тип согласия, источник. При отправке любой формы проверяем наличие актуального согласия и, если его нет, показываем модальное окно. В CMS это удобно реализовать через общий JS‑модуль и PHP‑сервис, который вызывается из всех форм. Чтобы не дублировать код, делаем один компонент “баннер согласия” и подключаем его в header. Если скажете, сколько у вас форм и какие типы согласий нужны (рассылка, обработка, куки), покажем структуру инфоблока и пример кода проверки.
Павел Ю.
Благодарю! Я так понял, что без программиста не реализовать...
Марина И.
Хотим сделать на сайте форму заявки на консультацию, где пользователь вводит телефон и выбирает удобное время. Как технически в Битриксе сделать так, чтобы телефон не хранился в публичной части и был доступен только менеджеру в админке, причём только по запросу?
Студия Фонарь
Здравствуйте, Марина! Можно реализовать так: в публичной части форма собирает данные и сохраняет в инфоблок со статусом “на проверке”, а поле телефона по умолчанию скрыто для всех. В админке показываем телефон только пользователям из группы “Менеджеры” через проверку прав в шаблоне компонента. Дополнительно можно добавить подтверждение по SMS/коду: телефон появляется только после ввода кода. Если скажете, какая у вас структура прав и какие компоненты форм используются, подскажем, где разместить проверку и как не сломать кэширование списка заявок.
Дмитрий Андреевич
У нас корпоративный сайт с формой обратной связи и подпиской на рассылку. Там просят имя и email. Можно ли вообще не хранить эти данные на сайте, а сразу передавать в CRM и тут же удалять из Битрикса? Как это сделать технически в CMS, чтобы не было следов?
Студия Фонарь
Дмитрий Андреевич, здравствуйте! Технически в битрикс это делается так: форма отправляет данные через AJAX в обработчик, который сразу пишет в CRM (через API) и не сохраняет в инфоблок. Если нужно логировать факт отправки для техподдержки, пишем только обезличенный лог: время, IP, код формы, статус. В коде это реализуется в result_modifier.php или отдельном компоненте без правки ядра. Если пришлёте структуру вашей формы и CRM, покажем пример безопасного обработчика и как настроить права доступа к логам.