等保测评五类数据库核查命令实战手册

简介：这是一份面向等保测评人员、数据库管理员及安全运维人员的实操型作业指导书，覆盖 MYSQL、ORACLE、SQLSERVER、Postgres、Redis 五类主流数据库，适用于等级保护测评现场核查、数据库安全自查及日常运维排查等场景。编写目的很明确：把测评中最常问到的核查项提前整理成可执行的查询命令，避免现场边查边翻手册。文档从实际作业角度出发，给出 CMD、SQLPLUS、MySQL Workbench 等连接登录方法，并按测评项列出密码复杂度与有效期、登录失败处理、超时退出、用户与来源IP限制、审计开关、远程管理加密、终端访问限制等 SQL 查询语句，可直接复制、修改后执行。压缩包内为 1 个 docx 文档，大小 1.83MB，按五类数据库分 PART 组织，目录层级清晰，可快速定位到对应库的核查命令。已有 784 人学习下载，既适合等保测评现场快速查阅，也适合初次接触数据库测评的工程师作为入门参考。

1. 等保测评进场后，最难的不是画拓扑，是五套数据库的核查命令

每次等保测评进场，最耗时间的不是画网络拓扑，而是面对 MySQL、Oracle、SQL Server、Postgres、Redis 五套数据库，每套都要在半天内给出认证、审计、超时、权限的核查结论。很多测评师手里只有等保标准条文，没有能直接落地的查询语句，到了现场一边百度一边写，效率低不说，还容易漏项。

这份数据库等保测评作业指导书 V1.1 解决的就是这个问题。它把五类数据库的常用核查点整理成了可直接执行的命令和判定口径，覆盖密码复杂度、密码有效期、登录失败处理、超时时间、用户权限、审计开关、远程管理加密这些等保要求里的高频检查项。适合三类人：做等保测评的工程师、被抽检的 DBA、想自查的运维。下面的拆解我把每条命令的参数含义和判定口径都过一遍，特别是那些查不到结果时的处理方式。

2. MySQL 核查命令实战：五个查询看清密码、审计与连接控制

2.1 连接方式与信息收集节奏

MySQL 的连接方式有两种，CMD 命令和 Workbench 图形化。命令行连接是测评进场最常用的方式：

mysql -u root -p

-u指定用户名，-p表示接下来输入密码。很多生产环境不允许直接给 root，测评时常见的做法是申请一个只读账号。注意show variables这类命令需要 PROCESS 权限，纯 SELECT 权限查不了，实际中不少测评师还是要了 root 或管理员账号。

Workbench 连接就是图形化操作：打开软件后选 Database → Connect to Database，填 IP、端口、用户名和密码。默认端口 3306，连接前先确认对方开了远程访问权限，否则会报 Host 不允许连接。进场后我习惯先把所有变量查询跑一遍，结果存成文本，后面写报告时直接引用，省得反复连库。

2.2 密码复杂度与密码长度：validate_password 插件的三种返回情况

密码复杂度核查是等保测评里的必查项，命令只有一条：

show variables like 'validate_password%';

这条命令在不同环境下返回三种情况，判定逻辑完全不同。

第一种，直接报错：ERROR 1193 (HY000): Unknown system variable 'validate_password_length'。这说明 validate_password 插件没有安装，数据库确实没有限制密码复杂度和长度，测评结论记为不符合。

第二种，返回validate_password=OFF，说明插件装了但没启用，效果等同于没有限制。

第三种，返回完整参数列表：

validate_password_dictionary_file validate_password_length validate_password_mixed_case_count validate_password_number_count validate_password_special_char_count

validate_password_length是密码最小长度，validate_password_mixed_case_count是大小写字母数量要求，validate_password_number_count是数字数量，validate_password_special_char_count是特殊字符数量。等保参考要求是密码长度不小于 6 位，复杂度至少包含数字、大小写字母、特殊字符中的两种以上。

