# 18、安全计算环境之数据完整性与保密性测评

> 安全计算环境之数据完整性与保密性测评：完整性与保密性定义、8.1.4.7 与 8.1.4.8 逐字母项测评方法、数据存储与传输的完整性算法（MD5/SHA-1/SHA-2/SHA-3/HMAC/CRC32）与保密性算法（AES/SM4/3DES/RSA/ECC/SM2）强度分析、口令存储保密性算法口径、核查命令与判定标准，附版本适用性对照表与测评项对照表。

---

LLMS index: [llms.txt](/wikis/llms.txt)

---

> 定位：安全计算环境「数据完整性（8.1.4.7）」与「数据保密性（8.1.4.8）」两个控制点的测评理解与判定口径。
> 配套测评：[01、Oracle数据库测评](../../系统管理软件平台/01oracle数据库测评/)、[04、Windows服务器测评记录](../../服务器/04windows服务器测评记录/)（RDP 判据）；
> 配套加固：[17、加固方案总纲](../../../reinforce/其他系统或设备/17网络设备安全设备服务器数据库和应用系统的加固方案/)；高风险口径：[22、高风险判定指引与加固对照表](../../../reinforce/其他系统或设备/22高风险判定指引与加固对照表/)。
> 适用：GB/T 22239-2019 安全计算环境数据完整性与保密性；三级系统的传输与存储两侧均须取证。
>
> 使用说明：
>
> - 本文所有命令均为**只读取证**命令，不修改配置、不重启服务、不执行清除类操作；确需变更由被测单位运维方在授权下实施。
> - 命令回显本身即证据，须连同命令行一起截图；示例中的地址、账户、路径均为演示值，现场须替换为真实取证结果，并对个人信息与内网管理地址脱敏后再入报告。
> - 命令不存在或输出与示例差异较大时，先确认产品版本与部署形态（物理机/虚拟机/容器/集群），再换用等效命令或转入配置文件、管理控制台取证，**不得据命令缺失直接判不符合**。
> - 文中「默认」「一般」等表述均为**初判倾向**，须经上机核查 + 访谈 + 配置/制度核对三方印证后定论，并在报告中写明取证来源。
>
> 不适用标识说明：
>
> - 使用 `【不适用】` 明确标记现场可判定为不适用的控制点，并写明判定依据与承载该能力的上位组件。
> - 依据 GB/T 28448-2019「按测评对象实际承载功能与数据处理范围判定」原则：控制能力由上层应用、统一认证平台、前置代理、堡垒机、日志审计系统、虚拟化平台或云托管平台承载时，应注明测评单元边界后判定不适用或转由上位组件核查，不得机械按缺失判不符合。
> - 产品版本确实不提供该能力（如设备无可信根、社区版无审计模块）时，须核查替代措施并按替代措施的实际效果定档，不得直接判不适用。

## 一、定义

### 1.1 完整性

通俗的来说就是数据不被篡改和非授权访问。目前完整性主要是通过哈希算法来实现。
国密算法中，能够提供数据完整性的算法主要是：**SM3**。国际算法中，能够提供数据完整性的算法主要是：**MD5、SHA256、SHA512**。

> 注：MD5 已被攻破（可构造碰撞），**不宜作为完整性校验算法**，
> 现场发现使用 MD5 时应按"部分符合 + 整改建议（改用 SM3 或 SHA-256 及以上）"表述。

### 1.2 保密性

通俗的来说就是数据不能是明文，目前保密性主要是通过加密算法来实现。
国密算法中，能够提供数据保密性的算法主要是：**SM1、SM2、SM4、SM9、ZUC（祖冲之）**
（其中 SM4 常用于无线局域网与数据加密，SM1/SM7 多以芯片形态提供）。
国际算法中，能够提供数据保密性的算法主要是：**DES、3DES、RSA、AES、ECC** 等。

> 注：DES 与 3DES 已被列为不安全算法，现场出现时应要求升级为 AES/SM4。

## 二、数据的完整性测评

