Шифрование строк подключения, так что другие разработчики не могут расшифровать, но приложение все еще имеет доступ

Question

У меня есть база данных, к которой я хочу получить доступ через веб-приложение .NET. Я могу достаточно легко зашифровать строку подключения в web.config, но любой разработчик, имеющий доступ к блоку, может дешифровать его с помощью нескольких строк кода - у них есть доступ к блоку, поэтому он имеет доступ к ключу шифрования, хранящемуся в машине. конфигурации.

Хотя я могу заблокировать людей из базы данных, отказав в доступе к их учетным записям, это не помогает, если у веб-приложения есть общеизвестные ключи от королевства. Кто-нибудь знает хороший способ предоставления веб-приложению доступа к базе данных без использования учетной записи SQL, используемой веб-приложением, для опытных разработчиков?

Answer 1

Это проблема курицы и яйца. Если ваше приложение имеет доступ к секретному ключу (ключу для шифрования строки подключения), любой, работающий с теми же правами, что и ваше приложение, также имеет его.

Лучший способ справиться с этим - вообще не иметь секрета и не использовать login / pwd в строке подключения SQL Server, а использовать встроенную защиту (SSPI). Таким образом, ваше приложение будет проходить аутентификацию в базе данных, используя свои учетные данные Windows (учетную запись, от имени которой работает ваше приложение), без отправки каких-либо учетных данных по проводам (обычная аутентификация означает, что login / pwd передается между приложением и db при каждом открытии соединение), и вам не нужно хранить пароль. Вам просто нужно убедиться, что пароль к действующей учетной записи нелегко угадать. После этого вы так же надежны, как и учетная запись (о которой нечего и говорить, но гораздо лучше, чем передавать учетные данные между процессами).

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

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

Answer 2

Если я знаю, как программа шифрует данные, и я знаю, где находятся ключи, тогда я могу расшифровать данные. («Я» == любой разработчик)

Защита ключей (разрешения Unix, списки ACL для Windows) может остановить большинство из них, но в программу всегда можно добавить строку, которая сбрасывает ключи (или только незашифрованные данные) в секретное место. (Или измените команды шифрования на похожие команды, которые на самом деле являются простым XOR или эквивалентным ...)

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

Answer 3

Возможно, вы смотрите на это неправильно.

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

Если вы используете SSPI, как упоминал Ян Шварц, в базу данных могут попасть только рабочие веб-серверы. Если это невозможно, системный администратор должен вручную вставить (зашифрованный) пароль в файл web.config во время развертывания.

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

Answer 4

Ответ, приведенный здесь, не отвечает на вопрос.

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

Если эта база данных является чем-то отличным от сервера sql, например oracle или sybase, то вышеуказанное решение не будет работать.

Существует множество ссылок в Шифрование значений Web.Config в ASP.NET 2.0 для решения этой проблемы:

Answer 5

Хотя я думаю, что у вас может быть совсем другой набор проблем, если вы не можете доверять своим разработчикам, вы можете проверить aspnet_setreg , чтобы посмотреть, может ли это помочь.

Или вы можете просто нанять неопытных разработчиков. :)

Answer 6

Если вы ДЕЙСТВИТЕЛЬНО полагаете, что ваши разработчики представляют серьезную угрозу безопасности в том смысле, в котором вы задаете этот вопрос, вам следует незамедлительно уволить их и нанять разработчиков, которым вы в конечном итоге можете доверять.

Разработчику, которому нельзя доверять ключи к вашим БД, также не следует доверять кодовую базу.

Примечание на стороне Что удерживает их от DEL *. * в вашей файловой системе?