Сколько личной информации о вас хранится в мире онлайна? От финансовых операций и медицинских досье до социальных сетей и корпоративных баз данных – данные каждого из нас оказываются в цифровом пространстве, привлекая внимание злоумышленников и вызывая беспокойство как у нас, так и у служб безопасности.
Одним из распространенных методов защиты является маскировка данных. Для более ясного понимания этого процесса давайте рассмотрим различные техники маскировки и попробуем разобраться, с чем это едят. Данная статья нацелена на джунов и специалистов, которые только начинают погружаться в тематику.
Начнем с вопроса: зачем вообще нужна маскировка данных?
Вероятно, вы уже знаете, что объем данных постоянно растет. Если термин Big Data начал активно использоваться в начале 2000-х, то за первые двадцать с небольшим лет 21 века объем данных увеличился многократно. К 2012 году объем данных в интернете достиг 1 зеттабайта (~ 1.07 млрд терабайт). К 2020 году эта цифра увеличилась до 59 зеттабайт, а к 2025 году ожидается, что объем данных превысит 170 зеттабайт.
С увеличением объема данных неизбежно увеличивается и количество утечек. Например, в аналитическом отчете Infowatch отмечается, что утечки информации ограниченного доступа составили более 1100 млн записей ПДН за 2023 год, тогда как в 2021 количество утекших данных в сети составляло «лишь» 250 млн записей.
Так почему же Neoflex решил заняться маскировкой и шифрованием данных?
Наша команда работает в различных областях, где использование маскированных данных крайне желательно, ведь любая утечка может нанести сокрушительный удар по репутации компании. Наша цель не только предоставить готовое решение, но и создать гибкий инструмент, применимый на различных проектах с разными базами данных. Инструмент также должен быть легким в использовании, не требующим глубоких знаний в области, что сделает его доступным для всех пользователей.
Поговорим о процессе маскирования данных, рассмотрев упрощенную схему процесса.
Давайте детально рассмотрим схему, начав с профилирования данных, представляющего собой процесс анализа и изучения структуры данных с целью выявления их особенностей, паттернов и взаимосвязей. Этот этап является ключевым в области обработки данных и обеспечения безопасности информации. Профилирование данных включает в себя идентификацию как прямых, так и косвенных идентификаторов.
Попробуем разобраться на примере нашей выдуманной БД из двух таблиц импровизированного банка. Одна таблица содержит в себе данные по клиентам нашего банка, другая – информацию по запросам предоставления ипотеки:
Прямые идентификаторы представляют собой атрибуты данных, которые напрямую указывают на конкретного пользователя, объект или сущность. ФИО, ИНН, номер СНИЛС, паспорта – все эти данные являются прямыми идентификаторами, которые могут быть использованы для прямой идентификации.
В нашей БД таким являются лишь номер паспорта и ФИО, пометим его голубым (заодно и наши идентификаторы, но это уже для целостности картины):
Косвенные идентификаторы – атрибуты, позволяющие определить респондента с той или иной степенью неопределенности. Дата рождения, почтовый индекс, номер телефона и даже вес или должность человека – все они могут служить косвенными идентификаторами, если данные атрибуты (или их комбинация) позволяют частично идентифицировать потенциальную жертву злоумышленников. В эту категорию чаще всего могут попадать общедоступные персональные данные.
В нашем случае при доступе к базе данных злоумышленником отдельные знания о номере телефона и дате рождения не позволяют однозначно идентифицировать личность человека. Однако же комбинация этих знаний позволяет существенно сузить выборку, тем самым мы относим эти данные к косвенным идентификатором. Окрасим их в зеленый цвет:
Необходимо также разобраться в понятии чувствительных данных. Это информация, которая при попадании в открытый доступ или к третьим лицам может нанести потенциальный вред ее законному владельцу: в том числе, угрозу для личной жизни, финансовой безопасности и репутации. Такими данными могут являться сведения о доходах, медицинских диагнозах и другая личная информация.
В нашем импровизированном банке к этой категории мы отнесем информацию по заявкам наших клиентов на ипотеку, атрибуты даты заявки, зарплаты и запрашиваемой суммы.
В процессе маскирования мы стремимся скрыть чувствительные данные таким образом, чтобы сохранялась возможность проведения анализа, а также требуемая полезность данных. Следовательно, основным критерием успеха в обезличивании данных является достижение оптимального баланса между полезностью и безопасностью результата.
Завершим же наш этап профилирования, окрасив последнюю категорию наших атрибутов в оранжевый цвет:
Профилирование БД современных объемов крайне трудоемкий и важный процесс, который необходимо оптимизировать. Как делаем это мы? Рецепт довольно прост: берем заранее обученную ML-модель собственной разработки и заставляем ее профилировать за нас. Пользователю остается лишь скорректировать или подтвердить результат. Это позволяет нам добиться максимально качественного результата с минимальным вовлечением дорогостоящих человеческих ресурсов. А важен этот этап именно из-за того, что на базе него осуществляются дальнейшие решения о выборе степени и метода обезличивания.
Разобравшись с профилированием, перейдем к самому вкусному.
Как же мы можем обезопасить свои данные, сделав их бесполезными для мошенников, при этом не потеряв полезность для себя?
Рассмотрим различные методы маскирования данных, начиная с самого бескомпромиссного.
Подавление записей
Этот безжалостный метод заключается в удалении или замене части данных, что делает их недоступными для анализа. Значения могут быть заменены на «*», либо какие-то стандартные значения для сохранения формата данных. Мы же не хотим, чтобы в нашей базе даты рождения стали звездочками? Поэтому меняем их на «1900-01-01», а номера паспортов на 0000 000000. Также можем сохранить серию паспорта, меняя на нули только последние шесть цифр, сохранив часть информации.
При хранении информации о паспортных данных клиента подавление записей делает их личные данные недоступными для исследователей. Также можно применить локальное подавление к медицинским данным, чтобы часть информации о пациентах стала недоступной.
Давайте применим этот метод ко всей нашей базе данных:
Выглядит, конечно, здорово – злоумышленнику не достанется ничего. Но и нашим сотрудникам будет сложно тестировать доработки и развивать эту замечательную БД. Маскирование данных подобным образом – идеальный пример нарушения оптимального баланса между безопасностью и полезностью данных.
Предположим, что к нам пришли злые аналитики и теперь мы хотим убрать этим методом лишь прямые идентификаторы, коими являются ФИО и номер паспорта нашего клиента:
В таком случае злоумышленник сможет однозначно установить личность клиента лишь с помощью косвенных идентификаторов.
Что же касается минусов для нас: теперь мы не можем проверить, а есть ли дубли записей по номеру паспорта. Также мы теряем возможность использования номера паспорта как натурального ключа с другими потенциальными таблицами, где нет аналога прямой ссылки на нашу таблицу.
Забегая вперед, скажем, что минусов можно было избежать, поэтому использование данного метода не рекомендуется, но он применим.
Округление
Метод округления применяется для замены точных значений на их ближайшие округленные аналоги. Это может снизить точность данных, сохраняя при этом общие тенденции. Округление может быть применено как ко всем значениям атрибутов, так и локально. Например, округление может использоваться с диапазоном значений, что также предоставляет удобство. В реальной практике диапазоны практически не используются в корпоративном мире, но повторять за профессионалами не обязательно.
Давайте воспользуемся данным методом для наших атрибутов, описывающих дату рождения. Округлим атрибут DOB_DT до ближайшего десятилетия, а номер телефона – до ближайшей 1000:
До применения округления на атрибуты даты рождения и телефона клиента для однозначного определения конкретного человека в нашей БД было достаточным знать лишь один из этих атрибутов. Сейчас же, при доступе злоумышленника к БД точные знания лишь о дате рождения или номере телефона клиента не позволят ему однозначно идентифицировать потенциальную жертву, что говорит об улучшении безопасности нашего датасета.
Из минусов: мы до сих пор не можем отслеживать появление дубликатов по данным полям, если такое необходимо. Также можно заметить, что наши данные теряют свою точность распределения и принимают более однородный вид в сравнении с оригинальным набором данных.
Перестановки
Этот метод изменяет порядок данных или перемешивает их, что делает сложным установление связи между исходными и маскированными данными. Перемешивание порядка строк или их частей в таблице с данными о клиентах усложнит анализ личной информации, сохранив при этом их точную статистику.
Давайте попробуем вместо округления применить данный метод к атрибутам PHONE_NO и DOB_DT:
В отличие от предыдущего метода мы сохраняем реальные данные и их распределение, убирая возможность идентификации клиента злоумышленниками по комбинации номер телефона/дата рождения. Также данный метод позволяет проследить появление дубликатов, в отличие от предыдущих двух.
Из минусов: при доступе к БД злоумышленник может получить набор хаотичных, но реальных данных. В нашем случае под ударом скорее всего окажется список всех телефонных номеров клиентов, и они станут получать нежелательные звонки. Поэтому к некоторым категориям данных в чистом виде данный метод применять не рекомендуется.
Добавление шума
Этот подход заключает в себе внесение случайных или искаженных данных, создавая дополнительные сложности для анализа и предотвращая восстановление реальных значений. Берем суммы зарплат, и умножаем на случайный коэффициент в заданном диапазоне от 0.8 до 1.2. Похоже на округление, но при этом мы оставляем разнообразие значений и реалистичность данных.
Отлично подходит для искажения наших данных из предыдущего пункта. Воспользуемся им, изменив последние 9 цифр номера телефона в пределах +-1, а даты рождения – в пределах 30 дней:
Таким образом, мы оставляем распределение и вид данных, близкое к оригинальному, но не даем заполучить злоумышленнику точных чисел. Теперь наш набор телефонных номеров стал бесполезным для мошенников, сохранив большую часть полезности для сотрудников нашего банка, занимающихся развитием хранилища.
Данный метод хорошо работает при наличии большого количества похожих значений (например, в случае одинаковой заработной платы у всех сотрудников), а также неплохо комбинируется с другими методами.
Если все вышеуказанные методы кажутся простыми, то так оно и есть.
Тем не менее, их уместное использование и комбинация во многих случаях позволяет добиться требуемого уровня безопасности при должном уровне полезности данных, не говоря уже про их более доработанные и усложненные варианты.
Давайте рассмотрим еще один чуть более продвинутый метод.
Шифрование
Шифрование заменяет реальные данные на специальные коды или символы, обеспечивая сохранение уникальности идентификаторов. Например, замена имен пользователей на уникальные хэши или идентификаторы делает данные труднопонимаемыми без специального ключа. Это лодин из самых востребованных и сложных в реализации инструментов. Мы можем перекрутить все номера паспортов так, что их будет не узнать, но при этом во всех сущностях одинаковые номера будут заменены на одинаковые значения.
Таким образом, сможем сохранить связи во всей базе данных, защитив данные, если использовать номера паспортов как натуральный ключ. Данный метод требует большего количества ресурсов для реализации, но при этом с его помощью достигается самый оптимальный результат соотношения безопасности и полезности данных.
При использовании подавления на номера паспортов мы потеряли ту самую возможность связывать таблицы между собой, используя натуральные ключи.
Вместо подавления воспользуемся сохраняющим формат шифрованием, атрибуты PASSPORT_NO, NAME, SURNAME:
Вся польза данного метода заключается в том, что мы можем спрятать и обезопасить реальные данные, сохранив при этом взаимосвязи между огромным количеством таблиц без необходимости дополнительного введения идентификаторов для связи. В случае применения данного метода на аналогичные атрибуты в любой сущности нашей БД все Алексеи станут Александрами, а Ольги – Тамарами.
Минус данного метода заключается в требованиях большого количества вычислительных ресурсов, чем зачастую мы можем быть ограничены. Особенно в задачах, где необходимо замаскировать терабайты информации.
Взглянем на получившийся датасет. Теперь он анонимен и не содержит реальных данных по нашим клиентам, ведь при доступе к чувствительным данным злоумышленник не сможет идентифицировать – к какому клиенту они относятся. При этом доступ к реальным чувствительным данным все же остается и можно пойти дальше, применив методы обезличивания к ним. Если бы вы обезличивали данные таблицы, то какой метод или комбинацию применили и к каким атрибутам?
Все вышеописанные алгоритмы являются лишь верхушкой айсберга от бескрайнего количества производных алгоритмов, позволяющих нам обезопасить ваши данные. Но при этом они же являются базой и основой маскирования данных.
Профилирование и методы обсудили, осталось понять, кому же эти маскированные данные достанутся.
Основная идея наличия обезличенных данных в компании – минимизировать количество специалистов, имеющих доступ к персональным данным и данным промышленного контура. Это является ключевым аргументом в обеспечении должного уровня безопасности. Но при таком ограничении мы запросто можем свести к минимуму качество доработок. Как протестировать поставку, если синтетика на тестовых контурах не позволяет сымитировать качество исходных данных? Вот на этом этапе и приходят на помощь обезличенные данные, позволяющие нам проводить анализ и тестирование на базе аналогичных по качеству данных.
Соответственно по замыслу с обезличенными данными встретимся именно мы – простые работяги, трудящиеся на благо общества аналитики, разработчики и тестировщики. То самое, идеальное обезличивание, позволит сохранить нам и компании данные там, где они и должны оставаться, при этом не ограничив темпов и качества развития хранилища.
Использование маскирования позволяет существенно снизить риски утечки информации и повысить уровень безопасности хранилища данных, несмотря на концептуально простые методы и их легкую реализацию.
Будьте ответственны за данные тех, кого приручили.