> **对应控制点**：GB/T 22239-2019 8.1.4.7 数据完整性 a)b)
>
> **判定要点**：传输侧对鉴别数据、重要业务数据、重要审计数据、重要配置数据采用校验技术或密码技术保护且不可降级；存储侧有哈希基线、校验字段或完整性监控并定期比对 → 符合；仅传输侧保护、或校验参数可协商降级、或仅个别配置文件有基线 → 部分符合；传输与存储均无完整性保护 → 不符合。
>
> **取证要求**：传输协议与加密/校验参数截图、抓包结果（脱敏）、完整性算法与密钥长度清单、哈希基线文件与比对记录、第三方完整性监控（FIM/HIDS）说明与告警。

a)应采用校验技术或密码技术保证重要数据在传输过程中的完整性，包括但不限于鉴别数据、重要业务数据、重要审计数据、重要配置数据、重要视频数据和重要个人信息等；

测评理解：重点有3个,1校验技术或密码技术；2传输过程中的完整性；3包括不仅限于鉴别数据、重要业务数据、重要审计数据、重要配置数据、重要视频数据和重要个人信息等。

先一个个来看：

01、校验技术其实很好理解，就是类似TCP协议的CRC校验码或者海明校验码等，这是协议层面的，如果按照这要求利街，那么这条指标基本全部符合，所以目前测评难点不是在这里，而是在密码技术如何实现完整性，这里是一个容易弄混的的知识点，可能大部分人有疑惑，密码技术不是i用来加密的吗，怎么能用来保证完整性呢?其实在商用密码中，密码算法分为加密算法和哈希算法两大类，其中哈希算法常见是MD5和SHA系列，哈希算法也属于密码算法，所以通过密码技术完全可以实现完整性校验。

02、传输过程中的完整性，传输过程中的完整性主要通过协议来实现，比如TLS、SSH协议，通过MAC（消息校验码）来实现整个数据报文的完整性和加密性，无论报文本身内容是否进行加密和哈希校验，这个应该比较好理解把，因此，测评中，如果采用TLS协议、SSH协议，默认其实应该是符合传输过程中的完整性要求的。

03、重要数据的理解，主要数据包括鉴别数据、审计数据、业务数据等。

b)应采用校验技术或密码技术保证重要数据在存储过程中的完整性，包括但不限于鉴别数据、重要业务数据、重要审计数据、重要配置数据、重要视频数据和重要个人信息等。

操作系统的存储过程完整性。操作系统鉴别数据主要就是用户名、口令、组ID等。其中WindowsNT中默认采用SAM文件保存鉴别信息，其中口令字段采用SHA哈希算法进行加密。而在Linux中，口令保存shadow文件中，口令也是采用SHA哈希算法进行加密，主要有三类：$1表示MD5 ; $6 表示SHA-512 ; $5 SHA-256。可能在这里大家有疑惑，为什么不采用加密算法对口令加密，而采用哈希算法进行加密？个人觉得原因主要有2个：1是加密算法分为对称加密算法和非对称加密算法，无论哪种，都需要安全的保存密钥，这就导致鸡生蛋和蛋生鸡的问题，2加密算法时间长，哈希算法时间较短。因此，操作系统的数据传输过程的完整性要求中默认是符合的。

至于业务数据、审计数据存储过程中的完整性，主要是核查数据库表（业务数据、审计数据）是否存在哈希字段，在业务数据或审计数据中，数据在前端一般通过json或xml格式进行传输，那么数据的完整性应该是核查相关数据库表字段中是否包含完整性校验字段。目前测评项目中极为少见，一般均为不符合，印象中好像只有个一个系统实现存储过程中的完整性校验。但是如果通过TLS、SSH等协议，可以通过传输过程中的完整性在一定程度上弥补存储过程中的完整性。

其实在开发过程中，技术方面进行哈希校验并不难，因为常见开发语言均内置哈希函数，比如php的hash()、java的hashcode()等，但是问题重点在主流开发语言目前少于内置SM3等国密哈希算法，随着商密应用的测评，日后要求支持国密的哈希算法估计会成为测评要求判定之一，当然商密局官网有现成的php、java、c++源代码库下载，可以用来在开发项目中直接调用。

## 三、数据的保密性测评

