SQL Server需启用Windows身份验证并配置组策略强制密码复杂性；PostgreSQL需启用SCRAM-SHA-256及passwordcheck扩展；MySQL需启用validate_password插件并设PERSIST参数；连接池与中间件须动态注入密码并扫描明文凭据。
SQL Server 如何启用 Windows 身份验证 + 强密码策略
仅靠 SQL Server 自身的 sa 密码强度设置，无法真正加固访问控制——它不校验密码复杂度，也不阻止弱密码重用。必须把认证环节交给操作系统级策略。
- 在 Windows 组策略中启用「密码必须符合复杂性要求」（路径：
Computer Configuration → Windows Settings → Security Settings → Account Policies → Password Policy） - 确保 SQL Server 实例配置为仅允许
Windows Authentication mode（不能是Mixed Mode），否则sa或其他 SQL 登录仍可绕过系统策略 - 禁用或删除所有 SQL 登录账户，包括
sa；只保留域用户/组，并通过sysadmin角色授权 - 注意：应用连接字符串必须改用
Integrated Security=true或Trusted_Connection=yes，否则会直接报错Login failed for user ''
PostgreSQL 强制 SCRAM-SHA-256 + 密码检查扩展
PostgreSQL 10+ 默认支持 scram-sha-256，但不自动拒绝弱密码——得靠外部机制拦截。
- 在
postgresql.conf中设password_encryption = scram-sha-256（别用md5，已过时且易被离线破解） - 在
pg_hba.conf中将所有host行的认证方法从md5改为scram-sha-256 - 安装并启用
passwordcheck扩展（需编译安装）：它会在CREATE ROLE/ALTER ROLE时调用 C 函数校验密码长度、大小写、数字、特殊字符 - 若无法编译扩展，退而求其次：在应用层或 DBA 操作 SOP 中强制使用
psql的\password命令前人工校验，或用pg_set_password工具生成合规密码
MySQL 8.0+ 的 validate_password 插件实操要点
MySQL 自带的 validate_password 插件看似开箱即用，但默认策略太松（比如允许 12345678），且容易被管理员误关。
- 先确认插件已加载：
SELECT plugin_name, plugin_status FROM information_schema.plugins WHERE plugin_name LIKE 'validate%';，若没结果，执行INSTALL PLUGIN validate_password SONAME 'validate_password.so'; - 关键参数必须显式设死：
SET PERSIST validate_password.length = 12;、SET PERSIST validate_password.mixed_case_count = 2;、SET PERSIST validate_password.number_count = 2;、SET PERSIST validate_password.special_char_count = 2; -
SET PERSIST是重点——它写入mysqld-auto.cnf，重启不丢失；用SET GLOBAL重启就失效 - 注意：该插件对
root@localhost也生效，首次初始化后立即改密时就得满足规则，别卡在ALTER USER报错Failed to set password for 'root'@'localhost'
连接池与中间件层的密码兜底校验
数据库本身再严，如果应用代码里硬编码了弱密码、或连接池配置文件明文存了 password=123456，一切白搭。
- 在连接池初始化阶段（如 HikariCP 的
connection-init-sql）插入一条校验语句：SELECT CASE WHEN LENGTH(@@session.password) >= 12 THEN 1 ELSE SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Password too weak' END;（需配合 MySQL 用户变量或自定义函数） - 更可靠的做法：用 Vault、AWS Secrets Manager 等工具动态注入密码，应用启动时不读取静态配置；同时在 CI/CD 流水线中加入正则扫描，禁止提交含
password=的明文配置 - 特别注意 JDBC URL 中的
password参数——它比配置文件更隐蔽，也更容易被日志打印出来（如开启logSlowQueries或 APM 监控时）
强密码不是设个策略就完事；它必须贯穿认证链每一环：OS 策略、DB 认证协议、密码生成逻辑、连接凭据分发方式。漏掉任意一环，攻击者都可能从最松的地方撬开整个访问控制体系。
