Маскировка данных

Данные, подвергнутые маскировке, должны соответствовать следующим критериям:

1. Замаскированные данные должны быть понятными с точки зрения логики приложения. Например, рассмотрим ситуацию, когда необходимо замаскировать элементы почтовых адресов, а названия городов заменить другими названиями. Если приложение имеет возможность проверки почтового индекса или поиска по почтовому индексу, то маскировка не должна мешать корректному выполнению этих функций. Это же касается алгоритмов проверки номеров платёжных карт, страховых свидетельств и т. д.
2. Маскировка должна полностью исключать возможность восстановления реальных производственных данных из замаскированных. Например, может быть общеизвестным, что в организации работают 10 руководителей высшего звена, зарплата которых составляет свыше $300,000. Если в замаскированную базу данных отдела кадров включено 10 значений из указанного чис��ового диапазона (свыше $300,000), то злоумышленник может восстановить оставшиеся сведения методом реверс-инжиниринга. Поэтому маскировка данных должна проводиться таким образом, чтобы гарантировать защиту записей, содержащих персональные сведения, а не просто отдельных элементов в разрозненных полях и таблицах.

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

Метод замены можно применять для полей БД, содержащих данные различного рода: например, телефонные номера, почтовые индексы, номера платёжных карт, страховых свидетельств и т. д. Важно, что в случае с номерами пластиковых карт, фиктивные номера должны успешно проходить проверку по алгоритму Луна.

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

Перемешивание — очень распространённый способ маскировки данных. Он схож с методом замены, рассмотренным выше, но при перемешивании данные для замены берутся из той же колонки таблицы, что и исходные данные. Попросту говоря, данные в колонке перемешиваются случайным образом.

Однако, маскировка с использованием лишь одного этого метода имеет серьёзные недостатки. Злоумышленник, имеющий доступ к части реальных сведений, может восстановить остальные данные путём анализа методом «что, если?». Кроме того, перемешивание можно обратить вспять, дешифровав его алгоритм.

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

Метод дисперсии (разброса) применяется при работе c полями БД, содержащими финансовую информацию и даты. Этот метод заключается в отклонении замаскированного числового значения от исходного на определённую величину. Например, при маскировке ячеек, содержащих данные о зарплате сотрудников, отклонение от исходного значения может составлять ±10 %, поэтому замаскированная информация выглядит вполне реалистично и логично.

Это же касается колонок таблиц БД, содержащих даты. Если при маскировке требуется сохранить целостность демографической и актуарной информации, то применение отклонения на ± 120 дней к полям календарных дат сохранит их соотношение в таблице, но определить личность человека по дате его рождения, например, будет невозможно.

Шифрование — это наиболее сложный способ маскировки данных. Алгоритм шифрования обычно предполагает наличие «ключа», необходимого для дешифровки и просмотра исходных данных.

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

Шифрование также может сопровождаться преобразованием исходных данных в бинарный вид, что способно вызвать проблемы в работе приложений. Для выявления и устранения конфликтов внутри приложений необходимо проводить тестирование с передачей исходной информации тестировщикам, а это, в свою очередь, предполагает проверку задействованных в тестировании IT-специалистов службой безопасности. Прекрасная, в теории, идея при реализации на практике вызывает массу сложностей: шифрование отнимает много времени на тестирование и устранение выявленных недостатков.

Относительно недавно проблемы, связанные с шифрованием, были признаны разработчиками ПО и научным сообществом. Итогом изысканий в данной сфере стало появление новых алгоритмов шифрования, позволяющих сохранять формат исходных данных — FPE (format preserving encryption).

Иногда используется упрощённый метод маскировки данных, заключающийся в замене символов в записи БД нулями или произвольными символами (например, астерисками или «Х»). Очевидно, что этот способ позволяет лишь скрыть, а не замаскировать исходное значение. Практически во всех случаях подобный подход снижает степень целостности данных, поскольку вызывает проблемы с валидацией данных приложениями. Кроме того, «неестественные» значения в записях БД явно свидетельствуют о том, что к таблице применена маскировка.

Чаще всего этот способ маскировки применяется в процессе работы с платёжными картами. Например, операторы колл-центров интернет-магазинов могут видеть лишь последние четыре цифры номера кредитной карты клиента (XXXX XXXX XXXX 6789), но после подтверждения данных биллинговая система передаёт платёжной системе полный номер карты.

Эта система не очень эффективна для тест-систем, но полезна для биллингового сценария описанного выше. Он также широко известен как способ динамической маскировки данных^[6].

Существует два основных типа маскировки данных: статическая и динамическая маскировка.

Статическая маскировка данных обычно применяется при необходимости передачи базы данных для тестирования (например, при передаче на аутсорсинг). Администратор БД создаёт копию производственной базы данных, загружает её на отдельный сервер, сокращает объём содержащихся в ней сведений, оставляя только информацию, необходимую для проведения конкретных тестов, затем применяет маскировку, вносит необходимые изменения в программный код и отправляет замаскированную копию БД разработчикам или тестировщикам.

Динамическая маскировка (маскировка в режиме реального времени, маскировка «на лету») происходит в процессе передачи производственных данных разработчикам, без промежуточной записи на какие-либо носители информации.

Маскировка данного типа является наиболее рациональным решением для организаций, применяющих непрерывную интеграцию и не располагают временем, необходимым для создания и загрузки резервных копий баз данных. При непрерывной интеграции важна возможность постоянной пересылки небольших наборов производственных данных разработчикам для тестирования.

Динамическая маскировка происходит на основе атрибутов и заданных политик. Например:

• Врач может просматривать медицинские карты закреплённых за ним пациентов (фильтрация данных);
• Врач не может просматривать ИНН внутри медицинской карты (маскировка данных).

Динамическая маскировка также может применяться вместе с шифрованием данных в режиме реального времени, в частности при использовании шифрования с сохранением формата (Format-preserving encryption).

В последние годы все чаще применяется разработка приложений «в облаке», вне зависимости от того, будут ли эти приложения выполняться непосредственно в «облаке» или на локальном компьютере. Существуют различные методы создания наборов тестовых данных и перемещения их из локальных баз данных в «облако» или между разными средами в пределах «облака». Маскировка данных при этом неизбежно становится частью жизненного цикла ПО.

• Understanding DataMasking Whitepaper V2
• Data Masking Methodology
• What is Data Obfuscation
• Static and Dynamic Data Masking Explained, Gartner
• Data processing systems with format-preserving encryption and decryption engines
• Data Masking: What You Need to Know. (PDF)
• Data Masking Made Simple with DataSunrise (PDF)
• Dynamic vs. Static Data Masking (недоступная ссылка)
• Коротко о маскировке данных.