防止SQL注入的数据库用户仅授予必要权限

防止SQL注入最有效的手段之一，就是给数据库用户只授予完成业务所需的最小权限。说白了，你的应用程序用什么表就给什么表的权限，能查就不给写，能写就不给删，能删就不给删库。很多开发团队图省事，直接给应用一个root或者db_owner权限，这就等于把家门钥匙全交给了一个可能被黑客利用的入口。一旦SQL注入发生，攻击者能做的事情就被限制在极小范围内，损失可控。这不是什么高深技术，而是数据库安全的基本原则——最小权限原则（Principle of Least Privilege）。

今天这篇文章，我会从原理、实操、不同数据库的具体配置、常见误区、以及进阶策略这几个层面，把"数据库用户权限最小化"这件事讲透。不管你用MySQL、PostgreSQL还是SQL Server，看完都能直接上手改。

SQL注入的本质是攻击者通过输入恶意SQL语句，让数据库执行了开发者没预料到的操作。但这里有个关键问题：攻击者能执行什么操作，完全取决于当前连接数据库的那个用户有什么权限。如果你给了DROP权限，攻击者就能删表；给了GRANT权限，攻击者就能提权创建新用户；给了FILE权限，攻击者可能直接读写服务器文件系统。反过来，如果你只给了SELECT权限，那攻击者注入的SQL最多也就是多查几条数据，造不成结构性破坏。

所以权限控制不是SQL注入的"预防"手段，而是"止损"手段。参数化查询、输入验证这些是在入口拦截，而最小权限是在最后一道防线兜底。两者缺一不可，但很多团队只做了前者，忽略了后者，这是非常危险的。

最小权限原则说的是：每个用户、每个程序、每个进程，只应该拥有完成其任务所必需的最少权限，不多给一分。落实到数据库层面，就是三个维度的控制：

第一，操作权限维度。SELECT、INSERT、UPDATE、DELETE这四个基础操作，按需分配。一个只做展示的页面，只需要SELECT；一个提交表单的接口，只需要INSERT；一个编辑功能，只需要UPDATE对应字段。千万不要图方便全部给。

第二，对象权限维度。只授权需要访问的表和视图。如果应用只用了users和orders两张表，就不要给其他几十张表的权限。更细一点，甚至可以只给特定列的权限，比如只允许读用户名和邮箱，不允许读密码字段。

第三，范围权限维度。限制用户能影响的数据行数。MySQL 8.0以后支持角色和资源组，PostgreSQL有行级安全策略（RLS），这些都能做到更细粒度的控制。

MySQL是最常见的数据库，也是SQL注入重灾区。下面给出具体操作步骤。

首先，创建一个专用的低权限用户，不要用root跑应用：

CREATE USER 'app_user'@'localhost' IDENTIFIED BY 'StrongPassword123!';

然后，只授予需要的权限。假设应用只需要对orders表进行增删改查：

GRANT SELECT, INSERT, UPDATE, DELETE ON mydb.orders TO 'app_user'@'localhost';

如果还需要读products表但不需要写：

GRANT SELECT ON mydb.products TO 'app_user'@'localhost';

注意，这里没有给任何全局权限，没有GRANT OPTION，没有FILE权限，没有PROCESS权限，没有SUPER权限。执行完之后刷新权限：

FLUSH PRIVILEGES;

验证一下权限是否正确：

SHOW GRANTS FOR 'app_user'@'localhost';

如果你发现应用需要执行存储过程，也只给EXECUTE权限，不要给ALTER ROUTINE或CREATE ROUTINE：

GRANT EXECUTE ON mydb.proc_get_order TO 'app_user'@'localhost';

特别提醒：绝对不要给app_user任何带WITH GRANT OPTION的权限，否则它可以把自己的权限转授给别人，等于绕过了你的控制。

PostgreSQL的权限体系比MySQL更细，支持列级别和行级别控制。创建用户：

CREATE ROLE app_user WITH LOGIN PASSWORD 'StrongPassword123!';

授予表级权限：

GRANT SELECT, INSERT, UPDATE, DELETE ON TABLE orders TO app_user;

如果只想让用户读特定列：

GRANT SELECT (id, product_name, price) ON orders TO app_user;

PostgreSQL还有一个强大的功能叫行级安全策略（Row Level Security），可以限制用户只能看到符合条件的行：

CREATE POLICY user_own_orders ON orders
    FOR ALL
    TO app_user
    USING (user_id = current_setting('app.current_user_id')::int);

这意味着即使用户通过注入绕过了应用层逻辑，他也只能操作自己的数据行，无法触及其他用户的记录。

SQL Server使用的是基于角色的权限模型。创建登录名：