如果插件缺失，可以用下面的语句装上：

INSTALL PLUGIN validate_password SONAME 'validate_password.so';

提示：插件装好后只对之后新设置的密码生效，存量弱密码不会被强制失效，需要配合ALTER USER ... PASSWORD EXPIRE让旧密码过期。

2.3 密码有效期与登录失败处理：两个层面的参数别混用

密码有效期核查涉及两个参数。查看当前值用：

show global variables like 'default_password_lifetime';

这个参数单位是天，默认值可能是 0（永不过期），等保要求是不大于 90 天。临时整改可以执行：

SET GLOBAL default_password_lifetime = 90;

注意SET GLOBAL只对重启前生效，要固化得写进 my.cnf 配置文件。

登录失败处理要分两个层面看。第一个是主机维度：

show variables like '%max_connect_errors%';

max_connect_errors表示同一主机连接请求失败超过设定次数后，MySQL 会拒绝该主机后续的连接请求。第二个是用户维度，靠 connection_control 插件：

show variables like '%connection_control%';

如果返回空，说明 connection_control 插件没装。装了之后能看到三个参数：

connection_control_failed_connections_threshold是单个用户因密码错误失败的次数上限，默认 3；connection_control_max_connection_delay是失败上限之后再次尝试登录前的最大等待时间；connection_control_min_connection_delay是最小等待时间，默认 1000 毫秒。等保参考要求是登录失败次数不大于 5 次，锁定时间不小于 1 分钟。想要达到这个标准，可以这样设置：

INSTALL PLUGIN connection_control SONAME 'connection_control.so'; SET GLOBAL connection_control_failed_connections_threshold = 5; SET GLOBAL connection_control_min_connection_delay = 60000;

min_connection_delay单位是毫秒，60000 就是 60 秒。

2.4 超时时间与用户权限边界：wait_timeout 默认 8 小时

连接空闲超时是数据库测评里容易忽略的一项。查看命令：

show variables like 'wait_timeout'; show variables like '%timeout';

wait_timeout默认 28800 秒，也就是 8 小时。这个值对等保要求来说偏大了，一般建议不大于 30 分钟。interactive_timeout针对的是交互式连接（mysql 工具、mysqldump），wait_timeout针对非交互式连接。修改方式：

SET GLOBAL wait_timeout = 1800; SET GLOBAL interactive_timeout = 1800;

提示：修改只对之后新建的连接生效，已建立的连接还是沿用旧值，测评时不要改完立刻复查，容易误判。

用户和权限核查用两条语句：

select user, host from mysql.user; select user();

host列是重点。host=192.168.1.1表示只允许该 IP 连接；host=192.168.1.%表示 IP 前缀为 192.168.1 的都能连；host=%表示所有 IP 都可以连接。测评报告里要特别标注有没有高权限账号配了%。查看单个用户的具体权限：

show grants for 'root'@'localhost';

2.5 审计功能核查：三个开关别混为一谈

MySQL 的审计核查有三个开关，很多人容易搞混：

show variables like 'general_log%'; show variables like 'log_bin'; show variables like '%audit%';

general_log记录所有到达 MySQL Server 的 SQL 语句，值 ON 表示开启，这是最直接的审计依据。log_bin记录的是 DDL 和 DML 的二进制日志，主要服务于主从复制和时间点恢复，它不等于审计日志，测评时不能拿 log_bin 当审计已开启的证据。%audit%是审计插件（比如 MariaDB 的 server_audit）的相关参数，查到server_audit_logging=ON才算部署了专业审计。

等保判定口径：general_log=ON或server_audit_logging=ON都能满足审计要求，log_bin不算。

远程管理加密看 SSL：

show variables like '%have_ssl%';

have_ssl=YES表示数据库支持 SSL 加密连接，NO就是不支持。还想确认是否强制远程走加密，看require_secure_transport参数，5.7.5 以上版本才有：

show variables like '%require_secure_transport%';

