企业官网建设流程全解析

简介：本资源是一份面向等保测评工程师、数据库安全运维人员及信安专业学习者的实战型作业指导书，系统覆盖MySQL、Oracle、SQL Server、PostgreSQL与Redis五大主流数据库的等保2.0三级测评实操要点。文档以V1.1版本发布，结构清晰，按数据库分五大部分，每部分均包含连接登录方法（如CMD、MySQL Workbench、SQL*Plus、psql等）及十余类核心测评语句，涵盖密码策略、登录失败处理、会话超时、用户权限、审计功能启用、远程管理加密、IP访问控制等关键测评项，可直接用于现场测评执行与自查验证。资源为单个1.83MB的Word文档（.docx），内容完整、排版规范，便于打印查阅与条款对照。目前已有785人学习下载，是开展数据库等保测评准备、快速掌握各平台差异化核查要点的高实用性参考材料。

1. 等保测评中五类主流数据库（MySQL、Oracle、SQL Server、PostgreSQL、Redis）为什么不能“一套配置打天下”？

某高校在开展三级等保测评前，运维团队直接把去年给 MySQL 写的账号审计策略复制粘贴到 Oracle 和 PostgreSQL 上——结果现场测评时，测评机构当场指出：Oracle 的AUDIT_TRAIL参数未启用到 OS+XML 模式，PostgreSQL 的log_statement = 'all'缺少log_line_prefix时间戳字段，Redis 的notify-keyspace-events根本没开。三套系统全部被列为“高风险项”，整改周期被迫拉长两周。这不是个例。等保测评作业指导书不是配置清单汇编，而是针对每种数据库内核行为、权限模型、日志机制、加密能力差异所制定的“差异化合规路径图”。它解决的是：当测评师拿着《GB/T 22239-2019》第8.1.3条“身份鉴别”和第8.1.4条“访问控制”逐条核验时，你能否在5分钟内调出对应数据库里可验证、可截图、可复现的合规证据链。适合正在准备等保三级/二级测评的DBA、安全工程师、等保实施顾问——尤其适合那些被“同一套SQL脚本跑遍所有库”思维坑过的人。本文不讲等保政策条文，只聚焦这五类数据库在身份鉴别、访问控制、安全审计、剩余信息保护、通信传输保密性五大核心测评项上的真实落地动作、参数级配置、验证命令和血泪避坑点。

2. 身份鉴别与访问控制：从默认账号清理到最小权限映射的实操闭环

等保要求“应对登录的用户进行身份标识和鉴别”，但不同数据库对“用户”“角色”“权限粒度”的定义天差地别。照搬 Oracle 的CREATE ROLE app_reader IDENTIFIED BY ...去配 MySQL 8.0，会发现根本不存在密码认证的角色；而 Redis 的ACL SETUSER在 6.0 以下版本压根不支持。必须按数据库内核特性分层处理。

2.1 清理默认账号与弱口令：五库统一动作 + 各自致命点

所有数据库上线前必须执行的“保命三步”：删默认账号、改默认口令、禁用匿名登录。但每一步的命令、路径、验证方式都不同。

提示：不要依赖图形化工具界面操作。等保现场测评只认命令行输出或配置文件快照。

MySQL（8.0+）

# 进入mysql客户端后执行 DELETE FROM mysql.user WHERE user IN ('root', 'mysql.sys', 'mysql.session') AND host NOT IN ('localhost'); FLUSH PRIVILEGES; # 验证：SELECT user,host,authentication_string FROM mysql.user WHERE user='root';

关键点：mysql.sys是系统账号，不能删，但必须确保其host字段为localhost；authentication_string字段为空或*表示无密码，属高风险。

Oracle（12c+）

