在线考试人脸识别如何合规？本地活体检测、人脸模板加密与替代认证的技术架构设计

一、政策背景：在线考试系统的人脸识别，为什么需要重新审视？

2025年3月，国家互联网信息办公室、公安部联合公布《人脸识别技术应用安全管理办法》（国家互联网信息办公室、公安部令第19号）。

该办法自2025年6月1日起施行。

近年来，在线考试系统已经从简单的账号密码登录，逐步发展为支持人脸识别、活体检测、屏幕监控、异常行为分析等功能的综合考务平台。

在大型集团培训、岗位资格考核、安全生产考试等场景中，人脸识别可以辅助解决以下问题：

考试登录账号是否由本人使用；
考试过程中是否存在人员替换；
远程考试是否需要进一步确认身份；
发生争议时，如何复核身份验证结果。

但是，人脸属于生物识别信息，与一般账号密码存在明显区别。

密码泄露后可以修改，人脸特征却无法像密码一样重新设置。

而且，人脸模板一旦与员工姓名、工号、考试记录等信息关联，便可能形成具有较高敏感性的个人信息集合。

因此，在线考试系统不能只考虑识别准确率，还应考虑收集是否必要、认证是否可替代、信息保存位置是否合理，以及数据是否具备受控删除机制。

1.1 《办法》中值得技术人员关注的要求

条款	主要要求	技术设计重点
第四条	特定目的、充分必要、最小影响	最小化采集与目的限定
第五、六条	告知义务及基于同意处理时的单独同意	独立告知、授权与撤回
第七条	不满14周岁未成年人信息保护	监护人同意、专门规则
第八条	设备端存储、互联网传输限制、最短保存期限	本地识别、存储边界、数据生命周期
第九条	事前进行个人信息保护影响评估	风险评估、留痕和复评
第十条	符合条件时提供非人脸识别替代方式	多种身份认证路径
第十四条	加密、审计、访问控制等措施	数据安全架构
第十五条	达到规定存储数量时履行备案	存储规模管理与合规备案

其中，第十条对在线考试系统的设计具有直接影响。

如果存在能够实现相同目的或者达到同等业务要求的其他非人脸识别方式，就不能把人脸识别作为唯一验证方式。

个人不同意使用人脸识别身份验证时，应提供其他合理、便捷的方式。国家另有规定的，从其规定。

这意味着，系统在规划考试身份核验时，不应默认所有考生必须上传人脸信息才能参加考试。

技术架构应当支持多种核验方式，而不是把所有考生绑定到单一的人脸识别流程。

二、首先明确：人脸照片、人脸模板和核验结果不是一回事

开发在线考试系统时，常见的数据设计错误，是将人脸照片、特征向量和核验日志统一放在一个数据表中。

实际上，这三类数据的用途及风险并不相同。

2.1 原始人脸图像

例如摄像头采集到的照片或视频帧。

原始图像通常包含比身份核验所需更多的信息，包括个人外貌以及周围环境。

如果只是为了进行一次身份核验，系统是否有必要长期保存完整图像，应当进行独立评估。

2.2 人脸特征模板

人脸识别算法通常通过特征提取模型，将图像转化成用于匹配的特征表示。

例如：

复制代码

Camera Frame
     |
     v
Face Detection
     |
     v
Face Alignment
     |
     v
Feature Extraction
     |
     v
Face Embedding
     |
     v
1:1 Face Verification

特征模板可能以浮点数向量等形式表示。

需要注意：

人脸特征模板并不是天然匿名化的数据。

只要该模板能够用于识别或者关联特定个人，通常仍属于需要依法保护的人脸信息。

不能因为数据库保存的是特征向量，而不是照片，就认为可以随意存储、共享或用于其他用途。

2.3 身份核验结果

例如：

复制代码

{
  "examId": "EXAM-2026-001",
  "userId": "USER-001",
  "method": "ON_DEVICE_FACE",
  "status": "PASS",
  "verifiedAt": "2026-10-10T09:00:00+08:00"
}

这里的结果只描述一次核验事件，不直接包含原始人脸照片或特征向量。

