Как вы обрабатываете пароли или учетные данные для автономных приложений? - PullRequest
Новая
       4

Как вы обрабатываете пароли или учетные данные для автономных приложений?

3 голосов
/ 20 апреля 2010

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

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

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

Как бы вы справились с этиме?Где бы вы поместили эти учетные данные или защитили бы их от взлома?Или как бы вы подключились к своим базам данных в этом сценарии?

Ответы [ 3 ]

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

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

Взгляните на архитектуру криптографии Java - шифрование на основе пароля . Концепция довольно проста: вы шифруете / дешифруете поток XML с помощью ключа, полученного из пароля пользователя, перед (де) сериализацией файла.

Я только догадываюсь о том, что требуют ваши соображения безопасности / соответствия, но определенно стоит учесть:

  1. Требуется надежные пароли .
  2. Постарайтесь минимизировать время, в течение которого вы расшифровываете чувствительный материал.
  3. Во время работы аккуратно обращайтесь с чувствительным материалом - не оставляйте его открытым в глобальном объекте; вместо этого постарайтесь максимально уменьшить область применения чувствительного материала. Например, инкапсулируйте все расшифрованные данные как частные в одном классе.
  4. Подумайте, как вам следует обращаться со случаем, когда теряется пароль к файлу конфигурации. Возможно, все просто: вы можете просто создать новый конфигурационный файл?
  5. Требуется надежный пароль и файл ключа пользователя для доступа к файлу конфигурации. Это позволит пользователю безопасно хранить ключевой файл; и если какая-либо часть информации будет случайно раскрыта, она бесполезна без того и другого.

Хотя это, вероятно, излишне, я настоятельно рекомендую взглянуть на Прикладная криптография Брюса Шнайера. Это дает отличный взгляд в область крипто.

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

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

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

0 голосов
/ 21 апреля 2010

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

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

Вы тестировали / тестировали его?

...