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

Question

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

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

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

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

Answer 1

Обновление : Вы захотите проверить 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 и др.).

Answer 2

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

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

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

Answer 3

Вам необходимо использовать новый класс алгоритмов шифрования, который называется Format Preserving Encryption (поиск по вики).

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

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

Answer 4

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

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

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

Answer 5

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

Answer 6

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

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

(1): http://docs.rocketsoftware.com, поиск по "UniVerse Security Features"

Answer 7

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

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

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

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

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

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

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

Answer 8

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

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

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

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

Answer 9

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

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

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