值为 ON 时所有连接必须走 SSL/TLS，这是比较严格的合规配置。

3. Oracle 测评深挖：dba_profiles 参数状态与审计开关判定

3.1 一条 SQL 看遍口令策略：dba_profiles 的正确读法

Oracle 的口令策略集中在 profile 里，DBA 用户执行：

select * from dba_profiles where profile='DEFAULT';

超时相关的 KERNEL 参数单独查：

SELECT * FROM dba_profiles where resource_type='KERNEL';

返回结果里每个资源项对应一个 LIMIT 值，重点关注这几个参数：

很多生产库的DEFAULTprofile 从来没动过，查出来全是UNLIMITED，这就是典型的"查到了但等于没设置"。整改时可以用：

ALTER PROFILE DEFAULT LIMIT FAILED_LOGIN_ATTEMPTS 5 PASSWORD_LIFE_TIME 90 PASSWORD_LOCK_TIME 1 PASSWORD_VERIFY_FUNCTION verify_function_11G IDLE_TIME 30;

verify_function_11G是 Oracle 自带的密码复杂度脚本，需要先以 DBA 身份执行@?/rdbms/admin/utlpwdmg.sql创建，然后才能引用到 profile 里。

3.2 用户状态机：account_status 里藏着整改线索

用户及状态核查命令：

select username, account_status from dba_users;

Oracle 的用户状态比 MySQL 复杂得多，常见的几种：

OPEN是正常可用状态。LOCKED表示被 DBA 手工锁定。EXPIRED表示口令被设置为到期，用户下次登录时必须修改密码。EXPIRED(GRACE)表示处于宽限期，还能正常登录但系统会提示改密码。LOCKED(TIMED)是登录失败次数超过FAILED_LOGIN_ATTEMPTS被系统自动锁定。还有EXPIRED & LOCKED(TIMED)这种组合状态，是口令到期后用户又连续登录失败被锁。

测评时要重点查有没有scott、outln这类示例账户处于 OPEN 状态，以及是否存在大量EXPIRED账户长期不处理。如果示例账户被锁定了，可以在报告里记为符合，但建议 DBA 直接 drop 掉更干净。

3.3 远程管理与审计开关：show parameter 三连查

远程管理核查看密码文件的使用方式：

show parameter remote_login_passwordfile;

EXCLUSIVE是独占模式，允许客户端以 SYSDBA/SYSOPER 权限远程登录，也允许授予和回收这两个权限，这是默认值。NONE表示禁用口令文件验证，禁止远程 SYSDBA 登录。SHARED允许远程登录但不能修改权限。

审计核查：

show parameter audit; show parameter audit_sys_operations;

audit_trail的值决定了审计开没开：db或true表示启用并把审计结果写到 sys.aud$ 表；os表示启用并写入操作系统文件；db_extended和xml是增强模式；none或false是禁用。等保要求audit_trail不为 none/false，且audit_sys_operations（审计 SYSDBA 活动）为 TRUE。audit_trail=db时要注意 sys.aud$ 表会持续膨胀，生产环境建议配合定期清理策略。

3.4 sqlnet.ora 限制终端接入：黑白名单配置与生效条件

Oracle 限制终端 IP 访问靠的是 sqlnet.ora 文件里的三个参数：

TCP.VALIDNODE_CHECKING=yes TCP.EXCLUDED_NODES=(192.168.56.101) TCP.INVITED_NODES=(127.0.0.1,192.168.190.60,192.168.190.61)

TCP.VALIDNODE_CHECKING=yes是启用检查的总开关，必须为 yes 才生效。TCP.EXCLUDED_NODES是黑名单，TCP.INVITED_NODES是白名单，同时配置时白名单优先。

文件位置：Windows 在ORACLE_HOME\network\admin目录下，Linux 同样在$ORACLE_HOME/network/admin。改完之后需要重启监听才生效，很多人配置完不重启监听，测试半天发现还是老样子。核查的时候如果发现配置已改但连接还是能进来，先怀疑监听没重载。

