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

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

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

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

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

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

3 3
password-protection

3 ответа:

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

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

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

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

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

Вы можете рассмотреть возможность использования LDAP или предоставления крючков в приложении для корпоративного LDAP.

1

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

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

Вы проверяли / сравнивали его?

0