Управление ключами для защиты данных и время существования в ASP.NET Core

  • Статья

Автор: Рик Андерсон (Rick Anderson)

Управление ключами

Приложение пытается самостоятельно обнаружить рабочую среду и обрабатывать конфигурацию ключа.

  1. Если приложение размещено в приложение Azure, ключи сохраняются в папке %HOME%\ASP.NET\DataProtection-Keys. Эта папка копируется в сетевое хранилище и синхронизируется на всех машинах, где размещается приложение.

    • Во время хранения ключи не защищаются.
    • Папка DataProtection-Keys предоставляет кольцо ключей всем экземплярам приложения в одном слоте развертывания.
    • Отдельные слоты развертывания, такие как промежуточное хранение и производство, не используют общую связку ключей. При переключении между слотами развертывания, например переключение промежуточного хранения на рабочую среду или использование тестирования A/B, любое приложение с помощью Защиты данных не сможет расшифровать сохраненные данные с помощью кольца ключей внутри предыдущего слота. Это приводит к выходу пользователей из приложения, использующего стандартную проверку подлинности ASP.NET Core cookie , так как она использует защиту данных для защиты своих cookies. Если вы хотите, чтобы кольца ключей независимо от слотов, используйте внешний поставщик кругов ключей, например Хранилище BLOB-объектов Azure, Azure Key Vault, хранилище SQL или кэш Redis.

  2. Если профиль пользователя доступен, ключи сохраняются в папке %LOCALAPPDATA%\ASP.NET\DataProtection-Keys . Если операционная система — Windows, ключи шифруются неактивных данных с помощью DPAPI.

    Также необходимо включить атрибут setProfileEnvironment пула приложений. Значение setProfileEnvironment по умолчанию — true. В некоторых сценариях (например, в ОС Windows) для параметра setProfileEnvironment установлено значение false. Если ключи не хранятся в каталоге профиля пользователя:

    1. Перейдите к папке %windir%/system32/inetsrv/config.
    2. Откройте файл applicationHost.config.
    3. Найдите элемент <system.applicationHost><applicationPools><applicationPoolDefaults><processModel>.
    4. Убедитесь, что атрибут setProfileEnvironment отсутствует и установлено значение по умолчанию true, или же явно задайте для атрибута значение true.

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

  4. Если ни одно из этих условий не соответствует, ключи не сохраняются вне текущего процесса. Когда процесс завершится, все созданные ключи теряются.

Разработчик всегда находится в полном контроле и может переопределить способ и место хранения ключей. Первые три варианта выше должны обеспечить хорошие значения по умолчанию для большинства приложений, аналогичных тому, как <в прошлом работали подпрограммы автоматического создания ASP.NET machineKey> . Последний резервный вариант — это единственный сценарий, который требует от разработчика указать конфигурацию заранее, если требуется сохраняемость ключей, но это резервное копирование происходит только в редких ситуациях.

При размещении в контейнере Docker ключи должны храниться в папке, которая является томом Docker (общим томом или томом, подключенным к узлу, который сохраняется за пределами времени существования контейнера) или внешним поставщиком, например Azure Key Vault или Redis. Внешний поставщик также полезен в сценариях веб-фермы, если приложения не могут получить доступ к общему сетевому тому (дополнительные сведения см. в разделе PersistKeysToFileSystem ).

Предупреждение

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

Время существования ключа

Ключи по умолчанию имеют 90-дневное время существования. После истечения срока действия ключа приложение автоматически создает новый ключ и задает новый ключ в качестве активного ключа. Пока устаревшие ключи остаются в системе, приложение может расшифровать все данные, защищенные с ними. Дополнительные сведения см. в разделе "Управление ключами ".

Алгоритмы по умолчанию

Алгоритм защиты полезных данных по умолчанию — AES-256-CBC для конфиденциальности и HMACSHA256 для проверки подлинности. 512-разрядный главный ключ, изменяющийся каждые 90 дней, используется для получения двух вложенных ключей, используемых для этих алгоритмов на основе полезных данных. Дополнительные сведения см . в производной части подраздела .

Дополнительные ресурсы