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

Question

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

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

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

как для окон, так и для решений linux!

Answer 1

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

Если это не сработает, используйте встроенный configuration encryption system in ASP.NET.

Answer 2

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

Answer 3

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

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

Спасибо!

Answer 4

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

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

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

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

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

Answer 5

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

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

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

Answer 6

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

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

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

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

Answer 7

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

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

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

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