企业官网建设流程全解析

简介：面向等保测评工程师、数据库管理员及安全运维人员，一套覆盖MYSQL、ORACLE、SQLSERVER、Postgres、Redis五类主流数据库的等保测评作业指导书，系统梳理每种数据库的连接登录方式、测评基本查询语句及相关安全配置核查项，可直接用于日常安全配置核查与测评作业落地。资源包共1个文件，为docx格式文档，容量1.83MB，内容按数据库类型划分五大章节，结构清晰便于查阅。文档针对密码复杂度、密码有效期、登录失败处理、超时退出、用户权限、审计策略、远程管理加密及终端IP限制等核心检查项，逐一给出具体查询语句与操作路径，并覆盖测评中的高频检查点，能有效减少现场排查时间。目前已有785人学习使用，适合需要快速上手等保测评数据库核查、提升作业效率的从业者参考。

1. 等保测评数据库查证：一份可直接抄的作业指导书，覆盖五种库

等保测评数据库这块，新手最容易翻车的地方不是不懂等级保护标准，而是不知道该往数据库里敲哪条 SQL，敲完又不知道返回结果怎么对应到测评项。这份覆盖 MySQL、Oracle、SQLServer、Postgres、Redis 的数据库等保测评作业指导书，把五类数据库的连接方式和核查语句都列全了，密码复杂度、有效期、登录失败锁定、超时退出、审计开关、远程管理限制，每条语句后面还带判定参考值。适合刚接手等保测评项目的工程师，也适合驻场运维自查整改时直接照着执行。

2. MySQL 等保测评九连查：从密码复杂度到审计日志的完整语句链

MySQL 是测评里出现频率最高的库，因为部署门槛低、实例多。指导书里把 MySQL 的测评点拆成粒度很小的查询语句，每一句都能直接在命令行执行，下面按测评项顺序展开。

2.1 连接登录：CMD 与 Workbench 两条路

测评的第一步是连上数据库。指导书给了两种方式，我实际用下来 CMD 方式最快：

mysql -u root -p

这条命令会提示输入密码，root 是测试账号，实际测评时替换成被测评方提供的具有查询权限的账号。连上之后，下面的核查语句就都能跑了。

图形化方式是用 MySQL Workbench，打开后选 Database -> Connect to Database，填 IP、端口、用户名和密码。这里有个容易被忽略的点：Workbench 连接时默认走的是交互式会话，查 wait_timeout 时要注意交互式和非交互式的区别，否则会拿错参数值去写报告。

2.2 密码策略四件套：复杂度、有效期、登录失败、超时

密码复杂度是等保第三级的基本要求，核查语句是：

show variables like 'validate_password%';

如果返回空，说明数据库没装 validate_password.so 插件，也就是没做复杂度限制，测评可以直接判不符合。如果返回了参数，重点看四个值：validate_password_length 是密码最小长度，mixed_case_count 是大小写字母数量要求，number_count 是数字要求，special_char_count 是特殊字符要求。等保参考要求是密码长度不小于 6 位且包含数字、大小写字母、特殊字符合计至少两类，所以这四个值组合起来要能满足"两类以上"的判定。

密码有效期看 default_password_lifetime：

show global variables like 'default_password_lifetime';

这个参数单位是天，参考要求是不大于 90 天。注意它是全局参数，MySQL 8.0 之后还可以对单个用户设置，测评时全局值不满足时，还要看看有没有针对特权账号单独设过，避免漏判。

登录失败处理措施要查两个地方。第一个是 max_connect_errors：

show variables like '%max_connect_errors%';

这个参数限制的是同一主机连接失败的次数，侧重防扫描爆破，不是严格意义的账号锁定。真正做账号锁定的是 connection_control 插件：

show variables like '%connection_control%';

如果返回空，说明插件没装。装了的场景下，connection_control_failed_connections_threshold 是单个用户登录失败次数上限，默认 3 次；connection_control_min_connection_delay 是失败后的等待时间，默认 1000ms。等保参考值是失败不大于 5 次、锁定时间不小于 1 分钟，所以要注意阈值和延迟时间的组合是否满足。

超时时间在 MySQL 里有好几个，最常被问的是空闲超时：

