Проверка подлинности и авторизация в Майкрософт Foundry

Проверка подлинности и авторизация в Майкрософт Foundry определяют, как субъекты доказывают удостоверение и получают разрешение на выполнение операций. Foundry делит операции на плоскость управления (управление ресурсами) и плоскость данных (использование среды выполнения), у каждой из которых есть собственная проверка подлинности и контроль доступа на основе ролей (RBAC) на поверхности.

Foundry поддерживает два метода проверки подлинности: Microsoft Entra ID и ключи API. Microsoft Entra ID включает условный доступ, управляемые удостоверения и детализированное ролевое управление доступом (RBAC). Ключи API остаются доступными для быстрого создания прототипов, но отсутствует возможность отслеживания для каждого пользователя. В этой статье сравниваются данные методы, сопоставляются идентификации с ролями и описываются распространенные сценарии с минимальными привилегиями.

Это важно

Используйте Microsoft Entra ID для рабочих нагрузок, чтобы включить условный доступ, управляемые удостоверения и наименьшие привилегии RBAC. Ключи API удобны для быстрой оценки, но предоставляют грубый доступ.

Предпосылки

Подписка Azure. Если у вас нет учетной записи, создайте бесплатную учетную запись.
Ресурс Майкрософт Foundry с настроенным поддоменом custom.
Понимание концепций Azure RBAC.
Чтобы назначить роли, вам потребуется роль Owner или User Access Administrator в соответствующей области.
(Необязательно) Azure CLI или Azure SDK для Python установлен для программной проверки подлинности.
(Необязательно) пакеты Python для примеров кода: pip install azure-identity requests

Плоскость управления и плоскость данных

Операции Azure делятся на две категории: контролируемая плоскость (control plane) и плоскость данных (data plane). Azure отделяет управление ресурсами (плоскость управления) от операционной среды выполнения (плоскости данных). Таким образом, плоскость управления используется для управления ресурсами в вашей подписке, а плоскость данных — для работы с возможностями, предоставляемыми вашим экземпляром указанного типа ресурса. Дополнительные сведения о контрольно-управляющей плоскости и плоскости данных см. в разделе Контрольно-управляющая плоскость и плоскость данных в Azure. В Foundry существует четкое различие между операциями в плоскости управления и операциями в плоскости данных. В следующей таблице объясняются различия между двумя этими понятиями, область применения в Foundry, типичные операции пользователя, примеры инструментов и функций, а также уровень доступа, необходимый для использования каждого из них.

самолёт	Область применения в Foundry	Типичные операции	Примеры инструментов	Поверхность авторизации
Контрольная плоскость	Настройка и конфигурация ресурсов, проектов, сетевых параметров, шифрования и подключений.	Создание или удаление ресурсов, назначение ролей, смена ключей, настройка Приватный канал	портал Azure, Azure CLI, шаблоны ARM, Bicep, Terraform	действия RBAC Azure
Плоскость данных	Выполнение и использование вывода модели, взаимодействие агентов, задания оценки и вызовы безопасности содержимого	Завершение чата, создание вложений, запуск задач точной настройки, отправка сообщений агента, операции анализатора и классификатора	Пакеты SDK, REST API, детская площадка на портале Foundry	Azure RBAC dataActions

Все примеры Bicep, Terraform и SDK см. в репозитории foundry-samples в GitHub для Foundry.

В следующих списках и схеме подробно показано разделение между плоскостями управления и действиями плоскости данных. Действия уровня управления в Foundry включают:

Создание ресурса в Foundry
Создание литейных project
Создание узла возможностей учетной записи
Создание хоста возможностей Project
Развертывание модели
Создание учетных записей и подключений к проекту.

Действия плоскости данных в Foundry включают:

Создание агентов
Выполнение оценки
Трассировка и мониторинг
Fine-tuning

На следующей схеме показано, как в Foundry происходит разделение плоскости управления и плоскости данных, а также управление доступом на основе ролей (RBAC) и каким доступом может обладать пользователь в плоскости управления, плоскости данных или в обеих плоскостях. Как показано на схеме, действия RBAC ("actions") связаны с плоскостью управления, а RBAC "dataActions" связаны с плоскостью данных.

Методы аутентификации

Foundry поддерживает Microsoft Entra ID (на основе токенов, без ключей) и ключи API.

Microsoft Entra ID

Microsoft Entra ID использует маркеры носителя OAuth 2.0, ограниченные https://ai.azure.com/.default.

Используйте Microsoft Entra ID для:

Нагрузки производственной среды.
Условный доступ, многофакторная проверка подлинности (MFA) и динамический доступ.
минимально привилегированный RBAC и интеграция управляемой идентификации.

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