在完成身份验证目的、风险评估允许的情况下，考试业务系统可以优先保留必要的核验状态和审计信息，而不是长期保存全部人脸材料。

核验结果仍可能涉及个人信息，需要实施权限控制、保存期限管理及目的限制。

三、推荐架构：优先考虑设备端1:1人脸核验

从个人信息保护角度来看，值得优先研究的方向，是将人脸采集和匹配处理尽量保留在受控的设备端。

而不是默认把所有考生的人脸照片上传到一台集中式服务器。

3.1 设备端本地核验架构

复制代码

                 考生
                  |
                  v
             考试身份选择
                  |
           +------+------+
           |             |
           v             v
       人脸核验       非人脸认证
           |             |
           v             |
     受控考试终端        |
           |             |
           v             |
      摄像头采集         |
           |             |
           v             |
       活体检测          |
           |             |
           v             |
      本地1:1比对        |
           |             |
           v             v
      可信核验结果    替代认证结果
           |             |
           +------+------+
                  |
                  v
           Java身份验证服务
                  |
                  v
            考试准入检查
                  |
                  v
              正式考试

这种架构将身份核验与考试业务管理进行分离。

设备端处理人脸信息，Java业务系统主要负责考试安排、考生资格、认证状态以及考试会话管理。

但这里有一个关键前提：

服务器不能无条件相信普通客户端返回的"人脸验证通过"。

如果考生使用的是可以自行修改的普通网页，攻击者可能伪造JavaScript调用结果。

因此，受控终端方案还需要考虑可信执行环境、设备身份、结果签名、挑战响应和设备完整性验证等安全措施。

即使采用这些机制，也需要通过实际安全测试评估其抗攻击能力。

3.2 为什么优先推荐1:1核验？

人脸识别主要有两种模式。

对比项目	1:1身份核验	1身份检索
核验方式	与特定人员的参考模板比较	在多个人脸模板中进行搜索
典型场景	已知考生身份后确认本人	在人脸库中寻找对应身份
数据处理范围	通常较小	通常较大
系统复杂度	相对较低	相对较高
在线考试适用性	更适合已知账号身份确认	需论证额外必要性

例如，考生已经通过企业统一身份平台登录，系统能够确定其申报的用户身份。

如果业务确需进行人脸核验，采用该考生对应的参考模板进行1:1验证，通常比在全体员工人脸数据库中进行1搜索更符合数据最小化设计思路。

《办法》第十九条也分别定义了"一对一"身份验证与"一对多"特定个人辨识。

在一般企业培训考试中，不应仅为了简化开发就默认启用全员人脸库搜索。

四、本地活体检测如何设计？

活体检测主要用于判断摄像头前呈现的是否为真实人体特征，而不是照片、屏幕重放或其他呈现攻击。

但是，活体检测与身份识别属于两个不同环节。

活体检测通过，只能表明采集内容满足某种活体判断条件，不代表这个人一定就是指定考生。

4.1 活体检测与1:1身份比对的顺序

可以采用以下流程：

复制代码

摄像头采集
     |
     v
检测人脸区域
     |
     v
检查图像质量
     |
     v
执行活体检测
     |
     v
提取临时人脸特征
     |
     v
与授权参考模板1:1比对
     |
     v
生成核验结果
     |
     v
清理不再需要的临时数据

其中，图像质量检测可以辅助识别严重遮挡、光照不足、模糊等问题。

活体检测则需要评估真实呈现攻击风险。

4.2 常见活体检测方式

第一种：静默式活体检测。

基于图像或视频特征判断是否存在照片、屏幕翻拍等呈现攻击。

优点是操作流程相对简单，但效果取决于算法、摄像头及攻击类型。

第二种：交互式活体检测。

例如要求考生按照随机提示完成特定动作。

这种方式可以引入挑战响应机制，但并不意味着能够防御全部视频合成或注入攻击。

第三种：专用设备活体检测。

在具备条件的受控考试终端上，可以采用具有相应安全能力的摄像设备或身份核验模块。

具体方案需要考虑硬件成本、终端兼容性、认证安全以及企业管理要求。

对于普通浏览器远程考试场景，尤其要防范视频流替换、虚拟摄像头及客户端数据伪造。

