SQL注入本质是参数未绑定导致用户输入被当语法执行，须用参数化查询；权限应按数据域最小化切分；加密需密钥分离并区分传输/存储；备份脱敏须自动化版本化。
SQL 注入不是“加单引号就中招”，而是参数未绑定的必然结果
只要用字符串拼接构造 SQL，哪怕只在日志里插个 user_name，就存在注入风险。本质不是单引号、分号或注释符的问题，而是数据库把用户输入当成了可执行语法的一部分。
- 常见错误现象：
SELECT * FROM users WHERE name = ' + request.args.get('name') + '—— 这类拼接在 Flask/Django 原生 SQL 或 JDBCStatement中高频出现 - 正确做法：一律改用参数化查询，比如 Python 的
cursor.execute("SELECT * FROM users WHERE id = %s", [user_id])，或 Java 的PreparedStatement - 注意边界：ORM 如 SQLAlchemy 的
filter(User.name == name)是安全的，但filter(text("name = '{}'".format(name)))就立刻退化为拼接 - 兼容性影响：老系统用
mysql_query()（PHP）或sqlite_exec()（C）基本无参数化能力，必须升级到mysqli_prepare()或绑定接口
权限最小化不是“给个只读账号就行”，而是按数据域切分角色
一个 report_reader 账号能查全库 sales_2023 表，不代表它该查 sales_2024_q1；更不该让它看到 employee_salary 视图，哪怕只是 SELECT 权限。
- 使用场景：多租户 SaaS 系统里，
tenant_id必须作为所有查询的强制过滤条件，不能靠应用层“自觉加 where”，而应通过行级安全策略（如 PostgreSQL 的RLS）或视图封装 - 参数差异：MySQL 8.0+ 支持
CREATE ROLE和GRANT ... ON database.table，但不支持列级或行级控制；PostgreSQL 则可通过GRANT SELECT (col_a, col_b) ON table精确授权 - 容易踩的坑：
GRANT SELECT ON *.* TO 'app'@'%'在测试环境很常见，上线前必须收窄——连information_schema都不该开放
敏感字段加密不能只靠 AES_ENCRYPT()，得区分传输中和存储时
AES_ENCRYPT() 在 MySQL 里看着方便，但它把密钥硬编码进 SQL 或配置文件，等于把保险柜钥匙焊在柜门上。
- 传输中加密靠 TLS：确认连接串含
?sslmode=require（PostgreSQL）或&useSSL=true（MySQL JDBC），否则密码、身份证号明文飞过网络 - 存储时加密要密钥分离：用 KMS（如 AWS KMS、HashiCorp Vault）托管密钥，应用只调用
decrypt(encrypted_ssn)接口，不接触原始密钥 - 性能影响：对
WHERE条件字段（如手机号）加密后无法索引，得加确定性加密或用HMAC摘要建索引，否则查一次要全表扫 - 别碰
MD5/SHA1存密码：必须用bcrypt、scrypt或argon2，且轮数不低于 12
备份与脱敏不是“导出再删”，而是自动化流水线里的不可信环节
运维手动 mysqldump --all-databases 后用 sed 替换邮箱，这种操作只要漏掉一个字段或换行符错位，整份备份就变成高危泄露源。
- 真实使用场景：CI/CD 流水线里跑测试库，必须从生产备份拉取数据，但需自动脱敏——比如用
gitlab-runner调用sqldelight或自定义 Python 脚本，在导入前逐行重写email字段为REPLACE(email, '@', '+test@') - 关键点：脱敏逻辑必须版本化，和应用代码一起走 Git；不能存在某台跳板机上的私有脚本里
- 容易被忽略：备份文件本身权限是
644，若存于共享 NFS 或对象存储，得额外设 ACL 或加密，否则aws s3 cp s3://backup/db.sql.gz .就可能被非授权下载
事情说清了就结束。真正难的不是知道该做什么，而是让每个环节——从开发写第一行 SQL 开始，到 DBA 配置最后一条 GRANT——都默认走安全路径，而不是靠事后审计去堵。
