Крупные утечки персональных данных и как их избежать. Часть 2

В первой части статьи рассказал о методах защиты данных, которые существенно снижают эффективность CRM-маркетинга. Теперь конкретно о методах, которые можно и нужно внедрить в работу с данными.

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

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

Например, у Алексея Сидорова, зарегистрированного в нашей базе, сущность “имя” получила ID 325562. А у Галины Петровой имя получило ID 685982.

Речь идет не о классической реляционной структуре (в которой, чаще всего, и так выстраиваются базы данных) , а об объединении данных в самодостаточные сущности и формировании витрин данных. Примеры таких информационных сущностей перечислены ниже — ФИО или история покупок. CRM-маркетологу доступны для работы некоторые, нужные ему, витрины данных из общей базы. Каждая выгрузка сама по себе не представляет ценности с точки зрения утечки, но имеет достаточный набор данных для работы маркетолога. Пример набора выгрузок:

В таком случае, базу покупок можно анализировать любыми доступными методами и строить сегменты, связанные с уникальными ID.

С обезличенным массивом данных аналитики могут работать без надзора службы безопасности. Для каждого сегмента будет создана персональная коммуникация, затем база сегментов будет связана с персональными данными (ФИО, контактами) . Этот этап связи короткий и его можно провести под неусыпным оком службы безопасности.

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

О том, каким сущностям какие коды присвоены, знает только выделенная ИТ-система во внутреннем контуре, и один аналитик, который эти коды присваивал.

Можно спросить: "А как же человеческий фактор?”. Да, как минимум один человек будет в курсе кодирования. Но у него нет доступа к другим данным (к персоналиям и контактам). И даже если представить, что база утекла, то много ли толку с информации "Иванов, код 1”.

Конечно, согласен, человеческий фактор есть всегда. И мы понимаем, что большая часть проблем с утечками данных связана с сотрудниками-инсайдерами, а не со злыми хакерами. Методики, которые я описываю, призваны минимизировать человеческие риски.

Подытоживая описанные выше инструменты, отмечу, что таблица связей, содержащая стык между всеми агрегированными информационными сущностями (витринами) , должна быть наиболее защищенной. Идеально, если у сотрудников нет прямого доступа к этой таблице, и каждый сотрудник работает с кодированными витринами.

Эта работа усложняет и удлиняет процесс. Но, во-первых, не так страшен черт… доводилось работать даже в более жестких условиях доступа к данным. Если процесс налажен, он идет быстро. И согласитесь, лучше использовать предложенные методы защиты, чем останавливать работу запретами или работать с открытыми данными с большими рисками утечки.

Ну и последний рубеж, контрольные адреса, раньше их называли “закладками”. В базе данных всегда должно быть какое-то весомое количество “подставных клиентов” (то есть контактов сотрудников компании), с уникальными номерами телефонов, мейлами и ФИО. Весомое количество — это не меньше 10 штук. Больше 50-60 (в большой базе) тоже смысла нет, слишком сложно администрировать. Если коммуникации идут с глубокой персонализацией, то такие “закладки” должны попадать в разные сегменты.

Во-первых, наличие таких адресов позволяет контролировать коммуникации. Даже если нет утечек, просто проверить, что компания рассылает, небесполезно.

Во-вторых, если эти “закладки” переделывать перед серьезными итерациями с данными (передача другому подрядчику, интеграция другой системы и т.д.), то реестр “закладок” позволит понять, в какой момент произошла утечка. Если в базе одного подрядчика мой контактбыл помечен как Иванопуло, у другого Берта-Мария-Бей, у третьего Воробьянинов, и база появилась в доступе — можно понять, в какой момент допущена утечка.

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

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

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

Кстати, с 1 сентября этого года и с 1 марта 2023 года вступают в силу новые изменения 152-ФЗ, которые мы тоже обязательно рассмотрим, и я опубликую аналитику. Думаю, что в течение августа сделаем.