Обезличивание данных
опубликовано: ⏰ 8Небольшая статья о способах обезличивания данных. Зачастую в процессе разработки требуется тестировать новые версии систем на данных, приближенных к реальным. Суррогатные данные в большинстве случаев не закрывают все возможные варианты использования, что ведёт к “протеканию” ошибок до промышленного контура.
В статье, в основном, речь пойдет об очистке данных на уровне СУБД для использования на тестовых серверах. Но немного будут затронуты и другие варианты использования. Есть инструменты для обработки, например файловых артефактов, но это требуется реже и их можно найти отдельно. Список возможных инструментов для обезличивания скорее всего будет не полным, так как в основном использовал Greenmask. В основном это коммерческие решения, но есть и бесплатные с открытым кодом, что важно, если требуется аудит на чистоту кода для используемых инструментов.
Что такое обезличивание данных?
Обезличивание – это процесс преобразования данных таким образом, чтобы они перестали быть связанными с конкретными физическими или юридическими лицами, но при этом сохранили свою полезность для определенных задач (тестирование, разработка, аналитика).
Ниже в таблице приведены варианты обезличивания данных
| Анонимизация (Anonymization) | Необратимое удаление или модификация данных, делающая невозможной идентификацию субъекта данных без доступа к дополнительной информации, которая отсутствует или не может быть использована для идентификации. Цель – максимальная защита. |
| Псевдонимизация (Pseudonymization) | Замена данных на псевдонимы с использованием дополнительной информации (ключа). Позволяет восстановить исходные данные при наличии ключа. Сочетает защиту с сохранением полезности данных для анализа в контролируемой среде. |
| Маскировка (Masking) | Общий термин, часто используемый для обозначения статического или динамического сокрытия чувствительных частей данных. Может быть необратимым (как часть анонимизации) или обратимым (как псевдонимизация). |
| Обфускация (Obfuscation) | Более широкий термин, описывающий методы скрытия структуры или содержания данных (например, хеширование, искажение форматов, замена на фиктивные значения). Часто является частью других методов. |
Зачем нужно обезличивание данных? Кроме организации тестовых контуров есть ещё несколько причин:
- Организация среды разработки и тестирования – использование реалистичных, но обезличенных копий данных из промышленного контура позволяет разработчикам и тестировщикам эффективно работать, не рискуя утечкой реальной информации.
- Защита конфиденциальности – предотвращение несанкционированного доступа к PII, ПДн, PHI, финансовым и другим чувствительным данным. Эти данные необходимо скрывать и они не должны быть доступны неограниченному кругу лиц.
- Соответствие законодательным требованиям – обеспечение соответствия GDPR, CCPA, ФЗ-152, HIPAA, PCI DSS и другим нормативным актам. Это больше относится к передаче данных между системами, в том числе геораспределёнными и в меньшей степени к тестовым контурам.
- Данные для анализа – обеспечение аналитиков данными для построения моделей и получения отчётов без нарушения конфиденциальности.
- Снижение рисков утечек – даже при компрометации среды (например, взлом сервера тестирования) обезличенные данные не представляют прямой угрозы.
Не все данные являются одинаково чувствительными к утечкам. Можно выделить критически важные для защиты:
- PII, ПДн – ФИО, паспортные данные (серия, номер), СНИЛС, ИНН, email, номера телефонов, адреса проживания, фото, биометрические данные.
- Финансовые данные – номера банковских карт (PAN), IBAN, реквизиты счетов, кредитные рейтинги, транзакционные истории, суммы выплат сотрудникам и так далее.
- Медицинские данные – диагнозы, истории болезни, данные о лечении, результаты анализов, информация о страховании.
- Корпоративные конфиденциальные данные – внутренние идентификаторы сотрудников, схемы баз данных, конфигурации систем, информация представляющая коммерческую тайну.
- Учетные данные и ключи – пароли, API ключи, токены доступа. Хранение в открытом виде в СУБД подобных данных уже явное нарушение ИБ, но это встречается иногда.
Основные подходы к обезличиванию
Выбор подхода зависит от цели использования обезличенных данных, уровня требуемой защиты и готовности организации поддерживать такой подход в рамках выделенного бюджета. Например, динамическое обезличивание потребует вмешательства на уровне СУБД, что не всегда возможно. Более простой альтернативой может быть статическое обезличивание.
Статическая маскировка (Static Masking)
Создается статическая, обезличенная копия набора данных (обычно из промышленного контура) для использования в тестовых окружениях. Процесс обезличивания выполняется один раз или периодически по мере обновления данных.
| Плюсы | Минусы |
|---|---|
| Простота реализации и управления | Данные не обновляются в реальном времени |
| Низкая нагрузка на промышленный контур | Требуется ручной или полу-ручной процесс запуска обезличивания |
| Подходит для больших объемов данных |
Примеры:
- Полная замена значения на фиктивное. Например, “Иван Иванов” -> “Тестовый Пользователь”.
- Частичное обезличивание, с сокрытием части значения. Например, номер карты
9222-2222-2222-2222->9222-XXXX-XXXX-2222, emailtest@example.com->t***@e***.com. - Шифрование или дешифрование с обратимым преобразованием с использованием ключа (часто используется в псевдонимизации).
- Обфускация – хеширование, перестановка символов, сохранение формата с потерей исходной информации.
Динамическая маскировка (Dynamic Data Masking)
Более сложный вариант с обезличиванием данных “на лету” в реальном времени при запросе к базе данных или другому хранилищу. Пользователи видят разные данные в зависимости от своих привилегий.
| Плюсы | Минусы |
|---|---|
| Защита данных даже в промышленном контуре, | Повышенная нагрузка на СУБД из-за необходимости преобразования данных |
| Всегда актуальные данные | Сложность настройки и управления политиками доступа |
| Высока гибкость правил разграничения видимости и обезличивания данных на основе прав доступа | Повышенный риск утечки данных в случае некорректной настройки правил и прав доступа |
Примеры:
- Обезличивание по правам доступа и ролям: когда разные пользователи (разные роли) видят разное представление данных (например, аналитик видит частично замаскированный номер карты, а администратор – полный).
- Обезличивание по контексту: с зависимостью от контекста запроса. Например, запрос из приложения тестирования или запрос из административной консоли.
Псевдонимизация (Pseudonymization)
Замена прямых идентификаторов (например, ФИО, ID) на псевдонимы с помощью криптографического ключа. Исходные данные могут быть восстановлены только при наличии ключа. Для организации тестовых контуров не актуально, но думаю, нужно упомянуть.
| Плюсы | Минусы |
|---|---|
| Сохраняет реляционные связи между данными | Требует безопасного хранения и управления ключами (в идеале – в HSM - Hardware Security Module) |
| Позволяет проводить сложный анализ на псевдонимизированных данных | Не подходит для полной анонимизации |
Примеры:
- Научные исследования.
- Совместная обработка данных между организациями.
- Долгосрочное хранение данных для возможного восстановления.
Анонимизация (Anonymization)
Необратимое удаление или модификация атрибутов, делающая невозможной идентификацию субъекта данных без дополнительной информации, которой нет или которой нельзя воспользоваться. Позволяет максимально обезличить данные, но ценой потери полезной информации. Но даже такой вариант зачастую лучше, чем полностью суррогатные данные.
| Плюсы | Минусы |
|---|---|
| Максимально возможная степень защиты | Потеря полезной информации и контекста |
| Подходит для передачи данных третьим лицам | Сложность достижения истинной анонимизации, так как есть риск косвенной идентификации при комбинации данных |
| Низкий риск косвенной иентификации данных при корректной реализации | Сложность корректной реализации |
Примеры:
- Замена идентификаторов на случайно сгенерированные последовательности, что может приводить к нарушению согласованности данных.
- Использование метрик для оценки степени обфускации – k-анонимность, l-разнообразие, t-близость, обобщение (generalization), подавление (suppression).
Инструменты для обезличивания
Как писал выше, в основном использовал Greenmask. Решение не без проблем, но как простой и быстрый вариант для обезличивания данных вполне подходит. Для крупных систем со сложными правилами, всё-таки стоит рассмотреть коммерческие решения или PostgreSQL Anonymizer.
Бесплатные с открытым исходным кодом:
| Инструмент | Описание | Примеры |
|---|---|---|
| Greenmask | Преобразование данных на основе правил и шаблонов. | Пример |
| PostgreSQL Anonymizer | Расширение для PostgreSQL, может использоваться как для статического обезличивания, так и для динамического | Пример |
| pg_obfuscator | Обфускатор для PostgreSQL на основе clickhouse obfuscator | Пример |
| clickhouse-obfuscator | CLI, используется для обезлиичвания данных в ClickHouse |
Коммерческие решения:
| Инструмент | Комментарий |
|---|---|
| Jay Data | |
| Solix Data Masking | |
| Oracle Data Masking | |
| SQL Server Dynamic Data Masking | |
| MongoDB Atlas Field Level Encryption | Не совсем обезличивание, но можно скрыть данные |
| Informatica Data Masking | |
| IBM InfoSphere Guardium Data Encryption/Masking | |
| Protegrity Transparent Data Encryption/Masking |
Что стоит учитывать при обезличивании
Необходима предварительная инвентаризация и классификация данных по уровню чувствительности. Например, по матрице CIA (нет, не ЦРУ) – Конфиденциальность (Confidentiality), Целостность (Integrity), Доступность (Availability). Это необходимо, чтобы не заниматься бесполезным обезличиванием не критичных данных или пропустить то, что критично.
Обязательно задокументировать все политики и правила обезличивания для каждого типа данных и каждой среды (Dev, Test, Prod, Analytics).
- Документируйте всё: какие поля маскировать каким методом, кто имеет доступ к исходным данным и ключам.
- Фиксируйте все изменения в политиках маскировки. Ведите логи доступа к инструментам и операциям маскировки.
- Также необходимо ограничить доступ к самим инструментам обезличивания и к ключам псевдонимизации.
Настроить и автоматизировать процесс обезличивания через CI/CD. Например, при создании копии БД для тестирования и ETL/ELT. Это значительно снизит риск человеческих ошибков и ускорит сам процесс.
Обязательно требуется регулярное тестирование и валидация:
- Для статического необходим этап ревью полученных данных, чтобы убедиться, что копия обезличена корректно.
- Для динамического необходима проверка правил доступа, что все видят именно те данные, которые должны.
- При псевдонимизации необходимо убедиться, что восстановление работает только с ключом.
- Важно хранить ключи в защищенных системах (например, HSM) и строго контролировать доступ к ним с регулярной ротацией.
- Для анонимизации необходимо оценивать риск восстановления данных (если возможно).
Заключение
Задача обезличивания данных для организации тестовых контуров довольно полезна для организации адекватного тестирования релизов на приближенных к реальным данным. Как показывает практика, суррогатные данные не дают той полноты, которая необходима для отработки всех вариантов использования системы. При этом сама задача может быть относительно долгой, кропотливой и требовать внимательной работы к описанию правил и политик. Возможно, сейчас это можно автоматизировать с помощью ИИ. Например, для первичного описания правил с дальнейшей корректировкой человеком.