SQL注入防护不能只靠参数化查询

应用层用 prepareStatement 或者 query 做参数绑定，确实能防住大部分SQL拼接的漏洞。但问题往往出在部署侧：如果数据库连接凭证是硬编码的，或者配置是静态、未隔离的，一旦攻击者拿下了应用服务器，就能直接连上数据库，执行任意语句。所以说，参数化查询只是第一道防线，真正的安全是一个组合拳。

轮换凭证本身并不能防止注入攻击，但它能有效切断“一次得手、长期有效”的攻击链条。真正起作用的，是下面这一套组合动作：参数化查询 + 凭证动态获取 + 权限最小化 + 连接池隔离。缺了任何一环，防护都可能出现缺口。

数据库连接凭证必须从运行时环境注入，而非打包进代码

一个常见的错误，是把 DB_USER、DB_PASSWORD 直接写死在 application.properties 或 config.yml 这样的配置文件里，甚至不小心提交到了代码仓库。这种做法，会让“定期轮换”变成一场噩梦——每次换密码都得改代码、发版本、重启服务，根本谈不上“定期”。

正确的做法，是让凭证在应用运行时才被注入：

• Ja va/Spring Boot应用：应该通过 JDBC_URL、DB_USER、DB_PASSWORD 等环境变量来加载。Spring Boot对此有原生支持。要特别注意，避免在 spring.datasource.username 这类配置项里写死用户名密码。
• Node.js应用：使用 process.env.DB_PASSWORD 来获取密码，绝对不要用 require('./config/db.json') 这种直接读取静态文件的方式。
• Kubernetes环境：凭证必须通过 Secret 对象来管理，可以挂载为环境变量或卷文件。这里有个关键点：Secret 的名称和挂载路径，最好能与应用的启动逻辑解耦，这样轮换时会更灵活。
• 避免使用 .env 文件：这类文件容易被误提交到代码库，而且在密钥轮换时，很难做到原子性的无缝切换。

轮换凭证时，必须容忍新旧凭据并存的窗口期

数据库本身并不支持“原子切换密码”。当你执行 ALTER USER ... IDENTIFIED BY 修改密码后，旧密码会立刻失效。如果此时应用没有重启，或者连接池没有刷新，还在使用旧的连接，那么就会瞬间爆出一堆 Access denied for user 的错误，导致服务中断。

所以，安全的轮换流程必须包含一个新旧凭证并存的窗口期。具体操作要点如下：

• 第一步，创建新用户：在数据库里创建一个新用户（比如叫 app_prod_v2），并赋予其最小必要的权限（通常只给相关表的 SELECT、INSERT、UPDATE 权限）。
• 第二步，更新并滚动重启：更新环境变量或K8s Secret，然后以滚动重启的方式更新应用（例如在K8s中使用 rollingUpdate 策略），避免服务全部中断。
• 第三步，等待旧连接自然消亡：确认新连接都已成功建立。同时，依靠连接池的 maxLifetime 配置（建议设为10到30分钟），让旧的连接在超时后自然断开。
• 第四步，清理旧用户：等待至少24小时，观察数据库日志确认没有旧用户的登录记录后，再安全地删除旧用户。

跳过这个并存期，无异于亲手制造一次可用性事故。

连接池配置不当会让轮换彻底失效

很多团队遇到过这种情况：明明轮换了数据库密码，但应用好像“没感觉”，依然跑得好好的——其实是因为连接池复用了已经建立好的旧连接，根本没有去读取新的环境变量。这就让轮换工作成了“掩耳盗铃”。

因此，检查连接池的配置至关重要：

• HikariCP：确保密码是通过 dataSourceProperties 动态设置的，而不是直接拼接在 jdbcUrl 里（像 jdbc:mysql://x/y?user=a&password=b 这种写法是绝对的反模式）。
• Druid：注意 initConnectionSqls 里不要包含认证相关的语句。建议开启 testOnBorrow 或 testWhileIdle，并设置一个简单的 validationQuery（如 SELECT 1）来验证连接有效性。
• 通用关键参数：所有连接池都必须设置 maxLifetime（建议不超过30分钟）。如果没有这个设置，连接可能会一直存活，远超过凭证的有效期。

一句话总结：一个没有设置 maxLifetime 的连接池，就等于把旧密码缓存在了应用内存里，任何轮换操作都是徒劳。

说到底，凭证轮换不是简单地让定时任务跑个改密码的脚本。它的本质，是验证你的应用是否具备这样一种能力：在不重启整个进程的前提下，能够使用新的凭据建立新连接，并安全地淘汰旧连接。 构建出这个能力，远比单纯追求密码的复杂度要重要得多。