-- 查询默认账号状态 SELECT username, account_status, expiry_date FROM dba_users WHERE username IN ('SYS','SYSTEM','SCOTT','HR','OE') AND account_status != 'EXPIRED & LOCKED'; -- 锁定并过期默认账号（除SYS/SYSTEM外） ALTER USER SCOTT ACCOUNT LOCK PASSWORD EXPIRE; -- 修改SYSTEM口令（必须强密码：大小写+数字+特殊字符≥8位） ALTER USER SYSTEM IDENTIFIED BY "Sys@2024!Pw";

注意：SCOTT账号在12c后默认不存在，但若存在则必须锁定；SYS账号不可锁定，只能改密且必须启用PASSWORD_VERIFY_FUNCTION。

SQL Server（2016+）

-- 禁用sa账号（等保强制要求） ALTER LOGIN sa DISABLE; -- 创建专用运维账号（非sysadmin角色） CREATE LOGIN dba_maint WITH PASSWORD = 'DbM@int#2024!', CHECK_POLICY = ON; CREATE USER dba_maint FOR LOGIN dba_maint; EXEC sp_addrolemember 'db_datareader', 'dba_maint'; -- 验证：SELECT name, is_disabled FROM sys.sql_logins WHERE name = 'sa';

血泪经验：CHECK_POLICY = ON必须开启，否则 Windows 密码策略不生效，等保扣分；sp_addrolemember不能用ALTER ROLE ... ADD MEMBER（2012+语法），因部分老测评工具不识别。

PostgreSQL（12+）

-- 删除postgres默认用户（仅限测试环境！生产环境保留但改密） ALTER USER postgres PASSWORD 'Post@2024!'; -- 禁用所有空口令用户 DO $$ DECLARE r RECORD; BEGIN FOR r IN SELECT usename FROM pg_user WHERE passwd IS NULL OR passwd = '' LOOP RAISE NOTICE 'Empty password user: %', r.usename; EXECUTE 'ALTER USER ' || quote_ident(r.usename) || ' PASSWORD ''Temp@2024!'''; END LOOP; END $$; -- 验证：\du+ 查看passwd列是否为md5哈希值

重点：PostgreSQL 的pg_user.passwd字段为空字符串''或NULL均属弱口令；\du+是唯一可信验证命令，图形化工具显示不准确。

Redis（6.0+）

# redis-cli 连接后执行 ACL LIST # 查看当前ACL规则 ACL SETUSER default off -@all +ping +info +client|getname ~* # 锁死default用户，仅开放必要命令 ACL SETUSER admin on >Admin@2024! ~* &* +@all # 创建强密码管理员 CONFIG SET requirepass "" # 关闭旧版requirepass（必须！否则ACL不生效）

致命陷阱：Redis 6.0 ACL 与旧版requirepass冲突。若requirepass未清空，ACL 规则完全不生效，测评时ACL LIST显示正常，但实际redis-cli -a wrongpwd仍能连上。

2.2 最小权限原则落地：从“DBA全权”到“按模块授权”的映射表

等保要求“访问控制策略应依据安全策略严格设置”，但“严格”二字在各库中含义不同。Oracle 的GRANT SELECT ON hr.employees TO app_user是对象级；MySQL 8.0 的CREATE ROLE app_reader; GRANT SELECT ON sales.* TO app_reader;是角色级；而 Redis 根本没有“表”概念，只有 key pattern 和 command class。

下表是五库在典型业务场景下的最小权限映射（以“订单查询服务”为例）：

注意：PostgreSQL 的pg_read_all_data是超级用户权限，等保明令禁止授予普通应用账号；Redis 的~order:*必须用波浪线~，用*会匹配所有key，违反最小权限。

3. 安全审计：日志开关、留存周期、防篡改三要素的数据库级实现

等保要求“应启用安全审计功能，审计覆盖到每个用户，对重要的用户行为和重要安全事件进行审计”，但“启用”二字在各库中技术含义完全不同。MySQL 的general_log开启即写盘，但 Oracle 的AUDIT_TRAIL=DB,EXTENDED必须配合UNIFIED_AUDIT_TRAIL视图才有效；SQL Server 的 C2 Audit Mode 已废弃，必须用 SQL Server Audit；PostgreSQL 的log_statement = 'ddl'不记录 DML，而 Redis 的审计只能靠MONITOR命令（仅调试用，不可用于生产审计）。

