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

Question

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

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

Пример:

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

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

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

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

Answer 1

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

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

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

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

Pseudonymous наборы данных notoriously vulnerable для информационных атак фьюжн - вы должны удалить или «размытость» много ключевых коррелирующих информации, чтобы сделать набор данных устойчивы к таким атакам, но точно, сколько вам нужно раздеться это topic of current research.