stringtranslate.com

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

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

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

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

Фон

Данные, используемые при любой маскировке или сокрытии данных, должны оставаться значимыми на нескольких уровнях:

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

Методы

Замена

Замена — один из наиболее эффективных методов маскировки данных, позволяющий сохранить подлинный вид и содержание записей данных.

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

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

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

Перетасовка

Метод перетасовки — очень распространенная форма запутывания данных. Он похож на метод подстановки, но он выводит набор подстановки из того же столбца данных, который маскируется. Проще говоря, данные случайным образом перетасовываются внутри столбца. [3] Однако, если использовать его изолированно, любой, кто имеет хоть какое-то знание исходных данных, может затем применить сценарий «что если» к набору данных, а затем собрать воедино настоящую личность. Метод перетасовки также открыт для обратного использования, если алгоритм перетасовки может быть расшифрован. [ необходима цитата ]

Перетасовка данных позволяет преодолеть сомнения относительно использования искаженных или измененных конфиденциальных данных, поскольку она сохраняет все желаемые свойства искажения, при этом демонстрируя лучшие результаты, чем другие методы маскировки, как с точки зрения полезности данных, так и риска раскрытия. [3]

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

Разница в числах и датах

Метод числовой дисперсии очень полезен для применения к финансовым и информационным полям, управляемым датами. По сути, метод, использующий этот способ маскирования, все еще может оставить значимый диапазон в наборе финансовых данных, например, в платежной ведомости. Если применяемая дисперсия составляет около +/- 10%, то это все еще очень значимый набор данных с точки зрения диапазонов зарплат, выплачиваемых получателям.

То же самое относится и к информации о дате. Если общий набор данных должен сохранять целостность демографических и актуарных данных, то применение случайной числовой дисперсии +/- 120 дней к полям даты сохранит распределение даты, но все равно не позволит прослеживать обратную связь с известным субъектом на основе его известной фактической даты или рождения или известного значения даты для любой маскируемой записи.

Шифрование

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

Недавно проблема шифрования данных с сохранением свойств сущностей получила признание и новый интерес среди поставщиков и академических кругов. Новая задача породила алгоритмы, выполняющие шифрование с сохранением формата . Они основаны на принятом алгоритмическом режиме Advanced Encryption Standard (AES), признанном NIST. [4]

Обнуление или удаление

Иногда применяется очень упрощенный подход к маскировке путем применения нулевого значения к определенному полю. Подход с нулевым значением на самом деле полезен только для предотвращения видимости элемента данных.

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

Маскировка

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

Это обычно применяется к данным кредитных карт в производственных системах. Например, оператор в колл-центре может выставить счет за товар на кредитную карту клиента. Затем он указывает ссылку на счет для карты с последними 4 цифрами XXXX XXXX xxxx 6789. Как оператор, он может видеть только последние 4 цифры номера карты, но как только биллинговая система передает данные клиента для списания, полный номер раскрывается системам платежного шлюза.

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

Дополнительные сложные правила

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

Разные типы

Маскирование данных тесно связано с построением тестовых данных. Два основных типа маскирования данных — статическое и маскирование данных «на лету».

Статическая маскировка данных

Статическое маскирование данных обычно выполняется на золотой копии базы данных, но может также применяться к значениям в других источниках, включая файлы. В средах БД администраторы производственных баз данных обычно загружают резервные копии таблиц в отдельную среду, сокращают набор данных до подмножества, которое содержит данные, необходимые для определенного раунда тестирования (метод, называемый «подмножество»), применяют правила маскирования данных, пока данные находятся в состоянии стазиса, применяют необходимые изменения кода из системы управления исходным кодом и/или отправляют данные в нужную среду. [9]

Детерминированное маскирование данных

Детерминированное маскирование — это процесс замены значения в столбце тем же значением, будь то в той же строке, той же таблице, той же базе данных/схеме и между экземплярами/серверами/типами баз данных. Пример: база данных имеет несколько таблиц, каждая из которых содержит столбец с именами. При детерминированном маскировании имя всегда будет заменено тем же значением — «Lynne» всегда станет «Denise» — где бы в базе данных ни находилось «Lynne». [10]

Сокрытие статистических данных

Существуют также альтернативы статическому маскированию данных, которые опираются на стохастические возмущения данных, которые сохраняют некоторые статистические свойства исходных данных. Примерами методов обфускации статистических данных являются дифференциальная конфиденциальность [11] и метод DataSifter . [12]

Маскировка данных «на лету»

Маскировка данных «на лету » [13] происходит в процессе передачи данных из среды в среду без касания ими диска по пути. Та же техника применяется к «Динамической маскировке данных», но по одной записи за раз. Этот тип маскировки данных наиболее полезен для сред, которые выполняют непрерывное развертывание, а также для сильно интегрированных приложений. Организации, которые используют методы непрерывного развертывания или непрерывной доставки , не имеют времени, необходимого для создания резервной копии и загрузки ее в золотую копию базы данных. Таким образом, непрерывная отправка меньших подмножеств (дельт) маскированных тестовых данных из производства важна. В сильно интегрированных приложениях разработчики получают каналы из других производственных систем в самом начале разработки, а маскировка этих каналов либо игнорируется, либо не закладывается в бюджет до более позднего времени, что делает организации несоответствующими. Наличие маскировки данных «на лету» становится необходимым.

Динамическое маскирование данных

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

Динамическое маскирование данных допускает несколько сценариев, многие из которых основаны на строгих правилах конфиденциальности, например, на правилах валютного управления Сингапура или правилах конфиденциальности в Европе.

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

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

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

