Как анонимизировать новые записи журнала, не нарушая отношения между старыми и новыми данными? - PullRequest
Новая
       11

Как анонимизировать новые записи журнала, не нарушая отношения между старыми и новыми данными?

2 голосов
/ 12 мая 2009

Я создаю записи в журнале о действиях пользователя. По соображениям конфиденциальности их необходимо анонимизировать через N дней. Однако мне также нужно создавать отчеты по этим анонимным данным.

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

Пример:

Пользователь Фрэнк Мюллер купил 3 банки супа.

Три дня спустя пользователь Фрэнк Мюллер попросил возмещение за 3 банки супа.

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

Сталкивались ли вы с таким сценарием раньше? Какие у меня есть варианты? Очевидно, мне нужно пойти на какой-то компромисс - что оказалось для вас эффективным? Как максимально эффективно использовать такие данные?

1 Ответ

7 голосов
/ 12 мая 2009

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

  • Разделите ваш анализ и базы данных OLTP. Минимизируйте количество людей, которые имеют доступ к обоим.
  • Держите ключ HMAC в секрете для приложения, которое копирует данные в базу данных анализа, недоступно ни из одной базы данных. Возможно, приложение сгенерирует его при установке и запутает его с помощью жестко закодированного ключа, так что ни системные администраторы, ни разработчики программного обеспечения не сочтут его тривиальным без сговора.
  • Не копируйте реальные имена и адреса или любые эквивалентные или легко связываемые ключи, такие как номер пользователя, номера счетов и т. Д. , из базы данных OLTP без их хеширования.

Если вы сделаете это, есть два основных пути атаки, чтобы получить реальную личность от псевдонима.

  • Прямая атака: получите ключ HMAC, вычислите псевдоним для каждого известного пользователя и отмените поиск в полученной таблице. (HMAC является необратимым: при наличии только псевдонима и ключа вы не можете получить исходное значение.)
  • Атака объединения информации: без знания ключа и списка идентификаторов следующая лучшая вещь - просто попытаться сопоставить псевдонимные данные с другими данными - возможно, даже украденной копией базы данных OLTP.

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

...