Chat 密评与等保

USER

等保三级及以上系统要求必须使用国密算法，这是为了通过密评吗？

ASSISTANT

您的理解非常准确。等保三级及以上系统要求使用国密算法，最直接、最核心的原因就是为了满足国家法律法规的要求，并顺利通过“密评”（商用密码应用安全性评估）。

为了让您更清晰地了解背后的政策逻辑，我们可以从以下几个维度来拆解“等保”、“密评”与“国密算法”之间的关系：

1. 厘清一个常见误区：等保标准本身并未“强制写死”国密

在《网络安全等级保护基本要求》（GB/T 22239-2019，即等保2.0）中，条款的表述通常是“应采用密码技术保证通信过程/存储过程中的机密性/完整性”。等保标准本身**并没有强制规定必须使用国密算法**（理论上用RSA、AES等国际算法也能满足等保的技术要求）。

但是，随着2020年《中华人民共和国密码法》的实施，情况发生了根本性的变化。

2. 真正的“强制力”来自《密码法》与“密评”

根据《中华人民共和国密码法》第二十七条规定：法律、行政法规和国家有关规定要求使用商用密码进行保护的**关键信息基础设施**，其运营者应当使用商用密码进行保护，自行或者委托商用密码检测机构开展**商用密码应用安全性评估（简称“密评”）**。

在实际执行中，国家密码管理局明确规定：等保三级及以上的信息系统、关键信息基础设施，必须开展密评。

而在密评的现行国家标准 《信息系统密码应用基本要求》（GB/T 39786-2021） 中，对第三级及以上的系统有极其严格的规定： * 必须使用国家密码管理局认可的商用密码算法（即国密算法，如SM2、SM3、SM4、SM9等）。 * 如果在三级系统中使用未经批准的密码算法（如国际通用的RSA、AES、MD5、SHA等），在密评中会被**直接判定为高风险项或严重扣分**，导致**密评直接不通过**。

3. 等保与密评的“强绑定”关系（双评机制）

目前，国家在网络安全监管上实行的是 “等保+密评”双评机制。 * **公安/网信部门**主管等保； * **密码管理局**主管密评。 在实际的合规审查中，等保三级系统如果“密评”不通过，其“等保测评”往往也无法通过（或被限期整改）。各地公安机关和网信办在进行等保监督检查时，都会将密评报告作为重要的核查材料。 因此，为了让系统顺利通过等保三级备案和测评，就必须通过密评；为了通过密评，就必须全面引入国密算法。

4. 为什么要这么做？（深层原因）

除了“应付”评估，国家强制推行国密算法的背后是**国家安全和自主可控**的战略考量： * 防范“后门”风险：国际通用算法（如RSA、ECC）由西方机构主导，存在未知后门或底层数学漏洞被利用的风险（如“棱镜门”事件）。 * 供应链安全：在金融、能源、交通、政务等涉及国计民生的等保三级系统中，如果底层加密技术依赖国外，一旦发生极端情况，将面临系统瘫痪或数据被解密的“卡脖子”风险。 * 国密算法的成熟：我国的SM系列算法（SM2非对称、SM3哈希、SM4对称）在安全性上已经达到甚至部分超越了国际同类算法的水平，且得到了国际标准化组织（ISO）的认可，具备了全面替代的技术基础。

总结

等保三级系统使用国密算法，表面上是为了通过“密评”和“等保”这两项合规性考试，本质上则是履行《密码法》的法定义务，保障国家关键信息基础设施的安全与自主可控。

如果您目前正在负责等保三级系统的建设或改造，建议尽早引入**国密浏览器、国密SSL证书、国密网关（VPN）、国密服务器密码机**等合规产品，并按照 GB/T 39786-2021 标准进行“三同步”（同步规划、同步建设、同步运行）改造，以免在最终的密评和等保测评中遭遇“一票否决”。

USER

密评主要测试哪些方面，仅仅测试密码算法是否合规吗？

ASSISTANT

绝对不是。 仅仅使用合规的国密算法（如SM2/SM3/SM4），只是通过密评的 “最低门槛”。

密评（商用密码应用安全性评估）的核心依据是 《信息系统密码应用基本要求》（GB/T 39786-2021）。密评不是单纯查一查你用了什么算法，而是对信息系统**如何正确、有效、安全地“使用”密码技术**进行的一次全方位体检。

简单来说，密评主要测试 “技术” 和 “管理” 两大维度，涵盖从物理机房到应用代码、从密钥生成到人员管理的方方面面。具体主要测试以下几个核心方面：

一、 技术层面（四大安全层面）

密评要求在信息系统的各个层级都正确应用密码技术，通常被称为“四层防护”：

1. 物理和环境安全（机房层）

• 测试重点：机房的门禁系统、视频监控系统是否使用了密码技术？
• 常见考点：门禁卡是否采用了国密算法（如CPU卡），而不是容易被复制的普通IC卡；进出机房的身份鉴别记录是否使用了密码技术保证完整性，防止被篡改。

2. 网络和通信安全（网络层）

• 测试重点：数据在网络传输过程中是否安全？通信双方的身份是否可信？
• 常见考点：
  • 通信链路加密：是否使用了国密SSL/TLS协议（国密浏览器/国密网关）或国密IPSec VPN来保证通信信道的机密性？
  • 身份鉴别：通信双方（如客户端与服务器、服务器与服务器）是否使用了基于国密数字证书的双向身份认证？

3. 设备和计算安全（操作系统/主机层）

• 测试重点：管理员登录服务器或网络设备时，密码技术如何发挥作用？
• 常见考点：
  • 登录鉴别：管理员是否使用国密UKey或动态令牌进行双因素强身份认证，而不是仅仅输入静态口令？
  • 访问控制与日志：系统的重要安全日志是否使用密码技术（如SM3哈希或MAC）进行了完整性保护，防止黑客删除或篡改日志？

4. 应用和数据安全（业务层，重中之重）