show variables like 'wait_timeout';

wait_timeout 默认 28800 秒，也就是 8 小时，参考值通常是不大于 30 分钟，默认值基本不符合。连带着还要看 interactive_timeout，交互式连接（mysql 工具、mysqldump）走的是它，wait_timeout 管的是非交互式连接（JDBC、PHP 这类）。测评时两个都要查，经常出现只改了 wait_timeout 没改 interactive_timeout 的情况。

2.3 用户列表与登录 IP：最小权限怎么查

用户核查的核心语句是：

select user, host from mysql.user;

这条语句把每个账号和允许登录的 IP 范围全部列出来。host 列的理解很关键：192.168.1.1 表示只允许从这个 IP 来，192.168.1.% 表示允许从整个 192.168.1.0 网段来，% 表示所有 IP 都能连。测评时如果发现有账号 host 是 %，且账号本身是高权限，基本可以记为越权风险。

想看某个账号的权限粒度，用：

show grants for root@localhost;

输出里能看到 GRANT ALL PRIVILEGES 还是只授权了 SELECT、INSERT 等具体权限。实际测评中不少 MySQL 实例的运维账号直接给 ALL PRIVILEGES，但业务其实只需要读写几张表，这就是权限过大的证据。另外，select user(); 可以查当前登录用户，确认测评时用的身份。

2.4 审计开关与 SSL：General_log、log_bin 和 have_ssl

审计核查是数据库测评的重头戏。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（不含 SELECT），值为 ON 说明已开启。audit 开头的变量是审计插件，server_audit_logging 为 ON 才算启用了第三方审计。许多 MySQL 实例只开了 log_bin，没开 general_log，也没装 audit 插件，这种情况测评组一般只能判"部分符合"，需要整改。

远程管理加密这块：

show variables like '%have_ssl%';

这条语句查的是 MySQL 是否编译并启用了 SSL 支持，返回 YES 说明支持，NO 说明不支持。注意这只是"服务器支持"，还得看客户端连接时实际走没走 SSL。用 status 命令能看到当前会话的 SSL 状态，显示 Not in use 时，即使服务器开了 SSL，连接也可能没加密，这一点在评审时容易被追问。

3. Oracle 测评：profile 参数、账号状态与 sqlnet.ora 白名单

Oracle 的测评点和 MySQL 完全不是一个路子。MySQL 靠 show variables，Oracle 靠数据字典视图 dba_profiles 和 dba_users。上手之前先说连接。

3.1 sqlplus 连接：本地无密码登入与远程口令文件

Oracle 本地测评最常用的方式：

sqlplus / as sysdba

这条命令利用操作系统认证，不需要输密码，前提是当前系统用户属于 dba 组。测评时用这个方式连本地库最快，不会因为密码问题卡住。远程连接则用：

conn sys/口令 as sysdba

远程用 sysdba 登录是否成功，受 remote_login_passwordfile 参数控制。这个参数有三个值：EXCLUSIVE 是独占模式，允许远程以 sysdba 登录，且支持增删 sysdba 账号；NONE 是禁用口令文件验证，禁止远程 sysdba 登录；SHARED 允许多实例共享口令文件，但禁止增删 sysdba 账号。测评参考值是 EXCLUSIVE，如果业务上不需要远程 DBA 管理，配置成 NONE 反而更安全。

3.2 dba_profiles 一把梭：失败锁定、有效期、空闲超时

Oracle 的密码策略全部配置在 profile 里，默认叫 DEFAULT。一条语句把所有关键参数都查出来：

select * from dba_profiles where profile='DEFAULT';

如果只想看跟时间相关的内核参数，可以加过滤条件：

select * from dba_profiles where resource_type='KERNEL';

返回结果里重点关注六列。failed_login_attempts 是登录失败次数上限，参考值 3-5 次，显示 UNLIMITED 就是没限制。password_lock_time 是失败后锁定天数，建议 5 分钟以上。password_life_time 是密码有效期，建议不大于 90 天。password_grace_time 是宽限期。password_reuse_time 和 password_reuse_max 是密码重用限制，两个必须配合设置。password_verify_function 是密码复杂度校验函数，为 NULL 表示没启用复杂度验证。

