将实时情况检测与网络隔离配合使用（预览版）

禁用对内部资源的公用网络访问通常是网络安全状况设计的一部分。 通过控制下的已验证反向代理路由实时检测请求，可以维护专用网络设置，并允许最终用户设备完成运行情况检查。 代理将所需的实时情况检测 API 调用从客户端转发到人脸或 Azure AI 服务。 通过此设置，你将获得严格的网络控制，但也承担更多责任。 必须部署和保护代理终结点，并确保该终结点保持可用 – 满足严格的安全要求需要权衡。

关于网络隔离

如果已禁用人脸或 Azure AI 服务资源的公共访问，则会阻止来自公共客户端（例如 Internet 上的移动应用）的任何直接调用。 人脸实时情况检测功能通常依赖于直接客户端到服务调用，默认情况下在此配置中不起作用。

先决条件

在继续之前，请确保满足以下先决条件：

• 启用了受限访问权限的人脸 API 资源 – 需要人脸或 Azure AI 服务资源，该资源在已获得人脸生存情况检测有限访问功能的订阅中获得批准。 有关详细信息，请参阅 “人脸受限访问 ”页。

• 专用网络配置 – 应配置人脸或 Azure AI 服务资源，以便禁用公用网络访问。 确保网络设置已完成并测试（例如，应用服务器或代理可以通过 专用链接与人脸或 Azure AI 服务资源通信）。

• 使用自定义域进行反向代理 – 部署反向代理服务，该服务充当公共客户端与人脸或 Azure AI 服务资源之间的桥梁。 在可以访问人脸资源的网络中托管此代理，例如同一虚拟网络或通过专用终结点。 使用你控制的公用域名公开代理。

  将代理配置为转发人脸生存度路由，而无需更改现有标头或有效负载。 确保代理将请求直接传递到人脸或 Azure AI 服务资源的专用终结点。 所有授权标头、查询参数和正文内容都必须保持不变。

  代理必须支持实时功能使用的以下 REST 路径。 这些路径用于创建会话、结束会话尝试、执行实时性检查，以及通过人脸验证执行实时性检查：

  • /face/[version]/session/start
  • /face/[version]/session/attempt/end
  • /face/[version]/detectLiveness/singleModal
  • /face/[version]/detectLivenessWithVerify/singleModal

• 域名系统（DNS）管理访问权限 – 由于需要证明代理域的所有权，因此应该能够为该域创建 DNS 记录（特别是 TXT 记录）。

• Azure 支持计划 – 使用专用人脸或 Azure AI 服务资源启用反向代理的过程当前涉及与Microsoft支持协调。 请确保你具有创建 Azure 支持请求的适当支持访问权限。

满足这些先决条件后，即可继续在网络隔离的设置中配置实时情况检测。

解决方案概述

在隔离网络中将人脸生存度检测功能与人脸或 Azure AI 服务资源结合使用涉及几个关键步骤。 概括而言，可以通过支持请求向Microsoft注册代理的信息，验证域所有权，更新客户端应用程序以使用新的代理终结点，然后测试端到端功能。

1. 提交反向代理注册 – 通过打开 Azure 支持请求开始注册自定义代理域以进行人脸生存情况检测。 包括人脸或 Azure AI 服务资源和代理主机名的详细信息。
2. 验证域所有权 – Azure 支持提供验证码。 通过在代理域的特定子域上添加 DNS TXT 记录来证明所有权。
3. 等待 Azure 启用代理访问 – Azure 验证 DNS 记录，并配置人脸或 Azure AI 服务资源以识别代理。 完成后，该服务将了解代理域，以便检测实时性流量。
4. 测试实时情况检测工作流 – 确保安装程序通过从客户端设备运行实时情况检测会话来运行。 验证客户端的请求是否通过代理，以及你是否收到成功的实时结果。

以下部分提供了每个步骤的详细说明。

步骤 1：通过提交支持请求注册反向代理

若要开始使用网络隔离启用实时检测的过程，目标是将反向代理域注册到Microsoft。 打开 Azure 支持请求，为人脸或 Azure AI 服务资源启动此注册。 在 Azure 门户中导航到人脸或 Azure AI 服务资源，然后在左侧菜单中找到 “支持 + 故障排除 ”（可能显示为帮助图标）。

1. 在简短的问题说明的文本框中，输入明确的摘要，例如： “请求在禁用公共网络访问的情况下注册人脸 API 实时检测的反向代理域。
2. 在服务选择中，选择：认知服务（认知 Services-Face API）。
3. 在资源选择中，选择要在其上设置反向代理的订阅和资源。
4. 在问题的选择中，选择：
   • 上述任何内容都没有
   • 问题类型： 安全性
   • 问题子类型： 虚拟网络
5. 滚动到底部，找到 “需要更多帮助？” 部分。 单击“ 创建支持请求”。

在 “新建支持请求 ”页中：

