Какой лучший способ хранить и все же индексировать зашифрованные данные клиента?

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

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

Каковы некоторые передовые методы и подходы для хранения конфиденциальных данных, которые должны быть доступны для просмотра, поиска и/или сортировки уполномоченными людьми?

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

Ответ 1

В настоящее время я ищу решение этой же проблемы.

Одна из лучших идей, которые я нашел, - это статья Рауля Гарсии, http://blogs.msdn.com/b/raulga/archive/2006/03/11/549754.aspx.

Он предлагает использовать MAC, чтобы создать индексируемый столбец. Решение для MS SQL Server, но оно может быть применено к другой системе.

Ответ 2

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

Хеш-функции здесь не являются решением. Как следует из принятого ответа, индексация зашифрованных данных требует "слепого индекса", которому способствует MAC.

Допустим, вы шифруете номера социального страхования. Когда вы вставляете их в базу данных, вы можете сделать что-то вроде этого:

$ssn_encrypted = \Defuse\Crypto\Crypto::encrypt($ssn, $our_encryption_key);
$ssn_blind_idx = \hash_hmac('sha512', $ssn, $our_search_key);

А затем сохранить оба значения в базе данных. Когда вам нужно быстро получить значение на основе ввода SSN, вы можете пересчитать HMAC и выполнить поиск на основе этого.

База данных никогда не видит SSN, и ваши ключи шифрования никогда не должны проверяться в системе контроля версий (SVN, git и т.д.).

Ответ 3

Вам необходимо использовать новый класс алгоритмов шифрования под названием "Форматирование шифрования" (search Wiki).

Я бы счел разумным использовать такие алгоритмы без помощи просто потому, что они относительно новы к литературе, и это правило большого пальца, которое вы ожидаете, когда алгоритм будет анализироваться криптографией (скажем) за десять лет до вы можете использовать его для серьезных целей. Я также не уверен, существуют ли какие-либо стандарты для таких форматов шифрования. Существует только проект стандарта, который был представлен в 2010 году. http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/proposedmodes/ffx/ffx-spec.pdf

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

Ответ 4

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

Ответ 5

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

Если необходим индекс, защитите данные, удалив разрешения для этих столбцов в учетных записях DBA. Только учетная запись приложения сможет запрашивать эти столбцы. Безопасность - это ограниченный доступ, а не шифрование.

Вы должны принять компромиссы. Надеюсь, что кто-то приходит с ответом wiz bang, который доказывает, что я ошибаюсь!

Ответ 6

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

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

Итак, если БД утечка вместе с индексами, интеллектуальный анализ набора слов может выявить много информации. Например, обнаружив, что 50% корпоративной почты компании-поставщика программного обеспечения включают термин "webos", может выявить (возможно, секретный) факт, что компания работает над программным обеспечением для webos.

Теперь вы видите, что шифрование имеет ограниченную полезность в вашем случае. Более сильная общая безопасность БД может быть более важной, чем шифрование.

Ответ 7

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

blob(ID,SHA(secret-seed,data))

и индексы могут быть связаны с блобом как таковым:

word(SHA(secret-seed,blob-ID),value)

Теперь, когда вы запрашиваете некоторый blob, вы делаете:

select blob join word on SHA(secret-seed,ID) = word-ID where query IN value

Вы даже можете использовать разные семплы для ключей и фактических данных капли.

Ответ 8

Существуют базы данных, которые поддерживают зашифрованные индексы. Тот, который я знаю (с тех пор как я работал в компании), является UniVerse.

Ознакомьтесь с руководством по безопасности (1) "Автоматическое шифрование данных". Возможно, это даст вам некоторые идеи.

(1): http://docs.rocketsoftware.com, найдите "UniVerse Security Features"

Ответ 9

Во-первых, если хакер попадает на ваш сервер, у вас, вероятно, больше проблем, чем при чтении зашифрованной базы данных.

Шифрование замедлит работу. Это компромисс для укрепления этой слабой ссылки: незашифрованная база данных. KeePass (инструмент управления паролями с открытым исходным кодом) говорит заранее, что вы не должны шифровать все поля, потому что это замедлит все.

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