本文目录导读：
针对数据库弱口令的整改,需要从排查、整改、固化三个核心环节入手，以下是详细的整改步骤和最佳实践：
第一阶段：全面排查（摸清家底）
在整改前,必须先知道“弱”在哪里，否则整改无从下手。
- 梳理资产清单：搞清楚公司内部有多少数据库（MySQL、Oracle、SQL Server、MongoDB、Redis、PostgreSQL等），分别部署在哪里（生产、测试、开发、办公环境）。
- 执行口令扫描：
- 使用专业工具：如Nmap（配合脚本）、Hydra、Medusa、SQLScan，或商业化的数据库审计/漏扫产品。
- 常见弱口令字典：
root/root、admin/123456、sa/Admin123、oracle/oracle、test/test、空口令、默认端口+默认口令等。 - 重点关注：默认账户（如MySQL的root、SQL Server的sa、PostgreSQL的postgres）、测试账户、开发阶段遗留账户。
第二阶段：整改执行（立行立改）
发现弱口令后,按以下优先级和步骤进行修改：
-
立即修改：
- 所有数据库的超级管理员账户（如
root,sa）。 - 所有运维、DBA使用的管理账户。
- 所有应用系统使用的默认或已知弱口令账户（如
appuser/123456）。 - 禁用/删除：立即禁用
guest、test等内置或遗留的匿名账户。
- 所有数据库的超级管理员账户（如
-
制定强密码策略（核心）：
- 密码长度：至少12位以上（推荐16位以上）。
- 复杂性：必须包含大写字母 + 小写字母 + 数字 + 特殊字符（如 ）。
- 避免常见模式：不得包含用户名、键盘连续字符（
qwert）、单词（password）、日期（2024）。 - 示例：
G%8kL&zW3xP@uQ9!（随机生成）。
-
修改方法：
- 最稳妥：通过数据库的命令行或图形化管理工具安全修改。
- 不允许：通过明文日志、代码文件、配置文件直接复制粘贴（避免泄露），应使用管理员的个人私密渠道通知或通过密码管理工具分发。
- 必要时：对于生产数据库，需在业务低峰期执行修改，并做好备份和回滚方案，防止应用连接中断导致服务不可用。
第三阶段：长效机制（巩固成果）
整改完不能只改一次,要建立制度防止复现。
-
口令生命周期管理：
- 定期更换：建议每90天或180天更换一次数据库口令（根据安全等级要求调整）。
- 到期提醒：通过自动化脚本或堡垒机提醒用户修改密码。
-
工具化与自动化：
- 部署堡垒机/跳板机：所有数据库操作通过堡垒机进行，堡垒机本身接管认证，用户无需知道数据库直接密码（实现“无口令”或“动态口令”）。
- 使用密钥认证（针对SSH）：对于通过SSH访问的数据库（如MySQL），禁止密码登录，改用SSH密钥对。
- 引入密码管理平台：如Hashicorp Vault、CyberArk、AWS Secrets Manager等，自动生成、轮换、分发强密码，应用通过API获取密码，用户无感。
-
持续监控与审计：
- 定期扫描：使用漏扫工具每月或每季度对整个数据库集群进行口令强度扫描。
- 登录审计：开启数据库的审计日志（Audit Log），记录所有登录失败/成功的操作，一旦发现异常弱口令尝试登录，即时告警。
- 最小权限原则：即使密码很强，也建议对应用账户进行权限最小化（例如只给
SELECT、INSERT、UPDATE权限，不给DROP、CREATE），降低弱口令带来的风险。
特殊情况处理建议
| 场景 | 问题 | 建议 |
|---|---|---|
| 历史遗留系统 | 修改密码后，应用配置文件写死，无法修改。 | 使用环境变量或外部参数注入密码。 使用数据库连接池，由统一组件管理密码。 紧急情况下，可保留旧密码，但必须强制更换并更新应用配置。 |
| 需要共享的账号 | 多人公用一个数据库管理员账号。 | 禁止，必须改为个人账号（通过数据库的CREATE USER创建个人用户，授予相应权限），或者使用堡垒机统一授权。 |
| 云数据库 | 阿里云/腾讯云/RDS等实例。 | 直接通过云控制台的“参数设置”或“账号管理”修改密码，云厂商通常自带复杂密码检测能力。 |
整改的“一票否决”项
- 禁止：
root/root、sa/Admin123、oracle/oracle、应用默认密码。 - 禁止：密码写在代码、配置文件、日志、邮件、聊天记录中（明文存储）。
- 禁止：所有数据库使用同一个密码（一旦泄露，全盘皆输）。
- 必须：遵循“最小权限”原则。
最终目标：让弱口令成为历史，并通过自动化工具和流程，确保每次密码变更都是复杂、随机、可审计的。