• 测试重点：业务系统里的核心数据是否得到了真正的密码保护？
• 常见考点：
  • 身份鉴别：用户登录App或Web系统时，是否使用了国密算法进行身份验证？
  • 数据机密性：鉴别数据（如密码）、重要业务数据、个人隐私信息在数据库中是否使用国密算法（如SM4）进行了**加密存储**？
  • 数据完整性：重要数据在存储和传输时，是否使用了密码技术（如HMAC）防止被篡改？
  • 抗抵赖性：关键业务操作（如审批、转账、电子合同签署）是否使用了**国密数字签名（SM2）**，确保操作人事后无法否认？

---

二、 密码核心技术：密钥管理（核心中的核心）

密码学界有一句名言：“密码的安全性不依赖于算法的保密，而依赖于密钥的保密。” 密评对“密钥管理”的审查极其严苛。

• 测试重点：密钥的**全生命周期**（生成、存储、分发、使用、更新、归档、销毁）是否安全？
• 常见考点：
  • 密钥是硬编码在代码里的（严重违规），还是由合规的硬件密码设备（如服务器密码机、签名验签服务器）生成的？
  • 密钥在设备内部存储时，是否使用了更高一级的密钥（主密钥）进行了加密保护？
  • 密钥更新和销毁机制是否完善？

---

三、 管理层面（安全管理体系）

即使你的技术做得再完美，如果管理一塌糊涂，密评同样无法通过。密评要求建立配套的密码安全管理制度：

• 管理制度：是否制定了专门的密码安全管理制度、操作规程和应急预案？
• 人员管理：关键密码岗位（如密钥管理员、密码审计员、密码操作员）是否做到了 “三员分立”（不能由一个人兼任，互相监督）？相关人员是否签署了保密协议并定期接受培训？
• 建设与运行：密码系统是否做到了“三同步”（同步规划、同步建设、同步运行）？采购的密码产品是否具备国家密码管理局颁发的《商用密码产品认证证书》？

---

总结：密评到底在评什么？

密评不是查你有没有买国密设备，而是查你有没有 “用对”、“用好”、“管好” 国密技术。

一个典型的失败案例： 某系统为了过密评，花重金购买了国密服务器密码机，数据库里的重要数据也确实调用了密码机的SM4接口进行了加密存储（算法合规、数据机密性达标）。但是，密评专家在审查时发现，调用密码机所需的“设备密钥”被开发人员明文写在了系统的配置文件里（密钥管理违规）。最终，该系统密评**直接不通过**。

因此，准备密评时，建议您不仅要采购合规的国密软硬件产品，更要从系统架构设计的初期，就引入专业的密评咨询或建设方案，确保密码技术能够真正融入到业务流程的每一个安全环节中。

USER

国密SSL/TLS协议需要企业自行实现吗？如果密码存储使用SM4或SM2等，虽然符合合规性要求，但是否存在密钥被攻击者获取从而解密的风险？

ASSISTANT

这两个问题非常切中企业落地“国密改造”时最核心的痛点。我们分两部分来详细解答：

---

一、 国密 SSL/TLS 协议需要企业自行实现吗？

答案是：绝对不需要，也强烈不建议企业自行实现。

1. 为什么不能自行实现？

• 技术门槛极高且极易出错：SSL/TLS 协议的实现极其复杂，涉及握手协商、密钥交换、分组加密、MAC 校验等。历史上著名的“心脏滴血”（Heartbleed）、“降级攻击”、“填充预言机攻击”等漏洞，都是协议实现层面的微小失误导致的。企业自行开发极易引入安全漏洞。
• 合规性要求（密评一票否决）：密评（GB/T 39786）明确要求，信息系统使用的密码产品必须是**经过国家密码管理局认证的商用密码产品**。企业自己写代码实现的 SSL/TLS 协议栈，没有《商用密码产品认证证书》，在密评中会被直接判定为**不合规**。

2. 企业应该如何落地国密 SSL/TLS？

目前国密 SSL/TLS 的生态已经非常成熟，企业只需要**采购或集成合规的商用密码产品**即可。常见的落地方式有：

• 部署国密 SSL 网关/负载均衡： 在企业现有的 Web 服务器（如 Nginx、Tomcat、IIS）前面，部署一台**国密 SSL 网关**（或支持国密的负载均衡设备，如 F5、深信服、迪普等）。由网关负责终结国密 HTTPS 请求，将解密后的明文或重新加密的流量转发给后端服务器。这是最常见、改造成本最低的方案。
• 使用支持国密的 Web 服务器软件： 如果企业需要直接在服务器上支持国密，可以使用经过安全认证的国密 Web 服务器版本（例如基于“铜锁 Tongsuo”或“GmSSL”等开源国密库深度定制并过审的商业版 Nginx/Apache）。
• 客户端配合： 国密 SSL/TLS 需要浏览器支持。目前主流的国密浏览器（如 360 安全浏览器、奇安信浏览器、红莲花等）以及部分国产移动端浏览器，都已经内置了对国密 SSL 协议的支持。

总结：企业不需要自己写密码算法和协议代码，只需要**选型合规的国密硬件/软件产品，并配置好国密 SSL 证书**即可。

---

二、 密钥被攻击者获取从而解密的风险存在吗？

答案是：风险确实存在，而且这正是密码安全领域的“命门”。

密码学界有一句名言：“密码系统的安全性不依赖于算法的保密，而依赖于密钥的保密。” SM4 或 SM2 算法在数学上是安全的（目前无法被暴力破解），但如果**密钥（Key）** 被黑客拿到了，那么加密数据就会瞬间“裸奔”。

1. 常见的“密钥泄露”高危场景（错误示范）

很多企业在做国密改造时，只做到了“算法合规”，却忽略了“密钥安全”，导致密评不通过或存在巨大隐患： * 硬编码：开发人员图省事，把 SM4 的对称密钥直接写死在 Java/Python 代码里，或者写在 application.yml 配置文件中。 * 明文存储：把加密数据库用的密钥，以明文形式存放在另一张数据库表里，或者存在服务器的普通文本文件中。 * 风险后果：一旦系统存在 SQL 注入、远程代码执行（RCE）漏洞，或者内部有“内鬼”，攻击者就能轻易拿到密钥，进而解密所有核心数据。这就相当于“把锁和钥匙放在了同一个抽屉里”。

