【生成式AI】通过网关为Azure OpenAI服务提供替代身份验证

通过平台原生Azure服务使用Azure OpenAI服务的智能应用程序提供了无缝的用户身份验证和授权方法。然而，有各种场景呈现出复杂性，需要不同的体系结构设计。这些场景包括非Azure托管客户端应用程序的拓扑、外部身份提供程序的使用，以及部署访问同一Azure OpenAI实例的多个客户端。在这些场景中，在Azure OpenAI前面引入网关可以通过添加一层来确保部署实例的身份验证的一致性，从而提供显著的安全改进。

本文探讨了使用Azure OpenAI服务进行身份验证时的以下关键场景。

• 使用外部身份提供程序进行身份验证的客户端应用程序
• 使用证书进行身份验证的客户端应用程序
• 多个客户端应用程序访问共享Azure OpenAI实例
• 客户端应用程序访问多个Azure OpenAI实例
   

每个场景都描述了它们带来的挑战，以及包括网关带来的好处。

重要的

以下指南适用于任何网关实现，包括Azure API管理（APIM）。在大多数场景中，体系结构图通常表示组件，以说明这一点。

使用外部身份提供程序进行身份验证的客户端应用程序

图表显示了解决方案的概念架构，其中客户端应用程序使用外部身份提供商对用户进行身份验证，并使用API密钥对Azure OpenAI进行身份验证。

图表显示了解决方案的概念架构，其中客户端应用程序使用外部身份提供商对用户进行身份验证，并使用API密钥对Azure OpenAI进行身份验证。

场景约束

以下是此场景中的约束条件：

• 客户端应用程序正在使用启用了OpenID Connect（OIDC）的外部身份提供程序，如Okta、Auth0或社交身份提供程序。
• 客户端应用程序正在针对不同于Azure OpenAI数据平面租户的Microsoft Entra租户进行身份验证。
   

这些约束可适用于以下情况：

• 已经通过外部OIDC提供商或Microsoft Entra ID进行身份验证的现有客户端应用程序正在与Azure OpenAI实例集成。
• 客户端应用程序需要以一致的方式对来自多个身份提供者的用户进行身份验证。
   

直接连接到Azure OpenAI

如果这些场景中的客户端应用程序直接连接到Azure OpenAI（不使用网关），则它们必须使用基于密钥的身份验证来向Azure OpenAI进行身份验证。基于密钥的身份验证引入了额外的安全问题，例如安全地存储密钥、旋转密钥，以及无法为不同的客户端提供用于单个模型部署的基于角色的访问控制（RBAC）配置。

引入网关

图中显示了在客户端应用程序和Azure OpenAI之间注入网关，从而启用外部身份提供程序的身份验证。

 

引入网关可以通过以下几种方式解决此场景的挑战：

• 网关可以使用OAuth来使用用户现有的外部身份提供程序对用户进行身份验证。在向支持Azure OpenAI实例授予授权之前，网关会验证身份提供商生成的经过身份验证的用户访问令牌，如JSON Web令牌（JWT）。
• 不再需要管理客户端的密钥，与使用基于密钥的身份验证相关的安全风险也消失了。
• 网关可以使用托管身份连接到Azure OpenAI，从而使用特权最低的Azure RBAC提高安全性。
   

针对该场景的建议和指导

• 可以将更多的OAuth作用域添加到您的身份提供程序中的应用程序注册中，以实现对消费者的细粒度权限。这些作用域允许客户端应用程序请求在网关中执行特定操作的权限，包括访问Azure OpenAI。
• 您可以使用入站策略为Azure API管理配置此方案。使用validate-jwt策略来强制支持的jwt的存在性、有效性和属性值。
   

在这种情况下避免使用网关的原因

如果你有一个智能应用程序访问Azure OpenAI，那么与网关相比，在应用程序内配置用户身份验证和授权会更容易。您可以使用此方法分配必要的Azure RBAC，以使用Azure OpenAI安全地对智能应用程序进行身份验证。

使用证书进行身份验证的客户端应用程序

用户使用客户端证书通过客户端应用程序进行身份验证，并使用API密钥通过Azure OpenAI进行身份验证的关系图。

 

场景约束

以下是此场景中的约束条件：

