Защитите свою конструкторскую среду API данных

Конструктор API предоставляет доступ к данным через REST- и GraphQL-эндпоинты. Защита API требует внимания к трем основным областям: проверка подлинности (кто вызывает?), авторизация (что они могут сделать?) и транспортная безопасность (защищается ли подключение?).

Иллюстрация сквозного потока запросов с проверкой подлинности, авторизацией и доступом к базе данных.

Три основных принципа безопасности

Столп Вопрос, на который дается ответ Ключевая концепция
Аутентификация Кто звонитель? Проверка токенов от поставщика удостоверений
Авторизация Что они могут сделать? Разрешения на основе ролей для сущностей
Транспорт Безопасно ли подключение? Шифрование протокола TLS для всего трафика

Выбор поставщика проверки подлинности

Построитель API данных поддерживает несколько поставщиков проверки подлинности. Выберите тот, который соответствует сценарию развертывания:

Поставщик Сценарий использования Guide
Неаутентифицированный DAB находится за интерфейсом доверенного, который обрабатывает идентификацию (по умолчанию) Настройка поставщика без проверки подлинности
Microsoft Entra ID (EntraID/AzureAD) Производственные приложения с использованием идентификации Microsoft Настройка проверки подлинности Microsoft Entra
Пользовательский веб-токен JSON (JWT) Сторонние поставщики удостоверений (IdP) (Okta, Auth0, Keycloak) Настройка пользовательской проверки подлинности JWT
Служба приложений Приложения, работающие через EasyAuth службы приложений Azure (платформенные заголовки) Настройка проверки подлинности службы приложений
Симулятор Локальная разработка и тестирование Настройка проверки подлинности симулятора
OBO (делегированный пользователем) Базы данных SQL, требующие реального удостоверения пользователя (безопасность на уровне строк, аудит) Настройка проверки подлинности OBO

Замечание

Функции построителя данных 2.0, описанные в этом разделе, находятся в предварительной версии и могут измениться до общедоступной доступности. Дополнительные сведения см. в статье "Новые возможности" версии 2.0.

Аутентификация

Аутентификация проверяет личность вызывающего абонента. Построитель API данных выполняет проверку подлинности запросов путем проверки маркеров носителя JWT (EntraID/AzureAD, Custom) или доверия заголовкам удостоверений, предоставляемым платформой (AppService, StaticWebApps). Simulator пропускает внешнюю проверку в среде разработки.

Иллюстрация того, как клиенты проходят проверку подлинности в построителе API данных с помощью токенов JWT.

Принцип работы

  1. Для поставщиков JWT клиент получает маркер от поставщика удостоверений.
  2. Клиент отправляет токен в заголовке Authorization: Bearer <token> (поставщики JWT) или платформа добавляет заголовки удостоверения (EasyAuth/SWA)
  3. Построитель API данных проверяет заголовок токена или платформы (издатель, аудитория, подпись для поставщиков JWT)
  4. DAB извлекает роли пользователя из токена или идентификационного заголовка.

Краткий справочник

Setting Описание
runtime.host.authentication.provider Поставщик проверки подлинности (Unauthenticated,, EntraID/AzureADCustom, AppService, StaticWebApps, ) Simulator
runtime.host.authentication.jwt.audience Ожидаемое утверждение аудитории для поставщиков JWT (не используется AppService/StaticWebApps/Simulator/Unauthenticated)
runtime.host.authentication.jwt.issuer Ожидаемый издатель или уполномоченный орган для поставщиков JWT (не используется AppService/StaticWebApps/Simulator/Unauthenticated)

Сведения о конфигурации для конкретного поставщика см. в руководствах по проверке подлинности в этом разделе.

Authorization

Авторизация определяет, что может сделать прошедший проверку подлинности (или анонимный) пользователь. Конструктор API данных использует управление доступом на основе ролей (RBAC) для ограничения доступа к действиям и сущностям.