1. 问题说明 – 此说明是从以前的响应中自动填充的。
2. 建议的解决方案 - 应跳过此步骤。
3. 其他详细信息 - 根据需要填写，例如：
   • 问题何时开始？ – 填写适当的时间，或者 不确定使用当前时间
   • 说明 – 填写详细信息，例如：
     • 设置的反向代理主机名（例如 liveness.contoso.com）
     • 确认先决条件
     • 理由或上下文，如果有特定的符合性标准或策略文档，可在此处引用它，帮助我们评估此预览计划是否适合你
   • 首选联系人方法 – 鉴于预期的转机时间和通过电话拼写长随机字符串的复杂性， 电子邮件 更适合此目的
   • 根据需要填写其他字段
4. 查看 + 创建 - 仔细检查是否包含所有必要的详细信息，然后创建票证。

Azure 支持工程师应响应并指导你完成后续步骤。 但是，在继续作之前，我们需要验证你是否确实拥有要使用的域。 此验证步骤可防止未经授权的参与方劫持或误用代理配置。 在下一步中，你将收到执行域验证的说明。

步骤 2：验证域的所有权

启动请求后，Azure 支持工程师将联系域验证步骤。 Azure 需要证明你为代理指定的域确实属于你的组织。 支持团队提供唯一代码，并要求将其置于 DNS 记录中。

Await 验证字符串

Azure 支持工程师更新票证并通过电子邮件发送随机生成的验证字符串。 通过在特定子域下创建 DNS TXT 记录来确认域所有权。 通常，使用的子域是专用域，类似于 azaiverify 域。 例如，如果代理域为 liveness.contoso.com，请为名称 azaiverify.liveness.contoso.com 创建 TXT 记录（电子邮件说明包含此步骤的确切子域）。 TXT 记录的值应为提供的验证字符串。

创建 DNS TXT 记录

使用 DNS 提供商的管理门户或 CLI，按照指示添加新的 TXT 记录。 完全按给定粘贴验证字符串。 不要更改字符串，并确保该字符串在正确的子域下。 发布 TXT 记录后，请响应支持工程师，让他们知道记录已到位。 此步骤需要在特定的时间范围内（通常在 48 小时内）完成，因为验证字符串可能会过期。

支持工程师在成功验证后确认 DNS 记录验证。

步骤 3：Microsoft为代理配置人脸或 Azure AI 服务资源

Microsoft确认域所有权后，支持工程师会在人脸或 Azure AI 服务资源上启用反向代理设置。 配置完成后，将更新支持请求。 然后，可以通过代理使用实时情况检测功能。

此时，人脸或 Azure AI 服务资源会继续拒绝所有直接的公共网络访问，但代理会处理这些调用，然后私下连接到人脸服务。 此设计可确保维护锁定的资源，以满足安全要求。

步骤 4：测试端到端实时检测流

配置后，请全面测试设置，以确保用户可以通过代理完成实时检查。

1. 执行实时性检查

   • 使用客户端应用（例如，使用人脸实时 SDK 的移动应用）以最终用户身份启动实时会话。
   • 确认所有请求都通过代理域路由（检查网络日志或调试器）。

2. 观察代理行为

   • 监视代理的访问日志，以验证它是否接收请求并将其转发到人脸资源的专用终结点。
   • 确保正在访问预期的 API 路径（例如 /face/[version]/session/start）。
   • 检查人脸服务的成功响应（HTTP 200）。

3. 验证 Liveness 结果

   • 在客户端上完成生存性挑战。
   • 确认客户端或应用服务器收到有效的生存结果（例如，成功布尔或分数）。
   • 成功结果确认完整管道（客户端→代理→人脸服务→代理→客户端）正在运行。

4. Troubleshooting

   • 连接问题：如果客户端无法连接或超时，请验证代理域、DNS 解析和代理可用性。
   • HTTP 403 错误：确保向 Azure 注册代理，通过代理路由请求，并使用有效的会话令牌。
   • 部分失败：检查代理日志中是否存在失败的 API 调用;所有 API 路由都必须成功。

   如果问题仍然存在，请联系 Azure 支持部门获取帮助。

5. Real-World 测试

   • 使用实际客户端应用和真实用户进行测试，以评估延迟和用户体验。
   • 监视代理性能、请求速率、响应时间和错误。

安全注意事项和共同责任

通过使用人脸 API 的自定义反向代理，可以有效地承担更多责任，以换取更大的网络控制。 请务必与网络安全专家一起审查影响。

• 网络隔离：公共网络访问保持禁用状态;只有代理可以访问人脸资源。
• 代理作为守护程序：使用 HTTPS、防火墙、速率限制和最少公开的路由来保护代理。
• 共同责任：管理代理可用性、缩放和安全性。 Microsoft保护 Azure 中的人脸服务。
• 端到端加密：使用传输层安全性（TLS）进行客户端到代理的通信，以及从代理到人脸服务的安全连接。
• 符合性和日志记录：如有必要，请使用代理进行审核日志记录。
• 域控制：只能将已验证的域用作代理。 如果更改域或代理基础结构，请更新 Azure。

相关内容

• 有关如何使用网络隔离保护 Azure AI 服务资源（如人脸 API）的指导，请参阅 “配置 Azure AI 服务虚拟网络”页的“使用专用终结点”部分 。

• 有关 Azure 人脸 API 的受限访问功能的详细信息，请参阅 “人脸受限访问 ”页。

• 有关Microsoft的相关安全控制，请参阅 NS-2：使用网络控制页保护云原生服务 。