企业官网建设流程全解析

简介：这份作业指导书面向数据库安全测评人员、等保合规工程师及运维人员，系统梳理了MySQL、Oracle、SQL Server、Postgres、Redis五类主流数据库在等保测评中的实操要点，帮助读者快速定位各数据库的测评项与查询方法。资源包内含1个docx文档，大小约1.83MB，按数据库类型分PART编排，涵盖连接登录方式与测评基本查询语句两大模块。其中MySQL部分涉及密码复杂度与有效期、登录失败处理、超时时间、用户及允许登录IP、审计功能、加密远程管理等查询；Oracle、SQL Server、Postgres、Redis则分别给出对应的连接方法与密码策略、权限列表、审计开启、终端IP限制等核查语句。目录结构清晰，便于按数据库类型逐项查阅，适合作为等保测评现场作业的速查手册与自查清单。目前已有785人学习下载，可供需要开展数据库合规检查、撰写测评报告或搭建测评环境的技术人员参考使用。

1. 等保测评里数据库这一关，为什么总在最后卡住

做过等保测评的人大概都有体会：网络、主机、应用层都过了，最后卡在数据库上。MySQL、Oracle、SQL Server、PostgreSQL、Redis 这五类数据库几乎覆盖了国内绝大多数业务系统，但它们的等保测评作业方式差异极大——Oracle 有独立的审计策略和 profile 机制，MySQL 5.7 和 8.0 的权限模型完全不同，Redis 默认无认证直接裸奔，SQL Server 的混合认证模式经常被忽略，PostgreSQL 的 pg_hba.conf 一行配置就能决定测评结论。

等保 2.0 三级要求里，安全计算环境部分涉及数据库的条款大约有十几项，涵盖身份鉴别、访问控制、安全审计、入侵防范、数据完整性和保密性。很多人以为等保测评就是填表格、截图、交文档，实际上测评机构会实际连上数据库执行命令验证，配置不对当场就开不符合项。这篇作业指导书面向的是需要自己动手做数据库等保加固和自查的工程师，不是写给测评机构看的，是写给你自己干活用的。

2. 五类数据库的身份鉴别与访问控制：从口令策略到最小权限

2.1 MySQL 8.0 的口令策略与账户锁定配置

MySQL 5.7 之后引入了validate_password组件，8.0 默认使用caching_sha2_password认证插件。等保要求口令长度不少于 8 位、包含大小写字母数字特殊字符、定期更换，同时要求登录失败处理功能。

先确认组件是否安装：

-- 查看密码验证组件状态 SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME LIKE 'validate_password%'; -- 如果未安装，安装组件 INSTALL COMPONENT 'file://component_validate_password'; -- 设置口令策略：MEDIUM 要求长度8位以上、含数字字母特殊字符 SET GLOBAL validate_password.policy = 'MEDIUM'; SET GLOBAL validate_password.length = 8; SET GLOBAL validate_password.mixed_case_count = 1; SET GLOBAL validate_password.number_count = 1; SET GLOBAL validate_password.special_char_count = 1;

逻辑说明：validate_password.policy设为 MEDIUM 时，MySQL 会强制校验口令的组成复杂度。length控制最小长度，等保三级通常要求 8 位以上，如果行业有更严格要求可以设到 12。这些参数写入my.cnf的[mysqld]段才能持久化，SET GLOBAL重启后失效。

登录失败锁定需要安装connection_control插件：

INSTALL PLUGIN connection_control SONAME 'connection_control.so'; INSTALL PLUGIN connection_control_failed_login_attempts SONAME 'connection_control.so'; -- 设置连续失败3次后锁定，锁定时间60秒 SET GLOBAL connection_control_failed_connections_threshold = 3; SET GLOBAL connection_control_min_connection_delay = 60000; SET GLOBAL connection_control_max_connection_delay = 180000;

参数说明：threshold是允许的连续失败次数，超过后触发延迟；min_connection_delay是最小延迟毫秒数，60000 即 60 秒。注意这个插件是按账户维度计数的，不是全局计数。

访问控制方面，等保要求数据库账户按最小权限分配。常见做法是：

