Безопасное хранение конфиденциальных данных в базе данных - PullRequest
4 голосов
/ 11 марта 2012

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

По сути, у меня есть таблица patient, в которой хранится общедоступная (= не конфиденциальная) информация о пациентах. Некоторая другая информация (например, имя, адрес) является частной и должна храниться в безопасном месте. Я использую пару открытый / закрытый ключ, сгенерированный PHP OpenSSL и отправленный менеджером сайта. Парольную фразу знают только люди, которым разрешен доступ к частным данным (в основном, медицинские работники). Я хотел бы хранить их в другой таблице. Первый вопрос , BLOB лучший тип столбца (с MySQL) для хранения двоичных данных. Или я должен преобразовать их (например, с base64) и сохранить их в столбце VARCHAR?

Моя patient_secure_data таблица выглядит так:

id          INT AUTO_INCREMENT
patient_id  INT (FOREIGN KEY to patient.id)
key         VARCHAR(63)
data        BLOB
env         BLOB

Это таблица значений ключей, где значение запечатано openssl_seal. Мне нужно сохранить третий параметр ($env_keys), чтобы иметь возможность расшифровывать данные. Итак, второй вопрос , зачем мне это env_keys, если при звонке с openssl_open?

у меня есть пароль

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

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

С уважением,

Гийом.

Извините, если мой язык не идеален, я не являюсь носителем английского языка ... Надеюсь, я дал понять.

Ответы [ 2 ]

2 голосов
/ 11 марта 2012

1 - BLOB - это мое предпочтение, потому что кодирование его в base64 увеличит пространство и время обработки (поскольку вам придется также декодировать base64 перед расшифровкой)

2 - openssl_seal не дает вам ключ, который использовался для шифрования данных. Цель env_keys - хранить зашифрованную форму сгенерированного ключа. Когда вы вызываете openssl_open, вы даете ему этот ключ конверта и закрытый ключ, необходимый для расшифровки ключа конверта. Закрытый ключ должен совпадать с открытым ключом, который использовался для генерации ключа конверта.

3 - Если ваш закрытый ключ требует парольную фразу, то технически ваши данные относительно безопасны. Даже если у них есть ключ конверта и закрытый ключ, они не смогут его использовать ... но насколько безопасна ваша пароль? Нужно понять, что вы можете почти никогда не гарантировать полностью защищенную схему, но вы определенно можете использовать ее для хакеров. Используйте свое воображение здесь. Кстати, ваш пароль в текстовом виде в вашем коде?

0 голосов
/ 11 марта 2012
  1. Все, что превышает 500 символов, вероятно, должно быть большим двоичным объектом (или сгустком).

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

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