必须同步收紧数据库账号权限，因erp系统常默认使用sa、root等高权限账号，而各模块仅需最小权限：web服务限select/insert、定时任务限update/execute、日志模块仅insert，且须禁用public默认权限并验证生效。
修复ERP系统SQL注入漏洞，仅靠参数化查询不够——必须同步收紧数据库账号权限。攻击者一旦突破输入层，最小权限就是最后的防线。
为什么ERP系统数据库账号常被配成高权限
很多ERP部署时直接用sa、root或db_owner角色连接，理由是“省事”“兼容老模块”。但实际中，一个销售查询接口只需要SELECT权限，却拥有DROP TABLE能力；一个基础数据导入功能只需INSERT和UPDATE，却能执行EXEC xp_cmdshell（SQL Server）或COPY FROM PROGRAM（PostgreSQL）。这类配置在明源、畅捷通T+、用友U8 Cloud的默认安装包里都曾被发现过。
如何为不同ERP模块分配专用数据库用户
不是简单建个新账号，而是按功能边界切分权限：
- 前端Web服务（如
/tplus/UFAQD/InitServerInfo.aspx）只授予对应业务表的SELECT、INSERT权限，禁止sys.tables、information_schema等元数据访问 - 后台定时任务（如日结、对账脚本）单独使用一个账号，允许
UPDATE和EXECUTE存储过程，但禁用CREATE、DROP - 审计日志写入模块（常从
X-Forwarded-For头取IP）只给INSERT权限到access_log表，且该表不能有触发器或外键关联核心业务表 - 所有账号禁用
public角色的默认权限，显式收回VIEW ANY DATABASE、ALTER ANY DATABASE等高危权限
权限分离后必须验证的三个点
改完权限不等于安全了，要确认是否真生效：
- 用
sp_helprolemember（SQL Server）或\du+（PostgreSQL）检查账号实际所属角色，避免误留db_securityadmin - 在测试环境模拟注入payload，比如向
ServerID参数传' OR 1=1; SELECT * FROM sysusers--，观察是否返回错误信息——若仍能查出sysusers，说明权限未真正隔离 - 检查ERP中间件日志，确认连接池初始化时使用的确实是新账号，而非配置文件里写错、或被JDBC URL里的
user=root覆盖
最容易被忽略的是：权限收紧后，某些ERP模块会静默失败——比如金蝶K/3的凭证过账功能依赖tempdb的CREATE TABLE权限，删掉就卡在“正在生成临时表”。这类依赖不会报错，只会让业务流程中断，必须在UAT阶段逐模块回归验证。