这里我踩过坑：dba_profiles 查出来 resource_name 是 IDLE_TIME 的那行，resource_type 是 KERNEL，但许多人只跑了一条不带过滤的语句，把 IDLE_TIME 漏了。空闲超时是等保的显式核查项，建议不大于 30 分钟，务必确认 IDLE_TIME 不为 UNLIMITED。

3.3 dba_users 账号状态：OPEN 到 LOCKED(TIMED) 怎么看

用户状态的核查语句是：

select username, account_status from dba_users;

状态值值得一个个弄清楚，因为评定的时候要准确描述账号当前处于什么状态。OPEN 表示可用；LOCKED 是 DBA 手工锁定；EXPIRED 是密码到期，下次登录必须改密码；LOCKED(TIMED) 是连续失败次数超过 failed_login_attempts 被系统自动锁定；EXPIRED(GRACE) 表示处于宽限期。等保测评关注的主要是两点：默认示例账户（scott、outln、ordays 等）是否存在且可用，理论上应不存在或处于锁定状态；是否存在长期 EXPIRED 但没有处理的账号。

实际测评中很多 Oracle 实例装好之后 scott 一直是 OPEN 或者处于卡在宽限期的状态，这类账号即使没造成实际危害，在报告里也要记为默认账户未清理。另外，dba_users 里的 created 列可以顺带确认是否存在近期新建的可疑账号。

3.4 审计参数与 sqlnet.ora 白名单

Oracle 审计核查的关键参数：

show parameter audit;

输出结果里主要看 audit_trail 和 audit_sys_operations。audit_trail 的值常见的有 DB、OS、DB_EXTENDED、XML，只要不是 NONE 或 FALSE 就算开了基础审计；audit_sys_operations 是是否审计 sysdba 管理员操作，参考要求是 TRUE。

远程访问限制的核查方式不是 SQL，而是看配置文件 sqlnet.ora。文件位置在 Windows 和 Linux 下都在 ORACLE_HOME\network\admin 目录。需要确认是否有如下配置：

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

注意几点：TCP.VALIDNODE_CHECKING 必须设为 yes，否则白名单不生效；INVITED_NODES 是白名单，EXCLUDED_NODES 是黑名单，两套配置不要同时写混；白名单里要把 127.0.0.1 写上，否则本地连接也会被拒；修改 sqlnet.ora 之后要执行 lsnrctl reload 让监听重读配置，只改文件不 reload 的话，复测时依然会被认定为未生效。

4. SQL Server 与 Postgres：图形界面与配置文件各占一半的测评路径

这两款数据库测评路径差异很大。SQL Server 很多核查项在 SSMS 图形界面里直接看，Postgres 则要靠配置文件加 SQL 混合确认。

4.1 SQL Server 本地登录与密码策略核查

SQL Server 本地测评直接打开 SSMS，用 Windows 身份验证或 SQL Server 身份验证登录实例。第一个核查项是密码复杂度策略和密码有效期：在 SSMS 对象资源管理器中展开"安全性"->"登录名"，右键需要核查的登录名选"属性"，能看到"强制实施密码策略"和"强制密码过期"两个复选框。

密码策略对应 Windows 的密码复杂度要求，密码过期对应密码有效期。等保要求密码策略开启、密码过期开启。这里有个常见坑：SQL Server 的密码策略其实是继承操作系统安全策略的，如果 Windows 服务器本身没启用密码复杂度，SQL Server 里即使勾了"强制实施密码策略"，实际强度也达不到预期。测评时我习惯顺手看一眼操作系统的 secpol.msc 密码策略配置，把它作为辅助证据链。

4.2 SQL Server 用户权限与审计状态查询

用户列表和权限的核查，我习惯用 SQL 查询而不是纯靠界面点选：

select name, type_desc, create_date, is_disabled from sys.server_principals where type_desc in ('SQL_LOGIN', 'WINDOWS_LOGIN');

这条语句把服务器级登录账号列出来，is_disabled 字段能区分账号是否被禁用。数据库级用户则查：

select dp.name, dp.type_desc, dp.is_fixed_role from sys.database_principals dp where dp.type in ('S','U','G');