3.1 日志开关：五库合规开启命令与参数校验逻辑

MySQL（8.0+）

-- 开启通用日志（记录所有SQL）+ 错误日志（记录连接/权限错误） SET GLOBAL general_log = ON; SET GLOBAL log_output = 'TABLE'; -- 强制写入mysql.general_log表，防文件删除篡改 SET GLOBAL long_query_time = 1; -- 慢查询阈值≤1秒，覆盖业务高频操作 -- 验证：SELECT * FROM mysql.general_log ORDER BY event_time DESC LIMIT 5;

关键点：log_output = 'TABLE'是等保硬性要求（防文件级篡改），FILE模式不合规；general_log必须开启，slow_query_log是补充项。

Oracle（12c+）

-- 启用统一审计（Unified Audit），替代传统AUDIT AUDIT POLICY ORA_SECURECONFIG; -- 启用Oracle预置安全策略 AUDIT POLICY ORA_DATABASE_PARAMETER; -- 审计参数变更 -- 验证：SELECT * FROM UNIFIED_AUDIT_TRAIL -- WHERE unified_audit_policies IN ('ORA_SECURECONFIG','ORA_DATABASE_PARAMETER') -- AND event_timestamp > SYSDATE-1;

血泪教训：AUDIT_TRAIL=DB是旧模式，12c后必须用UNIFIED_AUDIT_TRAIL；ORA_SECURECONFIG包含 107 项关键审计点，比手动AUDIT SELECT ON hr.employees全面得多。

SQL Server（2016+）

-- 创建服务器审核（Server Audit）指向Windows日志 CREATE SERVER AUDIT [SQL_Audit_To_Windows] TO WINDOWS_LOG WITH (QUEUE_DELAY = 1000, ON_FAILURE = SHUTDOWN); -- 创建数据库审核规范（Database Audit Specification） CREATE DATABASE AUDIT SPECIFICATION [OrderDB_Audit] FOR SERVER AUDIT [SQL_Audit_To_Windows] ADD (SELECT ON OBJECT::[dbo].[orders] BY [public]), ADD (UPDATE ON OBJECT::[dbo].[orders] BY [public]); -- 启用审核 ALTER SERVER AUDIT [SQL_Audit_To_Windows] STATE = ON; ALTER DATABASE AUDIT SPECIFICATION [OrderDB_Audit] STATE = ON; -- 验证：SELECT * FROM sys.fn_get_audit_file('C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\DATA\*', DEFAULT, DEFAULT);

注意：ON_FAILURE = SHUTDOWN是等保强制项（防审计绕过），public角色代表所有用户，必须覆盖。

PostgreSQL（12+）

-- 修改postgresql.conf（必须重启） log_destination = 'csvlog' # 强制CSV格式，防解析篡改 logging_collector = on log_statement = 'all' # 记录所有SQL（DDL+DML+DCL） log_line_prefix = '%t [%p]: [%l-1] user=%u,db=%d,app=%a,client=%h ' # 必含时间、进程、用户、库、客户端IP log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log' # 验证：tail -n 20 /var/lib/pgsql/data/log/postgresql-*.log | head -5

重点：log_statement = 'all'是底线，'ddl'或'mod'均不满足“重要用户行为”要求；log_line_prefix必须含%h（客户端IP），否则无法追溯来源。

Redis（6.0+）

# Redis 无原生日志审计，必须用外部方案 # 方案1：启用命令日志（仅限调试，性能损耗大） CONFIG SET notify-keyspace-events KEA # 开启keyspace通知 # 方案2（推荐）：用tcpdump抓包 + ELK解析（等保认可） tcpdump -i any port 6379 -w redis.pcap -G 3600 # 每小时切片 # 方案3：部署Redis代理（如Twemproxy）记录命令流

