数据库安全基线检查项与自动化脚本

数据库安全基线并非一份虚无缥缈的清单，而是防止低级错误导致数据泄露的最后一道实体防线。绝大多数针对数据库的入侵并非利用零日漏洞，而是利用了默认端口未修改、默认口令未删除或高危权限未回收这些基础配置失误。安全基线检查的核心逻辑是将这些配置固化为可重复执行的自动化脚本，让每一次检查都得出确定性的结果，而非依赖人工抽查的随机性。

数据库账户是攻击者最垂涎的入口。检查的第一步必须锁定高权限账户的分布情况。很多生产环境仍然保留着安装时创建的测试账户或出厂默认账户，这些账户往往拥有极高的权限且密码广为人知。使用自动化脚本定期扫描账户表，筛选出具有超级管理员权限或数据库所有者权限的账户列表，并与白名单进行比对。一旦发现非白名单内的高权限账户，应立即触发告警。密码策略同样是重灾区。检查项必须覆盖密码复杂度校验是否开启、密码过期锁定策略是否生效以及是否存在空口令账户。对于MySQL，可以通过查询mysql.user表直接提取plugin字段，确认是否使用了mysql_native_password这种弱认证插件，并推动向caching_sha2_password迁移。对于PostgreSQL，则需要检查pg_hba.conf文件中是否仍然存在trust认证方式，这种无密码登录方式在容器化部署时极易被误开启。

权限泛滥是数据泄漏的主要推手。业务应用常常因为调试方便被直接授予ALL PRIVILEGES，这种粗放管理必须通过基线脚本进行量化约束。检查脚本需要直接查询系统权限表，分析是否存在针对整个数据库或关键业务表的SELECT ... GRANT OPTION权限。特别需要关注的是具备WITH GRANT OPTION或WITH ADMIN OPTION的账户，这些账户能够将权限二次授予其他用户，形成权限扩散。对于Oracle数据库，需要检查DBA角色被授予的情况，以及是否存在直接授予UNLIMITED TABLESPACE的系统权限。网络层面的访问控制同样不可忽视。脚本应当检测数据库监听地址是否绑定在0.0.0.0，如果业务不需要远程访问，必须强制修改为127.0.0.1或内网地址。同时检查防火墙规则或数据库自带的IP白名单配置，确认是否限制了应用服务器的特定IP段访问数据库端口。

没有审计的数据库就像没有监控摄像头的金库。很多运维人员为了节省磁盘空间或追求极致性能，会关闭数据库的审计功能，这导致发生数据泄露后无法溯源。基线检查脚本需要验证审计插件是否加载，审计策略是否覆盖了DDL操作、DML操作以及登录失败事件。对于MySQL，需要检查general_log和log_syslog变量的状态，但更关键的是确认audit_log_policy是否设置为ALL或至少包含LOGINS。对于SQL Server，脚本需要查询服务器级审核规范是否已启用，并确认审核操作组是否包含了SCHEMA_OBJECT_CHANGE_GROUP和DATABASE_PRINCIPAL_CHANGE_GROUP。日志存储安全也是检查项之一，必须确认审计日志的保存路径没有设置在可被应用服务覆盖的目录下，并且日志文件的权限设置为仅数据库进程可读写，防止攻击者入侵后清除操作痕迹。

数据库安装后的默认配置往往以兼容性优先，安全特性通常需要手动加固。检查脚本需要扫描数据库中是否存在不必要的内置存储过程或函数。例如SQL Server中的xp_cmdshell，如果开启则允许数据库执行操作系统命令，这是勒索病毒加密数据库文件前最常用的提权手段。脚本应通过查询系统配置表确认这些危险功能是否已被禁用。对于MySQL，需要检查secure_file_priv参数是否设置为空值，如果为空则意味着数据库可以读写任意系统目录，这极其危险。版本与补丁检查同样关键，脚本需要获取当前数据库的完整版本号，并与官方发布的漏洞修复版本列表进行比对。如果发现版本存在已知的高危CVE漏洞且未打补丁，应直接标记为严重不符合项。此外，数据传输加密状态也需要检查，确认ssl_ca等SSL证书参数是否配置，以及业务连接是否强制使用了TLS加密而非明文传输。