• 您希望使用证书对客户端应用程序进行身份验证。
• 客户端应用程序无法使用或您不想使用Microsoft Entra ID或任何OIDC提供程序进行身份验证。
• 客户端不能使用或您不想使用联合身份进行身份验证。
   

这些约束可适用于以下情况：

• 向Azure OpenAI服务进行身份验证的客户端是没有用户交互的机器或设备。
• 由于安全标准和法规遵从性，您的组织要求使用证书进行身份验证。
• 您希望为多个客户端应用程序提供基于其环境进行身份验证的选项，包括使用客户端证书。
   

直接连接到Azure OpenAI

Azure OpenAI本机不支持客户端证书身份验证。为了在没有网关的情况下支持此场景，智能应用程序将被限制为对用户使用证书身份验证，并使用API密钥或托管身份验证对Azure OpenAI实例的请求。证书身份验证逻辑必须在每个客户端中实现。在这种情况下，如果您从客户端直接连接到Azure OpenAI，则使用基于密钥的身份验证的风险和管理开销将适用。

引入网关

显示使用具有基于角色的访问控制的托管身份在客户端应用程序和Azure OpenAI之间注入网关的图。

 

您可以在该体系结构中引入一个网关，该网关从客户端卸载客户端证书验证。网关有责任验证智能应用程序提供的客户端数字证书，并检查颁发者、过期时间、指纹和吊销列表。网关应使用托管身份向Azure OpenAI进行身份验证。网关应使用Azure密钥保管库来存储根证书颁发机构（CA），以确保在集中位置管理客户端证书验证，从而减少维护开销。

引入网关来解决这种情况有几个优点，包括：

• 与访问密钥相比，使用网关的托管身份消除了密钥被盗的风险，并减少了轮换密钥的维护负担。
• 集中证书验证可确保您使用一致的安全策略来评估所有智能应用程序的客户端数字证书。
• 将证书验证卸载到网关可以简化客户端代码。

针对该场景的建议和指导

• 验证证书时，请验证整个证书链，包括根CA和中间证书。完全验证可确保证书的真实性，并防止未经授权的访问。
   
• 定期轮换和续订客户端证书，以最大限度地降低证书泄露的风险。使用Azure密钥保管库自动执行此过程，以确保证书始终是最新的。为即将到来的证书过期设置警报还可以防止网关上的服务中断。
• 实现双向TLS（mTLS）以确保客户端和服务器彼此进行身份验证，从而提供额外的安全层。通过设置适当的策略和约束，配置网关以强制执行mTLS。
• 使用Azure API管理，您可以使用validate-client-certificate策略来验证Azure密钥保管库中引用的客户端证书。此策略验证客户端应用程序提供的客户端证书，并检查颁发者、过期时间、指纹和吊销列表。
   

在这种情况下避免使用网关的原因

• 在客户端很少的简单环境中，在客户端中处理安全性和证书管理的成本可能超过引入网关所增加的复杂性。此外，如果您选择商业解决方案而不是定制实施，网关可能会成为单点故障，由于添加了层而增加延迟，并导致供应商锁定。
• 在决定实施客户端证书身份验证网关之前，您必须仔细评估您的特定需求、资源可用性和应用程序的关键性。

使用密钥访问共享Azure OpenAI实例的多个客户端应用程序

该图显示了多个客户端应用程序使用共享API密钥向Azure OpenAI进行身份验证的解决方案的概念架构。

该图显示了多个客户端应用程序使用共享API密钥向Azure OpenAI进行身份验证的解决方案的概念架构。

场景约束

以下是此场景中的约束条件：

• 多个客户端应用程序正在访问一个共享的Azure OpenAI实例。
• 客户端无法使用或您不想使用Microsoft Entra ID进行身份验证。
• 客户端不能使用或您不想使用联合身份进行身份验证。
• 您希望对客户端应用程序使用基于密钥的身份验证。

这些约束可适用于以下情况：

• 客户端应用程序部署在多个环境中，包括Azure、其他云提供商或内部部署。
• 组织需要向不同的团队提供Azure OpenAI服务，每个团队都有唯一的访问和使用限制。

直接连接到Azure OpenAI

