Настройка защиты данных

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

Существует метод расширения AddDataProtection, возвращающий IDataProtectionBuilder, который сам раскрывает методы расширения, которые вы можете объединить, чтобы настроить различные опции защиты данных. Например, чтобы сохранить ключи в UNC вместо %LOCALAPPDATA% (по умолчанию), настройте систему следующим образом:

public void ConfigureServices(IServiceCollection services)
{
         services.AddDataProtection()
        .PersistKeysToFileSystem(new DirectoryInfo(@"\\server\share\directory\"));

}

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

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

Вы можете настроить систему для защиты ключей, если вызовите один из API конфигурации ProtectKeysWith*. В примере ниже ключи хранятся в UNC и шифруются с помощью конкретного X.509 сертификата.

public void ConfigureServices(IServiceCollection services)
{
services.AddDataProtection()
  .SetDefaultKeyLifetime(TimeSpan.FromDays(14));
}

См. шифрование ключей.

Чтобы настроить систему для использования жизненного цикла ключей по умолчанию, равному 14 дней вместо 90, изучите следующий пример:

public void ConfigureServices(IServiceCollection services)
{
    services.AddDataProtection()
        .SetApplicationName("my application");
}

По умолчанию система защиты данных изолирует приложения друг от друга, даже если они делят один и тот же физический репозиторий ключей. Тогда приложения не могут считывать защищенные данные друг друга. Чтобы два разных приложения могли считывать защищенные данные друг друга, настройте систему, передав одно и то же имя обоим приложениям, как в примере ниже:

public void ConfigureServices(IServiceCollection services)
{
  services.AddDataProtection()
      .DisableAutomaticKeyGeneration();
}

Наконец, у вас может быть сценарий, когда приложение не должно автоматически использовать ключи после истечения их срока службы. Примером такого может служить настройка приложений в отношении первичный/вторичный, когда только первичное приложение отвечает за управление ключами, а все вторичные приложения могут использовать ключи только в формате read-only. Для этого система должна быть настроена вот так:

public void ConfigureServices(IServiceCollection services)
{
  services.AddDataProtection();
  services.ConfigureDataProtection(configure =>
  {
      configure.DisableAutomaticKeyGeneration();
  });
}

Изоляция по приложениям

Система защиты данных ASP.NET автоматически изолирует приложения друг от друга, даже если эти приложения запускаются в одном аккаунте рабочего процесса и используют одни и те же мастер ключи. Это похоже на модификатор IsolateApps элемента System.Web’s <machineKey>.

Механизм изоляции считает каждое приложение на локальной машине отдельной частью, поэтому IDataProtector, предложенный для любого заданного приложения, автоматически включает ID приложения в качестве дискриминатора. Уникальный ID приложения можно получить из двух мест.

  1. Если приложение хостится в IIS, уникальный идентификатор - это конфигурационный путь приложения. Если приложение расположено на ферме, это значение должно быть стабильным, ведь мы предполагаем, что IIS среды настроены одинаково для всех машин на ферме.
  2. Если приложение не хостится в IIS, уникальный идентификатор - это физический путь приложения.

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

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

Смена алгоритмов

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

services.ConfigureDataProtection(configure =>
{
    configure.UseCryptographicAlgorithms(new AuthenticatedEncryptionOptions()
    {
        EncryptionAlgorithm = EncryptionAlgorithm.AES_256_CBC,
        ValidationAlgorithm = ValidationAlgorithm.HMACSHA256
    });
});

По умолчанию EncryptionAlgorithm и ValidationAlgorithm являются AES-256-CBC и HMACSHA256, соответственно. Политика по умолчанию может быть настроена системным администратором через Политика на уровне компьютера, но вызов UseCryptographicAlgorithms переопределит политику по умолчанию.

Вызов UseCryptographicAlgorithms позволяет разработчику указать желаемый алгоритм (из встроенного списка), и разработчику не нужно волноваться насчет реализации алгоритма. Например, в сценарии выше система защиты данных попытается использовать CNG реализацию AES при запуске на Windows, иначе она вернется к классу System.Security.Cryptography.Aes.

Разработчик может указать реализацию вручную, если вызовет UseCustomCryptographicAlgorithms.

Совет

Смена алгоритма не влияет на существующие ключи - она влияет только на новые ключи.

Указание алгоритмов, управляемых пользователем

Чтобы указать алгоритмы, управляемые пользователем, создайте экземпляр ManagedAuthenticatedEncryptionOptions, который указывает типы реализации.

services.ConfigureDataProtection(configure =>
{
    configure.UseCustomCryptographicAlgorithms(new ManagedAuthenticatedEncryptionOptions()
    {
        // a type that subclasses SymmetricAlgorithm
        EncryptionAlgorithmType = typeof(Aes),

        // specified in bits
        EncryptionAlgorithmKeySize = 256,

        // a type that subclasses KeyedHashAlgorithm
        ValidationAlgorithmType = typeof(HMACSHA256)
    });
});

Обычно свойства *Type указывают на конкретную реализацию SymmetricAlgorithm и KeyedHashAlgorithm.

Примечание

У SymmetricAlgorithm длина ключа должна быть ≥ 128 битов, а размер блока ≥ 64 битов, также он должен поддерживать шифрование CBC с PKCS #7. У KeyedHashAlgorithm число символов должно быть >= 128 битов, и он поддерживает ключи длиной, равной длине символов алгоритма хэша. KeyedHashAlgorithm не обязательно должен быть HMAC.

Указание пользовательских Windows CNG алгоритмов

Чтобы указать пользовательский Windows CNG алгоритм, используя шифрование CBC + HMAC валидацию, создайте экземпляр CngCbcAuthenticatedEncryptionOptions, который содержит информацию по алгоритму.

services.ConfigureDataProtection(configure =>
{
    configure.UseCustomCryptographicAlgorithms(new CngCbcAuthenticatedEncryptionOptions()
    {
        // passed to BCryptOpenAlgorithmProvider
        EncryptionAlgorithm = "AES",
        EncryptionAlgorithmProvider = null,

        // specified in bits
        EncryptionAlgorithmKeySize = 256,

        // passed to BCryptOpenAlgorithmProvider
        HashAlgorithm = "SHA256",
        HashAlgorithmProvider = null
    });
});

Примечание

У симметричного блокового алгоритма шифрования длина ключа должна быть ≥ 128 битов, а размер блока ≥ 64 битов, он должен поддерживать шифрование CBC с PKCS #7. У алгоритма хэша длина символов должна достигать >= 128 битов, и он должен открываться флагом BCRYPT_ALG_HANDLE_HMAC_FLAG. Свойства *Provider можно установить на null, чтобы использовать провайдер по умолчанию для конкретного алгоритма. См. BCryptOpenAlgorithmProvider.

Чтобы указать пользовательский Windows CNG алгоритм, используя шифрование Galois/Counter Mode + валидацию, создайте экземпляр CngGcmAuthenticatedEncryptionOptions, который содержит информацию по алгоритму.

services.ConfigureDataProtection(configure =>
{
    configure.UseCustomCryptographicAlgorithms(new CngGcmAuthenticatedEncryptionOptions()
    {
        // passed to BCryptOpenAlgorithmProvider
        EncryptionAlgorithm = "AES",
        EncryptionAlgorithmProvider = null,

        // specified in bits
        EncryptionAlgorithmKeySize = 256
    });
});

Примечание

У симметричного блокового алгоритма шифрования длина ключа должна быть ≥ 128 битов, а размер блока ровно 128 битов, он должен поддерживать шифрование GCM. Свойство EncryptionAlgorithmProvider может быть установлено на null, чтобы использовать провайдер по умолчанию для конкретного алгоритма. См. BCryptOpenAlgorithmProvider.

Указание других пользовательских алгоритмов

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

Поделись хорошей новостью с друзьями!
Следи за новостями!