权限明细可以继续查 sys.database_permissions，但测评阶段通常到"账号是否存在、是否被禁用、是不是 sysadmin 固定角色"就够出报告了。

SQL Server 审计核查，我一般看三块：服务器是否启用 audit（SSMS 的"安全性"->"审核"下查看是否配置了 AUDIT 对象且处于开启状态）；登录审核是否记录失败和成功登录；是否存在扩展事件会话。执行下面的语句能确认实例的审计配置：

select name, is_enabled from sys.server_audits;

4.3 Postgres 连接方式与关键配置核查

Postgres 测评首先要知道版本和当前用户：

select version(); select usename from pg_user; select current_user;

密码有效期核查，指导书里的思路是直接看用户的密码期限属性，实际执行中我用：

select usename, valuntil from pg_user;

valuntil 为 null 表示永不过期，等保要求密码有效期不大于 90 天，如果查询结果里大部分账号都是 null，基本要整改。

登录失败次数限制，Postgres 默认走的是 pg_hba.conf 的认证配置，本身没有一个独立的"失败 N 次锁 M 分钟"参数。核查时看两个地方：pg_hba.conf 里认证方式是否为 scram-sha-256 或 md5；以及是否配置了连接失败延迟。常用核查命令：

show password_encryption;

输出结果是 scram-sha-256 或 md5，较新的等保要求是使用 scram-sha-256，因为 md5 已经能被离线破解。密码复杂度核查在 Postgres 里没有内置插件，通常依赖扩展或 shared_preload_libraries：

show shared_preload_libraries;

如果返回空，说明没有加载密码校验相关扩展，密码复杂度这条可以按未启用记。时间相关参数里重点看 idle_in_transaction_session_timeout 和 statement_timeout：

show idle_in_transaction_session_timeout; show statement_timeout;

这两个参数默认值都是 0，表示不限制，等保要求会话超时时间不大于 30 分钟，所以 0 是不符合的，要整改成具体分钟数。

4.4 审计开关：logging_collector 与日志落盘确认

Postgres 审计的核查重点是日志收集是否开启：

show logging_collector; show log_directory; show log_destination;

logging_collector 为 on 且 log_destination 配置了 stderr 或 csvlog，说明系统在持续记录日志。日志里是否包含每条 SQL 的完整语句，取决于 log_statement 参数，参考要求是至少设置为 ddl 或 mod。改 postgresql.conf 之后要执行 pg_reload_conf() 或者重启实例，这个步骤经常被忘，导致配置文件和内存值不一致。

5. Redis 测评避坑：保护模式、权限分离与拿不到证据的三个翻车点

Redis 是所有测评对象里最容易出"假证据"的一个，不少安全参数不重启不生效，或者改了配置没持久化，测评时查内存里拿到的是旧值。这一章先把核查语句走一遍，再讲我踩过的三个坑。

5.1 Redis 连接与密码复杂度核查

Redis 测评先要连上实例：

redis-cli -h 127.0.0.1 -p 6379

连上后核查密码：

config get requirepass

requirepass 返回空表示没设置密码。设置密码的命令是：

config set requirepass "口令"

注意 config set 只在内存里生效，不写入 redis.conf，重启就丢了。要持久化，需要打开 redis.conf 找到 requirepass 一行，去掉注释并改成实际口令。按等保要求，密码复杂度至少包含大小写字母和数字等两类以上组合，口令长度不少于 8 位。如果 AUTH 密码只写了 123456，复杂度这条直接判不符。

5.2 保护模式、登录失败策略与权限分离

保护模式是 Redis 的高频考点：

config get protected-mode

protected-mode 为 yes 时，Redis 只接受本机回环地址连接，拒绝外部访问，这是安全状态。如果为 no，表明允许外部直接连接，在未正确配置 requirepass 的情况下，这几乎等于裸奔，入侵防范这条大概率不符合。

登录失败策略在 Redis 里并没有像关系型数据库那样的现成参数，Redis 本身不提供连续失败锁定，通常靠 Redis 6.0 之后的 ACL 或外层防火墙实现。核查时我一般看 ACL 列表：

ACL LIST

