发布日期:2026-06-04 浏览次数:

所有运行基于RSA、ECC、TLS 或 AES 加密的组织都拥有自己的加密资产。大多数组织并不清楚其中究竟包含哪些内容。
这并非批评,而是结构性现实。密码学的设计初衷并非像服务器或应用程序那样进行管理。它没有IP地址,也不会在达到使用寿命终点时发出警报。它静静地运行在几乎所有你操作的系统的后台,直到出现故障,直到监管机构要求你提供无法提供的文档,或者直到你认为只是理论上的威胁模型变得足够现实,以至于拥有实际资源的人决定采取行动。
结果可想而知。组织机构多年来不断累积加密债务,却浑然不觉其全部规模。SHA-1 算法仍然存在于多年无人维护的系统中。三重 DES 加密算法仍在配置于不同时代的支付终端上运行。硬编码的密钥仍然存放在开发人员早已弃用的存储库中。证书运行在无人正式拥有的基础设施上。而在你的云环境中,某个微服务正使用着从未有人明确设定过的默认加密设置运行。
这就是密码发现问题,它是贵组织需要执行的所有其他密码学计划的基础。合规性准备、后量子时代迁移、证书生命周期管理和密钥治理:所有这些都需要在任何有意义的工作开始之前了解您拥有什么。
当组织首次尝试进行加密资产清点时,他们总是会对所发现的情况感到惊讶,不是因为发现的情况出乎意料,而是因为发现的情况太多,而现有的记录系统中却很少记录到这些情况。
根据BIS第158号文件,70%到90%的企业软件是由第三方组件组装而成。这些组件中的每一个都包含着部署它们的组织从未直接做出的加密选择:例如,库版本绑定到过时的依赖项、库编写时设置的默认密码套件、以及嵌入到产品代码中的算法选择,而这些代码又来自从未公开过加密信息的供应商。
应用量子加密迁移框架估计,单个移动银行应用程序中存在超过 320 个加密函数调用。在整个企业环境中,加密资产、算法、密钥、证书、协议和库实现的总数高达数十万。大多数组织仅正式记录了其中的一小部分。
组织机构自认为拥有的加密资产与实际生产环境中运行的加密资产之间的差距,并非简单的库存差异。它是所有合规性漏洞、所有补救措施延误以及所有耗时两倍于计划的迁移项目的根本原因。
在着手进行加密资产清点时,人们的自然反应是使用现有工具:运行漏洞扫描器、导出证书管理系统、查询配置管理数据库 (CMDB)。这些工具都能提供一些有用的信息,但它们各自都存在结构性缺陷,无法通过任何配置来克服。
证书管理平台管理您在其平台上注册的证书。但它们没有机制来发现以下证书:在您的管理工作流程之外配置的证书、开发人员直接从公共 CA 请求的证书、云平台自动生成的证书,或者仍在未停用的测试环境中运行的证书。
漏洞扫描器会报告哪些服务可以访问以及哪些服务正在运行。但它们不会揭示应用层之间东西向流量(即内部服务间连接,这些连接在网络边界不可见,并且几乎不受与入站外部流量相同的 TLS 策略约束)上正在协商哪些密码套件。
配置管理数据库 (CMDB)仅记录官方配置的基础设施。它们会遗漏部署在标准工作流程之外的云资源、设施管理部门独立配置的 OT 设备、已集成到运营中但从未录入资产登记册的收购公司系统,以及所有者离职时未记录在案的任何系统。
这些并非工具故障,而是设计局限性。每个工具都是为特定用途而设计的,而这些用途并非用于密码学发现。要弥补这些差距,需要将密码学发现视为一个多层次的过程,而不是运行一次扫描就完事。
完整的密码学清单需要五个不同的发现层。它们不可互换,也不冗余。每一层都能揭示其他层在结构上无法揭示的信息。
| 分层法 | 它独有的发现 |
| 被动网络流量分析 | 生产环境中的实时协议协商,关注的是实际使用的协议,而不仅仅是配置的协议。 |
| 静态代码分析 | 应用程序逻辑中固定了硬编码键、已弃用的库导入和算法选择。 |
| 配置和证书扫描 | 托管基础架构上的密码套件策略;通过 CT 日志获取影子证书 |
| 运行时和二进制分析 | 您无法直接读取供应商设备、OT系统和固件的加密状态。 |
| 人工调查 | 自定义协议、专有方案、未记录的集成以及组织环境 |
被动网络分析是唯一能够揭示生产环境中实际协商的加密协议(而非配置中规定的可协商协议)的发现方法。这种区别比大多数团队预想的更为重要。
配置为支持TLS 1.3 的服务器可能仍然会与无法升级的旧式端点协商 TLS 1.1。在网络边界强制使用现代密码套件的负载均衡器无法控制应用服务器和数据库之间的后端连接,这些后端连接运行的是应用程序最初编写时所使用的任何加密套件。被动分析部署在关键聚合点的网络分路器或 SPAN 端口上,可以从这些连接中捕获实时 TLS 握手元数据,而无需解密流量或对生产系统造成任何负载。
桑坦德银行的加密资产清点计划由 Jaime Gómez García 在 2025 年 PKI 联盟 PQC 大会上提出。该计划利用现有工具进行适配,而非使用专门构建的发现平台,实现了对全球 9000 个 Apache 实例的全面监控。在第一层(网络层)中,往往会出现运营上最棘手的问题。
静态分析会扫描源代码库,查找直接嵌入在应用程序逻辑中的加密材料,例如硬编码的密钥值、已弃用的库导入以及密钥生成调用中显式指定的密钥长度参数。这些加密选择在代码级别是固定的,必须完全重新部署才能更改。
在生产应用程序中调用 hashlib.sha1() 不仅仅是算法已弃用的警告。它需要进行代码修改、构建、测试和部署等一系列修复工作。在包含数十万个加密函数调用的企业代码库中,第二层(数据层)首次真正展现了应用级迁移工作的规模。
这一层涵盖了负载均衡器、防火墙和 VPN 集中器上配置的密码套件策略,以及PKI环境和云基础设施中的证书清单。
证书透明度 (CT) 日志是这一层中最常被低估的资源。每个受公众信任的证书颁发机构 (CA)都必须将其颁发的每个证书提交到 CT 日志中,这些日志是公开可查询的。对您的域名进行 CT 日志查询会返回为其颁发过的所有证书,包括那些从未在您的证书管理系统中注册的证书。这些就是您的影子证书,无论它们是否出现在您的管理清单中,都属于监管范围。
对于无法获取源代码的厂商设备、嵌入式固件和OT系统,运行时和二进制分析是评估实际加密状况的唯一可行方法。这适用于ATM和POS终端、网络设备、工业控制系统以及任何加密实现位于贵组织未编写且无法直接检查的固件中的设备。
NIST CSWP 39文件指出,OT 系统的平均更新周期为 20 年。实际上,这意味着过时的加密算法可能会在运营技术环境中长期存在十年甚至更久,既没有更新机制,也没有任何治理流程对其进行过维护。
架构文档审查、HSM和KMS审计日志检查、供应商安全文档分析以及与平台和系统所有者的结构化访谈,共同构成了完整的发现图景。人工调查能够揭示所有自动化层都会遗漏的自定义协议、专有加密方案和未记录的集成,并提供组织背景信息,将原始的技术发现转化为真正可操作的情报。
每一层都能发现其他层无法发现的问题。跳过任何一层都意味着永久继承该层的盲点。
对于受DORA、PCI DSS 4.0 或NIS2约束的组织而言,加密资产清单并非最佳实践建议,而是现行的、可强制执行的法律义务。
《数据保护条例》(DORA) 第 9.2 条要求金融机构维护一份最新的信息资产登记册,其中明确包括所有支持关键或重要功能的 ICT 系统所使用的加密资产。DORA第 7.4 条进一步要求该登记册包含所有数字证书及其存储设备。这两项规定均自2025 年 1 月 17 日起生效。
PCI DSS 12.3.3 要求对所有正在使用的加密套件和协议进行记录并持续维护,每项记录均需提供业务理由,并需进行积极的可用性监控,以及针对任何已识别的加密漏洞制定书面应对策略。该要求自2025 年 3 月 31 日起生效。
这两项都不是未来的截止日期,而是目前就必须履行的义务。如果一个组织在监管审查期间无法提供所需文件,这并非是其发展路线图存在漏洞,而是其未能履行自今年年初以来就已生效的强制性要求。
构建加密资产清单的商业理由并不需要进行量子威胁评估或正式的后量子迁移授权。自2025年1月以来,仅合规性问题就足以构成充分的理由。
加密发现问题并非未来才有的挑战,而是迫在眉睫的现实。大多数组织都面临着巨大的差距:他们自认为的加密资产与实际生产环境中运行的加密资产之间存在显著差异。这些差距并非无关紧要,它们会导致迁移项目停滞不前,合规性审计发现意料之外的问题,以及补救措施的实施时间远远超出最初的预期。
SHA-1 到 SHA-256 的迁移预计需要五年时间,但实际耗时超过十年。后量子时代的转型在各个方面都规模更大,而且 DORA 和 PCI DSS 4.0 的合规义务已经生效。每个月缺少完整且受监管的库存清单,都意味着风险的累积。
了解自身拥有的资源并非终点,而是起点。但所有其他举措、合规性、迁移和治理工作都依赖于此起点。那些现在就建立起这种可视性的组织,才能在关键时刻做好准备。
揽阁信息 · 值得您信赖的信息安全顾问!