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

Question

Возможно ли установить соединение JDBC с Oracle без указания имени пользователя и пароля в файле конфигурации (или в любом другом стандартном читаемом месте)?

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

Я не думаю, что это возможно с Oracle и JDBC, но мне нужно подтверждение ...

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

Answer 1

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

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

Answer 2

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

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

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

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

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

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

Answer 3

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

Answer 4

Все J2EE контейнеры ( JBOSS , Tomcat , BEA ) имеют пулы соединений. Они откроют несколько соединений, сохранят их живыми и дадут их вам за 1/100 ^th время, необходимое для его создания с нуля.

Кроме того, они также имеют интересные функции, например, в JBOSS вся информация о соединении хранится во внешнем файле. Если вы измените информацию о соединении, т.е. вы переключитесь с test на production DB, ваше приложение будет динамически получать соединения из нового пула

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

Руководство по использованию встроенного пула соединений Tomcat приведено в apache commons-dbcp:

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

Answer 5

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

1) У каждого пользователя есть учетные данные, которые передаются через приложение, для службы, используемой приложением; в вашем случае база данных Oracle использует эти учетные данные пользователя для подключения к базе данных. Недостатком является то, что каждому пользователю нужны учетные данные для каждой безопасной службы. Это разумный безопасный подход, но он также требует значительных дополнительных усилий для предоставления и поддержки учетных данных пользователя. Администраторы вашей базы данных должны будут активно управлять учетными данными пользователей, которые могут противоречить политикам управления безопасностью вашей компании.

2) Учетные данные базы данных приложения хранятся в защищенной службе каталогов, например, Безопасный LDAP. Приложение обращается к службе каталогов с учетными данными пользователей. Служба каталогов возвращает учетные данные для доступа к службе.

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

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

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

Answer 6

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

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

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

Answer 7

Насколько мне известно, для подключения к jdbc имена пользователей и пароли должны храниться в виде простого текста. Одним из способов ограничения возможных рисков этого является ограничение прав пользователя, чтобы можно было использовать только заданную базу данных приложений и только с заранее определенного хоста. По-моему, это сильно ограничит злоумышленника: он может использовать un / pw только с того же хоста, на котором находится исходное приложение, и только для атаки на базу данных исходного приложения.

Answer 8

Поскольку я не совсем понимаю вашу среду, кроме Java и JDBC, общаясь с Oracle, я поговорю об этом.

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

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

Answer 9

В дополнение к уже упомянутым решениям (аутентификация Kerberos, использование прокси-аутентификации) есть еще 2 решения, которые работают с тонким драйвером JDBC:

1. Сохраните пароль в кошельке единого входа: кошелек можно использовать для хранения пароля пользователя. Если вы используете SSO кошелек, то сам кошелек не имеет пароля. SSO кошельки обычно используются в контексте SSL, но они также могут быть использованы только для хранения пароля.
2. Использовать SSL с аутентификацией пользователя: настроить SSL с пользователем, который аутентифицируется извне по отличительному имени (DN). У этого пользователя нет пароля. Пока вы подключаетесь с помощью SSL с использованием сертификата с этим DN, вы сможете создавать сеанс с использованием этого пользователя.

Answer 10

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