最小权限不能阻止SQL注入，但能阻断拖库、提权和横向移动；在分布式系统中尤为关键，因多组件共享数据库，任一未参数化环节使用高权限账号即导致全表数据泄露。
最小权限不能阻止SQL注入发生，但能切断攻击者从“查到数据”走向“拖库、提权、横向移动”的路径。在大型分布式系统中，它不是锦上添花的配置项，而是当WAF漏掉某个变体、ORM被绕过、或某个运维脚本直连数据库时，唯一还能拦住攻击者的那道闸门。
为什么分布式系统里最小权限更关键？
单体应用里，数据库账号通常只被一个服务使用；而分布式系统中，同一套数据库可能被商品、订单、库存、风控、报表、定时任务、第三方SDK等十几个组件访问。只要其中任意一个环节没做参数化（比如一段Python导出脚本用str.format()拼SQL），高权限账号就等于把整张表的SELECT权限白送给攻击者。
常见错误现象包括：
- 所有微服务共用一个
app_rw账号，权限覆盖myapp_*所有库 - 定时任务用的账号仍保留
SHOW DATABASES和SELECT ON information_schema.* - 测试环境账号权限照搬生产，导致本地误删表却没报错——上线后才发现权限不足
MySQL 8.0+ 和 PostgreSQL 中怎么精确授予权限？
别再用GRANT SELECT ON myapp_db.* TO 'app'@'%'。真实场景需要字段级、路径级、角色级控制：
- 商品搜索服务只需
SELECT(id, name, price, category_id)onproducts，禁止访问sku_details或users - 订单创建服务允许
INSERT到orders和order_items，但UPDATE仅限status和updated_at字段 - 库存服务必须禁用
SELECT，只留UPDATE(quantity, updated_at)——防批量扫库存 - PostgreSQL中要显式执行
REVOKE USAGE ON SCHEMA public FROM PUBLIC，否则攻击者可直接SELECT table_name FROM information_schema.tables
示例语句（MySQL）：
GRANT SELECT(id, name, price) ON myapp_db.products TO 'search_svc'@'%'; GRANT INSERT, UPDATE(status, updated_at) ON myapp_db.orders TO 'order_svc'@'%'; REVOKE FILE, PROCESS, SUPER ON *.* FROM 'order_svc'@'%';
哪些权限最容易被忽略却最危险？
很多团队检查完SELECT/INSERT/UPDATE就以为安全了，但以下权限一旦开放，相当于给SQL注入开了高速通道：
-
EXECUTE：允许调用存储过程——老系统常把密码重置、资金划转逻辑写在SP里 -
LOAD DATA INFILE（MySQL）或COPY FROM PROGRAM（PostgreSQL）：配合注入可读取/etc/passwd或~/.ssh/id_rsa -
SELECT ON information_schema.*或SHOW DATABASES：让盲注从“猜字段”变成“直接枚举”，效率提升10倍 -
CREATE VIEW或CREATE ROUTINE：攻击者可建视图绕过列级限制，或写函数执行系统命令
检查方式很简单：SHOW GRANTS FOR 'app_svc'@'%'，逐条核对，不是“没开就安全”，而是“没显式REVOKE就不安全”。
权限最小化不是上线前一次配置，而是持续动作
每次新增接口、接入新SDK、部署定时任务，都必须重审数据库账号权限。最容易被跳过的三个盲区是：
- 第三方支付回调组件悄悄执行
SELECT @@version或SHOW TABLES，若被拒绝会中断通知——得提前加白名单 - DBA用客户端连生产库排查问题，临时账号权限过大，且未设自动过期
- 密钥管理没落地，
database.conf里明文存着app_rw密码，服务器一旦被拿shell，权限再小也白搭
真正卡住攻击链的，往往不是最炫的防护技术，而是那个没人记得改、也没人敢动的数据库账号配置。
