Каково расположение реестра по умолчанию, которое используется для кольца ключей реестра для системы 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.