发布日期：2026-05-07 浏览次数：
2020年3月，一次例行的证书过期导致部分互联网服务瘫痪。这次与Cloudflare相关的服务中断并非由高级攻击或零日漏洞引起，而是由于其边缘基础设施关键部分的证书过期所致。服务无法访问，用户被封锁，事件迅速蔓延。
这并非个例。微软和Let's Encrypt等公司也曾遭遇类似问题，过期或配置错误的证书导致服务大规模中断。另一方面，诸如SHA-1算法在被弃用后仍长期沿用等弱加密算法，则带来了真正的安全风险，包括碰撞攻击和数字签名信任失败。
还有一个不太显眼但却更危险的问题：未管理的密钥。例如，代码库中存放的私钥、云环境中遗忘的凭证，或者没有任何生命周期跟踪的密钥。这些问题不会立即导致服务中断，但一旦暴露，就可能导致更难检测和控制的安全漏洞。
模式很明确。这些故障并非因为组织不重视安全，而是因为加密技术分散在各个系统、团队和工具中，缺乏统一的可见性。证书、密钥、算法和协议都在发挥作用，但没有人能够全面了解它们的位置、使用方式以及何时会构成风险。
这才是真正的问题所在：加密资产的可见性存在缺陷。在企业能够清晰地了解其加密资产之前，它们就像是在盲区中运营，而这些盲区可能会在几乎没有任何预警的情况下演变成服务中断、审计失败或安全事件。
如果您熟悉软件物料清单（SBOM），那么加密物料清单（CBOM）背后的理念与之非常相似。
软件组件物料清单 (SBOM) 会告诉你应用程序内部包含哪些软件组件。加密组件物料清单 (CBOM) 会告诉你环境内部使用了哪些加密技术。
这包括以下内容：
证书（SSL/TLS、代码签名）
密钥（HSM、云端、应用层）
算法（RSA、ECC、哈希函数）
加密库和依赖项
简而言之，CBOM 回答了一个简单但至关重要的问题：我们正在使用什么加密技术，它在哪里，以及它是否安全？
为什么这件事突然变得这么重要了？
首先，后量子密码技术正在兴起。美国国家标准与技术研究院 (NIST) 的标准明确指出，RSA 和 ECC 等算法终究无法永远适用。但问题在于：大多数机构甚至不知道这些算法目前在哪些地方被使用，更遑论如何替换它们了。
其次是合规性问题。诸如PCI DSS、NIS2和DORA等法规和框架正不断加大对组织的压力，要求其证明对加密资产的控制能力。仅仅声称“我们使用加密”是不够的，还需要说明在何处、如何以及是否符合相关政策。
最后，我们来谈谈供应链。软件不再是孤立构建的，而是由库、服务、容器和第三方组件组装而成。这些组件各自都存在加密依赖关系和潜在风险。一旦出现故障或漏洞，就需要迅速追踪问题所在。
综合以上所有因素，CBOM不再是“锦上添花”，而正在成为一项基本要求。你无法管理你看不见的东西。在密码学领域，缺乏可见性不仅会拖慢速度，还会危及安全性、可用性和合规性。CBOM正是弥合这一差距的关键。
乍一看，CBOM似乎很简单：只需建立一个所有加密资产的清单，就大功告成了。但实际上，这种方法很快就会失效。
“清点所有资源”的方法无法扩展：如今大多数环境规模都不小，也不是集中式的。负载均衡器里有证书，硬件安全模块 (HSM) 里有密钥，云端密钥库里有机密信息，容器里有加密库，CI/CD 流水线里还会不断启动更多资源。试图手动跟踪所有这些资源，甚至通过定期扫描，最终都会徒劳无功。等到清点完成时，其中一部分可能已经过时了。
运行时加密与静态清单截然不同：静态清单或许能告诉你某个系统使用了某种算法或证书，但它无法告诉你这些算法或证书在运行时是如何实际使用的。例如，生产环境中是否仍在使用弱加密套件？某个服务是否正在调用已弃用的算法？静态清单完全忽略了这一层，而这往往才是真正风险所在。
仅依赖工具的方法忽略了上下文：许多工具专注于发现：它们可以找到密钥、证书，甚至算法。但如果没有上下文，这些数据就没什么用处。知道某个密钥存在并不等同于知道：
它属于谁？
哪个系统依赖于它
无论是暴露的还是合规的
它对运营的重要性
如果没有这种背景信息，团队最终得到的只是原始数据，而不是可操作的洞察。
这是核心问题：传统的 CBOM 思维将问题视为资产跟踪，而实际上它是关于理解密码学如何在各个系统中使用。
大多数方法都存在数据收集与真正理解数据之间的差距，而这正是它们的不足之处。
密码学并非静静地存在于某个地方等待管理。它遍布于你的技术栈中，持续不断地被使用，而且往往在出现故障之前都处于隐蔽状态。
加密技术无处不在：它不仅仅存在于网络服务器上的证书中。您会在以下方面发现加密技术的身影：
TLS证书保护API和用户流量
存储在硬件安全模块 (HSM) 和云存储库中的密钥
应用程序和容器中捆绑的加密库
强制执行传输中和静态加密的协议
每一种都有其自身的生命周期、配置和风险概况。
它渗透到各种系统和工作流程中：加密货币出现在你并不总是密切关注的地方：
云平台会自动生成和轮换密钥。
HSM在幕后处理高价值密钥。
CI/CD 流水线对构建和工件进行签名
应用程序通过嵌入式库进行加密调用
这些并非孤立的系统；它们在不同的时间点都在创建、使用和依赖加密组件。所有权不明确，碎片化严重。
事情就此变得复杂起来。安全团队制定策略，DevOps团队部署服务，开发人员引入库，基础设施团队管理平台。密码学贯穿所有这些领域，但很少有单一的负责人。
结果如何？
无人主动追踪的证书
钥匙所有权不明
未经审查就使用的算法
纸面上存在的政策，却未能得到持续执行。
因此，尽管密码学无处不在，但问责制却并非如此。它分散在各个团队和工具中，这使得回答诸如“谁拥有这个密钥？”或“如果这个证书过期会发生什么？”之类的基本问题都变得困难。
这就是大多数组织面临的现实，也正是因为如此，简单的基于库存的方法才行不通。
如果传统的CBOM仅仅是一份资产清单，它并不能解决实际问题。企业需要的不是更多的数据，而是可用的洞察。
这不是静态清单，而是情境化、可操作的 CBOM：静态清单只是密钥、证书和算法的快照，虽然纸面上看起来有用，但它无法回答关键问题。它告诉你存在什么，而不是什么才是重要的。实用的 CBOM 能将这些点连接起来。它不仅列出加密资产，还会解释它们的用途、存储位置以及存在的风险。这才是 CBOM 从一份报告转变为团队真正可以操作的工具的关键所在。
加密货币可见性（不仅仅是发现）：发现是第一步。可见性是指了解：
加密货币的使用情况
哪些系统依赖于它
是否符合政策
这就像“我们找到了 500 个证书”和“这 20 个证书至关重要，即将到期”之间的区别。
依赖关系映射：密码学并非孤立存在。单个证书可能支持多种服务。HSM 中的密钥可能与签名管道和生产工作负载相关联。
如果不绘制这些关系图，就无法预测影响。有了它，你就可以回答以下问题：
如果旋转这个钥匙，会损坏什么？
哪些服务依赖于此证书？
该算法实际在哪些地方执行？
风险优先级排序：并非所有加密问题都相同。测试环境中的弱算法与面向公众的服务上的过期证书截然不同。有效的 CBOM 可以通过突出显示以下内容来帮助您集中精力：
弱算法或已弃用的算法
过期或配置错误的证书
未管理或暴露的密钥
与关键系统相关的政策违规行为
目标并非收集所有信息，而是了解哪些信息至关重要并采取行动。这就是转变：从库存管理转向情报收集。如果不进行这种转变，CBOM 就只能停留在形式主义层面，而无法真正成为一项安全能力。
一份实用的 CBOM 并非囊括所有信息的庞大导出文件。它是一种聚焦且结构化的密码学视图，能够帮助您理解风险并采取相应措施。您可以将其视为“最小可行 CBOM”，仅包含足够信息以确保准确性、可操作性和可维护性。
资产清单（密钥、证书、算法）：从基础开始：了解现有的加密资产有哪些。这包括：
证书（TLS、代码签名、内部 PKI）
密钥（HSM、云端 KMS、应用层）
算法（RSA、ECC、哈希函数）
加密库和提供商
目标并非盲目地罗列所有资产，而是以规范化的方式记录资产，以便后续进行关联。例如，将证书与其底层公钥关联起来，或者识别同一密钥在不同系统中的重复使用情况。一份清晰的资产清单是基础，但仅靠它还不够。
使用场景（加密技术的使用地点/方式）：这正是 CBOM 发挥作用的地方。您需要了解：
资产部署位置（应用程序、服务、云资源）
它的用途（TLS、签名、静态加密）
无论是正在使用还是闲置不用
例如，除非你知道某个证书正在主动终止生产 API 上的流量，否则证书库中的证书本身意义不大。上下文可以将原始条目转化为有意义的信息。
风险信号（算法薄弱、证书到期）：一份实用的 CBOM 报告应该指出哪些方面需要关注，而不仅仅是现有情况。关键信号包括：
已弃用或安全性较弱的算法（例如 SHA-1 或密钥长度过小）
即将到期的证书
配置错误（密钥使用不当、缺少约束）
没有轮换策略的密钥
CBOM 不应强迫团队分析原始数据，而应直接突出显示这些问题，以便确定优先级并加以解决。
所有权与生命周期：大多数环境中最大的缺陷之一是所有权问题。对于每个密钥或证书，您都应该能够回答以下问题：
它属于谁？
哪个团队负责
它的生命周期是怎样的（创建、轮换、过期）
如果没有生命周期跟踪，即使识别出的风险也无法解决，因为没有人知道应该由谁来采取行动。生命周期跟踪还有助于避免常见的故障，例如证书过期或密钥长期未轮换。
实用的物料清单并非为了完整而完整，而是为了清晰性和行动力。
如果这能帮助你回答：
我们拥有什么？
它用于哪些领域？
这样做有风险吗？
它属于谁？
那么你就走对了路。
即使团队理解了CBOM的必要性，执行环节往往才是问题所在。挑战通常不在于意图，而在于环境的碎片化程度。
缺乏集中式可见性：加密资产分散在各个系统中——云平台、硬件安全模块 (HSM)、应用程序、负载均衡器和内部公钥基础设施 (PKI) 设置。每个系统都有自己的接口、访问控制和数据存储方式。最终结果是，您只能在各个地方获得部分可见性，而无法获得任何完整视图。
安全团队可以看到策略，DevOps 团队可以看到部署情况，开发人员可以看到代码层面的加密使用情况——但没有人能看到所有这些是如何关联的。这种信息鸿沟使得风险评估变得困难，甚至难以回答关于当前使用情况的基本问题。
手动跟踪（Excel、CMDB 漏洞）：许多组织仍然依赖电子表格或维护不善的 CMDB 条目（CMDB 是一个集中式存储库，用于存储组织 IT 基础架构中所有硬件、软件和 IT 组件的信息）来跟踪证书和密钥。这种方法存在显而易见的问题：
数据很快就会过时。
更新取决于手动输入
影子资产永远不会进入系统。
即使是维护良好的配置管理数据库 (CMDB) 也难以应对这种情况，因为加密资产的行为方式与传统基础设施截然不同。它们是动态创建的，频繁轮换，并且通常与应用程序逻辑而非静态资源绑定。
供应商不透明性：第三方工具和服务通常会将加密技术抽象化。云提供商、SaaS 平台和托管服务会在内部处理密钥和证书，但并非总是公开全部细节。因此，虽然加密技术正在被使用，但您并不总是知道：
哪些算法正在运行？
密钥的生成或轮换方式
配置是否符合您的策略
这种缺乏透明度的情况会造成盲点，尤其是在评估风险或准备审计时。
CI/CD 或云环境中缺乏自动化：现代环境构建于自动化之上，但加密可见性通常不包含在自动化流程中。证书在部署期间颁发，密钥动态生成，签名在构建系统内部进行，但所有这些都没有被持续跟踪或整合到中央视图中。缺乏自动化：
新资产无法实时获取
政策审查不会提前进行。
问题往往在后期才被发现，通常是在生产过程中。
综合来看，这些挑战造成了这样一种局面：加密技术虽然在整个组织中广泛应用，但可见性、控制力和问责制却严重滞后。这正是许多基于密码的管理（CBOM）项目停滞不前的原因；它们试图用静态的、彼此割裂的方法来解决动态问题。
揽阁信息拥有20多年的行业经验，可为您提供满足最新国际合规要求的FIPS 140-3认证的HSM、KMS等产品，并结合您的项目情况为您提供定制化解决方案，欢迎联系我们，与我们的安全专家进行深入交流和讨论。
揽阁信息 · 值得您信赖的信息安全顾问！
沪公网安备31011202021337号 网站地图
友情链接： Thales官网 芯片产品网站 服务热线
