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

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

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

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

Спасибо!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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