> **对应控制点**：GB/T 22239-2019 8.1.4.8 数据保密性 a)b)
>
> **判定要点**：鉴别数据以强算法加盐存储（不存在 LM/NTLMv1、明文口令、DES/MD5 等已废弃算法），重要业务数据与个人信息在传输与存储环节采用密码技术保护，密钥管理可控 → 符合；仅传输侧加密而存储侧明文、或加密算法强度不足、或密钥与密文同机存放 → 部分符合；鉴别数据使用弱算法或重要数据全程明文 → 不符合。
>
> **取证要求**：口令存储格式与算法查询输出、磁盘/文件系统加密配置（BitLocker/LUKS/dm-crypt）、应用侧或数据库侧加密配置、证书与密钥管理截图、算法清单与选型说明、抓包结果（脱敏）。

<div class="alert alert-warning" role="alert"><div class="h4 alert-heading" role="heading">高风险提示</div>


重要业务数据与个人信息明文存储且无任何加密措施，或鉴别数据使用已废弃弱算法，属高风险线索；密钥与密文同机同目录存放导致加密形同虚设时同样记录。

判定口径详见 [22、高风险判定指引与加固对照表](../../../reinforce/其他系统或设备/22高风险判定指引与加固对照表/)。

</div>


a)应采用密码技术保证重要数据在传输过程中的保密性，包括但不限于鉴别数据、重要业务数据和重要个人信息等；

传输过程中的保密性测评中，这个比较简单，主要核查是否采用TLS、SSH等加密协议，其中常见的问题主要集中在以下两个地方：

1）Windows远程桌面RDP是否符合传输过程中的保密性？笔者查过相关资料，Windows的RDP安全主要有安全层和加密级别两个参数，其中安全层有RDP安全层、协商和TLS1.0共3个值，其中默认值是协商。

![](/wikis/_resources/18%E3%80%81%E5%AE%89%E5%85%A8%E8%AE%A1%E7%AE%97%E7%8E%AF%E5%A2%83%E4%B9%8B%E6%95%B0%E6%8D%AE%E5%AE%8C%E6%95%B4%E6%80%A7%E4%B8%8E%E4%BF%9D%E5%AF%86%E6%80%A7%E6%B5%8B%E8%AF%84/89e51d55d4179062c190f8ba6e574951_MD5.jpg)

如下图所示:

![](/wikis/_resources/18%E3%80%81%E5%AE%89%E5%85%A8%E8%AE%A1%E7%AE%97%E7%8E%AF%E5%A2%83%E4%B9%8B%E6%95%B0%E6%8D%AE%E5%AE%8C%E6%95%B4%E6%80%A7%E4%B8%8E%E4%BF%9D%E5%AF%86%E6%80%A7%E6%B5%8B%E8%AF%84/e62e11692f8232fe33d64712d6d95bfc_MD5.jpg)

![](/wikis/_resources/18%E3%80%81%E5%AE%89%E5%85%A8%E8%AE%A1%E7%AE%97%E7%8E%AF%E5%A2%83%E4%B9%8B%E6%95%B0%E6%8D%AE%E5%AE%8C%E6%95%B4%E6%80%A7%E4%B8%8E%E4%BF%9D%E5%AF%86%E6%80%A7%E6%B5%8B%E8%AF%84/3a629e2b01358a327c56773a6ba69876_MD5.jpg)

![](/wikis/_resources/18%E3%80%81%E5%AE%89%E5%85%A8%E8%AE%A1%E7%AE%97%E7%8E%AF%E5%A2%83%E4%B9%8B%E6%95%B0%E6%8D%AE%E5%AE%8C%E6%95%B4%E6%80%A7%E4%B8%8E%E4%BF%9D%E5%AF%86%E6%80%A7%E6%B5%8B%E8%AF%84/465f7f9075c1b78b3545919de909893b_MD5.jpg)

加密级别也主要有4个值可选，分别是低、客户端兼容、高和符合FIPS标准，区别主要是加密算法.

![](/wikis/_resources/18%E3%80%81%E5%AE%89%E5%85%A8%E8%AE%A1%E7%AE%97%E7%8E%AF%E5%A2%83%E4%B9%8B%E6%95%B0%E6%8D%AE%E5%AE%8C%E6%95%B4%E6%80%A7%E4%B8%8E%E4%BF%9D%E5%AF%86%E6%80%A7%E6%B5%8B%E8%AF%84/3c4bee6d2b7f5ead0ae473b2472108ba_MD5.jpg)

