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

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

Примечание

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

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

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

Примечание

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

Если вы используете 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, обсуждается, как установить и использовать его, и предоставляется справочная информация по его элементам.