Шифрование сторонних учетных данных - PullRequest
4 голосов
/ 30 ноября 2009

У меня есть приложение, в котором мне нужно хранить учетные данные третьих сторон для таких сервисов, как Amazon S3, FTP, SFTP и т. Д.

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

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

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

Любой совет по этому вопросу будет очень ценным!

Ответы [ 3 ]

3 голосов
/ 30 ноября 2009

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

Если вам нужна базовая защита, вы можете разрешить MySQL ее обрабатывать с помощью комбинаций имени пользователя и пароля и установить права доступа для данной учетной записи. Однако, поскольку механизм контроля доступа в mysql не является детализированным (вы можете устанавливать правила контроля доступа только для таблицы, а не для строки), это, вероятно, приведет к неправильному дизайну базы данных.

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

Другой подход заключается в шифровании ваших данных в базе данных. Вы можете сделать это, получив симметричный ключ из пароля и зашифровав учетные данные этими данными. Выгода здесь, конечно, в том, что ваш протокол деривации ключей должен быть хорошим, и это нелегко сделать (поэтому, если вы выберете это, я советую вам использовать существующие протоколы деривации ключей или использовать потоковый шифр). Посмотрите здесь список потокового шифра http://en.wikipedia.org/wiki/Stream_cipher.

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

1 голос
/ 01 декабря 2009

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

0 голосов
/ 01 декабря 2009

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

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

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