2. 如何防止密钥被获取？（标准解决方案）

为了解决这个问题，国家密码管理局和密评标准（GB/T 39786）给出了明确的规范：必须使用硬件级安全设备来管理密钥。

• 核心武器：服务器密码机（HSM）/ 签名验签服务器 企业必须采购经过认证的**硬件密码机**。它的核心特性是**“密钥永不离开硬件边界”（Key never leaves the boundary）**。

  • 密钥生成与存储：SM4 的主密钥、SM2 的私钥，直接在密码机内部的加密芯片里生成，并永久存储在里面。任何管理员、开发人员、甚至操作系统都无法将密钥以明文形式导出或读取。
  • 加解密流程：应用系统不接触密钥。应用系统把“明文数据”和“指令”发送给密码机，密码机在硬件内部用密钥完成加密/解密，然后把“密文/明文”返回给应用系统。
  • 防物理攻击：合规的密码机具备防拆、防探测、防旁路攻击能力。一旦检测到有人试图物理拆解设备，硬件会自动销毁内部密钥。

• 信封加密（Envelope Encryption）机制 对于海量数据的加密，通常采用“两层密钥”架构：

  1. 主密钥（Master Key）：存在密码机硬件里，绝对不出域。
  2. 工作密钥（Data Key）：由密码机随机生成，用于加密具体的业务数据。
  3. 流程：工作密钥用完即毁，或者用主密钥加密后（密文状态）存在数据库里。黑客即使拖库，拿到的也只是“密文数据”和“密文密钥”，没有密码机里的主密钥，根本无法解密。

• 严格的权限控制与“三员分立” 密评要求对密码设备的访问必须严格控制。系统管理员、安全保密管理员、安全审计员必须权限分离。调用密码机接口需要严格的身份认证和授权，防止内部人员滥用。

---

三、 给企业的实战建议

如果您正在负责系统的国密改造和密评准备，请务必遵循以下原则：

1. 不要重复造轮子：坚决不要让自己的研发团队去写 SM2/SM3/SM4 的底层算法代码，也不要去实现 SSL/TLS 协议。直接采购有《商用密码产品认证证书》的密码机、国密网关、国密浏览器。
2. 密钥管理是重中之重：在架构设计时，必须引入**服务器密码机**或**国密密钥管理系统（KMS）**。确保所有核心数据的加解密、签名验签，都是调用密码机的 API 完成的，而不是应用服务器自己拿着密钥算。
3. 落实“三同步”：密码安全不是等系统上线前突击买个设备就能解决的。必须在系统需求分析和架构设计阶段，就规划好“哪里需要加密、哪里需要签名、密钥放在哪里”，做到**同步规划、同步建设、同步运行**。
4. 提前做差距分析：在正式密评前，建议找有资质的密评咨询机构做一次“预评估”，重点排查是否存在“密钥硬编码”、“未使用合规密码产品”、“未实现抗抵赖性”等高频致命问题。

只要按照国家标准正确使用硬件密码设备并管好密钥，国密算法不仅能帮您通过合规审查，更能为您的系统构筑起真正坚固的安全防线。

USER

但密码等口令数据使用SM3哈希算法存储不是更好吗，这样是否也不需要考虑密钥的保存安全性了？

ASSISTANT

您的直觉非常敏锐！对于“口令（密码）”这类用于身份鉴别的数据，使用哈希算法（如国密 SM3）进行单向处理，确实比使用对称加密（如 SM4）更好、更标准。 因为系统本身永远不需要“解密”出用户的原始密码，只需要比对哈希值即可。

但是，针对您后半句的问题：“这样是否也不需要考虑密钥的保存安全性了？”

答案是：依然需要考虑，而且非常重要。

仅仅把口令直接丢进 SM3 算法里算出一个哈希值存起来，在安全上是**极其脆弱**的，在密评（GB/T 39786）中也是**不合规**的。下面我为您详细拆解原因以及正确的做法。

---

一、 为什么“纯 SM3 哈希”是不安全的？

如果您在数据库里存的是 SM3("123456") 的结果，会面临两个致命风险：

1. 彩虹表攻击（Rainbow Table） 黑客手里有现成的“常用密码-哈希值”对照表。只要他们拖库拿到了您的 SM3 哈希值，直接查表就能反推出原始密码是 "123456"。
2. SM3 计算速度太快了 SM3 是为了高效校验数据完整性而设计的，现代 GPU 每秒可以计算**数十亿次** SM3。如果数据库泄露，黑客可以在几小时内把几百万个常用密码全部用 SM3 算一遍，暴力破解出弱口令。

---

二、 解决方案：必须引入“盐（Salt）”和“密钥（Pepper/Secret）”

为了解决上述问题，业界和国密标准都要求在哈希时加入额外的随机值或秘密值。这就是为什么您依然绕不开“密钥/秘密值安全管理”的原因。

1. 加盐（Salt）—— 防彩虹表

• 做法：用户注册时，系统生成一个随机字符串（Salt），和密码拼在一起再哈希：SM3(Salt + Password)。Salt 和密码哈希一起存在数据库里。
• 安全性：即使两个用户都用 "123456"，因为 Salt 不同，哈希值也完全不同。黑客无法直接查表。
• 局限性：Salt 是明文存在数据库里的，它不是秘密。黑客拖库后，依然可以针对每个用户单独进行暴力破解。

2. 加“胡椒”或服务器密钥（Pepper / Secret Key）—— 防离线暴力破解