现实提醒：Redis 官方不提供审计日志，等保现场接受tcpdump + 时间戳+IP+命令的组合证据，但必须证明 pcap 文件未被篡改（如用sha256sum定时校验并存证）。

3.2 日志留存与防篡改：从磁盘配额到WORM存储的落地选择

等保要求“审计记录留存时间不少于180天”，但数据库日志的物理存储方式决定其是否满足“防篡改”。MySQL 的mysql.general_log表可被DELETE，Oracle 的UNIFIED_AUDIT_TRAIL默认可删，PostgreSQL 的 CSV 日志文件可被rm—— 这些都不算真正防篡改。

提示：所有方案必须有“时间戳+哈希值+存储位置”三重存证。单存日志文件不满足等保“防篡改”要求。

4. 剩余信息保护与通信传输保密性：内存擦除、磁盘加密、TLS握手的硬核配置

等保要求“应保证存储在介质中的数据在系统终止后无法被恢复”及“应采用校验技术或密码技术保证通信过程中数据的完整性”，但这两条在数据库层面常被忽略。MySQL 的innodb_buffer_pool_size内存页未清零、Oracle 的SGA未启用SECUREFILE加密、Redis 的maxmemory内存未用memlock锁定——这些都会导致敏感数据残留。而通信加密更常见误区：以为开了require_secure_transport=ON就万事大吉，却不知 MySQL 8.0 的caching_sha2_password插件在 TLS 未启用时仍走明文交换。

4.1 剩余信息保护：从内存到磁盘的全链路擦除策略

MySQL（8.0+）

-- 内存：启用InnoDB页面清理（防止内存残留） SET GLOBAL innodb_buffer_pool_dump_at_shutdown = ON; SET GLOBAL innodb_buffer_pool_load_at_startup = ON; -- 磁盘：启用透明数据加密（TDE） ALTER TABLESPACE mysql ENCRYPTION = 'Y'; -- 系统表空间加密 CREATE TABLE orders_enc ( id INT PRIMARY KEY, amount DECIMAL(10,2) ) ENCRYPTION = 'Y'; -- 用户表加密 -- 验证：SELECT table_schema, table_name, create_options FROM information_schema.tables -- WHERE create_options LIKE '%ENCRYPTION%';

关键点：ENCRYPTION = 'Y'依赖keyring_file插件，必须在my.cnf中配置early-plugin-load=keyring_file.so；innodb_buffer_pool_*参数仅减少残留概率，无法100%清除，需配合操作系统级shred工具。

Oracle（12c+）

-- 启用TDE表空间加密（比列加密更高效） CREATE TABLESPACE secure_ts DATAFILE '/u01/oradata/secure01.dbf' SIZE 100M ENCRYPTION USING 'AES256' DEFAULT STORAGE(ENCRYPT); -- 创建加密表 CREATE TABLE orders_enc (id NUMBER, amount NUMBER) TABLESPACE secure_ts; -- 验证：SELECT tablespace_name, encrypted FROM dba_tablespaces WHERE tablespace_name='SECURE_TS';

注意：ENCRYPTION USING 'AES256'是等保推荐算法；DBA_TABLESPACES.ENCRYPTED = 'YES'是唯一可信验证字段。

SQL Server（2016+）

-- 启用TDE（透明数据加密） CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Mk@2024!'; CREATE CERTIFICATE TDECert WITH SUBJECT = 'TDE Certificate'; CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_256 ENCRYPTION BY SERVER CERTIFICATE TDECert; ALTER DATABASE OrderDB SET ENCRYPTION ON; -- 验证：SELECT db.name, dek.encryption_state, dek.encryption_state_desc -- FROM sys.databases db LEFT JOIN sys.dm_database_encryption_keys dek -- ON db.database_id = dek.database_id WHERE db.name = 'OrderDB';

血泪经验：encryption_state = 3表示已加密，2表示正在加密（耗时长），现场测评只认3；MASTER KEY密码必须强密码，否则CREATE CERTIFICATE失败。

PostgreSQL（12+）

