Скрипты vs коробка: как эффективно маскировать данные

На связи Артемий Новожилов, архитектор систем информационной безопасности группы компаний «Гарда». Немногим ранее я рассказывал о DLP, а сегодня предлагаю обсудить тему маскирования.

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

Сразу скажу, что в статье уделим внимание статическому обезличиванию (еще существует динамическое, которое работает с запросами напрямую к продуктивной БД, но об этом – в отдельной статье). Иными словами, это создание обезличенной копии БД с синтетическими данными, но с сохранением структуры исходной базы данных (primary key, foreign key, индексы). Сохранение структуры необходимо для того, чтобы «не сломать» логику работы обезличенной базы данных.

Поговорим вот о чем:

• что такое обезличивание

• для чего применяется маскирование данных

• почему нельзя передавать данные as is

• какие данные необходимо обезличивать

• почему звездочки не помогают

• этапы обезличивания с реальными примерами

В контексте статьи обезличивание – это замена существующих реальных значений в базах данных значениями синтетическими, по структуре сходными с первоначальными. Например, у нас есть значение в таблице «Иванов Иван Иванович». Мы хотим его замаскировать, но сохранить структуру – в данном случае это ФИО. Его можно поменять на Петра Петровича Сидорова, и никто никогда не догадается о том, кто за ним скрывается. Такие же методы применяются и к цифровым наборам: номер паспорта 4111 можно поменять на 4999. Важно, что маскированные данные никому не принадлежат, поэтому мы их считаем синтетическими.

Сам процесс обезличивания состоит из трех этапов:

• Категоризация информации: здесь необходимо понять, где, а главное, какие именно данные находятся;

• Маскирование: создание копии с обезличенными данными;

• Автоматизация процесса маскирования. Не обязательный, но желательный этап.

Как правило, крупный бизнес хранит большую часть данных в структурированном виде в базах данных. По сути, это некоторое представление таблиц, связанных друг с другом, наполненных абсолютно разными значениями: от ФИО клиентов до номеров карт и СНИЛС.

Далее мы разберем ряд сценариев, при которых требуется передать базы данных или в тестовый сегмент разработки, или подрядчикам для выполнения работ:

• Передача данных в сегмент разработки. Например, компании А необходимо импортозаместить существующую систему по обработке клиентских заявок. Компания А нанимает компанию Б для разработки такого приложения. Компания Б просит предоставить примеры баз данных для реализации проекта, чтобы не писать БД с нуля, а взять уже готовую архитектуру. Компания А предоставляет базу данных компании Б, но никакие данные в ней не обезличивает;

• Передача данных для маркетингового исследования. Нередко перед компанией стоит задача протестировать эффективность каналов коммуникации, воздействовать на конкретную аудиторию, подготовиться к маркетинговой кампании. Для этого привлекают агентство, которое справедливо требует данные о клиентах (возраст, пол, место жительства и т.д.) для подготовки. Заказчик нередко передает данные в не обезличенном виде вместе с критичными данными, что может привести к утечкам информации;

• Передача данных в Data Lake. Часть статистики компании может передаваться в Data Lake (Озеро данных). Это метод хранения данных системой или репозиторием, который предполагает одновременное размещение информации в различных схемах и форматах. Идея озера данных в том, чтобы иметь логически определенное, единое хранилище всех данных в организации (enterprise data). Data Lake может размещаться как в инфраструктуре компании, так и в стороннем репозитории. Кроме того, в июне 2024 года Минцифры подготовило версию поправок в ФЗ-152 «О персональных данных», которые касаются оборота обезличенных данных и создания ГИС «Госозеро данных» для обмена информацией между компаниями.

  Соответственно, пользователями Data Lake могут быть как подрядчики, так и сотрудники компании (например, если нужно подготовить годовой отчет). Это значит, что в Data Lake может быть передана не обезличенная информация, и любой пользователь озера данных сможет получить к ней доступ и использовать в своих, не всегда благих, целях;

