Мне интересно, какие методы вы используете для хранения учетных данных базы данных для своего приложения. Я специально интересуюсь java webapps, но я не думаю, что есть необходимость ограничивать вопросы.
вещи, которые следует учитывать:
Используете ли вы файлы свойств, xml configs, другие?
Связано ли это с вашим приложением (то есть в файле jar) или хранится отдельно в файловой системе где-нибудь?
Зашифрован ли пароль? Если да, то какую схему шифрования вы используете?
Поскольку вы оставляете вопрос открытым для платформы, я добавлю, что учетные данные базы данных для приложений .NET хранятся в файле web.config. Начиная с версии 2.0 и выше, существует специальный раздел ConnectionStrings, который позволяет упростить программный доступ к строке подключения.
В дополнение к тому, что IIS автоматически блокирует прямые запросы к файлу web.config по умолчанию, вы также можете использовать команду IIS для шифрования раздела ConnectionString файла web.config. Это шифрование является специфичным для машины, что повышает его сильные стороны, а среда выполнения .NET также расшифровывает строку соединения "на лету" при ее доступе, поэтому нет необходимости в дополнительном кодировании в приложении для работы с ней.
С Java, пулы подключения к базам данных должны быть переданы в webapps контейнером. Это стандартно декларируется в WEB-INF/web.xml в качестве ресурсов. То же самое относится к почтовым сеансам и другим внешним ресурсам, которые могут отличаться от установки к установке. Посмотрите JNDI для получения дополнительной информации об этом)
Приятная часть этого заключается в том, что приложение не заботится о том, как фактически подключиться к чему-либо снаружи. Он не увидит никаких паролей, потому что сам контейнер будет их использовать.
В tomcat это настроено либо из файлов контекста (например,) в conf/Catalina/localhost/, conf/server.xml, либо, предпочтительно, только для сред dev, из webapps META-INF/context.xml. Другие среды имеют свое собственное местоположение конфигурации или приложение.
Шифрование паролей фактически зависит от контейнера. Tomcat хранит их в открытом виде, но само приложение не увидит его. Я не знаю о механике в других средах.
В стеке Microsoft все может быть очень приятным.
Вы создаете учетную запись сетевого пользователя в Active Directory без каких-либо разрешений. Вы настраиваете IIS для запуска вашего webapp в качестве этого пользователя. Вы предоставляете пользователю доступ к доступу к веб-папкам и файлам на диске. Вы настраиваете SQL Server, чтобы предоставить пользователям права на чтение/запись для таблиц, которые вы хотите. И в строке подключения вы укажете, что клиент db будет подключаться как учетная запись пользователя, в которой в настоящее время выполняется webapp.
Существует только одна фактическая учетная запись пользователя, хотя она видна в нескольких местах. У этой учетной записи очень ограниченные разрешения. Хранилище паролей отсутствует, даже если оно зашифровано. Конфигурация, которая должна быть выполнена в коде для работы, не требуется (все это при настройке разрешений).
Зависит от сервера приложений.
Обычно я использую JNDI-запросы для источника данных, поэтому учетные данные хранятся на сервере приложений, который обрабатывает пул соединений. Не нужно помещать в конфигурацию ничего, кроме имени JNDI.
Да, пароль зашифрован в WebLogic.
В Tomcat все может быть очень рискованным. Информация о подключении находится в файле META-INF/context.xml, что означает простой текст для пароля. Я делаю это только для развития, никогда в производстве.
В Django учетные данные находятся в файле конфигурации settings.py. Поскольку это обычно не содержится в дереве каталогов /var/www/, это очень безопасно.
Кроме того, одно приложение Django может использоваться (и повторно использоваться) для многих веб-сайтов или веб-серверов на одном и том же хосте, каждый из которых имеет свои собственные настройки. Таким образом, конфигурация settings.py не входит в комплект приложения, но является частью одного развертывания приложения.
Для asp.net:
Я храню глобальные параметры, такие как строки подключения и пути репозитория в реестре, а затем ссылку на запись реестра в файле web.config.
Основная причина в том, что я часто нахожу, что мне приходится писать автономный исполняемый файл для запуска фоновых задач и других автоматизированных функций, требующих доступа к тем же параметрам. Поэтому сохранение всего, что по-настоящему глобально в одном легкодоступном месте, облегчает жизнь.
Какое из них является хорошим местом для хранения учетных данных базы данных веб-приложений? В отдельном файле в исходном коде В отдельном файле на вашем веб-сервере В вашей базе данных Никто. Учетные данные базы данных никогда не должны храниться