Azure OpenAI支持使用共享密钥进行基于密钥的身份验证。虽然Azure OpenAI公开了一个主密钥和一个辅助密钥，但辅助密钥的目的是支持密钥轮换，而不是用于客户端身份隔离。在这种情况下，当您直接向Azure OpenAI验证多个客户端时，每个客户端共享相同的密钥。以下是实施过程中的挑战：

• 您无法吊销特定客户端的权限，因为每个客户端都共享相同的密钥。
• 在同一Azure OpenAI实例部署中，您不能向不同的客户端授予对不同模型的不同访问权限。
• 从日志记录的角度来看，您无法区分一个客户端和另一个客户端。

引入网关

该图显示了多个客户端和Azure OpenAI之间的网关，每个客户端具有订阅密钥和托管身份验证。

 

您可以在该体系结构中引入一个网关，该网关向每个客户端应用程序颁发专用密钥。Azure API管理使用订阅的概念来提供专用的客户端密钥。网关应使用托管身份向Azure OpenAI进行身份验证。

引入网关来解决这种情况有几个优点，包括：

• 您可以在不影响其他客户端的情况下撤销对单个客户端应用程序的访问。
• 旋转密钥在逻辑上变得不那么困难，因为在旋转密钥之前不需要更新所有客户端的密钥配置。在更新客户端配置之后，可以为每个客户端旋转专用密钥。
• 每个客户端都可以从日志记录的角度进行唯一标识。
• 网关负责独立执行每个客户端的速率限制和配额。

针对该场景的建议和指导

• 由于使用来自网关的托管身份不会提高Azure OpenAI日志中最终用户和客户端应用程序的可跟踪性，因此可以增强对与API请求相关的指标的监控。网关应提供与请求相关联的日志记录，例如请求客户端和用户ID。
• 当通过网关将多个客户端应用程序请求路由到共享Azure OpenAI服务时，请确保网关根据客户端身份向适当的模型部署做出路由决策。有关多个Azure OpenAI部署的网关实现的更多最佳实践，请参阅在多个Azure Open AI部署之前使用网关。
   

客户端应用程序访问多个Azure OpenAI实例

显示客户端应用程序使用每个实例的共享API密钥对多个Azure OpenAI实例进行身份验证的图表。

场景约束

以下是此场景中的约束条件：

• 客户端应用程序正在连接到一个或多个区域中的多个Azure OpenAI实例。
• 客户端不能使用或您不想使用Microsoft Entra ID或任何OIDC提供程序进行身份验证。
• 您希望对客户端应用程序使用基于密钥的身份验证。

这些约束可适用于以下情况：

• 客户端应用程序需要按地理位置分布其工作负载，以减少延迟并提高性能。
• 客户端应用程序试图通过跨多个区域部署实例来优化其每分钟令牌（TPM）配额。
• 组织需要无缝的故障切换和灾难恢复功能，以通过管理双重部署战略来确保连续运行，双重部署战略可能包括供应吞吐量部署和现收现付部署。
• 客户端应用程序需要使用仅在某些Azure区域中可用的特定模型功能。

直接连接到多个Azure OpenAI实例

当客户端应用程序直接连接到多个OpenAI实例时，每个客户端都必须存储每个实例的密钥。除了使用密钥的安全考虑外，还增加了有关轮换密钥的管理负担。

引入网关

网关的示意图，该网关具有客户端应用程序的单个密钥，并具有基于角色的访问控制的Azure OpenAI的托管身份验证。

引入网关来处理访问多个Azure OpenAI部署的客户端应用程序具有与引入网关来使用密钥访问共享Azure OpenAI实例来处理多个客户端应用程序相同的好处。除了这些原因之外，通过使用单个用户定义的托管身份来验证从网关到多个Azure OpenAI实例的请求，验证过程得到了简化。实现这种方法可以减少总体操作开销，并最大限度地减少在处理多个实例时客户端配置错误的风险。

针对该场景的建议和指导

• 实施负载平衡技术，将API请求分布在Azure OpenAI服务的多个实例中，以处理高流量并确保高可用性。有关此实现的更多信息，请参阅在多个Azure OpenAI部署或实例前使用网关。
• 当您使用多个Azure OpenAI实例实现多租户场景时，必须在网关处关联特定租户的跟踪令牌使用情况。关联网关上的令牌使用情况可确保跟踪令牌的总使用情况，而不管请求转发到哪个后端Azure OpenAI实例。

