通过 Azure 原生服务使用 Azure OpenAI 服务的智能应用程序提供无缝的用户身份验证和授权。 但是，有些方案很复杂，需要不同的体系结构设计。 这些方案包括具有非在 Azure 上托管的客户端应用程序的拓扑、使用外部标识提供者，以及部署访问同一 Azure OpenAI 实例的多个客户端。 在这些方案中，在 Azure OpenAI 前面引入网关可以通过添加一个层来确保对已部署实例进行一致身份验证，从而显著改进安全性。
本文介绍向 Azure OpenAI 提供身份验证的主要方案：
每个方案都描述了它们带来的挑战，以及包含网关的好处。
重要
您可以将以下指南用于任何网关实现，包括 Azure API Management。 为了说明这种灵活性，体系结构图在大多数方案中使用组件的通用表示形式。
通过外部标识提供者对客户端应用程序进行身份验证
下载此体系结构的 Visio 文件。
方案约束条件
此方案具有以下约束：
客户端应用程序使用启用了 OpenID Connect (OIDC) 的外部标识提供者，如 Okta、Auth0 或社交标识提供者。
客户端应用程序针对不同于 Azure OpenAI 数据平面租户的 Microsoft Entra 租户进行身份验证。
以下约束可能适用于以下示例：
已针对外部 OIDC 提供程序或 Microsoft Entra ID 进行身份验证且与 Azure OpenAI 实例集成的现有客户端应用程序。
必须一致地对来自多个标识提供者的用户进行身份验证的客户端应用程序。
直接连接到 Azure OpenAI
如果这些方案中的客户端应用程序直接连接到 Azure OpenAI，而不使用网关，则必须使用基于密钥的身份验证向 Azure OpenAI 进行身份验证。 基于密钥的身份验证会带来额外的安全问题。 必须安全地存储和轮换密钥，并且不能为单个模型部署提供不同的客户端基于角色的访问控制 (RBAC) 配置。
网关简介
下载此体系结构的 Visio 文件。
网关通过以下方式解决了此方案的难题：
网关使用 Open Authorization (OAuth) 通过现有的外部标识提供者对用户进行身份验证。 网关会验证标识提供者生成的经过身份验证的用户访问令牌，例如 JSON Web 令牌 (JWT)。 然后，网关向支持 Azure OpenAI 实例授予授权。
您不需要管理客户端密钥。 此方法消除了基于密钥的身份验证的安全风险。
网关使用托管标识连接到 Azure OpenAI，从而通过最低特权的 Azure RBAC 提高了安全性。
针对此方案的建议
将更多 OAuth 作用域添加到标识提供者中的应用程序注册，以实现对使用者的精细权限。 这些作用域让客户端应用程序可请求在网关中执行特定操作的权限，包括访问 Azure OpenAI。
使用入站策略为 API Management 配置此方案。 使用
validate-jwt策略强制实施受支持 JWT 的存在性、有效性和属性值。
在此方案中避免使用网关的原因
如果单个智能应用程序访问 Azure OpenAI，那么在应用中配置用户身份验证和授权比通过网关配置会更轻松。 使用此方法分配必要的 Azure RBAC，以使用 Azure OpenAI 安全地对智能应用程序进行身份验证。
通过证书对客户端应用程序进行身份验证
下载此体系结构的 Visio 文件。
方案约束条件
此方案具有以下约束：
需要使用证书对客户端应用程序进行身份验证。
客户端应用程序无法使用或不想使用 Microsoft Entra ID 或其他 OIDC 提供程序进行身份验证。
客户端无法使用或不想使用联合标识进行身份验证。
以下约束可能适用于以下示例：
向 Azure OpenAI 进行身份验证的客户端是计算机或设备，并且没有用户交互。
由于安全标准和合规性法规，组织要求使用证书进行身份验证。
需要为多个客户端应用程序提供基于其环境进行身份验证的选项，包括使用客户端证书。
直接连接到 Azure OpenAI
Azure OpenAI 本身不支持客户端认证身份验证。 为了在没有网关的情况下支持此方案，智能应用程序需要对用户使用证书身份验证，并使用 API 密钥或托管标识对 Azure OpenAI 实例的请求进行身份验证。 必须在每个客户端中实现证书身份验证逻辑。 在此方案中，如果从客户端直接连接到 Azure OpenAI，则基于密钥的身份验证会带来风险和管理开销。
网关简介
下载此体系结构的 Visio 文件。
可以在该体系结构中引入一个网关，该网关从客户端卸载客户端证书验证。 网关会验证智能应用程序提供的客户端数字证书，并检查颁发者、过期时间、指纹和吊销列表。 网关使用托管标识通过 Azure OpenAI 对自己进行身份验证。 网关还应使用 Azure Key Vault 来存储根证书颁发机构 (CA)。 使用此方法可集中进行客户端证书验证，从而减少维护开销。
在此方案中，网关提供了多项优势：
使用网关的托管标识，而非访问密钥，这可消除密钥被盗的风险，并减少轮换密钥的维护负担。
可以集中进行证书验证，从而确保使用一致的安全策略来评估所有智能应用程序的客户端数字证书。
可以将证书验证卸载到网关，这将简化客户端代码。
针对此方案的建议
验证证书时，验证整个证书链，包括根 CA 和中间证书。 完整验证可确保证书的真实性，并防止未经授权的访问。
定期轮换和续订客户端证书，以最大程度地降低证书泄露的风险。 使用 Key Vault 自动执行此流程并将证书保持最新。 为即将过期的证书设置警报，以防止网关上出现服务中断。
实现相互传输层安全 (mTLS)，以确保客户端和服务器相互进行身份验证。 此策略提供额外的安全层。 要将网关配置为强制实施 mTLS，请设置适当的策略和约束。
使用 API Management 中的
validate-client-certificate策略验证 Azure Key Vault 引用的客户端证书。 此策略验证客户端应用程序提供的客户端证书，并检查颁发者、过期日期、指纹和吊销列表。
在此方案中避免使用网关的原因
在客户端很少的简单环境中，在客户端中处理安全性和证书管理的成本可能超过引入网关所增加的复杂性。 此外，网关可能成为单一故障点，由于增加了层而增加了延迟，并且如果选择商业解决方案而非自定义实现，则会导致供应商套牢。
在实现用于客户端证书身份验证的网关之前，必须仔细评估特定需求、资源可用性和应用程序的关键性。
通过密钥访问共享 Azure OpenAI 实例对多个客户端应用程序进行身份验证
下载此体系结构的 Visio 文件。
方案约束条件
此方案具有以下约束：
- 多个客户端应用程序访问共享 Azure OpenAI 实例。
- 客户端无法使用或不想使用 Microsoft Entra ID 进行身份验证。
- 客户端无法使用或不想使用联合标识进行身份验证。
- 需要对客户端应用程序使用基于密钥的身份验证。
以下约束可能适用于以下示例：
在多个环境中部署客户端应用程序，包括 Azure、本地或其他云提供商。
组织需要为不同的团队提供 Azure OpenAI，并且为每个团队设置独特的访问和使用限制。
直接连接到 Azure OpenAI
Azure OpenAI 支持通过共享密钥进行基于密钥的身份验证。 Azure OpenAI 会公开主密钥和辅助密钥。 辅助密钥的目的是支持密钥轮换。 它不提供客户端标识隔离。 在此方案中，直接向 Azure OpenAI 验证多个客户端的身份时，每个客户端共享相同的密钥。 此实现具有下列挑战：
您无法撤销特定客户端的权限，因为每个客户端都共享相同的密钥。
在相同的 Azure OpenAI 实例部署中，不能为不同的客户端赋予不同的访问权限。
从日志记录的角度来看，无法区分一个客户端和另一个客户端。
网关简介
下载此体系结构的 Visio 文件。
可以在该体系结构中引入一个网关，该网关向每个客户端应用程序颁发专用密钥。 API Management 使用订阅的概念提供专用客户端密钥。 网关使用托管标识通过 Azure OpenAI 对自己进行身份验证。
在此方案中，网关提供了多项优势：
可以在不影响其他客户端的情况下撤销对单个客户端应用程序的访问权限。
轮换密钥之前，无需更新客户端的所有密钥配置，因此密钥轮换在逻辑上会更轻松。 在更新客户端配置之后，可以为每个客户端轮换专用密钥。
从日志记录的角度来看，可以唯一地标识每个客户端。
网关单独对每个客户端强制实施速率限制和配额。
针对此方案的建议
增强对与 API 请求相关的指标的监视。 从网关使用托管标识时，Azure OpenAI 日志中用户和客户端应用程序的可追溯性不会提高。 网关应提供与请求关联的日志记录，例如请求客户端和用户 ID。
通过网关将多个客户端应用程序请求路由到共享 Azure OpenAI 实例时，确保网关根据客户端标识将路由决策传送到适当的模型部署。 有关详细信息，请参阅在多个 Azure OpenAI 部署前使用网关。
对访问多个 Azure OpenAI 实例的客户端应用程序进行身份验证
下载此体系结构的 Visio 文件。
方案约束条件
此方案具有以下约束：
- 客户端应用程序连接到一个或多个区域中的多个 Azure OpenAI 实例。
- 客户端无法使用或不想使用 Microsoft Entra ID 或其他 OIDC 提供程序进行身份验证。
- 需要对客户端应用程序使用基于密钥的身份验证。
以下约束可能适用于以下示例：
客户端应用程序必须按地理位置分发其工作负载，以减少延迟并提高性能。
客户端应用程序试图通过跨多个区域部署实例来优化其每分钟令牌配额。
组织需要无缝故障转移和灾难恢复功能，才能确保连续运行。 因此，它们会管理双重部署策略，例如由预配的吞吐量部署和即用即付部署组成的策略。
客户端应用程序必须使用仅在某些 Azure 区域中可用的特定模型功能。
直接连接到多个 Azure OpenAI 实例
当客户端应用程序直接连接到多个 Azure OpenAI 实例时，每个客户端必须存储每个实例的密钥。 除了使用密钥的安全注意事项之外，关于密钥轮换的管理负担也在增加。
网关简介
下载此体系结构的 Visio 文件。
使用网关处理访问多个 Azure OpenAI 部署的客户端应用程序时，将获得与处理通过密钥访问共享 Azure OpenAI 实例的多个客户端应用程序的网关具有相同的好处。 此外，还简化了身份验证流程，因为使用单个用户定义的托管标识对从网关到多个 Azure OpenAI 实例的请求进行身份验证。 实现此方法可降低整体运营开销，并最大程度地降低处理多个实例时客户端配置不当的风险。
针对此方案的建议
实现负载均衡技术，以在 Azure OpenAI 的多个实例之间分配 API 请求，以处理高流量并确保高可用性。 有关详细信息，请参阅在多个 Azure OpenAI 部署或实例前使用网关。
使用多个 Azure OpenAI 实例实现多租户方案时，关联网关上每个租户的令牌使用情况。 此方法将确保可跟踪令牌总体使用情况，而无需考虑将请求转发到的后端 Azure OpenAI 实例。
一般建议
通过网关集成 Azure OpenAI 时，有几个适用于所有方案的交叉建议需要考虑。
使用 API Management 而不是创建自己的解决方案，可实现高效的 API 业务流程、与其他 Azure 服务的无缝集成，以及通过减少开发和维护工作来节省成本。 API Management 可直接支持身份验证和授权，从而确保安全的 API 管理。 它与标识提供者（如 Microsoft Entra ID）集成，从而支持 OAuth 2.0，并提供基于策略的授权。 此外，API Management 使用托管标识对 Azure OpenAI 进行安全、低维护的访问。
组合方案以实现全面的网关解决方案
在实际应用中，用例可以横跨本文中的多个方案。 例如，你可能拥有通过外部标识提供者进行身份验证的客户端应用程序，并且需要访问多个 Azure OpenAI 实例。
下载此体系结构的 Visio 文件。
要构建一个可满足特定需求的网关，请结合这些方案中的建议，以提供一种全面的方法。
强制实施网关策略
在网关向 Azure OpenAI 实例发送请求之前，确保强制实施入站身份验证和授权策略。 要确保网关仅转发经过身份验证和授权的请求，请使用来自标识提供者的用户访问令牌或者证书验证来实现此方法。
要实现精细控制，请在网关中为客户端应用程序实现更多的角色和权限授权范围。 使用这些范围可根据客户端应用程序的需求允许特定操作。 此方法可增强安全性和可管理性。
对于访问令牌验证，请确保验证所有已注册密钥的声明，如 iss、aud、exp 和 nbf，以及任何相关的特定于工作负荷的声明，如组成员身份或应用程序角色。
使用 Azure 托管标识
要简化所有客户端应用程序方案的身份验证，请使用 Azure 托管标识集中进行身份验证管理。 这种方法降低了在客户端应用程序中管理多个 API 密钥或凭据的复杂性和风险。
托管标识本质上支持 Azure RBAC，因此它们可确保网关仅具有访问 Azure OpenAI 实例所需的最低级别的权限。 要降低未经授权的访问风险，并简化与安全策略的合规性，请将托管标识与禁用替代身份验证的其他方法相结合。
实现全面的可观测性
当使用托管标识实现网关时，它会降低可追溯性，因为托管标识代表的是网关本身，而不是发出请求的用户或应用程序。 因此，提高与 API 请求相关的指标的可观测性至关重要。 要保持对访问模式和使用情况的可见性，网关应提供更多的跟踪元数据，例如请求客户端和用户 ID。
集中记录通过网关的所有请求有助于维护审核线索。 集中式审核线索对于故障排除、合规性和检测未经授权的访问尝试尤其重要。
网关实现
Azure 不提供本文中生成网关的统包解决方案或参考体系结构，因此必须生成和操作网关。 Azure 提供社区支持的实现示例，这些实现涵盖本文中的用例。 生成自己的网关解决方案时，请参考这些示例。 有关详细信息，请参阅视频 Learn Live：Azure OpenAI 应用程序标识和安全性。
供稿人
本文为以下参与者的原创作品。
主要作者：
- Lizet Pena De Sola | FastTrack for Azure 高级客户工程师
- Bappaditya Banerjee | FastTrack for Azure 高级客户工程师
- James Croft | ISV 和数字原生卓越中心客户工程师
要查看非公开的 LinkedIn 个人资料，请登录到 LinkedIn。
后续步骤
- RBAC for Azure OpenAI
- 在 API Management 中使用托管标识
- API 管理中的策略
- API 管理中 API 的身份验证和授权
- 使用 OAuth 2.0 和 Microsoft Entra ID 在 API Management 中保护 API
- 使用 API Management 中的客户端证书身份验证确保后端服务安全