Где хранить учетные данные базы данных в веб-приложении?

Question

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

на что стоит обратить внимание:
Используете ли вы файлы свойств, XML-конфиги, другие?
Он включен в ваше приложение (то есть в файл jar) или хранится отдельно в файловой системе где-нибудь?
Пароль зашифрован? Если да, то какую схему шифрования вы используете?

Answer 1

Поскольку вы оставляете вопрос открытым для платформы, я добавлю, что учетные данные базы данных для приложений .NET хранятся в файле web.config. Начиная с версии 2.0 и выше, существует специальный раздел ConnectionStrings, который обеспечивает более легкий программный доступ к строке подключения.

Помимо того, что IIS автоматически блокирует прямые запросы к файлу web.config по умолчанию, вы также можете использовать команду IIS для шифрования раздела ConnectionString файла web.config. Это шифрование зависит от конкретной машины, дополняя его сильные стороны, и среда выполнения .NET также расшифровывает строку подключения на лету, когда вы получаете к ней доступ, поэтому нет необходимости в дополнительном кодировании в вашем приложении для работы с ним.

Answer 2

При использовании Java пулы соединений с базами данных должны передаваться контейнером в веб-приложения. Это в стандарте, объявленном в WEB-INF / web.xml как ресурсы. То же самое относится к почтовым сеансам и другим внешним ресурсам, которые могут варьироваться от установки к установке. Посмотрите JNDI для получения дополнительной информации об этом)

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

В tomcat это настраивается либо из файлов контекста (например, в conf / Catalina / localhost /, conf / server.xml) или - предпочтительно только для сред разработки, из веб-приложений META-INF / context.xml. Другие среды имеют свое собственное расположение конфигурации или приложение.

Шифрование паролей фактически зависит от контейнера. Tomcat хранит их в виде открытого текста, но само приложение его не видит. Я не знаю о механике в других средах.

Answer 3

В стеке Microsoft все может быть очень хорошо.

Вы создаете сетевую учетную запись пользователя в Active Directory практически без разрешений. Вы настраиваете IIS для запуска вашего веб-приложения от имени этого пользователя. Вы предоставляете этому пользователю доступ для чтения к веб-папкам и файлам на диске. Вы настраиваете SQL Server, чтобы предоставить этому пользователю права на чтение / запись для таблиц, которые вы хотите. А в строке подключения вы указываете клиенту db подключаться как учетная запись пользователя, под которой в данный момент выполняется веб-приложение.

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

Answer 4

Зависит от сервера приложений.

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

Да, пароль зашифрован в WebLogic.

На Tomcat вещи могут быть рискованными. Информация о соединении находится в META-INF / context.xml, что означает простой текст для пароля. Я делаю это только для разработки, а не для производства.

Answer 5

для asp.net:

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

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

Answer 6

В Django учетные данные находятся в вашем settings.py файле конфигурации. Поскольку это обычно не хранится в вашем дереве каталогов /var/www/, это очень безопасно.

Кроме того, одно приложение Django может использоваться (и использоваться повторно) для многих веб-сайтов или веб-серверов на одном хосте, каждый из которых имеет свои собственные настройки. Таким образом, конфигурация settings.py не связана с приложением, а является частью единого развертывания приложения.

Answer 7

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