密码等级划分这件事很多人第一次接触时都会以为是在给密码算法排座次——谁的密钥长谁就更高级。实际上真到了工程落地环节你面对的分级至少是四套并行且互相咬合的体系算法强度分级、密钥长度与安全位数的折算、密码模块实现的安全等级、以及数据与应用场景的保护等级。这四套东西各管一段混着谈就会出问题。我做密码应用改造和合规评审陪跑这些年最常看到的错位是系统上了 SM2 加 SM4算法清单看着完全合规但密钥全部明文躺在配置文件里模块跑在普通应用进程中随机数用的是语言自带的伪随机函数。这种系统在算法强度那一栏能拿满分在密码模块和密钥管理那两栏基本是零分。所以这篇我想把密码等级划分拆开讲每一套分级到底在分什么、边界在哪、换算过程怎么算、实操时按什么顺序核查。刚入门的同学可以把它当成一张地图已经做过改造的同行可以对照着找找自己系统里被忽略的那几栏。1. 先搞清楚密码等级到底在分什么1.1 四个维度的分级别混为一谈我把密码等级划分拆成四层来看这四层从下往上越往上越贴近业务也越容易被忽视。第一层是算法强度分级。它回答的问题是这个算法在当前算力下还能不能扛住。衡量单位不是密钥长度而是安全位数bits of security也就是攻击者攻破它所需要的计算量折合成 2 的多少次方。同样是 256 位SM3 的输出是 256 位SM2 的私钥是 256 位但两者能提供的安全位数一个约是 128一个约是 128看着一样背后的攻击模型完全不同——哈希看的是抗碰撞性椭圆曲线看的是离散对数求解难度。第二层是密钥体系分级。根密钥、主密钥、数据密钥、会话密钥这是四个不同量级的密钥它们的生成环境、存储介质、更新周期、销毁方式都不一样。一个系统如果所有密钥都用同一套保护措施那等于把保险柜钥匙和门禁卡挂在同一个挂钩上分级形同虚设。第三层是密码模块实现的安全等级。同一个 SM4 算法写在一段纯软件代码里和跑在一块带物理防护、带自检、带身份鉴别、篡改即自动擦除密钥的硬件密码模块里安全性差着好几个数量级。这一层国际上通行的做法是把模块分成四个递进的等级等级越高攻击者需要付出的物理和工程成本越高。第四层是应用场景与数据的保护等级。身份认证、传输加密、存储加密、完整性校验、不可否认性不同场景对算法的要求差异很大。会话密钥可以短、可以频繁换归档数据密钥可能要存十年那它的强度余量就必须往前看十年。这四层之间是乘积关系不是加和关系。任何一层失守整体的密码保护强度就被拉到那一层的水位。我见过太多方案把力气全花在第一层反复论证算法选型结果真正被攻破的点是第四层密钥管理里的一个小疏漏。1.2 为什么分级标准不按算法名字排座次新手常问的一个问题是为什么不直接列张表A 算法是三级B 算法是二级照着选就行了因为算法本身的安全性是时间相关的。一个算法在某个时间点被评为高强度十年后可能因为算力进步或者新的攻击方法被降级。历史上这种案例不少早期被广泛使用的短密钥算法后来在公开的破解竞赛里被逐步攻破整个行业随之把它们的下限抬走。分级体系真正稳定的部分不是哪个算法叫什么而是你需要多少安全位数——这是一个可以随算力演进动态调整的标尺。所以工程上的正确姿势是先确定你的数据需要多少安全位数这取决于数据的保密期限、攻击者的资源假设、你的风险容忍度再倒推该选什么算法和什么密钥长度。而不是反过来先选算法再想它能撑几年。举个具体的例子。假设你有一套归档系统合同扫描件要求保密期 15 年。你按当前可接受的最低强度是 112 位安全位数来选选了 RSA-2048。但 15 年后 RSA-2048 还能不能维持 112 位这是一个需要打问号的假设。稳妥的做法是至少给一个档位的余量选到 128 位安全位数对应的参数也就是 RSA-3072 或 ECC-256SM2 的 256 位曲线落在这一档。多付的那点性能代价相比 15 年后数据裸奔的风险是很划算的买卖。注意安全位数的档位通常按 112、128、192、256 四档来组织档与档之间是台阶不是斜坡。跨档时密钥长度的增幅是非线性的具体换算见下一节。2. 算法强度分级安全位数才是那把通用尺子2.1 对称算法的强度换算以及密钥长度等于强度的例外对称算法是最好理解的一类在不考虑量子计算的前提下n 位密钥的对称算法其安全位数就是 n。AES-128 是 128 位AES-256 是 256 位SM4 的密钥长度是 128 位安全位数也就是 128 位。这里没有复杂的换算式因为对称算法的标准攻击方式就是穷举密钥空间有多大攻击量级就是多大。但密钥长度等于安全位数这句话有个前提算法本身没有结构性弱点。如果某个对称算法的密钥扩展设计有缺陷存在比穷举更高效的攻击路径那它的实际安全位数就会低于标称密钥长度。这也是为什么算法选型要选经过长时间公开分析、被广泛部署验证的标准化算法而不是自己设计的或者是来路不明的算法。另一个影响对称算法分级判断的因素是工作模式。同一个分组密码配上不同的工作模式安全性会有明显差异。电子密码本模式因为相同明文块产生相同密文块会泄露明文结构信息早已不适合用于超过一个分组的数据。密码分组链接模式解决了这个问题但加密必须串行性能受限。计数器模式和伽罗瓦计数器模式支持并行和随机访问后者还额外提供完整性校验是目前工程上的主流选择。你在做算法清单核查时如果只看到SM4或AES看不到工作模式那这份清单是不完整的必须继续往下追。还有一点常被忽略初始化向量和随机数的质量。计数器模式下的初始计数器值如果被重复使用同一密钥下两次加密的密钥流就一样了把两段密文异或一下就能拿到明文的异或结果等于加密白做。这类问题不是算法强度不够是实现用错了但它对最终安全等级的影响是决定性的。2.2 非对称算法为什么 RSA-2048 只等于 112 位非对称算法的密钥长度和安全位数之间是比较复杂的非线性关系因为它不是靠穷举攻破而是靠求解数学难题。RSA 依赖大整数分解椭圆曲线依赖离散对数两者的攻击算法复杂度不同换算曲线也就不同。下面这张表是我在实际工作中常用的对照关系把常用算法按安全位数档位对齐方便在方案评审时快速判断这几个参数是不是同一档的。安全位数档位对称算法密钥长度RSA 模数长度椭圆曲线含 SM2哈希算法抗碰撞约 112 位3DES 三密钥2048 位224 位SHA-224 / SM3-224 档约 128 位AES-128 / SM4-1283072 位256 位SM2 在此档SHA-256 / SM3约 192 位AES-1927680 位384 位SHA-384约 256 位AES-25615360 位521 位SHA-512这张表里最让人意外的一栏是 RSA 那一列。从 112 位档跳到 128 位档对称算法只加了 16 位密钥椭圆曲线只加了 32 位RSA 却要从 2048 位涨到 3072 位涨了 50%。原因在于一般数域筛法的复杂度与模数长度的关系是次指数级的模数越长分解难度的增长越慢所以必须靠大幅增加模数长度来换取一个安全位数的提升。反过来算一笔账更直观。假设攻击者投入的资源按每年翻一倍的速度增长这是个粗略的工程假设不代表真实预测RSA-2048 从 112 位安全位数被降到 100 位需要多少年112 到 100 是 2 的 12 次方倍也就是 4096 倍按每年翻倍算大约需要 12 年。这个量级说明 112 位档次在中期内仍然有实用价值但对于长周期数据就不够了。提示如果系统里还在用 RSA-1024那它对应的安全位数只有 80 位左右属于早已应该淘汰的档次。做自查时把 1024 位模数当成硬性不合格项处理。2.3 哈希算法的抗碰撞强度只有输出长度的一半哈希算法这一栏有个容易被误解的点安全位数不等于输出长度抗碰撞强度约等于输出长度的一半。SM3 输出 256 位抗碰撞强度约 128 位;SHA-256 同理。背后的原因是生日攻击——找到任意两条碰撞消息所需的尝试次数是 2 的 n/2 次方量级。这个结论在实操中的直接影响是截断哈希。有些系统为了节省存储空间把 256 位的哈希值截断存前 128 位觉得128 位也够长了。但截断之后抗碰撞强度掉到了 64 位左右攻击者做 2 的 64 次方量级的计算就能构造碰撞这个量级在现代硬件上已经不算天文数字。所以哈希值的截断使用必须非常谨慎——如果你只是拿它做完整性校验、不做抗碰撞的安全承诺截断勉强可接受;如果用在数字签名或者证书体系里绝对不能截断。另外要区分抗碰撞性和抗第二原像性。抗第二原像给定一条消息找另一条哈希值相同的消息的难度约是 2 的 n 次方比抗碰撞强得多。所以有些场景下短哈希仍然安全比如用哈希值遮蔽原始值做去重攻击者无法从哈希反推原始值的情况下截断的风险就没那么高。判断的关键是攻击者能不能自由选择两条消息来构造碰撞。能就是抗碰撞场景不能风险等级下降。还有一类特殊用法要单独说基于口令的密钥派生。口令本身的熵非常低一个普通人设的密码可能只有 30 到 40 位熵直接哈希一次就被彩虹表或者高速字典攻击拿下了。所以必须用带盐、带迭代的派生函数用迭代次数把单次尝试的成本抬高。行业公开建议的量级是几十万次迭代起步具体数字取决于你的硬件预算和用户能忍受的登录延迟。单次派生控制在 100 到 300 毫秒是比较常见的折中太慢用户体验崩太快强度不够。3. 密码模块安全等级实现层的那道分水岭3.1 四个等级递进的核心逻辑攻击成本阶梯密码模块的安全等级国际通行的思路是分成四个递进档位。这套分级不看算法选得对不对只看模块作为一个物理实体和软件实体能在多大程度上保护内部的密钥不被提取或篡改。它的核心逻辑是一条攻击成本阶梯低等级的攻击者可以是远程的、纯软件的不接触设备;高等级的对手需要物理接触设备、需要专业设备、需要相当的时间和资金投入。等级越高能被挡住的攻击者画像就越高阶。四个档位的递进关系大致是这样的等级物理安全要求身份鉴别与角色自检能力典型形态一级无特殊物理要求仅要求基本功能正确无强制要求基本功能自检纯软件库、嵌入式实现二级需要防篡改证据封条、涂层、外壳痕迹必须有基于角色的身份鉴别上电自检、条件自检加固的软件模块、带封条的硬件三级需要防篡改或篡改检测机制检测到即销毁关键参数更强的鉴别支持多角色分离完整的自检覆盖含算法自检密码卡、密码机、带零化电路的芯片四级需要环境失效保护温度、电压等异常时自动销毁同上要求更高的鉴别强度同上高保障硬件模块注意二级那道坎从无物理要求到必须有防篡改证据这是一个质变。很多纯软件实现的密码库停在一级原因就是它跑在通用操作系统上任何有 root 权限的人都能把密钥从内存里 dump 出来物理上更是一点防护都没有。三级那道坎也是质变从有防篡改证据到能主动检测并响应。防篡改证据是被动的攻击者打开外壳你能事后发现;防篡改机制是主动的检测到入侵就立刻把密钥清掉让攻击者拿到的只是一堆空壳。这一层的实现方式包括感应网格、光敏检测、微动开关等一旦外壳被打开、或者内部参数被异常访问触发零化电路。四级的差别在环境失效保护。三级能防打开外壳这种主动入侵但防不住把整块芯片放到极端温度、异常电压下诱导出错这类环境攻击。四级要求在检测到温度、电压、时钟频率等环境参数越界时同样触发密钥销毁。3.2 选型时怎么判断自己该用哪一级这不是一个越高越好的选择题而是一个成本与风险的匹配题。判断依据我通常从三个角度切第一密钥的价值和寿命。一把保护会话的密钥生命周期可能只有几分钟泄露了影响也就那几分钟的通信内容。这种密钥用一级模块生成完全够用。但一把用于签发证书的根密钥生命周期十年以上一旦泄露整条信任链崩塌那必须放在三级以上的硬件模块里而且要有双人控制、分片保存。第二部署环境的物理可达性。服务器放在自有数据中心的机柜里有门禁、有监控、有出入登记物理攻击的门槛本身就不低二级到三级之间可以按成本权衡。如果设备部署在分支机构、门店、甚至户外机柜那物理接触的门槛很低就必须往三级靠。第三合规与审计的硬性要求。有些行业场景对密码模块的等级是有明确要求的做方案时先把这个硬约束摸清楚再去谈技术选型顺序不能反。我经手过的一个项目最开始为了省成本选了纯软件实现跑在容器里。上线前的安全评审提了一个问题你的密钥在内存里容器被逃逸之后密钥怎么保护项目组拿不出答案。后来改成把密钥操作收敛到一个独立的密码服务密钥在硬件模块内部生成且永不出模块应用只拿到操作句柄。这个改动的成本比想象中低——不需要全系统改造只需要把加解密调用从本地函数改成远程调用接口语义基本不变。但安全等级一下子从一级跨到了三级。提示密钥永不出模块这个特性比模块等级本身更能说明问题。评审时不要只盯着等级证书要追问密钥是不是在模块内生成、是不是从外部导入、导出接口是不是被物理性禁用。有些系统挂着高等级模块的名头密钥却是软件生成后导入的导入通道还开着等于白搭。4. 场景分级把强度要求落到具体系统里4.1 按数据生命周期来定保护等级前面三节讲的是密码本身怎么分级这一节讲你的数据需要哪一档。我习惯用数据生命周期来做这个映射因为它能很自然地解释为什么同样是加密要求不一样。传输态数据在网络上来回跑暴露面最大但你最关心的是这一段时间内不可读和不被篡改。防护主力是传输层加密会话密钥可以频繁协商、用完即弃。这一档的核心要求是前向安全性——即使长期密钥泄露历史会话也解不开。所以这类场景应该优先用临时密钥交换比如基于椭圆曲线的临时-临时密钥协商而不是用长期密钥直接加密会话。安全位数取 128 位档即可配合定期重协商。存储态数据落在磁盘、对象存储、数据库里暴露面相对小但时间维度拉长了。你在设计存储加密时必须假设这套数据要放五年十年所以安全位数必须留余量。我的建议是存储加密一律按 128 位安全位数起步长周期归档数据往上取到 192 位。密钥管理的复杂度也更高数据加密密钥用主密钥封装主密钥再用根密钥保护形成密钥信封结构这样轮换根密钥时不需要重加密全部数据只需要重新封装数据密钥那一层。使用态数据在内存里参与计算这一块最容易被忽视。很多方案把数据加密落盘了但应用一读出来就是明文在进程内存里躺着中间还可能被写进交换分区。这一档的措施包括内存加密、进程隔离、敏感数据用后立即清零、禁止写入核心转储文件。这一层没有算法选型这么简单但它是密码保护链条上最容易断的一环。销毁态数据该删了普通文件删除只是删了索引扇区上的数据还在。这一档要求对密钥做真正的销毁多次覆写或者利用硬件模块的零化功能对存储介质做安全擦除或者物理销毁。密钥销毁是这里的关键动作——只要密钥没了密文留着也解不开这是密码学提供的一个非常优雅的性质。4.2 典型场景的算法组合推荐把上面的分析落成一张可以直接抄的对照表。这张表里的组合是我在多个项目里验证过的兼顾了合规性、性能和实现复杂度。场景推荐组合安全位数关键实现要点传输层加密SM2临时密钥协商 SM4-GCM SM3128 位必须支持前向安全会话密钥定期重协商静态数据加密业务库SM4-CBC 或 SM4-GCM SM3-HMAC128 位密钥用信封结构数据密钥随记录或随批次轮换静态数据加密长周期归档AES-256-GCM 或 SM4-256 扩展 SM3192 位以上密钥单独托管与数据分离存储身份认证与签名SM2 签名 SM3 摘要128 位私钥必须在密码模块内签名操作不下放完整性校验SM3-HMAC128 位密钥与数据分离先加密后认证的顺序不能错口令存储SM3 或 SHA-256 迭代派生 随机盐视迭代次数盐必须每用户唯一迭代次数按时间预算定密钥封装SM2 加密封装数据密钥128 位每次封装都要新生成临时密钥对表格里先加密后认证这一点值得单独强调。加密和认证的顺序如果反了会引入一系列细微的攻击面。正确的做法是先加密得到密文再对密文通常还包括关联数据计算认证标签。解密时先验证标签验证通过才解密。这个顺序保证攻击者无法通过构造畸形密文来探测解密过程的行为差异。还有一点是不要自己设计加密文件格式。我见过项目组自己设计的容器格式头部存了算法标识、初始化向量长度、密钥版本号这些东西没有纳入认证范围攻击者可以篡改算法标识来实施降级攻击。正确做法是把所有这些头部字段作为关联数据一起参与认证任何一处被改动标签验证就会失败。5. 实操一次密码应用自查怎么走5.1 第一步永远是画清单不是改代码很多团队一提到密码改造就直接动手改代码改到一半发现不知道改哪儿、改到什么程度算完最后搞成了一团乱麻。我的建议是先把清单画出来画清单的成本远低于返工的成本而且清单本身就是后续所有工作的索引。清单分两张资产清单和算法清单。资产清单回答哪些地方用到了密码我通常按下面几个维度去扫所有的网络通信入口和出口包括内部服务之间的调用所有落盘的存储位置包括数据库字段、对象存储、日志、缓存、临时目录所有身份凭证相关的流程登录、令牌签发、会话管理所有涉及不可否认性的业务动作电子签名、时间戳所有的密钥和证书文件包括配置文件里的、环境变量里的、代码里硬编码的最后一条最容易出问题。硬编码密钥这个坏习惯在很多老系统里根深蒂固扫的时候要专门用正则捞一遍代码库把疑似密钥的字符串全部拎出来人工确认。算法清单回答每个点用的是什么算法、什么参数、什么模式。这张表的字段我一般这么设计字段说明位置文件路径或服务名精确到函数级用途传输、存储、认证、签名、校验算法与参数算法名 密钥长度 工作模式 填充方式安全位数折算后的档位用于横向比较密钥来源硬编码、配置文件、环境变量、模块内生成密钥保护明文、加密保护、模块内不出数据寿命这份数据需要保护多久这张表填完问题会自己浮出来。我试过一次填表的过程中就发现了同一个系统里三套不同的密钥管理方式其中一套用的是五年前的老密钥还没轮换。这种问题光看代码是看不出来的一定要横向拉通看。5.2 逐条核查的执行要点清单有了接下来是按项核查。核查顺序我建议从高价值资产往低价值资产走先把核心资产的问题解决掉避免在小问题上消耗预算。核查项一算法是否在可接受清单内。明确列出必须淘汰的算法短密钥的 RSA、单倍长度的数据加密标准算法、已经被证明存在碰撞攻击的哈希算法、流密码里被废弃的那些。发现一个标一个按资产价值排优先级。核查项二随机数来源是否合格。这是最容易被忽视又最致命的一环。检查所有生成密钥、初始化向量、盐值的地方看随机数发生器是不是操作系统提供的密码学安全实现。语言自带的普通随机函数常见的以时间戳、线性同余算法为基础的那些绝对不能用于安全用途。在代码里搜随机数相关的函数调用逐个确认来源。核查项三密钥是否在模块内生成。如果密钥是软件生成后导入模块的那模块的物理防护等级再高也没用因为导入那一刻密钥已经暴露在模块外部了。正确做法是在模块内部生成导出接口关闭。这一条如果做不到至少要保证导入通道是加密的、一次性的。核查项四密钥轮换是否有机制。不是问有没有轮换过而是问有没有自动轮换的能力。手动轮换在现实中往往一拖再拖最后变成永不轮换。设计上应该给每个密钥打上版本号和创建时间配置里能设置轮换周期到期自动生成新密钥并切换旧密钥保留一段时间用于解密历史数据过期后归档。核查项五日志里有没有敏感信息。这个坑太常见了。密钥、令牌、口令、完整的身份证号、银行卡号这些在调试日志里出现的频率高得惊人。检查日志输出点确认敏感字段做了脱敏或者干脆在日志框架层配置过滤规则。注意核查过程中如果发现某个位置看起来没问题但你也说不清为什么不要放过。密码相关的疑问说不清就等于有问题。我踩过的坑里有一半是因为当时觉得应该没事。5.3 密钥管理的分级落地密钥管理是密码应用里最能体现分级思想的地方。我把它拆成三个层次来看层次一密钥本身的层级。根密钥保护主密钥主密钥保护数据密钥数据密钥保护实际数据。这个信封结构的价值在于你只需要用最高等级的保护措施保护最顶层的根密钥下面几层的密钥都可以用上层密钥加密后存储。轮换成本也因此大幅下降——换上层的密钥只需要重新封装下一层不需要重加密业务数据。层次二密钥生命周期的阶段。生成、分发、存储、使用、轮换、归档、销毁,七个阶段每个阶段都有对应的控制点。生成要求高质量随机数;分发要求加密通道;存储要求密文或者模块内;使用要求最小权限、按需调用;轮换要求有周期和触发条件;归档要求旧密钥仍然可用但仅用于解密;销毁要求真正不可恢复。层次三操作权限的分级。这个是最容易做形式化的地方。双人控制、角色分离这些机制设计出来是为了防止单点滥用但如果实际上两个人是同一个人的两个账号或者审批流程是自动通过的那这个机制就等于不存在。我在评审时会专门看操作日志看这些高权限操作是不是真的由不同的账号发起、时间上是不是有真实的间隔。6. 常见问题与排查实录6.1 高频问题速查表下面这张表是我这些年被问得最多的问题按现象、可能原因、排查方向整理遇到类似症状可以对着看。现象可能原因排查方向加密后数据量明显变大分组密码用了需要填充的模式且数据块很小检查是否可以用计数类模式省掉填充或调整存储格式相同明文两次加密结果一样初始化向量固定或被硬编码检查初始化向量的生成逻辑确认每次加密都重新随机生成解密偶发失败初始化向量或被认证的关联数据在传输中被改动比对加密端和解密端的关联数据组装顺序检查是否有字段没纳入认证密钥泄露后发现历史数据仍可解没有做前向安全设计长期密钥直接加密数据改为临时密钥协商长期密钥只用于身份认证性能瓶颈出现在加密环节用了串行模式或者每次调用都重新初始化模块换并行模式会话复用批量操作合并调用合规审查时算法清单被打回清单只写了算法名缺工作模式和密钥长度补齐参数逐项标注折算后的安全位数密钥轮换后老数据读不出来轮换时没有保留旧密钥的解密能力引入密钥版本号支持多版本并存按密文里的版本号选密钥模块正常工作但自检报错模块固件版本或者环境参数温度、电压越界查模块日志确认部署环境是否满足模块的工作条件6.2 几个我实际踩过的坑第一个坑把用了国密算法当成密码应用合规。早期做项目时我们判断标准很简单算法清单里有 SM2、SM3、SM4 就认为过关。结果评审时被问了一串问题密钥怎么生成的在哪儿存的谁能调用轮换过吗一个都答不上来。这件事让我明白算法只是最表层的一层皮真正的功夫在算法之外的密钥管理和模块边界上。后来我调整了工作顺序先做密钥管理的设计再定算法清单反而顺畅得多。第二个坑性能优化把安全性优化掉了。有个系统加密调用太频繁导致延迟高开发同学做了一版优化把密钥缓存在应用进程内存里避免每次调用都走模块。延迟确实降下来了但密钥等于暴露在了应用层模块的物理防护完全失效。正确的优化方向应该是减少调用次数批量加密、会话复用而不是把密钥搬出安全边界。这个教训是任何以把密钥拿出来为代价的性能优化都不是优化是降级。第三个坑自检机制形同虚设。密码模块通常带自检功能上电时验证算法实现的正确性。但有些部署方式会让自检失效比如模块被配置成跳过自检以加快启动或者自检失败只记日志不阻断启动。这两种情况都等于关掉了最后一道保险。正确的配置是自检失败必须阻断服务启动宁可起不来也不能带着错误的实现跑。第四个坑测试环境用了生产密钥。这个问题的严重性不用多说。根源往往是配置管理没有做好隔离测试环境的配置文件是从生产环境拷贝过来的。解决办法是把密钥从配置文件里彻底移出去改成运行时从密钥管理服务获取并且用环境标识做硬隔离——测试环境的服务根本没有权限拿到生产密钥。第五个坑以为加密了就安全了忘了完整性。只加密不认证密文被篡改后解密会得到一堆垃圾数据或者抛出异常但如果攻击者能控制篡改方式某些模式下可以做到可控的明文改动。所以加密和认证必须成对出现任何只加密不认证的设计都要打回去重做。7. 关于分级的最后一点个人体会做了这么多轮改造和评审我越来越觉得密码等级划分这件事的价值不在于评出几级而在于它逼着你去回答一些平时会绕过去的问题这把密钥到底保护什么、丢了会怎样、谁能碰到它、多久换一次。这些问题答不上来的时候等级是评不出来的;答上来了等级其实已经不太重要了因为你已经知道该做什么。还有一个实操上的建议不要试图一次把所有东西都做到最高等级。分级的本意就是让资源花在刀刃上——核心资产按高档位保护边缘资产用够用的档位就行。我见过一些团队追求全系统最高等级结果预算全砸在非核心模块上真正该加固的根密钥反而没钱上硬件模块。把钱花在对的地方比把钱花在多的地方更考验判断力。