Ограничения: более высокая сложность начальной настройки. Требует понимания access control на основе ролей (RBAC). Дополнительные сведения о RBAC в системе Foundry см. в разделе Ролевая модель управления доступом для Майкрософт Foundry.

Ключи API

Ключи API — это статические секреты, ограниченные ресурсом Foundry.

Использование ключей API для:

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

Преимущества: простые, независимые от языка и не требующие получения токенов.

Ограничения: Невозможно выразить личность пользователя, трудно детализировать область и сложнее проводить аудит. Как правило, не принимается рабочими нагрузками предприятия и не рекомендуется Майкрософт.

Дополнительные сведения о включении проверки подлинности без ключей см. в разделе Настройка без ключа проверки подлинности с помощью Microsoft Entra ID.

Проверка подлинности с помощью Microsoft Entra ID (Python)

В следующем примере показано, как выполнить проверку подлинности с помощью Microsoft Entra ID с помощью библиотеки azure-identity и выполнить запрос к конечной точке Foundry:

from azure.identity import DefaultAzureCredential
import requests

# Create a credential object using DefaultAzureCredential
# This automatically uses environment variables, managed identity, or Azure CLI credentials
credential = DefaultAzureCredential()

# Get an access token for the Cognitive Services scope
token = credential.get_token("https://ai.azure.com/.default")

# Use the token in your API request
headers = {
    "Authorization": f"Bearer {token.token}",
    "Content-Type": "application/json"
}

# Replace with your Foundry endpoint
endpoint = "https://<your-resource-name>.cognitiveservices.azure.com"

# Example: List deployments (adjust the path for your specific API)
response = requests.get(f"{endpoint}/openai/deployments?api-version=2024-10-21", headers=headers)
print(response.json())

Ожидаемые выходные данные: ответ JSON с описанием развертываний модели или ошибка проверки подлинности, если учетные данные отсутствуют или назначение роли не настроено.

Справочник: DefaultAzureCredential | azure-identity library

Проверка подлинности с помощью ключа API (Python)

В следующем примере показано, как пройти проверку подлинности с помощью ключа API. Используйте этот подход только для быстрого создания прототипов; Microsoft Entra ID рекомендуется для рабочей среды.

import requests

# Replace with your actual API key and endpoint
api_key = "<your-api-key>"
endpoint = "https://<your-resource-name>.cognitiveservices.azure.com"

headers = {
    "api-key": api_key,
    "Content-Type": "application/json"
}

# Example: List deployments
response = requests.get(f"{endpoint}/openai/deployments?api-version=2024-10-21", headers=headers)
print(response.json())

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

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

Ожидаемые выходные данные: ответ JSON, в котором перечислены развертывания модели, или ошибка 401, если ключ API недопустим.

Reference: Вращение API ключей доступа

Матрица поддержки компонентов

См. следующую матрицу, чтобы понять, какие возможности в Foundry поддерживают API ключи по сравнению с Microsoft Entra ID.

Возможность или функция	Ключ API	Microsoft Entra ID	Примечания.
Инференция базовой модели (чат, эмбеддинги)	Да	Да	Полностью поддерживается.
Операции тонкой настройки	Да	Да	Entra ID добавляет аудит по каждому субъекту.
Служба агентов	нет	Да	Используйте Entra ID для доступа к средству управляемого удостоверения.
Evaluations	нет	Да	Используйте Entra ID.
анализ вызовов для обеспечения безопасности контента	Да	Да	Используйте RBAC для ограничения операций с высоким риском.
Задания пакетного анализа (понимание содержимого)	Да	Да	Для целей масштабирования рекомендуется использовать Entra ID.
Использование игровой площадки портала	Да	Да	В Playground используется режим подключения проекта.
Сетевая изоляция с помощью Приватный канал	Да	Да	Entra ID добавляет условный доступ.
Принцип наименьших привилегий со встроенными и пользовательскими ролями	нет	Да	Ключи — это все или ничего для каждого ресурса.
Управляемая идентификация (назначаемая системой или пользователем)	нет	Да	Позволяет аутентификацию без использования секретов.
Атрибуция для пользователя по запросу	нет	Да	Маркер содержит идентификаторы арендатора и объектов.
Отзыв (немедленно)	Поворот ключа	Удалить роль или отключить принципала	Применяется короткое время жизни токена.
Поддержка автоматизационных конвейеров	Да (секрет)	Да (сервисный принципал или управляемое удостоверение)	Entra ID сокращает ротацию секретов.
API помощников	Да	Да	Рекомендуется использовать Entra ID.
Пакетная обработка	Да	Да

