Крупные утечки персональных данных и как их избежать
Илья Шагаев
Основатель агентства DM Basis
Этот год богат на утечки данных: то скандальная утечка покупателей Яндекс.Еды, то попавшая в сеть база данных медицинской компании “Гемотест”, недавно пострадали клиенты и контрагенты СДЭК. В статье делюсь личным опытом CRM-маркетолога с большим стажем и "вредными и полезными" методами защиты данных.
Осознание масштаба ситуации приходит после небольшой сводки новостей 2022 года:
- 1 марта 2022 года в сеть попали данные 6.397 млн. пользователей сервиса Яндекс.Еда. По заявлению Яндекса в сеть телефоны клиентов и информация о заказах, утечка не коснулась банковских, платежных и регистрационных данных пользователей.
- 1 мая 2022 года в сети появились данные 31 млн. пользователей компании “Гемотест” сообщил Forbes.
- 20 мая 2022 года сервис доставки Delivery Club признал первую утечку данных, в июне вторую. А 18 августа за эти утечки сервис получил штраф в 80 тыс.рублей, известил Коммерсантъ.
- 13 июля 2022 года произошла утечка данных 25 млн. пользователей и 30 тысяч контрагентов логистической компании СДЭК, по сообщениям rbc.ru.
Ну утекли несколько миллионов записей. И что?
Основной регулятор сферы, Роскомнадзор, давно планирует повышение штрафов за неправомерную обработку персональных данных, в том числе за утечки. Сервис Яндекс.Еда был оштрафован на 100 тысяч рублей, для такого бизнеса это не великая “финансовая дубина”. Такими штрафами серьезный бизнес не испугать, а значит, штрафы будут расти. Десять лет назад, во времена моего участия в консультативном совете при Роскомнадзоре, РКН настаивал на вводе штрафов до полумиллиона рублей. Большие штрафы в то время уже практиковал ФАС, полмиллионом можно было поплатиться за рекламный спам, поэтому РКН есть на кого равняться.
Тогда я и ряд других участников консультативного совета выступали против повышения штрафов, ибо законодательство о персональных данных было молодым и несовершенным. Был существенный риск получить серьезную дубину для наказания “неугодного” бизнеса. Сейчас пора признать, что ситуация уже не так однозначна, и дубина в каком-то виде должна появиться.
Тогда я и ряд других участников консультативного совета выступали против повышения штрафов, ибо законодательство о персональных данных было молодым и несовершенным. Был существенный риск получить серьезную дубину для наказания “неугодного” бизнеса. Сейчас пора признать, что ситуация уже не так однозначна, и дубина в каком-то виде должна появиться.
Задача CRM-маркетологов — найти методы защиты данных, которые позволят балансировать между наказанием и невозможностью выстраивать персональную коммуникацию из-за жестких внутренних ограничений.
“Всё взять и запретить” — не наш метод. Поэтому поделюсь и “вредными” советамии полезными — реальным опытом разработки методологий “как рыбку съесть и косточки продать”.
Не будем концентрироваться на классических методах инфобезопасности, на DLP-системах, это прерогатива специальных отделов. Для начала расскажу, как не надо организовывать работу сотрудников на уровне бизнес-процессов и на уровне организации информации.
Не будем концентрироваться на классических методах инфобезопасности, на DLP-системах, это прерогатива специальных отделов. Для начала расскажу, как не надо организовывать работу сотрудников на уровне бизнес-процессов и на уровне организации информации.
Вредный совет #1. Физически уничтожать данные после использования
25 лет назад мы делали рассылки для нескольких крупнейших компаний страны. Базы для рассылок обрабатывались на нескольких выделенных компьютерах, без доступа во внутреннюю сеть, под пристальным вниманием службы безопасности клиента. Наблюдатели работали посменно, сидели в комнате и смотрели, чтобы к компьютерам никто ничего не подключал. По завершению работы жесткие диски из компьютеров изъяли и торжественно разбили молотками. Я не шучу. Вот это безопасность! Приятно вспомнить :)
фото из открытых интернет-источников
Но такой архаичный способ мало подходит для текущих CRM-реалий, ведь мы хотим персонализировать коммуникации с клиентом на протяжении всего жизненного цикла, иметь возможность этот цикл максимально удлинить и возобновлять.
Вредный совет #2. Выстроить многоуровневую сложную систему согласования доступа к данным
Есть отрасли и компании, которые мы называем “территорией победившего комплаенса”, простите за жаргон. Организации, в которых утечка данных приводит к огромным рискам, например, финансовый сектор и медицина, часто во главу угла ставят риск-менеджмент. И, если есть риск утечки, то службе безопасности проще запретить бизнесу использовать данные для маркетинга и продаж, чем выстраивать систему безопасной работы.
Вот опыт, который каждый владелец банковского счета получает довольно часто: типовая sms с предложением “вам одобрена кредитная карта” или типовой звонок из колл-центра с предложением открыть накопительный вклад. И это вне зависимости от того, какое у него состояние счетов и какая история с банком.
Вот опыт, который каждый владелец банковского счета получает довольно часто: типовая sms с предложением “вам одобрена кредитная карта” или типовой звонок из колл-центра с предложением открыть накопительный вклад. И это вне зависимости от того, какое у него состояние счетов и какая история с банком.
фото с площадки ru.freepik.com
А ведь банки владеют максимумом информации о нашем финансовом поведении, и кажется, уж могли бы сделать персональное предложение!
Проблема тут не в неумении сотрудников банка выстраивать персонализированные коммуникации. Проблема в семи кругах ада, которые надо пройти для согласования доступа к данным.
Правила безопасности, превратившиеся в систему запретов, вместо выстроенных процессов работы с данными, могут даже повышать риски. Сотрудники, получившие разрешение службы безопасности, зачастую дальше не бдят с должным уровнем — рисковики же разрешили, а процедура работы “после разрешения” не выстроена. Коллеги по рынку рассказывали, как некоторые крупные банки после длительных согласований скидывали базы с ФИО и контактами, практически сразу сотрудники банка переставали контролировать процессы работы, и безопасность, кажется, никого уже не интересовала.
Проблема тут не в неумении сотрудников банка выстраивать персонализированные коммуникации. Проблема в семи кругах ада, которые надо пройти для согласования доступа к данным.
Правила безопасности, превратившиеся в систему запретов, вместо выстроенных процессов работы с данными, могут даже повышать риски. Сотрудники, получившие разрешение службы безопасности, зачастую дальше не бдят с должным уровнем — рисковики же разрешили, а процедура работы “после разрешения” не выстроена. Коллеги по рынку рассказывали, как некоторые крупные банки после длительных согласований скидывали базы с ФИО и контактами, практически сразу сотрудники банка переставали контролировать процессы работы, и безопасность, кажется, никого уже не интересовала.
Мы за рациональный подход
Мы в DM Basis ратуем за повышение стандартов рынка, чтобы компании учились правильно использовать клиентские данные, правильно выстраивать CRM-стратегии. Пора перестать считать CRM просто рассылками и понять, что это модель бизнеса, клиентоориентированный способ зарабатывать деньги. Суть CRM-маркетинга выражается простой фразой:
CRM - способ получать доход от клиента как можно больше и дольше, делая клиента счастливым.
Пока что примеров такого полноценного понимания CRM мало, и еще меньше реализаций. Значит, это наша задача: работать над этим, образовывать рынок, делиться знаниями. Наш путь — это использование технологий и методик, чтобы сделать CRM безопасным, персонализированные коммуникации эффективными, клиента счастливым, а бизнес доходным.
Метод #1. Деперсонализируем данные и маскируем связи.
Мастер-база — хранилище всех данных, остается недоступной для ручной работы CRM-маркетолога. И это правильно. Вид данных становится информационной сущностью, каждой единице этой сущности присваивается уникальный ID.
Например, у Алексея Сидорова, зарегистрированного в нашей базе, сущность “имя” получила ID 325562. А у Галины Петровой имя получило ID 685982.
Например, у Алексея Сидорова, зарегистрированного в нашей базе, сущность “имя” получила ID 325562. А у Галины Петровой имя получило ID 685982.
Речь идет не о классической реляционной структуре (в которой, чаще всего, и так выстраиваются базы данных) , а об объединении данных в самодостаточные сущности и формировании витрин данных. Примеры таких информационных сущностей перечислены ниже — ФИО или история покупок. CRM-маркетологу доступны для работы некоторые, нужные ему, витрины данных из общей базы. Каждая выгрузка сама по себе не представляет ценности с точки зрения утечки, но имеет достаточный набор данных для работы маркетолога.
Пример набора выгрузок:
В таком случае, базу покупок можно анализировать любыми доступными методами и строить сегменты, связанные с уникальными ID.
Пример набора выгрузок:
- База ФИО;
- База контактов (email, телефоны) ;
- База покупок (или состояния счетов, если говорить о банковских данных) ;
- База поведенческих реакций на коммуникации.
В таком случае, базу покупок можно анализировать любыми доступными методами и строить сегменты, связанные с уникальными ID.
В итоге, аналитик не знает, что именно Иванов П. П. купил дорогой суперкар или хранит 100 млн. на счете — это принадлежит ID 123987. Данные теряют ценность, а вероятность утечки стремится к нулю.
С обезличенным массивом данных аналитики могут работать без надзора службы безопасности. Для каждого сегмента будет создана персональная коммуникация, затем база сегментов будет связана с персональными данными (ФИО, контактами) . Этот этап связи короткий и его можно провести под неусыпным оком службы безопасности.
Метод #2. “Кодировка” сущностей в базе
Для дополнительной защиты особо ценные сведения в таблицах можно тоже закодировать под уникальными ID. То есть коды используются не только для связи между таблицами, но и для обозначения блоков персональной информации.
Если Иванову П. П. из предыдущего примера должна пойти рассылка с упоминанием в тексте его элитарного статуса, информации об этом присваивается код 1.
Другому адресату предназначен другой информационный блок под кодом 2. Рассыльщик будет знать только номер кода, а Иванов получит сообщение: “Вы наш премиум-клиент и поэтому для Вас действуют условия… ”
Другому адресату предназначен другой информационный блок под кодом 2. Рассыльщик будет знать только номер кода, а Иванов получит сообщение: “Вы наш премиум-клиент и поэтому для Вас действуют условия… ”
О том, каким сущностям какие коды присвоены, знает только выделенная ИТ-система во внутреннем контуре, и один аналитик, который эти коды присваивал.
Можно спросить: "А как же человеческий фактор?”. Да, как минимум один человек будет в курсе кодирования. Но у него нет доступа к другим данным (к персоналиям и контактам). И даже если представить, что база утекла, то много ли толку с информации "Иванов, код 1”.
Конечно, согласен, человеческий фактор есть всегда. И мы понимаем, что большая часть проблем с утечками данных связана с сотрудниками-инсайдерами, а не со злыми хакерами. Методики, которые я описываю, призваны минимизировать человеческие риски.
Конечно, согласен, человеческий фактор есть всегда. И мы понимаем, что большая часть проблем с утечками данных связана с сотрудниками-инсайдерами, а не со злыми хакерами. Методики, которые я описываю, призваны минимизировать человеческие риски.
Метод #3. Строгий контроль доступа к “таблице связей”
Подытоживая описанные выше инструменты, отмечу, что таблица связей, содержащая стык между всеми агрегированными информационными сущностями (витринами) , должна быть наиболее защищенной. Идеально, если у сотрудников нет прямого доступа к этой таблице, и каждый сотрудник работает с кодированными витринами.
- Аналитик данных обработал и сегментировал базу. Вместе с маркетологом определили гипотезы под сегменты, в виде кодов информация ушла в таблицу связей.
- Копирайтер и дизайнер сделали материалы в соответствии с поставленной задачей, где конкретные блоки соответствуют указанным кодам.
- Верстальщик, не имея доступа к данным, делает на основе блоков макет.
- Рассылка запускается из интегрированной с итоговой таблицей связей системы, без ручного доступа сотрудников к информации.
- Желательно сначала сделать рассылку по тестовым адресам и убедиться, что все блоки подставляются корректно и выглядят корректно. Для этого еще на первом этапе аналитик составит таблицу (тест-кейсы) для проверки
Метод # 4. Настройка системы проверок
Ну и последний рубеж, контрольные адреса, раньше их называли “закладками”. В базе данных всегда должно быть какое-то весомое количество “подставных клиентов” (то есть контактов сотрудников компании), с уникальными номерами телефонов, мейлами и ФИО. Весомое количество — это не меньше 10 штук. Больше 50-60 (в большой базе) тоже смысла нет, слишком сложно администрировать. Если коммуникации идут с глубокой персонализацией, то такие “закладки” должны попадать в разные сегменты.
Во-первых, наличие таких адресов позволяет контролировать коммуникации. Даже если нет утечек, просто проверить, что компания рассылает, небесполезно.
Во-вторых, если эти “закладки” переделывать перед серьезными итерациями с данными (передача другому подрядчику, интеграция другой системы и т.д.), то реестр “закладок” позволит понять, в какой момент произошла утечка. Если в базе одного подрядчика мой контактбыл помечен как Иванопуло, у другого Берта-Мария-Бей, у третьего Воробьянинов, и база появилась в доступе — можно понять, в какой момент допущена утечка.
Во-первых, наличие таких адресов позволяет контролировать коммуникации. Даже если нет утечек, просто проверить, что компания рассылает, небесполезно.
Во-вторых, если эти “закладки” переделывать перед серьезными итерациями с данными (передача другому подрядчику, интеграция другой системы и т.д.), то реестр “закладок” позволит понять, в какой момент произошла утечка. Если в базе одного подрядчика мой контактбыл помечен как Иванопуло, у другого Берта-Мария-Бей, у третьего Воробьянинов, и база появилась в доступе — можно понять, в какой момент допущена утечка.
Проверка на целесообразность
В завершение скажу, что уровень безопасности, уровень затрат на нее и уровень «кругов ада», которые надо пройти при работе с данными, напрямую зависит от ценности данных и понимания востребованности этих данных на черном рынке.
фото с площадки https://ru.freepik.com/photos/phone
Если информация касается финансов и имущества, ее ценность высока, и применяются правила высокого уровня безопасности. Если же база мало кому нужна, кроме вас, достаточно необходимого минимума методик. Очень хочется, чтобы бизнесу не пришлось этим методам учиться под давлением жестких редакций закона 152-ФЗ и КОАП с большими штрафами.
Напишите лично Илье Шагаеву, если хотите получить консультацию по CRM-маркетингу