简单增加"眨眼检测"，并不能证明系统已经具备高强度防攻击能力。

4.3 活体检测不能只追求识别通过率

在测试过程中，至少需要关注：

真实考生被错误拒绝的情况；
不同光照条件下的表现；
佩戴眼镜、面部遮挡等情况；
不同终端摄像头的适配能力；
对照片、屏幕重放等攻击的识别能力；
检测失败后的人工复核与替代认证流程。

对于活体检测技术，可参考ISO/IEC 30107系列标准中的呈现攻击检测框架及测试方法。

不能单纯用"识别准确率99.9%"来替代系统级安全评估。

五、人脸模板加密：Java如何使用AES-GCM保护敏感数据？

有些考试项目出于特定业务需要，可能要求在受控服务器端保存人脸参考模板。

这一场景必须先确认相关处理具有充分必要性、适用的法律依据以及符合《办法》第八条要求的相应条件。

特别需要注意：

企业服务器位于内网，不等于服务器就是《办法》所说的人脸识别设备。

设备外集中存储不能仅凭"已经私有化部署"就认定符合要求。

以下介绍的是在依法允许集中保存的前提下，如何从技术层面对存储数据进行加密保护。

5.1 为什么不能直接存储明文特征向量？

假设数据库中保存：

复制代码

user_id: USER001

face_template:
[0.128, -0.235, 0.487, ...]

如果数据库账号泄露，攻击者可能取得可用于人脸匹配的特征信息。

因此，在确需存储且具备合法处理条件的情况下，应当对模板实施严格保护。

常见设计包括：

应用层认证加密；
数据加密密钥与业务数据库分离；
按租户、人员和用途绑定加密上下文；
通过KMS或HSM管理密钥；
限制解密服务的调用权限；
记录敏感数据访问审计；
根据保存目的和期限执行删除。

5.2 AES-GCM加密示例

下面使用Java 17提供一个简化的AES-GCM工具类。

AES-GCM是一种认证加密方式，可以在保护机密性的同时检测密文是否遭到篡改。

复制代码

import javax.crypto.Cipher;
import javax.crypto.SecretKey;
import javax.crypto.spec.GCMParameterSpec;

import java.nio.ByteBuffer;
import java.nio.charset.StandardCharsets;
import java.security.GeneralSecurityException;
import java.security.SecureRandom;

public final class FaceTemplateCrypto {

    private static final int IV_SIZE = 12;
    private static final int TAG_BITS = 128;
    private static final byte FORMAT_VERSION = 1;

    private static final SecureRandom RANDOM =
            new SecureRandom();

    private FaceTemplateCrypto() {
    }

    public static byte[] encrypt(
            byte[] template,
            SecretKey key,
            String context
    ) throws GeneralSecurityException {

        byte[] iv = new byte[IV_SIZE];
        RANDOM.nextBytes(iv);

        Cipher cipher = Cipher.getInstance(
                "AES/GCM/NoPadding"
        );

        cipher.init(
                Cipher.ENCRYPT_MODE,
                key,
                new GCMParameterSpec(TAG_BITS, iv)
        );

        cipher.updateAAD(
                context.getBytes(StandardCharsets.UTF_8)
        );

        byte[] encrypted = cipher.doFinal(template);

        return ByteBuffer.allocate(
                    1 + IV_SIZE + encrypted.length
                )
                .put(FORMAT_VERSION)
                .put(iv)
                .put(encrypted)
                .array();
    }

    public static byte[] decrypt(
            byte[] stored,
            SecretKey key,
            String context
    ) throws GeneralSecurityException {

        if (stored == null ||
                stored.length < 1 + IV_SIZE + 16) {
            throw new GeneralSecurityException(
                    "Invalid encrypted template"
            );
        }

        ByteBuffer buffer = ByteBuffer.wrap(stored);

        byte version = buffer.get();

        if (version != FORMAT_VERSION) {
            throw new GeneralSecurityException(
                    "Unsupported format version"
            );
        }

        byte[] iv = new byte[IV_SIZE];
        buffer.get(iv);

        byte[] encrypted = new byte[buffer.remaining()];
        buffer.get(encrypted);

        Cipher cipher = Cipher.getInstance(
                "AES/GCM/NoPadding"
        );

        cipher.init(
                Cipher.DECRYPT_MODE,
                key,
                new GCMParameterSpec(TAG_BITS, iv)
        );

        cipher.updateAAD(
                context.getBytes(StandardCharsets.UTF_8)
        );

        return cipher.doFinal(encrypted);
    }
}

