SQL存储过程权限扩散指的是存储过程被授权后，调用该存储过程的用户自动获得存储过程内部执行语句对应的所有权限，超出用户原本应有的操作范围，带来数据库安全隐患。这种问题在复杂业务系统中尤为常见，需要通过合理的设计实现最小特权控制。
存储过程权限扩散的常见原因
权限扩散通常不是单一因素导致的，主要包含以下几类情况：
- 存储过程创建时使用了高权限账户，且未限制执行权限的传递范围
- 给存储过程授予了超出业务需求的权限，比如只需要查询权限却授予了增删改权限
- 多个业务模块共用同一个存储过程，不同模块的用户获得了相同的冗余权限
- 存储过程执行过程中调用了其他高权限对象，间接放大了调用用户的权限范围
最小特权的核心设计原则
通过存储过程实现最小特权，需要遵循几个核心原则：
- 权限按需分配：存储过程仅授予完成对应业务功能必需的最小权限集合
- 权限隔离：不同业务场景的存储过程独立授权，避免权限交叉
- 执行上下文控制：限制存储过程执行时的权限上下文，不继承调用用户的冗余权限
- 定期审计回收：定期排查存储过程权限使用情况，及时回收无用权限
实现最小特权的具体操作方法
1. 规范存储过程创建权限
创建存储过程时避免使用数据库管理员等高权限账户，优先使用仅具备存储过程创建权限的专用账户，从根源上减少权限冗余。以MySQL为例，创建存储过程时可以指定DEFINER为低权限用户：
-- 创建存储过程时指定DEFINER为仅具备查询权限的用户
CREATE DEFINER = 'query_user'@'localhost' PROCEDURE get_user_info(IN user_id INT)
BEGIN
-- 仅查询用户表对应id的信息，无额外权限
SELECT id, name, age FROM user_table WHERE id = user_id;
END;
2. 精确授予存储过程执行权限
不要给存储过程授予ALL PRIVILEGES这类全量权限，仅授予EXECUTE权限，并且限定可调用存储过程的用户范围。比如仅允许业务用户调用查询用户信息的存储过程：
-- 仅授予业务用户执行get_user_info存储过程的权限 GRANT EXECUTE ON PROCEDURE test_db.get_user_info TO 'biz_user'@'localhost'; -- 刷新权限使配置生效 FLUSH PRIVILEGES;
3. 控制存储过程内部权限上下文
部分数据库支持设置存储过程的SQL SECURITY属性，通过设置为DEFINER可以让存储过程执行时使用创建者的权限，而不是调用者的权限，避免调用者的冗余权限被带入存储过程执行过程。以MySQL为例：
-- 设置SQL SECURITY为DEFINER，执行时使用DEFINER指定的用户权限
CREATE DEFINER = 'query_user'@'localhost' PROCEDURE get_order_info(IN order_id INT)
SQL SECURITY DEFINER
BEGIN
-- 即使调用者有更高权限，执行时也仅使用query_user的查询权限
SELECT order_id, order_amount, create_time FROM order_table WHERE order_id = order_id;
END;
4. 定期审计与权限回收
建立定期的存储过程权限审计机制，排查无用的存储过程权限和冗余授权。可以通过以下查询语句查看存储过程的权限授予情况：
-- 查询MySQL中所有存储过程的授权信息 SELECT * FROM information_schema.USER_PRIVILEGES WHERE PRIVILEGE_TYPE = 'EXECUTE' AND OBJECT_TYPE = 'PROCEDURE';
对于不再使用的存储过程权限，及时执行回收操作：
-- 回收业务用户的存储过程执行权限 REVOKE EXECUTE ON PROCEDURE test_db.get_user_info FROM 'biz_user'@'localhost'; FLUSH PRIVILEGES;
注意事项
在配置存储过程权限时，需要注意不同数据库的特性差异，比如SQL Server使用EXECUTE AS子句控制执行上下文，PostgreSQL通过SECURITY DEFINER属性设置执行权限。同时要避免在存储过程中编写动态SQL拼接语句，防止SQL注入风险进一步扩大权限影响范围。如果存储过程需要调用其他对象，仅给存储过程的DEFINER用户授予对应对象的必需权限，不要给调用用户额外授权。