企业官网建设流程全解析

简介：这份作业指导书面向数据库运维、安全测评与等保合规从业人员，系统梳理了MySQL、Oracle、SQL Server、Postgres、Redis五类主流数据库在等级保护测评中的实操要点。资源包内含1个docx文档，大小约1.83MB，按数据库类型分五个部分编排，结构清晰、便于按需查阅。内容覆盖各数据库的连接登录方式与测评基本查询语句，例如MySQL的密码复杂度与有效期、登录失败处理、超时时间、用户登录IP限制、审计开启及远程加密管理；SQL Server的密码策略、失败锁定、自动超时退出、用户权限与终端IP访问测试；Postgres的版本、用户名、密码有效期、失败次数限制与审计参数；以及Redis的连接与测评查询方法。读者可据此快速定位对应数据库的核查命令与判断依据，减少自行摸索成本，适合作为等保测评现场作业的参考手册与自查清单。目前已有785人学习下载。

1. 等保测评里数据库这一关，为什么总在“看起来没问题”的地方翻车

做过等保测评的人都有一个共识：主机、网络、应用层的整改往往还能靠堆设备、加策略糊弄过去，唯独数据库这一块，最容易在“看起来没问题”的地方翻车。MySQL、Oracle、SQL Server、PostgreSQL、Redis 这五类数据库，几乎覆盖了国内绝大多数业务系统，但它们的等保测评作业逻辑完全不同——关系型数据库查的是身份鉴别、访问控制、安全审计、数据完整性，Redis 这类缓存数据库查的是未授权访问、危险命令禁用、持久化文件权限。很多团队拿着同一份检查表去套所有数据库，结果就是 MySQL 过了、Redis 裸奔、Oracle 的审计策略根本没开。

这篇作业指导书要解决的问题很具体：给你一套可以照着走的流程，把五类数据库的等保测评从“凭感觉查”变成“按清单过”。适合谁看？一是正在做等保整改的运维和 DBA，二是需要出具测评结论的测评机构工程师，三是负责统筹等保项目的安全负责人。我不会只讲概念，每一类数据库都会落到具体的查询语句、配置文件路径、参数值和验证命令上。先立住一个判断：等保测评不是把数据库加固到最严，而是把测评项逐条对应到可验证的证据上，证据链完整比配置漂亮更重要。

2. 五类数据库的等保测评项拆解：从身份鉴别到数据完整性

2.1 关系型数据库的四个核心测评维度

MySQL、Oracle、SQL Server、PostgreSQL 虽然语法和架构不同，但在等保 2.0 的测评框架下，核心维度是一致的：身份鉴别、访问控制、安全审计、数据完整性。身份鉴别看的是有没有强密码策略、有没有多因素认证、登录失败有没有锁定；访问控制看的是账号权限有没有最小化、有没有多余的默认账号、角色划分是否清晰；安全审计看的是有没有开启审计日志、日志能不能追溯到具体用户和操作；数据完整性看的是传输和存储有没有加密、备份是否可恢复。

这四个维度在测评时不是并列关系，而是有优先级的。身份鉴别和访问控制是必查项，几乎每个等保三级项目都会重点看；安全审计在三级以上是强制项，二级项目可能只做抽查；数据完整性则更多看业务系统的实际需求，比如涉及个人敏感信息的系统会重点查加密。我一般会先确认系统的等保级别，再决定每个维度的检查深度，避免在二级项目上花三级的时间。

2.2 Redis 为什么不能套用关系型数据库的检查表

Redis 的等保测评逻辑和关系型数据库有本质区别。Redis 默认没有用户名概念，只有一个可选的 requirepass 密码，而且早期版本默认绑定 0.0.0.0 且无密码。等保测评对 Redis 的核心关注点是：有没有未授权访问、有没有禁用危险命令、持久化文件有没有权限控制、有没有绑定内网地址。