以上代码用于说明加密与完整性校验方式，不是一套完整的人脸信息管理系统。

在生产环境中，需要进一步注意以下问题。

第一，密钥不能硬编码。

示例中的SecretKey应由经过授权的密钥管理服务提供。

不应将真实密钥直接写在配置文件、源代码或普通数据库中。

第二，同一密钥下不能重复使用GCM IV。

示例为每次加密生成随机12字节IV。

生产系统还需要结合密钥使用规模、加密调用数量和密钥轮换策略管理IV唯一性风险。

第三，AAD必须由可信服务端构造。

例如使用：

复制代码

tenantId | userId | templateVersion | purpose

这些内容可以作为认证附加数据，与密文进行完整性绑定。

但AAD本身不提供保密性，不能直接包含不应暴露的敏感数据。

第四，解密接口必须严格限制。

不能向普通管理员、统计报表接口或者开放API提供任意解密人脸模板的能力。

第五，必须设计密钥轮换和删除机制。

包括模板版本变化、密钥失效、授权撤回、备份处理等情况。

即使已经加密，人脸模板仍然属于应受到严格保护的敏感信息，不能因此延长无必要的保存期限。

六、数据库设计：如何管理人脸模板生命周期？

如果确有依法允许的集中模板存储需求，可以将模板管理与考试业务数据进行隔离。

一个简化的逻辑数据结构如下：

复制代码

face_template_record
|
+-- record_id
+-- tenant_id
+-- user_id
+-- template_version
+-- encrypted_template
+-- key_version
+-- processing_purpose
+-- authorization_reference
+-- expire_at
+-- status
+-- created_at
+-- deleted_at

其中：

authorization_reference用于关联已经确认的合法处理依据或授权记录，并不意味着所有处理活动都只依靠同意作为法律基础。

expire_at应根据具体业务目的、必要性与适用法律要求确定。

status可以设置为：

复制代码

ACTIVE
   |
   +-- EXPIRED
   |
   +-- WITHDRAWN
   |
   +-- REVOKED
   |
   +-- DELETED

对于普通员工培训考试，不能不加区分地把人脸模板永久绑定在人员档案中。

培训档案可能需要长期保存，但人脸识别模板未必需要保存同样长的时间。

6.1 推荐的数据分离方式

复制代码

人员组织数据库
      |
      +-- 员工基础信息
      +-- 组织部门
      +-- 岗位信息

考试业务数据库
      |
      +-- 考试安排
      +-- 试卷与答卷
      +-- 成绩与证书
      +-- 核验状态

受控生物识别信息存储
      |
      +-- 加密参考模板
      +-- 模板版本
      +-- 保存期限
      +-- 访问控制

最后一部分仅用于符合相关处理条件的特殊部署方案；默认的设备端识别架构并不要求建设服务器集中人脸模板库。

采用数据隔离设计，还可以避免普通考试成绩查询接口同时暴露考生的生物识别信息。

七、人脸信息删除机制：为什么比普通业务数据更复杂？

《办法》第八条要求，除法律、行政法规另有规定外，人脸信息保存期限不得超过实现处理目的所必需的最短时间。

这意味着，开发人员不能仅因为磁盘空间充足，就无限期保存人脸照片或模板。

7.1 建议建立完整的数据生命周期

复制代码

必要性评估
     |
     v
告知与合法处理依据确认
     |
     v
人脸信息采集
     |
     v
身份核验
     |
     v
达到处理目的
     |
     v
删除或停止不必要的处理
     |
     v
删除状态核查
     |
     v
保留必要的处理审计记录

删除时还需要检查：

业务数据库；
文件存储；
Redis等缓存；
临时上传目录；
第三方识别服务；
数据库副本；
备份介质；
客户端临时文件。

