Лучший способ сохранить пароль базы данных в файле сценария запуска/конфигурации?

Question

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

Как лучше всего хранить имя/пароль для этих приложений с точки зрения

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

решения как для Windows, так и для Linux оценены по достоинству!

Answer 1

Лучший способ защитить свой пароль — прекратить его использование.Используйте доверенное соединение:Как:Подключение к SQL Server с использованием проверки подлинности Windows в ASP.NET 2.0.Тогда вам нечего скрывать — опубликуйте свой web.config и исходный код всему миру, они все равно не смогут попасть в вашу базу данных.

Если у вас это не сработает, используйте встроенный система шифрования конфигурации в ASP.NET.

Answer 2

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

1. Ограничьте доступ к локальному порту, например разрешив подключаться к нему только определенному пользователю.
2. Настройте подключение без пароля к хосту PostgreSQL, указав ssh в качестве конкретного пользователя.
3. Разрешить пользователю подключаться по ssh, чтобы иметь локальный доступ к PostgreSQL без пароля.

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

Редактировать:Я должен добавить, что это будет работать с любой базой данных, которая прослушивает порт TCP/IP.Просто это описано в PostgreSQL.И вам понадобится iptables (или его эквивалент в Linux) для ограничения портов.Видеть этот.

Answer 3

Я согласен с lomaxx:если кто-то уже находится на сервере или имеет к нему широкий доступ (например, системный администратор), игра практически окончена.Таким образом, идея состоит в том, чтобы использовать сервер, которому вы доверяете, и что он безопасен в той степени, в которой вы хотите.Конкретно:

• Вам нужно доверять сисадминам
• Вам нужно доверять кому-либо еще, кто запускает код на том же сервере (вот почему общий хостинг для меня категорически запрещен).

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

Answer 4

простой текст?Если они находятся на вашем сервере, я надеюсь, что сервер достаточно безопасен, чтобы не допустить несанкционированного доступа.Если люди могут получить доступ к вашим файлам конфигурации на сервере, значит, что-то пошло не так гораздо раньше.

Answer 5

уточнение:с точки зрения безопасности, ремонтопригодности (например.если логин нужно сменить, могу ли я найти его позже и т. д.)

@lomax:возможно, я не хочу, чтобы все имели доступ к физическому серверу (например,системные администраторы), чтобы увидеть пароль.

Спасибо!

Answer 6

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

Более сложная альтернатива — настроить выделенный сервер безопасных паролей, который:

• предоставляет услугу расшифровки паролей
• фактически хранит пароли для использования другими менее безопасными серверами

В зависимости от используемых сетевых протоколов это может не защитить от мошеннического системного администратора с помощью tcpdump.И от решительного сисадмина с отладчиком это тоже, вероятно, не защитит.В этот момент, возможно, пришло время взглянуть на что-то вроде билетов Kerberos.

Answer 7

Вы можете встроить симметричный ключ шифрования в свой двоичный файл и заставить этот двоичный файл считывать зашифрованные имя пользователя и пароль из файла на диске при запуске.

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

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

Вы также можете заблокировать сервер базы данных, чтобы он принимал соединения с компьютеров ваших веб-приложений только по IP.

В конечном итоге ваша проблема заключается в том, что ключ (пара имени пользователя и пароля вашей БД) должен быть доступен для программного и автоматического использования вашими веб-приложениями.