一般性建议

当您通过网关集成Azure OpenAI服务时，有几个跨领域的建议需要考虑，适用于所有场景。

选择Azure API管理（APIM）而不是创建自己的解决方案有几个好处。它提供了高效的API编排、与其他Azure服务的轻松集成，并通过降低开发和维护工作量来节省成本。APIM通过直接支持身份验证和授权来提供安全的API管理。它与身份提供程序（如Microsoft Entra ID）集成，支持OAuth 2.0，并提供基于策略的授权。此外，它还可以利用托管身份对Azure OpenAI进行安全、低维护的访问。

组合场景以实现全面的网关解决方案

在实践中，您的用例可以跨越本指南中概述的多个场景。例如，您可能拥有通过外部身份提供商进行身份验证的客户端应用程序，并且需要访问多个Azure OpenAI实例。

显示客户端应用程序通过访问多个Azure OpenAI实例的网关与外部身份提供商进行身份验证的图表。

结合这些场景中的建议，可以提供一种全面的方法来构建一个支持您特定需求的网关。

网关策略强制执行

在通过网关向Azure OpenAI实例发送请求之前，应强制执行入站身份验证和授权策略。无论是通过身份提供者的用户访问令牌还是通过证书验证，实现这种方法都可以确保只转发经过身份验证和授权的请求。

在网关中为客户端应用程序实现更多的角色和权限授权范围，还可以实现细粒度控制。这些作用域允许根据客户端应用程序的需要允许特定的操作，从而增强了安全性和可管理性。

对于访问令牌验证，请确保验证所有密钥注册声明，如iss、aud、exp和nbf，以及任何相关的特定于工作负载的声明，如组成员身份或应用程序角色。

使用Azure托管身份

使用Azure托管身份通过集中身份验证管理简化了所有客户端应用程序场景中的身份验证。这种方法降低了在客户端应用程序中管理多个API密钥或凭据的复杂性和风险。

由于托管身份固有地支持Azure基于角色的访问控制，因此它们确保网关仅具有访问Azure OpenAI实例所需的最低级别的权限。与禁用替代身份验证方法相结合，托管身份降低了未经授权访问的风险，并简化了对安全策略的遵守。

实现综合可观测性

当您使用托管标识实现网关时，可追溯性可能会降低，因为托管标识代表的是网关，而不是最终用户或发出请求的应用程序。因此，提高与API请求相关的度量的可观察性是至关重要的。网关应该提供更多的跟踪元数据，包括请求客户端和用户ID，以保持对访问模式和使用情况的可见性。

集中记录通过网关的所有请求也有助于维护审计跟踪。集中的审核跟踪对于故障排除、法规遵从性和确保能够检测到未经授权的访问尝试尤其重要。

网关实施

Azure没有为构建这样的网关提供交钥匙解决方案或参考体系结构。正如介绍文章中所提到的，您必须构建和操作此网关。以下是社区支持的实现示例，涵盖了前面提到的用例。在构建自己的网关解决方案时，请考虑参考这些示例。

实施示例

Azure没有为构建这样的网关提供交钥匙解决方案或参考体系结构。正如介绍文章中所提到的，您必须构建和操作此网关。以下是社区支持的实现示例，涵盖了前面提到的用例。在构建自己的网关解决方案时，请考虑参考这些示例。

Implementation	Example
Azure OpenAI Application Identity and Security – Learn Live Webinar	Learn Live: Azure OpenAI Application Identity & Security (youtube.com)

接下来的步骤

为您的工作负载实现网关提供的好处超出了本文中详细介绍的改进身份验证和授权的场景。了解网关可以解决的其他关键挑战。

贡献者
以下贡献者最初撰写了这篇文章。

主要作者：

• Lizet Pena De Sola | Azure快速通道高级客户工程师
• Bappaditya Banerjee | Azure快速通道高级客户工程师
• James Croft | ISV和数字原生卓越中心客户工程师
   

要查看非公开的领英个人资料，请登录领英。

相关资源

• Role-based access control for Azure OpenAI
• Use managed identities in Azure API Management
• Policies in Azure API Management
• Authentication and authorization to APIs in Azure API Management
• Protect an API in API Management using OAuth 2.0 and Microsoft Entra ID
• Secure API Management backend using client certificate authentication