Типы идентификации

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

Azure поддерживает следующие типы удостоверений.

Тип идентификации	Description
Главный пользователь	Отдельный пользователь в Microsoft Entra ID
Субъект-служба (регистрация приложения)	Идентификация приложения, использующая клиентский секрет или сертификат
Managed identity (назначаемое системой)	Azure идентификатор, связанный с ресурсами, автоматически управляемый платформой.
Управляемая учетная запись (с назначением пользователем)	Автономный идентификатор, который прикрепляется к нескольким ресурсам.

Общие сведения о встроенных ролях

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

Сценарий	Типичные встроенные роли	Примечания.
Создание агентов с предварительно развернутыми моделями	пользователь ИИ Azure	Только использование плоскости передачи данных; нет управляющих записей.
Управление развертываниями или точной настройкой моделей	Менеджер проекта Azure ИИ	Включает создание и обновление модели.
Ротация ключей или управление ресурсами	владелец учетной записи ИИ Azure	Высокие привилегии; рассмотрите настраиваемую роль для минимизации привилегий.
Управление ресурсами, управление развертываниями, агентами сборки	владелец ИИ Azure	Высоко привилегированная роль самообслуживания для пользователей, которым требуется доступ как к контрольной плоскости, так и к плоскости данных. Объедините с Azure Monitor Reader, если необходима наблюдаемость.
Наблюдаемость, трассировка, мониторинг	Пользователь Azure AI (минимальный)	Добавьте Azure Monitor Reader на Application Insights.

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

Подсказка

Создайте пользовательскую роль, если встроенная роль предоставляет избыточные разрешения для вашего варианта использования.

Настройка Microsoft Entra ID

Общие рекомендации по настройке проверки подлинности Entra ID в Foundry см. в статье Configure key-less authentication.

Убедитесь, что ресурс Майкрософт Foundry настроен с настраиваемым поддоменом. См. Пользовательские поддомены. Для аутентификации на основе токенов требуется пользовательский поддомен.
Назначьте необходимую встроенную или пользовательскую роль каждому субъекту. Для назначения ролей требуется роль Owner или User Access Administrator в целевой области. Общие назначения ролей:
- Azure ИИ Пользователь: для разработчиков, которым нужно создавать и тестировать с уже развернутыми моделями.
- Azure AI Project Manager: для руководителей групп, которым необходимо создавать проекты и управлять развертываниями.
- Владелец учетной записи Azure AI: Для администраторов, которым требуется полное управление ресурсами и которые могут условно назначать пользователю Azure AI доступ к дата-плоскости.
- Владелец Azure AI: Для пользователей, которым требуется как полное управление ресурсами, так и доступ к плоскости данных. Пример команды CLI для назначения роли пользователя Azure ИИ:
```
az role assignment create \
  --assignee <principal-id> \
  --role "Azure AI User" \
  --scope /subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.CognitiveServices/accounts/<resource-name>
```
Чтобы проверить назначение роли, запустите az role assignment list --assignee <principal-id> --scope <resource-scope> и подтвердите, что роль отображается в выходных данных.
(Необязательно) Для субъекта-службы создайте регистрацию приложения, добавьте секрет клиента или сертификат и запишите идентификатор арендатора, идентификатор клиента и секрет или сертификат.
(Необязательно) Для управляемого удостоверения включите системное удостоверение в вызывающей службе или прикрепите пользовательское удостоверение, а затем назначьте ему роль на ресурсе Foundry.
Удалите аутентификацию на основе ключей после того, как все вызывающие начнут использовать аутентификацию токенов. При необходимости отключите локальную проверку подлинности в шаблонах развертывания.

Reference: Назначение ролей Azure | Управление доступом на основе ролей для Foundry

Устранение распространенных ошибок проверки подлинности

Ошибка	Причина	Резолюция
401 — не авторизовано	Отсутствующий или истекший токен; недопустимый ключ API	Убедитесь, что область получения токена `https://ai.azure.com/.default`. Повторно создайте ключ API при использовании проверки подлинности на основе ключей.
403 Запрещено	Отсутствие назначения роли RBAC	Назначьте соответствующую встроенную роль (например, Пользователь Azure AI) на уровне ресурса или проекта.
AADSTS700016	Приложение не найдено в клиенте	Убедитесь, что регистрация приложения существует в правильном арендаторе и что идентификатор клиента является правильным.
Обязательный настраиваемый поддомен	Ресурс использует региональную конечную точку вместо пользовательского поддомена	Настройте поддомен custom в ресурсе Foundry. Для аутентификации с использованием токенов требуется настраиваемый поддомен.

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2026-04-08