Иллюстрация того, как построитель api данных выбирает роль и оценивает разрешения для запроса.

Принцип работы

  1. DAB назначает роль запросу на основе токена и заголовков.
  2. DAB ищет права доступа объекта для этой роли
  3. Если роль имеет разрешение на запрошенное действие, DAB выполняет запрос.
  4. Если нет, DAB возвращает ответ 403 Forbidden

Системные роли и роли пользователей

Тип роли Описание
Anonymous Назначается, если аутентифицированное удостоверение отсутствует
Authenticated Назначается при проверке подлинности запроса (заголовок доверенной платформы JWT) и не выбрана определенная роль пользователя.
Роли пользователей Пользовательские роли из утверждения токена roles (или роли платформы), выбранные с помощью X-MS-API-ROLE заголовка

Безопасность по умолчанию

Сущности по умолчанию не имеют разрешений. Необходимо явно предоставить доступ:

{
  "entities": {
    "Book": {
      "permissions": [
        { "role": "authenticated", "actions": ["read"] }
      ]
    }
  }
}

Подробные сведения о конфигурации см. в обзоре авторизации.

Безопасность на уровне строк и на уровне полей

Перейдите за рамки разрешений уровня сущности с помощью точного управления доступом:

Функция Описание Guide
Политики базы данных (безопасность на уровне строк) Преобразование выражений политики в предикаты запросов, которые фильтруют строки на основе утверждений или контекста сеанса Реализация безопасности на уровне строк
Безопасность на уровне полей Включение или исключение определенных столбцов для каждой роли Доступ к полю
От имени (OBO) Обменяйте входящий токен пользователя на нижестоящий токен SQL, чтобы база данных выполняла проверку подлинности как текущий вызывающий пользователь (только mssql). Пользовательская делегированная аутентификация

Наследование ролей

DAB 2.0 представляет наследование ролей для разрешений сущностей. Цепочка наследования — это named-role → authenticated → anonymous. Если роль не настроена явно для сущности, она наследует от следующей по иерархии более широкой роли. Определите разрешения один раз на anonymous, и каждая более широкая роль получает такой же доступ. Дополнительные сведения см. в разделе "Наследование ролей".

Безопасность транспорта и конфигурации

Безопасность транспорта

  • Использование TLS для всех подключений: шифрование трафика между клиентами и DAB
  • Отключение устаревших версий TLS: используйте только TLS 1.2+
  • Использование конечных точек HTTPS: никогда не предоставляйте DAB через незашифрованный HTTP в рабочей среде

Дополнительные сведения см. в рекомендациях по обеспечению безопасности.

Безопасность конфигурации

  • Хранение секретов в переменных среды: использование @env('SECRET_NAME') в конфигурации
  • Использование Azure Key Vault: ссылаться на секреты с помощью @azure('key-vault-uri')
  • Никогда не добавляйте секреты: держитеdab-config.json свободным от паролей и строк подключения
{
  "data-source": {
    "connection-string": "@env('SQL_CONNECTION_STRING')"
  }
}

Мониторинг и обновления

  • Мониторинг доступа: использование Application Insights для отслеживания запросов и обнаружения аномалий
  • Проверка журналов: проверка неудачных попыток проверки подлинности и отказов в разрешении
  • Обновление DAB: применение исправлений для системы безопасности путем обновления до последней версии

Краткие руководства по началу работы

задачи Guide
Использование доверенного интерфейса без проверки JWT в DAB Настройка поставщика без проверки подлинности
Настройка аутентификации Microsoft Entra ID Настройка проверки подлинности Microsoft Entra
Используйте Okta или Auth0 Настройка пользовательской проверки подлинности JWT
Запуск службы приложений Azure Настройка проверки подлинности службы приложений
Локальное тестирование разрешений Настройка проверки подлинности симулятора
Ограничение строк пользователем Реализация безопасности на уровне строк
Понимание назначения ролей Обзор авторизации

Связанный контент

  • Last updated on