硬核的基线检查不能依赖商业扫描器，必须自建轻量级脚本才能适配复杂的异构环境。以下脚本示例演示了如何在MySQL环境中一键检查高危账户、弱密码策略和危险参数。脚本采用Shell编写，通过无交互方式连接数据库执行SQL查询，并将结果与预期基线值进行比对。

#!/bin/bash
# MySQL安全基线自动化检查脚本
HOST="127.0.0.1"
PORT="3306"
USER="checker"
PASS="your_secure_password"

# 检查项1：是否存在匿名用户或空口令账户
echo "=== 检查匿名用户与空口令 ==="
mysql -h${HOST} -P${PORT} -u${USER} -p${PASS} -e "SELECT User, Host FROM mysql.user WHERE User='' OR authentication_string='';" 2>/dev/null
if [ $? -eq 0 ]; then
    echo "[FAIL] 发现匿名用户或空口令账户，请立即清理。"
else
    echo "[PASS] 未发现匿名用户或空口令账户。"
fi

# 检查项2：是否开启了远程root登录
echo "=== 检查远程Root登录 ==="
REMOTE_ROOT=$(mysql -h${HOST} -P${PORT} -u${USER} -p${PASS} -e "SELECT COUNT(*) FROM mysql.user WHERE User='root' AND Host NOT IN ('localhost','127.0.0.1','::1');" -s -N 2>/dev/null)
if [ "$REMOTE_ROOT" -gt 0 ]; then
    echo "[FAIL] Root账户允许远程登录，存在暴力破解风险。"
else
    echo "[PASS] Root账户仅允许本地登录。"
fi

# 检查项3：secure_file_priv 参数是否安全
echo "=== 检查 secure_file_priv 配置 ==="
SECURE_VAL=$(mysql -h${HOST} -P${PORT} -u${USER} -p${PASS} -e "SHOW VARIABLES LIKE 'secure_file_priv';" -s -N 2>/dev/null | awk '{print $2}')
if [ "$SECURE_VAL" = "" ] || [ "$SECURE_VAL" = "NULL" ]; then
    echo "[FAIL] secure_file_priv 未设置或为NULL，存在文件读写风险。"
else
    echo "[PASS] secure_file_priv 已正确设置为: $SECURE_VAL"
fi

# 检查项4：审计日志是否开启
echo "=== 检查审计日志状态 ==="
AUDIT_STATUS=$(mysql -h${HOST} -P${PORT} -u${USER} -p${PASS} -e "SHOW VARIABLES LIKE 'audit_log_policy';" -s -N 2>/dev/null | awk '{print $2}')
if [ "$AUDIT_STATUS" = "ALL" ]; then
    echo "[PASS] 审计日志已全面开启。"
else
    echo "[FAIL] 审计日志未开启或策略不完整，当前状态: $AUDIT_STATUS"
fi

上述脚本只是一个最小化验证单元。在生产环境中，应当将检查结果输出为JSON格式，方便接入监控系统进行趋势分析。对于Oracle数据库，脚本逻辑类似，但需要切换到sqlplus命令行工具，并查询dba_users、dba_role_privs和dba_sys_privs等数据字典视图。对于PostgreSQL，重点检查pg_shadow表中的passwd字段是否为空，以及pg_hba.conf文件中的认证方式。脚本的执行不应使用具有超级权限的账户，而应创建一个专用的只读检查账户，仅授予对系统视图的SELECT权限，避免脚本本身成为攻击面。

发现不符合项只是基线检查的起点，不是终点。脚本输出必须包含明确的修复建议，例如具体的SQL语句或配置文件修改指令，让运维人员能够直接复制执行，减少人为误操作的可能。对于无法立即修复的高风险项，例如核心业务系统存在弱密码，需要建立临时补偿控制措施，比如在网络层对该数据库IP实施严格的访问控制列表限制。基线脚本应当集成到持续集成或持续部署流水线中，在应用发布窗口前后自动触发执行。如果检测到新的权限变更或配置漂移，应当阻断发布流程或发出紧急回滚通知。将每次的检查报告归档存储，能够形成数据库安全态势的长期画像，当发生安全事件时，这些历史基线数据就是最可靠的分析依据。