#c# #azure #asp.net-core #azure-keyvault #appsettings
#c# #azure #asp.net-core #azure-keyvault #настройки приложений
Вопрос:
Возможно, на мой вопрос уже есть ответ, но я не смог найти его после долгого поиска.
Мой вариант использования следующий: у меня есть один ASP.Net Веб-приложение Core 3.1. Для хранения некоторой информации используется база данных MSSQL (к вашему сведению, я не храню никаких пользовательских секретов, но все же информация для меня ценна). Он также использует почтовый клиент для отправки электронных писем. Мне нужно сохранить строку подключения к базе данных, а также учетные данные для почтового клиента. До сих пор я хранил их в файле appsettings.json, пока не понял, что они хранятся в виде обычного текста, и если кто-то получит к ним доступ, у него / нее будет доступ к моей базе данных и моему почтовому клиенту.
Теперь я ищу способ более безопасного их хранения. После прочтения вопросов в SO я пришел к пониманию, что предлагаемый способ хранения такой информации — использовать Azure Key Vault. Я могу использовать его, и я начал обновлять свое приложение для работы с ним (я читал, что я могу получить к нему доступ за пределами Azure). Но я понял, что мне нужно где-то хранить URL хранилища, значения ClientID и clientSecret.
Как я могу их сохранить. В одном из руководств они были в файле appsettings.json, но они сказали, что это не очень хороший подход для производства, что понятно. Предлагаемым вариантом было сохранить их в переменных среды. Но здесь возникает моя проблема — я размещаюсь на общем сервере и не могу добавить какие-либо переменные среды. Поэтому использование переменных среды для меня не вариант.
В моем случае, когда я не могу добавить какие-либо переменные среды, какой был бы наилучший подход для хранения любых производственных секретов, таких как строка подключения к базе данных? Является ли Azure Key Vault по-прежнему допустимым и хорошим вариантом? Должен ли я рассмотреть возможность сохранения их в appsetting.json и шифрования этого файла? Или, может быть, есть другой лучший подход?
Приложение разрабатываю только я, плюс я не храню его ни в каком общедоступном репозитории GitHub или в чем-либо еще.
PS: Вот ссылка на руководство, которое я просматривал:Использование Azure Key Vault из приложения, отличного от Azure
Спасибо.
РЕДАКТИРОВАТЬ: Вот одно руководство, которое я нахожу полезным, о том, как использовать Azure Key Vault с сертификатом за пределами Azure
Комментарии:
1. Вы на правильном пути. Рекомендуемый подход заключается в хранении секретов в Azure Keyvault. Однако, чтобы получить авторизованный доступ к KeyVault, вам понадобятся учетные данные, такие как ClientID и Secret или Certificate. Итак, вопрос в том, где хранить эти секреты, чтобы получить доступ к KeyVault для реальных секретов ! :). Теперь, если бы вы были на хосте Azure, например, в веб-приложении Azure или виртуальной машине, я мог бы сразу порекомендовать управляемую идентификацию docs.microsoft.com/en-us/azure/key-vault/general/… где вам не нужно было бы сохранять учетные данные в приложении .. (Продолжение в следующем комментарии)
2. Но поскольку вы упомянули, что это не Azure-хост, я хотел бы узнать больше об этом, чтобы предложить вам хорошее решение. Что такое хост? Виртуальная машина, сторонний хостинг? Или?
3. В этом случае есть ли у них поддержка «принести свой собственный сертификат»? Вы можете аутентифицироваться в keyvault, используя идентификатор клиента и сертификат (рекомендуется) вместо Secret, если они поддерживают установку сертификата. learn.microsoft.com/en-us/azure/key-vault/general /…
4. даже если в примере есть файл формата pem (в нем использовался самозаверяющий сертификат только в качестве примера с использованием инструмента openssl), он также может работать с форматом pfx … в основном с сертификатом x509 ssl.com/faqs/what-is-an-x-509-certificate наличие расширения аутентификации клиента. Да, он должен быть установлен на сервере, а код C # должен быть таким c-sharpcorner.com/article /… (ближе к концу этой статьи)
5. Да, если они не поддерживают, вы можете аутентифицироваться в keyvault, используя идентификатор клиента и секрет. Вы можете сохранить его в appsettings.json и зашифровать, но тогда где бы вы хранили ключ шифрования?
Ответ №1:
Две вещи:
1- Вы должны хранить секреты в Azure Key Vault. Как вы уже заметили, он предоставит URL-адрес, который будет использоваться для извлечения секрета из хранилища ключей.
2-Только разрешенные службы смогут извлекать секреты. Что вам нужно сделать, это создать идентификатор управления для ваших веб-приложений, а затем предоставить доступ к секретам GET / LIST из хранилища ключей к этому управляемому идентификатору.
вот пошаговый:
https://learn.microsoft.com/en-us/azure/key-vault/general/tutorial-net-create-vault-azure-web-app
Комментарии:
1. Может ли это управляемое удостоверение использоваться приложениями, которые не размещены в Azure? Мое приложение находится на другом хосте. Я думаю, что предоставленная вами ссылка предназначена для приложений, размещенных в Azure, или нет?
2. нет, управляемые удостоверения действительны только для приложений Azure
Ответ №2:
(Подведение итогов обсуждения и разрешение в качестве ответа)
Рекомендуемый подход заключается в хранении секретов в Azure Keyvault. Однако, чтобы получить авторизованный доступ к KeyVault, вам понадобятся учетные данные, такие как ClientID и Secret или Certificate. Итак, вопрос в том, где хранить эти секреты, чтобы получить доступ к KeyVault для реальных секретов ! :). Теперь, если бы вы были на хосте Azure, например, в веб-приложении Azure или виртуальной машине, я мог бы сразу порекомендовать управляемую идентификацию, где вам не нужно было бы сохранять учетные данные в приложении, но поскольку вы упомянули, что это не Azure host, я бы предложил пройти проверку подлинности по сертификату, поскольку для аутентификации на основе секретов вам потребуется сохранить секрет где-нибудь в конфигурации / переменной среды, что не очень хорошая идея. Также убедитесь, что только ваше приложение имеет доступ к этому сертификату на хосте.
Поскольку теперь вы согласовали со своим поставщиком хостинга настройку сертификата, и все работает, я надеюсь, что это помогло. Спасибо.