为了彻底防止黑客拖库后离线破解，必须在哈希过程中引入一个“只有服务器知道、且绝不落在数据库里”的秘密密钥。通常采用 HMAC-SM3 或 PBKDF2-HMAC-SM3 算法： * 公式：Hash = HMAC-SM3(服务器主密钥, Salt + Password) * 关键点：这里的**“服务器主密钥”就是您必须保护的**密钥！ * 风险：如果黑客通过 SQL 注入或内鬼拿到了数据库，但没有拿到这个“服务器主密钥”，他们依然无法算出正确的哈希值。但如果这个主密钥被硬编码在代码里，或者明文写在配置文件里，一旦服务器被攻破，密钥泄露，所有口令防线瞬间崩溃。

3. 慢哈希/迭代（Slow Hashing）—— 防 GPU 暴力破解

必须使用类似 PBKDF2 的口令派生函数，将 SM3 迭代运算 10,000 次甚至 100,000 次。这样黑客每尝试一个密码，成本都会增加几万倍，从而让暴力破解变得在经济上不可行。

---

三、 密评（GB/T 39786）对口令存储的合规要求

在等保三级和密评的审查中，专家不仅看您用没用 SM3，更看您**怎么用**。合规的口令存储架构通常要求：

1. 必须使用合规的密码产品 不能随便找个开源的 SM3 库在应用服务器里算。通常要求调用**服务器密码机（HSM）**或**签名验签服务器**的接口。
2. 密钥不出硬件（Key never leaves the boundary） 用于 HMAC-SM3 运算的**主密钥**，必须在**服务器密码机内部**生成和存储。应用系统只能发送“口令明文 + 盐”给密码机，密码机在硬件内部用主密钥算出 HMAC 值返回。任何开发人员、DBA 都无法看到或导出这个主密钥。
3. 算法合规性 必须使用国家密码管理局认可的算法和模式（如 SM3 杂凑算法，结合 HMAC 结构）。

---

四、 企业落地的最佳实践（抄作业）

如果您正在设计一个等保三级系统的登录模块，建议采用以下架构：

1. 前端：使用国密浏览器或国密安全控件，通过**国密 SSL/TLS** 将用户口令加密传输给后端（防止中间人监听）。
2. 后端接收：后端通过国密 SSL 网关解密拿到明文口令。
3. 调用密码机：后端通过 API 调用**服务器密码机**的“口令哈希/杂凑运算”接口。
   • 传入：用户口令 + 随机盐（Salt）。
   • 密码机内部：使用存储在硬件里的**主密钥**，执行 PBKDF2-HMAC-SM3 迭代运算。
   • 返回：最终的哈希值。
4. 数据库存储：只存储 用户名、随机盐(Salt)、哈希值。绝对不存储任何密钥。
5. 密钥管理：服务器密码机的主密钥由安全管理员通过硬件 Token 或控制台管理，严格遵循“三员分立”，确保密钥不落地、不导出。

总结

• 用 SM3 存口令是对的方向，比用 SM4 加密好得多。
• 但绝对不能“裸算”SM3，必须加盐、加服务器密钥（HMAC）、加迭代。
• 那个“服务器密钥”依然是整个安全体系的命门。一旦它泄露，黑客就能伪造或破解所有口令。
• 合规且安全的唯一解：把这个密钥关进**硬件密码机（HSM）** 里，让密码设备来替您保管它。这样既满足了密评对“密钥管理”的严苛要求，又真正做到了防拖库、防内鬼。

USER

密评和等保需要针对企业所有相关资产(服务器、主机、WEB系统等)进行测评吗？是否需要先进行资产评估？

ASSISTANT

这是一个非常专业且切中合规落地痛点的问题。

直接回答您的两个核心疑问： 1. **不需要**针对企业“所有”资产进行测评，而是针对 “特定的定级对象（信息系统）及其支撑边界内的资产” 进行测评。 2. 必须**先进行资产梳理和识别（在安全领域通常不叫财务意义上的“资产评估”，而是叫 “资产盘点”与“数据分类分级”），这是开展等保和密评的**前置必经步骤。

下面为您详细拆解其中的逻辑和实操方法：

一、 测评范围：是“测系统”，而不是“测整个企业”

很多企业误以为等保三级或密评，就是要对全公司的所有电脑、服务器、网络进行大考，这其实是一个误区。

1. 等保的边界：以“定级对象”为单位

等保（网络安全等级保护）的基本单元是**信息系统**（或通信网络设施、数据资源等）。 * 举例：您的企业可能有一个“核心交易业务系统”（定为三级），一个“企业内部OA系统”（定为二级），还有一个“对外宣传官网”（定为一级或不定级）。 * 结论：如果您现在要做“等保三级”测评，测评机构**只针对“核心交易业务系统”** 以及**支撑该系统运行的物理机房、网络设备、服务器、数据库、应用代码**进行测评。您的内部OA系统和宣传官网，如果不涉及核心交易系统的网络互通或数据共享，则**完全不在**本次三级测评的范围内。

2. 密评的边界：与等保“强绑定”

密评（商用密码应用安全性评估）的原则是 “同步规划、同步建设、同步运行”。 * 密评的边界通常**与等保的边界完全一致**。 * 如果您的“核心交易业务系统”定为等保三级，那么密评也是针对这个系统。您需要梳理的是：这个系统的数据传输是否用了国密？这个系统的服务器登录是否用了国密？这个系统的数据库里的核心数据是否用了国密？ * 结论：不属于该定级系统边界内的资产，不需要纳入本次密评范围。

💡 避坑指南（合理划分边界）： 在定级和备案阶段，**合理划分系统边界**非常重要。如果把无关的边缘系统、测试服务器硬塞进三级系统的边界里，不仅会大幅增加您的改造成本（都要买国密设备、改代码），还会增加测评不通过的风险。

---

二、 为什么必须先做“资产梳理”（资产识别与分类分级）？

您提到的“资产评估”，在合规语境下指的是**信息资产的盘点、识别与数据分类分级**。如果不做这一步，等保和密评根本无法开展。

1. 为什么等保需要资产梳理？

