Привет, Хабр!
На связи Дмитрий Ларин, я руковожу продуктовым направлением по защите баз данных, в Гарде.
Маскирование данных — важное направление нашей работы (в продуктовой линейке Гарды даже представлен отдельный продукт для выполнения таких задач). Поэтому нам не привыкать к разнообразным вопросам об этом методе защиты — от банального «зачем вообще нужно маскирование?» до провокационного «почему бы не скормить поиск ПДн нейронке?».
Далеко не всегда можно «вытащить из рукава» однозначный ответ, ведь дьявол, как известно, кроется в деталях: особенностях корпоративной сети, специфике бизнеса, сценариях использования данных.
Недавно мы провели вебинар с говорящим названием «Маскирование данных: битва мнений». Мы постарались честно и взвешенно ответить на частые и животрепещущие вопросы по этой теме, и теперь делимся своими ответами в статье.
Итак, поехали.
Зачем шифровать production сегмент, если тестовый открыт нараспашку?
Представим тестовый контур, скажем, стенд для разработки мобильного банка. Разработчики и безопасники хранят прод как зеницу ока, в то время как такие тестовые среды часто защищают по остаточному принципу. В итоге они превращаются в проходные дворы: туда вхожи и сотрудники, и сторонние исполнители, включая аутсорсинговых разработчиков, тестировщиков, аналитиков. Изоляция же сегмента часто ограничивается базовыми настройками сети. А ведь на таком тестовом стенде могут использоваться реальные данные (ФИО клиентов, платежная информация, детализация по транзакциям), чтобы всё работало как в проде.
При подобном подходе даже арсенал СЗИ на внешнем периметре не спасет от неконтролируемого использования чувствительной информации внутри компании. К тому же неприступных крепостей не бывает. Кто даст гарантию, что внешний периметр давно не скомпрометирован, а злоумышленник не затаился в инфраструктуре и не ворует информацию? Так что маскирование данных внутри корпоративной сети — это вовсе не паранойя и не оверкилл, с точки зрения ИБ, а вполне оправданная и даже базовая мера защиты.
Зачем маскировать данные, если уже есть шифрование?
В этом контексте вспоминается кейс одного нашего клиента. В компании подошли к вопросу безопасности тестового контура основательно: зашифровали базу целиком — и перестарались. При каждом обращении система тратила ресурсы на расшифровку данных, а запросы к базе выполнялись со скоростью улитки. Производительность стенда упала в разы. Словом, чрезмерное шифрование имеет свои побочные эффекты, и иногда его стоит сочетать с другими методами, которые меньше нагружают систему, например, маскированием.
Важно, что обезличенная таким способом информация остается в текстовом формате — ее можно дедуплицировать (например, за счет методов детерминированного преобразования) и сжать на уровне систем хранения. Это удобно при резервном копировании реальных чувствительных данных из прода в тестовую среду. Зашифрованный «в лоб» бэкап, напротив, плохо поддается сжатию и весит практически столько же, сколько и исходники в открытом виде.
К тому же эти две технологии действуют в своих нишах и закрывают, по сути, разные спектры угроз.
Шифрование защищает данные от несанкционированного доступа при хранении или передаче. Эта мера работает в случае перехвата или кражи информации из прода, утери физического носителя. Стоит приложению или пользователю получить легитимный доступ к защищенным данным, как они расшифровываются при первом же обращении (при наличии соответствующих прав, конечно). Соответственно, криптографические методы помогут против злоумышленников-гастролеров, но не остановят всё тех же недобросовестных подрядчиков с доступом к тестовому контуру.
Задача же маскирования — проконтролировать, что увидит конкретный пользователь при обращении к БД. Оно скрывает реальные значения при легитимном или полулегитимном доступе к данным. Это именно тот барьер перед злоумышленниками из числа внутренних пользователей, который не может обеспечить шифрование.
Таким образом, эти два метода не конкурируют между собой, а гармонично дополняют друг друга. Главное, как говорится, уметь правильно их «готовить».
Какой смысл маскировать данные, если после этого тесты перестают работать?
После такого обезличивания тестовые среды и вправду могут ломаться, но не спешите с выводами. Виной всему не маскирование как таковое, а неправильный подход к нему.
Приложение ждет информацию определенного формата и структуры — иначе его логика ломается. Обезличенные данные должны иметь семантическое сходство с исходными, а не превращаться в нечитаемую «абракадабру» из звездочек или случайных символов. То есть реальные ФИО меняются на условные, и такой же трюк проделывается с номерами документов, суммами платежей и прочим. Так сохраняются структура базы данных, индексы и связи между таблицами. Приложение не видит подвоха и работает по обычной логике.
Фактически при маскировании создается полноценная копия базы данных, в которой реальные значения заменены синтетическими. При необходимости эту копию можно уменьшить. Такая опция пригождается для использования в тестовом сегменте, где нет смысла сохранять полный объем продуктивной базы, только бы работали нужные сценарии.
Допустимая степень преобразования данных определяется тем, зачем нужна обезличенная копия. Требуется прогнать в тестовом контуре полноценный цикл разработки — тогда семантику и структуру лучше сохранить вплоть до запятой. Необходимо передать часть данных для внешней аналитики — допускается больше расхождений с оригиналом.
А может, вместо маскирования лучше удалить лишнее?
Иногда маскирование действительно не требуется — достаточно не включать поля с чувствительной информацией в выгрузку. Представим, что компания передает данные подрядному аналитическому агентству для оценки маркетинговой стратегии на основе покупательского поведения. Для выполнения такой задачи подрядчику хватит сведений о поле покупателя, регионе, категории товара и объеме покупки, в то время как ФИО и другие персональные данные ни к чему. Опять же проще исключить лишние поля из выборки, чем тратить ресурсы на обезличивание.
Только в случае с тестовым контуром всё сложнее. Развернутому там приложению нужна полноценная структура и семантика базы данных, а не урезанный набор полей. Поэтому удаление лишней информации здесь не заменяет маскирование, а лишь дополняет его в отдельных случаях.
Как и в медицине, главное — соблюсти принцип «не навреди» и не сломать логику приложения радикальным «выкашиванием» данных.
Какие виды маскирования существуют и зачем их столько?
Технология обезличивания применяется для целого комплекса задач:
подготовка копии базы для DevOps-конвейеров, тестовых и учебных сред, внешних подрядчиков;
ограничение доступа к чувствительным полям в продуктивной среде;
сокращение циклов выпуска новых версий продуктов;
обезличивание данных уволенных сотрудников;
защита информационного потока в аналитическую систему.
Под разные сценарии предусмотрены свои типы маскирования, между которыми часто возникает путаница. Давайте разбираться.
Статическое маскирование подходит для создания копии базы данных при передаче подрядчикам, разработчикам или в тестовый контур. Данные обезличиваются единоразово (скажем, реальные ФИО меняются на условные), далее пользователи работают с измененной информацией, и никаких дополнительных обработок не производится. Такая копия полностью отчуждаема, а исходная база при этом не меняется.
Динамическое маскирование часто используется для обезличивания чувствительных данных в продуктовой среде. Вместо создания копии здесь перехватываются обращения к продуктивной базе, после чего пользователю возвращается ответ (замаскированный или незащищенный, в зависимости от пользовательских прав). Упор делается на скорость — отклик должен укладываться в миллисекунды, чтобы не замедлять работу приложения.
Выборочное маскирование обезличивает не всю базу, а только конкретные записи, например, данные уволенных сотрудников. Закон требует хранить такую информацию и предоставлять ее по запросу контролирующих органов. Выборочное маскирование позволяет сохранить записи в базе, но скрыть их от посторонних глаз.
Потоковое маскирование применяют при перемещении данных между системами, например, при загрузке в BI-платформу. Здесь важно не столько время отклика, сколько пропускная способность: нужно обработать большой объем данных, не снижая скорость передачи. В отличие от динамического маскирования, потоковое направлено на то, чтобы обезличить информацию до того, как она «ляжет», например, в СХД.
Почему нельзя прогнать базу через ML для поиска персональных данных?
В теории один универсальный инструмент удобнее, чем набор правил и шаблонов. Неумолимая практика же снова показывает, что ИИ — это не «серебряная пуля», и сфера его применения сильно ограничена. Посмотрим, когда такой подход срабатывает, а когда лучше выбрать другие решения.
В случае со структурированными данными быстрее и точнее работают регулярные выражения. Они по щелчку пальцев находят, скажем, номера паспортов определенного формата в колонке и другую упорядоченную информацию. Модель ML потратит на ту же задачу больше времени и ресурсов ради результата, который и так предсказуем.
Другое дело длинные неструктурированные сообщения, такие как поля комментариев в XML-файлах с записями операторов кол-центра. Там ПДн нередко хаотично разбросаны внутри текста. ML отлично «просеивает эти крупинки золота»: распознает фамилии, адреса или номера документов внутри связного текста.
Поэтому в нашем продукте Гарда Data Masking мы применяем гибридный подход, сочетающий названия колонок, шаблоны, справочники, регулярные выражения и ML. Решение проектировали так, чтобы результат автоматического поиска можно было проверить и скорректировать вручную, если классификация оказалась ошибочной.
Почему 70 ТБ нельзя «протолкнуть» по гигабитному каналу за 24 часа?
Да, маскирование съедает меньше ресурсов системы, чем чрезмерное шифрование. Но при неправильном подходе даже обезличивание данных замедляет запросы и снижает производительность в высоконагруженных контурах. Неудивительно, что у бизнеса и разработчиков возникает крамольная мысль: «Дайте нам доступ к реальным данным, хватит нас тормозить!». И лишь понимание матчасти помогает выбрать оптимальный подход к маскированию и не поломать остальные процессы.
Возьмем для примера полное обезличивание продуктивной базы PostgreSQL на 5 ТБ, которое может занимать примерно 14 часов (14 — Карл!). Если мы планируем (на самом деле, вынуждены) действовать днем, то нам важно будет не «уронить» скорость работы production БД и нам придется перейти на чтение данных небольшими порциями, что снизит нагрузку на базу. Правда, при этом упадет и скорость маскирования. Обработка данных крупными пачками, напротив, потребует больше ресурсов базы, зато процесс ускорится.
Если же мы можем действовать за пределами рабочего дня, то у нас несколько развязываются руки…
Тут часто приходит эйфория, и параметры, влияющие на скорость процессов маскирования (а, следовательно, и нагрузкой на базу), выкручивают на максимум. При этом забывая про репликацию. Важно разнести по времени репликацию и маскирование. Эти процессы не стоит запускать параллельно на одном сервере, но оба лучше выполнять в нерабочие часы, чтобы поменьше нагружать продуктивную базу в наиболее горячее время. Словом, чем-то придется пожертвовать.
Еще нужно учитывать скорость дисковой подсистемы и пропускную способность сети. При передаче 5 ТБ данных по стандартному гигабитному каналу одно только копирование займет 11–12 часов, и никакие настройки алгоритмов здесь не помогут. В таком случае остается сокращать объемы передаваемых данных. Для этого можно создать сжатую копию базы с сохранением нужной структуры и семантики. Другой возможный вариант — применить инкрементальное маскирование, при котором после первого полного цикла обрабатывается только дельта изменений. Это также сокращает время доставки данных из продуктивной базы в тестовый контур или другую целевую систему.
Помимо скорости сети и объема трафика, важно правильно оценить ресурсы под сам процесс маскирования.
Вот характерный пример из нашей практики: на пилотном проекте нужно было обезличить 30 ТБ данных, но под результат выделили виртуальную машину всего на 10 ТБ. Процесс никак не завершался, и мы не могли понять причину. Оказалось, итоговая база попросту не помещается в выделенный сегмент инфраструктуры. Сейчас это звучит как анекдот, но тогда нам было не до смеха. Это наглядная демонстрация того, как недостаточное планирование ресурсов сводит на нет все усилия по оптимизации маскирования.
Почему маскирование нельзя свести к нескольким скриптам?
Простой самописный скрипт подойдет только для небольших объемов однотипной информации и несложной инфраструктуры. При обработке массивов разнообразных данных подобный подход превращается в попытку заткнуть пальцем дыры в плотине. Разберем, почему так происходит.
Первая сложность — разнородный ландшафт СУБД внутри крупной компании. Когда нужно обезличивать данные сразу в нескольких базах, например, PostgreSQL и Oracle, каждый скрипт приходится дорабатывать отдельно. А при изменении схемы базы — вовсе переписывать заново. Во избежание подобных сложностей мы, например, в своем продукте предусмотрели такой алгоритм: правило настраивается один раз для типа данных и переиспользуется при подключении новых баз или изменении существующих.
Вторая сложность — необходимость категоризировать данные перед обезличиванием, то есть понять, какого они типа и где хранятся. Для этого нужны права на чтение исходной базы и на запись в целевую. На практике с настройкой этих прав часто возникают затруднения. И скрипт здесь не помощник: он не умеет определять персональные данные и не может сам очертить уровни доступа.
К тому же почти в каждой компании применяются кастомные поля и специфические форматы данных (скажем, номера договора, присущий конкретной организации). Под них нужно создавать отдельный шаблон и алгоритм генерации значений. В самописном скрипте это означало бы написание нового кода с нуля и его дальнейшее сопровождение. В свою очередь, специализированное решение позволяет настроить такие правила прямо в интерфейсе.
Еще один сценарий, по которому уже сходили некоторые наши клиенты — это развитие собственного решения по обезличиванию данных на базе open source. Всё выглядит здорово и классно на первых порах. Но через какое-то время приходит ощущение, что внутри появляется отдельная команда разработки со своими процессами и структурой.
И тут встает резонный вопрос: «А что с этим делать?» Появился почти рабочий, «полурыночный» продукт, в который мы инвестировали большое количество времени и ресурсов. Есть команда, которая его поддерживает и развивает (что тоже недешево).
Стоит ли выходить с этим решением на рынок или правильнее всё же остановиться и поручить эту задачу профильным компаниям? Пожалуй, оставлю этот вопрос открытым — пусть каждый сам для себя найдет на него ответ… ;)
О маскировании, как и о Римской империи, можно рассуждать часами. Но не будем слишком растягивать статью. Если у вас всё еще остались вопросы или вы хотите поделиться своими интересными кейсами по теме маскирования, не стесняйтесь и пишите в комментариях.
