SQL 数据安全综合案例分析

sql注入本质是参数未绑定导致用户输入被当语法执行，须用参数化查询；权限应按数据域最小化切分；加密需密钥分离并区分传输/存储；备份脱敏须自动化版本化。

SQL 注入不是“加单引号就中招”，而是参数未绑定的必然结果

只要用字符串拼接构造 SQL，哪怕只在日志里插个 user_name，就存在注入风险。本质不是单引号、分号或注释符的问题，而是数据库把用户输入当成了可执行语法的一部分。

• 常见错误现象：select * FROM users WHERE name = ' + request.args.get('name') + ' —— 这类拼接在 flask/django 原生 SQL 或 JDBC Statement 中高频出现
• 正确做法：一律改用参数化查询，比如 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——都默认走安全路径，而不是靠事后审计去堵。