4. SQL Server、Postgres 与 Redis：三种不同形态的核查方式

4.1 SQL Server：从 SSMS 图形化到系统视图的核查

SQL Server 的密码策略核查在图形化界面里是右键用户 → 属性 → 勾选"强制实施密码策略"和"强制密码过期"。但写报告不能只截界面图，要用系统视图确认：

SELECT name, is_policy_checked, is_expiration_checked FROM sys.sql_logins;

is_policy_checked=1对应"强制实施密码策略"，is_expiration_checked=1对应"强制密码过期"。这两个字段只对 SQL 登录账号生效，Windows 登录账号查出来没有参考意义。

SQL Server 没有 MySQL connection_control 那种用户级登录失败锁定机制，它依赖 Windows 的帐户锁定策略。核查时要先确认CHECK_POLICY已开启，再配合 Windows 安全选项里的"帐户锁定阈值"，一般建议不超过 5 次，锁定时间不低于 30 分钟。

超时退出方面，SQL Server 没有 wait_timeout 的等价参数，常见做法是查远程超时相关配置：

SELECT * FROM sys.configurations WHERE name LIKE '%remote%timeout%';

remote login timeout默认 10 秒，remote query timeout默认 600 秒。如果要实现空闲会话自动断开，SQL Server 原生没有这个参数，一般靠登录触发器或定时任务杀会话，测评时如实记录。

用户权限列表：

SELECT name, type_desc FROM sys.server_principals WHERE type IN ('S','U');

审计核查查两个视图：

SELECT name, is_enabled FROM sys.server_audits; SELECT name, is_disabled FROM sys.server_audit_specifications;

返回空说明没配正规审计。如果要整改，可以创建审计对象：

