Как сохранить несколько паролей connectionString в безопасности, разделить и легко развернуть?

Question

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

1. Приложение ASP.NET будет работать на нескольких различных веб-серверах, включая рабочие станции localhost для разработки. Это означает, что шифрование web.config с использованием ключа машины отсутствует. Каждый «тип» или среда веб-сервера (dev, test, prod) имеет свою собственную соответствующую базу данных (dev, test, prod). Мы хотим разделить эти строки подключения, чтобы разработчик, работающий над кодом «dev», не мог видеть пароли строки подключения «prod» и не позволял этим рабочим паролям когда-либо развертываться на неправильном сервере или фиксироваться в SVN.

2. Приложение будет должно иметь возможность решать, какую строку подключения пытаться использовать, основываясь на имени сервера (используя оператор switch). Например, «localhost» и «dev.example.com» будут знать, как использовать DevDatabaseConnectionString, «test.example.com» будет использовать TestDatabaseConnectionString, а «www.example.com» будет использовать ProdDatabaseConnectionString, например. Причина этого заключается в том, чтобы ограничить вероятность любых аварийных ситуаций развертывания, когда неправильный тип веб-сервера подключается к неверной базе данных.

3. В идеале, одинаковые исполняемые файлы и файл web.config должны быть в состоянии работать в любой из этих сред, без необходимости настраивать или настраивать каждую среду отдельно при каждом развертывании (то, что кажется простым забыть / испортить один день во время развертывания, поэтому мы отказались от наличия только одной строки подключения, которая должна быть изменена для каждой цели). Развертывание в настоящее время осуществляется через FTP. Обновление: Использование "событий сборки" и пересмотр наших процедур развертывания, вероятно, неплохая идея.

4. У нас не будет доступа из командной строки к производственному веб-серверу. Это означает, что использование aspnet_regiis.exe для шифрования файла web.config вышло. Обновление: Мы можем сделать это программно, поэтому этот момент спорный.

5. Мы бы предпочли не перекомпилировать приложение при смене пароля, поэтому использование web.config (или db.config или чего-либо еще) кажется наиболее целесообразным.

6. Разработчик не может получить доступ к паролю производственной базы данных. Если разработчик проверяет исходный код на своем ноутбуке localhost (который определит, что он должен использовать DevDatabaseConnectionString, помните?), И ноутбук потерян или украден, он не сможет получить доступ к другим строкам соединения. Таким образом, наличие единого закрытого ключа RSA для незашифрования всех трех паролей не может рассматриваться. (Вопреки пункту 3 выше, кажется, что нам нужно иметь три отдельных файла ключей, если мы пойдем по этому пути; они могут быть установлены один раз для каждой машины, и если неправильный файл ключа будет развернут на неправильном сервере, наихудший это должно произойти из-за того, что приложение не может ничего расшифровать - и не разрешить неправильному хосту обращаться к неправильной базе данных!)

7. ОБНОВЛЕНИЕ / ДОПОЛНЕНИЕ: в приложении есть несколько отдельных компонентов для веб-интерфейса: классический проект веб-служб ASMX, приложение веб-форм ASPX и более новое приложение MVC. Чтобы не сойти с ума, настроив одну и ту же строку подключения в каждом из этих отдельных проектов для каждой отдельной среды, было бы неплохо, чтобы это отображалось только в одном месте. (Возможно, в нашей библиотеке классов DAL или в одном связанном конфигурационном файле.)

Я знаю, что это, вероятно, субъективный вопрос (спрашивать «лучший» способ что-то сделать), но, учитывая критерии, которые я упомянул, я надеюсь, что единственный лучший ответ действительно возникнет.

Спасибо!

Answer 1

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

Лично для всего, что зависит от машины (не только от строки подключения), я вставляю внешнюю ссылку из Интернета.config, используя эту технику: http://www.devx.com/vb2themax/Tip/18880

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

Answer 2

(Во-первых, вау, я думаю, что 2 или 3 "быстрых абзаца" оказались немного длиннее, чем я думал! Вот и я ...)

