Это жизнеспособно и необходимо для шифрования байтов? - PullRequest
0 голосов
/ 15 мая 2010

У нас есть требование от клиента, что если кто-то получает доступ к базе данных, все данные, которые включают в себя личную информацию, должны быть зашифрованы, чтобы при выборе звонков они не могли видеть ничего в виде открытого текста. Теперь это не проблема для Strings, но как насчет bytearrays? (потенциально это может быть довольно много (несколько сотен Мб))

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

Ответы [ 2 ]

2 голосов
/ 15 мая 2010

Похоже, что это подход, который даст вам немного дополнительной безопасности при больших усилиях, не говоря уже о дополнительных головных болях отладки запросов с использованием зашифрованных данных!

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

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

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

РЕДАКТИРОВАТЬ: я написал это с учетом локальной базы данных, так как ОП говорит о том, что злоумышленник овладевает базой данных. С другой стороны, если вы используете удаленный сервер базы данных, который физически защищен, протокол с шифрованием транспортного уровня, например HTTPS даст вам то, что вы хотите. Злоумышленник в середине не сможет понять, какие данные передаются между вашей программой и базой данных. Это также прозрачно - ваш код доступа к данным не нужно менять вообще.

1 голос
/ 15 мая 2010

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

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...