-- 创建只读账户，仅允许从应用服务器网段连接 CREATE USER 'app_readonly'@'192.168.1.%' IDENTIFIED BY 'R3ad0nly@2024'; GRANT SELECT ON biz_db.* TO 'app_readonly'@'192.168.1.%'; -- 创建应用读写账户，禁止 DDL 和 DROP CREATE USER 'app_rw'@'192.168.1.%' IDENTIFIED BY 'AppRw@2024#Sec'; GRANT SELECT, INSERT, UPDATE, DELETE ON biz_db.* TO 'app_rw'@'192.168.1.%'; -- 回收默认的 test 库权限和匿名账户 DROP DATABASE IF EXISTS test; DELETE FROM mysql.user WHERE User=''; FLUSH PRIVILEGES;

2.2 Oracle 的 Profile 与审计策略配置

Oracle 的等保加固核心在 Profile 和统一审计。先创建符合等保要求的口令策略 Profile：

-- 创建等保合规的 Profile CREATE PROFILE sec_profile LIMIT FAILED_LOGIN_ATTEMPTS 5 PASSWORD_LOCK_TIME 1 PASSWORD_LIFE_TIME 90 PASSWORD_GRACE_TIME 7 PASSWORD_REUSE_MAX 5 PASSWORD_REUSE_TIME 365 PASSWORD_VERIFY_FUNCTION ora12c_verify_function SESSIONS_PER_USER 10 IDLE_TIME 30 CONNECT_TIME 480; -- 将 Profile 应用到用户 ALTER USER app_user PROFILE sec_profile;

参数说明：FAILED_LOGIN_ATTEMPTS 5表示连续失败 5 次锁定；PASSWORD_LOCK_TIME 1锁定 1 天；PASSWORD_LIFE_TIME 90口令 90 天过期；IDLE_TIME 30空闲 30 分钟断开。PASSWORD_VERIFY_FUNCTION指定口令复杂度校验函数，Oracle 12c 以上自带ora12c_verify_function。

Oracle 统一审计从 12c 开始推荐使用：

-- 创建统一审计策略，审计所有登录失败和权限变更 CREATE AUDIT POLICY sec_audit_policy ACTIONS LOGON, ALTER USER, DROP USER, GRANT, REVOKE WHENEVER NOT SUCCESSFUL; -- 启用审计策略 AUDIT POLICY sec_audit_policy; -- 确认审计策略状态 SELECT POLICY_NAME, ENABLED_OPT, SUCCESS, FAILURE FROM AUDIT_UNIFIED_POLICIES WHERE POLICY_NAME = 'SEC_AUDIT_POLICY';

逻辑说明：WHENEVER NOT SUCCESSFUL表示只记录失败操作，减少审计日志量。如果等保要求记录所有操作，改为WHENEVER SUCCESSFUL或去掉该子句。审计记录默认写入UNIFIED_AUDIT_TRAIL视图，需要确认AUDIT_TRAIL参数设为DB或XML。

2.3 SQL Server 的混合认证与登录审计

SQL Server 等保测评最常见的坑是混合认证模式。Windows 认证模式下，数据库层面无法独立控制口令策略，测评时会被质疑。建议启用混合模式并配置 SQL Server 登录的密码策略：

-- 查看当前认证模式（1=Windows, 0=混合） SELECT SERVERPROPERTY('IsIntegratedSecurityOnly') AS IsWindowsOnly; -- 创建 SQL 登录并强制密码策略 CREATE LOGIN app_login WITH PASSWORD = 'Str0ng@Pass2024!', CHECK_POLICY = ON, CHECK_EXPIRATION = ON, DEFAULT_DATABASE = biz_db; -- 创建数据库用户并授予最小权限 USE biz_db; CREATE USER app_user FOR LOGIN app_login; ALTER ROLE db_datareader ADD MEMBER app_user; ALTER ROLE db_datawriter ADD MEMBER app_user; -- 明确拒绝 DDL 权限 DENY CREATE TABLE, ALTER ANY SCHEMA TO app_user;

