Обзор защиты основных данных ASP.NET

Защита основных данных ASP.NET предоставляет криптографический API для защиты данных, включая управление ключами и смену ключей.

Веб-приложениям часто требуется хранить конфиденциальные данные безопасности. Windows предоставляет API защиты данных, DPAPI, но Windows DPAPI не предназначен для использования в веб-приложениях.

Стек защиты данных ASP.NET Core предназначен для долгосрочной замены <элемента machineKey> в ASP.NET 1.x - 4.x. Он был разработан для решения многих недостатков старого криптографического стека, предоставляя решение вне коробки для большинства вариантов использования современных приложений, скорее всего, столкнутся.

формулировка проблемы;

Общее заявление о проблеме может быть кратко указано в одном предложении: мне нужно сохранить доверенные сведения для последующего извлечения, но я не доверяю механизму сохраняемости. В веб-терминах это может быть записано как "Мне нужно выполнить круговую поездку доверенного состояния через ненадежный клиент".

Канонический пример этого является маркером проверки подлинности cookie или носителя. Сервер создает маркер "I am Groot и имеет разрешения xyz" и передает его клиенту. На некоторой следующей дате клиент будет представлять этот маркер обратно на сервер, но серверу требуется некоторое подтверждение того, что клиент не подделал маркер. Таким образом, первое требование: подлинность (a.k.a. целостность, изменение правописания).

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

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

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

Философия проектирования

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

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

  • Предложить простой API для потребителей. API-интерфейсы должны быть легко использовать правильно и трудно использовать неправильно.

  • Разработчикам не нужно изучать принципы управления ключами. Система должна обрабатывать выбор алгоритма и время существования ключа от имени разработчика. В идеале разработчик никогда не должен иметь доступ к сырым ключевым материалу.

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

С учетом этих принципов мы разработали простой и простой стек защиты данных.

API-интерфейсы защиты основных данных ASP.NET не предназначены в первую очередь для неограниченного сохранения конфиденциальных полезных данных. Другие технологии, такие как Windows CNG DPAPI и Azure Rights Management , более подходят для сценария неограниченного хранилища, и они имеют соответствующие сильные возможности управления ключами. Тем не более чем разработчик не запрещает использовать API защиты данных ASP.NET Core для долгосрочной защиты конфиденциальных данных.

Аудитория

Система защиты данных делится на пять основных пакетов. Различные аспекты этих API предназначены для трех основных аудиторий;

  1. API-интерфейсы потребителей обзор целевых приложений и платформ разработчиков платформы.

    "Я не хочу узнать, как работает стек или как он настроен. Я просто хочу выполнить некоторую операцию как можно проще с высокой вероятностью использования API успешно".

  2. API конфигурации предназначены для разработчиков приложений и системных администраторов.

    "Мне нужно сообщить системе защиты данных, что для моей среды требуются пути или параметры, отличные от по умолчанию".

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

    "Мне нужно заменить весь компонент в системе, потому что у меня есть действительно уникальные требования к поведению. Я готов узнать редко используемые части поверхности API, чтобы создать подключаемый модуль, который соответствует моим требованиям".

Макет пакета

Стек защиты данных состоит из пяти пакетов.

  • Microsoft.AspNetCore.DataProtection.Abstractions содержит IDataProtectionProvider и IDataProtector интерфейсы для создания служб защиты данных. Он также содержит полезные методы расширения для работы с этими типами (например, IDataProtector.Protect). Если система защиты данных создается в другом месте, и вы используете API, обратитесь по ссылке Microsoft.AspNetCore.DataProtection.Abstractions.

  • Microsoft.AspNetCore.DataProtection содержит базовую реализацию системы защиты данных, включая основные криптографические операции, управление ключами, конфигурацию и расширяемость. Чтобы создать экземпляр системы защиты данных (например, добавив ее в ) IServiceCollectionили изменив или расширив его поведение, см. ссылку Microsoft.AspNetCore.DataProtection.

  • Microsoft.AspNetCore.DataProtection.Extensions содержит дополнительные API, которые разработчики могут найти полезными, но которые не принадлежат в основном пакете. Например, этот пакет содержит методы фабрики для создания экземпляра системы защиты данных для хранения ключей в расположении файловой системы без внедрения зависимостей (см. раздел DataProtectionProvider). Он также содержит методы расширения для ограничения времени существования защищенных полезных данных (см. раздел ITimeLimitedDataProtector).

  • Microsoft.AspNetCore.DataProtection.SystemWeb можно установить в существующее приложение ASP.NET 4.x для перенаправления <machineKey> операций для использования нового стека защиты данных ASP.NET Core. Дополнительные сведения см. в разделе "Замена ASP.NET machineKey" в ASP.NET Core.

  • Microsoft.AspNetCore.Cryptography.KeyDerivation предоставляет реализацию процедуры хэширования паролей PBKDF2 и может использоваться системами, которые должны безопасно обрабатывать пароли пользователей. Дополнительные сведения см. в разделе Хэш-пароли в ASP.NET Core.

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