很多团队在整改时只加了密码，但没改 bind 配置，结果 Redis 仍然监听在所有网卡上。测评时用 redis-cli -h 目标IP 直接连，如果不需要密码就能执行 INFO 命令，这一项直接判不符合。另一个高频问题是 CONFIG、FLUSHALL、KEYS 这些危险命令没有重命名或禁用，攻击者一旦连上就能清库或导出所有键。Redis 的等保整改必须同时做三件事：设密码、改绑定地址、重命名危险命令，缺一不可。

2.3 测评证据的采集方式：命令、配置文件与日志

等保测评的结论必须有证据支撑，不能只靠“我配了”。关系型数据库的证据采集主要靠三类：一是查询语句，比如 MySQL 的 SELECT user,host FROM mysql.user 看账号列表，Oracle 的 SELECT username, account_status FROM dba_users 看账号状态；二是配置文件，比如 PostgreSQL 的 pg_hba.conf 看认证方式，SQL Server 的配置管理器看混合认证模式；三是日志文件，比如 MySQL 的 general_log 和 audit_log，Oracle 的 AUD$ 表。

Redis 的证据采集更直接：redis-cli 连上去执行 CONFIG GET 看关键参数，检查 redis.conf 里的 bind、requirepass、rename-command 配置，再看持久化文件 dump.rdb 和 appendonly.aof 的权限。我一般会把这些证据按测评项编号整理成表格，每一项对应一条命令或一个文件路径，测评时直接照着采，避免现场翻文档。

3. MySQL 与 PostgreSQL 的实操检查：账号、权限与审计配置

3.1 MySQL 账号安全与密码策略的检查命令

MySQL 的等保测评从账号清单开始。先连上数据库，执行下面这条查询，看有没有匿名账号、有没有 host 为 % 的账号、有没有空密码账号：

-- 查看所有账号及其来源主机 SELECT user, host, authentication_string, plugin FROM mysql.user ORDER BY user, host; -- 检查是否存在匿名账号（user 为空） SELECT user, host FROM mysql.user WHERE user = ''; -- 检查是否存在 host 为 % 的账号（允许任意主机连接） SELECT user, host FROM mysql.user WHERE host = '%'; -- 检查密码是否为空（authentication_string 为空） SELECT user, host FROM mysql.user WHERE authentication_string = '' OR authentication_string IS NULL;

这三条查询的结果直接对应等保测评的身份鉴别项。匿名账号必须删除，host 为 % 的账号要确认是否必要，空密码账号必须立即整改。MySQL 8.0 之后默认使用 caching_sha2_password 插件，比 mysql_native_password 更安全，测评时可以把这个作为加分项。

密码策略的检查要看 validate_password 插件有没有安装和启用：

-- 查看密码策略插件状态 SHOW PLUGINS WHERE Name = 'validate_password'; -- 查看密码策略参数 SHOW VARIABLES LIKE 'validate_password%';

如果 validate_password 没有启用，等保三级项目基本会判不符合。关键参数是 validate_password.policy，建议设为 MEDIUM 或 STRONG，validate_password.length 建议不低于 8。设置完策略后，已有账号的密码不会自动重新校验，需要手动 ALTER USER 重置一次。

3.2 PostgreSQL 的 pg_hba.conf 与审计日志配置

PostgreSQL 的访问控制核心在 pg_hba.conf 文件里。这个文件决定了哪些主机、哪些用户、哪些数据库可以用什么认证方式连接。等保测评时重点看有没有 trust 认证方式，因为 trust 意味着完全信任，不需要密码：

# 查看 pg_hba.conf 中的认证配置 cat /var/lib/pgsql/data/pg_hba.conf | grep -v "^#" | grep -v "^$" # 检查是否存在 trust 认证 grep -i "trust" /var/lib/pgsql/data/pg_hba.conf

如果发现 trust，必须改成 md5 或 scram-sha-256。scram-sha-256 比 md5 更安全，PostgreSQL 10 之后都支持。改完 pg_hba.conf 后需要 reload 配置：

# 重新加载 PostgreSQL 配置 pg_ctl reload -D /var/lib/pgsql/data # 或者用 SQL 命令 SELECT pg_reload_conf();

审计日志方面，PostgreSQL 默认只记录启动、关闭和错误信息，不记录具体查询。等保三级项目需要开启 pgaudit 扩展或者配置 log_statement：

