Подтвердить что ты не робот

Двустороннее шифрование БД безопасно даже от администратора

У меня есть интересная проблема шифрования. Я не знаю, можно ли его решить, но здесь идет:

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

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

Кто-нибудь знает, как выйти из этого?

PS: Это настоящая проблема. Моя компания является фанатом абсолютной безопасности (ISO 27001 и все), и мне было поручено разработать систему с вышеупомянутой функциональностью. Кстати, я использую PHP script и MySQL.

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

4b9b3361

Ответ 1

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

Существуют также способы шифрования ключа агента восстановления, чтобы люди из m-out-of-n согласились использовать его.

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

Я скопировал терминологию из Microsoft Encrypting File System, которая реализовала эту схему.

Ответ 2

Невозможно выполнить.

Во всех случаях кто-то должен иметь возможность воссоздать ключ для его расшифровки. Рассмотрим варианты:

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

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