2015-04-25 5 views
1

Меня попросили защитить конфиденциальные данные, которые хранятся в базе данных Mysql. Эта база данных содержит несколько таблиц, среди которых есть критические данные, к которым ТОЛЬКО следует обращаться с помощью API, который выполняется в Django. К этому API будет только определенное количество людей, которые будут иметь к нему доступ, поэтому они будут единственными лицами, которые смогут получить доступ к данным из этой таблицы.как безопасно хранить секретный ключ шифрования

Таким образом, на данный момент проблема заключается в том, что все имеют доступ к базе данных и к этой таблице, поэтому мы решили зашифровать все данные из этой таблицы с помощью AES с помощью функций AES_ENCRYPT() и AES_DECRYPT() согласно https://dev.mysql.com/doc/refman/5.5/en/encryption-functions.html).

Итак ... до этого момента все в порядке, но главная проблема заключается в том, как сохранить ключ AES, используемый для шифрования/дешифрования. После некоторого мозгового штурма с моими коллегами и Google, я обнаружил, что лучше всего будет использовать Key Wrapper (http://en.wikipedia.org/wiki/Key_Wrap), который состоит в шифровании исходного ключа (главного ключа) с использованием ключей, принадлежащих лицам, которые могут доступ к этому API, который взаимодействует с таблицей базы данных. Итак, я думал об шифровании этого ключа, используя открытый ключ открытого ключа каждого человека, который имеет доступ к этому API, и храните зашифрованную версию в таблице, доступ к которой любой может получить. И тогда, когда пользователю нужен мастер-ключ, ему нужно только получить зашифрованный ключ, расшифровать его своим личным ключом и, наконец, он/она будет иметь ключ в сеансе входа, чтобы они могли используйте его через API.

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

+0

Прежде всего вам нужно спросить себя, почему каждый человек имеет доступ к этим данным. Считаете ли вы использование инструкции [GRANT] (https://dev.mysql.com/doc/refman/5.1/en/grant.html)? –

+0

Это не работает. У меня очень четкие приказы, и есть ограничения, которые необходимо учитывать. Это не зависит от меня ... это как раз то, как это ... моя задача - убедиться, что только уполномоченные лица смогут получить доступ к конфиденциальным данным. – user2435860

+1

Возможно, это лучше подходит для [ИТ-безопасности] (http://security.stackexchange.com) –

ответ

0

Подход с использованием одного ключа для шифрования содержимого («ключ содержимого шифрования» или CEK), то шифрование что ключ с ключом каждого уполномоченного получателя («ключ ключ шифрования» или KEK) является хорошим и используется в ряде стандартных протоколов, таких как S/MIME, PGP и т. д.

Но: в этой среде, где вы будете хранить личные ключи для авторизованных пользователей? Как вы будете держать их в тайне?

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

Смежные вопросы