• 定级的前提：只有摸清了系统里有哪些服务器、网络拓扑是什么样的、数据量有多大，才能准确评估系统遭到破坏后的危害程度，从而**确定定级级别**（二级还是三级）。
• 测评的基准：测评机构进场的第一步，就是让您提供《资产清单》。他们会拿着清单去核对：清单上的服务器是否打了补丁？数据库是否开启了审计？如果没有清晰的资产清单，测评无从下手。

2. 为什么密评更需要深度的资产与数据梳理？（核心！）

密评不是简单地查设备，而是查 “密码技术是否保护了重要资产”。因此，前期的资产梳理必须极其细致，特别是要进行**数据分类分级**： * 识别重要数据：系统里哪些是“鉴别数据”（如用户口令、生物特征）？哪些是“重要业务数据”（如交易流水、核心配方）？哪些是“个人隐私信息”？ * 匹配密码需求： * 如果是**鉴别数据**，必须梳理出它在传输和存储时是否用了合规的哈希/加密算法（如SM3/SM4）。 * 如果是**重要业务数据**，必须梳理出它在流转的每一个节点（前端、网关、应用服务器、数据库）是否都有密码技术保护机密性和完整性。 * 结论：如果不先做数据资产梳理，您就不知道哪些数据需要加密，密评专家一查发现“核心数据竟然在裸奔”，直接判定为高风险（一票否决）。

---

三、 实操指南：如何开展前期的“资产梳理”？

在正式启动等保和密评改造前，建议企业内部或请专业的咨询机构，按照以下维度建立详细的《系统资产与密码应用需求清单》：

1. 物理与环境资产

• 系统所在的机房位置？
• 门禁系统、视频监控系统是否属于该定级系统独占或共享？（密评要求门禁等使用密码技术）。

2. 网络与通信资产

• 网络拓扑图（边界在哪里？防火墙在哪？）。
• 通信链路（用户到Web服务器的链路、Web服务器到数据库的链路）是否使用了国密SSL/TLS或国密VPN？

3. 设备与计算资产（硬件/OS）

• 清单：所有属于该系统的服务器IP、操作系统版本、数据库类型及版本、网络设备（交换机/路由器）、安全设备。
• 梳理点：管理员是如何登录这些设备的？（是否使用了国密UKey进行双因素认证）。

4. 应用与数据资产（重中之重）

• 应用模块清单：系统有哪些核心功能？（如登录、支付、审批）。
• 数据流向图：核心数据从用户输入，到最终落盘，经历了哪些节点？
• 数据分类分级清单：
  • 极高价值数据（如用户密码、密钥、支付密码） -> 必须强加密/哈希+硬件保护。
  • 重要业务数据（如订单、合同） -> 需要SM4加密存储，SM2签名防篡改。
  • 普通数据 -> 视情况保护。

---

四、 特殊场景提醒：云上系统（云租户）的资产边界

如果您的系统部署在**阿里云、腾讯云、华为云**等公有云或政务云上，资产梳理的边界会有所不同： * 物理机房、底层网络、宿主机硬件：这些属于**云服务商**的资产，由云服务商自己去过等保和密评（云租户直接复用其合规证明，不需要您去测）。 * 您的资产边界：您租用的 ECS（云服务器）、RDS（云数据库）、VPC（虚拟网络）、以及您自己开发部署的**应用系统和业务数据**。 * 结论：云上系统的资产梳理相对简单，重点放在**应用层和数据层**的国密改造上（如使用云厂商提供的合规国密KMS服务、国密SSL证书等）。

总结

等保和密评**不是对企业进行“无差别的全身体检”**，而是对 “特定的器官（定级信息系统）” 进行深度检查。

“资产盘点与数据分类分级”是合规改造的“地基”。地基打不牢，边界划不清，不仅会导致您买错设备、花冤枉钱，还会在最终测评时因为“遗漏重要数据保护”而面临整改。建议在项目初期，务必花时间把《定级系统资产清单》和《数据分类分级目录》梳理清楚。

USER

关于数据分类分级，目前通常有哪些？在实际实施中是结合国家标准、企业自身、评审专家多个方面共同决定的吗？

ASSISTANT

您的理解非常精准！数据分类分级绝不是企业“拍脑袋”自己说了算的，它确实是一个结合了“国家法律法规标准、行业监管要求、企业自身业务属性以及专家评审意见”的多方协同、动态博弈的过程。

数据分类分级不仅是《数据安全法》的核心要求，也是**等保2.0**和**密评（GB/T 39786）** 中决定“哪些数据必须加密、哪些数据必须签名”的**根本依据**。

以下为您详细拆解目前主流的分类分级体系，以及在实际落地中各方是如何协同决定的。

---

一、 目前通常有哪些数据分类分级体系？

在2024年10月1日正式实施的最新国家标准 《数据安全技术 数据分类分级规则》（GB/T 43697-2024） 出台后，全国的分类分级有了统一的“度量衡”。通常分为 “横向分类” 和 “纵向分级”：

1. 横向分类（按业务属性和数据主体划分）

分类是为了方便管理，通常企业会将数据分为以下几大类： * 用户数据：客户的身份信息、生物特征、联系方式、交易记录等。 * 业务数据：企业核心业务流转产生的数据（如订单、合同、生产参数、研发图纸）。 * 经营管理数据：财务数据、HR数据、采购数据、战略规划等。 * 系统运行数据：网络日志、安全审计日志、系统配置、密钥信息等。

2. 纵向分级（按数据泄露/篡改后的危害程度划分）

分级是为了决定保护力度（也就是密评和等保的改造成本）。目前主要有两套并行的分级逻辑：

• 逻辑A：法定宏观分级（国标 GB/T 43697-2024 规定）

  • 核心数据：关系国家安全、国民经济命脉等（企业极少涉及，多在国家级基础设施）。
  • 重要数据：一旦泄露/篡改，可能危害国家安全、经济运行、社会稳定或公共利益。（密评重点保护对象，必须采取最高级别密码保护）。
  • 一般数据：危害程度仅限于企业自身或部分个人。一般数据内部通常会再细分为 1级（公开）、2级（内部）、3级（敏感）、4级（极敏感）。

