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

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

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

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

и Windows и Linux решения приветствуются!

14.08.2008 06:10:25
7 ОТВЕТОВ
РЕШЕНИЕ

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

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

10
14.08.2008 09:07:56

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

1
14.08.2008 06:12:31
Следование этой стратегии приведет к тому, что упустит возможность глубоко построить оборону.
AJ. 25.05.2010 09:34:07

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

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

Спасибо!

1
14.08.2008 06:20:30

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

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

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

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

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

0
14.08.2008 06:39:42

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

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

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

3
14.08.2008 06:41:12
Вполне возможно, что недостаток веб-сервера может позволить злоумышленнику заставить сервер обслуживать файл конфигурации, но все же не разрешить полный доступ к серверу. По этой причине, а также потому, что, как правило, рекомендуется создавать более глубокую защиту, не следует хранить конфиденциальные данные в незашифрованном виде.
AJ. 25.05.2010 09:36:20

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

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

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

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

1
14.08.2008 07:13:19

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

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

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

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

5
25.05.2010 07:55:16