![](/wikis/_resources/18%E3%80%81%E5%AE%89%E5%85%A8%E8%AE%A1%E7%AE%97%E7%8E%AF%E5%A2%83%E4%B9%8B%E6%95%B0%E6%8D%AE%E5%AE%8C%E6%95%B4%E6%80%A7%E4%B8%8E%E4%BF%9D%E5%AF%86%E6%80%A7%E6%B5%8B%E8%AF%84/92854caa0f1b977c125c21f07899de9b_MD5.jpg)

由此可知，其实在WindowsServer2008及以上系统，默认RDP就支持加密，差别就是加密长度和加密算法不同，至于采用何种算法，网上也没有统一的答案，抓包也没有发现，猜测可能是RC-4，如果是Windows10客户端连接WindowsServer2008,默认配置下使用的是TLSV1.0协议进行加密，如下图：

<div class="alert alert-warning" role="alert"><div class="h4 alert-heading" role="heading">RDP 默认加密不等于符合：TLS 1.0 与 RC4 均已被禁用</div>


原文"默认 RDP 就支持加密，因此传输保密性默认符合"的结论需要修正：

- **TLS 1.0/1.1 已于 2021 年被主流浏览器与操作系统（含 Windows）禁用**，多个行业标准亦不再接受；
- **RC4 已被 RFC 7465 明确禁止用于 TLS**；
- 等保测评中，使用 TLS 1.0 或 RC4 的远程管理通道应判**部分符合**并要求整改至 **TLS 1.2 及以上**。

现场应核查 RDP 的"安全层"是否设置为 **SSL(TLS 1.0)/协商 → 强制 TLS 1.2**（组策略或注册表
`HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp` 下的
`SecurityLayer`=2、`MinEncryptionLevel`=3），并用抓包确认实际协商版本。
</div>


![](/wikis/_resources/18%E3%80%81%E5%AE%89%E5%85%A8%E8%AE%A1%E7%AE%97%E7%8E%AF%E5%A2%83%E4%B9%8B%E6%95%B0%E6%8D%AE%E5%AE%8C%E6%95%B4%E6%80%A7%E4%B8%8E%E4%BF%9D%E5%AF%86%E6%80%A7%E6%B5%8B%E8%AF%84/04f1184de0569f4a25ed3213aea8c74b_MD5.jpg)

b)应采用密码技术保证重要数据在存储过程中的保密性，包括但不限于鉴别数据、重要业务数据和重要个人信息等。

存储过程中的保密性这个就比较简单了，主要是核查相关账户的口令、业务数据、审计数据是否加密存储，无论使用是何种加密算法，只要非明文，这条就符合，实践中，操作系统鉴别数据全部符合，默认都是使用哈希算法，业务系统的鉴别数据，这个一般核查下数据库表，部分系统可能仍然是明文存储，至于业务数据、审计数据之类基本实践中未见过使用加密存储，一来没有必要，二来会影响性能，所以一般不符合。d但是如果使用数据库加密功能，默认该项为符合，数据库加密 主要分库内加密和库外加密，库内加密主要是调用的数据库本身的加密功能，比如MSSQLSERVER的TDE功能、Oracle的DBMS_CRYPTO，有兴趣的可以自己百度，库外加密主要通过第三方厂家的数据库加密功能，为了避免推销，这里就不举例了。

## 四、数据传输与存储完整性、保密性算法分析

> **对应控制点**：GB/T 22239-2019 8.1.4.7 数据完整性 a)b)、8.1.4.8 数据保密性 a)b)
>
> **判定要点**：传输环节采用校验或密码技术且算法与密钥长度满足现行要求（不使用 SSLv3/TLS 1.0/1.1、RC4、3DES、MD5、SHA1 签名证书），存储环节有哈希基线或加密措施，密钥管理可控 → 符合；协议版本或算法强度不足、可协商降级、仅部分链路加密 → 部分符合；传输存储均无保护或使用已废弃算法 → 不符合。
>
> **取证要求**：协议版本与密码套件实测输出（`openssl s_client`、抓包 ClientHello/ServerHello）、证书链与签名算法、加密配置与密钥管理截图、哈希基线与比对记录、算法选型说明。

<div class="alert alert-warning" role="alert"><div class="h4 alert-heading" role="heading">高风险提示</div>


