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

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: если кто-то уже находится на сервере или имеет широкий доступ к нему (например, системный администратор), игра в значительной степени окончена. Таким образом, идея заключается в том, чтобы использовать сервер, которому вы доверяете, поскольку он безопасен настолько, насколько вы этого хотите. В частности:

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

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

Answer 4

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

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

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

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

Answer 5

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

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

Спасибо!

Answer 6

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

Answer 7

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

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

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

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

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