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