Интеллектуальные приложения, использующие Службу Azure OpenAI через собственные службы Azure, обеспечивают простую проверку подлинности и авторизацию пользователей. Однако некоторые сценарии являются сложными и требуют различных архитектур. Эти сценарии включают топологии с клиентскими приложениями, которые не размещены в Azure, используют внешних поставщиков удостоверений и развертывают несколько клиентов, которые обращаются к одному экземпляру Azure OpenAI. В этих сценариях внедрение шлюза перед Azure OpenAI может значительно повысить безопасность, добавив уровень, обеспечивающий согласованную проверку подлинности для развернутых экземпляров.
В этой статье описываются ключевые сценарии, которые обеспечивают проверку подлинности в Azure OpenAI:
Проверка подлинности клиентских приложений через внешний поставщик удостоверений
Проверка подлинности клиентских приложений с помощью сертификатов
Проверка подлинности клиентских приложений, обращаюющихся к нескольким экземплярам Azure OpenAI
Каждый сценарий описывает проблемы, которые они представляют, и преимущества включения шлюза.
Внимание
Вы можете использовать следующие рекомендации для любой реализации шлюза, включая azure Управление API. Чтобы проиллюстрировать эту гибкость, схемы архитектуры используют универсальные представления компонентов в большинстве сценариев.
Проверка подлинности клиентских приложений через внешний поставщик удостоверений
Скачайте файл Visio для этой архитектуры.
Ограничения сценария
Этот сценарий имеет следующие ограничения:
Клиентские приложения используют внешний поставщик удостоверений с поддержкой OpenID Connect (OIDC), например Okta, Auth0 или социальных удостоверений.
Клиентские приложения проходят проверку подлинности в клиенте Microsoft Entra, отличном от клиента плоскости данных Azure OpenAI.
Эти ограничения могут применяться к следующим примерам:
Существующие клиентские приложения, которые уже проходят проверку подлинности для внешнего поставщика OIDC или идентификатора Microsoft Entra и интегрируются с экземплярами Azure OpenAI.
Клиентские приложения, которые должны последовательно проходить проверку подлинности пользователей из нескольких поставщиков удостоверений.
Подключение непосредственно к Azure OpenAI
Если клиентские приложения в этих сценариях напрямую подключаются к Azure OpenAI без использования шлюза, они должны использовать проверку подлинности на основе ключей для проверки подлинности в Azure OpenAI. Проверка подлинности на основе ключей вызывает дополнительные проблемы безопасности. Необходимо безопасно хранить и поворачивать ключи, и вы не можете предоставлять разные конфигурации управления доступом на основе ролей клиентов (RBAC) для отдельных развертываний моделей.
Введение шлюза
Скачайте файл Visio для этой архитектуры.
Шлюз решает проблемы этого сценария следующими способами:
Шлюз использует open Authorization (OAuth) для проверки подлинности пользователей через существующих внешних поставщиков удостоверений. Шлюз проверяет маркеры доступа пользователей, прошедших проверку подлинности, например веб-маркер JSON (JWT), который создает поставщик удостоверений. Затем шлюз предоставляет авторизацию резервному экземпляру Azure OpenAI.
Вам не нужно управлять ключами клиента. Этот подход устраняет риски безопасности проверки подлинности на основе ключей.
Шлюз подключается к Azure OpenAI с помощью управляемого удостоверения, что повышает безопасность с помощью Azure RBAC с минимальными привилегиями.
Рекомендации по этому сценарию
Добавьте дополнительные области OAuth в регистрацию приложения в поставщике удостоверений, чтобы включить детализированное разрешение для потребителей. Эти области позволяют клиентским приложениям запрашивать разрешение на выполнение определенных операций в шлюзе, включая доступ к Azure OpenAI.
Настройте этот сценарий для Управление API с помощью политик входящего трафика.
validate-jwtИспользуйте политику для принудительного применения значений существования, допустимости и атрибутов поддерживаемого JWT.
Причины, чтобы избежать шлюза для этого сценария
Если одно интеллектуальное приложение обращается к Azure OpenAI, проще настроить проверку подлинности пользователей и авторизацию в приложении, а не через шлюз. Используйте этот подход, чтобы назначить необходимый azure RBAC для безопасной проверки подлинности интеллектуального приложения с помощью Azure OpenAI.
Проверка подлинности клиентских приложений с помощью сертификатов
Скачайте файл Visio для этой архитектуры.
Ограничения сценария
Этот сценарий имеет следующие ограничения:
Вы хотите использовать сертификаты для проверки подлинности клиентских приложений.
Клиентские приложения не могут использовать или не хотите использовать, идентификатор Microsoft Entra или другие поставщики OIDC для проверки подлинности.
Клиенты не могут использовать или не хотите использовать федеративное удостоверение для проверки подлинности.
Эти ограничения могут применяться к следующим примерам:
Клиент, прошедший проверку подлинности в Azure OpenAI, является компьютером или устройством, и взаимодействие с пользователем не выполняется.
В вашей организации требуется использовать сертификаты для проверки подлинности из-за стандартов безопасности и нормативных требований.
Вы хотите предоставить несколько клиентских приложений с параметрами проверки подлинности в зависимости от среды, включая использование сертификатов клиента.
Подключение непосредственно к Azure OpenAI
Azure OpenAI не поддерживает проверку подлинности клиента. Чтобы обеспечить поддержку этого сценария без шлюза, интеллектуальное приложение должно использовать проверку подлинности сертификата для пользователя и ключа API или управляемого удостоверения для проверки подлинности запросов к экземпляру Azure OpenAI. Необходимо реализовать логику проверки подлинности сертификата в каждом клиенте. В этом сценарии проверка подлинности на основе ключей представляет риски и затраты на управление при подключении непосредственно к Azure OpenAI от клиентов.
Введение шлюза
Скачайте файл Visio для этой архитектуры.
Вы можете ввести шлюз в эту архитектуру, которая выгрузит проверку сертификации клиента от клиентов. Шлюз проверяет цифровой сертификат клиента, который представляет интеллектуальное приложение и проверяет издателя, дату окончания срока действия, отпечаток и списки отзыва. Шлюз должен использовать управляемое удостоверение для проверки подлинности с помощью Azure OpenAI. Шлюз также должен использовать Azure Key Vault для хранения корневого центра сертификации (ЦС). Используйте этот подход для централизованной проверки сертификата клиента, что снижает затраты на обслуживание.
Шлюз предоставляет несколько преимуществ в этом сценарии:
Вы используете управляемое удостоверение шлюза вместо ключей доступа, что устраняет риск кражи ключей и снижает нагрузку на обслуживание смены ключей.
Вы можете централизировать проверку сертификата, которая гарантирует, что для оценки цифровых сертификатов клиента для всех интеллектуальных приложений используются согласованные политики безопасности.
Вы можете выгрузить проверку сертификата в шлюз, что упрощает код клиента.
Рекомендации по этому сценарию
Проверьте всю цепочку сертификатов, включая корневой ЦС и промежуточные сертификаты при проверке сертификатов. Полная проверка гарантирует подлинность сертификата и предотвращает несанкционированный доступ.
Регулярно поворачивайте и обновляйте сертификаты клиента, чтобы свести к минимуму риск компрометации сертификатов. Используйте Key Vault для автоматизации этого процесса и поддержания актуальности сертификатов. Настройте оповещения о предстоящих сроках действия сертификата, чтобы предотвратить нарушения работы служб на шлюзе.
Реализуйте взаимную безопасность уровня транспорта (mTLS), чтобы обеспечить проверку подлинности клиента и сервера. Эта стратегия обеспечивает дополнительный уровень безопасности. Чтобы настроить шлюз для принудительного применения MTLS, задайте соответствующие политики и ограничения.
validate-client-certificateИспользуйте политику в Управление API для проверки сертификатов клиентов, на которые ссылается хранилище ключей Azure. Эта политика проверяет сертификат клиента, который представляет клиентское приложение, и проверяет издателя, дату окончания срока действия, отпечаток и списки отзыва.
Причины, чтобы избежать шлюза для этого сценария
В простых средах с несколькими клиентами стоимость обработки безопасности и управления сертификатами в клиенте может перевесить дополнительную сложность внедрения шлюза. Кроме того, шлюзы могут стать одними точками сбоя, увеличивать задержку из-за добавленных слоев и привести к блокировке поставщика, если вы выбираете коммерческие решения, а не пользовательские реализации.
Перед реализацией шлюза для проверки подлинности сертификата клиента необходимо тщательно оценить свои потребности, доступность ресурсов и критически важное значение для приложений.
Проверка подлинности нескольких клиентских приложений с помощью ключей для доступа к общему экземпляру Azure OpenAI
Скачайте файл Visio для этой архитектуры.
Ограничения сценария
Этот сценарий имеет следующие ограничения:
- Несколько клиентских приложений обращаются к общему экземпляру Azure OpenAI.
- Клиенты не могут использовать или не хотите использовать идентификатор Microsoft Entra для проверки подлинности.
- Клиенты не могут использовать или не хотите использовать федеративное удостоверение для проверки подлинности.
- Вы хотите использовать проверку подлинности на основе ключей для клиентских приложений.
Эти ограничения могут применяться к следующим примерам:
Клиентские приложения развертываются в нескольких средах, включая Azure, локальные или другие поставщики облачных служб.
Организация должна предоставить Azure OpenAI разным командам и задать уникальные ограничения доступа и использования для каждой команды.
Подключение непосредственно к Azure OpenAI
Azure OpenAI поддерживает проверку подлинности на основе ключей с помощью общих ключей. Azure OpenAI предоставляет первичный ключ и вторичный ключ. Цель вторичного ключа — поддерживать смену ключей. Он не обеспечивает изоляцию идентификации клиента. При проверке подлинности нескольких клиентов непосредственно в Azure OpenAI в этом сценарии каждый клиент использует один и тот же ключ. Эта реализация имеет следующие проблемы:
Вы не можете отозвать разрешения для определенных клиентов, так как каждый клиент использует один и тот же ключ.
Вы не можете предоставить разным клиентам разные права доступа к разным моделям в одном развертывании экземпляра Azure OpenAI.
Вы не можете отличать один клиент от другого с точки зрения ведения журнала.
Введение шлюза
Скачайте файл Visio для этой архитектуры.
Вы можете ввести шлюз в эту архитектуру, которая выдает выделенный ключ для каждого клиентского приложения. Управление API использует концепцию подписок для предоставления выделенных ключей клиента. Шлюз должен использовать управляемое удостоверение для проверки подлинности с помощью Azure OpenAI.
Шлюз предоставляет несколько преимуществ в этом сценарии:
Вы можете отменить доступ к одному клиентскому приложению, не влияя на другие клиенты.
Вам не нужно обновлять все конфигурации ключей клиента перед поворотом ключей, поэтому смена ключей упрощается. После обновления конфигурации клиента можно повернуть выделенные ключи для каждого клиента.
Вы можете однозначно идентифицировать каждого клиента с точки зрения ведения журнала.
Шлюз применяет ограничения скорости и квоты для каждого клиента независимо.
Рекомендации по этому сценарию
Улучшение мониторинга метрик, связанных с запросами API. При использовании управляемого удостоверения из шлюза трассировка пользовательского и клиентского приложения в журналах Azure OpenAI не улучшается. Шлюз должен предоставить ведение журнала, связанное с запросом, например идентификаторы запрашивающего клиента и пользователя.
Убедитесь, что шлюз принимает решения о маршрутизации для соответствующих развертываний моделей на основе удостоверения клиента при маршрутизации нескольких запросов клиентского приложения через шлюз к общему экземпляру Azure OpenAI. Дополнительные сведения см. в статье "Использование шлюза перед несколькими развертываниями Azure OpenAI".
Проверка подлинности клиентских приложений, обращаюющихся к нескольким экземплярам Azure OpenAI
Скачайте файл Visio для этой архитектуры.
Ограничения сценария
Этот сценарий имеет следующие ограничения:
- Клиентские приложения подключаются к нескольким экземплярам Azure OpenAI в одном или нескольких регионах.
- Клиенты не могут использовать или не хотите использовать, идентификатор Microsoft Entra или другие поставщики OIDC для проверки подлинности.
- Вы хотите использовать проверку подлинности на основе ключей для клиентских приложений.
Эти ограничения могут применяться к следующим примерам:
Клиентские приложения должны распределять свои рабочие нагрузки географически, чтобы уменьшить задержку и повысить производительность.
Клиентские приложения пытаются оптимизировать свои токены в минуту квот, развертывая экземпляры в нескольких регионах.
Для обеспечения непрерывной работы организация требует простой отработки отказа и аварийного восстановления. Поэтому они управляют стратегией двойного развертывания, например стратегией, которая состоит из подготовленного развертывания пропускной способности и развертывания по мере использования.
Клиентские приложения должны использовать определенные возможности модели, доступные только в определенных регионах Azure.
Подключение непосредственно к нескольким экземплярам Azure OpenAI
При подключении клиентских приложений непосредственно к нескольким экземплярам Azure OpenAI каждый клиент должен хранить ключ для каждого экземпляра. Наряду с соображениями безопасности использования ключей существует повышенное бремя управления относительно смены ключей.
Введение шлюза
Скачайте файл Visio для этой архитектуры.
При использовании шлюза для обработки клиентских приложений, обращаюющихся к нескольким развертываниям Azure OpenAI, вы получаете те же преимущества, что и шлюз, обрабатывающий несколько клиентских приложений с помощью ключей для доступа к общему экземпляру Azure OpenAI. Вы также оптимизируете процесс проверки подлинности, так как используется одно определяемое пользователем управляемое удостоверение для проверки подлинности запросов из шлюза в несколько экземпляров Azure OpenAI. Реализуйте этот подход, чтобы сократить общие операционные издержки и свести к минимуму риски неправильной настройки клиента при работе с несколькими экземплярами.
Рекомендации по этому сценарию
Реализуйте методы балансировки нагрузки для распределения запросов API между несколькими экземплярами Azure OpenAI для обработки высокого трафика и обеспечения высокой доступности. Дополнительные сведения см. в статье "Использование шлюза перед несколькими развертываниями Или экземплярами Azure OpenAI".
Сопоставляйте использование маркеров для каждого клиента в шлюзе при реализации мультитенантных сценариев с несколькими экземплярами Azure OpenAI. Этот подход гарантирует, что вы отслеживаете общее использование токенов независимо от экземпляра Azure OpenAI, в который пересылается запрос.
Общие рекомендации
При интеграции Azure OpenAI через шлюз существует несколько перекрестных рекомендаций, которые следует учитывать во всех сценариях.
Используйте Управление API вместо создания собственного решения для эффективного оркестрации API, простой интеграции с другими службами Azure и экономии затрат за счет сокращения усилий по разработке и обслуживанию. Управление API обеспечивает безопасное управление API путем непосредственной поддержки проверки подлинности и авторизации. Он интегрируется с поставщиками удостоверений, такими как идентификатор Microsoft Entra, который позволяет OAuth 2.0 и обеспечивает авторизацию на основе политик. Кроме того, Управление API использует управляемые удостоверения для безопасного и низкого обслуживания доступа к Azure OpenAI.
Объединение сценариев для комплексного решения шлюза
В реальных приложениях варианты использования могут охватывать несколько сценариев из этой статьи. Например, у вас могут быть клиентские приложения, которые проходят проверку подлинности через внешнего поставщика удостоверений и требуют доступа к нескольким экземплярам Azure OpenAI.
Скачайте файл Visio для этой архитектуры.
Чтобы создать шлюз, поддерживающий определенные требования, объедините рекомендации из этих сценариев для комплексного подхода.
Принудительное применение политик шлюза
Прежде чем шлюз отправляет запросы в экземпляры Azure OpenAI, убедитесь, что вы применяете политики проверки подлинности и авторизации входящего трафика. Чтобы убедиться, что шлюз пересылает только прошедшие проверку подлинности и авторизованные запросы, используйте маркеры доступа пользователей от поставщика удостоверений или проверки сертификатов для реализации этого подхода.
Чтобы включить детализированный контроль, реализуйте дополнительные области авторизации с ролями и разрешениями для клиентских приложений в шлюзе. Используйте эти области для разрешения конкретных операций в зависимости от потребностей клиентского приложения. Этот подход повышает безопасность и управляемость.
Для проверки маркера доступа обязательно проверьте все зарегистрированные ключевые утверждения, такие как iss, expaudи nbf любые соответствующие утверждения, относящиеся к рабочей нагрузке, такие как членство в группах или роли приложения.
Использование управляемых удостоверений Azure
Чтобы упростить проверку подлинности во всех сценариях клиентского приложения, используйте управляемые удостоверения Azure для централизованного управления проверкой подлинности. Этот подход снижает сложность и риски, связанные с управлением несколькими ключами API или учетными данными в клиентских приложениях.
Управляемые удостоверения по сути поддерживают Azure RBAC, поэтому они гарантируют, что шлюз имеет только самый низкий уровень разрешений, необходимых для доступа к экземплярам Azure OpenAI. Чтобы снизить риск несанкционированного доступа и упростить соответствие политикам безопасности, объедините управляемые удостоверения с другими методами, которые отключают альтернативную проверку подлинности.
Реализация комплексной наблюдаемости
При реализации шлюза с управляемым удостоверением уменьшается возможность трассировки, так как управляемое удостоверение представляет сам шлюз, а не пользователь или приложение, которое делает запрос. Поэтому важно улучшить наблюдаемость метрик, связанных с запросами API. Чтобы обеспечить видимость шаблонов доступа и использования, шлюзы должны предоставлять дополнительные метаданные трассировки, такие как идентификаторы клиента и пользователя.
Централизованное ведение журнала всех запросов, проходящих через шлюз, помогает поддерживать путь аудита. Централизованный след аудита особенно важен для устранения неполадок, соответствия требованиям и обнаружения попыток несанкционированного доступа.
Реализации шлюза
Azure не предоставляет готовое решение или эталонную архитектуру для создания шлюза в этой статье, поэтому необходимо создать и управлять шлюзом. Azure предоставляет примеры поддерживаемых сообществом реализаций, охватывающих варианты использования в этой статье. Ссылайтесь на эти примеры при создании собственного решения шлюза. Дополнительные сведения см. в видеоролике Learn Live: удостоверение и безопасность приложений OpenAI в Azure.
Соавторы
Следующие участники первоначально написали эту статью.
Основные авторы:
- Lizet Pena De Sola | Старший инженер по работе с клиентами, FastTrack для Azure
- Bappaditya Banerjee | Старший инженер по работе с клиентами, FastTrack для Azure
- Джеймс Крофт | Инженер клиентов, ISV и Digital Native Center of Excellence
Чтобы просмотреть неопубликованные профили LinkedIn, войдите в LinkedIn.
Следующие шаги
- RBAC для Azure OpenAI
- Использование управляемых удостоверений в Управление API
- Политики в управлении API
- Проверка подлинности и авторизация api в Управление API
- Защита API в Управление API с помощью OAuth 2.0 и идентификатора Microsoft Entra
- Защита внутренних служб с помощью проверки подлинности сертификата клиента в Управление API