“人脸识别门禁带国密”这句话我在很多招标文件里见过。但真正把项目拿到手你会发现甲方、集成商、硬件厂商和密评机构四方对这句话的理解根本不在一个频道上。有的甲方只是想要“安全一点”有的则是被上级单位点名要做商用密码应用安全性评估还有的纯粹是看别人都上了自己不跟不行。人脸识别门禁只是表象藏在背后的核心诉求其实是一整套关于合规责任、密码算法、终端能力和数据生命周期的复杂问题。这篇文章不聊空洞的政策解读只从实际落地角度拆解这类项目到底在问什么、国密算法和人脸识别是怎么协同工作的、终端选型时哪些参数最容易被忽略、以及从招标到验收要经历哪些真实关卡。内容主要面向系统集成商的项目经理、安防行业的售前工程师以及负责园区或办公大楼信息化建设的甲方。1. “要用国密门禁”这句话背后甲方到底在问什么先说个我真实的经历。去年有个做园区安防改造的客户找到我们时需求只有一句话把所有门禁换成“国密人脸识别门禁”。我问他为什么要做国密他说不清楚只知道集团总部发了文件要求重要区域的门禁系统采用国密算法。再往下问“重要区域指哪些”“有没有密评要求”“原来的门禁系统能不能保留”他就答不上来了。这类情况其实非常普遍。国密门禁项目表面是技术升级实质是合规驱动的采购行为。真正需要搞清楚的不是“人脸识别门禁”本身的考勤、开门功能而是三个更深层的问题。1.1 合规责任如何划分甲方在问“我要不要做国密”本质上是在问“如果我不做出了事谁负责”。做信息安全的都清楚商用密码应用安全性评估密评对于政务系统、关基设施和能源、金融等重点行业已经逐步变成强制要求。门禁系统作为物理安防的一部分同时也关联着人员身份信息属于被密评覆盖的典型场景。而人脸数据依据个人信息保护法的定义属于生物识别信息是敏感个人信息需要采取加密措施。所以这个项目的第一问其实是合规责任归属问题。如果不做改造等保测评、密评、数据安全审计三个口子都会提出整改意见。做了之后虽然会增加预算和工期但能把合规责任向安全产品和系统承接方转移一部分。1.2 传统的“密码门禁”到底怎么变成“国密”门禁系统里原有的“密码”概念大多是刷卡、密码口令而国密算法是指SM2、SM3、SM4这一套公开的国产密码算法。SM2是非对称算法主要用于数字签名和密钥协商可以对应身份认证这一环节SM3是杂凑算法类似摘要指纹用于防止人脸特征数据被篡改SM4是对称加密算法用于通道加密和数据落盘加密。把这三样塞进门禁系统不是买一台“国密门禁机”那么简单它牵扯到前端终端、网络传输、后台平台、证书体系四个层面的整体适配。1.3 门禁厂商的“支持国密”是否可信甲方容易陷入的第二个误区是过分相信产品宣传页上印的“支持国密算法”。据我接触的终端厂商来看一些人脸识别门禁机所谓“国密”只是在读卡模块上加了SM1/SM7的CPU卡读头而人脸采集、比对、传输环节仍然是明文或者普通加密。严格来说这样只能叫“国密刷卡门禁”完全不满足“国密人脸识别门禁”的完整定义。所以甲方真正在问的其实是“我该怎么分辨哪些产品真正做到了全链路国密而不是只挂了一个名头”。2. 合规边界在哪等保密评与个保法的双重约束搞清楚甲方在问什么后就要理解合规框架对项目的具体限制范围。因为合规要求不是一道门槛而是很多道交错的线画得不准后面做到一半容易推倒重来。2.1 密评的覆盖范围不只是门禁主机密评的核心对象是“采用商用密码技术、产品和服务集成建设并运行的网络和信息系统”。门禁系统如果联网运行比如有人脸比对服务器、有云端管理平台、有手机App远程开门那么整个系统都在密评范围内。如果门禁是纯离线的单机设备只靠本地有人脸库做比对那它的角色更接近一个嵌入式产品有些环节的密评要求会有所不同。实操中的关键判断点是“系统”和“设备”的区分。很多甲方觉得我买的是一台台“国密门禁终端”这属于采购国密设备不是建设国密系统。但对集成商来说你只要把终端连接到管理平台做了远程授权、数据下发、日志回传就已经构建了一个商用密码应用系统需要按照GB/T 39786的要求来设计密码应用方案。2.2 等保、密评、个保法三者的侧重点很多人把等保和密评混在一起其实侧重点完全不同。等保2.0更多关注的是信息系统的安全保护能力从物理安全、网络安全、主机安全、应用安全、数据安全几个维度做等级保护测评。它关心的是门禁平台有没有访问控制、有没有审计日志、有没有入侵防范。密评则专门盯着密码应用的合规性重点看密码算法、密码协议、密钥管理、密码产品是否满足要求。比如系统里用了AES还是SM4TLS用的是国密套件还是普通套件人脸模板存储时有没有做加密密钥多久轮换一次用的密码机、密码模块有没有商密型号。至于个保法它管的是“人脸这种敏感个人信息”的收集和处理。做到最小必要、单独同意、安全存储、可删除可撤回就是合规。三者各查各的一个门禁项目可能要同时应付三拨测评人员。2.3 人脸识别算法本身也有“合规牌”要打还有一个容易遗漏的点是人脸识别算法是否做过算法备案或评估。根据相关规定提供具有舆论属性或社会动员能力的算法推荐服务需要向网信部门做算法备案。人脸识别门禁这种面向社会提供服务的场景如果甲方是银行网点、政务大厅、机场火车站等场景特别注意要在终端备案这一层有所准备。门的开关事小人脸数据被不当处理才致命。2.4 判断项目是否需要密评的几个信号我总结了几条实操判断标准帮助快速确认一个门禁项目是不是必须走密评路径避免做无用功或者漏做关键一步。判断信号说明甲方是否属于政务、金融、能源、交通等关键行业属于则密评概率极高直接按国密系统设计项目是否新建或改建后接入甲方已有网络系统接入系统则属于密码应用系统密评适用是否涉及大量人员的人脸采集、存储和跨平台共享涉及则个保法与数据安全要求叠加生效招标文件里是否明确写了“需要配合密评/密码应用方案”有写则预留商密产品证书、密评整改预算与工期是否想保留旧的非国密门禁设备保留设备需要双轨运行方案新旧设备混接较复杂这组信号基本能帮你在售前阶段判个大概省得签完合同再发现漏了密评整改那时成本已经翻倍了。3. 人脸数据和国密算法是怎么在一个门禁系统里跑起来的很多集成商朋友对人脸门禁的理解停留在“终端采集照片后台比对返回开门信号”。这个思路放在普通门禁上没问题但一旦接了国密要求整条数据链路都得重新设计。我尽量用通俗的语言拆一遍这中间的密码学逻辑。3.1 一个典型的国密人脸门禁系统架构先描述一个我经手的真实项目的架构供参考。前端是人脸识别门禁一体机通常有一块带NPU运算能力的SoC一个可见光摄像头、一个红外摄像头用于活体检测还有一个触摸屏和出门按钮接口。终端内置一个安全芯片用于存放密钥和做SM2/SM4运算。终端通过网线与后台的门禁管理平台通信后台部署在甲方机房里可能有独立的数据库服务器和管理终端。远程办公室如果需要远程开门可能会有App或微信小程序。这条链路里国密算法出现在五个关键位置终端采集人脸照片时、终端与门禁管理平台通信时、平台对人脸模板存储时、关键操作日志签名时以及如果涉及远程App开门App与服务器的双向认证时。3.2 人脸照片从采集到比对的全加密第一步是采集与活体检测。终端通过可见光摄像头采集人脸图像红外摄像头做活体判断防止照片、视频、头模的假体攻击。这一步产生的原始人脸照片在内存中就已经需要做敏感数据识别和处理不能明文落盘。第二步是特征提取。比较成熟的做法是在终端本地用算法模型把原始图片转成特征向量特征向量比如256位或者512位浮点数。这一步的关键是“原始图片不留存”终端只保留特征码。有些终端也支持把原始图加密后上传到平台留存但这会大幅增加合规解释成本我们不推荐。第三步是比对。比对的逻辑有两种一种是终端本地比对人脸库提前下发到终端适合离线场景或区域节点少的情况另一种是后端比对终端把加密的特征码通过国密TLS通道传到管理平台平台在加密数据库里检索比对。前者速度快但终端管理复杂后者中心化管控更严但依赖网络质量。第四步是传输与存储。假设你选的是后端比对终端需要和人脸库服务器建立双向认证的通信。这里的关键是密码套件国密TLS 1.3使用的密钥交换可以基于SM2消息认证可以使用SM3数据加密则是SM4。如果工程团队没有密评经验很容易在OpenSSL里仍然用ECDHE_RSA_AES256_GCM这类国际套件虽然也能跑通但对密评来说是不合格的。第五步是密钥管理。SM2密钥对的生成、存储、轮换、销毁不能随意写在代码里。一般会用密码机或密码卡统一管理。项目里我们遇到过甲方预算有限最后用软件密码模块包装了一下凑合能做演示但密评专家只要看一眼密钥管理方案和进程内存存储痕迹问题就会暴露。3.3 终端本地离线库与边缘计算的博弈有一种情况最容易引发争议园区网络不稳定甲方要求“断网也能刷脸开门”。这就意味着人脸特征库必须下发到终端本地终端离线也能比对。此处的合规难点是人脸特征库从平台下发到终端时本身是一批敏感个人信息在“移动”。下发通道需要做加密和完整性保护终端存储时特征库不能明文放在Flash里至少要用SM4加密后存储并且要做防调试和防越狱处理防止有人把终端拆下来直接从存储芯片里提取人脸特征库。从工程选型角度看如果终端算力有限只能做11比对那就需要预先绑定权限适合固定人员的办公室场景。如果要做1N检索比如1000人以上的库终端需要至少2TOPS以上的算力否则比对延迟会飙到一两秒实际体验很糟糕。3.4 为什么要“双算法并行”而不是一步到位纯国密我在多个项目里被问到既然要做国密为什么不能把国际算法全部去掉直接用SM系列算法就好现实是很多现有的门禁平台、考勤系统、手机App底层依赖的密码库并不完全支持国密套件全面替换的改造成本极高。而且在等保和密评的实际整改过程中也允许“双算法运行”也就是关键敏感数据用国密保护存量系统用国际算法兼容逐步向国密切换。双算法并行的典型做法是新旧终端并行上线新终端用国密通道入网旧终端在升级固件前维持原链路。平台端同时监听两套协议数据库里同一张人脸表同时存SM4加密字段和旧算法加密字段。等旧终端全部淘汰后再彻底关闭国际算法通道。这么做的风险点是两套密钥体系和两套加密逻辑并存如果数据库字段设计不合理改起来是牵一发动全身所以表结构设计一开始就要预留密文字段和算法标识位。4. 终端选型清单从摄像头到安全芯片每个参数都有讲究终端在国密人脸门禁项目里是最容易“图省事”的地方。很多人觉得采购一批有名气的门禁机配一台服务器平台装好就行。但终端作为人脸数据的第一站它决定了整个系统的安全底线。以下是我的完整选型维度挨个说清楚。4.1 人脸感知模块不是像素越高越好很多人挑选人脸识别门禁机时只关注摄像头像素动辄要求800万、1200万这是很典型的误区。人脸识别门禁机的核心在“在逆光、暗光、戴眼镜、戴口罩等复杂条件下能不能稳定检出人脸”而不只是分辨率高。推荐看这四个指标动态范围HDR、宽动态WDR、红外补光能力和活体检测方式。室内项目标配的双目方案基本够用但在半户外场景比如园区门口、食堂入口、地下车库门厅光照变化很大必须具备宽动态能力和补光灯。实测经验是在逆光环境下好一点的传感器和处理算法能保证99%的检出率差的机型人脸区域黑成一片没法用。选型时最好直接拿测试机踢到甲方现场早晚各跑一轮实测比看彩页管用得多。处理器算力方面参考公式是“人脸库规模×单次比对时间”。500人以内的库很多终端配0.5TOPS到1TOPS的NPU就够用超过2000人的库建议至少选2TOPS以上的方案。同时要看终端厂家对外提供的SDK是否支持自定义人脸库预热和增量下发这两个功能在批量化部署时非常重要。4.2 国密能力安全芯片和证书体系缺一不可终端要称得上“国密门禁机”必须具备以下几个能力。第一内置通过商密认证的安全芯片。以我接触过的几个方案来看常见的安全芯片型号有国芯、华大、国民技术这几家的产品基本都支持SM2/SM3/SM4硬件运算。安全芯片的作用是存储设备私钥保证私钥不可导出签名和加解密运算在芯片内部完成防止被逻辑探针或调试接口拖出密钥。第二要支持国密证书。终端启动后会向平台的证书服务发起认证请求下载或刷新设备证书并完成双向身份认证。很多朋友看到“CFCA国密证书下载”这个词会觉得陌生CFCA即中国金融认证中心是常见的CA机构企业也可以自建CA给终端签发国密证书。重点在于终端的证书管理流程证书过期、吊销、更新的处理逻辑是否完整不然大规模部署后证书管理会变成灾难。第三终端要能支持SM2签名验签。不只是和平台的通信要签名敏感操作日志、开机完整性校验、固件升级包的签名校验都应该走这一套。如果是单机门禁不带平台那至少要求终端具备数据加密存储和完整性的校验能力。人脸模板加密存储是必须项防拆报警和固件防回滚也不能少。4.3 协议开放程度决定了项目要流多少汗选终端时经常被忽略的是协议开放度。人脸门禁终端一般有主流的OpenAPI或者行业标准接口比如GB/T 28181、ONVIF或者厂家私有协议。做国密项目平台对接是最耗时的一环因此要重点关注以下几点。第一设备SDK是否支持国密套件的TLS接入。很多厂家的SDK默认走HTTPS或者私有TCP伪装成国密支持但细看SDK文档才发现不支持自定义密码套件。第二设备的“远程开门”“远程升级”“参数下发”三个动作是否也走加密通道。有的终端只把“人脸比对请求”做了加密管理通道却是明文的照样不合格。第三事件日志是否带签名。密评审查时会重点看“日志的完整性保护”如果开门记录只是普通的数据库记录攻击者可以轻易删改日志这是非常严重的密评失分项。第四是否支持对接国密门禁管理平台的密钥灌装接口。有些甲方要求平台统一管密钥不允许每台终端出厂用相同的默认密钥。终端的密钥灌装流程若不支持就只能一台台用U盘导入非常痛苦。4.4 外壳与防护等级、安装方式等容易被低估的细节室内门禁和半户外门禁对防护等级的要求差很多。纯室内场景IP42基本够用但如果是园区岗亭、室外围墙门就需要IP65以上的防尘防水等级工作温度也要满足零下20℃到60℃。北方冬天的低温环境下很多廉价终端的屏会“冻住”出现触控失灵或图像残影。安装方式上是壁挂、立式还是闸机一体闸机一体的门禁终端往往要求更小的体积和不同的开孔尺寸选型时要提前和闸机厂家对齐。这些细节不影响国密合规但直接影响交付后的使用体验和售后频率。4.5 一台合格国密人脸门禁终端的核心清单我把上面的选型维度归纳成一张表格便于采购和验收时逐项打钩。选型维度必须满足项加分项摄像头与人脸模块双目/红外活体、宽动态、适应逆光支持口罩识别、自定义识别阈值可调算力支持本项目人像库规模比对不卡顿具备本地1N检索与离线更新能力国密安全芯片内置商密认证安全芯片SM2/SM3/SM4硬件运算芯片私钥支持应用隔离与签名防伪密码套件支持国密TLS套件可与平台双向认证支持国际算法兼容模式便于新旧过渡存储保护人脸模板SM4加密存储防调试接口拆除外壳自动锁定或擦除密钥协议与二次开发提供OpenAPI/SDK支持日志签名、远程升级支持GB/T 28181、支持批量灌装密钥结构与防护满足室内/半户外的IP等级和工作温度闸机一体安装兼容、支持POE供电证书管理支持国密证书签发、更新、吊销支持多CA切换、证书备份与恢复5. 从招标到验收国密门禁项目落地的完整路线图前面聊了合规、架构和终端现在说说这类项目真正执行时会经历哪些阶段。很多人以为门禁项目熬过安装调试就算完成了实际上国密项目的重头戏在验收前的“测评整改”阶段。我做了一个简化的阶段说明按时间顺序展开。5.1 售前阶段把“是否要做密评”明确写进合同售前技术交流最重要的一件事是协助甲方判断“这个项目要不要做密评”。如果要做那么项目预算里必须包含密码应用方案设计、密码产品采购、密评机构测评配合、整改复测费用。这些费用不算在门禁设备里经常被忽略。签合同时要注意几个动词的区别。甲方如果写“配合密评”那责任边界比较模糊后期扯皮空间大。更好的表述是“完成系统建设并通过商用密码应用安全性评估测评费用由甲方负责整改费用由乙方负责”。这能有效避免后续因为密评不合格导致的验收纠纷。5.2 设计阶段出密码应用方案比出图纸更重要国密门禁项目在深化设计阶段需要单独输出一份《密码应用方案》这是和传统门禁项目最大的区别。方案至少要覆盖系统架构和密码应用范围使用的密码算法和产品型号包括商密型号证书编号密钥管理体系设计包括密钥生成、分发、存储、更新、销毁的流程身份认证方案包括终端、用户、管理员的认证方式数据传输和存储加密方案日志完整性保护方案。这份方案既是施工依据也是后续密评的审查材料。很多集成商在这阶段图省事随便从网上下载一份模板改了甲方名字导致密评专家一看就问出各种答不上来的问题。我的建议是方案必须结合实际的拓扑图、设备清单、数据库表结构来写宁可慢一点也要把边界画清晰。5.3 实施阶段双算法切换和数据迁移是暗礁实施过程中最容易被轻视的任务是旧门禁系统的人脸数据迁移。旧系统里的人脸特征模板大概率是用旧算法加密的迁移到新国密平台时不能简单地把密文搬过去而是要先解密旧库再用SM4重新加密入库。这个过程中数据在内网服务器上是短暂明文存在的一旦审计日志里出现明文人脸数据处理痕迹密评专家容易质疑数据处理过程的合规性。稳妥的做法是写程序在内存中完成解密再加密不落盘并在操作日志里明确记录迁移任务编号、操作人、操作时间和数据量。另一个方案是直接让用户重新录脸牺牲体验换合规适合人员规模较小的办公场景。切换路径上我建议采用分批上线的策略不要一次性把所有门禁切到新平台。先拿一栋楼或一条通道做试点验证终端离线开门、平台数据同步、远程授权三个核心流程再逐步扩大范围。这个策略听起来保守但实际项目里能挽回不少损失因为平台侧的问题往往在批量接入后才会暴露。5.4 测评阶段密评专家到底在看什么密评审查一般分为两部分文档审查和技术测试。文档方面专家会翻阅密码应用方案、密钥管理制度、设备清单和产品证书。技术测试方面会用专用工具检查通信报文是否加密、是否用了国密套件、密钥是否存在硬编码、数据库加密字段能否直接从存储介质里读出明文、日志能否被篡改。最容易当场翻车的有三类问题一是终端后台默认密码没改专家拿默认密码登录进去发现人脸照片和开门记录一览无余二是平台的密码机接口配置错误虽然代码里写了调用密码机但实际业务数据没走密码机加密只是日志里伪造了调用记录三是证书过期没及时更新终端提示证书无效业务直接降级为明文模式。这三类都是我们见到的真实整改案例。5.5 验收阶段不仅看门能不能开还要看“审计链路”完不完整最终验收时除了常规的功能测试和性能测试还要专门检查审计链路。具体的验收动作包括抓包验证人脸比对请求是否走了国密TLS通道从数据库中复制一份人脸模板密文尝试用已知密钥解密确认密文的可辨识程度修改一条开门记录检查日志签名能否被检测出来模拟断网场景确认终端是否能够降级为离线模式以及离线模式下的人脸比对记录能否在恢复网络后补传至平台。这些动作做完才能说这个项目真正实现了“合规落地”。6. 如果不做国密改造你可能在哪个环节被卡住最后一部分聊聊我踩过的一些坑以及大家常说的“我早做了国密”这句话是怎么被打脸的。这些经验基本不写在厂商说明书上但对后来者非常有参考价值。6.1 只换终端不换平台等于没换有一次项目甲方为了赶工期让我们先把一批老设备换成国密人脸终端平台改造放到二期。结果新终端接入老平台通信协议不兼容新终端的国密能力完全没法启用数据链路仍然是明文等于花高价买了一堆“高级刷卡机”。这种“半国密”状态比不换更危险因为测评人员一眼就能看出系统在合规层面存在明显缺口。如果确实要分步走起码要保证平台侧预留国密模块的接口并且把新终端那部分数据单独加密后接入平台而不是直连老库。这个接口看起来简单但很多老平台根本没有设计扩展位后面只能把整个平台推倒重来。6.2 误以为“支持国密算法”就等于“全链路国密”人脸门禁机的国密能力是全链路概念不是某一个环节用国密就算数。数据传输、存储加密、日志签名、身份认证这四个环节必须全部覆盖。单纯把摄像头采集的照片在SDK里调用国密加密接口但TLS通道走普通HTTPS的场景我在不止一个项目里见到过。密评专家一步抓包就能发现这类漏洞。6.3 人脸特征模板的存储安全比门禁本身更值得较真人脸特征模板一旦被拖库攻击者可以利用模板重建人脸特征甚至还原原始照片的近似信息这是比门禁被绕过严重得多的安全事件。所以数据库里所有人脸特征字段必须使用SM4加密存储而且业务程序不能直接拿密文做字符串比较。很多人踩的坑是在数据库里用了可逆的弱加密函数比如AES_ECB模式或者更夸张的Base64编码后再写个注释“已加密”。SM4的加密模式也建议用CBC或GCM模式带初始化向量和消息认证码确保密文不可重放、不可篡改。数据库字段设计上至少留六个字段算法标识、密钥版本、初始化向量、密文、认证标签、更新时间缺一个后期密评都会有疑问。6.4 证书管理会成为后期最大的运维黑洞国密证书是有有效期的。一台人脸终端的国密证书到期后如果不主动更新终端与平台之间就会变成“验证失败、通道断开”。而很多项目的证书更新流程并没有做到自动化靠人工一年一次地导证书文件终端数量超过一百台后这个工作量就会崩溃。我在一个项目里提前设计了证书自动化更新方案在管理平台里写了一个定时任务提前三十天检查所有终端的证书有效期自动从CA系统申请新证书并灌装到终端。如果没有这个功能光证书更新一件事就能拖垮整个运维团队。6.5 “离线可用”和“全链路审计”如何兼顾前面提到的离线需求是所有国密门禁项目里最难取舍的部分。终端本地保存人脸库离线也能开门这本身体验很好。可一旦脱离平台终端本地的日志、开门记录、事件信息都存在本地如果设备被拆走日志也就没了审计链路出现缺口。可行的做法是给终端增加缓存加密存储区离线期间的日志和记录用SM4加密后存放在本地上线后自动把所有缓存记录加上终端签名一次性补传到平台。即使中间有人把终端偷走本地日志没有密钥也读不出来事后审计还能查出“这台终端在什么时间点丢失了什么数据”。一个更长期的观察在我经手的项目里国密人脸识别门禁的难点从来不在算法本身也不在设备价格而是在于整个团队是否具备“合规项目”的系统性思维。做普通门禁项目只要把人脸识别率调好、门禁联动逻辑调顺就差不多了而做国密门禁项目从售前交流、合同条款、系统设计、产品选型、施工调试到密评验收每一环都是在给同一个问题的答案层层加码——你的系统在密码学意义上到底安不安全。如果让我给正在筹备国密门禁项目的朋友一条最朴素的建议先找一台真正懂密码应用方案的集成商或者自己花时间把GB/T 39786和等保相关要求读一遍再去选终端会让你少走非常多的弯路。项目里的有些费用可以省但在合规这件事上省下来的每一分钱最后都会变成整改时的加班费和密评不通过时的违约金。 
长河君 · 2026/9/15 7:01:35 · 阅读 1.2k 国密人脸识别门禁落地指南：从合规边界到终端选型与密评验收
“人脸识别门禁带国密”这句话我在很多招标文件里见过。但真正把项目拿到手你会发现甲方、集成商、硬件厂商和密评机构四方对这句话的理解根本不在一个频道上。有的甲方只是想要“安全一点”有的则是被上级单位点名要做商用密码应用安全性评估还有的纯粹是看别人都上了自己不跟不行。人脸识别门禁只是表象藏在背后的核心诉求其实是一整套关于合规责任、密码算法、终端能力和数据生命周期的复杂问题。这篇文章不聊空洞的政策解读只从实际落地角度拆解这类项目到底在问什么、国密算法和人脸识别是怎么协同工作的、终端选型时哪些参数最容易被忽略、以及从招标到验收要经历哪些真实关卡。内容主要面向系统集成商的项目经理、安防行业的售前工程师以及负责园区或办公大楼信息化建设的甲方。1. “要用国密门禁”这句话背后甲方到底在问什么先说个我真实的经历。去年有个做园区安防改造的客户找到我们时需求只有一句话把所有门禁换成“国密人脸识别门禁”。我问他为什么要做国密他说不清楚只知道集团总部发了文件要求重要区域的门禁系统采用国密算法。再往下问“重要区域指哪些”“有没有密评要求”“原来的门禁系统能不能保留”他就答不上来了。这类情况其实非常普遍。国密门禁项目表面是技术升级实质是合规驱动的采购行为。真正需要搞清楚的不是“人脸识别门禁”本身的考勤、开门功能而是三个更深层的问题。1.1 合规责任如何划分甲方在问“我要不要做国密”本质上是在问“如果我不做出了事谁负责”。做信息安全的都清楚商用密码应用安全性评估密评对于政务系统、关基设施和能源、金融等重点行业已经逐步变成强制要求。门禁系统作为物理安防的一部分同时也关联着人员身份信息属于被密评覆盖的典型场景。而人脸数据依据个人信息保护法的定义属于生物识别信息是敏感个人信息需要采取加密措施。所以这个项目的第一问其实是合规责任归属问题。如果不做改造等保测评、密评、数据安全审计三个口子都会提出整改意见。做了之后虽然会增加预算和工期但能把合规责任向安全产品和系统承接方转移一部分。1.2 传统的“密码门禁”到底怎么变成“国密”门禁系统里原有的“密码”概念大多是刷卡、密码口令而国密算法是指SM2、SM3、SM4这一套公开的国产密码算法。SM2是非对称算法主要用于数字签名和密钥协商可以对应身份认证这一环节SM3是杂凑算法类似摘要指纹用于防止人脸特征数据被篡改SM4是对称加密算法用于通道加密和数据落盘加密。把这三样塞进门禁系统不是买一台“国密门禁机”那么简单它牵扯到前端终端、网络传输、后台平台、证书体系四个层面的整体适配。1.3 门禁厂商的“支持国密”是否可信甲方容易陷入的第二个误区是过分相信产品宣传页上印的“支持国密算法”。据我接触的终端厂商来看一些人脸识别门禁机所谓“国密”只是在读卡模块上加了SM1/SM7的CPU卡读头而人脸采集、比对、传输环节仍然是明文或者普通加密。严格来说这样只能叫“国密刷卡门禁”完全不满足“国密人脸识别门禁”的完整定义。所以甲方真正在问的其实是“我该怎么分辨哪些产品真正做到了全链路国密而不是只挂了一个名头”。2. 合规边界在哪等保密评与个保法的双重约束搞清楚甲方在问什么后就要理解合规框架对项目的具体限制范围。因为合规要求不是一道门槛而是很多道交错的线画得不准后面做到一半容易推倒重来。2.1 密评的覆盖范围不只是门禁主机密评的核心对象是“采用商用密码技术、产品和服务集成建设并运行的网络和信息系统”。门禁系统如果联网运行比如有人脸比对服务器、有云端管理平台、有手机App远程开门那么整个系统都在密评范围内。如果门禁是纯离线的单机设备只靠本地有人脸库做比对那它的角色更接近一个嵌入式产品有些环节的密评要求会有所不同。实操中的关键判断点是“系统”和“设备”的区分。很多甲方觉得我买的是一台台“国密门禁终端”这属于采购国密设备不是建设国密系统。但对集成商来说你只要把终端连接到管理平台做了远程授权、数据下发、日志回传就已经构建了一个商用密码应用系统需要按照GB/T 39786的要求来设计密码应用方案。2.2 等保、密评、个保法三者的侧重点很多人把等保和密评混在一起其实侧重点完全不同。等保2.0更多关注的是信息系统的安全保护能力从物理安全、网络安全、主机安全、应用安全、数据安全几个维度做等级保护测评。它关心的是门禁平台有没有访问控制、有没有审计日志、有没有入侵防范。密评则专门盯着密码应用的合规性重点看密码算法、密码协议、密钥管理、密码产品是否满足要求。比如系统里用了AES还是SM4TLS用的是国密套件还是普通套件人脸模板存储时有没有做加密密钥多久轮换一次用的密码机、密码模块有没有商密型号。至于个保法它管的是“人脸这种敏感个人信息”的收集和处理。做到最小必要、单独同意、安全存储、可删除可撤回就是合规。三者各查各的一个门禁项目可能要同时应付三拨测评人员。2.3 人脸识别算法本身也有“合规牌”要打还有一个容易遗漏的点是人脸识别算法是否做过算法备案或评估。根据相关规定提供具有舆论属性或社会动员能力的算法推荐服务需要向网信部门做算法备案。人脸识别门禁这种面向社会提供服务的场景如果甲方是银行网点、政务大厅、机场火车站等场景特别注意要在终端备案这一层有所准备。门的开关事小人脸数据被不当处理才致命。2.4 判断项目是否需要密评的几个信号我总结了几条实操判断标准帮助快速确认一个门禁项目是不是必须走密评路径避免做无用功或者漏做关键一步。判断信号说明甲方是否属于政务、金融、能源、交通等关键行业属于则密评概率极高直接按国密系统设计项目是否新建或改建后接入甲方已有网络系统接入系统则属于密码应用系统密评适用是否涉及大量人员的人脸采集、存储和跨平台共享涉及则个保法与数据安全要求叠加生效招标文件里是否明确写了“需要配合密评/密码应用方案”有写则预留商密产品证书、密评整改预算与工期是否想保留旧的非国密门禁设备保留设备需要双轨运行方案新旧设备混接较复杂这组信号基本能帮你在售前阶段判个大概省得签完合同再发现漏了密评整改那时成本已经翻倍了。3. 人脸数据和国密算法是怎么在一个门禁系统里跑起来的很多集成商朋友对人脸门禁的理解停留在“终端采集照片后台比对返回开门信号”。这个思路放在普通门禁上没问题但一旦接了国密要求整条数据链路都得重新设计。我尽量用通俗的语言拆一遍这中间的密码学逻辑。3.1 一个典型的国密人脸门禁系统架构先描述一个我经手的真实项目的架构供参考。前端是人脸识别门禁一体机通常有一块带NPU运算能力的SoC一个可见光摄像头、一个红外摄像头用于活体检测还有一个触摸屏和出门按钮接口。终端内置一个安全芯片用于存放密钥和做SM2/SM4运算。终端通过网线与后台的门禁管理平台通信后台部署在甲方机房里可能有独立的数据库服务器和管理终端。远程办公室如果需要远程开门可能会有App或微信小程序。这条链路里国密算法出现在五个关键位置终端采集人脸照片时、终端与门禁管理平台通信时、平台对人脸模板存储时、关键操作日志签名时以及如果涉及远程App开门App与服务器的双向认证时。3.2 人脸照片从采集到比对的全加密第一步是采集与活体检测。终端通过可见光摄像头采集人脸图像红外摄像头做活体判断防止照片、视频、头模的假体攻击。这一步产生的原始人脸照片在内存中就已经需要做敏感数据识别和处理不能明文落盘。第二步是特征提取。比较成熟的做法是在终端本地用算法模型把原始图片转成特征向量特征向量比如256位或者512位浮点数。这一步的关键是“原始图片不留存”终端只保留特征码。有些终端也支持把原始图加密后上传到平台留存但这会大幅增加合规解释成本我们不推荐。第三步是比对。比对的逻辑有两种一种是终端本地比对人脸库提前下发到终端适合离线场景或区域节点少的情况另一种是后端比对终端把加密的特征码通过国密TLS通道传到管理平台平台在加密数据库里检索比对。前者速度快但终端管理复杂后者中心化管控更严但依赖网络质量。第四步是传输与存储。假设你选的是后端比对终端需要和人脸库服务器建立双向认证的通信。这里的关键是密码套件国密TLS 1.3使用的密钥交换可以基于SM2消息认证可以使用SM3数据加密则是SM4。如果工程团队没有密评经验很容易在OpenSSL里仍然用ECDHE_RSA_AES256_GCM这类国际套件虽然也能跑通但对密评来说是不合格的。第五步是密钥管理。SM2密钥对的生成、存储、轮换、销毁不能随意写在代码里。一般会用密码机或密码卡统一管理。项目里我们遇到过甲方预算有限最后用软件密码模块包装了一下凑合能做演示但密评专家只要看一眼密钥管理方案和进程内存存储痕迹问题就会暴露。3.3 终端本地离线库与边缘计算的博弈有一种情况最容易引发争议园区网络不稳定甲方要求“断网也能刷脸开门”。这就意味着人脸特征库必须下发到终端本地终端离线也能比对。此处的合规难点是人脸特征库从平台下发到终端时本身是一批敏感个人信息在“移动”。下发通道需要做加密和完整性保护终端存储时特征库不能明文放在Flash里至少要用SM4加密后存储并且要做防调试和防越狱处理防止有人把终端拆下来直接从存储芯片里提取人脸特征库。从工程选型角度看如果终端算力有限只能做11比对那就需要预先绑定权限适合固定人员的办公室场景。如果要做1N检索比如1000人以上的库终端需要至少2TOPS以上的算力否则比对延迟会飙到一两秒实际体验很糟糕。3.4 为什么要“双算法并行”而不是一步到位纯国密我在多个项目里被问到既然要做国密为什么不能把国际算法全部去掉直接用SM系列算法就好现实是很多现有的门禁平台、考勤系统、手机App底层依赖的密码库并不完全支持国密套件全面替换的改造成本极高。而且在等保和密评的实际整改过程中也允许“双算法运行”也就是关键敏感数据用国密保护存量系统用国际算法兼容逐步向国密切换。双算法并行的典型做法是新旧终端并行上线新终端用国密通道入网旧终端在升级固件前维持原链路。平台端同时监听两套协议数据库里同一张人脸表同时存SM4加密字段和旧算法加密字段。等旧终端全部淘汰后再彻底关闭国际算法通道。这么做的风险点是两套密钥体系和两套加密逻辑并存如果数据库字段设计不合理改起来是牵一发动全身所以表结构设计一开始就要预留密文字段和算法标识位。4. 终端选型清单从摄像头到安全芯片每个参数都有讲究终端在国密人脸门禁项目里是最容易“图省事”的地方。很多人觉得采购一批有名气的门禁机配一台服务器平台装好就行。但终端作为人脸数据的第一站它决定了整个系统的安全底线。以下是我的完整选型维度挨个说清楚。4.1 人脸感知模块不是像素越高越好很多人挑选人脸识别门禁机时只关注摄像头像素动辄要求800万、1200万这是很典型的误区。人脸识别门禁机的核心在“在逆光、暗光、戴眼镜、戴口罩等复杂条件下能不能稳定检出人脸”而不只是分辨率高。推荐看这四个指标动态范围HDR、宽动态WDR、红外补光能力和活体检测方式。室内项目标配的双目方案基本够用但在半户外场景比如园区门口、食堂入口、地下车库门厅光照变化很大必须具备宽动态能力和补光灯。实测经验是在逆光环境下好一点的传感器和处理算法能保证99%的检出率差的机型人脸区域黑成一片没法用。选型时最好直接拿测试机踢到甲方现场早晚各跑一轮实测比看彩页管用得多。处理器算力方面参考公式是“人脸库规模×单次比对时间”。500人以内的库很多终端配0.5TOPS到1TOPS的NPU就够用超过2000人的库建议至少选2TOPS以上的方案。同时要看终端厂家对外提供的SDK是否支持自定义人脸库预热和增量下发这两个功能在批量化部署时非常重要。4.2 国密能力安全芯片和证书体系缺一不可终端要称得上“国密门禁机”必须具备以下几个能力。第一内置通过商密认证的安全芯片。以我接触过的几个方案来看常见的安全芯片型号有国芯、华大、国民技术这几家的产品基本都支持SM2/SM3/SM4硬件运算。安全芯片的作用是存储设备私钥保证私钥不可导出签名和加解密运算在芯片内部完成防止被逻辑探针或调试接口拖出密钥。第二要支持国密证书。终端启动后会向平台的证书服务发起认证请求下载或刷新设备证书并完成双向身份认证。很多朋友看到“CFCA国密证书下载”这个词会觉得陌生CFCA即中国金融认证中心是常见的CA机构企业也可以自建CA给终端签发国密证书。重点在于终端的证书管理流程证书过期、吊销、更新的处理逻辑是否完整不然大规模部署后证书管理会变成灾难。第三终端要能支持SM2签名验签。不只是和平台的通信要签名敏感操作日志、开机完整性校验、固件升级包的签名校验都应该走这一套。如果是单机门禁不带平台那至少要求终端具备数据加密存储和完整性的校验能力。人脸模板加密存储是必须项防拆报警和固件防回滚也不能少。4.3 协议开放程度决定了项目要流多少汗选终端时经常被忽略的是协议开放度。人脸门禁终端一般有主流的OpenAPI或者行业标准接口比如GB/T 28181、ONVIF或者厂家私有协议。做国密项目平台对接是最耗时的一环因此要重点关注以下几点。第一设备SDK是否支持国密套件的TLS接入。很多厂家的SDK默认走HTTPS或者私有TCP伪装成国密支持但细看SDK文档才发现不支持自定义密码套件。第二设备的“远程开门”“远程升级”“参数下发”三个动作是否也走加密通道。有的终端只把“人脸比对请求”做了加密管理通道却是明文的照样不合格。第三事件日志是否带签名。密评审查时会重点看“日志的完整性保护”如果开门记录只是普通的数据库记录攻击者可以轻易删改日志这是非常严重的密评失分项。第四是否支持对接国密门禁管理平台的密钥灌装接口。有些甲方要求平台统一管密钥不允许每台终端出厂用相同的默认密钥。终端的密钥灌装流程若不支持就只能一台台用U盘导入非常痛苦。4.4 外壳与防护等级、安装方式等容易被低估的细节室内门禁和半户外门禁对防护等级的要求差很多。纯室内场景IP42基本够用但如果是园区岗亭、室外围墙门就需要IP65以上的防尘防水等级工作温度也要满足零下20℃到60℃。北方冬天的低温环境下很多廉价终端的屏会“冻住”出现触控失灵或图像残影。安装方式上是壁挂、立式还是闸机一体闸机一体的门禁终端往往要求更小的体积和不同的开孔尺寸选型时要提前和闸机厂家对齐。这些细节不影响国密合规但直接影响交付后的使用体验和售后频率。4.5 一台合格国密人脸门禁终端的核心清单我把上面的选型维度归纳成一张表格便于采购和验收时逐项打钩。选型维度必须满足项加分项摄像头与人脸模块双目/红外活体、宽动态、适应逆光支持口罩识别、自定义识别阈值可调算力支持本项目人像库规模比对不卡顿具备本地1N检索与离线更新能力国密安全芯片内置商密认证安全芯片SM2/SM3/SM4硬件运算芯片私钥支持应用隔离与签名防伪密码套件支持国密TLS套件可与平台双向认证支持国际算法兼容模式便于新旧过渡存储保护人脸模板SM4加密存储防调试接口拆除外壳自动锁定或擦除密钥协议与二次开发提供OpenAPI/SDK支持日志签名、远程升级支持GB/T 28181、支持批量灌装密钥结构与防护满足室内/半户外的IP等级和工作温度闸机一体安装兼容、支持POE供电证书管理支持国密证书签发、更新、吊销支持多CA切换、证书备份与恢复5. 从招标到验收国密门禁项目落地的完整路线图前面聊了合规、架构和终端现在说说这类项目真正执行时会经历哪些阶段。很多人以为门禁项目熬过安装调试就算完成了实际上国密项目的重头戏在验收前的“测评整改”阶段。我做了一个简化的阶段说明按时间顺序展开。5.1 售前阶段把“是否要做密评”明确写进合同售前技术交流最重要的一件事是协助甲方判断“这个项目要不要做密评”。如果要做那么项目预算里必须包含密码应用方案设计、密码产品采购、密评机构测评配合、整改复测费用。这些费用不算在门禁设备里经常被忽略。签合同时要注意几个动词的区别。甲方如果写“配合密评”那责任边界比较模糊后期扯皮空间大。更好的表述是“完成系统建设并通过商用密码应用安全性评估测评费用由甲方负责整改费用由乙方负责”。这能有效避免后续因为密评不合格导致的验收纠纷。5.2 设计阶段出密码应用方案比出图纸更重要国密门禁项目在深化设计阶段需要单独输出一份《密码应用方案》这是和传统门禁项目最大的区别。方案至少要覆盖系统架构和密码应用范围使用的密码算法和产品型号包括商密型号证书编号密钥管理体系设计包括密钥生成、分发、存储、更新、销毁的流程身份认证方案包括终端、用户、管理员的认证方式数据传输和存储加密方案日志完整性保护方案。这份方案既是施工依据也是后续密评的审查材料。很多集成商在这阶段图省事随便从网上下载一份模板改了甲方名字导致密评专家一看就问出各种答不上来的问题。我的建议是方案必须结合实际的拓扑图、设备清单、数据库表结构来写宁可慢一点也要把边界画清晰。5.3 实施阶段双算法切换和数据迁移是暗礁实施过程中最容易被轻视的任务是旧门禁系统的人脸数据迁移。旧系统里的人脸特征模板大概率是用旧算法加密的迁移到新国密平台时不能简单地把密文搬过去而是要先解密旧库再用SM4重新加密入库。这个过程中数据在内网服务器上是短暂明文存在的一旦审计日志里出现明文人脸数据处理痕迹密评专家容易质疑数据处理过程的合规性。稳妥的做法是写程序在内存中完成解密再加密不落盘并在操作日志里明确记录迁移任务编号、操作人、操作时间和数据量。另一个方案是直接让用户重新录脸牺牲体验换合规适合人员规模较小的办公场景。切换路径上我建议采用分批上线的策略不要一次性把所有门禁切到新平台。先拿一栋楼或一条通道做试点验证终端离线开门、平台数据同步、远程授权三个核心流程再逐步扩大范围。这个策略听起来保守但实际项目里能挽回不少损失因为平台侧的问题往往在批量接入后才会暴露。5.4 测评阶段密评专家到底在看什么密评审查一般分为两部分文档审查和技术测试。文档方面专家会翻阅密码应用方案、密钥管理制度、设备清单和产品证书。技术测试方面会用专用工具检查通信报文是否加密、是否用了国密套件、密钥是否存在硬编码、数据库加密字段能否直接从存储介质里读出明文、日志能否被篡改。最容易当场翻车的有三类问题一是终端后台默认密码没改专家拿默认密码登录进去发现人脸照片和开门记录一览无余二是平台的密码机接口配置错误虽然代码里写了调用密码机但实际业务数据没走密码机加密只是日志里伪造了调用记录三是证书过期没及时更新终端提示证书无效业务直接降级为明文模式。这三类都是我们见到的真实整改案例。5.5 验收阶段不仅看门能不能开还要看“审计链路”完不完整最终验收时除了常规的功能测试和性能测试还要专门检查审计链路。具体的验收动作包括抓包验证人脸比对请求是否走了国密TLS通道从数据库中复制一份人脸模板密文尝试用已知密钥解密确认密文的可辨识程度修改一条开门记录检查日志签名能否被检测出来模拟断网场景确认终端是否能够降级为离线模式以及离线模式下的人脸比对记录能否在恢复网络后补传至平台。这些动作做完才能说这个项目真正实现了“合规落地”。6. 如果不做国密改造你可能在哪个环节被卡住最后一部分聊聊我踩过的一些坑以及大家常说的“我早做了国密”这句话是怎么被打脸的。这些经验基本不写在厂商说明书上但对后来者非常有参考价值。6.1 只换终端不换平台等于没换有一次项目甲方为了赶工期让我们先把一批老设备换成国密人脸终端平台改造放到二期。结果新终端接入老平台通信协议不兼容新终端的国密能力完全没法启用数据链路仍然是明文等于花高价买了一堆“高级刷卡机”。这种“半国密”状态比不换更危险因为测评人员一眼就能看出系统在合规层面存在明显缺口。如果确实要分步走起码要保证平台侧预留国密模块的接口并且把新终端那部分数据单独加密后接入平台而不是直连老库。这个接口看起来简单但很多老平台根本没有设计扩展位后面只能把整个平台推倒重来。6.2 误以为“支持国密算法”就等于“全链路国密”人脸门禁机的国密能力是全链路概念不是某一个环节用国密就算数。数据传输、存储加密、日志签名、身份认证这四个环节必须全部覆盖。单纯把摄像头采集的照片在SDK里调用国密加密接口但TLS通道走普通HTTPS的场景我在不止一个项目里见到过。密评专家一步抓包就能发现这类漏洞。6.3 人脸特征模板的存储安全比门禁本身更值得较真人脸特征模板一旦被拖库攻击者可以利用模板重建人脸特征甚至还原原始照片的近似信息这是比门禁被绕过严重得多的安全事件。所以数据库里所有人脸特征字段必须使用SM4加密存储而且业务程序不能直接拿密文做字符串比较。很多人踩的坑是在数据库里用了可逆的弱加密函数比如AES_ECB模式或者更夸张的Base64编码后再写个注释“已加密”。SM4的加密模式也建议用CBC或GCM模式带初始化向量和消息认证码确保密文不可重放、不可篡改。数据库字段设计上至少留六个字段算法标识、密钥版本、初始化向量、密文、认证标签、更新时间缺一个后期密评都会有疑问。6.4 证书管理会成为后期最大的运维黑洞国密证书是有有效期的。一台人脸终端的国密证书到期后如果不主动更新终端与平台之间就会变成“验证失败、通道断开”。而很多项目的证书更新流程并没有做到自动化靠人工一年一次地导证书文件终端数量超过一百台后这个工作量就会崩溃。我在一个项目里提前设计了证书自动化更新方案在管理平台里写了一个定时任务提前三十天检查所有终端的证书有效期自动从CA系统申请新证书并灌装到终端。如果没有这个功能光证书更新一件事就能拖垮整个运维团队。6.5 “离线可用”和“全链路审计”如何兼顾前面提到的离线需求是所有国密门禁项目里最难取舍的部分。终端本地保存人脸库离线也能开门这本身体验很好。可一旦脱离平台终端本地的日志、开门记录、事件信息都存在本地如果设备被拆走日志也就没了审计链路出现缺口。可行的做法是给终端增加缓存加密存储区离线期间的日志和记录用SM4加密后存放在本地上线后自动把所有缓存记录加上终端签名一次性补传到平台。即使中间有人把终端偷走本地日志没有密钥也读不出来事后审计还能查出“这台终端在什么时间点丢失了什么数据”。一个更长期的观察在我经手的项目里国密人脸识别门禁的难点从来不在算法本身也不在设备价格而是在于整个团队是否具备“合规项目”的系统性思维。做普通门禁项目只要把人脸识别率调好、门禁联动逻辑调顺就差不多了而做国密门禁项目从售前交流、合同条款、系统设计、产品选型、施工调试到密评验收每一环都是在给同一个问题的答案层层加码——你的系统在密码学意义上到底安不安全。如果让我给正在筹备国密门禁项目的朋友一条最朴素的建议先找一台真正懂密码应用方案的集成商或者自己花时间把GB/T 39786和等保相关要求读一遍再去选终端会让你少走非常多的弯路。项目里的有些费用可以省但在合规这件事上省下来的每一分钱最后都会变成整改时的加班费和密评不通过时的违约金。