RDS自身不提供SQL注入规则拦截能力，其安全机制聚焦网络隔离、权限控制、审计日志和SSL加密；所谓“SQL注入检测”实为前置WAF或审计服务的能力，非RDS实例自身功能。
云数据库 RDS 本身不提供可配置的 SQL 注入“规则拦截”能力——它没有 WAF 那样的 payload 匹配引擎，也不会主动解析并阻断 UNION SELECT 或 ' OR 1=1 -- 这类语句。想靠 RDS 控制台点几下就防住 SQL 注入，注定失败。
为什么 RDS 控制台里找不到“SQL注入防护开关”
RDS 是托管数据库服务，核心职责是稳定运行 MySQL/PostgreSQL 等引擎，不是做应用层语义分析的网关。它的安全机制聚焦在：网络隔离、账号权限、审计日志、SSL 加密。所谓“RDS 支持 SQL 注入检测”，实际是指云厂商在 RDS 前置的管控组件（如云盾 WAF、数据库审计服务、或云防火墙）提供的能力，而非 RDS 实例自身。
直接在 RDS 控制台搜索“SQL 注入”“防护规则”“拦截策略”，结果为空或跳转到 WAF 页面，就是这个原因。
真正起作用的三处配置必须手动检查
这三项不配齐，任何上层 WAF 都可能被绕过：
-
数据库账号权限必须最小化：用
SHOW GRANTS FOR 'app_user'@'%';确认输出中不含FILE、PROCESS、SUPER；否则攻击者一旦注入成功，立刻能读文件、查进程、提权。 -
secure_file_priv必须设为受限目录：执行SELECT @@secure_file_priv;，返回值不能是NULL或空字符串；推荐设为/var/lib/mysql-files/并确保该路径仅 DBA 可写。 -
禁用
local_infile：执行SELECT @@local_infile;，结果必须为OFF；若为ON，攻击者可通过LOAD DATA LOCAL INFILE读取服务器任意文件。
WAF 规则必须针对 RDS 的真实访问路径生效
很多团队把 WAF 挂在 API 网关后，却忘了 RDS 往往通过内网直连——WAF 根本看不到流量。关键判断点：
- 如果应用服务器和 RDS 在同一 VPC 内，且走内网地址（如
rm-xxx.mysql.rds.aliyuncs.com），WAF 对 RDS 查询零感知，此时 WAF 规则再全也无效。 - 只有当用户请求经由公网或 ALB/NLB 转发到应用层，且该层再拼接 SQL 发给 RDS，WAF 才能拦住
username=admin'--这类载荷。 - 若使用 JSON 提交参数（如
{"q": "admin'--"}），必须在 WAF 控制台开启JSON 解析开关，否则 WAF 只解析 URL 和表单，漏掉 body 内容。
数据库审计日志必须独立部署且不可篡改
这是最后一道防线，也是最容易被忽略的一环：
- 审计 Agent 绝不能装在和 RDS 同一台 ECS 上，也不能把审计日志写进同一个 RDS 实例——攻击者拿到 DBA 权限后第一件事就是
DROP TABLE mysql.audit_log;或清空general_log。 - 正确做法：审计服务旁路部署，日志实时推送至权限隔离的 OSS/Bucket，且该 Bucket 的
DELETE权限仅授予 SOC 团队。 - 验证是否生效：手动执行一条高危语句（如
SELECT LOAD_FILE('/etc/passwd');），立即去审计控制台查是否有对应记录；没有，说明链路断了。
真正难的不是配置开关，而是厘清流量路径——WAF 拦哪段、RDS 管哪段、审计盯哪段。三者脱节，防护就只剩一层纸。
