Поделиться через

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

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

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

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

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

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

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

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

Подсказка

Начните с Simulator в процессе разработки, чтобы тестировать разрешения без настройки поставщика удостоверений. Перед развертыванием перейдите к производственному поставщику.

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

Аутентификация проверяет личность вызывающего абонента. Построитель 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 Description
runtime.host.authentication.provider Поставщик проверки подлинности (EntraID/AzureAD, , CustomAppService, ) StaticWebAppsSimulator
runtime.host.authentication.jwt.audience Ожидаемое утверждение аудитории для поставщиков JWT (не используется AppService/StaticWebApps/Simulator)
runtime.host.authentication.jwt.issuer Ожидаемый издатель/орган для поставщиков JWT (не используется в AppService / StaticWebApps / Simulator)

Для получения подробной информации о настройке см. раздел Настройка аутентификации Microsoft Entra ID.

Авторизация

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Использование 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
Настройка проверки подлинности Microsoft Entra ID Настройка проверки подлинности Entra
Используйте Okta или Auth0 Настройка пользовательской проверки подлинности JWT
Запуск службы приложений Azure Настройка проверки подлинности службы приложений
Локальное тестирование разрешений Настройка проверки подлинности симулятора
Ограничение строк пользователем Реализация безопасности на уровне строк
Понимание назначения ролей Авторизация и роли

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

  • Last updated on