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

Ответ 1

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

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

Ответ 2

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

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

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

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

Ответ 3

В стеке Microsoft все может быть очень приятным.

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

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

Ответ 4

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

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

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

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

Ответ 5

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

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

Ответ 6

Для asp.net:

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

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

Ответ 7

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