仍启用 SSLv3/TLS 1.0/TLS 1.1 或 RC4/3DES/DES/EXPORT 等已废弃算法，或证书链不完整、使用 MD5/SHA1 签名、RSA 密钥长度不足 2048 位，导致传输数据可被降级或离线破解，属高风险线索。

判定口径详见 [22、高风险判定指引与加固对照表](../../../reinforce/其他系统或设备/22高风险判定指引与加固对照表/)。

</div>


### 4.1 数据存储完整性算法
1. 校验和（Checksum）：校验和是一种简单的完整性算法，通过对数据进行算术运算生成一个固定长度的校验值。接收方可以在接收数据后重新计算校验和，并与发送方的校验和进行比较，以验证数据的完整性。
2. 哈希函数（Hash Function）：哈希函数将任意长度的数据映射为固定长度的哈希值。哈希值是唯一的，即使输入数据发生微小的变化，哈希值也会发生很大的变化。接收方可以使用相同的哈希函数对接收到的数据进行计算，并与发送方的哈希值进行比较，以验证数据的完整性。
3. 循环冗余校验（CRC）：CRC是一种通过多项式除法来计算校验值的算法。发送方将数据和计算得到的校验值一起发送，接收方可以通过使用相同的多项式除法算法对接收到的数据进行计算，并将计算得到的校验值与发送方的校验值进行比较，以验证数据的完整性。
4. 数字签名（Digital Signature）：数字签名使用公钥密码体系，结合哈希函数和非对称密钥算法来实现数据的完整性和认证。发送方使用私钥对数据进行签名，接收方使用发送方的公钥对签名进行验证，从而确保数据的完整性和发送方的身份。

### 4.2 数据传输完整性算法
1. 循环冗余校验（CRC）：CRC算法也可以用于数据传输的完整性验证。发送方在数据中添加一个CRC校验值，接收方收到数据后使用相同的算法计算CRC校验值，并将计算得到的值与发送方的校验值进行比较，以验证数据的完整性。
2. 哈希函数（Hash Function）：哈希函数可以用于数据传输完整性的验证。发送方使用哈希函数对数据进行计算，生成一个固定长度的哈希值，并将该哈希值发送给接收方。接收方在接收到数据后使用相同的哈希函数计算哈希值，并将计算得到的哈希值与发送方的哈希值进行比较，以验证数据的完整性。
3. 消息认证码（Message Authentication Code，MAC）：MAC是一种使用共享密钥的算法，用于验证数据传输的完整性和认证。发送方使用密钥对数据进行加密生成MAC值，并将MAC值与数据一起发送给接收方。接收方使用相同的密钥对接收到的数据进行加密，并将计算得到的MAC值与发送方的MAC值进行比较，以验证数据的完整性和发送方的身份。
4. 数字签名（Digital Signature）：数字签名也可以用于数据传输的完整性验证。发送方使用私钥对数据进行签名，将签名和数据一起发送给接收方。接收方使用发送方的公钥对签名进行验证，从而验证数据的完整性和发送方的身份。

### 4.3 数据传输保密性算法
1. 对称加密算法：对称加密算法使用相同的密钥对数据进行加密和解密。常见的对称加密算法包括AES（高级加密标准）、DES（数据加密标准）和3DES（三重数据加密算法）等。发送方使用密钥对数据进行加密，接收方使用相同的密钥进行解密，以保护数据的机密性。
2. 非对称加密算法：非对称加密算法使用一对密钥，包括公钥和私钥。发送方使用接收方的公钥对数据进行加密，接收方使用自己的私钥进行解密。常见的非对称加密算法包括RSA（Rivest-Shamir-Adleman）和ECC（椭圆曲线加密算法）等。非对称加密算法通常用于密钥交换和数字签名。
3. 混合加密算法：混合加密算法结合了对称加密算法和非对称加密算法的优势。发送方使用非对称加密算法对对称密钥进行加密，并将加密后的对称密钥与数据一起发送给接收方。接收方使用私钥解密对称密钥，然后使用对称密钥对数据进行加密和解密。这种方法同时提供了数据的机密性和安全密钥的交换。
4. VPN（Virtual Private Network）：VPN是一种建立安全通信通道的技术，通过使用加密协议和隧道技术，将数据在传输过程中进行加密和解密，以保护数据的机密性。常见的VPN协议包括IPSec（Internet Protocol Security）和SSL/TLS（Secure Socket Layer/Transport Layer Security）等。

