Каково расположение реестра по умолчанию, которое используется для кольца ключей реестра для системы ASP.NET Core Data Protection

TL;DR;

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

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

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

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

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

В разделе "Защита данных" документа "Host 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?

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

2 ответа

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

  • Файловая система
  • Реестр Windows
  • Профиль пользователя IIS (может, в котором ключи сохраняются в реестре HKLM в специальном разделе реестра, который ACL-файл только для учетной записи рабочего процесса. Ключи шифруются в состоянии покоя с использованием 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


Чтобы немного подробнее рассказать о моем тесте:

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

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

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

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

Как только я запустил сценарий powershell Provision-AutoGenKeys.ps1 (из 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.

Другие вопросы по тегам