Как избежать хранения учетных данных для подключения к Oracle с JDBC?

Я предложил бы, чтобы Вы изучили аутентификацию прокси. Это документируется в Руководство по обеспечению безопасности OracleВ® Database, а также Руководство разработчика OracleВ® Database JDBC и Ссылка . По существу, что это позволяет, Вы, чтобы сделать, имеют пользователя в базе данных, которая ТОЛЬКО имеет полномочия подключения. Пользователи реальные учетные записи базы данных настроены, чтобы быть в состоянии подключение как пользователь прокси. Ваше приложение, соединяющееся через JDBC тогда, хранит имя пользователя прокси и пароль, и когда соединение обеспечивает эти учетные данные ПЛЮС имя пользователя настоящего пользователя базы данных в строке подключения. Подключения Oracle как пользователь прокси, и затем подражают настоящему пользователю базы данных, наследовав полномочия базы данных реального пользователя.

Можно хотеть попробовать Kerberos, который может использовать учетные данные пользователя ОС и добавление пользователя ОС к базе данных, как определено внешне. Удостоверьтесь, что Вы используете Kerberos а не старый способ сделать это, которое имело серьезные проблемы безопасности.

Для поддержки Kerberos Вам были бы нужны опция повышенной безопасности и недавний драйвер JDBC, вероятно, 11-граммовая версия. Прежде, чем попытаться заставить его работать в Java, испытайте его в использовании Sql*Plus '/' как имя пользователя и пустой пароль. "выберите пользователя из двойного", должен дать Вам user@domain. Можно также найти, что существует принципиальное различие между использованием тонкого или драйвера OCI когда дело доходит до конфигурации Kerberos.

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

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

В вопросе, Вы предоставили ответ. Сохраните зашифрованный пароль и дешифруйте при необходимости в нем. Очевидно, необходимо использовать симметричный алгоритм шифрования такой в качестве 3DES, таким образом, можно дешифровать его. Удостоверьтесь, что симметричный ключ не что-то, что может быть предположено.

прием - то, где Вы сохраняете симметричный ключ необходимым для en/de-cryption. Можно поместить его в файл, который защищается через ОС, или можно сохранить его в коде, но тогда необходимо сохранить код безопасным. Можно также генерировать ключ при использовании техники, которая произведет тот же ключ, и алгоритм довольно безопасен.

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

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

К моему знанию имена пользователей/пароли соединения JDBC должны быть сохранены как простой текст. Один способ ограничить возможные риски этого состоит в том, чтобы ограничить права пользователя так, чтобы только данная база данных приложений могла использоваться и только от предопределенного хоста. IMO, это ограничило бы взломщика очень: он мог только использовать un/pw от того же хоста, где исходное приложение находится и только напасть на базу данных исходного приложения.

Задались вопросом это в прошлом.

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

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

Так как я не совсем ясен на Вашей среде кроме Java & JDBC, говорящий с Oracle, я буду говорить к этому.

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

пул соединения и источник данных содержат и защищают учетные данные.

Можно сохранить учетные данные где угодно, включая как соединенные проводами строки в программе или как записи в реестре Windows. Вам решать для получения их, если Вы используете что-то нестандартное, хотя; я не знаю ни о каких предварительно прокрученных решениях, которые не являются простым текстом.

Вы могли попробовать аутентификацию Oracle прокси, где клиент JDBC аутентифицирует использование сертификата против известного компонента/сервиса среднего уровня (прокси), которому доверяет сервер базы данных. Я никогда не пробовал это, хотя, таким образом, я не знаю, легко ли сделать.

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

1) у Каждого пользователя есть учетные данные, которые несут через приложение для сервиса, который используется Приложением; в Вашем случае база данных Oracle использует те удостоверения пользователя для соединения с базой данных. Оборотная сторона - то, что каждому пользователю нужны учетные данные для каждого безопасного сервиса. Это - разумный безопасный подход, но также и требует, чтобы signficant дополнительная работа предоставила и поддержала удостоверения пользователя. Ваши администраторы базы данных должны будут активно управлять удостоверениями пользователя, которые могут работать в противоречии с Вашими company’s политиками управления безопасностью.

2) учетные данные базы данных Application хранятся на безопасной службе каталогов, например, Защищают LDAP. Доступы к приложению служба каталогов с users’ учетными данными. Служба каталогов возвращает approriate учетные данные для получаемого доступ сервиса.

В обоих случаях учетные данные базы данных должны быть ограничены для выполнения соответствующих операций только. Учетные данные должны отразить требования бизнес-процессов, например; они позволяют выбор из определенных представлений/таблиц, вставляют в других, но не создают, обновляют или отбрасывают таблицы. Во втором использовании подхода отдельные учетные данные для каждого основного бизнес-процесса, например, Обработки заказов, Учета, HR, и т.д.

Однако помнят, что безопасность похожа на слои луковицы, если кто-то снял слои для доступа к приложению, такому, что они могут получить доступ к DB contection файл конфигурации пула. Они могут, вероятно, троянец приложение для получения users’ учетных данных. Это - то, где хорошая политика управления безопасностью входит.

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

All J2EE containers (JBOSS, Tomcat, BEA) have connection pools. They will open a number of connections, keep them alive and will give them to you in 1/100^th the time it takes to create one from scratch.

Additionally, they also have cool features, in JBOSS for example, all the connection info is stored in an external file. If you change the connection info i.e., you switch from a test to a production DB, your application will dynamically be fed connections from the new pool

The good news is that you don't need to run a full J2EE container just to use connection pooling. The external resource allows the password to be stored in either plaintext, or pseudo-encrypted.

For a guide on using Tomcat's builtin connection pooling see the apache commons-dbcp:

• http://vigilbose.blogspot.com/2009/03/apache-commons-dbcp-and-tomcat-jdbc.html