Надежная де-идентификация при сохранении уникальных идентификаторов

Question

Я создаю хранилище данных о клиентах. Это включает в себя чтение CSV с различной информацией:

cell      email         gender  language  transaction
5551212   foo@bar.com     M        E         005

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

Одним из подходов, которые я рассмотрел, было хеширование ячейки + электронная почта с использованием алгоритма безопасного хеширования, такого как SHA2. Таким образом, сохраненные данные будут:

uid         gender  language  transaction
aW51SGvswX...     M        E         005

Когда я получаю дополнительные записи, я хеширую ячейку + электронная почта. Если это новое, я создаю нового клиента. Если хеш существует, увеличьте счетчик транзакций на клиенте.

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

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

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

Есть ли альтернативы этой системе? Есть что-то, что я пропускаю?

Спасибо

Justin

Answer 1

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

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

Answer 2

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