• Использование БД в тестовом сегменте внутри организации. Многие крупные компании не нанимают сторонних подрядчиков для разработки ПО, а имеют в штате свою команду. Такой подход позволяет быстрее дорабатывать изменения в системе, получая напрямую данные из продуктивной БД. В таком случае сценарий тот же, только данные не утекают за пределы организации, а попадают в тестовый контур, в котором может не быть систем мониторинга и защиты от утечек. Это значит, что любой разработчик может взять фрагмент продуктивной базы данных и слить ее вовне, например, скопировав на флешку.

Если владелец данных не давал разрешения на их передачу третьему лицу, а они все же были переданы, по обращению в Роскомнадзор он может начать разбирательство по факту нарушения закона (Федеральный закон «О персональных данных» №152-ФЗ). Иногда к процессу расследования Роскомнадзор может подключать ФСТЭК и ФСБ.

В передаваемой базе данных могут храниться весьма чувствительные данные, утечка которых может нанести финансовый и репутационный вред компании и ее клиентам:

• закрытые значения прайсов (их утечка может повлиять на финансовые показатели компании),

• номера телефонов VIP-клиентов,

• скидки,

• номера банковских карт,

• логины пользователей и хеши паролей,

• номера телефонов с привязкой к имени, адресу и другой личной информацией и т.д.

Как правило, речь идет именно о персональных или очень чувствительных данных:

• номер СНИЛС,

• номер банковской карты,

• номер банковского счета,

• серия и номер паспорта,

• адрес прописки, адрес проживания,

• номер телефона,

• ФИО,

• VIN-номер автомобиля,

• e-mail,

• ИНН,

• номер водительского удостоверения,

• сведения, которые относятся к коммерческой тайне,

• номер трудовой книжки, и т.д.

Кроме того, обезличивать необходимо и корпоративную критическую информацию, поскольку именно она будет использоваться, например, хакерами в случае атаки:

• MAC-адрес,

• логины пользователей,

• IP-адреса,

• хеши паролей.

Первое, что обычно приходит на ум – замена критичных данных звездочками, но этот вариант не всегда рабочий, расскажу почему.

Во-первых, в случае тестирования уже разработанного приложения написанный код необходимо «положить» на ту же самую базу данных из промышленной среды – с теми же связями, ключами и форматами данных. То есть в поле, в котором хранится номер кредитной карты, нельзя записать «****», так как код написанного приложения будет валидировать это значение по алгоритму Лу́на (специальный алгоритм вычисления контрольной суммы для проверки номера пластиковой карты в соответствии со стандартом ISO/IEC 7812, принятый во всем мире), чтобы защитить пользователя от неправильного ввода в будущем. А это значит, что и при тестировании этого приложения значение в ячейке должно быть о структуре точно такое же, как и в промышленном сегменте – попадать под алгоритм Луна!

Во-вторых, обезличенные данные в ряде случаев должны быть консистентными, то есть иметь единое представление в разных таблицах. Так, если в исходной БД имеется значение «Иванов Иван Иванович», то во всех связанных БД он должен замаскироваться одинаково, чтобы не искажалась связь между объектами. В противном случае эту обезличенную БД нельзя использовать при тестировании.

В-третьих, если данные передаются в Data Lake или подрядную компанию для маркетингового исследования, то ненужную информацию можно попробовать заменить на звездочки, но как именно найти то, что требуется заменить? Из этого вытекает две проблемы:

• Структура хранения данных может быть нелогичной. Иногда недостаточно посмотреть только на название столбца – данные могут храниться в столбце с названием PDN1 (персональные данные), а сами значения будут соответствовать банковским картам. Вручную перебрать все значения практически невозможно ввиду большого объема информации, если, например, передается база в несколько терабайт. В таких случаях необходим автоматизированный инструмент, который сможет категоризировать контент в столбце;

• В компании может быть абсолютно разный парк СУБД (PostgreSQL, MySQL, MSSQL, Oracle, ClickHouse, MongoDB, MariaDB и т.д.), что потребует разных подходов к методам определения и обезличивания данных.

