数据库弱口令如何整改

本文目录导读：

1. 第一阶段：全面排查（摸清家底）
2. 第二阶段：整改执行（立行立改）
3. 第三阶段：长效机制（巩固成果）
4. 特殊情况处理建议
5. 总结：整改的“一票否决”项

针对数据库弱口令的整改,需要从排查、整改、固化三个核心环节入手，以下是详细的整改步骤和最佳实践：

第一阶段：全面排查（摸清家底）

在整改前,必须先知道“弱”在哪里，否则整改无从下手。

1. 梳理资产清单：搞清楚公司内部有多少数据库（MySQL、Oracle、SQL Server、MongoDB、Redis、PostgreSQL等），分别部署在哪里（生产、测试、开发、办公环境）。
2. 执行口令扫描：
   • 使用专业工具：如Nmap（配合脚本）、Hydra、Medusa、SQLScan，或商业化的数据库审计/漏扫产品。
   • 常见弱口令字典：root/root、admin/123456、sa/Admin123、oracle/oracle、test/test、空口令、默认端口+默认口令等。
   • 重点关注：默认账户（如MySQL的root、SQL Server的sa、PostgreSQL的postgres）、测试账户、开发阶段遗留账户。

第二阶段：整改执行（立行立改）

发现弱口令后,按以下优先级和步骤进行修改：

1. 立即修改：

   • 所有数据库的超级管理员账户（如root, sa）。
   • 所有运维、DBA使用的管理账户。
   • 所有应用系统使用的默认或已知弱口令账户（如appuser/123456）。
   • 禁用/删除：立即禁用guest、test等内置或遗留的匿名账户。

2. 制定强密码策略（核心）：

   • 密码长度：至少12位以上（推荐16位以上）。
   • 复杂性：必须包含大写字母 + 小写字母 + 数字 + 特殊字符（如 ）。
   • 避免常见模式：不得包含用户名、键盘连续字符（qwert）、单词（password）、日期（2024）。
   • 示例：G%8kL&zW3xP@uQ9!（随机生成）。

3. 修改方法：

   • 最稳妥：通过数据库的命令行或图形化管理工具安全修改。
   • 不允许：通过明文日志、代码文件、配置文件直接复制粘贴（避免泄露），应使用管理员的个人私密渠道通知或通过密码管理工具分发。
   • 必要时：对于生产数据库，需在业务低峰期执行修改，并做好备份和回滚方案，防止应用连接中断导致服务不可用。

第三阶段：长效机制（巩固成果）

整改完不能只改一次,要建立制度防止复现。

1. 口令生命周期管理：

   • 定期更换：建议每90天或180天更换一次数据库口令（根据安全等级要求调整）。
   • 到期提醒：通过自动化脚本或堡垒机提醒用户修改密码。

2. 工具化与自动化：

   • 部署堡垒机/跳板机：所有数据库操作通过堡垒机进行，堡垒机本身接管认证，用户无需知道数据库直接密码（实现“无口令”或“动态口令”）。
   • 使用密钥认证（针对SSH）：对于通过SSH访问的数据库（如MySQL），禁止密码登录，改用SSH密钥对。
   • 引入密码管理平台：如Hashicorp Vault、CyberArk、AWS Secrets Manager等，自动生成、轮换、分发强密码，应用通过API获取密码，用户无感。

3. 持续监控与审计：

   • 定期扫描：使用漏扫工具每月或每季度对整个数据库集群进行口令强度扫描。
   • 登录审计：开启数据库的审计日志（Audit Log），记录所有登录失败/成功的操作，一旦发现异常弱口令尝试登录，即时告警。
   • 最小权限原则：即使密码很强，也建议对应用账户进行权限最小化（例如只给SELECT、INSERT、UPDATE权限，不给DROP、CREATE），降低弱口令带来的风险。

特殊情况处理建议

整改的“一票否决”项

• 禁止：root/root、sa/Admin123、oracle/oracle、应用默认密码。
• 禁止：密码写在代码、配置文件、日志、邮件、聊天记录中（明文存储）。
• 禁止：所有数据库使用同一个密码（一旦泄露，全盘皆输）。
• 必须：遵循“最小权限”原则。

最终目标：让弱口令成为历史，并通过自动化工具和流程，确保每次密码变更都是复杂、随机、可审计的。