你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn。
禁用对内部资源的公用网络访问通常是网络安全状况设计的一部分。 通过控制下的已验证反向代理路由活体检测请求,可以维护专用网络设置,并允许最终用户设备完成活体检查。 代理将必需的活体检测 API 调用从客户端转发到人脸或 Foundry Tools。 通过此设置,你将获得严格的网络控制,但也承担更多责任。 必须部署和保护代理终结点,并确保该终结点保持可用 – 满足严格的安全要求需要权衡。
关于网络隔离
如果已禁用 Face 或 Foundry Tools 资源的公共访问权限,则会阻止来自公共客户端(例如互联网上的移动应用程序)的任何直接调用。 人脸活体检测功能通常依赖于直接客户端到服务的调用,默认情况下在此配置中不起作用。
先决条件
在开始之前,请确保满足以下先决条件:
启用了受限访问权限的人脸 API 资源–你需要获得批准使用人脸活体检测受限访问功能的订阅中的人脸或 Foundry Tools 资源。 有关详细信息,请参阅人脸服务受限访问页面。
专用网络配置 – 应配置 Face 或 Foundry 工具资源,以便禁用公用网络访问。 确保您的网络设置已完成并经过测试(例如,您的应用服务器或代理可以通过专用链接与Face或Foundry工具资源进行通信)。
具有自定义域的反向代理 – 部署反向代理服务,该服务充当公共客户端与人脸或 Foundry 工具资源之间的桥梁。 在可以访问人脸资源的网络中托管此代理,例如同一虚拟网络或通过专用终结点。 使用你控制的公用域名公开代理。
将代理配置为转发人脸活体路由,而无需更改现有标头或有效负载。 确保代理将请求直接传递到您的 Face 或 Foundry Tools 资源的私有终端节点。 所有授权标头、查询参数和正文内容都必须保持不变。
代理必须支持活体功能使用的以下 REST 路径。 这些路径用于创建会话、结束会话尝试、执行活体检查,以及通过人脸验证执行活体检查:
/face/[version]/session/start/face/[version]/session/attempt/end/face/[version]/detectLiveness/singleModal/face/[version]/detectLivenessWithVerify/singleModal
域名系统 (DNS) 管理访问权限 – 由于你需要证明代理域的所有权,因此应该能够为该域创建 DNS 记录(特别是 TXT 记录)。
Azure 支持计划 – 当前需要 Microsoft 支持团队配合,才能使用专用人脸或 Foundry Tools 资源启用反向代理的过程。 请确保你具有创建 Azure 支持请求的适当支持访问权限。
满足这些先决条件后,即可继续在网络隔离的设置中配置活体检测。
解决方案概述
在隔离网络中,将人脸活体检测功能与人脸或 Foundry Tools 资源结合使用涉及几个关键步骤。 概括而言,可以通过支持请求向 Microsoft 注册代理的信息,验证域所有权,更新客户端应用程序以使用新的代理终结点,然后测试端到端功能。
- 提交反向代理注册 – 开启 Azure 支持请求以开始注册自定义代理域以进行人脸活体检测。 请加入你的人脸或 Foundry Tools 资源和代理主机名的详细信息。
- 验证域所有权 – Azure 支持提供验证码。 通过在代理域的特定子域上添加 DNS TXT 记录来证明所有权。
- 等待 Azure 启用代理访问 – Azure 会验证 DNS 记录,并配置 Face 或 Foundry Tools 资源以便识别代理。 完成后,该服务将知晓你的代理域,以便活体检测流量通过。
- 测试活体检测工作流 – 通过从客户端设备运行活体检测会话来确保设置无误。 验证客户端的请求是否通过代理,以及你是否收到成功的活体结果。
以下部分提供了每个步骤的详细说明。
步骤 1:通过提交支持请求注册反向代理
若要开始使用网络隔离启用活体检测的过程,你的目标是将反向代理域注册到 Microsoft。 开启 Azure 支持请求,为人脸或 Foundry Tools 资源启动此注册。 在 Azure 门户中导航到 Face 或 Foundry Tools 资源,然后在左侧菜单中找到 支持 + 故障排除 (可能显示为帮助图标)。
- 在简短的问题说明文本框中,输入明确的摘要,例如:“请求在禁用公用网络访问的情况下注册人脸 API 活体检测的反向代理域。”
- 在服务选择中,选择:认知服务(认知服务-人脸 API)。
- 在资源选择中,选择要在其上设置反向代理的订阅和资源。
- 在问题的选择中,选择:
- 以上均不是
- 问题类型:安全性
- 问题子类型:虚拟网络
- 滚动到底部,找到“需要更多帮助?”部分。 点击“创建支持请求”。
在“新建支持请求”页中:
- 问题说明 – 此说明是从以前的响应中自动填充的。
- 建议的解决方案 - 应跳过此步骤。
- 其他详细信息 - 根据需要填写,例如:
- 该问题是何时开始的? – 填写适当的时间,或者不确定,使用当前时间
- 说明 – 填写详细信息,例如:
- 设置的反向代理主机名(例如
liveness.contoso.com) - 确认先决条件
- 理由或上下文,如果有特定的合规性标准或策略文档,可在此处引用它,帮助我们评估此预览计划是否适合你
- 设置的反向代理主机名(例如
- 首选联系人方法 – 鉴于预期的周转时间和通过电话拼写长随机字符串的复杂性,电子邮件更适合此目的
- 根据需要填写其他字段
- 查看 + 创建 - 仔细检查是否包含所有必要的详细信息,然后创建工单。
Azure 支持工程师应响应并指导你完成后续步骤。 但是,在继续操作之前,我们需要验证你是否确实拥有要使用的域。 此验证步骤可防止未经授权的参与方劫持或误用代理配置。 在下一步中,你将收到执行域验证的说明。
步骤 2:验证域的所有权
启动请求后,Azure 支持工程师将联系你来完成域验证步骤。 Azure 需要证明你为代理指定的域确实属于你的组织。 支持团队会提供一个唯一代码,并要求你将其置于 DNS 记录中。
等待验证字符串
Azure 支持工程师更新工单并通过电子邮件发送随机生成的验证字符串。 通过在特定子域下创建 DNS TXT 记录来确认域所有权。 通常,使用的子域是你的域上的专用域,类似于 azaiverify。 例如,如果代理域为 liveness.contoso.com,为名称 azaiverify.liveness.contoso.com 创建 TXT 记录(电子邮件说明包含此步骤的确切子域)。 TXT 记录的值应为提供的验证字符串。
创建 DNS TXT 记录
使用 DNS 提供商的管理门户或 CLI,按照指示添加新的 TXT 记录。 完全按给定粘贴验证字符串。 不要更改字符串,并确保该字符串在正确的子域下。 发布 TXT 记录后,请响应支持工程师,让他们知道记录已到位。 此步骤需要在特定的时间范围内(通常在 48 小时内)完成,因为验证字符串可能会过期。
注释
域验证窗口为 48 小时。 在建议的时间范围内完成 DNS TXT 记录设置,避免请求新的验证码。
支持工程师在成功验证后会确认 DNS 记录验证。
步骤 3:Microsoft 为你的人脸或 Foundry Tools 资源配置代理
Microsoft确认您的域所有权后,支持工程师会在Face或Foundry Tools资源上启用反向代理设置。 配置完成后,将更新支持请求。 然后,你可以通过代理使用活体检测功能。
此时,人脸或 Foundry Tools 资源会继续拒绝所有直接公用网络访问,但代理会处理这些调用,然后私密连接到人脸服务。 此设计可确保维护锁定的资源,以满足安全要求。
步骤 4:测试端到端活体检测流
配置后,请全面测试设置,以确保用户可以通过代理完成活体检查。
执行活体检查
- 使用客户端应用(例如,使用人脸活体 SDK 的移动应用)以最终用户身份启动活体会话。
- 确认所有请求都通过代理域路由(检查网络日志或调试器)。
观察代理行为
- 监视代理的访问日志,以验证它是否接收请求并将其转发到人脸资源的专用终结点。
- 确保正在访问预期的 API 路径(例如
/face/[version]/session/start)。 - 检查人脸服务的成功响应 (HTTP 200)。
验证活体结果
- 在客户端上完成活体质询。
- 确认客户端或应用服务器收到有效的活体结果(例如,成功布尔值或分数)。
- 成功结果会确认完整管道(客户端→代理→人脸服务→代理→客户端)运行无误。
Troubleshooting
- 连接问题:如果客户端无法连接或超时,请验证代理域、DNS 解析和代理可用性。
- HTTP 403 错误:确保向 Azure 注册代理,通过代理路由请求,并使用有效的会话令牌。
- 部分失败:检查代理日志中是否存在失败的 API 调用;所有 API 路由都必须成功。
如果问题仍然存在,请联系 Azure 支持部门获取帮助。
现实世界测试
- 使用实际的客户端应用和真实用户进行测试,以评估延迟和用户体验。
- 监视代理性能、请求速率、响应时间和错误。
安全注意事项和共同责任
通过使用人脸 API 的自定义反向代理,你可以有效地承担更多责任,以换取更大的网络控制。 请务必与网络安全专家一起审查影响。
- 网络隔离:公共网络访问保持禁用状态;只有代理可以访问人脸资源。
- 代理作为守护程序:使用 HTTPS、防火墙、速率限制和最少公开的路由来保护代理。
- 共同责任:管理代理可用性、缩放和安全性。 Microsoft 保护 Azure 中的人脸服务。
- 端到端加密:使用传输层安全性 (TLS) 进行客户端到代理的通信,以及从代理到人脸服务的安全连接。
- 符合性和日志记录:如有必要,请使用代理进行审核日志记录。
- 域控制:只能将已验证的域用作代理。 如果更改域或代理基础结构,请更新 Azure。
相关内容
有关如何使用网络隔离保护 Foundry 工具资源(如人脸 API)的指导,请参阅 “配置 Foundry 工具虚拟网络”页的“使用专用终结点”部分 。
有关 Azure 人脸 API 的受限访问功能的详细信息,请参阅“人脸受限访问”页。
有关 Microsoft 的相关安全控制,请参阅 NS-2:使用网络控制保护云原生服务页。