Для решения задачи обезличивания многие компании прибегают к написанию скриптов. Скрипт – это команда, запускаемая из консоли системы управления базами данных (СУБД), позволяющая заменить текущие значения в столбце/строке на иные значения. Этот подход может быть оправдан на начальных этапах работы с данными, когда объем обрабатываемой информации невелик. Однако по мере роста количества данных сложность и стоимость поддержки скриптов возрастает.

Разработка таких скриптов часто не требует больших материальных вложений. При этом они могут использовать стандартные механизмы для выявления персональных данных: регулярные выражения и справочники. Ключевые преимущества метода:

• низкая стоимость разработки и внедрения, особенно на начальном этапе,

• возможность тонкой настройки скрипта под конкретные потребности организации.

Но при обезличивании скриптами возникает ряд проблем:

• Скрипты используют мощности самих СУБД для проведения процедуры обезличивания. Это приводит к уменьшению производительности (а в некоторых случаях влияют и на работоспособность) системы, ведь в них нет встроенных алгоритмов ограничения потребления ресурсов. При этом если есть требования к скорости маскирования (когда базу данных необходимо замаскировать за один час), скрипты, как правило, не могут управлять этим процессом;

• Если база данных динамически меняется и обезличивать ее требуется регулярно, то необходим отдельный сотрудник (оператор), который будет заниматься ручной категоризацией данных и правкой скриптов по обезличиванию данных в БД, что не исключает ошибок. Например, некорректное определение данных повлечет за собой некорректное обезличивание или его невыполнение. Допустим, оператор не определил номер банковских карт, и не запустил скрипт на обезличивание. Как итог – данные не замаскированы и переданы третьему лицу;

• Как правило, при использовании скриптов нет возможности предварительно посмотреть, как будут замаскированы данные. Значит, если скрипт не отработал на части данных, это будет ясно только после завершения процесса, и цикл придется повторить после исправления скрипта, что значительно растягивает процесс по времени. К тому же, нет возможности оценить, как именно сработают алгоритмы, и, следовательно, подходит ли выбранный алгоритм к данным, которые находятся в конкретной колонке;

• Все скрипты работают неодинаково на разных СУБД (PostgreSQL, MSSQL, Oracle и т.д.). Редко встречаются компании, где используется одна версия СУБД. Как правило, это все же парк решений, что усложняет первоначальное написание и дальнейшую поддержку скриптов. Одной версии СУБД – один пул скриптов. Это занимает много времени у оператора, и не исключает человеческий фактор.

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

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

Таким образом, в отличии от скрипта, специализированное ПО позволяет:

• в автоматическом режиме выявлять чувствительную информацию (ФИО, номера телефонов и другие данные, указанные выше ),

• настраивать алгоритмы маскирования данных один раз, а затем просто использовать уже настроенную систему,

• производить полную репликацию исходной БД с сохранением взаимосвязей (таблицы и связанные с ними ключи),

• добавлять свои скрипты с учетом уже выстроенной логики самой системы,

• автоматизировать процесс категоризации данных и обезличивания (встраивание в pipeline CI/CD).

Ниже разберем подробнее все этапы обезличивания баз данных специализированными средствами.

Процесс обезличивания как скриптами, так и специализированными системами, состоит их трех важных итераций: категоризация, маскирование, автоматизация (в методе со скриптами может и не быть). Рассмотрим каждую из них на примере нашего продукта «Гарда Маскирование».

Категоризация

Для начала необходимо определить в БД те самые критичные данные. То есть каким-то образом автоматизированная система должна понять, что одно значение – это номер паспорта, а другое – простой набор из 16 цифр.

Для этого у систем по обезличиванию данных имеется набор шаблонов категоризации, основанный на лучших практиках вендора. Так, некоторые данные могут быть найдены через название колонки, а некоторые на основе контентного анализа – просмотра всех значений в колонке и проверки их различными регулярными выражениями. Шаблон категоризации адреса представлен ниже в качестве примера.

