数据库安全之定期扫描弱口令账号并强制修改策略

弱口令问题不是新问题，但始终是数据库安全防御体系里最容易被击穿的短板。每次安全审计、等保测评、护网行动，弱口令都是必查项，也是失分重灾区。很多团队把精力放在0day漏洞、APT攻击这些听起来高级的威胁上，却忽略了攻击者最常用的入口就是撞库和暴力破解。一个root/root或者system/password123的账号，足以让多层网络隔离、WAF、IDS全部失效。解决这个问题不能靠一次性的策略下发，必须建立定期扫描、自动发现、强制修改、持续验证的闭环机制。

不能笼统地说“密码太简单”，必须有可执行的标准。通常弱口令包含以下几类：一是符合常见弱口令字典的字符串，比如123456、admin、password、qwerty等及其变体；二是与数据库实例名、IP地址、公司名称、产品名称相同或高度相似的密码；三是长度不足8位且仅包含单一字符类型的密码；四是已知泄露密码库中的密码，可以在Have I Been Pwned等公开接口查询哈希值进行比对。对于核心业务数据库，建议将弱口令标准提高到：长度不低于12位，必须包含大小写字母、数字和特殊字符中的至少三类，且不得包含连续三个以上重复字符或键盘序列字符。把这些规则量化后，扫描脚本才能准确判断，而不是拍脑袋说“这个密码看起来弱”。

很多扫描只检查了数据库用户表中的账号，却忽略了操作系统层面的数据库服务账号、管理后台账号、监控探针账号、复制链路账号、备份恢复账号。这些账号同样拥有高权限，一旦被爆破，危害不亚于root。扫描范围至少要包括：数据库实例的本地认证账号、LDAP/AD集成的域账号、云数据库控制台的管理账号、数据库中间件的连接池账号、以及数据库所在宿主机的SSH/RDP账号。对于MySQL，要扫描mysql.user表；对于PostgreSQL，要扫描pg_shadow和pg_hba.conf中配置的认证方式；对于Oracle，要检查dba_users中的认证类型和密码版本；对于SQL Server，要检查sys.sql_logins中的策略状态。每个数据库平台的扫描方式不同，需要分别适配。

以MySQL为例，可以通过编写一个Shell与Python混合的扫描工具来实现。先通过MySQL自带的mysql_secure_installation检查项作为基础，然后扩展自定义的弱口令字典匹配。核心逻辑是：连接数据库后，提取所有用户的认证字符串，用本地字典和规则库进行碰撞匹配。下面是一段简化但可用的扫描脚本框架：

#!/bin/bash
# MySQL弱口令扫描脚本 - 仅用于授权安全测试

DB_HOST="127.0.0.1"
DB_PORT="3306"
DICT_FILE="/opt/security/weak_passwords.txt"
REPORT_FILE="/var/log/db_weak_pwd_report.log"

# 从数据库获取用户列表
mysql -h ${DB_HOST} -P ${DB_PORT} -u root -p'your_secure_password' -e "SELECT user,authentication_string FROM mysql.user;" -s -N 2>/dev/null | while read user auth_str
do
    if [ -z "$auth_str" ]; then
        echo "[WARN] 用户 ${user} 未设置密码或使用auth_socket插件" >> ${REPORT_FILE}
        continue
    fi
    
    while read weak_pwd
    do
        # 尝试用弱口令连接
        result=$(mysql -h ${DB_HOST} -P ${DB_PORT} -u ${user} -p"${weak_pwd}" -e "SELECT 1;" 2>&1)
        if [[ "$result" == *"1"* ]]; then
            echo "[CRITICAL] 用户 ${user} 存在弱口令: ${weak_pwd}" >> ${REPORT_FILE}
            break
        fi
    done < ${DICT_FILE}
done

这个脚本的思路是遍历用户列表，用弱口令字典逐个尝试连接。生产环境中需要加入连接频率控制、超时设置、错误日志分离，并且要确保扫描行为已经过审批，避免触发安全设备的告警。更安全的做法是不实际尝试登录，而是提取密码哈希后在本地进行离线破解匹配，这样对生产环境零影响。MySQL 8.0使用caching_sha2_password，可以提取哈希后用hashcat进行离线比对，速度更快也更隐蔽。

扫描频率不是越高越好，过于频繁的扫描会影响数据库性能，也可能触发安全告警导致运维人员麻木。建议的分层扫描策略是：核心数据库每7天扫描一次，非核心数据库每30天扫描一次，新建实例或变更账号后24小时内触发一次即时扫描。扫描时间窗口选择业务低峰期，通常是凌晨2点到5点之间。扫描前要通过数据库的慢查询日志和连接数监控确认该时段确实低负载。对于7x24小时高并发的核心系统，可以采用只读副本扫描的方式，在主库上仅做一次用户列表快照，实际密码强度检测在副本上完成，完全隔离扫描负载。

发现弱口令后直接锁定账号是最粗暴的做法，但可能导致线上业务瞬间中断。需要设计分级响应机制：第一级，对于非生产环境、测试账号、长期未登录的僵尸账号，发现弱口令后立即锁定并通知管理员，24小时内未处理则自动删除；第二级，对于生产环境的应用账号，先发送告警通知，给予72小时修改期限，到期未修改则降权处理，将账号权限临时收缩到最小必要权限；第三级，对于超级管理员账号，发现弱口令后立即触发二次认证或临时令牌机制，同时强制要求8小时内完成修改，超时则暂时冻结账号并启动应急流程。整个强制修改过程要记录完整的审计日志，包括发现时间、通知时间、修改时间、修改结果、未处理的升级措施。

