Шифрование ASP.NET - aspnet_regiis - Ферма - PullRequest
4 голосов
/ 03 ноября 2011

У нас есть веб-сайт, который использует «NT Authority \ Network Service».

Response.Write(WindowsIdentity.GetCurrent().Name); 

В настоящее время мы используем следующую команду для шифрования файлов конфигурации.

aspnet_regiis -pc "NetFrameworkConfigurationKey"
aspnet_regiis -pa "NetFrameworkConfigurationKey" "NT Authority\Network Service"
aspnet_regiis.exe -pef "connectionStrings" "C:\WebAppLocation\Folder"

Примечание. Мы не используем "-exp".Когда мы используем «-exp», он не создает контейнер ключей RSA.

Как видите, мы используем ключ по умолчанию - NetFrameworkConfigurationKey.На нашем сайте есть балансировщик нагрузки.Доступны Webserver1 (W1) и WebServer2 (W2).

Если я буду следовать вышеупомянутым командам, мы будем использовать отдельные клавиши на W1 и W2.Однако сайт работает с этим подходом.

Достаточен ли этот подход?Есть ли у него недостатки или дыры?Сбой в любом сценарии?

Примечание. Ключ машины добавлен в наш файл web.config.Это одинаково в обоих конфигах.Тем не менее, наш configProtectedData не находится в Web.Config.Кроме того, я думаю, что NetFrameworkConfigurationKey будет отличаться на обоих серверах.

Я прочитал следующую статью MSDN для шифрования в сценариях веб-фермы.http://msdn.microsoft.com/en-us/library/ff650304.aspx

Ответы [ 3 ]

9 голосов
/ 03 ноября 2011

Мне не кажется, что ты все сделал правильно.Прежде всего, здесь есть две проблемы:

  1. Проверка того, что machineKey одинакова на обоих веб-серверах.
  2. Проверка того, что один и тот же закрытый ключ RSA установлен в контейнере ключей наоба сервера, так что зашифрованная конфигурация может быть расшифрована каждым сервером.

Это отдельные проблемы: machineKey не имеет отношения к шифрованию / дешифрованию раздела конфигурации, который вы хотите защитить.

Итак, прежде всего команда aspnet_regiis -pc используется для создания нового контейнера ключей RSA, и причина его сбоя заключается в том, что указанное вами имя контейнера уже существует, потому что оно используется по умолчанию.Пара ключей в этом контейнере не экспортируется, поэтому вам нужно создать новый контейнер ключей и указать переключатель -exp, чтобы обозначить, что пара ключей экспортируема.

aspnet_regiis -pc "MyDeploymentKeyContainer" -exp

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

aspnet_regiis -px "MyDeploymentKeyContainer" deploykey.xml -pri

Теперь добавьте раздел config в ваш web.config и сохраните его.

<configProtectedData>
  <providers>
  <add keyContainerName="MyDeploymentKeyContainer" 
           useMachineContainer="true"
           description="Uses RsaCryptoServiceProvider to encrypt and decrypt"
           name="DeploymentProvider"
     type="System.Configuration.RsaProtectedConfigurationProvider,System.Configuration, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
  </providers>
</configProtectedData>

Затем зашифруйте раздел web.config, указав имя поставщика, как показано выше (здесь это«DeploymentProvider»)

aspnet_regiis -pef "connectionStrings" "C:\WebAppLocation\Folder" -prov "DeploymentProvider"

Теперь вам нужно развернуть приложение на обоих серверах и импортировать контейнер ключа RSA, который вы экспортировали в файл ранее.Скопируйте файл и на каждом сервере запустите:

aspnet_regiis -pi deploykey.xml

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

aspnet_regiis -pa "MyDeploymentKeyContainer" SomeDomain\SomeAccount
0 голосов
/ 09 февраля 2019

Я решил это следующим образом:

aspnet_regiis -pi "MyDeploymentKeyContainer" "c:\keys.xml"
0 голосов
/ 03 ноября 2011

Все, что вы делаете, хорошо, но я также рекомендую вам поставить machinekey в machine.config вместо web.config.Это значение обычно не меняется часто и уменьшает вероятность случайного изменения при изменении web.configs.

Это также позволит вам масштабировать будущие приложения, не портя все больше и больше web.configs.

...