ACL LIST 输出每个用户和权限。默认只有一个 default 用户，拥有所有权限，测评时看到这种情况且业务未做 ACL 拆分，就记为权限过大。进一步用：

ACL GETUSER default

如果 categories 里是 +@all 且没有限制命令，就是典型的权限过大，权限最小化和权限分离都没做到。

5.3 数据完整性与保密性核查

数据完整性主要看持久化配置：

config get save config get appendonly

appendonly 为 yes 表示开启 AOF 持久化，save 参数表示 RDB 快照的触发条件，比如 save 900 1 表示 900 秒内至少有 1 次写操作就落盘。两个参数组合起来才能判断持久化策略是否满足。

数据保密性看网络层是否加密。Redis 默认是明文 TCP，远程连接时等保要求数据传输采用加密协议或加密措施。Redis 6.0 之后支持 tls-port 参数：

config get tls-port config get port

如果 tls-port 为空且 port 是默认 6379，说明远程通信是明文。如果 Redis 只在本机使用，这一项可以按不适用处理，但要在报告里留说明。

5.4 三个踩坑记录：审计、超时与重启丢配置

第一个坑是审计证据拿不到。现象：config get 查不到任何审计相关参数，报告里只能写"未开启审计"。原因：Redis 本身没有原生的 SQL 审计，很多部署方靠的是日志输出到 syslog 或者外部采集。解决：核查 logfile 参数和 redis.conf 里的 loglevel，确认日志是否单独落盘；如果日志打到系统日志里，就把 /var/log 下对应输出文件的轮转策略一并截图，作为审计证据链的一部分。

第二个坑是超时检查分不清连接空闲和命令空闲。现象：config get timeout 返回 0，测评方认为没有超时退出。原因：Redis 的 timeout 参数 0 代表关闭，但部署方如果在 redis.conf 里设置了 timeout 300，且客户端启用了 TCP keepalive，连接不一定会被 Redis 主动断开。解决：额外查看 config get tcp-keepalive，如果 tcp-keepalive 为非 0，说明连接检测机制存在，配合 timeout 的值综合判定，而不是凭 timeout=0 一票否决。

第三个坑最翻车：改了 config set 但不写 redis.conf。现象：测评当场 config get requirepass 有值，报告里写了符合，实际重启后 Redis 无密码可直连。原因：config set 只在运行时生效，没有执行 config rewrite，也没有手动改配置文件。解决：部署整改时强制走一遍 config set 加 config rewrite，或者直接改配置文件后重启实例；测评复测时优先看 redis.conf 里的实际配置，而不是只信内存值。

6. 测评收尾：把查询结果整理成证据链的一线技巧

测评做完不等于报告能交。数据库等保测评最容易被质疑的，就是你查的数据是什么时间点的、登录身份是什么、这个参数是全局生效还是会话级生效。我的习惯是每查完一个库，立即把四条信息记录下来：查询时间、登录账号、执行路径（命令行还是图形界面）、输出截图。比如 MySQL 查 validate_password 的结果，我会同时截下 show variables like 'validate_password%' 的完整输出和 mysql> 提示符，因为评审专家看到没带库名和时间的截图，第一反应是这张图能不能从别的实例复现出来。

第二个技巧是把符合或不符合的判定依据列成清单，每条对应到等保标准的具体条款。比如 MySQL 的 wait_timeout 默认 28800 秒，条款对应"应对登录连接建立超时时间进行设置，空闲会话应在一段时间后自动终止"，判定依据写清楚当前值 28800 和推荐值 1800 的差距，整改建议直接给出 set global wait_timeout=1800 和 set global interactive_timeout=1800 的组合命令，少写"建议调整超时时间"这种无效话。

第三个技巧是要区分参数作用域。MySQL 的 wait_timeout 是全局加会话两层作用域，Oracle 的 profile 是用户级，Redis 的 requirepass 是实例级。写报告时如果混为一谈，整改方按你给的命令执行后重新查询，发现值又不对，就变成你测评失误了。从那以后我每次整理证据链，都强制先标出每个参数的作用域，再写整改命令，这个习惯帮我挡掉了不少麻烦。希望帮到你。

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