人工通知然后等DBA手动修改，这个链路太长，容易遗漏。可以建设一个密码修改的自动化推送平台。当扫描发现弱口令后，系统自动生成一个符合复杂度要求的随机密码，通过加密通道推送到配置中心或者密钥管理服务，然后调用数据库的ALTER USER语句完成密码变更。对于应用侧，需要同步更新连接配置。如果已经使用了配置中心如Apollo、Nacos，可以直接通过API更新配置项并触发应用配置刷新。如果应用尚未实现配置热更新，至少要将新密码写入一个安全存储，然后通知应用负责人进行重启操作。整个推送流程的状态机要清晰：待处理、已推送、已同步应用、已验证、已关闭，每个状态都有超时升级机制。

定期扫描是事后补救，真正有效的做法是在密码创建或修改时就拦截弱口令。在数据库层面，MySQL 8.0可以使用validate_password组件，设置密码最小长度、混合字符类型数量、字典文件路径等策略。PostgreSQL可以使用passwordcheck模块，在password_check_hook中实现自定义验证逻辑。Oracle有密码验证函数，可以通过修改PASSWORD_VERIFY_FUNCTION来增强。但数据库自带的验证往往不够灵活，建议在自动化运维平台或工单系统中增加一道密码强度校验，用户在提交密码修改申请时，前端和后端同时校验，不符合策略的直接拒绝，不进入数据库执行环节。校验规则包括：长度、字符类型、与历史密码的相似度、是否命中弱口令库、是否包含用户名或主机名等个人信息。

没有度量就没有管理。弱口令治理需要建立可量化的指标：弱口令账号数量趋势、弱口令发现到修复的平均时长、重复出现弱口令的账号占比、新创建账号的弱口令拦截率、扫描覆盖率。这些指标应该展现在安全运营看板上，每周进行复盘。如果某个业务线连续多次出现弱口令，说明该团队的密码管理意识薄弱，需要定向培训甚至纳入绩效考核。对于长期保持零弱口令的团队，可以给予正向激励。看板还要展示各数据库类型的弱口令分布，比如MySQL弱口令占比多少、Redis弱口令占比多少，因为Redis这类缓存数据库往往更容易被忽视，需要重点关注。

等保2.0在安全计算环境部分明确要求：应对登录的用户进行身份标识和鉴别，身份标识具有唯一性，鉴别信息具有复杂度要求并定期更换。具体到数据库安全，测评要点包括：是否启用了密码复杂度策略、密码长度是否符合要求、是否定期更换密码、是否存在空口令或弱口令、是否对登录失败进行限制。定期扫描弱口令并强制修改，直接对应等保测评中的“身份鉴别”控制点。在测评时，扫描报告、整改记录、策略配置截图都是有效的证据材料。建议将每次扫描的结果和整改闭环记录归档保存，形成时间序列的证据链，应对监管检查和审计。

云数据库RDS的控制台账号、Kubernetes中Secret存储的数据库密码、Serverless数据库的临时凭证，这些场景下的弱口令扫描需要调整策略。云数据库通常不允许直接扫描底层认证文件，只能通过API调用或连接测试来验证。需要申请相应的API权限，通过云厂商的OpenAPI批量获取实例列表和账号信息，然后进行连接测试。容器环境中的数据库密码往往以Secret形式挂载，扫描工具需要能够读取Secret并解析，然后对目标数据库进行验证。要注意的是，容器中的数据库实例生命周期短、变化快，扫描频率需要相应提高，建议结合CI/CD流水线，在镜像构建阶段就进行密码强度检查。

第一个误区是只扫描不整改，扫描报告出了一堆，但没有人跟进，这是最大的浪费。必须建立工单闭环，每个弱口令对应一个工单，有责任人、有截止时间、有升级机制。第二个误区是扫描脚本本身成为安全隐患，脚本中硬编码了数据库连接密码或者弱口令字典被恶意利用。扫描工具的部署位置、访问权限、日志输出都要严格管控，脚本中的敏感信息要从密钥管理服务中动态获取。第三个误区是强制修改密码后应用连接中断，导致业务故障。修改密码前必须与应用侧确认配置更新方案，最好有灰度变更机制，先在非核心环境验证，再逐步推广。第四个误区是密码策略过于严苛导致用户把密码写在便签纸上，反而降低了安全性。策略要平衡安全性和可用性，可以推广密码管理器或单点登录方案来减轻记忆负担。

弱口令治理不是一次性项目，而是持续运营过程。建议每季度做一次全面的弱口令专项排查，每月做一次策略有效性评估，每周看一次弱口令趋势报表。当组织架构调整、业务系统上线、数据库版本升级时，都要重新评估扫描策略是否需要调整。同时要关注攻击手法的变化，比如近年来出现的凭证填充攻击，攻击者利用其他平台泄露的账号密码组合来尝试登录数据库，这要求弱口令库不能只依赖静态字典，要接入威胁情报源，动态更新已知泄露的凭证列表。只有把扫描、整改、验证、度量、优化形成完整的PDCA循环，才能真正把弱口令风险控制在可接受范围内。