Возможно ли установить соединение JDBC с Oracle без предоставления информации о имени пользователя и пароле в файле конфигурации (или в любом другом стандартном читаемом месте)?
Обычно приложения имеют файл конфигурации, содержащий параметры настройки для подключения к базе данных. У некоторых администраторов баз данных есть проблемы с тем, что имена пользователей и пароли содержатся в текстовом файле в конфигурационных файлах.
Я не думаю, что это возможно с Oracle и JDBC, но мне нужно подтверждение...
Возможный компромисс заключается в шифровании пароля в файле конфигурации и расшифровке его перед настройкой соединения. Конечно, ключ дешифрования не должен находиться в одном файле конфигурации. Это разрешит случайное открытие файла конфигурации неавторизованными пользователями.
Ответ 1
Возможно, вы захотите попробовать Kerberos, который может использовать учетные данные пользователя ОС и добавить пользователя ОС в базу данных, как указано извне. Убедитесь, что вы используете Kerberos, а не старый способ сделать это, что имеет серьезные проблемы с безопасностью.
Для поддержки Kerberos вам потребуется расширенная опция безопасности и недавний драйвер JDBC, возможно, версия 11g. Прежде чем пытаться заставить его работать на Java, попробуйте его в Sql * Plus, используя "/" в качестве имени пользователя и пустого пароля. "выберите пользователя из двойника" должен предоставить вам домен user @. Вы также можете обнаружить, что существует фундаментальное различие между использованием тонкого или OCI-драйвера, когда дело доходит до конфигурации Kerberos.
Ответ 2
Вы определенно не хотите подключаться к базе данных без учетных данных, потому что это делает базу данных уязвимой.
Это общая проблема, как мне хранить учетные данные, необходимые для доступа к внешним системам? Для решения этой проблемы WebLogic имеет средство сопоставления учетных данных, в котором учетные данные (зашифрованные) хранятся во встроенном LDAP. Многие продукты Oracle используют средство хранения учетных данных, которое хранит учетные данные в кошельке Oracle.
В вопросе вы предоставили ответ. Храните пароль в зашифрованном виде и расшифровывайте его, когда вам это нужно. Очевидно, вы должны использовать симметричный алгоритм шифрования, такой как 3DES, чтобы расшифровать его. Убедитесь, что симметричный ключ не является чем-то, что можно угадать.
Фокус в том, где вы храните симметричный ключ, необходимый для en/de-cryption. Вы можете поместить его в файл, который защищен через ОС, или вы можете сохранить его в коде, но тогда вам нужно сохранить код в безопасности. Вы также можете сгенерировать ключ, если вы используете технику, которая будет генерировать один и тот же ключ, и алгоритм достаточно безопасен.
Если вы можете сохранить код в безопасности, вы также можете сохранить пароль в коде. Однако вам нужна гибкость в возможности изменять учетные данные без изменения кода.
Вы также можете добавить еще несколько слоев в это решение. Вы можете зашифровать файл конфигурации (с другим ключом), а также пароль внутри него, чтобы хакер обнаружил 2 ключа. Существуют и другие более безопасные методы, использующие PKI, но их сложно настроить.
Ответ 3
Я бы предложил вам изучить прокси-аутентификацию. Это описано в Руководстве по безопасности баз данных Oracle®, а также Руководство разработчика и справочник разработчиков JDBC для баз данных Oracle®. По сути, это позволяет вам иметь пользователя в базе данных, которая ТОЛЬКО имеет права на подключение. Пользователи реальных учетных записей базы данных настроены на возможность подключения в качестве прокси-пользователя. Приложение, подключающееся через JDBC, затем сохраняет имя пользователя и пароль прокси, а при подключении предоставляет эти учетные данные, PLUS - имя пользователя реального пользователя базы данных в строке подключения. Oracle подключается как пользователь прокси, а затем имитирует реального пользователя базы данных, наследуя привилегии базы данных реального пользователя.
Ответ 4
Все контейнеры J2EE (JBOSS, Tomcat, BEA) имеют пулы подключений. Они откроют несколько соединений, сохранят их и передадут вам в 1/100 th время, необходимое для создания с нуля.
Кроме того, у них также есть интересные функции, например, в JBOSS, вся информация о подключении хранится во внешнем файле. Если вы измените информацию о подключении, то есть вы переключитесь с теста на производственную БД, ваше приложение будет динамически загружать подключения из нового пула
Хорошей новостью является то, что вам не нужно запускать полный контейнер J2EE, чтобы использовать пул соединений. Внешний ресурс позволяет сохранять пароль в виде открытого текста или псевдошифровать.
Для руководства по использованию объединенного пула соединений Tomcat см. apache commons-dbcp:
Ответ 5
Поскольку я не совсем понимаю вашу среду, отличную от Java и JDBC, разговаривающих с Oracle, я буду говорить по этому поводу.
Если вы говорите о приложении Java EE, вы должны иметь возможность настраивать пулы подключений и источники данных на сервере приложений, а затем приложение обращается к пулу соединений, который обрабатывает соединение на этом уровне.
Пул соединений и источник данных хранятся и сохраняют учетные данные.
Ответ 6
Насколько мне известно, подключение jdbc к именам пользователей/паролям необходимо хранить в виде простого текста. Один из способов ограничить возможные риски этого - ограничить права пользователя, чтобы можно было использовать только данную базу данных приложений и только с предопределенного хоста. IMO, это очень ограничило бы атакующего: он мог использовать только un/pw с того же хоста, где находится исходное приложение, и только для атаки исходной базы данных приложений.
Ответ 7
Задумывались об этом в прошлом.
Решение, безусловно, включает в себя обеспечение надлежащей сетевой безопасности на уровне сервера и сети, чтобы действительно уменьшить количество людей, которые могут получить доступ к системе, а наличие учетных данных базы данных дает доступ только к учетной записи базы данных с открытым минимум разрешений, необходимых для запуска приложения.
Шифрование файлов свойств может быть достаточным сдерживающим фактором в терминах "не нужно беспокоиться, чтобы найти ключ или кодовую фразу", чтобы заставить злоумышленника перейти на следующий зараженный сервер. Я бы не стал полагаться на "мой сосед менее безопасен, так что украсть у него, пожалуйста" безопасность, однако!
Ответ 8
Есть два ключевых подхода, и оба они оказывают значительное влияние на дизайн системы, так что перемещаться из одного в другое без существенного переписывания непросто. Вам нужно понять, что перед политикой политики безопасности вашей компании.
1) У каждого пользователя есть учетные данные, которые переносятся через приложение, для службы, которая используется Приложением; в вашем случае база данных Oracle использует эти учетные данные для подключения к базе данных. Недостатком является то, что каждому пользователю нужны учетные данные для каждого защищенного сервиса. Это разумный безопасный подход, но также требует значимой дополнительной работы для предоставления и поддержания учетных данных пользователя. Администраторам баз данных необходимо будет активно управлять учетными данными пользователей, что может противоречить политикам управления безопасностью вашей компании.
2) Учетные данные базы данных приложения хранятся в службе безопасного каталога, например. Защитите LDAP. Приложение обращается к службе каталогов с учетными данными пользователей. Служба каталогов возвращает соответствующие учетные данные для доступа к сервису.
В обоих случаях учетные данные базы данных должны быть ограничены только для выполнения соответствующих операций. Например, учетные данные должны отражать требования бизнес-процессов; они позволяют выбирать из определенных представлений/таблиц, вставлять в другие, но не создавать, обновлять или удалять таблицы. Во втором подходе используют отдельные учетные данные для каждого основного бизнес-процесса, например. Обработка заказов, учет, управление персоналом и т.д.
Однако помните, что безопасность подобна слоям лука, если кто-то удалил слои для доступа к приложению, чтобы они могли получить доступ к конфигурационному файлу пула удаленных баз данных. Вероятно, они могут трояна приложениям для регистрации учетных данных пользователей. Именно здесь происходит хорошая политика управления безопасностью.
Управление безопасностью - сложная проблема, которая требует высшего руководства, потому что, если вам нужен этот уровень безопасности для вашей живой платформы, он стоит. Вам необходимо отделить обязанности разработки от развертывания, операций и управления полномочиями пользователей. Возможно, вам также потребуются аудиторы безопасности, у которых есть полный доступ к изменениям просмотра, но нет возможности изменить конфигурацию. Это, если далек от простого и высокооплачиваемого специалиста.
Ответ 9
Вы можете хранить учетные данные в любом месте, в том числе в виде проводных строк в программе или в качестве записей в реестре Windows. Это зависит от вас, чтобы получить их, если вы используете что-то нестандартное; Я не знаю о каких-либо готовых решениях, которые не являются открытым текстом.
Ответ 10
Вы можете попробовать аутентификацию прокси-сервера Oracle, где клиент JDBC аутентифицируется с использованием сертификата с известным компонентом/сервисом промежуточного уровня (прокси), которому доверяет сервер базы данных. Я никогда не пробовал этого, поэтому я не знаю, легко ли это сделать.
Ответ 11
В дополнение к уже упомянутым решениям (проверка подлинности Kerberos с использованием прокси-аутентификации) есть еще два решения, которые работают с тонким драйвером JDBC:
- Сохраните пароль в кошельке SSO: кошелек можно использовать для хранения пароля пользователя. Если вы используете кошелек SSO, то сам кошелек не имеет пароля. Кошельки SSO обычно используются в контексте SSL, но они также могут использоваться для простого хранения пароля.
- Используйте SSL с аутентификацией пользователя: настройте SSL с пользователем, который прошел внешнюю аутентификацию с помощью Distinguished Name (DN). У этого пользователя нет пароля. Пока вы подключаетесь к SSL с помощью сертификата, имеющего это DN, вы сможете создать сеанс с помощью этого пользователя.
