Привет, Хабр! На связи Дима Пичугин, тимлид в направлении комплаенса и безопасности данных. В статье рассказываю о пользе, которую подразделение информационной безопасности Т-Банка получило от каталога данных Data Detective и процессов вокруг него.
Как человек, который стоял у истоков появления каталога данных в Т-Банке и выстраивал процессы защиты чувствительных данных, я надеюсь, что статья поможет кому-то избежать некоторых наших ошибок. При желании можно творчески позаимствовать некоторые из наших наработок для решения своих задач.
Проблема защиты чувствительных данных
В рамках статьи под чувствительными данными будем понимать любую информацию, доступ к которой должен быть ограничен по веским причинам: регуляторные, этические, корпоративные и так далее.
Базовая цель защиты таких данных формулируется просто: доступ к чувствительным данным должны иметь только те, кто объективно не может без них обойтись в выполнении рабочих задач и только на время выполнения этих задач. Преследуя эту цель, мы ограничиваем поверхность атаки до необходимого минимума и снижаем вероятность несанкционированного доступа и утечки данных.
В ответах на вопрос «Как именно мы должны преследовать цель?» заканчивается обманчивая простота и начинается территория нюансов:
Нужны четкие и понятные «правила игры» по работе с чувствительными данными. Они должны отвечать на вопросы: почему мы считаем конкретно эти данные чувствительными? Какой риск мы митигируем их защитой? Каким политикам доступа мы следуем при работе с конкретными чувствительными данными?
Нужна карта местонахождения чувствительных данных. Мы не можем адекватно защитить данные, о существовании которых не подозреваем.
Нужны механизмы защиты и управления доступом к чувствительным данным, которые обеспечат соблюдение «правил игры» для всех известных вам чувствительных данных.
Каждый из нюансов сам по себе заслуживает отдельной статьи, как и возможные рецепты его приготовления. Сейчас сосредоточимся на карте местонахождения чувствительных данных, так как этот пункт вызвал у нас очень серьезные сложности.
Сложности были вызваны тремя взаимосвязанными причинами:
Разнообразие бизнес-процессов в нашей группе компаний и как итог — разнообразие данных, которые они производят. Уровень критичности одних и тех же данных может кардинально различаться в контексте разных бизнес-процессов. При этом сотрудники информационной безопасности далеко не всегда способны качественно оценить уровень критичности данных без помощи экспертов в конкретных бизнес-процессах.
Огромное количество пользователей платформы данных Т-Банка, которые должны соблюдать «правила игры»: больше 17 000 аналитиков ежемесячно используют данные Data Platform.
Масштаб платформы данных Т-Банка и как итог — огромное количество разнообразных данных. Подробнее о нашей платформе я рассказывал в предыдущей статье, тут для контекста ограничусь некоторыми цифрами:
Объем данных платформы — более 1,7 петабайт уникальных данных в GreenPlum.
Количество модельных таблиц данных и таблиц реплик систем-источников — больше 31 тысячи таблиц.
Количество запросов к данным в месяц — более 144 млн.
Забегая вперед: нам удалось разобраться с этими сложностями и в целом решить проблему. При этом мы не первые и не единственные, кто с ней столкнулся.
Безопасность до внедрения каталога данных
Платформа данных Т-Банка существует больше 18 лет, но я выбрал за точку отсчета 2020 год. В начале 2020 вышла в свет первая версия Data Detective (на тот момент Metadata Governance) и я, как руководитель команды, придумавшей этот инструмент, радовался первым 50 еженедельным пользователям.
На тот момент в платформе данных уже существовал достаточно зрелый (но не идеальный) процесс ограничения доступа к чувствительным данным.
Основные компоненты процесса:
Справочник типов чувствительных данных, который находится на поддержке подразделения информационной безопасности и кратко описывает основные типы чувствительных данных.
Процесс разметки данных на чувствительность на основе справочника типов. Разметка чувствительных данных является частью технического задания на создание таблицы и хранится в Confluence.
Функционал ограничения доступа к столбцам или строкам таблиц, размеченным как чувствительные данные.
В 2020 году процесс успешно работал, но не был лишен недостатков, наиболее существенными из которых были:
Недостаточный уровень качества разметки таблиц типами чувствительных данных, что оставляло часть чувствительной информации в широком доступе.
Непригодность Confluence на роль мастер-системы разметки чувствительных данных.
Проблема: недостаточный уровень качества разметки таблиц типами чувствительных данных
Влияние проблемы на Т-Банк: это основная проблема защиты чувствительных данных в платформе, с которой мы системно работаем и одерживаем верх. В 2020 году такая проблема повышала риск утечки неразмеченных чувствительных данных, потому что мы не применяли к ним политики защиты, соответствующие уровню их критичности, что могло повлечь:
регуляторные последствия в виде штрафов и уголовной либо административной ответственности за утечку;
репутационные потери среди клиентов и сотрудников;
потерю конкурентного преимущества на рынке.
Выявленные причины проблемы и решения:
У владельцев данных не было четкого понимания, что относится к чувствительным данным, а что — нет. Из-за этого у владельцев и у ИБ часто формировались параллельные, а порой противоречащие друг другу мнения, например по вопросу «Является ли город рождения клиента чувствительными данными?».
Мы пересмотрели фреймворк ведения справочника, определили ответственных и сформулировали их зоны ответственности. Дали четкое понимание, какие данные и почему подлежат защите в рамках конкретного типа чувствительных данных.
Для ключевых типов чувствительных данных мы запустили централизованный процесс актуализации справочника. По персональным данным сформировали четкий перечень защищаемых атрибутов, что позволило перейти от неформального подхода к управляемому: если атрибут есть в справочнике, он подлежит защите, если нет — решение остается за владельцем данных.
У владельцев данных не было формальной ответственности за качество разметки. В отдельных случаях это приводило к ожиданиям со стороны владельца, что все данные будут корректно защищены усилиями ИБ без его участия.
Мы сформулировали и описали роль владельца данных. Владельцы назначены для 99% объектов модели платформы данных. В их зону ответственности входит в том числе разметка таблиц на наличие чувствительных данных.
Для оценки качества выполнения разметки таблиц разработали прокси-метрику — количество не устраненных вовремя инцидентов некорректной разметки. Этот показатель рассчитывается для технических руководителей бизнес-линий и включен в регулярный верхнеуровневый отчет по метрикам данных как продукта.
Не было постоянного контроля со стороны ИБ за качеством разметки данных. Это замедляло исправление частых и очевидных ошибок со стороны владельцев данных и приводило к необходимости редких, но ресурсоемких проектов по миграции процессов аналитиков на корректные политики доступа.
Мы внедрили инструменты и процессы, поддерживающие выявление и разметку чувствительных данных. Разработали два основных инструмента: Hound — средство поиска чувствительной информации в содержимом таблиц по маскам — и Data Security Advisor — библиотеку на базе LLM, анализирующую описания полей для выявления чувствительности.
С помощью новых инструментов для поддержки владельцев данных мы внедрили процессы автоматического контроля:
Все таблицы, создаваемые инженерами данных, проходят ревью с использованием Data Security Advisor, который подсказывает возможное наличие чувствительных данных.
Все новые таблицы автоматически сканируются с помощью Hound на следующий день, и в случае обнаружения чувствительных данных разметка направляется на верификацию ИБ, после чего при необходимости инициируется инцидент для владельца данных.
Все таблицы в платформе данных сканируются с помощью Hound каждые 30 дней для выявления неразмеченных чувствительных данных, которые могли появиться в результате изменений или доработок источников данных.
Проблема: непригодность Confluence на роль мастер-системы разметки чувствительных данных
Влияние проблемы на Т-Банк: сама по себе эта проблема не оказывает значительного влияния, но в сочетании с предыдущей проблемой она существенно усложняет ее устранение из-за отсутствия прозрачной и общедоступной информации о расположении чувствительных данных в платформе.
Выявленные причины проблемы и решения:
Не было качественной интеграции Confluence с другими системами платформы данных. Отсутствие интеграции серьезно затрудняло автоматизацию любых процессов, связанных с разметкой чувствительных данных. Это привело к появлению четырех независимых сервисов, конвертирующих информацию из Confluence в формат, пригодный для работы других компонентов платформы. Естественно, информация в каждом из них «немного» отличалась от других.
Мы заменили Confluence на внутренний сервис собственной разработки — SensLabelHub (SLH). Новый сервис обеспечил единую точку правды по разметке чувствительных данных как на текущий момент, так и в ретроспективе. А еще у него простой и стабильный контракт для интеграции с любым компонентом платформы данных.
Внедрение SLH позволило:
Автоматизировать процессы, связанные с разметкой данных. Из-за этого снизилось влияние человеческого фактора на качество разметки за счет устранения рутинных действий и обеспечило ИБ возможность постоянного контроля за корректностью разметки на всех этапах ее жизненного цикла.
Упростить и автоматизировать проекты по миграции аналитических процессов на корректные политики доступа для устранения накопленных за годы ошибок в разметке данных.
Не было прозрачной и общедоступной информации о расположении чувствительных данных в платформе. Проблема возникла из-за структуры хранения в Confluence и ограничений его поиска. Это приводило к тому, что пользователи в большинстве случаев узнавали о наличии чувствительных данных только постфактум — когда их запросы неожиданно возвращали пустые значения строк или столбцов.
С появлением SLH стала возможна централизованная синхронизация разметки чувствительных данных во всех компонентах Data Platform, что практически исключило случаи расхождений и дублирования информации.
Кроме того, единая и консистентная разметка была сделана общедоступной для всех пользователей путем интеграции SLH с Data Detective. Это сократило количество обращений с вопросами типа «почему я не вижу данные N?».
Чем помог Data Detective
Важно отметить, что под каталогом данных в контексте статьи я подразумеваю не только программный продукт с веб-интерфейсом и базой данных, но и совокупность процессов управления данными, обеспечивающих его функционирование.
Польза Data Detective:
1. Каталог — единый источник информации по всем метаданным Data Platform с простым механизмом интеграции. Нельзя адекватно защитить данные, о существовании которых даже не подозреваешь. Он обеспечивает наличие полной, консистентной и актуальной информации о том, какие данные есть в платформе, где они находятся, кто за них отвечает и так далее.
Наличие в одном месте полной и актуальной информации по данным позволило нам реализовывать множество сценариев повышения защищенности данных.
С помощью каталога мы запустили процессы автоматического сканирования таблицы на наличие чувствительных данных на следующий день после ее появления. Загрузка информации в Data Detective служит триггером для запуска, а технические метаданные позволяют определить ее местонахождение и структуру.
Все таблицы описаны в одном каталоге, и это позволило создать Data Security Advisor, использующий данные Data Detective как обучающую выборку, и привлечь внешних специалистов к ручной перепроверке разметки для валидации корректности наших алгоритмов. А наличие информации о владельце данных позволило упорядочить и в дальнейшем автоматизировать процесс определения ответственного за инциденты некорректной разметки конкретной таблицы.
2. Каталог дал пользователям единый и удобный интерфейс для получения информации о данных, в том числе и по их разметке. Аналитики данных не являются экспертами в области информационной безопасности и не обязаны знать все виды чувствительных данных и правила работы с каждым из них.
Чаще всего они узнают о том, что работали с чувствительными данными, исключительно по сообщениям "access restricted" либо по внезапному появлению null-значений вместо еще вчера доступных данных. Интеграция SLH с Data Detective позволила пользователям всегда иметь доступ к актуальной информации о разметке чувствительных данных и подробные сведения о существующих типах чувствительных данных и правилах работы с ними. Такой подход сократил количество вопросов вида «куда делись данные?» и дал неожиданный дополнительный эффект в виде синергии с процессом Data Guard. Обладая полной информацией о том, что и как должно быть защищено, пользователи стали активнее сообщать нам об ошибках разметки чувствительных данных, что позволило нам устранить ряд неприятных уязвимостей.
Итоги пятилетки с каталогом данных
Каталог данных работает уже пять лет — с 2020 года. Мне кажется, нам еще далеко
до того уровня, когда я смогу сказать, что проблема безопасности данных в широком смысле полностью решена и можно расслабиться и ни о чем не беспокоится.
При этом я считаю, что с 2020 года мы достигли значительного прогресса и снизили риски получения несанкционированного доступа к нашим данным. С моей точки зрения, цифры всегда говорят правдивее слов, поэтому вот немного цифр, которых у нас получилось добиться за время работы с каталогом данных:
59 типов в 9 группах содержит справочник типов чувствительных данных.
Более 37 000 полей в 10 300 таблицах платформы данных содержат чувствительные данные.
58% — прирост количества размеченных полей с чувствительными данными за 2024 год (повышение качества поиска, ужесточение методологии и общей роста количества данных в платформе).
Более 3 000 алертов с подозрением на некорректную разметку чувствительных данных было автоматически сгенерировано за Q1.2025.
Более 500 инцидентов ИБ по некорректной разметке данных в новых объектах было заведено за Q1.2025 по итогу обработки алертов.
Более 60 случаев некорректной разметки данных были найдены пользователями за Q4.2024.
Более 80% — точность Data Security Advisor при простановке флага чувствительности данных ( >90% составляет точность внешних специалистов).
Более 53% — точность Data Security Advisor при простановке правильного кода типа чувствительных данных (надо поработать, чтобы было выше!).
Более 98,5% таблиц стабильно успешно ресканируются на наличие чувствительных данных раз в 30 дней.
Краткое послесловие
Обеспечение информационной безопасности в масштабах платформы данных Т-Банка с десятками компонентов и 17 000 пользователей — сложная и интересная задача. Мы регулярно сталкиваемся с множеством проблем, о которых готовы рассказать, и эта статья точно не последняя.
Приглашаю делиться в комментариях, какие аспекты работы Data Platform представляют для вас наибольший интерес, — постараюсь рассказать и о них тоже.