8.5 MySQL Enterprise Data Masking and De-Identification — MySQL 9.2

8.5 Маскирование данных и обезличивание в MySQL Enterprise

Примечание

Маскирование данных и обезличивание в MySQL Enterprise — это расширение, включенное в MySQL Enterprise Edition, коммерческий продукт. Дополнительную информацию о коммерческих продуктах см. на странице https://www.mysql.com/products/.

MySQL Enterprise Edition предоставляет возможности маскирования и обезличивания данных:

Преобразование существующих данных для маскирования и удаления идентификационных характеристик, например, изменение всех цифр номера кредитной карты, кроме последних четырех, на 'X' символов.
Генерация случайных данных, таких как адреса электронной почты и номера платежных карт.
Замена данных данными из словарей, хранящихся в базе данных. Словари легко дублируются стандартным способом. Управление ограничено авторизованными пользователями, которым предоставлены специальные привилегии, чтобы только они могли создавать и изменять словари.

Примечание

Маскирование и обезличивание данных в MySQL Enterprise первоначально реализованы в MySQL в виде библиотеки плагинов. Начиная с MySQL 9.2, MySQL Enterprise Edition также предоставляет компоненты для доступа к возможностям маскирования и обезличивания данных. Сведения о сходствах и различиях см. в таблице 8.46 «Сравнение компонентов маскирования данных и элементов плагина».

Если вы впервые используете MySQL Enterprise Data Masking and De-Identification, рекомендуется установить компоненты для доступа к текущим усовершенствованиям, доступным только с инфраструктурой компонентов.

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

Приложения, использующие конфиденциальные данные, могут защитить их, выполнив маскирование данных и разрешив использование частично замаскированных данных для идентификации клиента. Например, колл-центр может попросить клиентов предоставить последние четыре цифры номера социального страхования.
Приложения, которые требуют данных в правильном формате, но необязательно исходных данных, могут синтезировать образцовые данные. Например, разработчик приложения, тестирующий валидаторы данных, но не имеющий доступа к исходным данным, может синтезировать случайные данные в том же формате.
Приложения, которые должны заменить реальное имя термином из словаря для защиты конфиденциальной информации, но при этом предоставить приложениям реалистичное содержимое. Например, пользователю в процессе обучения, которому запрещено просматривать адреса, выдаётся случайный термин из словаря city names вместо реального названия города. Вариантом этой ситуации может быть замена реального названия города только в том случае, если оно есть в usa_city_names.

Пример 1:

Медицинские исследовательские учреждения могут хранить данные пациентов, которые содержат смесь персональных и медицинских данных. Это может включать генетические последовательности (длинные строки), результаты тестов в формате JSON и другие типы данных. Хотя данные могут в основном использоваться программным обеспечением для автоматического анализа, доступ к данным генома или результатам тестов конкретных пациентов всё ещё возможен. В таких случаях для обезличивания этой информации следует использовать маскирование данных.

Пример 2:

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

Обработка большого количества финансовых транзакций в секунду.
Хранение большого объёма данных, связанных с транзакциями.
Защита данных, связанных с транзакциями, с жёсткими требованиями к персональным данным.
Обработка жалоб клиентов на транзакции с использованием обратимых или частично замаскированных данных.

Типичная транзакция может включать множество типов конфиденциальной информации, включая:

Номер кредитной карты.
Тип и сумма транзакции.
Тип продавца.
Криптограмма транзакции (для подтверждения легитимности транзакции).
Геолокацию терминала с GPS (для выявления мошенничества).

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

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

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

Маскирование и обезличивание являются ключевыми для соблюдения нормативных требований, поэтому MySQL Enterprise Data Masking and De-Identification может помочь разработчикам приложений удовлетворить требования конфиденциальности:

PCI – DSS: Данные платежных карт.
HIPAA: Конфиденциальность медицинских данных, Закон об информационных технологиях в здравоохранении для экономического и клинического здравоохранения (закон HITECH).
Общая директива ЕС по защите данных (GDPR): Защита персональных данных.
Закон о защите данных (Великобритания): Защита персональных данных.
Sarbanes Oxley, GLBA, Закон США о борьбе с терроризмом, Закон о противодействии краже личности 1998 года.
FERPA – Данные о студентах, NASD, CA SB1386 и AB 1950, государственные законы о защите данных, Базель II.

В следующих разделах описываются элементы MySQL Enterprise Data Masking and De-Identification, обсуждается, как их установить и использовать, а также предоставляется справочная информация об их элементах.