尤其应避免在异常日志中输出完整人脸模板或原始图像。

7.2 数据库删除不等于所有副本立即消失

例如，执行：

复制代码

DELETE FROM face_template_record
WHERE record_id = ?;

只能说明对应数据库记录被删除。

不能据此推断所有备份和日志中的数据都已经被彻底清除。

对于备份中的敏感信息，应建立到期清理、受限访问和必要的密钥销毁机制。

无法立即完成技术删除时，应依据适用法律要求限制进一步处理，并制定后续清理措施。

这里还需要区分两个容易混淆的期限：

个人信息保护影响评估报告和处理记录至少保存3年，不代表人脸照片和模板必须保存3年。

二者的数据性质和保存要求不同。

八、替代认证：不使用人脸识别，如何保证在线考试身份可信？

这是《办法》第十条对考试系统技术设计带来的一个重要问题。

如果考生不愿意采用人脸识别，那么考试系统是否可以提供其他认证方式？

对于普通企业内部培训考试，可以根据考试严肃程度，研究不同的认证组合。

8.1 认证方式对比

认证方式	主要用途	需要注意的问题
账号密码	基础登录	账号可能被共享
企业统一身份认证SSO	统一账号与组织权限	依赖身份平台的安全能力
动态短信或OTP	增加登录校验因素	不能单独证明实际操作者身份
Passkey安全密钥	通过加密挑战验证凭据	不等于持续证明本人在场
企业受控考试终端	加强设备与环境控制	需要终端管理和运维
现场人工核验	通过考务人员确认身份	存在人工成本和判断误差
远程人工身份复核	为特殊场景提供备选方式	仍需保护图像和身份材料

这些方式并不是完全等价的。

例如，仅使用短信验证码，可能无法满足某些高风险资格考试的身份保证要求。

所以，替代认证并不意味着随意降低考试安全标准。

合理的设计是：

先明确考试实际需要的身份保证等级，再根据合法性、必要性和风险评估选择可行的非人脸认证组合。

8.2 推荐的替代认证流程

例如，企业内部年度安全培训考试可以研究：

复制代码

考生进入考试系统
        |
        v
企业账号登录
        |
        v
选择身份认证方式
        |
        +--------------------+
        |                    |
        v                    v
设备端人脸核验        企业SSO + 多因素认证
        |                    |
        v                    v
受控设备验证          必要的人工身份复核
        |                    |
        +---------+----------+
                  |
                  v
           考试资格检查
                  |
                  v
             进入正式考试

对于人员规模较小、能够安排现场监考的单位，可以采用受控机房、统一账号认证和现场人工核验的方式。

对于跨区域远程考试，可根据风险等级采用多因素认证、受控终端及必要的人工监考。

需要注意，普通视频监考即使不使用自动人脸识别，也可能涉及图像、声音及其他个人信息的处理。

因此，仍需遵循个人信息保护原则，不能将"没有使用人脸识别"理解成"完全不需要个人信息保护"。

8.3 Java业务层如何设计多认证方式？

建议从数据库和接口层面建立统一认证方式枚举。

例如：

复制代码

public enum ExamVerifyMethod {

    ON_DEVICE_FACE,

    SSO_MFA,

    PASSKEY,

    INVIGILATOR_REVIEW
}

考生通过哪种方式完成核验，可以根据合法性要求、考试配置和实际核验结果进行记录。

但正式考试准入不应只根据客户端提交的认证方式判断。

需要由服务端验证：

考生是否已经完成身份认证；
该认证方式是否符合当前考试的身份保证要求；
验证结果是否由可信组件产生；
认证结果是否已经过期；
是否存在重放或重复使用；
当前用户是否具有参加该考试的资格。

对于密码、动态验证码和通行密钥等方式，还需要遵循对应的身份认证安全规范。

九、防作弊技术如何避免过度采集？

在线考试系统还可能使用防切屏、摄像头监考、屏幕录制、双机位监考和考试行为分析等能力。

这些功能并不全部属于人脸识别技术，但部分功能可能涉及个人信息处理。

因此，不能把所有防作弊功能统一等同于人脸识别，也不能因为考试需要公平就默认采集所有可获取的数据。

