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

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

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

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

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

Ответов (7)

Решение

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

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

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

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

Спасибо!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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