-- 查看当前日志配置 SHOW log_statement; SHOW log_connections; SHOW log_disconnections; -- 建议配置（在 postgresql.conf 中修改） -- log_statement = 'all' 或 'ddl' -- log_connections = on -- log_disconnections = on -- log_line_prefix = '%t [%p]: [%l-1] user=%u,db=%d,app=%a,client=%h '

log_statement 设为 all 会记录所有 SQL 语句，对性能有影响，生产环境建议设为 ddl 或 mod。log_line_prefix 的格式决定了日志能不能追溯到具体用户和客户端 IP，等保测评时会检查这个格式是否包含用户、数据库、客户端地址三个要素。

3.3 用 SQL 验证权限最小化与角色分离

访问控制的测评核心是权限最小化。MySQL 和 PostgreSQL 都需要检查有没有账号拥有超出业务需要的权限。MySQL 的检查命令：

-- 查看所有用户的权限 SELECT * FROM mysql.user WHERE user NOT IN ('mysql.sys', 'mysql.session', 'mysql.infoschema'); -- 查看具体用户的授权 SHOW GRANTS FOR 'app_user'@'192.168.1.%'; -- 检查是否有用户拥有 SUPER 或 FILE 权限 SELECT user, host FROM mysql.user WHERE Super_priv = 'Y' OR File_priv = 'Y';

SUPER 权限允许用户终止其他会话、修改全局变量，FILE 权限允许读写服务器文件，这两个权限在等保测评中属于高风险项。业务账号不应该有这两个权限，只有 DBA 账号可以保留。

PostgreSQL 的权限检查：

-- 查看所有角色及其属性 SELECT rolname, rolsuper, rolcreaterole, rolcreatedb, rolcanlogin FROM pg_roles WHERE rolname NOT LIKE 'pg_%'; -- 查看数据库级别的权限 SELECT datname, datacl FROM pg_database; -- 查看表级别的权限 SELECT grantee, table_schema, table_name, privilege_type FROM information_schema.table_privileges WHERE grantee NOT IN ('postgres', 'PUBLIC');

PostgreSQL 的 PUBLIC 角色默认拥有一些权限，等保测评时建议回收 PUBLIC 的不必要权限，特别是 CREATE 权限。角色分离方面，建议把业务账号、只读账号、管理账号分开，不要用同一个账号做所有事。

4. Oracle 与 SQL Server 的实操检查：审计策略与认证模式

4.1 Oracle 审计策略的开启与验证

Oracle 的等保测评最容易被扣分的地方是审计没开。Oracle 的审计分传统审计和统一审计两种，11g 默认用传统审计，12c 之后推荐统一审计。先检查当前审计状态：

-- 查看传统审计参数 SHOW PARAMETER audit_trail; -- 查看统一审计策略（12c 及以上） SELECT policy_name, enabled_option, audit_condition FROM audit_unified_policies; -- 查看已启用的统一审计策略 SELECT policy_name, enabled_option FROM audit_unified_enabled_policies;

audit_trail 参数如果是 NONE，说明审计完全没开，等保测评直接判不符合。如果是 DB，审计记录写在数据库表里；如果是 OS，写在操作系统文件里；如果是 XML，写在 XML 文件里。等保三级建议设为 DB 或 XML，方便查询和保留。

开启传统审计的步骤：

-- 修改审计参数（需要重启数据库） ALTER SYSTEM SET audit_trail = DB SCOPE = SPFILE; -- 重启后开启具体审计项 AUDIT CREATE SESSION BY ACCESS; AUDIT CREATE TABLE BY ACCESS; AUDIT DROP TABLE BY ACCESS; AUDIT ALTER TABLE BY ACCESS; AUDIT GRANT BY ACCESS; AUDIT REVOKE BY ACCESS; -- 查看审计记录 SELECT username, action_name, obj_name, timestamp FROM dba_audit_trail ORDER BY timestamp DESC;

统一审计的开启方式不同，需要先创建审计策略再启用：

