Насколько безопасна моя процедура псевдонимизации?

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

• Случайное присвоение идентификатора каждому пациенту. Процедура позволяет избежать дублирования (используя образец(), среди прочего)
• Создайте соль для каждого пациента (используя соль <- bcrypt::gensalt(log_rounds= 5))
• Создайте хешированный идентификатор для каждого пациента, используя идентификатор и соль (используя id_hashed <- bcrypt::hashpw(id, соль = соль))

Я сохраняю данные в трех разных файлах

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

На практике это будет использоваться следующим образом:

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

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

Примечания:

• Я знаю, что теоретически нет необходимости в случайно сгенерированных идентификаторах, потому что мы можем использовать данные пациента (имя и дату рождения) и соль для создания хешированного идентификатора. Нам не нужен этот подход, потому что моим коллегам не нравится иметь очень длинные хешированные идентификаторы в фактической базе данных (третий файл).
• Описание bcrypt:: hashpw() говорит: «Bcrypt используется для безопасного хеширования паролей. Основное отличие от обычных алгоритмов дайджеста таких как MD5 или SHA256, заключается в том, что алгоритм bcrypt специально разработан для интенсивного использования ЦП в для защиты от атак грубой силы. Точная сложность алгоритма настраивается через параметр log_rounds. Интерфейс полностью совместим с интерфейсом Python." (см. здесь ).

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

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

Это проблема ИТ-безопасности, для которой нет полного криптографического решения. Стандартное решение — ограничить доступ на чтение к файлам. Лучшее, что я вижу практически возможным без таких ограничений, это то, что знание/угадывание точного имени и даты рождения пациента необходимо для деанонимизации его данных, а проверка предположения требует вычислительных затрат. Общая идея состоит в том, чтобы либо

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

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