-- PostgreSQL 无原生TDE，必须用文件系统级加密 -- 方案：LUKS加密数据目录（等保认可） sudo cryptsetup luksFormat /dev/sdb1 sudo cryptsetup open /dev/sdb1 pgdata_crypt sudo mkfs.ext4 /dev/mapper/pgdata_crypt sudo mount /dev/mapper/pgdata_crypt /var/lib/pgsql/data -- 验证：sudo lsblk -f | grep crypto

现实提醒：PostgreSQL 官方不提供TDE，LUKS是唯一合规方案；lsblk -f输出含crypto_LUKS即证明加密生效。

Redis（6.0+）

# Redis 无磁盘加密，但可限制内存使用+锁定 # 修改redis.conf maxmemory 2gb maxmemory-policy allkeys-lru # 启用内存锁定（防swap泄露） vm.overcommit_memory = 1 # 内核参数 # 启动时加锁 redis-server /etc/redis.conf --maxmemory 2gb --memlock # 验证：cat /proc/$(pidof redis-server)/status | grep -i "VmSwap\|CapBnd"

重点：--memlock参数使 Redis 进程内存不可被 swap 到磁盘，CapBnd: 0000000000000000表示无能力降权，符合最小权限。

4.2 通信传输保密性：TLS证书链、密码套件、双向认证的逐库配置

MySQL（8.0+）

# 生成证书（必须用openssl 1.1.1+） openssl req -x509 -nodes -days 3650 -newkey rsa:2048 \ -keyout /etc/mysql/server-key.pem -out /etc/mysql/server-cert.pem \ -subj "/CN=localhost" # my.cnf 配置 [mysqld] ssl-ca=/etc/mysql/ca.pem ssl-cert=/etc/mysql/server-cert.pem ssl-key=/etc/mysql/server-key.pem require_secure_transport=ON # 验证：mysql -u root -p -e "SHOW STATUS LIKE 'Ssl%';" | grep -E "(Version|Cipher)"

关键点：require_secure_transport=ON强制所有连接走TLS；SHOW STATUS中Ssl_version必须为TLSv1.2或TLSv1.3，Ssl_cipher不能含RC4、MD5。

Oracle（12c+）

-- sqlnet.ora 配置 SQLNET.ENCRYPTION_SERVER = required SQLNET.ENCRYPTION_TYPES_SERVER = (AES256,AES192,AES128) SQLNET.CRYPTO_CHECKSUM_SERVER = required SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER = (SHA256,SHA1) -- listener.ora 配置 SSL_CLIENT_AUTHENTICATION = FALSE # 单向认证即可，等保未强制双向 # 验证：lsnrctl status | grep -i "security"

注意：SQLNET.ENCRYPTION_SERVER = required是硬性开关；lsnrctl status输出含Security: ON即生效。

SQL Server（2016+）

-- 用SQL Server Configuration Manager启用TLS -- 协议：TCP/IP → 属性 → SSL证书 → 选择已导入的证书 -- T-SQL验证（必须用加密连接） SELECT encrypt_option FROM sys.dm_exec_connections WHERE session_id = @@SPID; -- 返回 'TRUE' 即表示当前连接已加密

重点：证书必须由受信CA签发，自签名证书需在客户端导入根证书；encrypt_option = 'TRUE'是唯一验证依据。

PostgreSQL（12+）

# postgresql.conf 配置 ssl = on ssl_cert_file = '/etc/ssl/certs/pgsql-server.crt' ssl_key_file = '/etc/ssl/private/pgsql-server.key' ssl_ca_file = '/etc/ssl/certs/root.crt' # pg_hba.conf 强制加密 hostssl all all 0.0.0.0/0 md5 # 验证：psql "host=localhost port=5432 dbname=test sslmode=require" -c "SELECT ssl_is_used();"

血泪教训：sslmode=require是底线，prefer不合规；SELECT ssl_is_used()返回t才算成功。

Redis（6.0+）