-- 创建统一审计策略 CREATE AUDIT POLICY audit_ddl_policy ACTIONS CREATE TABLE, DROP TABLE, ALTER TABLE; -- 启用策略 AUDIT POLICY audit_ddl_policy; -- 查看审计记录 SELECT audit_type, dbusername, action_name, object_name, event_timestamp FROM unified_audit_trail ORDER BY event_timestamp DESC;

统一审计比传统审计更灵活，可以按条件过滤，但配置复杂度也更高。我一般建议新系统直接用统一审计，老系统如果已经开了传统审计，可以保持不动，避免迁移风险。

4.2 SQL Server 的混合认证模式与登录审计

SQL Server 的等保测评第一个检查点是认证模式。SQL Server 支持 Windows 认证和混合认证两种模式，混合认证允许 SQL Server 账号登录，风险更高。检查方式：

-- 查看服务器认证模式 SELECT SERVERPROPERTY('IsIntegratedSecurityOnly') AS IsWindowsOnly; -- 返回 1 表示仅 Windows 认证，返回 0 表示混合认证 -- 查看所有登录账号 SELECT name, type_desc, is_disabled, create_date, modify_date FROM sys.server_principals WHERE type IN ('S', 'U', 'G') ORDER BY name; -- 查看是否有空密码或弱密码账号（需要结合策略检查） SELECT name, is_policy_checked, is_expiration_checked FROM sys.sql_logins;

is_policy_checked 为 0 表示没有启用密码策略，is_expiration_checked 为 0 表示密码不过期。等保测评要求这两个至少有一个为 1，三级项目建议都设为 1。

SQL Server 的审计功能通过 SQL Server Audit 实现，可以审计登录失败、权限变更、数据修改等：

