邮件系统做密码合规改造,密码算法与密码产品的合规性该怎么核验?

1 邮件系统做密码合规改造,密码算法与密码产品的合规性该怎么核验?
三个层次的合规性,不能混为一谈

密码合规常被简化成一句「用国密算法」,这个理解漏掉了大部分内容。完整的判断包含三个递进的层次,任何一层不过关,整体都不成立:

  1. 合规性:使用的算法、产品、服务是否符合国家有关要求。这是准入问题。
  2. 正确性:算法与产品是否被正确地实现和配置。选对了产品但配置错误,等同于没用。
  3. 有效性:在实际运行中是否真正发挥了作用。配置正确但实际链路走了旁路,同样等同于没用。

GB/T 39786-2021 对信息系统的密码应用提出基本要求,其技术部分覆盖物理和环境安全、网络和通信安全、设备和计算安全、应用和数据安全四个层面,并配有管理要求。邮件系统在这四个层面都有落点:机房门禁涉及物理层;SMTP/IMAP 的传输加密涉及网络和通信层;服务器登录与完整性保护涉及设备和计算层;邮件内容的加密与签名、归档数据的保护涉及应用和数据层。

常见的误区是只做了「网络和通信安全」这一层——上了 TLS 就认为完成了密码改造。实际上应用和数据层往往是失分最多的地方,因为它需要改动应用本身,成本更高。

算法合规性:怎么核验

算法层面的核验相对直接,需要回答的问题包括:

  • 用了哪些算法?对称加密、非对称加密、密码杂凑、随机数生成,逐项列出。这份清单必须来自实际测量,而不是产品文档的宣称。
  • 这些算法是否在允许使用的范围内?我国已发布的商用密码算法国家标准包括 GB/T 32918《信息安全技术 SM2椭圆曲线公钥密码算法》、GB/T 32905《信息安全技术 SM3密码杂凑算法》、GB/T 32907《信息安全技术 SM4分组密码算法》等,相应的密码行业标准可在密码行业标准化技术委员会公开的标准列表中查询。
  • 是否仍在使用已被淘汰的算法?已被证明不安全的杂凑算法、短密钥长度的对称算法、SSL 早期版本与 TLS 早期版本,都应当有明确的下线时间表。「为了兼容老客户端」不能成为无限期保留的理由,应当把兼容例外列成清单并逐项设定截止时间。

核验方法上有一条务实建议:不要只看配置文件,要从外部实测。对邮件服务的各个端口(SMTP 提交、SMTP 接收、IMAP、POP3、HTTPS)分别做协议与套件枚举,看服务端实际接受什么。配置文件与实际行为不一致是常态——中间件默认值、编译选项、库版本升级都可能改变实际生效的算法集合。

另外要注意 STARTTLS(RFC 3207)与直接 TLS 两种模式需要分别测试,二者的配置在很多实现中是分开的,只测一种会遗漏问题。RFC 8314 关于提交与访问应使用 TLS 的方向,可作为端口收敛的依据。

产品合规性:证书要看什么

密码法规定,涉及国家安全、国计民生、社会公共利益的商用密码产品,应当依法列入网络关键设备和网络安全专用产品目录,由具备资格的机构检测认证合格后,方可销售或者提供。该法同时规定商用密码产品检测认证适用国家统一的认证制度,鼓励商用密码从业单位自愿接受商用密码检测认证。

核验产品资质时,需要注意几个容易出问题的细节:

  1. 核对证书对应的型号与版本。厂商提供的证书可能对应的是另一个型号或较早的版本,而你实际采购的是新版本。型号与版本对不上的证书,不构成对当前产品的证明。
  2. 核对证书的有效期。过期证书需要厂商提供换证或延续的说明。
  3. 核对产品类别与实际用途是否匹配。不同类别的密码产品适用场景不同,用错类别同样是问题。
  4. 区分「产品有证书」与「系统用对了产品」。这是最关键的一条。买了合规的密码机,但应用调用的却是通用库里的软实现,密码机只是摆在机架上——这在密评中是明确的失分项,而且相当常见。必须能举证:应用的密码运算确实是通过该产品完成的。
  5. 核验证书的真实性。不应只接受厂商提供的复印件,应当通过官方渠道核对。国家密码管理局网站是权威的信息来源。
密钥管理:失分最集中的环节

在实际的密码应用评估中,密钥管理几乎总是问题最多的部分。原因在于算法与产品是「买」来的,而密钥管理是「做」出来的,无法外购。

邮件系统涉及的密钥比想象中多,应当逐一梳理:

  • TLS 服务端证书私钥(SMTP、IMAP、POP3、HTTPS 各自可能不同);
  • DKIM 签名私钥,以及各个选择器对应的密钥;
  • 用户口令的存储形式(杂凑算法、加盐方式、迭代强度);
  • 数据库与存储加密的密钥
  • 备份加密的密钥
  • 系统间集成使用的 API 密钥与令牌
  • 端到端加密体系中的用户密钥与主密钥(若已部署)。