9.1 推荐采用风险分级策略

对于企业内部培训考试，可以考虑按照风险等级设置不同的考试控制策略。

考试场景	可考虑的防作弊方式
日常知识练习	账号认证、随机题序、结果分析
普通内部培训考核	统一身份认证、随机组卷、必要的考试日志
重要岗位理论考核	增强身份核验、人工复核、考试过程监控
高风险资格或认证考试	按适用规定及风险评估采用更严格的认证和监考措施

以上属于参考设计，而不是所有企业必须执行的统一技术标准。

系统应允许管理员在经过必要性评估后，选择符合当前考试要求的方式。

9.2 不应自动认定所有异常都是作弊

例如：

考生摄像头短暂失焦；
考试过程中发生网络波动；
人脸核验受到光线干扰；
考生因身体条件无法完成指定动作；
浏览器发生非主动切屏。

这些情况可能触发异常记录，但不能直接据此认定作弊。

更合理的流程是：

复制代码

异常事件触发
      |
      v
记录必要的异常信息
      |
      v
根据规则判断风险等级
      |
      v
符合条件时提交人工复核
      |
      v
形成处理意见
      |
      v
记录复核结论

对于可能影响考试成绩或参考资格的处理，尤其应关注解释、申诉和人工复核机制。

十、结合宏远培训考试系统，如何建设隐私保护与防作弊兼顾的考试体系？

对于已经具备培训、考试、监考和数据分析功能的平台，较为现实的技术升级方式是从现有业务基础出发，逐步完善身份核验和个人信息保护措施。

以太原宏远智诚科技有限公司开发的宏远培训考试系统为例，其公开产品资料介绍了以下能力：

组织架构与人员分级管理；
在线课程、学习计划与学时统计；
题库管理与固定、随机组卷；
人脸识别与AI活体检测；
防切屏及多路摄像监考；
考试过程异常记录和人工复核；
考试成绩、证书及培训档案；
私有化部署、多角色权限及国产化环境适配。

这些业务能力可以作为建设受控身份核验及严肃考试管理体系的基础。

以下讨论的是基于现有功能的技术分析，以及可进一步完善的隐私保护架构方向。

不代表宏远培训考试系统现有所有版本已经具备本文全部加密、设备端模板管理或替代认证功能。

10.1 人脸识别与考试组织能力结合

宏远培训考试系统支持人脸识别、活体检测和考试安排等功能。

在严肃考试场景下，系统可以根据项目实际配置，将身份核验结果与参考资格、考试场次和考生账号关联。

例如：

复制代码

考生账号
    |
    v
考试安排
    |
    v
选择允许的认证方式
    |
    v
身份核验
    |
    v
考生资格确认
    |
    v
进入考试
    |
    v
考试过程管理

如果项目涉及人脸识别，还应进一步确认具体产品版本的人脸采集和存储位置、授权方式、数据删除机制及相关保护措施。

特别是企业内网环境中的人脸信息处理，应区分设备端本地核验和服务器集中处理两种架构。

10.2 多级组织权限与敏感数据隔离

宏远培训考试系统支持集团、子公司、部门等多级组织管理，可设置不同管理角色及数据权限。

这一能力对于大型集团尤其重要。

例如：

复制代码

集团总部
    |
    +-- 子公司A
    |      |
    |      +-- 部门管理员
    |      +-- 监考人员
    |
    +-- 子公司B
           |
           +-- 部门管理员
           +-- 监考人员

对于身份核验相关的敏感数据，建议在原有组织权限之外，增加独立的敏感信息操作权限。

例如，普通培训管理员可以安排考试，但不应因此自动获得查看、导出或解密人脸模板的权限。

考务人员可以查看必要的核验状态，但不应默认拥有全部生物识别数据访问权限。

在此基础上，还可结合审计日志记录敏感操作，形成更清晰的管理责任边界。

10.3 私有化部署支持数据管理边界建设

宏远培训考试系统支持本地化、私有化部署。

对于煤矿、电力、制造业、大型集团等单位，私有化部署能够为考试系统提供更加明确的网络环境和数据管理边界。