-- 创建服务器级别审计 CREATE SERVER AUDIT [Audit_Login] TO FILE (FILEPATH = 'D:\AuditLogs\', MAXSIZE = 100 MB, MAX_ROLLOVER_FILES = 10) WITH (ON_FAILURE = CONTINUE); -- 启用审计 ALTER SERVER AUDIT [Audit_Login] WITH (STATE = ON); -- 创建审计规范 CREATE SERVER AUDIT SPECIFICATION [Audit_Login_Spec] FOR SERVER AUDIT [Audit_Login] ADD (FAILED_LOGIN_GROUP), ADD (SUCCESSFUL_LOGIN_GROUP), ADD (DATABASE_PERMISSION_CHANGE_GROUP) WITH (STATE = ON); -- 查看审计记录 SELECT event_time, action_id, succeeded, server_principal_name, statement FROM sys.fn_get_audit_file('D:\AuditLogs\*', DEFAULT, DEFAULT);

审计文件路径要确保有足够的磁盘空间，MAX_ROLLOVER_FILES 控制文件轮转数量。ON_FAILURE = CONTINUE 表示审计写入失败时继续运行，等保测评一般建议设为 CONTINUE，避免审计故障导致业务中断。

4.3 用配置查询验证密码策略与登录失败锁定

Oracle 的密码策略通过 PROFILE 管理，检查命令：

-- 查看所有 PROFILE 的密码策略 SELECT profile, resource_name, limit FROM dba_profiles WHERE resource_name IN ( 'FAILED_LOGIN_ATTEMPTS', 'PASSWORD_LIFE_TIME', 'PASSWORD_REUSE_MAX', 'PASSWORD_VERIFY_FUNCTION' ) ORDER BY profile, resource_name; -- 查看用户使用的 PROFILE SELECT username, profile FROM dba_users WHERE account_status = 'OPEN';

FAILED_LOGIN_ATTEMPTS 建议设为 5 到 10，PASSWORD_LIFE_TIME 建议设为 90 天以内，PASSWORD_VERIFY_FUNCTION 应该指向一个密码复杂度校验函数。Oracle 默认的 DEFAULT PROFILE 这些值都是 UNLIMITED，必须修改。

SQL Server 的登录失败锁定通过策略组管理，检查方式：

-- 查看登录失败锁定策略（需要 Windows 策略或 SQL Server 策略） SELECT name, is_policy_checked, is_expiration_checked, LOGINPROPERTY(name, 'BadPasswordCount') AS BadPasswordCount, LOGINPROPERTY(name, 'LockoutTime') AS LockoutTime FROM sys.sql_logins;

SQL Server 的锁定策略依赖 Windows 的账户策略，如果 SQL Server 运行在域环境里，直接继承域策略；如果是独立服务器，需要在本地安全策略里配置。等保测评时会检查锁定阈值和锁定时间，建议阈值设为 5 次，锁定时间设为 15 分钟以上。

5. Redis 与全类数据库的避坑排查：从未授权访问到审计缺失

5.1 Redis 未授权访问与危险命令的排查

Redis 的未授权访问是等保测评中最常见的不符合项。排查步骤：

# 从外部主机尝试连接（替换为目标 IP） redis-cli -h 192.168.1.100 -p 6379 # 如果不需要密码就能执行命令，说明存在未授权访问 INFO server CONFIG GET requirepass CONFIG GET bind

如果 INFO 命令能直接执行，说明没有设密码或者密码没生效。检查 redis.conf：

# 查看关键配置 grep -E "^(bind|requirepass|rename-command|protected-mode)" /etc/redis/redis.conf # 推荐配置 # bind 127.0.0.1 或 bind 内网IP # requirepass 强密码 # protected-mode yes # rename-command CONFIG "" # rename-command FLUSHALL "" # rename-command FLUSHDB "" # rename-command KEYS ""

protected-mode 是 Redis 3.2 之后引入的保护模式，当没有设密码且没有绑定特定地址时，只允许本地连接。但很多团队为了远程管理把 protected-mode 设为 no，这就等于把 Redis 暴露出去。rename-command 把危险命令重命名为空字符串，等于禁用该命令，这是等保测评的推荐做法。

5.2 审计日志缺失与日志保留周期的整改

审计日志缺失是五类数据库的通病。MySQL 的 general_log 默认关闭，Oracle 的 audit_trail 默认 NONE，SQL Server 默认没有审计规范，PostgreSQL 默认只记录错误，Redis 只有慢查询日志。等保测评要求审计日志保留至少 6 个月，三级项目要求 12 个月。

整改时要注意日志保留周期和磁盘空间的平衡。MySQL 的 general_log 如果设为 ON，所有查询都会写入文件，高并发场景下磁盘很快写满。我一般建议用 audit_log 插件代替 general_log，只记录必要的操作类型。Oracle 的审计记录存在 SYSTEM 表空间，需要定期清理和归档，否则会把表空间撑爆。SQL Server 的审计文件要设置 MAX_ROLLOVER_FILES，避免无限增长。PostgreSQL 的 log_statement 设为 all 时，日志量会大幅增加，建议配合 log_rotation_age 和 log_rotation_size 做轮转。Redis 的慢查询日志通过 slowlog-log-slower-than 配置，等保测评不强制要求，但建议开启作为辅助证据。

5.3 常见踩坑记录：现象、原因与解决

坑一：MySQL 改了密码策略但旧账号没生效。现象是 validate_password 已启用，但旧账号仍然能用弱密码登录。原因是密码策略只对新密码生效，已有密码不会重新校验。解决方法是逐个账号执行 ALTER USER ‘user’@‘host’ IDENTIFIED BY ‘新密码’，强制刷新密码。

坑二：Oracle 审计开了但查不到记录。现象是 audit_trail 设为 DB，但 dba_audit_trail 表里没有数据。原因是审计项没有单独开启，audit_trail 只是总开关，具体操作需要 AUDIT 语句逐项开启。解决方法是执行 AUDIT CREATE SESSION、AUDIT CREATE TABLE 等语句，再用 SELECT 验证。

坑三：SQL Server 审计文件写满磁盘。现象是审计日志目录占满磁盘，业务写入失败。原因是 MAXSIZE 设得太大或者 MAX_ROLLOVER_FILES 设得太多。解决方法是把 MAXSIZE 设为 100MB 以内，MAX_ROLLOVER_FILES 设为 10 以内，并配置定期归档。

坑四：PostgreSQL 改了 pg_hba.conf 但没生效。现象是配置文件已改，但连接仍然用旧认证方式。原因是 pg_hba.conf 修改后需要 reload 或 restart，reload 对已有连接不生效。解决方法是执行 pg_ctl reload 后，断开所有现有连接再重连，或者直接 restart。

坑五：Redis 设了密码但仍然未授权访问。现象是 requirepass 已配置，但外部仍然能连。原因是 bind 没有改，Redis 仍然监听 0.0.0.0，而且 protected-mode 被设为 no。解决方法是同时修改 bind 为内网地址、设 requirepass、保持 protected-mode yes，三个条件同时满足才能阻断未授权访问。

6. 把等保测评从一次性检查变成常态化验证

等保测评不是每年做一次就完事，数据库的配置会随着业务变更、版本升级、人员操作而漂移。我见过太多系统在测评通过后三个月，因为一次紧急扩容把 Redis 的 bind 改回了 0.0.0.0，或者因为一次版本升级把 MySQL 的密码策略插件卸掉了。真正省心的做法是把测评项变成常态化验证脚本，每周跑一次，发现漂移立即告警。

下面是一个跨数据库的验证脚本框架，用 Python 实现，可以按数据库类型分别检查关键项：

import subprocess import json from datetime import datetime # 检查项配置：数据库类型、连接方式、检查命令、期望结果 CHECKS = { "mysql": { "cmd": "mysql -u check_user -p'密码' -e \"SELECT user,host FROM mysql.user WHERE user='' OR host='%';\"", "expect_empty": True, "desc": "检查匿名账号和任意主机账号" }, "redis": { "cmd": "redis-cli -h 127.0.0.1 CONFIG GET bind", "expect_contains": "127.0.0.1", "desc": "检查 Redis 绑定地址" }, "postgresql": { "cmd": "grep -i 'trust' /var/lib/pgsql/data/pg_hba.conf", "expect_empty": True, "desc": "检查 PostgreSQL trust 认证" } } def run_check(db_type, config): """执行单个检查项，返回是否符合""" try: result = subprocess.run( config["cmd"], shell=True, capture_output=True, text=True, timeout=10 ) output = result.stdout.strip() if config.get("expect_empty"): passed = len(output) == 0 elif config.get("expect_contains"): passed = config["expect_contains"] in output else: passed = False return { "db": db_type, "desc": config["desc"], "passed": passed, "output": output[:200], # 截断避免日志过长 "time": datetime.now().isoformat() } except Exception as e: return { "db": db_type, "desc": config["desc"], "passed": False, "output": str(e), "time": datetime.now().isoformat() } def main(): """遍历所有检查项并输出结果""" results = [] for db_type, config in CHECKS.items(): result = run_check(db_type, config) results.append(result) status = "通过" if result["passed"] else "不符合" print(f"[{status}] {db_type}: {result['desc']}") # 输出 JSON 格式便于对接告警系统 print(json.dumps(results, ensure_ascii=False, indent=2)) if __name__ == "__main__": main()

这个脚本的逻辑很直接：每个检查项定义一条命令和期望结果，expect_empty 表示命令输出为空才算通过，expect_contains 表示输出包含指定字符串才算通过。实际使用时，把连接命令和密码替换成环境变量，避免硬编码。输出格式用 JSON，方便对接监控系统做告警。

参数调整方面，timeout 设为 10 秒是防止某个数据库连接卡住导致整个脚本挂起。output 截断到 200 字符是避免日志文件过大。如果要做更细粒度的检查，可以扩展 CHECKS 字典，比如加上 Oracle 的 audit_trail 检查、SQL Server 的 IsIntegratedSecurityOnly 检查。

我自己的习惯是把这个脚本放在跳板机上，用 crontab 每周一早上跑一次，结果写入日志文件，同时把不符合项推送到内部告警群。这样等保测评前只需要看最近三个月的验证记录，就能证明数据库配置没有漂移，测评师也会认可这种常态化验证的证据链。希望帮到你。

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