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

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

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

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

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

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

2. Если профиль пользователя доступен, ключи сохраняются в папке %LOCALAPPDATA%\ASP.NET\DataProtection-Keys . Если операционная система — Windows, ключи шифруются rest с помощью 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 в специальном разделе реестра, доступном только к учетной записи рабочего процесса. Ключи шифруются rest с помощью DPAPI.

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

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

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

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

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

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

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

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

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

Удаление ключей

Удаление ключа делает защищенные данные недоступными. Чтобы устранить этот риск, рекомендуется не удалять ключи. Результирующее накопление ключей обычно оказывает минимальное влияние, потому что они малы. В исключительных случаях, таких как очень длительные службы, ключи можно удалить. Удалить только ключи:

• Это старое (больше не используется).
• Если вы можете принять риск потери данных в обмен на экономию хранилища.

Рекомендуется не удалять ключи защиты данных.

using Microsoft.AspNetCore.DataProtection.KeyManagement;

var services = new ServiceCollection();
services.AddDataProtection();

var serviceProvider = services.BuildServiceProvider();

var keyManager = serviceProvider.GetService<IKeyManager>();

if (keyManager is IDeletableKeyManager deletableKeyManager)
{
    var utcNow = DateTimeOffset.UtcNow;
    var yearAgo = utcNow.AddYears(-1);

    if (!deletableKeyManager.DeleteKeys(key => key.ExpirationDate < yearAgo))
    {
        Console.WriteLine("Failed to delete keys.");
    }
    else
    {
        Console.WriteLine("Old keys deleted successfully.");
    }
}
else
{
    Console.WriteLine("Key manager does not support deletion.");
}

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

• Расширяемость управления ключами в ASP.NET Core
• Узел ASP.NET Core в веб-ферме