• Основная информация – Наименование колонки и Тип данных –довольно быстро определяют и находят эти значения в исходной таблице

• Регулярные выражения – анализируют, что именно хранится в данной колонке

• Справочники – ищут значения из заранее сформированного справочника

Нередко необходим поиск по словарям. Например, если нужно найти в базе столбец с именами, проще использовать словарь известных имен.

При первом запуске сканирования система обращается к исходной базе данных через select, что позволяет проанализировать возвращаемый в ответе на запрос контент на наличие искомых данных.

ВАЖНО! Так как система по автоматизации маскирования устанавливается на выделенный сервер, то сам процесс категоризации не оказывает никакого влияния на исходную базу данных, а вся нагрузка приходит на систему маскирования.

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

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

В зависимости от определенной категории будет применен соответствующий алгоритм маскирования на следующем этапе.

Маскирование

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

А так выглядят данные после обработки:

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

Автоматизация

Для того чтобы не запускать сканирование и маскирование каждый раз через консоль комплекса, используется встроенный API для управления четырьмя задачами удаленно: запуск и остановка сканирования, запуск и остановка маскирования.

Интеграция с CI/CD pipeline:

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

• в GitLab или Jenkins созданы джобы, в рамках которых осуществляются шаги «Сканирование» и «Маскирование»,

• шаг «Сканирование» запускает по REST API обращение к системе «Маскирование» на категоризацию данных в рамках ранее созданной задачи на сканирование. Проверяет ответ, что изменений в базе не зафиксировано, то есть колонки с новыми персональными данными не появились. Если появились, то выдается сообщение об ошибке, отправляется сообщение и привлекается офицер безопасности для разбора ситуации,

• шаг «Маскирование»: проводится маскирование данных, вызывается через REST API запрос в «Гарда Маскирование».

После того как все этапы пройдены и процесс автоматизирован, дальше остается только изредка править или добавлять новые шаблоны.

При всем удобстве использования автоматизированных систем по обезличиванию, также можно выделить ряд недостатков, которые связаны с конкретными сценариями:

• Конфиденциальную информацию конкретной организации бывает достаточно сложно систематизировать

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

  С другой стороны, есть случаи, когда какие-либо регламенты отсутствуют вовсе, и тогда приходится полагаться исключительно на свой опыт. Важной особенностью является отсутствие явных требований регуляторов (и не только в РФ) к процедурам маскирования, что также не добавляет определенности используемым подходам. Например, сейчас обсуждается создание ГИС «Гособлако данных», и требования обезличивания к датасетам для нее пока неизвестны.

• Ложные срабатывания на некоторых типах данных

  Хорошо зарекомендовавшие себя схемы и алгоритмы по определению и маскированию персональных данных в ряде случаев дают ложный результат. Проблема кроется в особенностях клиентских баз данных. Так, например, при анализе данных клиента в одной из стран СНГ выяснилось, что номера телефонов сильно похожи на номера российских ИНН или ОКПО. Это потребовало учета особенности этой страны при проектировании новых шаблонов сканирования. Другой пример, когда ИНН юридического лица и ОКПО содержат в себе 10 знаков. Чтобы различать их, были улучшены и применены интеллектуальные алгоритмы сканирования.

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

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

Маскирование данных – сложная задача, решение которой часто требует индивидуального подхода. Выбор между специализированным решением и самописным скриптом зависит от конкретных потребностей организации и ее ресурсов. Специализированное решение обеспечивает высокую эффективность и поддержку производителя, однако может быть неоправданно дорогим при небольших объемах БД или если не использовать все функции. Самописный скрипт подходит для небольших объемов данных, узких задач и ограниченных бюджетов, но требует больше времени, ресурсов и усилий для поддержки и обновления.

В заключение хотелось бы добавить, что любая информационная система – это упрощение некоторого количества задач, но конечный пользователь – это всегда 4EJl0l3EK (ой, что-то замаскировалось )).