### 4.4 数据存储保密性算法
1. 对称加密算法：对称加密算法可以用于在数据存储时对数据进行加密。常见的对称加密算法包括AES（高级加密标准）、DES（数据加密标准）和3DES（三重数据加密算法）等。使用对称加密算法，数据在存储之前进行加密，存储在安全的存储介质上，只有授权的用户拥有解密密钥才能解密数据。
2. 文件级加密：文件级加密是一种将整个文件进行加密的方法。文件级加密可以应用于单个文件或整个存储设备上的文件。在文件级加密中，文件在存储时进行加密，并且只有在解密密钥的授权下才能访问和查看文件内容。
3. 数据库加密：数据库加密是一种在数据库存储过程中对数据进行加密的方法。数据库加密可以通过对整个数据库进行加密，或者对特定字段进行加密。这可以确保即使数据库被未经授权的访问或泄露，数据仍然是加密的。
4. 分区加密：分区加密是一种将存储设备分成多个加密区域的方法。每个区域都有自己的加密密钥，只有在解密密钥的授权下才能访问该区域的数据。分区加密可以应用于硬盘驱动器、闪存设备等存储介质。
5. 去标识化（De-identification）：去标识化是一种将敏感数据中的个人标识信息删除或替换为伪造的值的方法。这样可以保护数据的机密性，同时保留数据的可用性和有效性。去标识化通常应用于需要进行数据分析或共享的场景。

### 4.5 口令（密码）存储保密性算法
1. 哈希函数加盐存储：哈希函数是将密码转换为固定长度的哈希值的算法。为了增加密码的安全性，通常会将密码与一个随机生成的盐值进行组合，再通过哈希函数进行计算。将计算得到的哈希值和盐值一起存储，以保护密码的机密性。
2. 密码加密存储：密码加密存储是将密码使用对称加密算法进行加密后存储的方法。只有具有解密密钥的授权用户才能解密密码。常见的对称加密算法如AES（高级加密标准）可以应用于密码加密存储。
3. 彩虹表：彩虹表是一种用于破解密码存储的密码破解技术。为了防止彩虹表攻击，可以在存储密码时使用盐值并应用多次哈希函数计算。通过增加计算复杂度，可以防止彩虹表攻击。
4. 密码哈希函数（Password Hashing Function）：密码哈希函数是专门为密码存储而设计的哈希函数。与一般的哈希函数不同，密码哈希函数通常使用特定的算法和技术，如迭代哈希、密钥扩展和盐值等，以提高密码的安全性。
5. 双向加密存储：双向加密存储是一种将密码使用非对称加密算法进行加密后存储的方法。发送方使用接收方的公钥加密密码并存储，接收方使用私钥解密密码进行验证。这种方法同时提供了密码的机密性和数据的完整性。

## 五、核查命令与判定标准

### 5.1 传输过程完整性与保密性

```bash
# 确认实际协商的协议与套件（Web/HTTPS 服务）
openssl s_client -connect <host>:443 -servername <host> < /dev/null 2>/dev/null \
  | grep -E "Protocol|Cipher|Verify return code"

# SSH 服务端协商的算法
ssh -vvv <host> 2>&1 | grep -iE "kex|cipher|mac"

# 数据库链路（以 MySQL 为例）
# mysql> show variables like '%ssl%';
```

```powershell
# Windows RDP 安全层与加密级别
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' |
  Select-Object SecurityLayer, MinEncryptionLevel, UserAuthentication
# SecurityLayer=2（协商 SSL）、MinEncryptionLevel=3（高强度）、UserAuthentication=1（要求 NLA）
```

**判定标准（传输完整性/保密性 a)）**

| 结论 | 条件 |
|---|---|
| 不适用 | 管理通道与业务数据均不跨网络（纯本地） |
| 符合 | 使用 TLS 1.2 及以上 / SSHv2，无 `NULL`/`EXPORT`/RC4/DES/3DES 弱套件 |
| 部分符合 | 使用 TLS 1.0/1.1 或含 RC4 等弱套件（如默认 RDP 配置） |
| 不符合 | 明文传输鉴别数据或重要业务数据（HTTP/Telnet/FTP） |

