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

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

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

Необходимые условия

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

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

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

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

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

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

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

• Создание агентов
• Выполнение оценки
• Трассировка и мониторинг
• Точная настройка

На следующей схеме показано представление разделения плоскости управления и плоскости данных в Foundry, а также назначение управления доступом на основе ролей (RBAC) и доступ, который может иметь пользователь в плоскости управления, плоскости данных или в обеих. Как показано на схеме, RBAC "действия" связаны с плоскостью управления, а 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) и доступ в режиме just-in-time.
• Наименее привилегированный RBAC и интеграция управляемых удостоверений.

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

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

Ключи API

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

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

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

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

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

Дополнительные сведения о включении проверки подлинности без ключей см. в разделе Настройка без ключа проверки подлинности с помощью 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

Проверка подлинности с помощью ключа 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())

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

Справочник. Смена ключей доступа к API

Матрица поддержки функций

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

Типы идентификаторов

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

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

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

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

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

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

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

1. Убедитесь, что ресурс Microsoft Foundry настроен на пользовательский поддомен. См. настраиваемые поддомены. Для аутентификации на основе токенов требуется настраиваемый поддомен.

2. Назначьте необходимую встроенную или пользовательскую роль каждому субъекту. Для назначения ролей требуется роль владельца или администратора доступа пользователей в целевой области. Общие назначения ролей:

   • Azure AI User: для разработчиков, которым нужно создавать и тестировать предварительно развернутые модели.
   • 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> и подтвердите, что роль отображается в выходных данных.

3. (Необязательно) Для учетной записи службы создайте регистрацию приложения, добавьте секрет клиента или сертификат и зафиксируйте идентификатор арендатора, идентификатор клиента и секрет или сертификат.

4. (Необязательно) Для управляемого удостоверения включите системно назначаемое удостоверение в вызывающей службе или прикрепите назначенное пользователем удостоверение, затем назначьте ему роль в ресурсе Foundry.

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

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

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

Связанное содержимое

• Управление доступом на основе ролей для Foundry
• Настройка проверки подлинности без ключа с Microsoft Entra ID
• Смена ключей доступа к API
• Azure предустановленные роли (ИИ + машинное обучение)
• Аутентификация против авторизации (Microsoft Entra ID)
• Основы идентификации