CREATE SERVER AUDIT Audit_Login TO FILE (FILEPATH = 'D:\SQLAudit\') ON FAILURE CONTINUE; CREATE SERVER AUDIT SPECIFICATION Audit_Spec_Login FOR SERVER AUDIT Audit_Login ADD (FAILED_LOGIN_GROUP); ALTER SERVER AUDIT Audit_Login WITH (STATE = ON);

远程访问核查：

EXEC sp_configure 'remote access';

SQL Server 对终端 IP 限制没有 sqlnet.ora 那样的原生配置文件，常见做法是登录触发器判断来源 IP，或者靠防火墙。触发器核查用：

SELECT name, is_disabled FROM sys.server_triggers;

触发器里通常用EVENTDATA()提取ClientHost字段做判断，is_disabled=0表示触发器处于启用状态。

4.2 Postgres：配置文件驱动的核查项

Postgres 核查先看版本和用户：

select version(); select usename, rolvaliduntil from pg_authid;

rolvaliduntil是密码过期时间，infinity表示永不过期，这对应等保里的"密码有效期"核查项。只要看到 infinity 就得记不符合，整改方法是给用户设定具体过期时间：

ALTER ROLE test_user VALID UNTIL '2026-01-01';

密码复杂度方面，Postgres 默认不自带校验逻辑，需要预加载 passwordcheck 扩展：

show shared_preload_libraries;

如果返回结果里看不到 passwordcheck，说明数据库没有密码复杂度校验，测评结论只能是不符合。这个扩展要写进shared_preload_libraries并重启数据库才能生效。

登录失败次数限制，Postgres 同样没有内置参数，常见做法是用 fail2ban 监控日志并对来源 IP 做锁定。核查时看 postgresql.conf 里有没有相关配置，没有就记录为依赖外部控制手段。

审计核查看三个参数：

show logging_collector; show log_statement; show log_directory;

logging_collector=on是日志收集的总开关，log_statement可选none/ddl/mod/all，测评要求至少达到ddl以上。超时相关参数：

show statement_timeout; show idle_in_transaction_session_timeout; show tcp_keepalives_idle;

statement_timeout单位是毫秒，0 表示不限制；idle_in_transaction_session_timeout是空闲事务超时，默认 0；tcp_keepalives_idle是 TCP 心跳间隔，默认 0 表示走系统默认值。

4.3 Redis：一条 CONFIG 命令背后的九个测评点

Redis 的命令核查比较特殊，因为它返回的是运行时配置，很多参数跟 MySQL、Oracle 不是一个套路。连接方式：

redis-cli -h 127.0.0.1 -p 6379 -a '密码'

-a后面直接跟密码会留在 shell history 里，核查时更推荐先连上再执行AUTH 密码。

密码复杂度核查：

CONFIG GET requirepass

返回空字符串表示免密访问，这在高风险环境里属于重大不符合。Redis 本身不强制密码强度，所以长度和复杂度要靠人工判断，等保要求远程连接必须设置高强度密码。

登录失败与超时：

CONFIG GET timeout CONFIG GET tcp-keepalive

timeout是空闲 N 秒后关闭连接，0 表示不关闭，等保建议不大于 1800 秒。登录失败锁定 Redis 没有内置参数，生产环境靠 fail2ban 或类似机制实现，这条要在报告里写清楚是外部补偿措施。

鉴别信息传输核查：

CONFIG GET tls-port CONFIG GET port

port=6379且tls-port=0表示走的是明文 TCP，密码在传输过程中可被嗅探。整改可以开 TLS 端口或者在前面加一层加密隧道。

保护模式和访问控制：

CONFIG GET protected-mode CONFIG GET bind

protected-mode=yes且没有设置密码时，Redis 只允许本机回环地址连接。bind配置决定监听哪些网卡，如果bind 0.0.0.0加上requirepass为空，属于高危配置，必须记为不符合。

权限最小化核查：

CONFIG GET rename-command ACL LIST

Redis 6 引入了 ACL，可以用ACL SETUSER给不同用户分配不同命令权限。rename-command可以把高危命令改名或禁用：

rename-command FLUSHALL "" rename-command CONFIG ""

这里有个典型的自锁坑：CONFIG 命令被改名后，想通过CONFIG GET查看配置就做不到了。改之前务必先把该查的都查完，或者直接改 redis.conf 后重启生效。

审计核查：

CONFIG GET logfile CONFIG GET loglevel

Redis 没有传统数据库的审计日志，只能靠运行日志和 slowlog 做补偿。logfile返回空字符串表示输出到标准输出，建议指向固定文件；loglevel建议在 notice 以上。

数据完整性和保密性：

CONFIG GET save CONFIG GET appendonly

appendonly=yes表示 AOF 持久化开启，配合 RDB 快照可以满足数据完整性要求。数据保密性方面 Redis 本身不做字段级加密，库文件加密要靠磁盘级方案，核查时如实记录即可。

4.4 三个库的核查差异小结

5. 避坑记录：五种数据库核查时的典型翻车现场

5.1 MySQL 查 validate_password 报错，直接下"无策略"结论

现象：执行show variables like 'validate_password%'直接报ERROR 1193，于是测评结论写成"未限制密码复杂度和长度"。

原因：validate_password 插件没有加载。5.7 默认不装，8.0 社区版是内置但可能没启用，查询报错只能说明插件不存在，不能说明策略没配。

解决：先执行show plugins确认插件状态。缺失就INSTALL PLUGIN validate_password SONAME 'validate_password.so'装上，再重新查询。如果插件存在但参数为 OFF，要在配置文件中启用，而不是口头跟客户说"查不到"。

5.2 Oracle dba_profiles 全是 UNLIMITED，结果被漏报

现象：select * from dba_profiles where profile='DEFAULT'返回几十行，LIMIT 列全是 UNLIMITED，PASSWORD_VERIFY_FUNCTION 是 NULL，报告里这句就跳过了。

原因：生产库从没人动过 DEFAULT profile，Oracle 原生的默认值就是 UNLIMITED，这是常态而不是异常。

解决：UNLIMITED 就是不符合，逐项记入整改建议，并给出 ALTER PROFILE 语句。补 verify_function 要先执行@?/rdbms/admin/utlpwdmg.sql脚本，否则 ALTER PROFILE 会报函数不存在。

5.3 拿 log_bin=ON 当 MySQL 审计已开启

现象：报告里写"MySQL 已开启审计"，依据是log_bin=ON。

原因：把二进制日志和审计日志混为一谈。log_bin 的目的是主从复制和基于时间点恢复，它不记录查询语句，也不是为了追溯用户行为设计的。

解决：审计判定只看general_log=ON或server_audit_logging=ON。如果只有 log_bin，记为不符合，整改建议是开启 general_log 或部署审计插件，并说明 log_bin 可以保留但不算审计证据。

5.4 SQL Server 勾选"强制实施密码策略"后查出来还是 0

现象：SSMS 界面勾选了强制实施密码策略，客户也说配了，但sys.sql_logins查出来is_policy_checked=0。

原因：这个字段只对 SQL Server 登录账号有意义，如果是 Windows 登录账号，勾选不生效；还有一种可能是当时走了界面但脚本没执行成功。

解决：用显式语句整改并复查：

ALTER LOGIN test_user WITH CHECK_POLICY = ON, CHECK_EXPIRATION = ON;

另外 SQL Server 的登录失败锁定不是勾选策略就完事，还要去 Windows 安全策略里配置"帐户锁定阈值"，两个配合才算是完整的失败处理措施。

5.5 Redis 执行 rename-command 后把自己锁在门外

现象：按整改要求执行CONFIG SET rename-command CONFIG ""，想再查配置时提示命令不存在，管理端直接失联。

原因：CONFIG 命令被禁用后，运行时已经无法再通过 CONFIG 查看和修改任何配置，这是设计内的"自杀式"操作。

解决：改之前先把所有要查的配置项跑完，留存输出；生产环境不要用运行时CONFIG SET改 rename-command，直接编辑 redis.conf 后重启，并预留一个不受限制的管理通道。Redis 6 之后如果混用CONFIG SET requirepass和 ACL，容易误以为所有用户都设了密码，检查时ACL LIST要逐个用户确认权限范围。

6. 把查询结果变成测评记录：归档与判定口径统一的落地习惯

测评报告最怕的不是结论严苛，而是同一个核查项在不同数据库里用了两套判定标准。我的做法是进场后先跑一遍汇总脚本，把每个库的原始输出一次性导出来存档。

#!/bin/bash # mysql 等保核查信息汇总 mysql -u root -p -e " show variables like 'validate_password%'; show variables like 'default_password_lifetime'; show variables like '%max_connect_errors%'; show variables like '%connection_control%'; show variables like 'wait_timeout'; show variables like 'general_log%'; show variables like 'log_bin'; show variables like '%audit%'; show variables like '%have_ssl%'; select user, host from mysql.user;"

这段脚本把 MySQL 的核心核查项一次跑完，输出保存为文本文件，直接作为报告附件。Oracle、PostgreSQL、Redis 同理，先汇总再逐项判定。

最后是统一判定口径。比如"审计开启"这一项，MySQL 认general_log或 audit 插件，Oracle 认audit_trail不为 none/false，SQL Server 认存在启用的 server_audit，Postgres 认logging_collector=on且log_statement至少为 ddl，Redis 认 logfile 指向固定文件且 loglevel 不低于 notice。口径不一致的话，报告前后会自相矛盾，客户一问就露馅。

从那以后我每次进场，第一件事就是把这套汇总查询完整跑一遍，原始输出统一命名存档，然后再开始逐项判定和截图。这个习惯帮我省掉了大量和客户扯皮的时间——所有结论都有命令和输出兜底，而不是现场手敲临时拼凑。希望帮到你。

本文还有配套的精品资源，点击获取