CREATE LOGIN app_user WITH PASSWORD = 'StrongPassword123!';

在目标数据库中创建用户并映射：

USE mydb;
CREATE USER app_user FOR LOGIN app_user;

然后把用户加入一个自定义角色，只给这个角色必要权限：

CREATE ROLE db_app_reader;
GRANT SELECT ON dbo.orders TO db_app_reader;
GRANT SELECT ON dbo.products TO db_app_reader;
EXEC sp_addrolemember 'db_app_reader', 'app_user';

SQL Server还有一个容易被忽略的点：不要把用户加入db_owner或db_datareader/db_datawriter这些内置角色，这些角色权限太大。自己建角色，精确控制。

实际项目中，不同模块需要的权限不同。我给几个常见场景的模板：

场景一：纯展示型页面（如商品列表、文章阅读）。只需要SELECT权限，而且最好只读需要展示的列。如果用了视图，可以只给视图的SELECT权限，底层表权限都不给。

场景二：用户注册和提交表单。需要INSERT权限，但不需要UPDATE和DELETE。而且INSERT也可以限制列，比如不允许直接写入is_admin这种敏感字段。

场景三：后台管理系统。需要SELECT、INSERT、UPDATE、DELETE，但建议按表分开授权，不要一次性给所有表的全部权限。管理员操作和普通编辑操作甚至可以用不同数据库用户。

场景四：数据导出和报表。可以创建一个专门的报表用户，只有SELECT权限，而且可以限制只能在特定时间段连接，或者限制连接来源IP。

误区一：用同一个数据库用户跑所有模块。很多小项目为了省事，整个应用就一个数据库连接。正确做法是按模块或按功能拆分用户，比如web_read_user、web_write_user、api_user分开。这样即使一个模块被攻破，其他模块不受影响。

误区二：权限给了就不管了。数据库权限不是一次性配置就完事的，业务迭代会导致表结构变化、新增功能需要新权限。建议每季度做一次权限审计，用脚本批量检查哪些用户有哪些权限，清理不再使用的授权。

误区三：忽略了应用层的权限绕过。有些开发者觉得数据库权限控制了就万事大吉，但如果应用层没有做参数化查询，攻击者虽然权限小，但依然可以通过注入读取敏感数据。数据库权限是兜底，不是替代。

误区四：把权限给到了public角色。在PostgreSQL中，public角色默认对所有对象有一定权限。如果你创建表时没有显式REVOKE，可能public就有访问权。一定要显式收回：

REVOKE ALL ON orders FROM PUBLIC;

最小权限只是纵深防御的一环。要真正防住SQL注入，还需要配合以下措施：

第一，参数化查询和预编译语句。这是从根本上杜绝SQL注入的方法，不管权限多大，注入都不会发生。在代码层面用prepared statement或ORM框架的参数绑定。

第二，Web应用防火墙（WAF）。可以在流量层面拦截明显的注入特征，作为第一道过滤。

第三，数据库审计日志。开启慢查询日志和审计功能，一旦发现异常SQL语句，能及时告警。MySQL的general_log、PostgreSQL的pgAudit都可以用。

第四，网络层隔离。数据库不要暴露在公网，只允许应用服务器IP访问。即使攻击者拿到了数据库用户凭证，没有网络通路也连不上。

第五，定期轮换密码和密钥。数据库用户密码不要硬编码在代码里，用环境变量或密钥管理服务。定期更换，降低泄露后的风险窗口。

手动检查权限效率太低，建议写脚本定期跑。以MySQL为例，可以用这个查询找出所有权限过大的用户：

SELECT user, host, Super_priv, Grant_priv, File_priv, Process_priv
FROM mysql.user
WHERE Super_priv = 'Y' OR Grant_priv = 'Y' OR File_priv = 'Y';

PostgreSQL可以查询：

SELECT rolname, rolsuper, rolcreaterole, rolcreatedb
FROM pg_roles
WHERE rolsuper = true OR rolcreaterole = true;

把这些查询放进定时任务，每周跑一次，输出报告，发现异常立即处理。这是很多安全合规审计要求的基本动作。

防止SQL注入不需要花大钱买安全设备，也不需要复杂的架构改造。给数据库用户只授予必要权限，这件事成本几乎为零，但效果立竿见影。它不能单独解决SQL注入问题，但它能把SQL注入的破坏范围压缩到最小。配合参数化查询、输入验证、网络隔离、审计日志，形成多层防线，才是真正可靠的数据库安全方案。

记住一句话：不要信任任何输入，也不要信任任何权限。默认拒绝，按需开放，定期审查。做到这三点，你的数据库安全水平就能超过市面上绝大多数项目。