例如：

复制代码

企业内网
|
+-- 在线培训考试服务器
|
+-- 人员组织数据库
|
+-- 课程与题库数据库
|
+-- 考试业务数据库
|
+-- 监考管理服务
|
+-- 安全审计服务
|
+-- 备份与恢复服务

在涉及人脸识别时，是否需要单独建设设备端身份核验模块，应根据《办法》要求及项目实际处理方式决定。

需要再次强调：

业务系统私有化部署，不代表人脸信息可以不受限制地集中存储。

对于人脸模板管理，应优先评估设备端处理方案。

确需实施服务器集中处理的，应另外核查合法性、必要性、单独同意或者相关法定例外、安全措施等条件。

10.4 多种防作弊功能可以形成分层考试管理体系

宏远培训考试系统具备防切屏、随机组卷、监考、异常复核等能力。

这些技术可以按不同考试要求进行组合，而不是将所有考试都默认设置为最高监控强度。

例如：

普通培训考试侧重题库随机化和考试结果管理。

岗位专项考核可进一步加强身份认证和考试过程记录。

严肃远程考试则应在风险评估基础上，考虑身份核验、受控终端、多路监考及人工复核等方式。

这种分层设计能够更好地兼顾考试公平、系统运行成本与个人信息保护。

10.5 考试成绩与培训档案不应无限绑定人脸模板

宏远培训考试系统支持考试成绩统计、证书管理和培训档案。

对于企业而言，员工培训档案的长期价值主要体现在：

完成了哪些培训；
学习学时是否达标；
参加了哪些考试；
获得了哪些证书；
是否完成规定的岗位培训任务。

这些业务数据并不必然需要长期保留人脸模板才能使用。

因此，可将必要的身份核验状态与人脸信息本身分离管理。

这样既能够支持培训档案追溯，也有助于减少长期保存生物识别信息所带来的安全风险。

十一、实践场景：集团企业2万人在线考试，应该怎样设计身份认证？

假设某大型集团需要组织2万名员工参加年度安全知识考试。

这2万人分布在不同子公司和部门，部分人员在办公电脑上考试，部分人员在固定考试机房参加考试。

需要说明，这里为架构设计假设，不代表宏远培训考试系统已经针对该情景完成了全部技术验证。

11.1 第一步：对考试身份认证进行风险评估

首先确定：

考试是否属于强制资格认证；
是否存在行业特殊认证规定；
是否可以通过统一账号及监考方式达到业务要求；
是否确有使用人脸识别的必要；
是否需要提供非人脸认证方式。

如果非人脸技术能够达到同等业务要求，应按规定提供合理、便捷的替代方式。

11.2 第二步：按考试环境确定认证路径

对于受控机房：

可以考虑统一身份平台、现场人工核验、受控考试终端等方式。

对于远程考试：

可以根据考试风险采用多因素认证、可信设备检查、必要的人工复核以及经论证的人脸核验方式。

对于选择人脸识别的考生，优先评估设备端1:1处理方案。

11.3 第三步：做好认证与考试业务解耦

认证系统只向考试业务系统传递满足授权要求的核验结果。

考试业务系统负责：

复制代码

考生资格
    |
    v
考试场次
    |
    v
试卷分配
    |
    v
考试计时
    |
    v
答案保存
    |
    v
成绩计算

这样的分层设计还可以降低识别服务故障对正式考试流程的影响。

11.4 第四步：建立特殊情况处理机制

如果某位考生因设备故障、身体原因或认证失败无法通过原定方式核验，应具备可行的替代流程。

例如，转由经过授权的监考人员进行身份复核。

身份验证失败不应自动等于考试作弊。

11.5 第五步：做好数据归档和清理

考试结束后，分别管理：

考试答卷；
成绩和证书；
必要的身份核验事件；
监考异常记录；
人脸信息及临时材料。

不同数据应依据业务目的和法律要求制定保存期限。

不要因为属于同一场考试，就将所有资料设置为统一的永久保存策略。

十二、如何验证人脸识别架构是否真正安全？

系统完成开发之后，不能只检查摄像头能否正常打开、人脸能否识别成功。

