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

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

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

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

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

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

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

Solutions Collecting From Web of "Двустороннее шифрование БД безопасно даже от администратора"

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

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

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

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

Не может быть сделано.

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

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

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