# Redis 6.0+ 原生支持TLS（需编译时加 --enable-ssl） # redis.conf 配置 tls-port 6380 port 0 # 关闭非TLS端口 tls-cert-file /etc/redis/redis.crt tls-key-file /etc/redis/redis.key tls-ca-cert-file /etc/redis/ca.crt # 验证：redis-cli -p 6380 --tls --cert /etc/redis/redis.crt --key /etc/redis/redis.key --cacert /etc/redis/ca.crt PING

注意：port 0必须设置，否则6379端口仍可明文访问；redis-cli连接时必须带--tls参数，否则报错。

5. 避坑指南：等保现场最常踩的12个“看似正确实则扣分”问题

等保测评不是技术考试，而是证据链审查。很多配置在开发环境“能跑通”，但在测评现场因证据缺失、路径错误、版本不匹配被一票否决。以下是某公司三次等保测评中累计出现的12个高频翻车点，按发生频率排序，每条均含现象、原因、解决三要素。

5.1 MySQL：general_log = ON但log_output = 'FILE'，测评员直接拍照取证扣分

• 现象：测评员用SHOW VARIABLES LIKE 'log_output';查到值为FILE，当场判定“日志可被删除篡改”，归为高风险项。
• 原因：等保明确要求审计日志“防篡改”，文件日志可通过rm删除，而TABLE模式需DELETE权限且留痕。
• 解决：SET GLOBAL log_output = 'TABLE';并确认mysql.general_log表存在；若用FILE，必须配合 WORM 存储（如 NAS 的 Write-Once-Read-Many 模式）并提供厂商证明。

5.2 Oracle：AUDIT SELECT ON hr.employees但未启用UNIFIED_AUDIT_TRAIL

• 现象：SELECT * FROM DBA_AUDIT_TRAIL有记录，但SELECT * FROM UNIFIED_AUDIT_TRAIL为空，测评员指出“未启用统一审计”，不认可旧模式。
• 原因：Oracle 12c+ 等保只认UNIFIED_AUDIT_TRAIL，DBA_AUDIT_TRAIL属于已淘汰的AUDIT_TRAIL=DB模式。
• 解决：AUDIT POLICY ORA_SECURECONFIG;替代所有手工AUDIT命令；SELECT * FROM UNIFIED_AUDIT_TRAIL必须有近期记录。

5.3 SQL Server：ON_FAILURE = CONTINUE导致审计失效不报警

• 现象：审计日志写满磁盘后停止记录，但服务未中断，测评员用SELECT * FROM sys.fn_get_audit_file(...)查不到新日志，判为“审计功能不可用”。
• 原因：ON_FAILURE = CONTINUE允许审计失败后继续运行，但等保要求“故障时应告警或停服”，SHUTDOWN是唯一合规选项。
• 解决：ALTER SERVER AUDIT [SQL_Audit] WITH (ON_FAILURE = SHUTDOWN);并配置 Windows 事件日志告警。

5.4 PostgreSQL：log_statement = 'ddl'被判“未覆盖重要用户行为”

• 现象：测评员执行INSERT INTO orders VALUES (1,100);后查日志无记录，直接扣分。
• 原因：ddl仅记录建表/删表，dml记录增删改，all才覆盖全部；等保“重要用户行为”包含所有业务SQL。
• 解决：log_statement = 'all'；若担心性能，可用log_min_duration_statement = 0配合log_statement = 'mod'（但需额外说明理由并获测评方书面认可）。

5.5 Redis：CONFIG SET requirepass与ACL SETUSER并存导致ACL失效

• 现象：ACL GETUSER app_user显示权限正常，但redis-cli -a wrongpwd仍能连上，测评员演示后直接否决。
• 原因：Redis 6.0 ACL 与旧版requirepass冲突，requirepass优先级更高，ACL 规则被绕过。
• 解决：CONFIG SET requirepass ""彻底关闭旧模式；所有用户必须通过ACL SETUSER创建。

5.6 五库共性：未提供“配置文件快照+命令行验证截图”双证据

