简介面向等保测评人员与数据库运维管理员的实操型作业指导书覆盖MySQL、Oracle、SQL Server、Postgres、Redis五类常见数据库。文档以V1.1版本整理围绕测评工作中高频检查项展开先介绍各数据库通过CMD命令行与Workbench/SQLPlus等图形化工具的连接登录方法再逐项列出密码复杂度、密码有效期、登录失败处理措施、超时时间、用户与允许登录IP、审计功能、远程管理加密等关键查询语句并说明语句用途与执行后的判读思路方便测评现场直接对照使用。资源为1个docx文件压缩包大小1.83MB目录按数据库类型分为PART 1至PART 5每个数据库独立成章检索定位快捷可整包下载后打印或离线查阅。目前已有785人学习下载既适合等保测评新人按步骤入门也能作为一线测评人员处置Oracle、MySQL、SQLServer等数据库核查时的速查手册能明显缩短现场取证与结果记录时间。1. 等保测评作业指导书五套数据库怎么一次测明白等保测评现场最怕的不是规则难而是五套数据库摆在你面前每套都得当场拿出检查命令。MySQL 8.0、Oracle 19c、SQLServer 2019、Postgres 14、Redis 7各有各的口令策略、审计开关、权限模型和备份机制一套 SQL 通吃不了。这份作业指导书要解决的就是这个把等保2.0三级系统对数据库的要求翻译成每种库能直接执行的检查 SQL、参数命令和审计日志核对步骤让测评工程师和负责自查的 DBA 拿来就能测测完知道怎么判、怎么整改。适合三类人需要出报告的等保测评工程师、甲方自查的数据库管理员以及从运维转型做合规的技术人员。2. 等保三级数据库测评的通用框架检查项怎么拆、测评面怎么定2.1 等保2.0数据库测评控制点身份、访问、审计、备份四类等保2.0GB/T 22239-2019对数据库的要求分散在安全计算环境里真正需要落到数据库实例上的可以归纳成六个可测的面。测评时不用背整本标准按这张表逐项核就行测评面核心检查点数据库侧落点身份鉴别口令复杂度、定期更换、登录失败锁定、空口令/默认口令密码策略插件、账号有效期、失败锁定参数访问控制最小权限、默认账号整改、远程访问限制账号权限表、超级用户、默认库自带账号安全审计审计开启、覆盖到语句级、日志留存审计开关、审计表/日志文件、留存策略数据完整性传输完整性、存储完整性校验TLS/SSL、校验函数、副本一致性数据保密性敏感数据加密存储、加密传输TDE、字段加密、连接加密备份恢复本地备份、异地备份、周期性恢复验证备份工具、备份集时间线、恢复演练判断一个测评项是否“符合”核心是两条配置存在且生效、证据可追溯。比如 MySQL 里validate_password插件装了但没加载配置存在却不生效依然要判不符合。所以下面的实操章里所有命令都同时给了“查看配置”和“验证生效”两条路径。2.2 测评对象边界的三种定法实例级、库级、集群级现场最容易产生争议的是“测哪个”。常见做法是单机实例直接测整个实例一主一从或多从的复制架构主库必须测从库抽一台验证数据一致性和只读配置Redis 集群或哨兵架构每个节点都要做身份鉴别和危险命令检查然后抽一个 master 和一个 replica 做数据持久化验证。Oracle RAC 则要把集群当作一个逻辑实例检查crsctl stat res确认各节点状态同时在其中一个节点上执行账号和审计检查。边界定清楚后要把“测评对象清单”写进作业指导书开头列清每个对象的 IP、端口、版本、部署方式物理机/虚拟机/容器。这个清单也是后来填报告“测评范围”的直接素材。2.3 测评前资料收集架构图、口令策略、账号清单、备份策略动手测之前先发一份资料收集清单给客户通常包含六项数据库架构图含主从/集群关系、所有实例的版本和补丁信息、账号清单含应用账号和运维账号、口令策略制度文件、备份作业配置和执行记录、网络分区说明。缺哪一项测评当天就可能在某个检查项上卡住。比如没有备份执行记录就无法判定“备份恢复”这条是不是真做了。资料不全时不要硬着头皮开工。我一般会在首轮沟通里就把“备份执行记录”列为必交材料并说明这是测评项的直接证据。客户如果拿不出来测评结论会受影响提前讲清楚避免现场扯皮。3. 开源数据库测评实操MySQL 与 Postgres 的 SQL 检查和策略验证3.1 MySQL 身份鉴别与口令策略user 表、validate_password、连接锁定MySQL 的测评从账号清单开始。执行下面这组 SQL把实例里所有账号、主机、认证插件和口令散列拉出来-- 查看全部账号及认证插件 SELECT user, host, plugin, authentication_string FROM mysql.user; -- 找空口令或弱口令账号authentication_string 为空或太短 SELECT user, host FROM mysql.user WHERE authentication_string OR authentication_string IS NULL;第一条 SQL 是判定“默认账号是否整改”和“是否存在多余账号”的依据plugin列能看出是否用了caching_sha2_password这类安全插件。第二条查空口令测评标准里空口令账号直接判不符合。口令策略检查分版本看MySQL 5.7 用插件8.0 默认用组件。检查命令一样-- 查看口令策略参数 SHOW VARIABLES LIKE validate_password%; -- 查看登录失败锁定参数connection_control 或 8.0.19 自带策略 SHOW VARIABLES LIKE connection_control%;validate_password.policy有 LOW/MEDIUM/STRONG 三档测评至少要求 MEDIUM也就是密码必须同时包含数字、大小写字母和符号。connection_control_failed_connections_threshold是连续失败多少次后开始锁定通常要求不大于 5。注意 8.0 里如果没显式执行INSTALL COMPONENT file://component_validate_passwordSHOW VARIABLES是查不到这些参数的后面避坑章会展开讲。3.2 MySQL 访问控制与审计权限表、general_log、binlog 与审计插件访问控制检查分三步账号权限、库级授权、远程访问限制。-- 查看某账号的全部授权 SHOW GRANTS FOR appuser%; -- 查看所有库级授权 SELECT user, host, db, Select_priv, Insert_priv, Update_priv, Delete_priv FROM mysql.db;SHOW GRANTS是判定最小权限原则的核心命令测评时重点看应用账号有没有SUPER、GRANT OPTION这类越权权限。mysql.db表能看到授权是否精确到库如果出现appuser对*.*有写权限就要记一条不符合。审计检查先看开关再确认日志落盘-- 通用日志开关生产环境慎开 SHOW VARIABLES LIKE general_log%; -- binlog 是否开启也是审计依据之一 SHOW VARIABLES LIKE log_bin%; -- 企业版/Percona 审计插件状态 SHOW VARIABLES LIKE audit_log%;general_log记录所有语句生产库开了会拖垮性能测评时如果客户说“业务高峰期不能开”可以接受用 binlog 加慢日志组合做部分审计但要在报告里写明审计覆盖不全的残余风险。audit_log是企业版能力社区版没有遇到社区版就靠general_log和binlog取证。3.3 Postgres 身份鉴别与口令策略pg_hba.conf、password_encryption 与角色检查Postgres 的口令策略核心在pg_hba.conf这是客户端认证的“黑匣子”测评时先看它的认证方式-- 查看当前生效的 hba 规则 SELECT * FROM pg_hba_file_rules; -- 查看口令加密方式 SHOW password_encryption;pg_hba_file_rules能看到每条规则的认证方法测评要求不能出现trust认证md5视为弱加密建议scram-sha-256。password_encryption在 PostgreSQL 14 以上默认是scram-sha-256如果看到md5要记录。角色和登录权限检查-- 查看所有可登录角色 SELECT rolname, rolsuper, rolcanlogin, rolvaliduntil FROM pg_roles WHERE rolcanlogin true; -- 查看口令有效期没有设置则为永久 SELECT rolname, rolvaliduntil FROM pg_roles WHERE rolvaliduntil IS NOT NULL;rolsuper标记超级用户测评要求超级用户只保留给运维专用账号。rolvaliduntil对应口令有效期等保要求定期更换口令如果所有账号都没设置有效期这条只能判“不符合但风险可控”整改建议是引入密码管理平台或定期人工轮换。3.4 开源库的备份恢复验证与数据完整性检查备份这块 MySQL 和 Postgres 的做法不同。MySQL 常见逻辑备份mysqldump和物理备份xtrabackup验证方式是把备份恢复到一台临时实例上比对行数# 用 mysqldump 备份 mysqldump -u backup_user -p --single-transaction --routines --triggers appdb appdb_$(date %Y%m%d).sql # 恢复到临时实例验证 mysql -u root -p -e CREATE DATABASE appdb_restore; mysql -u root -p appdb_restore appdb_$(date %Y%m%d).sql # 比对关键表行数 mysql -u root -p -e SELECT COUNT(*) FROM appdb_restore.orders;--single-transaction保证备份时不影响线上写入--routines和--triggers不能漏否则恢复出来的库少了存储过程和触发器。恢复验证不能只跑通要抽几张核心表比对行数我见过备份恢复成功但某张表数据少了的情况就是没做行数核验。Postgres 用pg_basebackup做物理备份# 物理备份 pg_basebackup -D /backup/pg_$(date %Y%m%d) -Fp -Xs -P # 在临时实例上启动验证 pg_ctl -D /backup/pg_$(date %Y%m%d) -o -p 5433 start-Fp表示输出为普通格式目录-Xs用流复制模式同步 WAL 日志。验证时把备份目录当数据目录启一个临时实例端口错开比如 5433能正常起来且能查到最新数据这条才算过。4. 商用数据库测评实操Oracle 与 SQLServer 的配置项和审计日志核对4.1 Oracle 身份鉴别与口令策略DBA_USERS、DBA_PROFILES、PASSWORD_VERIFY_FUNCTIONOracle 的账号状态和口令策略都记录在数据字典里测评从这两条 SQL 开始-- 查看账号状态、锁定时间、过期时间 SELECT username, account_status, lock_date, expiry_date FROM dba_users ORDER BY username; -- 查看 DEFAULT Profile 的资源限制 SELECT resource_name, limit FROM dba_profiles WHERE profile DEFAULT AND resource_name IN (FAILED_LOGIN_ATTEMPTS, PASSWORD_LIFE_TIME, PASSWORD_LOCK_TIME, PASSWORD_VERIFY_FUNCTION);account_status如果出现OPEN但expiry_date是空的说明该账号口令永不过期这不符合“定期更换口令”的要求。FAILED_LOGIN_ATTEMPTS通常要求小于等于 5PASSWORD_LIFE_TIME要求小于等于 90PASSWORD_VERIFY_FUNCTION必须返回一个函数名为空就说明没启用口令复杂度校验。连库时遇到ORA-12541: TNS:no listener或监听服务无法启动不要急着改配置。先用lsnrctl status看监听状态再用tnsping测网络连通性最后才检查tnsnames.ora里的主机名和端口是否匹配。八成是监听没起或者端口被防火墙挡了跟数据库本身没关系。4.2 Oracle 审计audit_trail 参数、统一审计与传统审计记录Oracle 12c 以后有传统审计和统一审计两套体系19c 默认用统一审计。先看参数-- 审计开关 SHOW PARAMETER audit_trail; SHOW PARAMETER audit_sys_operations; SHOW PARAMETER audit_file_dest;audit_trail在 19c 里通常是DB或OSaudit_sys_operations必须为TRUE否则 SYSDBA 操作不留痕这条在三级等保里是硬指标。参数正确不代表审计一定在工作要实际查审计记录-- 统一审计记录取最近 20 条注意 ROWNUM 和排序的配合 SELECT os_username, username, action_name, return_code, event_timestamp FROM unified_audit_trail WHERE ROWNUM 20 ORDER BY event_timestamp DESC;ROWNUM 20的过滤和ORDER BY一起用有个经典坑先取行再排序结果不是真正的“最近 20 条”。Oracle 12c 可以用FETCH FIRST 20 ROWS ONLY替代写报告取证时别在这里翻车。另外要检查审计表空间是否够用传统审计模式下AUD$表所在表空间满了会停止写审计表现为“有审计开关但查不到新记录”。4.3 SQLServer 身份鉴别与登录审计CHECK_POLICY、错误日志与扩展事件SQLServer 的测评入口是登录账号和策略标记-- 查看所有 SQL 登录账号及密码策略标记 SELECT name, is_policy_checked, is_expiration_checked FROM sys.sql_logins ORDER BY name; -- 查看服务器审计配置 SELECT name, status_desc, current_state_desc FROM sys.server_audits;is_policy_checked对应 Windows 密码策略是否强制is_expiration_checked对应口令是否定期过期两个都为 1 才算符合。很多客户的应用账号是历史遗留这俩字段都是 0测评记录里要单列。审计这块SQLServer 从 2012 起建议用服务器审计Server Audit检查current_state_desc是否为ON再确认审计是否覆盖到FAILED_LOGIN_GROUP这类登录失败事件。旧版本可以看错误日志里是否有登录失败记录但那是间接证据能上 Server Audit 就不要用错误日志凑数。4.4 SQLServer 数据加密与备份检查TDE、备份历史与恢复验证SQLServer 的数据保密性检查集中在 TDE透明数据加密-- 查看所有开启了 TDE 的数据库及加密状态 SELECT DB_NAME(database_id) AS db_name, encryption_state, percent_complete FROM sys.dm_database_encryption_keys;encryption_state 3表示已加密2表示正在加密0表示未加密。等保三级不强制所有库都加密但包含敏感业务数据的库必须加密这个判定要结合客户的业务资产清单来定。备份检查先看备份历史-- 查看各库最近备份情况 SELECT database_name, backup_start_date, type, backup_size / 1024 / 1024 AS size_mb FROM msdb.dbo.backupset ORDER BY backup_start_date DESC;type字段D是全量、I是差异、L是日志。测评要求“本地备份异地备份定期恢复验证”三者齐备只看备份集还不够要拿一份最近的备份执行恢复验证-- 验证备份文件完整性不用恢复即可校验 RESTORE VERIFYONLY FROM DISK ND:\backup\appdb_20250101.bak;RESTORE VERIFYONLY只校验备份集可读性速度快、不影响线上是现场验证的首选。如果客户声称做了恢复演练要求他们提供演练记录内的日志截图只有备份文件没有恢复记录的备份恢复这条最多判“部分符合”。5. 等保测评避坑五个高频踩坑点的现场排查5.1 现象一MySQL 的 validate_password 参数查不到现场执行SHOW VARIABLES LIKE validate_password%返回空但客户的等保自查报告里说已开启密码复杂度。原因大概率是 MySQL 8.0 的 validate_password 是组件不是插件默认只安装未启用需要执行INSTALL COMPONENT file://component_validate_password才生效。解决先查mysql.component表确认组件是否注册再 INSTALL然后重新查参数。这条务必在测评前确认亲手执行过才算数不能只看客户提供的截图。这也解释了为什么有人用docker 安装 MySQL搭测评环境时会遇到类似问题——容器镜像默认精简了组件注册步骤。5.2 现象二Oracle 审计开关开了审计表却查不到记录SHOW PARAMETER audit_trail显示DB但SELECT COUNT(*) FROM dba_audit_trail是 0。先查audit_sys_operations是否为 TRUE再看是不是 19c 默认统一审计接管了传统审计。19c 里传统审计参数即使设置为 DB实际写入的也可能是UNIFIED_AUDIT_TRAIL。解决用SELECT COUNT(*) FROM unified_audit_trail查统一审计记录同时确认AUD$表空间没满。另一个常见原因是客户只开了审计参数没执行具体审计策略比如没写AUDIT LOGON登录行为就永远不会被记录这种情况要判定“审计策略不完整”。5.3 现象三SQLServer 开启 CHECK_POLICY 后应用账号全部登录失败整改现场把应用账号的is_policy_checked设为 1结果应用连接池瞬间打爆报密码过期或密码不符合策略。原因很简单存量密码本身不符合 Windows 密码复杂度策略策略一旦强制旧密码直接失效。解决先在开发或测试实例上执行ALTER LOGIN appuser WITH CHECK_POLICY ON, CHECK_EXPIRATION ON观察连接是否正常如果失败先把密码改成强密码再开策略顺序反了必出事故。生产环境做这条整改建议选在发布窗口别在业务高峰期碰。5.4 现象四Redis 修改 requirepass 后主从复制立刻断连测评要求 Redis 必须开启密码认证客户整改时只改了 master 的requirepass忘记配置 replica 的masterauth结果主从复制中断业务读请求全部打到从库报错。解决改配置必须按“从库先行”的顺序先给每个 replica 配好masterauth再动 master 的requirepass。如果已经断连先把从库的masterauth补上再执行REPLICAOF NO ONE再REPLICAOF master_ip master_port重新建立复制关系。这条在 Redis 哨兵和集群架构下同样适用节点间认证是独立于客户端认证的另一层配置。5.5 现象五备份检查只看到备份文件没验证可恢复性客户提供了近一个月的备份文件列表时间线看着完整但现场抽查发现某天的备份文件大小异常只有正常值的十分之一。原因是当时磁盘快满了备份作业中途失败但告警没被处理客户只看备份脚本跑完就以为成功了。解决测评时不能只看备份文件是否存在要抽查文件大小、执行RESTORE VERIFYONLY或mysqlbackup --apply-log做完整性校验并核对备份日志里的返回码。备份这关的判定标准不是“有备份”而是“备份可恢复”数据恢复不了备份等于白做。6. 从测评结果到整改验收报告编制技巧与整改清单闭环6.1 测评记录与证据截图、输出重定向与判定依据现场测评时养成的习惯是每执行一条检查命令把输出重定向到一个按实例分目录的结果文件夹里同时保留一份终端截图。比如 MySQL 的检查结果存成mysql_8.0_node1_variables.txtOracle 的审计查询结果存成oracle_19c_node1_audit.sql.out。这样做既方便写报告时摘录证据也避免客户口头说“我们没问题”时拿不出凭据。6.2 整改项分级与整改清单报告里把整改项分成三级紧急项空口令、信任认证、审计未开启、备份从未验证、重要项口令策略强度不够、账号权限过大、审计留存不足 6 个月、一般项口令有效期未设置、警告日志未接入监控。每一条整改项写成一行清单注明对应测评编号、责任角色、建议方案和期望完成时间。客户按这张清单逐条整改下次复测时对照销项效率比翻报告高很多。6.3 整改验收的核心技巧验证一条、销号一条整改验收的常见误区是客户说“改完了”就复测实际配置没生效。我的验收习惯是让客户提供每个整改项的配置命令输出和生效时间再复测时把原来那套检查命令重新跑一遍并对比输出。口令策略改了就看SHOW VARIABLES返回的新值审计开了就看审计表里有没有新增日志。每确认一条在整改清单里销一条最终把剩余风险控制到可接受范围内。这些年做下来最大的教训就是“别信截图只看现场执行结果”——检查命令的输出可以造假但现场跑一遍骗不了人。希望这份作业指导书能让你下次做等保测评时少踩几个坑五套库一次过。本文还有配套的精品资源点击获取