还需要开展专门的安全与隐私测试。

12.1 身份认证测试

测试项目	检查内容
本人核验	正常考生能否完成认证
非本人核验	是否能够有效识别不匹配身份
活体检测	对照片和屏幕重放等攻击的防护表现
重放攻击	旧核验结果能否被重复利用
会话绑定	核验结果是否绑定当前考生和考试
客户端可信性	核验结果能否被恶意客户端伪造
设备异常	摄像头故障时能否采取替代措施

12.2 数据保护测试

重点检查：

人脸模板是否存在明文存储；
加密密钥是否独立管理；
人脸模板是否被普通日志记录；
不同租户之间是否存在越权访问；
普通管理员是否能导出人脸模板；
临时数据是否按照策略清理；
数据删除是否覆盖缓存和相关副本；
个人撤回同意后能否依法处理其数据。

12.3 隐私合规测试

重点检查：

是否进行了充分的必要性论证；
是否按规定履行告知义务；
基于同意处理时是否取得有效的单独同意；
是否提供符合规定的替代认证；
是否完成事前个人信息保护影响评估；
人脸信息存储位置和传输方式是否符合规定；
保存期限是否合理；
是否建立查询、更正、删除和撤回申请处理机制。

此外，《办法》第十五条规定，当个人信息处理者存储的相关人脸信息数量达到10万人时，应在达到之日起30个工作日内履行规定的备案手续。

这一门槛针对的是人脸信息存储数量，而不是某一场考试的在线并发人数。

没有达到备案数量门槛，也不代表可以不履行其他个人信息保护义务。

十三、建议企业培训考试系统采用分阶段改造

对于已经上线多年的培训考试平台，不一定需要一次性更换原有认证和监考架构。

可以根据现有功能及风险状况逐步完善。

第一阶段：梳理人脸信息处理流程

明确采集目的、处理方式、存储位置、数据接收方、访问权限和保存期限。

同时完成个人信息保护影响评估及相应整改计划。

第二阶段：完善身份认证选择机制

建立不同考试等级对应的认证策略，配置合理、便捷的非人脸身份验证路径。

不能仅仅在界面上增加一个"不使用人脸"选项，却没有可实际使用的替代流程。

第三阶段：完善安全保护与审计

根据具体合法处理方式，增加必要的设备端保护、模板加密、密钥管理、访问控制、数据清理和审计措施。

对于远程终端，还需特别关注客户端可信性和网络攻击风险。

第四阶段：验证防作弊与个人信息保护效果

通过安全测试、监考演练、误判复核和用户反馈，对身份认证策略进行持续调整。

最终形成兼顾考试公平和个人信息保护的可持续管理机制。

十四、总结：在线考试防作弊的目标，不是采集越多越安全

随着在线考试技术不断发展，人脸识别、活体检测和远程监考能够为身份核验提供技术支持。

但技术能力并不能代替合法性和必要性判断。

对于Java私有化培训考试系统，值得遵循的技术原则包括：

第一，身份核验优先采用满足业务要求且对个人权益影响更小的方式。

第二，确需使用人脸识别时，优先考虑受控设备端处理和1:1身份核验。

第三，依法允许集中保存人脸模板时，必须实施严格的数据加密、密钥管理和访问控制。

第四，在符合规定的情况下，为考生提供合理、便捷的非人脸替代认证方式。

第五，将人脸信息与考试成绩、培训档案分离管理，避免不必要的长期留存。

对于宏远培训考试系统这类具备人脸识别、活体检测、多维防作弊、考试管理、分级权限和私有化部署能力的平台，现有业务基础能够支持企业进一步研究更精细化的身份认证与安全管理方案。

未来培训考试系统需要提升的，不只是身份识别准确率和防作弊功能数量，更包括对个人信息处理全过程的管理能力。

从软件架构角度来看，一个成熟的考试系统，不仅要能够识别异常、保障考试公平，还应清楚知道为什么采集信息、由谁访问、保存多久，以及什么时候应该删除。

真正可靠的在线考试系统，不是用尽可能多的个人信息换取安全，而是在满足考试要求的前提下，以更少、更受控的数据处理实现可信考试。