Я пришел к выводу (возможно,вы не согласитесь со мной в этом), что способность "защищать" web.config на сервере (или с помощью aspnet_iisreg) имеет лишь ограниченное преимущество и, возможно, не очень хорошая вещь, поскольку она может датьложное чувство безопасности.Моя теория заключается в том, что если кто-то может получить доступ к файловой системе, чтобы в первую очередь прочитать этот файл web.config, то он также, вероятно, имеет доступ к созданию своего собственного простого файла ASPX, который может «снять защиту» и раскрыть его секреты.им.Но если посторонние люди trouncing вокруг в вашей файловой системы, а ... то у вас большие проблемы под рукой, так что вся моя забота сейчас спорный вопрос! ¹

Я также понимаю, что не существует надежного способа надежного сокрытия паролей внутри DLL, так как в конечном итоге их можно разобрать и обнаружить, возможно, с помощью чего-то вроде ILDASM. ² Дополнительную меру безопасности скрытности можно получить, запутав и зашифровав ваши двоичные файлы, например, используя Dotfuscator, но это не следует считать «безопасным». И снова,если у кого-то есть доступ на чтение (и, вероятно, тоже на запись) к вашим двоичным файлам и файловой системе, у вас снова возникают более серьезные проблемы.

Чтобы решить проблемы, о которых я упоминал, о нежелании паролей жить у разработчиканоутбуки или в SVN: решение этого с помощью отдельного файла .config, который не находится в SVN, - (сейчас!) очевидный выбор.Web.config может счастливо жить в управлении исходным кодом, в то время как секретные части этого не делают.Однако - и именно поэтому я продолжаю свой собственный вопрос с таким длинным ответом - есть еще несколько дополнительных шагов, которые я предпринял, чтобы попытаться сделать это, если не более безопасным, то, по крайней мере,немного больше неясных .

Строки подключения, которые мы хотим сохранить в секрете (кроме паролей разработки), никогда не будут жить как обычный текст в any файлы.Теперь они сначала шифруются секретным (симметричным) ключом, используя, конечно, новый нелепый Encryptinator (TM)!Утилита, созданная специально для этой цели - прежде чем они будут помещены в копию файла «db.config».Затем файл db.config загружается только на соответствующий сервер.Секретный ключ компилируется непосредственно в DLL DAL, который сам затем (в идеале!) Будет затем запутан и зашифрован чем-то вроде Dotfuscator.Мы надеемся, что это, по крайней мере, исключит любое случайное любопытство.

Я не собираюсь сильно беспокоиться о симметричном "DbKey", живущем в библиотеках DLL или SVN, или на ноутбуках разработчиков.Это пароли, которые я не буду использовать.Нам все еще нужно иметь файл «db.config» в проекте для разработки и отладки, но в нем есть все фальшивые пароли, кроме паролей разработки.Фактические серверы имеют реальные копии с собственными секретами.Файл db.config обычно возвращается (используя SVN) в безопасное состояние и никогда не хранится с реальными секретами в нашем хранилище subversion.

Учитывая все сказанное, я знаю, что это не идеальное решение (существует ли оно?), и тот, который все еще требует заметки после публикации с некоторыми напоминаниями о развертывании, но он кажется достаточным дополнительным уровнем хлопот, который может очень хорошо удержать всех, кроме самых умных и решительных атакующих.Мне пришлось смириться с «достаточно хорошей» безопасностью, которая не идеальна, но позволяет мне вернуться к работе после того, как я почувствовал себя хорошо после того, как дал ему «College Try!»

^1. _{За мой комментарий15 июня здесь http://www.dotnetcurry.com/ShowArticle.aspx?ID=185 - дайте мне знать, если я за пределами базы!-и еще несколько хороших комментариев здесь Шифрование строк подключения, чтобы другие разработчики не могли расшифровать, но приложение все еще имеет доступ здесь Не имеет смысла шифровать web.config? а здесь Шифрование веб.config с помощью Защищенной конфигурации бессмысленно?}

^2. _{Хорошая дискуссия и пища для размышления на другую тему, но очень связанные с этим понятия здесь: Надежно хранить пароль в программном коде? - что действительно поразило, так это FAQ по Pidgin, связанные с выбраннымиОтвет: Если у кого-то есть ваша программа, он может узнать ее секреты.}

Answer 3

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

..

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

Я полагаю, что этот сценарий затрагивает все (или большинство?) Ваших очков.