安全审计

a) 应启用安全审计功能，审计覆盖到每个用 户，对重要的用户行为和重要安全事件进行审计

1)执行命令“show global variables like '%general%';”默认为OFF，不符合。应设置为ON为开启审计。

2）访谈管理员是否通过第三方插件收集审计数据进行分析。

b) 审计记录应包括事件的日期和时间、用户、事件类型、事件是否成功及其他与审计相关的信息

1)是否已开启审计general_log为ON。执行命令“select * from general_log;”查看具体内容。

2)核查是否部署第三方工具（数据库审计系统）增强MySQL日志功能。记录第三方审计工具的审计内容，查看是否包括事件的日期和时间、用户、事件类型、事件是否成功及其他与审计相关的信息。

c) 应对审计记录进行保护，定期备份，避免受到未预期的删除、修改或覆盖等

应保证各个管理员尽可以访问与自身相关的日志日志文件，其中，错误日志仅root用户可以访问日志文件。

1)访谈管理员对审计记录如何保护，对审计记录是否定期备份，备份策略。

是否采取了备份、转存等手段对审计记录进行保护，避免未预期的删除、修 改或覆盖，数据库本地日志保存时间超过6个月。采用第三方数据库审计产品，审计记录保存时间超过6个月。

2)是否严格限制用户访问审计记录的权限，可以通过普通用户登录然后是否能够访问修改删除日志。

d) 应对审计进程进行保护，防止未经授权的中断

1)询问是否严格限制管理员、审计员权限，查看非root账户，能否中断审计进程。

2)用户重启实例关闭审计功能，查看是否成功

（大多数情况默认判定为符合）

入侵防范

a)应遵循最小安装的原则，仅安装需要的组件和应用程序；

（数据库系统判定为不适用）

b)应关闭不需要的系统服务、默认共享和高危端口；

（数据库系统判定为不适用）

c) 应通过设定终端接入方式或网络地址范围对通过网络进行管理的管理终端进行限制

查看用户登录的IP地址;是否给所有用户加上IP限制，拒绝所有未知主机进行连接，当user表中的Host值不为localhost时,应指定特定IP地址，不应为%；或将user表中的Host值为空，而在host表中指定用户账户允许登录访问的主机IP，使在非信任的客户端（其他地址）以数据库账户登录时被拒绝访问。

执行命令“show grants for root@localhost;”查看用户登录的IP地址；是否给所有用户加上IP限制，拒绝所有未知主机进行连接。

d)应提供数据有效性检验功能，保证通过人机接口输入或通过通信接口输入的内容符合系统设定要求；

（数据库系统判定为不适用）

e) 应能发现可能存在的已知漏洞，并在经过充分测试评估后，及时修补漏洞

访谈MySQL补丁升级机制，查看补丁安装情况:

1)执行命令"show variables where variable_name like 'version';"或“show variables where variable_name like '%version%';”查看当前补丁版本;

2)访谈管理员是否定期进行漏洞扫描，并对高风险漏洞是否测试评估后进行修复。

可信验证

可基于可信根对计算设备的系统引导程序、系统程序、重要配置参数和应用程序等进行可信验证，并在应用程序的所有执行环节进行动态可信验证，在检测到其可信性受到破坏后进行报警，并将验证结果形成审计记录送至安全管理中心，并进行动态关联感知。

（目前此测评项直接判定为不符合，有的测评机构判不适用，个人觉得不应该判定为不适用）

数据完整性

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

传输过程中的完整性一般是通过通信协议来实现的，常见的包括TLS、SSH等协议，对数据而言，查看是否启用了SSL进行了数据通信，同时询问下管理人员，确认是否还有其他保证数据传输过程中的完整性措施。

（本地管理判定为不适用，远程管理根据实际情况判定）

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

对数据库配置文件进行一个完整性检测，需要配置文件初始可信状态时的哈希值，然后再根据目前的文件生成一个哈希值，对比前后的一致性，确认数据是否被篡改过，根据了解一般数据库自身不带这种机制，询问管理人员是否使用了第三方软件对数据库重要数据进行了完整性校验。

数据保密性

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

此处主要针对鉴别信息（其他像业务数据、审计数据和配置数据一般情况未加密）传输相关的参数大致有下类三个：

SCRAM-SHA-256属于挑战-响应架构， 可防止密码在不可信连接上嗅探，并支持以密码散列的形式将密码存储在服务器上， 这种形式被认为是安全的。

MD5使用自定义安全性较低的质询-响应机制。 它可以防止密码嗅探，并避免以纯文本形式将密码存储在服务器上， 但如果攻击者设法从服务器窃取密码哈希，则不提供保护。（MD5哈希算法现在不再被认为是安全的算法）

若password是以明文密码传送给数据库，建议不在生产环境中使用。若数据库未开启SSL时，我通过Wireshare对数据库认证过程的数据包进行抓取，可能发现传输的密码字段信息。

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

MySQL提供的数据加密方案中包括AES加解密方案AES_ENCRYPT AES_DECRYPT，DES加解密方案DES_ENCRYPT DES_DECRYPT。

数据备份恢复

a)应提供重要数据的本地数据备份与恢复功能；

访问管理员配置数据、审计数据、业务数据的备份策略，检查备份策略的备份情况与管理员所说是否一致，是否具有恢复测试记录。

另外可以通过数据库管理工具进行备份，如navicat、mysqldump 等工具，工具具备 MySQL 自带的逻辑备份。它的备份原理是通过协议连接到 MySQL 数据库，将需要备份的数据查询出来，将查询出的数据转换成对应的insert 语句，当我们需要还原这些数据时，只要执行这些 insert 语句，即可将对应的数据还原。

b)应提供异地实时备份功能，利用通信网络将重要数据实时备份至备份场地；

部署异地备份机房，并符合备份策略通过网络定期进行异地备份。

c)应提供重要数据处理系统的热冗余，保证系统的高可用性；

集群部署、双机热备均可判定为符合。

剩余信息保护

a)应保证鉴别信息所在的存储空间被释放或重新分配前得到完全清除；

一般情况下数据库系统内核层默认无法实现剩余信息保护功能，需要第三方工具才能实现。

b)应保证存有敏感数据的存储空间被释放或重新分配前得到完全清除。

一般情况下数据库系统内核层默认无法实现剩余信息保护功能，需要第三方工具才能实现。

个人信息保护

a)应仅采集和保存业务必需的用户个人信息；

检查数据库中是否存储个人信息，若有，检查个人信息保护机制和个人信息保护管理制度

b)应禁止未授权访问和非法使用用户个人信息。

检查个人信息保护机制和个人信息保护管理制度，验证非授权人员是否可以访问个人信息存储的相关组件内容。