У меня есть веб-приложение С# со строкой подключения к базе данных, сохраненной в файле web.config. Этот файл также является частью репозитория git. Как сохранить строку подключения, чтобы предотвратить ее компрометацию в случае, если злоумышленник получит доступ к моему репозиторию?
Решит ли шифрование файла мою проблему, как предлагают ответы на этот старый вопрос? Если да, то как я могу сделать это в .NET?
Using Windows Authentication is not really suitable for my projects as multiple web apps run on one web server and I would like to separate the access different applications have.
вам не обязательно использовать одну и ту же учетную запись Windows для всех приложений. На самом деле вам придется проделать дополнительную работу, чтобы использовать ту же учетную запись. Для начала каждый пул приложений запускается под собственной учетной записью виртуальной службы. Если вы хотите использовать учетную запись домена, используйте разные учетные записи AD для каждого приложения.
Это (как минимум) два отдельных вопроса в одном. Первый абзац вопроса — хороший самостоятельный вопрос. Я предлагаю вам отредактировать этот вопрос, чтобы он был именно таким. Другими словами, как безопасно хранить секреты в git. Тогда у вас есть вопрос 2, который, похоже, касается защиты файла web.config (нужно ли отправлять этот файл в зашифрованном виде?). И, возможно, отдельный вопрос 2b о том, как предоставить учетные данные серверному процессу. Я предлагаю прочитать эти темы отдельно и, конечно же, задать больше вопросов SO, если вы не найдете то, что вам нужно :)
@HughW Спасибо за ваш комментарий. Я отредактировал свой вопрос и надеюсь, что теперь он понятнее. Я включил только вторую часть, потому что думал, что это может быть решением моей проблемы.
@ Аарон Спасибо за вашу помощь. Я использую Jenkins, но мой скрипт Groovy для развертывания также является частью моего репозитория. Если не из репозитория, откуда Джекинсу взять строку подключения? Как это улучшит безопасность? (извините, если это очень нубский вопрос, но я относительно новичок в этой области)
Вы можете добавить учетные данные в Jenkins jenkins.io/doc/book/using/using-credentials обычно они состоят из имени пользователя + пароля. Затем эти переменные могут быть введены, например, в ваш файл web.config во время сборки.
Вы должны (как я видел в своих проектах) хранить его в файле launchSettings.json.
Например
"environmentVariables": {
"ConnectionStrings__MyDb":"Server=localhost\\SQLEXPRESS;Database=My;Trusted_Connection=True"
},
Этот файл у всех программистов разный.
Это не касается той части вопроса, где он спрашивает, как я могу сохранить строку подключения, чтобы предотвратить ее компрометацию в случае, если злоумышленник получит доступ к моему репозиторию?
Не "должны ли вы" сделать это. Есть много разных способов решить эту проблему, и говорить, что вы должны что-то делать, не упоминая плюсы, минусы или альтернативы, очень вводит в заблуждение.
Существует множество инструментов для безопасного хранения секретов в репозитории Git, и вы найдете отличный обзор здесь ( archive 1 , archive 2), в котором обсуждаются компромиссы.
Из упомянутых в статье я использовал только git-secret, описание которого:
git-secret
шифрует файлы и сохраняет их в вашемgit
репозитории, предоставляя историю изменений для каждой фиксации.git-secret
не требует никаких дополнительных операций развертывания, кроме предоставления соответствующего закрытого ключа (чтобы разрешить расшифровку) и использованияgit secret reveal
для расшифровки всех секретных файлов.
Что касается более широкого вопроса о том, как предоставить пароли серверу ASP.NET, это большая тема. Я предлагаю прочитать руководство Защита строк подключения и другой информации о конфигурации от Microsoft.
Вы никогда не должны передавать конфиденциальные данные или учетные данные в fit.
Вы можете использовать пользовательские секреты для работы локально.
При развертывании на сервере или в среде хостинга следует использовать переменные среды.
Это имеет дополнительное преимущество, позволяя вам устанавливать разные значения в каждой среде.
Ну, связанный вопрос дает вам своего рода ответ. Зачем вам в первую очередь отправлять веб-конфигурацию с учетными данными в git? Обычно вы добавляете их в процесс сборки (с помощью jenkins, azure dev ops или чего-то еще) и используете их только в производственной системе.