Безопасность базы данных не так безопасна - PullRequest
5 голосов
/ 29 июня 2011

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

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

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

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

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

Я что-то здесь упускаю?

Ответы [ 3 ]

2 голосов
/ 29 июня 2011

Существует старая поговорка «Шифрование - это просто, управление ключами - это сложно». И это очень применимо здесь.

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

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

1 голос
/ 29 июня 2011

Лучшим вариантом будет использование сертификатов, и это легко сделать в большинстве СУБД.

0 голосов
/ 29 июня 2011

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

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

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

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