• 逻辑B：个人信息专项分级（《个人信息保护法》规定）

  • 一般个人信息：如姓名、普通浏览记录。
  • 敏感个人信息：如身份证号、人脸指纹、精准定位、金融账户、医疗健康等（一旦泄露容易导致人格尊严受侵害或人身财产安全受危害）。

• 逻辑C：行业特色分级（如金融行业 JR/T 0197）

  • 金融行业通常将数据分为 1级到5级（或公开、内部、敏感、高敏感、极敏感），级别越高，对国密算法（SM2/SM4）的调用要求越严苛。

---

二、 实际实施中，到底由谁来决定？（三方协同机制）

正如您所猜测的，一份合格的《数据分类分级目录》是三方力量共同作用的结果：

1. 国家标准与行业监管 —— “划红线、定基调”

• 作用：提供不可逾越的底线。
• 实操：国家法律和行业标准明确规定了**什么是“重要数据”和“敏感个人信息”**。例如，卫健委明确规定“百万人以上的基因数据、健康档案”属于重要数据；央行明确规定“千万级用户的金融交易流水”属于极敏感数据。
• 约束力：企业**不能**为了降低密评改造成本，强行把国家标准里定义的“重要数据”降级为“一般数据”。一旦监管查处或发生数据泄露，将面临严厉处罚。

2. 企业自身（业务部门 + 安全/IT部门） —— “做盘点、贴标签”

• 作用：将抽象的标准落地到具体的数据库表和字段上。外部专家不可能比企业更懂自己的业务流。
• 实操：
  • **业务部门**负责梳理：我们有哪些业务？产生了哪些字段？这个字段泄露了会对客户和公司造成什么影响？
  • **IT/安全部门**负责映射：把业务部门梳理出的字段，对应到数据库的表名、列名，并利用自动化工具（如数据资产梳理工具）进行打标。
  • 制定企业级细则：在国标框架下，制定适合本企业的《数据分类分级管理细则》。比如，国标说“财务数据是敏感数据”，企业细则里要明确“员工工资单是3级，公司年度未公开财报是4级”。

3. 评审专家与第三方机构 —— “做把关、防风险”

• 作用：纠正企业的“避重就轻”，确保定级合理，并为等保/密评提供背书。
• 实操：
  • 密评/等保测评机构：在测评进场前，专家会审查企业的《分类分级目录》。如果专家发现企业把“用户明文密码”或“核心交易密钥”定级为“一般数据（无需强加密）”，专家会**直接提出整改意见**，甚至判定高风险。
  • 行业监管部门/专家组：对于涉及“重要数据”目录的认定，通常需要上报给行业主管单位（如通管局、金融局、大数据局），由官方组织的专家组进行评审和备案。只有专家认可了你的定级，你的合规体系才算真正闭环。

---

三、 分类分级如何直接指导“密评”与“等保”改造？

做完分类分级后，您就能清晰地知道**钱应该花在刀刃上**，而不是盲目地对所有数据都进行最高级别的国密改造。

数据分级结果	密评/等保 密码应用要求（以三级系统为例）	改造成本与策略
核心/重要数据 极敏感个人信息 (如：用户密码、生物特征、核心交易流水、密钥本身)	必须强制使用合规硬件密码机。 1. 存储：必须使用SM4高强度加密，密钥由密码机管理。 2. 传输：必须国密SSL/TLS加密。 3. 完整性/抗抵赖：必须使用SM2数字签名。	高 必须采购服务器密码机/签名验签服务器，应用代码需深度改造对接API。
敏感数据 (如：手机号、身份证号、普通订单信息)	推荐使用密码技术保护。 1. 存储：建议SM4加密或脱敏存储。 2. 传输：国密HTTPS加密。 3. 访问控制：需严格的身份鉴别。	中 可使用云厂商的合规KMS（密钥管理服务）或软件级国密模块，改造成本适中。
一般数据 (如：公开的产品介绍、系统公开日志)	无强制加密要求。 主要依靠网络边界防护（防火墙）、访问控制等常规安全手段。	低 无需额外采购密码设备，保持现有安全策略即可。

四、 给企业的落地建议

1. 先盘点，后买设备：千万不要在没做数据分类分级之前，就盲目采购一堆国密硬件设备。很可能花大价钱加密了一堆“一般数据”，而真正的“重要数据”却因为业务逻辑复杂还在“裸奔”。
2. 借助自动化工具：现代企业数据量庞大，靠人工Excel梳理是不现实的。建议采购或租赁**数据资产自动发现与分类分级工具**，通过正则表达式、机器学习算法，自动扫描数据库，识别出身份证、手机号、银行卡等敏感字段，并自动打标。
3. 建立动态更新机制：数据分类分级不是一次性的工作。当企业上线新业务、采集新字段，或者国家出台新标准时，必须由**企业安全委员会（联合业务、IT、法务）** 重新评审并更新目录。

总结：数据分类分级是**国家定标准、企业做落地、专家严把关**的共同产物。它是等保和密评的“导航仪”，只有分级做准了，您的国密改造才能既满足合规要求，又兼顾业务性能和改造成本。

USER

姓名算不算敏感数据？有必要对姓名进行去标识化吗？

ASSISTANT

这是一个非常经典且在实际业务中极易引发争议的问题。

直接回答您的疑问： 1. 单独的“姓名”在法律定义上通常不属于“敏感个人信息”，而是属于“一般个人信息”。 2. 是否有必要去标识化（脱敏）？答案是：视“使用场景”而定。在某些场景下必须去标识化，但在数据库底层存储时，通常不需要像密码或身份证号那样进行高强度的加密或去标识化。

为了让您在应对“等保”、“密评”以及《个人信息保护法》（PIPL）合规时更有底气，我们从法律界定、场景实操和测评专家视角三个维度为您详细拆解。

---

一、 法律界定：姓名到底算不算“敏感数据”？

