Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Аутентификация и авторизация в Microsoft Foundry контролируют, как участники подтверждают свою личность и получают разрешение на выполнение операций. Foundry делит операции на плоскость управления (управление ресурсами) и плоскость данных (использование среды выполнения), каждая из которых имеет собственную область проверки подлинности и управления доступом на основе ролей (RBAC).
Foundry поддерживает два метода проверки подлинности: идентификатор Microsoft Entra и ключи API. Идентичность Microsoft Entra обеспечивает условный доступ, управляемые удостоверения и детализированное ролевое управление доступом (RBAC). Ключи API остаются доступными для быстрого создания прототипов, но отсутствует возможность отслеживания для каждого пользователя. В этой статье сравниваются данные методы, сопоставляются идентификации с ролями и описываются распространенные сценарии с минимальными привилегиями.
Это важно
Используйте идентификатор Microsoft Entra для рабочих нагрузок, чтобы включить условный доступ, управляемые удостоверения и наименьшие привилегии RBAC. Ключи API удобны для быстрой оценки, но обеспечивают грубый доступ.
Предпосылки
- Подписка Azure. Если ее нет, создайте бесплатную учетную запись.
- Ресурс Microsoft Foundry с настраиваемым поддоменом .
- Общие сведения о концепциях Azure RBAC.
- Чтобы назначить роли, вам нужна роль владельца или роль администратора доступа пользователей в соответствующей области.
- (Необязательно) Azure CLI или Пакет SDK Azure для Python , установленный для программной проверки подлинности.
- (Необязательно) Пакеты Python для примеров кода:
pip install azure-identity requests
Плоскость управления и плоскость данных
Операции Azure делятся на две категории: плоскость управления и плоскость данных. Azure отделяет управление ресурсами (плоскость управления) от операционной среды выполнения (плоскости данных). Таким образом, плоскость управления используется для управления ресурсами в вашей подписке, а плоскость данных — для работы с возможностями, предоставляемыми вашим экземпляром указанного типа ресурса. Дополнительные сведения о плоскости управления и плоскости данных см. в разделе "Плоскость управления Azure" и плоскость данных. В Foundry существует четкое различие между операциями в плоскости управления и операциями в плоскости данных. В следующей таблице объясняется различие между двумя областями, областью в Foundry, типичными операциями пользователя, примерами инструментов и функций, а также областью авторизации для использования каждого из них.
| самолёт | Область применения в Foundry | Типичные операции | Примеры инструментов | Область авторизации |
|---|---|---|---|---|
| Контрольная плоскость | Настройка и конфигурация ресурсов, проектов, сетевых параметров, шифрования и подключений. | Создание или удаление ресурсов, назначение ролей, смена ключей, настройка приватного канала | Портал Azure, Azure CLI, шаблоны ARM, Bicep, Terraform | Действия Azure RBAC |
| Плоскость данных | Выполнение и использование вывода модели, взаимодействие агентов, задания оценки и вызовы безопасности содержимого | Завершение чата, создание вложений, запуск задач точной настройки, отправка сообщений агента, операции анализатора и классификатора | Пакеты SDK, REST API, детская площадка на портале Foundry | Azure RBAC dataActions |
Все примеры Bicep, Terraform и SDK см. в репозитории foundry-samples на сайте GitHub для Foundry.
В следующих списках и схеме подробно показано разделение между плоскостями управления и действиями плоскости данных. Действия уровня управления в Foundry включают:
- Создание ресурса в Foundry
- Создание проекта Foundry
- Создание узла возможностей учетной записи
- Создание узла возможностей проекта
- Развертывание модели
- Создание подключения к учетной записи и проекту
Действия плоскости данных в Foundry включают:
- Создание агентов
- Выполнение оценки
- Трассировка и мониторинг
- Fine-tuning
На следующей схеме показано разделение плоскости управления и плоскости данных в Foundry, а также назначение управления доступом на основе ролей (RBAC) и доступ, который пользователь может иметь в плоскости управления, плоскости данных или в обеих. Как показано на схеме, действия RBAC ("actions") связаны с плоскостью управления, а RBAC "dataActions" связаны с плоскостью данных.
Методы аутентификации
Foundry поддерживает Microsoft Entra ID (на основе токенов, без ключей) и ключи API.
Майкрософт Ентра айди
Microsoft Entra ID использует маркеры носителя OAuth 2.0, предназначенные для https://cognitiveservices.azure.com/.default.
Используйте идентификатор Microsoft Entra для:
- Нагрузки производственной среды.
- Условный доступ, многофакторная аутентификация (MFA) и доступ по требованию.
- минимально привилегированный RBAC и интеграция управляемой идентификации.
Преимущества: тонкая настройка назначения ролей, аудит на уровне субъекта, контролируемое время жизни токенов, автоматическая гигиена секретов и управляемые идентичности для сервисов.
Ограничения: более высокая сложность начальной настройки. Требует понимания управления доступом на основе ролей (RBAC). Дополнительные сведения о RBAC в Foundry см. в разделе "Управление доступом на основе ролей" для Microsoft Foundry.
Ключи API
Ключи API — это статические секреты, ограниченные ресурсом Foundry.
Использование ключей API для:
- Быстрое прототипирование.
- Изолированные тестовые среды, в которых допускается смена одного секрета.
Преимущества: простые, независимые от языка и не требующие получения токенов.
Ограничения: Невозможно выразить личность пользователя, трудно детализировать область и сложнее проводить аудит. Как правило, не принимается рабочими нагрузками предприятия и не рекомендуется корпорацией Майкрософт.
Дополнительные сведения о включении проверки подлинности без ключей см. в разделе "Настройка проверки подлинности без ключей" с помощью идентификатора Microsoft Entra.
Проверка подлинности с помощью идентификатора Microsoft Entra (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://cognitiveservices.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 рекомендуется для рабочей среды.
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 недопустим.
Справочник. Смена ключей доступа к API
Матрица поддержки компонентов
Обратитесь к следующей матрице, чтобы понять, какие возможности в Foundry поддерживаются ключами API по сравнению с Microsoft's Entra ID.
| Возможность или функция | Ключ API | Майкрософт Ентра айди | Примечания. |
|---|---|---|---|
| Инференция базовой модели (чат, эмбеддинги) | Да | Да | Полностью поддерживается. |
| Операции тонкой настройки | Да | Да | Entra ID добавляет аудит по субъектам. |
| Служба агентов | нет | Да | Используйте Entra ID для доступа к инструменту управляемых удостоверений. |
| Evaluations | нет | Да | Используйте Entra ID. |
| анализ вызовов для обеспечения безопасности контента | Да | Да | Используйте RBAC для ограничения операций с высоким риском. |
| Задания пакетного анализа (понимание содержимого) | Да | Да | Рекомендуется использовать Entra ID для масштабирования. |
| Использование игровой площадки портала | Да | Да | В Playground используется режим подключения проекта. |
| Сетевая изоляция с помощью приватного канала | Да | Да | Entra ID добавляет условный доступ. |
| Принцип наименьших привилегий со встроенными и пользовательскими ролями | нет | Да | Ключи — это все или ничего для каждого ресурса. |
| Управляемая идентификация (назначаемая системой или пользователем) | нет | Да | Позволяет аутентификацию без использования секретов. |
| Атрибуция для пользователя по запросу | нет | Да | Маркер содержит идентификаторы арендатора и объектов. |
| Отзыв (немедленно) | Поворот ключа | Удалить роль или отключить принципала | Применяется короткое время жизни токена. |
| Поддержка конвейеров автоматизации | Да (секрет) | Да (сервисный принципал или управляемое удостоверение) | Entra ID уменьшает частоту обновления секретов. |
| API помощников | Да | Да | Рекомендуется использовать идентификатор Entra. |
| Пакетная обработка | Да | Да |
Типы идентификации
Ресурсы и приложения Azure проходят проверку подлинности с помощью различных типов удостоверений, предназначенных для конкретных сценариев. Субъекты-пользователи представляют пользователей, субъекты-службы представляют приложения или автоматизированные процессы, а управляемые удостоверения предоставляют безопасный, бесплатный способ доступа к другим службам в ресурсах Azure. Понимание этих различий помогает выбрать правильное удостоверение для интерактивных входов, обмена данными между приложениями или автоматизации рабочей нагрузки.
Azure поддерживает следующие типы удостоверений.
| Тип идентификации | Description |
|---|---|
| Главный пользователь | Отдельный пользователь в идентификаторе Microsoft Entra |
| Субъект-служба (регистрация приложения) | Идентификация приложения, использующая клиентский секрет или сертификат |
| Управляемое удостоверение (назначаемое системой) | Удостоверение, привязанное к ресурсам Azure, автоматически управляется платформой. |
| Управляемая учетная запись (с назначением пользователем) | Автономный идентификатор, который прикрепляется к нескольким ресурсам. |
Общие сведения о встроенных ролях
В Foundry используйте встроенные роли для разделения разрешенных действий для пользователя. Большинство предприятий хотят разделения действий управления и плоскости данных для своих встроенных ролей. Другие ожидают объединенную роль уровня данных и уровня управления, чтобы свести к минимуму количество необходимых назначений ролей. В следующей таблице перечислены сценарии и соответствующие встроенные роли Foundry, которые лучше всего соответствуют каждому сценарию.
| Сценарий | Типичные встроенные роли | Примечания. |
|---|---|---|
| Создание агентов с предварительно развернутыми моделями | Пользователь Azure AI | Только использование плоскости передачи данных; нет управляющих записей. |
| Управление развертываниями или точной настройкой моделей | Диспетчер проектов Azure AI | Включает создание и обновление модели. |
| Ротация ключей или управление ресурсами | Владелец учетной записи ИИ Azure | Высокие привилегии; рассмотрите настраиваемую роль для минимизации привилегий. |
| Управление ресурсами, управление развертываниями, агентами сборки | Владелец ИИ Azure | Услуга самостоятельного использования с высокими привилегиями для пользователей, которым требуется доступ как к плоскости управления, так и к плоскости данных. Объедините с Azure Monitor Reader, если требуется наблюдение. |
| Наблюдаемость, трассировка, мониторинг | Пользователь ИИ Azure (минимум) | Добавление средства чтения Azure Monitor в Application Insights. |
Чтобы понять разбивку встроенных ролей и действий в области управления и плоскости данных, ознакомьтесь со следующей схемой.
Подсказка
Создайте пользовательскую роль, если встроенная роль предоставляет избыточные разрешения для вашего варианта использования.
Настройка идентификатора Microsoft Entra
Общие рекомендации по настройке аутентификации Entra ID в Foundry см. в разделе Настройка безключевой аутентификации.
Убедитесь, что в вашем ресурсе Microsoft Foundry настроен пользовательский поддомен. См. настраиваемые поддомены. Для аутентификации на основе токенов требуется пользовательский поддомен.
Назначьте необходимую встроенную или пользовательскую роль каждому субъекту. Для назначения ролей требуется роль владельца или администратора доступа пользователей в целевой области. Общие назначения ролей:
- Пользователь ИИ Azure: для разработчиков, которым надо создавать и тестировать с предварительно развернутыми моделями.
- Azure AI Project Manager: для руководителей групп, которым необходимо создавать проекты и управлять развертываниями.
- Владелец учетной записи искусственного интеллекта Azure. Для администраторов, которым требуется полное управление ресурсами и можно условно назначить пользователя ИИ Azure для доступа к плоскости данных.
- Владелец ИИ Azure: для пользователей, которым требуется полное управление ресурсами и доступ к уровню данных. Пример команды CLI для назначения роли пользователя Azure AI:
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.
Удалите аутентификацию на основе ключей после того, как все вызывающие начнут использовать аутентификацию токенов. При необходимости отключите локальную проверку подлинности в шаблонах развертывания.
Справочник: Назначение ролей Azure | Управление доступом на основе ролей для Foundry
Устранение распространенных ошибок проверки подлинности
| Ошибка | Причина | Резолюция |
|---|---|---|
| 401 — не авторизовано | Отсутствующий или истекший токен; недопустимый ключ API | Убедитесь, что область получения токена имеет значение https://cognitiveservices.azure.com/.default. Повторно создайте ключ API при использовании проверки подлинности на основе ключей. |
| 403 Запрещено | Отсутствие назначения роли RBAC | Назначьте соответствующую встроенную роль (например, пользователь ИИ Azure) в области ресурса или проекта. |
| AADSTS700016 | Приложение не найдено в клиенте | Убедитесь, что регистрация приложения существует в правильном арендаторе и что идентификатор клиента является правильным. |
| Обязательный настраиваемый поддомен | Ресурс использует региональную конечную точку вместо пользовательского поддомена | Настройте настраиваемый поддомен в ресурсе Foundry. Для аутентификации с использованием токенов требуется настраиваемый поддомен. |