对每一个密钥需要回答完整的生命周期问题:怎么产生(随机源是否合规)、存在哪里(是否明文落盘)、谁能访问、怎么使用、多久轮换、如何备份、如何销毁、泄露后如何应急。

几个典型的失分场景:

  1. 私钥明文躺在配置文件或代码仓库里。这是最常见也最严重的一项。
  2. DKIM 密钥多年未轮换。选择器机制本来就是为平滑轮换设计的,但很多部署自上线起从未换过。
  3. 离职人员的访问权限未清理。密钥的访问清单需要纳入人员离职流程。
  4. 密钥备份与主密钥存在同一处。这使备份失去意义。
  5. 随机数来源不明。密钥生成所依赖的随机源如果不合规,后面所有工作都会被否定。
  6. 没有应急预案。私钥疑似泄露时的处置流程——如何快速轮换、如何评估影响范围、历史数据如何处理——需要事先写好并演练。
推进路径与制度衔接

密码合规改造是一项工程量不小的工作,建议的推进顺序:

  1. 先做现状测绘。实测所有端口的协议与套件,梳理全部密钥清单,标注每一项的现状。这一步的产出是后续所有工作的基线,不能靠问卷和文档代替。
  2. 做差距分析。把现状与 GB/T 39786-2021 的四个技术层面要求逐项对照,标出符合、部分符合、不符合三类。
  3. 按风险与成本排序。优先处理「高风险且低成本」的项——例如禁用弱套件、清理明文私钥、关闭明文端口,这些通常改动小而收益大。
  4. 再处理需要改造应用的项。应用和数据层的密码应用往往需要改代码,周期长,应当尽早启动并纳入版本规划。
  5. 建立持续验证机制。把协议与套件的实测纳入定期巡检,避免升级或变更后悄然退化。密码配置的退化是渐进且无声的,一次组件升级就可能重新启用某个弱套件。
  6. 与其他评估工作衔接。密码法规定,法律、行政法规和国家有关规定要求使用商用密码进行保护的关键信息基础设施,其运营者应当使用商用密码进行保护,并自行或者委托商用密码检测机构开展商用密码应用安全性评估;该评估与关键信息基础设施安全检测评估、网络安全等级测评制度相衔接,避免重复评估、测评。应当主动利用这一衔接,把资产清单、日志体系、文档基线统一起来,避免三套工作产出三份互相矛盾的材料。
  7. 保留过程证据。测绘记录、差距分析、整改前后的对比、产品证书核验记录、密钥管理流程文件与执行记录。评估看的是证据链,不是结论陈述。

参考:《中华人民共和国密码法》,「国家法律法规数据库」(全国人民代表大会常务委员会法制工作委员会主办),https://flk.npc.gov.cn/ ;《中华人民共和国网络安全法》,「国家法律法规数据库」(全国人民代表大会常务委员会法制工作委员会主办),https://flk.npc.gov.cn/ ;《关键信息基础设施安全保护条例》,「国家法律法规数据库」(全国人民代表大会常务委员会法制工作委员会主办),https://flk.npc.gov.cn/ ;GB/T 39786-2021《信息安全技术 信息系统密码应用基本要求》,「国家标准全文公开系统」(国家市场监督管理总局、国家标准化管理委员会),https://openstd.samr.gov.cn/bzgk/gb/ ;GB/T 32918《信息安全技术 SM2椭圆曲线公钥密码算法》,「国家标准全文公开系统」(国家市场监督管理总局、国家标准化管理委员会),https://openstd.samr.gov.cn/bzgk/gb/ ;GB/T 32905《信息安全技术 SM3密码杂凑算法》,「国家标准全文公开系统」(国家市场监督管理总局、国家标准化管理委员会),https://openstd.samr.gov.cn/bzgk/gb/ ;GB/T 32907《信息安全技术 SM4分组密码算法》,「国家标准全文公开系统」(国家市场监督管理总局、国家标准化管理委员会),https://openstd.samr.gov.cn/bzgk/gb/ ;GB/T 22239-2019《信息安全技术 网络安全等级保护基本要求》,「国家标准全文公开系统」(国家市场监督管理总局、国家标准化管理委员会),https://openstd.samr.gov.cn/bzgk/gb/ ;密码行业标准化技术委员会「标准列表」,https://www.gmbz.org.cn/main/bzlb.html ;国家密码管理局,https://www.oscca.gov.cn/ ;RFC 3207《SMTP Service Extension for Secure SMTP over Transport Layer Security》,P. Hoffman,2002 年 2 月,https://www.rfc-editor.org/rfc/rfc3207.html ;RFC 8314《Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access》,K. Moore、C. Newman,2018 年 1 月,https://www.rfc-editor.org/rfc/rfc8314.html