根据我国《个人信息保护法》第二十八条以及国标《个人信息安全规范》（GB/T 35273）的定义： * 敏感个人信息：是一旦泄露或者非法使用，容易导致自然人的人格尊严受到侵害或者人身、财产安全受到危害的个人信息（如：生物识别、宗教信仰、特定身份、医疗健康、金融账户、行踪轨迹等，以及**不满十四周岁未成年人的个人信息**）。 * 一般个人信息：除敏感个人信息外的其他个人信息。

结论： 对于一个成年人来说，单独的“姓名”（如：张三）通常只属于“一般个人信息”。因为仅凭一个名字，很难直接定位到特定的自然人，也很难直接对其人身或财产安全造成严重危害。

⚠️ 但是，有两个重要的“反转”情况： 1. 组合效应（数据拼接）：当“姓名”与“手机号”、“身份证号”、“家庭住址”、“病历”结合存储时，这个**数据包的整体敏感度会急剧上升**，必须按照高敏感度（甚至敏感个人信息）的标准来保护。 2. 特定人群：如果姓名属于**未成年人**、特殊疾病患者、举报人、涉密人员**或**高净值VIP客户，那么该姓名及其关联信息将被直接认定为“敏感数据”，需要采取最高级别的保护措施。

---

二、 实际实施中，有必要对姓名进行去标识化吗？

在数据分类分级和等保/密评落地中，我们不会对所有数据“一刀切”，而是**基于场景**来决定是否去标识化（脱敏）。

1. 前端展示与业务办理场景（必须去标识化）

• 场景：客服系统查看用户列表、外卖小哥查看订单、大屏数据展示、快递面单。
• 做法：必须进行掩码去标识化。例如显示为“张*”、“*三丰”、“张*三”。
• 原因：防止内部员工（如客服、业务员）批量窃取用户信息，或防止外部人员偷窥。这也是《个人信息保护法》中“最小必要”原则的体现。在等保测评中，专家会重点检查前端界面是否存在“明文越权展示”的漏洞。

2. 数据库底层存储场景（通常无需去标识化/强加密）

• 场景：业务系统的关系型数据库（如MySQL/Oracle）底层表结构。
• 做法：通常明文存储即可（或采用轻量级加密），**不需要**使用SM4进行高强度加密，也不需要哈希处理。
• 原因：姓名需要被频繁用于业务检索、模糊查询、关联分析（如“查找所有姓张的客户”）。如果对姓名进行强加密或不可逆的去标识化，将导致业务系统无法正常进行SQL查询，严重影响系统性能。
• 合规替代方案：虽然不加密，但必须在数据库层面做好**访问控制**（谁能连数据库？），并在应用层做好**安全审计**（谁通过API查询了姓名？必须留存日志）。

3. 数据共享、分析与测试环境（必须去标识化/匿名化）

• 场景：将生产数据导给第三方做营销分析、提供给外包团队做开发测试、或者进行跨部门的数据共享。
• 做法：必须进行去标识化（假名化）或匿名化。例如将“张三”替换为“User_89757”。
• 原因：脱离受信环境后，数据泄露风险不可控。等保和密评均严禁将包含真实个人信息的未经脱敏数据直接用于测试环境或违规共享。

---

三、 等保与密评专家是如何审查“姓名”保护的？

如果您正在准备等保三级或密评，测评机构对“姓名”的审查重点与对“用户密码”或“身份证号”是完全不同的：

审查维度	用户密码/私钥（极敏感/鉴别数据）	身份证号/银行卡号（敏感个人信息）	姓名（一般个人信息）
密评要求	**强制**使用国密算法（SM3/SM4），且**必须**由硬件密码机处理，密钥不出域。	**推荐/强制**使用国密算法（SM4）加密存储，传输必须国密SSL加密。	无强制加密要求。重点审查是否与其他敏感信息绑定保护。
等保要求	身份鉴别机制是否合规、防暴力破解。	存储和传输的机密性、完整性保护。	重点审查**访问控制**（权限是否最小化）和**安全审计**（查询日志是否完整）。
前端展示	绝对不可见。	必须掩码脱敏（如 110***1234）。	建议掩码脱敏（如 张*），视业务需求而定。

专家避坑指南： 在等保测评中，如果专家发现您的系统允许一个普通业务员通过后台接口，一次性无限制地导出包含“姓名+手机号”的十万条明文数据，且**没有审计日志、没有数据防泄漏（DLP）拦截**，这会被判定为**高风险项（严重不符合）**，因为这构成了严重的“个人信息泄露隐患”。

---

四、 给企业的落地实操建议

针对“姓名”及类似的一般个人信息，建议企业在架构设计和合规改造时采取以下策略：

1. 分类分级打标：在数据字典中，明确将单独的“姓名”标记为“一般个人信息（2级或3级）”，将“姓名+身份证+手机号”的组合标记为“敏感数据（4级）”。
2. 实施动态脱敏（Dynamic Data Masking）：不要在数据库里把名字改写成“张*”，而是保持数据库明文。在**应用层或数据库代理层**配置动态脱敏规则。当客服账号查询时，API返回“张*”；当超级管理员或核心结算系统查询时，返回“张三”。这样既兼顾了业务，又满足了合规。
3. 强化API审计与限流：针对包含姓名的查询接口，必须接入**API安全网关**或**数据库审计系统**。一旦发现某个账号在短时间内高频调用包含姓名的接口（如爬虫行为），立即触发告警或阻断。
4. 关注特殊群体：在系统设计中，如果业务涉及未成年人（如K12教育、游戏防沉迷），请务必在代码逻辑中将“未成年人姓名”升级为敏感数据级别，采取更严格的加密和访问控制措施。

总结：姓名本身不是“洪水猛兽”，不需要像保护密码那样用国密硬件密码机把它死死锁住。对姓名的保护，核心不在于“加密算法”，而在于“场景化的脱敏展示”和“严格的访问控制与审计”。

USER

为什么未成年人、特殊疾病患者、举报人、涉密人员或高净值VIP客户等的姓名信息为敏感个人信息数据？如果暴露了会存在什么风险？