参数说明：CHECK_POLICY = ON让 SQL Server 继承 Windows 密码策略（长度、复杂度、锁定阈值）；CHECK_EXPIRATION = ON启用密码过期。如果操作系统层面没有配置密码策略，CHECK_POLICY的效果会打折扣，需要先在本地安全策略里配好。

登录审计通过 SQL Server Audit 实现：

-- 创建服务器级审计 CREATE SERVER AUDIT sec_audit TO FILE (FILEPATH = 'D:\AuditLogs\', MAXSIZE = 500 MB, MAX_ROLLOVER_FILES = 10) WITH (ON_FAILURE = CONTINUE); ALTER SERVER AUDIT sec_audit WITH (STATE = ON); -- 创建审计规范，记录登录失败和权限变更 CREATE SERVER AUDIT SPECIFICATION sec_audit_spec FOR SERVER AUDIT sec_audit ADD (FAILED_LOGIN_GROUP), ADD (SUCCESSFUL_LOGIN_GROUP), ADD (DATABASE_ROLE_MEMBER_CHANGE_GROUP), ADD (SERVER_ROLE_MEMBER_CHANGE_GROUP) WITH (STATE = ON);

2.4 PostgreSQL 的 pg_hba.conf 与角色权限

PostgreSQL 的访问控制核心在pg_hba.conf，这个文件决定了谁能从哪个 IP 以什么认证方式连接哪个库。等保测评会重点检查这个文件。

# pg_hba.conf 典型等保合规配置 # TYPE DATABASE USER ADDRESS METHOD local all all peer host all all 127.0.0.1/32 scram-sha-256 host all all ::1/128 scram-sha-256 host biz_db app_user 192.168.1.0/24 scram-sha-256 host all all 0.0.0.0/0 reject

逻辑说明：最后一行reject是兜底规则，拒绝所有未明确允许的连接。scram-sha-256是 PostgreSQL 10 之后推荐的认证方式，比 md5 更安全。peer用于本地 Unix socket 连接，按操作系统用户映射。

口令策略通过passwordcheck扩展或ALTER SYSTEM配置：

-- 安装 passwordcheck 扩展（需在 shared_preload_libraries 中加载） ALTER SYSTEM SET shared_preload_libraries = 'passwordcheck'; -- 重启后生效 -- 创建角色时设置有效期和连接限制 CREATE ROLE app_user WITH LOGIN PASSWORD 'Pg@Str0ng2024' VALID UNTIL '2025-12-31' CONNECTION LIMIT 20; -- 授予最小权限 GRANT CONNECT ON DATABASE biz_db TO app_user; GRANT USAGE ON SCHEMA public TO app_user; GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO app_user; -- 禁止创建新表 REVOKE CREATE ON SCHEMA public FROM app_user;

2.5 Redis 的认证与命令重命名

Redis 默认无认证，这是等保测评中最容易被开不符合项的地方。Redis 6.0 之后支持 ACL，但大多数生产环境还在用 5.x 或更早版本，只能用requirepass。

# redis.conf 等保合规配置 requirepass R3dis@Str0ng2024! bind 192.168.1.100 127.0.0.1 protected-mode yes port 6379 maxclients 100 timeout 300 tcp-keepalive 60 # 重命名危险命令 rename-command FLUSHALL "" rename-command FLUSHDB "" rename-command CONFIG "CONFIG_a1b2c3" rename-command KEYS "" rename-command SHUTDOWN ""

参数说明：bind限制监听地址，不要绑0.0.0.0；protected-mode yes在没有 bind 和密码时拒绝外部连接；rename-command把危险命令重命名为空字符串即禁用。注意CONFIG命令重命名后，运维需要用新名字，别把自己锁在外面。

Redis 6.0 以上建议用 ACL：

# 创建只读用户 ACL SETUSER app_readonly on >Read0nly@2024 ~cache:* +get +mget +hget +hgetall -@all # 创建应用用户，允许读写但不允许管理命令 ACL SETUSER app_rw on >AppRw@2024 ~app:* +@read +@write -@admin -@dangerous # 查看用户列表 ACL LIST

3. 安全审计与日志留存：五类数据库的审计配置对照

3.1 审计功能开启与日志格式要求

等保要求审计记录包含事件日期时间、用户、事件类型、事件结果等字段，日志留存不少于 6 个月。五类数据库的审计开启方式差异很大，下面用表格对照。

MySQL 的 audit_log 插件配置：

-- 安装审计插件（企业版自带，社区版需第三方） INSTALL PLUGIN audit_log SONAME 'audit_log.so'; -- 配置审计策略 SET GLOBAL audit_log_policy = 'ALL'; SET GLOBAL audit_log_format = 'JSON'; SET GLOBAL audit_log_rotate_on_size = 104857600; -- 100MB 轮转 SET GLOBAL audit_log_rotations = 10; -- 保留10个文件

PostgreSQL 的 pgaudit 配置：

# postgresql.conf shared_preload_libraries = 'pgaudit' pgaudit.log = 'ddl, role, write' pgaudit.log_catalog = off pgaudit.log_parameter = on pgaudit.log_relation = on # 日志轮转 logging_collector = on log_directory = 'pg_log' log_filename = 'postgresql-%Y-%m-%d.log' log_rotation_age = 1d log_rotation_size = 100MB log_retention_days = 180

3.2 日志留存 6 个月的落地方法

等保要求日志留存 6 个月，实际落地时数据库本地磁盘往往撑不住。常见做法是本地保留 7-30 天，然后通过日志采集工具推送到集中日志平台。

# 以 MySQL general_log 为例，用 logrotate 管理 # /etc/logrotate.d/mysql-audit /var/log/mysql/audit.log { daily rotate 180 missingok notifempty compress delaycompress create 640 mysql mysql postrotate mysqladmin -u root -p'xxx' flush-logs endscript }

逻辑说明：rotate 180配合daily实现 180 天留存；compress压缩旧日志节省空间；postrotate通知 MySQL 重新打开日志文件。注意mysqladmin flush-logs需要认证信息，建议用--defaults-file指定配置文件避免密码出现在命令行。

注意：日志留存不只是数据库层面的事，等保测评会检查操作系统层面的日志轮转配置和集中日志平台的留存策略，两边都要对得上。

4. 数据完整性与保密性：传输加密和存储加密的实操

4.1 传输层 TLS 配置

等保三级要求数据库管理终端和数据库之间的通信加密。五类数据库都支持 TLS，但配置方式不同。

MySQL 8.0 默认启用 TLS，确认证书状态：

-- 查看 SSL 状态 SHOW VARIABLES LIKE '%ssl%'; -- 强制所有连接使用 SSL SET GLOBAL require_secure_transport = ON; -- 写入 my.cnf: require_secure_transport = ON

PostgreSQL 的 SSL 配置：

# postgresql.conf ssl = on ssl_cert_file = '/etc/ssl/certs/server.crt' ssl_key_file = '/etc/ssl/private/server.key' ssl_min_protocol_version = 'TLSv1.2' ssl_ciphers = 'HIGH:!aNULL:!MD5' # pg_hba.conf 中强制 SSL hostssl biz_db app_user 192.168.1.0/24 scram-sha-256

Redis 6.0 以上支持 TLS：

# redis.conf tls-port 6380 port 0 # 禁用非 TLS 端口 tls-cert-file /etc/ssl/certs/redis.crt tls-key-file /etc/ssl/private/redis.key tls-ca-cert-file /etc/ssl/certs/ca.crt tls-auth-clients yes

4.2 存储加密与敏感数据脱敏

存储加密分两个层面：透明数据加密（TDE）和应用层加密。Oracle 和 SQL Server 有原生 TDE，MySQL 和 PostgreSQL 需要依赖文件系统加密或应用层处理。

Oracle TDE 配置：

-- 创建密钥库（需先配置 wallet 目录） ADMINISTER KEY MANAGEMENT CREATE KEYSTORE '/u01/app/oracle/wallet' IDENTIFIED BY "W@llet2024"; -- 打开密钥库 ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "W@llet2024"; -- 设置主密钥 ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY "W@llet2024" WITH BACKUP; -- 加密表空间 ALTER TABLESPACE users ENCRYPTION ONLINE USING 'AES256' ENCRYPT;

SQL Server TDE 配置：

-- 创建主密钥 USE master; CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'M@ster2024!'; -- 创建证书 CREATE CERTIFICATE TDE_Cert WITH SUBJECT = 'TDE Certificate'; -- 创建数据库加密密钥 USE biz_db; CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_256 ENCRYPTION BY SERVER CERTIFICATE TDE_Cert; -- 启用加密 ALTER DATABASE biz_db SET ENCRYPTION ON;

注意：TDE 加密后备份文件也是加密的，恢复时需要对应的证书和密钥。证书丢失等于数据丢失，务必做好证书备份。

5. 等保测评自查避坑：五类数据库最常见的翻车点

5.1 口令策略配了但没生效

现象：明明在 MySQL 里设了validate_password.policy = MEDIUM，测评时用弱口令创建用户却成功了。

原因：SET GLOBAL只对当前会话之后的新连接生效，而且如果my.cnf里没有对应配置，重启后策略丢失。更隐蔽的情况是validate_password组件没装，SET GLOBAL不报错但也不生效。

解决：先查INFORMATION_SCHEMA.PLUGINS确认组件状态，再把参数写入my.cnf的[mysqld]段，重启后验证。Oracle 的 Profile 要确认已ALTER USER应用，SQL Server 的CHECK_POLICY依赖操作系统密码策略。

5.2 审计日志把磁盘写满导致数据库宕机

现象：开启全量审计后，数据库运行几天突然不可用，检查发现磁盘 100%。

原因：MySQL 的general_log或 Oracle 的统一审计没有配置轮转和清理策略，日志无限增长。Redis 的MONITOR命令输出如果被重定向到文件也会撑爆磁盘。

解决：MySQL 用audit_log_rotate_on_size控制轮转；Oracle 设置审计表空间配额和定期清理任务；PostgreSQL 用log_rotation_age和log_rotation_size；所有数据库的日志目录都要配监控告警。

5.3 Redis 绑定了 127.0.0.1 但测评还是不过

现象：redis.conf里bind 127.0.0.1已经配了，测评机构还是开了不符合项。

原因：等保要求的是「仅允许通过特定管理终端连接」，bind 127.0.0.1只允许本机连接，如果应用服务器和 Redis 不在同一台机器上，实际生产环境肯定改了配置。测评时看的是实际运行配置，不是配置文件。

解决：用CONFIG GET bind和CONFIG GET requirepass确认运行时配置。如果必须远程连接，绑定具体的内网 IP 并配置密码，同时用防火墙限制源 IP。

5.4 PostgreSQL 的 pg_hba.conf 改了没 reload

现象：修改pg_hba.conf后测试连接，发现新规则没生效。

原因：pg_hba.conf修改后需要pg_ctl reload或SELECT pg_reload_conf()才生效，直接改文件不 reload 等于没改。

解决：养成改完就 reload 的习惯，用SELECT pg_reload_conf()确认返回t。另外注意pg_hba.conf的规则是从上到下匹配，第一条匹配的规则生效，后面的不再检查。

5.5 SQL Server 的 sa 账户没禁用或没改名

现象：测评扫描发现 sa 账户启用且口令强度不够。

原因：安装时选了混合模式，sa 账户默认启用，很多运维忘了处理。

解决：如果业务不需要 sa，直接ALTER LOGIN sa DISABLE；如果需要保留，改名并设置强口令。同时检查BUILTIN\Administrators登录是否存在，等保要求移除不必要的登录。

-- 禁用 sa ALTER LOGIN sa DISABLE; -- 或者改名并设强口令 ALTER LOGIN sa WITH NAME = sys_admin; ALTER LOGIN sys_admin WITH PASSWORD = 'N3wS@Admin2024!'; -- 移除不必要的 Windows 登录 DROP LOGIN [BUILTIN\Administrators];

6. 从自查到测评通过：一套可复用的检查脚本思路

等保测评不是一次性的活，每年都要做。与其每次手工敲命令，不如写一套自查脚本，把五类数据库的检查项固化下来。我自己的习惯是按数据库类型分目录，每个目录下放一个检查脚本，输出统一格式的报告。

以 MySQL 为例，核心检查项用一条 SQL 汇总：

-- MySQL 等保自查汇总查询 SELECT '口令策略' AS check_item, VARIABLE_VALUE AS current_value, 'length>=8, policy=MEDIUM' AS requirement FROM performance_schema.global_variables WHERE VARIABLE_NAME IN ('validate_password.length', 'validate_password.policy') UNION ALL SELECT 'SSL状态', VARIABLE_VALUE, 'require_secure_transport=ON' FROM performance_schema.global_variables WHERE VARIABLE_NAME = 'require_secure_transport' UNION ALL SELECT '匿名账户', COUNT(*), '0' FROM mysql.user WHERE User = '' UNION ALL SELECT '空口令账户', COUNT(*), '0' FROM mysql.user WHERE authentication_string = '';

逻辑说明：performance_schema.global_variables在 MySQL 8.0 中替代了SHOW VARIABLES，可以直接用 SQL 查询。UNION ALL把多个检查项合并成一个结果集，方便导出成报告。注意validate_password相关变量只有在组件安装后才存在，脚本里要做异常处理。

Oracle 的自查可以用一个 PL/SQL 块：

-- Oracle 等保自查 SET SERVEROUTPUT ON DECLARE v_count NUMBER; BEGIN -- 检查默认账户状态 FOR rec IN (SELECT username, account_status, profile FROM dba_users WHERE username IN ('SCOTT','HR','OE','PM','IX','SH') AND account_status = 'OPEN') LOOP DBMS_OUTPUT.PUT_LINE('警告: 默认账户 ' || rec.username || ' 处于开启状态'); END LOOP; -- 检查 Profile 口令策略 FOR rec IN (SELECT profile, resource_name, limit FROM dba_profiles WHERE resource_name IN ('FAILED_LOGIN_ATTEMPTS','PASSWORD_LIFE_TIME') AND limit = 'UNLIMITED') LOOP DBMS_OUTPUT.PUT_LINE('警告: Profile ' || rec.profile || ' 的 ' || rec.resource_name || ' 未限制'); END LOOP; -- 检查审计是否开启 SELECT COUNT(*) INTO v_count FROM audit_unified_enabled_policies; IF v_count = 0 THEN DBMS_OUTPUT.PUT_LINE('警告: 未启用统一审计策略'); END IF; END; /

这套脚本的思路是：把等保条款翻译成可查询的 SQL 条件，输出「当前值 vs 要求值」的对照。每次测评前跑一遍，不符合的项直接改，比对着测评表逐条翻要快得多。

Redis 的自查用redis-cli脚本：

#!/bin/bash # Redis 等保自查脚本 REDIS_CLI="redis-cli -h 192.168.1.100 -p 6379 -a R3dis@Str0ng2024!" echo "=== Redis 等保自查 ===" # 检查密码 PASS=$($REDIS_CLI CONFIG GET requirepass | tail -1) if [ -z "$PASS" ]; then echo "[不符合] 未设置密码" else echo "[符合] 已设置密码" fi # 检查绑定地址 BIND=$($REDIS_CLI CONFIG GET bind | tail -1) echo "绑定地址: $BIND" # 检查危险命令 for cmd in FLUSHALL FLUSHDB KEYS CONFIG; do RESULT=$($REDIS_CLI COMMAND INFO $cmd | head -1) if [ -n "$RESULT" ]; then echo "[警告] 危险命令 $cmd 未禁用或重命名" fi done # 检查保护模式 PROTECTED=$($REDIS_CLI CONFIG GET protected-mode | tail -1) echo "保护模式: $PROTECTED"

参数说明：-a指定密码，生产环境建议用REDISCLI_AUTH环境变量避免密码出现在进程列表。COMMAND INFO返回空表示命令已被重命名或禁用。

最后说一个我自己的教训：第一次做等保的时候，我把所有配置都改好了，截图也交了，结果测评机构现场验证时发现 MySQL 的validate_password组件在重启后没加载，因为my.cnf里写的是plugin_load_add但路径不对。从那以后我养成了一个习惯——所有配置改完必须重启一次再验证，不重启不算完。希望帮到你。

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