Назад | Перейти на главную страницу

Какое расположение реестра по умолчанию используется для набора ключей реестра для системы защиты данных ASP.NET Core

TL; DR;

В каком кусте реестра система защиты данных ASP.NET Core хранит свои ключи, когда вы запускаете приложение в IIS с учетной записью рабочего процесса без профиля пользователя.

Похоже, он повторно использует куст, используемый ASP.NET DPAPI, не так ли?

Мы настраиваем кучу основных приложений asp.net, которые должны работать вместе, и проверка защиты от подделки в настоящее время мешает запросам POST. Это выглядит как ASP.NET core Необходимо настроить защиту данных чтобы все приложения использовали одни и те же ключи.

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

Нам не разрешено активировать профиль пользователя для этих пользователей пула, поэтому мы хотим использовать реестр.

В разделе «Защита данных» документа «Размещение ASP.NET Core в Windows с IIS» Вот мы обнаружили, что для настройки защиты данных в IIS для сохранения связки ключей одним из подходов является создание ключей реестра для защиты данных с помощью сценария PowerShell из github. Вот :

Этот скрипт просто называется так: 

Provision-AutoGenKeys "4.0" "32" $poolSid

При чтении этого сценария PowerShell кажется, что все, что он делает, это устанавливает ACL для пользователя пула по следующим ключам: 

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\2.0.50727.0\AutoGenKeys
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.0\AutoGenKeys
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\ASP.NET\2.0.50727.0\AutoGenKeys
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\ASP.NET\4.0.30319.0\AutoGenKeys

Вот где я совершенно запутался ... они выглядят как ульи для "старых" автоматически сгенерированных ключей для шифрования с помощью ASP.NET, а не ASP.NET Core ....

Итак, мне интересно ... повторно использует ли Microsoft эти кусты для защиты данных ASP.NET Core?

Или мне стоит поискать в другом месте?

ASP.NET Core может хранить ключи практически где угодно:

  • Файловая система
  • Реестр Windows
  • Профиль пользователя IIS (может, в котором ключи сохраняются в реестре HKLM в специальном разделе реестра, доступ к которому ведется только для учетной записи рабочего процесса. Ключи в состоянии покоя зашифровываются с помощью DPAPI)
  • Azure KeyVault, учетная запись хранения Azure
  • Ключи приложения Azure (в% HOME% \ ASP.NET \ DataProtection-Keys)
  • Хранилище SQL
  • Кеш Redis
  • Профиль пользователя (если доступен профиль пользователя, ключи находятся в папке% LOCALAPPDATA% \ ASP.NET \ DataProtection-Keys и зашифрованы при хранении с помощью DPAPI для Windows)

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

Доказательство того, что пудинг есть ...

Я сделал простой тест и ДА в Система защиты данных .NET CORE является повторное использование старых кустов ASP.NET AutoGenKeys для Microsoft.AspNetCore.DataProtection.KeyManagement.

В тесте для добавления данных использовался следующий улей.
HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ ASP.NET \ 4.0.30319.0 \ AutoGenKeys \ S-1-5-21-1112422158-284577691-398547282-74630 \ DataProtection

To elaborate a bit more on my test :

  • У меня есть два простых основных приложения .net, которые отправляют сообщения друг другу.
  • Каждое приложение настроено с собственным пулом приложений.
  • Каждый пул приложений настроен для одного и того же пользователя.
  • У этого пользователя пула нет профиля пользователя и ограниченные права ...

Как только я добавил AntiforgeryValidation (который использует внутреннюю защиту данных .net), вызовы начали давать сбой.

Журнал приложения содержал такие записи:

  • «Использование хранилища в памяти. Ключи не будут сохраняться в хранилище».
  • «Ни профиль пользователя, ни реестр HKLM недоступны. Используется временное хранилище ключей. Защищенные данные будут недоступны, когда приложение существует».

Как только я запустил Provision-AutoGenKeys.ps1 сценарий PowerShell (из https://github.com/aspnet/AspNetCore/blob/master/src/DataProtection/Provision-AutoGenKeys.ps1) для ACL старого ASP.NET AutoGenKeys все начало работать ... Больше никаких предупреждений о том, что реестр HKLM недоступен.

Итак, отвечу на свой вопрос: ДА ... .NET CORE Data Protection повторно использует старый куст ASP.NET AutoGenKeys для Microsoft.AspNetCore.DataProtection.KeyManagement.