ASSISTANT

这是一个非常深刻且直指《个人信息保护法》（PIPL）核心立法精神的问题。

在常规认知中，“姓名”只是一个代号（一般个人信息）。但为什么当它属于**未成年人、特殊疾病患者、举报人、涉密人员或高净值VIP客户**时，就会被法律、国家标准（如 GB/T 35273）以及企业合规体系强制认定为**敏感个人信息**？

核心逻辑在于：在这些特定场景下，“姓名”不再是一个简单的文本字段，而是成为了一个“高危身份锚点（Identity Anchor）”。

根据《个人信息保护法》第二十八条的定义，敏感个人信息的判定标准是：“一旦泄露或者非法使用，容易导致自然人的人格尊严受到侵害或者人身、财产安全受到危害。”

如果这些特定人群的姓名暴露，并与他们的特定身份标签产生关联，将引发极其严重的现实风险。以下为您逐一拆解：

---

1. 未成年人（特别是14周岁以下儿童）

• 法律定性：《个人信息保护法》明确规定，不满十四周岁未成年人的个人信息**法定属于敏感个人信息**。
• 姓名暴露的致命风险：
  • 人身安全与拐卖风险：儿童的姓名如果与就读学校、家庭住址、父母信息结合泄露，极易被不法分子用于**精准诱拐、绑架**或冒充熟人诈骗。
  • 网络沉迷与不良诱导：黑灰产获取儿童姓名和年龄后，会精准推送暴力游戏、不良信息，甚至进行网络霸凌。
  • “数字烙印”影响一生：儿童时期的一些负面信息（如成绩差、犯过错、家庭变故）若与真实姓名绑定并在互联网上长期留存，会对其未来的升学、就业和心理健康造成不可逆的“社会性伤害”。

2. 特殊疾病患者（如传染病、精神疾病、遗传病、性病等）

• 法律定性：健康生理信息属于高度敏感个人信息。
• 姓名暴露的致命风险：
  • 严重的社会歧视（社会性死亡）：例如艾滋病、抑郁症、乙肝、梅毒等患者，一旦“姓名+疾病”的清单泄露，患者在职场、社交、婚恋中将面临毁灭性的歧视和排斥，导致其人格尊严严重受损，甚至引发自杀倾向。
  • 精准医疗诈骗：黑产获取“姓名+特定重疾”后，会伪装成“神医”或“特效药代理”进行精准诈骗，骗取患者救命钱，甚至延误正规治疗危及生命。
  • 保险与就业拒保：商业保险公司或用人单位若违规获取此类信息，会进行隐性歧视，拒绝理赔或拒绝录用。

3. 举报人（吹哨人、信访人）

• 法律定性：受《监察法》、《信访工作条例》等严格保护，涉及重大人身安全和隐私。
• 姓名暴露的致命风险：
  • 残酷的打击报复：被举报方（可能是黑恶势力、贪腐人员、违规企业）一旦知晓举报人的真实姓名，极易引发**暴力报复、威胁家属、恶意解雇、甚至暗杀**。
  • 社会监督机制瘫痪：如果举报人姓名轻易暴露，将产生“寒蝉效应”，导致社会正义无人敢于维护。因此，在政务和司法系统中，举报人姓名必须采用最高级别的加密和物理隔离。

4. 涉密人员（军工、科研、国安、核心政务人员）

• 法律定性：受《保守国家秘密法》保护，直接关系国家安全。
• 姓名暴露的致命风险：
  • 境外情报机构定向策反：境外间谍机构获取涉密人员的真实姓名后，会以此为“主键”，顺藤摸瓜挖掘其家庭背景、社会关系、财务状况、性格弱点，进而实施**精准策反、勒索或渗透**。
  • 关键基础设施被破坏：涉密人员往往是国家级核心系统的管理员或研发者，其身份暴露可能导致国家级网络攻击的突破口，威胁国家命脉。

5. 高净值VIP客户（富豪、明星、企业高管）

• 业务定性：虽非法定“敏感”，但在金融/商业场景中，其财产状况、行踪轨迹和身份信息属于高度敏感的商业机密。
• 姓名暴露的致命风险：
  • 精准绑架与敲诈勒索：犯罪分子通过姓名关联到其真实的财富规模、家庭住址、子女就读的贵族学校，极易实施恶性暴力犯罪（如绑架勒索）。
  • 商业间谍与恶意做空：竞争对手获取核心高管或大股东信息，可能进行商业间谍活动、窃取核心机密，或在资本市场上进行恶意做空。
  • 无休止的黑产骚扰：被各类高端理财、非法集资、奢侈品推销团伙精准盯上，严重干扰正常生活。

---

总结与合规启示：数据保护不能“刻舟求剑”

通过上述分析，我们可以得出一个在**数据分类分级**和**密评/等保**中极其重要的实战原则：

数据的敏感度不是由“字段名”决定的，而是由“数据的上下文（Context）”决定的。

• 刻舟求剑的做法：在数据库里，看到“姓名”字段，就一律按“一般数据”处理，不加密、不脱敏。
• 正确的合规做法：
  1. 打标签：在数据字典中，必须给特定人群的数据打上“敏感”标签（如 user_type = 'minor' 或 vip_level = 'black_card'）。
  2. 动态脱敏：当普通客服或外包人员查询这些特定人群的姓名时，系统必须在应用层或API网关层强制进行掩码（如显示为“张*”、“李*”），只有在法务审计或极高层授权时才能查看明文。
  3. 严格审计：对包含这些特定人群姓名的任何查询、导出操作，必须触发最高级别的安全审计日志，一旦发现异常批量拉取，立即阻断并报警。

因此，在进行等保和密评改造时，千万不要低估了“姓名”等看似普通字段在特定业务场景下的破坏力。合理识别这些高危场景，并采取针对性的密码技术（如国密SM4加密存储、SM2签名防篡改）和访问控制策略，才是真正懂合规、懂安全的体现。