Рекомендации по обеспечению безопасности в построителе API данных

Схема текущего расположения ('Оптимизация') в последовательности руководства по развертыванию.

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

Отключение устаревших версий TLS на уровне сервера

Данные, отправленные между клиентом и построителем API данных, должны происходить через безопасное подключение для защиты конфиденциальной или ценной информации. Обычно безопасное подключение устанавливается с помощью протоколов TLS.

Как описано в руководстве по защите транспортного слоя OWASP , TLS предоставляет многочисленные преимущества безопасности при правильной реализации:

  • Конфиденциальность — защита от злоумышленника от чтения содержимого трафика.
  • Целостность — защита от злоумышленника, изменяющего трафик.
  • Предотвращение воспроизведения — защита от повторения запросов злоумышленником на сервер.
  • Проверка подлинности — позволяет клиенту проверить, подключен ли он к реальному серверу (обратите внимание, что удостоверение клиента не проверяется, если не используются сертификаты клиента).

Рекомендации

Одним из способов безопасной настройки TLS является отключение использования устаревших версий TLS на уровне сервера. Построитель API данных основан на Kestrel, кроссплатформенный веб-сервер для ASP.NET Core и настроен по умолчанию для отсрочки конфигурации версии TLS операционной системы. Рекомендации по протоколу TLS Майкрософт по использованию .NET описывают мотивацию такого поведения:

Замечание

TLS 1.2 — это стандарт, обеспечивающий улучшения безопасности по сравнению с предыдущими версиями. Последняя выпущенная стандартная версия TLS 1.3, которая быстрее и безопаснее, в конечном итоге заменит TLS 1.2.

Чтобы обеспечить безопасность приложений .NET Framework, версия TLS не должна быть жестко закодирована. Приложения .NET Framework должны использовать версию TLS, поддерживаемую операционной системой (ОС).

Хотя явное определение поддерживаемых версий протокола TLS для Kestrel поддерживается, это не рекомендуется. Эти определения преобразуются в список разрешений, который предотвращает поддержку будущих версий TLS по мере их доступности. Дополнительные сведения о поведении версии протокола TLS по умолчанию Kestrel см. здесь.

Поддержка TLS

ПРОТОКОЛ TLS 1.2 включен по умолчанию для последних версий .NET и многих последних версий операционной системы.

Настройка аутентификации для производственной среды

Начиная с DAB 2.0, который в настоящее время находится в предварительной версии, поставщик проверки подлинности по умолчанию — Unauthenticated. Это означает, что DAB не инспектирует и не проверяет JSON веб-токены (JWT), и все запросы обрабатываются как anonymous. Другая служба перед DAB может проводить аутентификацию вызывающих абонентов или ограничивать доступ, но DAB по-прежнему авторизует только как anonymous.

Это важно

Если вы предоставляете DAB непосредственно клиентам, настройте поставщика проверки подлинности производственного уровня (например, EntraID или Custom) вместо того, чтобы полагаться на Unauthenticated. Если Unauthenticated активен, authenticated и пользовательские роли, определенные в разрешениях сущностей, никогда не активируются.

Дополнительные сведения см. в разделе "Настройка конфигурации неуверенного поставщика и проверки подлинности среды выполнения".

Делегированная пользователем проверка подлинности от имени (On-Behalf-Of, OBO)

Для развертываний SQL Server и Azure SQL, требующих безопасности на уровне строк с реальной идентификацией пользователя, рекомендуется включить проверку подлинности от имени (OBO). OBO обменивает входящий пользовательский токен на токен SQL для нижестоящей системы, чтобы база данных могла аутентифицироваться от имени фактического вызывающего пользователя. Дополнительные сведения см. в разделе о делегированной пользователем аутентификации.

  • Last updated on