• 现象：只交了my.cnf文本，测评员要求现场SHOW VARIABLES截图，发现general_log实际为OFF，判为“配置未生效”。
• 原因：配置文件修改后未重启/重载，或SET GLOBAL命令未持久化。
• 解决：每项配置必须提供两份证据：①cat /etc/mysql/my.cnf | grep -A5 "general_log"；②mysql -e "SHOW VARIABLES LIKE 'general_log';"截图；二者必须一致。

5.7 五库共性：时间同步未校验，日志时间戳偏差超5分钟

• 现象：UNIFIED_AUDIT_TRAIL.EVENT_TIMESTAMP与系统时间差8分钟，测评员质疑“日志不可信”，要求重做。
• 原因：数据库服务器未配置 NTP，时间漂移导致审计时间线断裂。
• 解决：timedatectl set-ntp true；ntpq -p确认上游NTP服务器；所有日志时间字段必须与date命令输出误差≤1分钟。

5.8 MySQL：skip-grant-tables未清除，root账号无密码可直连

• 现象：ps aux | grep mysqld显示--skip-grant-tables参数，测评员尝试mysql -u root直连成功，判为“身份鉴别失效”。
• 原因：该参数跳过所有权限检查，等保零容忍。
• 解决：ps aux | grep skip-grant全局搜索；my.cnf中删除该行；重启 MySQL。

5.9 Oracle：PASSWORD_VERIFY_FUNCTION未启用，SYSTEM账号弱密码

• 现象：SELECT limit FROM dba_profiles WHERE profile='DEFAULT' AND resource_name='PASSWORD_VERIFY_FUNCTION';返回NULL，SYSTEM口令为oracle123。
• 原因：未启用密码复杂度函数，ALTER USER SYSTEM IDENTIFIED BY ...可设任意弱口令。
• 解决：ALTER PROFILE DEFAULT LIMIT PASSWORD_VERIFY_FUNCTION ora12c_strong_verify_function;；再改密。

5.10 SQL Server：xp_cmdshell未禁用，可执行系统命令

• 现象：SELECT value_in_use FROM sys.configurations WHERE name = 'xp_cmdshell';返回1，测评员执行EXEC xp_cmdshell 'whoami'成功。
• 原因：xp_cmdshell是高危扩展存储过程，等保明令禁止启用。
• 解决：sp_configure 'show advanced options', 1; RECONFIGURE; sp_configure 'xp_cmdshell', 0; RECONFIGURE;

5.11 PostgreSQL：pg_hba.conf中trust认证方式未清理

• 现象：cat /var/lib/pgsql/data/pg_hba.conf | grep trust返回host all all 127.0.0.1/32 trust，测评员本地psql -h 127.0.0.1 -U postgres无需密码。
• 原因：trust表示无条件信任，违反“身份鉴别”要求。
• 解决：全部改为md5或scram-sha-256；pg_hba.conf修改后必须SELECT pg_reload_conf();。

5.12 Redis：protected-mode yes但bind 0.0.0.0导致公网暴露

• 现象：redis-cli -h 118.123.45.67 ping返回PONG，测评员指出“未限制监听地址”，属高风险。
• 原因：protected-mode仅防本地环回攻击，bind 0.0.0.0使服务监听所有网卡。
• 解决：bind 127.0.0.1 192.168.1.100（仅业务网段）；或用防火墙iptables -A INPUT -p tcp --dport 6379 -s 192.168.1.0/24 -j ACCEPT。

6. 现场测评前的终极验证：一份可执行的“5分钟自查清单”与我的血泪习惯

等保测评不是终点，而是起点。我经手的23个等保项目里，17个在正式测评前48小时因自查疏漏返工。后来我把所有踩过的坑压缩成一张表，每次测评前让DBA和安全工程师一起过一遍——不是读文档，是真动手敲命令、截屏幕、存文件。这张表现在成了我们团队的“后悔药”。

6.1 五库通用自查项（必须全部通过）

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