Существует шесть возможных технологий применения динамической маскировки данных:

  1. В базе данных: База данных получает SQL и применяет перезапись к возвращенному замаскированному набору результатов. Применимо для разработчиков и администраторов баз данных, но не для приложений (поскольку пулы соединений, кэширование приложений и шина данных скрывают идентификационные данные пользователя приложения от базы данных и также могут привести к повреждению данных приложения).
  2. Сетевой прокси между приложением и базой данных: захватывает SQL и применяет перезапись к запросу select. Применимо для разработчиков и администраторов баз данных с простыми запросами 'select', но не для хранимых процедур (в которых прокси идентифицирует только exec.) и приложений (поскольку пулы соединений, кэширование приложений и шина данных скрывают идентификационные данные пользователя приложения от базы данных и также могут привести к повреждению данных приложения).
  3. Прокси-сервер базы данных: это разновидность сетевого прокси-сервера. Прокси-сервер базы данных обычно развертывается между приложениями/пользователями и базой данных. Приложения и пользователи подключаются к базе данных через прокси-сервер безопасности базы данных. Способ подключения приложений и пользователей к базе данных не меняется. Также нет необходимости устанавливать агент на сервере базы данных. SQL-запросы переписываются, но при реализации этот тип динамической маскировки данных также поддерживается в процедурах хранения и функциях базы данных.
  4. Сетевой прокси между конечным пользователем и приложением: идентификация текстовых строк и их замена. Этот метод не применим для сложных приложений, поскольку он легко может вызвать повреждение, если замена строк в реальном времени будет применена непреднамеренно.
  5. Изменения кода в приложениях и XACML: изменения кода обычно трудно выполнить, невозможно поддерживать и неприменимы для упакованных приложений.
  6. В среде выполнения приложения: Инструментируя среду выполнения приложения, определяются политики для перезаписи набора результатов, возвращаемых из источников данных, при этом обеспечивая полную видимость для пользователя приложения. Этот метод является единственным применимым способом динамической маскировки сложных приложений, поскольку он позволяет контролировать запрос данных, результат данных и результат пользователя.
  7. Поддерживается плагином браузера: в случае SaaS или локальных веб-приложений надстройки браузера могут быть настроены для маскировки полей данных, соответствующих точным селекторам CSS . Это может быть достигнуто либо путем маркировки конфиденциальных полей в приложении, например, классом HTML , либо путем поиска правильных селекторов, которые идентифицируют поля, которые необходимо скрыть или замаскировать.

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

В последние годы организации все чаще разрабатывают свои новые приложения в облаке, независимо от того, будут ли конечные приложения размещаться в облаке или локально. Облачные решения на данный момент позволяют организациям использовать инфраструктуру как услугу , платформу как услугу и программное обеспечение как услугу . Существуют различные режимы создания тестовых данных и перемещения их из локальных баз данных в облако или между различными средами в облаке. Динамическое маскирование данных становится еще более важным в облаке, когда клиентам необходимо защищать данные PII, полагаясь на облачных поставщиков для администрирования своих баз данных. Маскирование данных неизменно становится частью этих процессов в жизненном цикле разработки систем (SDLC), поскольку соглашения об уровне обслуживания (SLA) сред разработки обычно не такие строгие, как SLA производственных сред, независимо от того, размещается ли приложение в облаке или локально.

Смотрите также

Ссылки

  1. ^ "Специалисты по управлению информацией". GBT . Получено 24 августа 2017 г.
  2. ^ Кобб, Майкл. «Что такое маскировка данных? Методы, типы и лучшие практики». SearchSecurity . Получено 2022-11-17 .
  3. ^ аб Муралидхар, Кришнамурти; Сарати, Ратиндра (1 мая 2006 г.). «Перетасовка данных: новый подход к маскировке числовых данных». Наука управления . 52 (5): 658–670. дои : 10.1287/mnsc.1050.0503. ISSN  0025-1909.
  4. ^ "Системы обработки данных с механизмами шифрования и дешифрования, сохраняющими формат" . Получено 24 августа 2017 г. .
  5. ^ "Решения IRI по динамическому маскированию данных" . Получено 24 августа 2017 г.
  6. ^ "Динамическое маскирование данных с помощью IBM Optim" . Получено 24 августа 2017 г. .
  7. ^ «Маскировка данных: что вам нужно знать» (PDF) . Net2000 Ltd . Получено 24 августа 2017 г. .
  8. ^ "Объяснение правил синхронизации и маскирования сложных данных" . Получено 24 августа 2017 г. .
  9. ^ "Статические функции маскирования данных". IRI . Получено 24 августа 2017 г. .
  10. ^ "Детерминированное маскирование данных". DATPROF . 2020-03-19 . Получено 2020-04-29 .
  11. ^ US 7698250, Синтия Дворк и Фрэнк Макшерри, «Различная конфиденциальность данных», опубликовано 13 апреля 2010 г., передано Microsoft Corp (первоначально) и Microsoft Technology Licensing LLC (текущее) 
  12. ^ Марино, Симеоне; Чжоу, Нина; Чжао, И; Чжоу, Нина; У, Цючэн; Динов, Иво (2018). «DataSifter: статистическое запутывание электронных медицинских записей и других конфиденциальных наборов данных». Журнал статистических вычислений и моделирования . 89 (2): 249–271. doi :10.1080/00949655.2018.1545228. PMC 6450541. PMID 30962669  . 
  13. ^ "Устранение рисков соответствия — маскировка данных в облаке" . Получено 24 августа 2017 г.