人脸活体检测的共同责任

Azure 与其客户之间共同负责构建安全合规的人脸活体解决方案。 可以在云共同责任中详细了解 Azure 的共同责任。 了解共同的责任模型对于活体检测解决方案尤其重要。 本文档介绍了如何保护和监视解决方案的各个方面。

保护连接

下图显示了客户如何使用 Azure 来保护端到端连接。

遵循以下准则来保护连接：

• 确保后端服务充当活体检测应用程序中的业务流程协调程序，使用 Azure 的安全基础结构启动活体检测会话并检查结果。 客户负责保护其后端服务。
• 为后端中的客户端应用程序实现适当的身份验证和授权。 确保客户端应用程序与后端服务之间的通信受到保护，不会被操纵。
• 对最终用户的实际标识进行身份验证，并将其帐户信息链接到活体会话。
• 对应用程序进行签名，并仅通过官方商店分发应用程序。

Azure 活体检测通过以下方式保护连接：

• 使用通过会话创建 API 获取的会话授权令牌验证所有事务。
• 仅允许对后端服务的 HTTPS 调用。
• 支持为客户设置标识访问管理 (IAM) 角色进行身份验证和执行操作。

保护客户端应用程序

复杂的攻击者可能会更改或篡改客户端应用程序，这可能会使活体结果不可信。 根据应用程序使用的平台，使用不同的方法：

移动应用程序

在 Android 和 iOS 平台中，都有本机和第三方解决方案来检查应用程序完整性，例如 iOS App Attest，以及 Android Play Integrity。 应用程序开发人员负责整合完整性检查功能，并及时响应潜在的黑客攻击。

Azure 活体检测可针对不可信的运行时环境实施安全措施。 活体检测 SDK 提供其活体检测服务调用的摘要，这些调用可以传递给应用程序完整性 API。

Web 应用程序

Web 应用程序在加载它们的浏览器的上下文中运行。 新式浏览器支持可靠的应用程序完整性检查。 你负责实现部署到浏览器的 Web 应用程序的完整性检查。 这些职责包括但不限于：

• 确保正确配置安全标头。 特别是，应特别注意缓存、HTTP 严格传输安全性 (HSTS)、iframe 和跨源策略。
• 为所有资源配置最严格的内容安全策略 (CSP)。 CSP 有助于防止跨站点脚本 (XSS) 攻击、点击劫持以及与混合内容页面关联的弱点。
• 通过 CSP 启用子资源完整性 (SRI)，并检查以确保加载的 SDK 是 Microsoft发布的真实副本。

Azure 将活体检测 Web SDK 的加密哈希与每个版本一起发布，客户可在其脚本完整性 CSP 标头中使用这些哈希。 Azure 还会确保 Web SDK 可以在新式浏览器中安全上下文的功能限制内运行。

保护客户端设备

不同的应用程序会根据其特定用例和方案具有不同的安全需求，范围包含从基本协议到高度严格协议。 应定制安全措施以满足这些要求。 在这里，我们重点介绍不同环境所需的不同安全级别。

在 Android 和 iOS 平台中，应用程序完整性解决方案（包括其各自的第一方产品/服务）已包括设备完整性和/或信誉。 实施 Web 应用程序并要求其安全基线包含设备完整性的客户需要确保仅通过受信任设备上的受信任新式浏览器访问该应用程序。 通常，此过程涉及：

• 企业设备管理解决方案配置为通过访问应用程序来管理设备。
• 通过设备管理强制实施与 Azure 的设备通信的虚拟网络。
• 安全启动以确保设备管理强制实施的硬件完整性
• 用于更高安全基线的供应链安全性，可以确保设备已得到管理，并且从制造点强制执行其所有安全策略。

这些注意事项也适用于 Android 和 iOS 平台。

Azure 人脸 API 支持虚拟网络和专用终结点。 请参阅指南。

使用高安全基线的客户可以引用设备管理解决方案，例如 Microsoft Defender for Endpoints。

使解决方案保持最新

Microsoft 会定期升级活体检测客户端 SDK 和服务，以提高安全性、可靠性和用户便利性。 保持这些更新的最新状态至关重要，因为活体检测字段面临主动和复杂的攻击。 客户应始终使用最新的客户端 SDK、最新服务和最新模型。 有关详细信息，请参阅了解客户端 SDK 版本。

监视滥用行为

面部识别技术（用于访问授权）可以是攻击者试图绕过它的目标，也可以是基于它构建的活体检测技术的目标。 通常，这些尝试涉及在系统面前暴力破解不同的材料，如各种印刷照片，这被认为是系统滥用。 若要缓解此类暴力攻击，可以针对重试计数和速率限制采取特定作。

• 创建一个具有保守调用和时间限制的会话：会话通过阻止暴力破解入侵来充当活体检测过程的第一道防线。 为每个会话生成会话授权令牌，可用于预设的识别配额或活体检测尝试。 如果应用程序用户未在尝试限制内成功，则需要新的令牌。 要求使用新令牌可以重新评估与进一步重试相关的风险。 通过为每个会话设置保守的允许调用数，可以在颁发新令牌之前更频繁地重新评估此风险。
• 在创建会话时使用适当的关联标识符：设备关联 ID 使人脸 API 中的自动滥用监视启发式功能可帮助你拒绝向系统发送滥用流量。 当特定的关联标识符达到滥用尝试的阈值时，它不再可用于创建会话。 生成随机 GUID 字符串，并将其与系统中同一单个主标识符中的顺序尝试相关联。 要映射的标识符或标识符的选择取决于应用程序需求以及用于评估访问风险的其他参数。 若要允许在必要时重新生成新的随机 GUID，请避免使用应用程序的主要标识符。
• 设计系统以支持人工判断：当标记设备关联 ID 且无法再使用标识符创建会话时，请实施有意义的人工审核过程，以确保不是由于滥用流量或暴力强制尝试而导致故障。 如果在审核后决定允许来自同一实体的更多尝试，因为以前的失败被视为合法，请通过生成映射到单个标识符的新随机 GUID 来重置关联。

对于滥用监视的 Azure 支持

Azure 提供以下机制来监视活体检测会话：

• 在同一关联 ID 上监视跨多个会话的流量；监视到可疑活动时做出响应。
• API 支持审核以在活体会话期间下载实时图像。
• Azure 会保留足够的日志，以进一步防止否认性攻击。

报告滥用行为

如果 Azure AI 人脸 API 未检测到你认为应被检测为欺骗的演示文稿攻击工具，创建 Azure 支持请求。

支持请求应包括：

• 出现的欺骗材料的类型。
• 作为 API 调用的一部分从服务返回的服务信息。 信息至少必须包括 API 路径、请求 ID (apim-request-id)、会话 ID (SID)和 API 模型版本 (model-version)。
• 重现攻击所需的特定条件。
• 重现攻击的分步说明。
• 利用图像或概念证明图像（如果可能）。
• 说明攻击的业务影响。

在向 Microsoft 报告攻击之前，可能会尝试重新创建攻击。 如果无法提供被利用的图像，复现步骤将特别有用。

后续步骤

教程：人脸活体检测