### 5.2 存储过程完整性与保密性

**鉴别数据（操作系统侧）**

```bash
# Linux：shadow 第二字段前缀标识算法
#   $1 = MD5（弱）  $5 = SHA-256  $6 = SHA-512  $y = yescrypt（部分新发行版）
#   ! 或 * = 账户锁定/不可登录；空 = 空口令（直接不符合）
awk -F: '{print $1, substr($2,1,3)}' /etc/shadow
```

```powershell
# Windows：口令哈希受 SAM 与 SYSKEY 保护；核查是否禁用 LM、是否启用 LSA 保护
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' |
  Select-Object NoLMHash, RunAsPPL, LmCompatibilityLevel
# NoLMHash=1（不存 LM 哈希）、RunAsPPL=1（LSA 保护）、LmCompatibilityLevel≥3
```

**业务数据与审计数据（数据库侧）**

```sql
-- MySQL：口令存储插件与 TLS 配置
select user, host, plugin from mysql.user;
show variables like '%ssl%';
-- 期望：plugin 为 caching_sha2_password / sha256_password；避免 mysql_native_password
```

**判定标准（存储完整性/保密性 b)）**

| 结论 | 条件 |
|---|---|
| 符合 | 鉴别数据经 SHA-256/SHA-512/SM3 等合规哈希（加盐）或更强机制存储；重要业务/审计数据有加密或完整性校验字段 |
| 部分符合 | 鉴别数据仅做哈希但算法为 MD5/LM；或业务数据未加密但传输侧有加密补偿 |
| 不符合 | 鉴别数据或重要业务数据明文存储 |

> 实践口径：操作系统鉴别数据（Linux shadow、Windows SAM）**默认即为符合**；
> 业务系统的鉴别数据需查数据库表，部分系统仍明文存储 → 不符合；
> 业务数据与审计数据的存储加密实践中极少见，通常判不符合，
> 但启用数据库 TDE 或字段级加密的应判符合。

## 六、版本适用性对照

| 对象 | 版本差异 | 判据要点 |
|---|---|---|
| Windows RDP | Server 2008 默认 TLS 1.0；2008R2+ 支持 TLS 1.2（需补丁与配置）；2012R2+/Win10+ 原生支持 TLS 1.2 | 默认配置按**部分符合**处理，须整改至 TLS 1.2 并强制 NLA |
| Windows 口令哈希 | XP/2003 存 LM 哈希（极弱）；Vista+ 默认禁 LM；Win10+ 支持 Credential Guard | 仍存 LM 哈希直接判不符合 |
| Linux shadow | 老发行版 `$1` MD5；RHEL6+/Debian 8+ `$6` SHA-512；部分新发行版 `$y` yescrypt | `$1` 判部分符合，须升级哈希算法并重设口令 |
| MySQL | 5.7 默认 `mysql_native_password`；8.0 默认 `caching_sha2_password`；8.4 起 `mysql_native_password` 默认禁用 | 出现 `mysql_native_password` 应提示升级 |
| 通用 | TLS 1.0/1.1 已于 2021 年被主流实现禁用；RC4 被 RFC 7465 禁止 | 出现即部分符合，整改至 TLS 1.2+ |

## 测评项对照表

| 控制点 | 核查要点 |
|---|---|
| 数据完整性 a) | 传输通道使用 TLS/SSH 等带 MAC（消息校验码）的协议，实际协商版本与套件合规 |
| 数据完整性 b) | 存储侧是否有哈希/校验字段、数字签名或 WORM 防篡改；重要数据与审计数据重点核查 |
| 数据保密性 a) | 鉴别数据、重要业务数据、个人信息在传输中加密；**RDP 默认 TLS 1.0 需整改** |
| 数据保密性 b) | 鉴别数据哈希加盐存储（SHA-256/512、SM3）；业务数据加密（TDE/字段加密/透明加密） |

## 参考依据

- GB/T 22239-2019《信息安全技术 网络安全等级保护基本要求》（8.1.4.7 数据完整性 a)b)、8.1.4.8 数据保密性 a)b)）：[http://openstd.samr.gov.cn/bzgk/gb/newGbInfo?hcno=BAFB47E8874764186BDB7865E8344DAF](http://openstd.samr.gov.cn/bzgk/gb/newGbInfo?hcno=BAFB47E8874764186BDB7865E8344DAF)
- GB/T 28448-2019《信息安全技术 网络安全等级保护测评要求》（测评对象边界认定、单元测评实施与结果判定：符合/部分符合/不符合/不适用）：[http://openstd.samr.gov.cn/bzgk/gb/newGbInfo?hcno=7E736CDF4502B6FF1258DD250AA3EC8C](http://openstd.samr.gov.cn/bzgk/gb/newGbInfo?hcno=7E736CDF4502B6FF1258DD250AA3EC8C)
- GB/T 22240-2020《信息安全技术 网络安全等级保护定级指南》、GB/T 25070-2019《安全设计技术要求》、GB/T 28449-2018《测评过程指南》，可在全国标准信息公共服务平台检索：[http://openstd.samr.gov.cn/bzgk/gb/](http://openstd.samr.gov.cn/bzgk/gb/)
- OpenSSL 官方文档入口：[https://docs.openssl.org/](https://docs.openssl.org/)
- OWASP Cryptographic Storage Cheat Sheet：[https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html)
- NIST SP 800-63B·Digital Identity Guidelines（口令长度与存储口径）：[https://pages.nist.gov/800-63-3/sp800-63b.html](https://pages.nist.gov/800-63-3/sp800-63b.html)
- 《网络安全等级保护测评高风险判定指引》（中关村信息安全测评联盟团体标准）——高风险情形判定口径，站内对照表：[22、高风险判定指引与加固对照表](../../../reinforce/其他系统或设备/22高风险判定指引与加固对照表/)
- 命令核验说明：算法强度与现行口径以 OpenSSL 官方文档、OWASP Cryptographic Storage Cheat Sheet 与 NIST SP 800-63B 核验（核验日期 2026-09-02）。五处须留意：① **MD5 与 SHA-1 已不满足完整性保护的现行要求**——MD5 存在实际碰撞攻击、SHA-1 已于 2017 年被实证碰撞（SHAttered），二者仅可用于非安全场景的重复文件比对，不得作为 8.1.4.7 的符合性证据；② 完整性保护若需防篡改（对抗有密钥需求的攻击者），须使用 HMAC 或数字签名而非裸哈希，裸哈希在攻击者可同时改写数据与哈希时失效；③ 保密性方面 3DES（有效强度 112 位）、RC4、DES 已废弃，AES 建议 128 位以上并优先 GCM/CCM 等 AEAD 模式（同时提供完整性），CBC 模式须另配 HMAC；④ 口令存储须使用加盐的慢哈希（bcrypt/scrypt/Argon2 或 PBKDF2 高迭代次数），SHA-256 加盐单次散列不满足现行口径；⑤ 国密场景下 SM3 对应哈希、SM4 对应分组密码、SM2 对应非对称，判定强度须参照国家密码管理部门现行商用密码标准而非直接套用国际算法结论。

## 关联文章

- [HTTPS 加密流量解析技术分析](../../其他系统或设备/23https加密流量解析技术分析/)
- [中间件与容器板块（TLS 配置取证）](../../中间件与容器/)
- [Linux 操作系统测评命令速查（磁盘加密与哈希基线）](../../服务器/16linux操作系统测评命令/)
- [Windows 主机测评（BitLocker 与 NTFS 权限）](../../服务器/20windows主机测评/)
- [数据库测评篇（口令散列与字段加密）](../../系统管理软件平台/12mysql测评命令/)
- 板块目录：[数据资源](/wikis/docs/gradeprotection/%E6%95%B0%E6%8D%AE%E8%B5%84%E6%BA%90/)
- 通用加固方案：[17、加固方案总纲](../../../reinforce/其他系统或设备/17网络设备安全设备服务器数据库和应用系统的加固方案/)
- 取证记录模板：[16、安全评估加固记录表3.0](../../../reinforce/其他系统或设备/16安全评估加固记录表3.0/)
- 高风险判定口径：[22、高风险判定指引与加固对照表](../../../reinforce/其他系统或设备/22高风险判定指引与加固对照表/)