禁用 xp_cmdshell 和 sp_oacreate 是最急的一步，因其启用等于为攻击者开放系统级后门；需立即检查并关闭，同时排查隐式依赖与权限滥用。
为什么禁用 xp_cmdshell 和 sp_oacreate 是最急的一步
因为这两个存储过程一旦启用，就等于给攻击者开了个系统级后门。SQL Server 默认禁用它们，但很多老系统在迁移或调试时被手动启用了，且长期无人检查。
常见错误现象：EXEC xp_cmdshell 'whoami' 能成功执行；日志里频繁出现 OLE Automation Procedures 相关警告；数据库账户权限没变，却能读写服务器文件系统。
- 先查是否启用：
SELECT value_in_use FROM sys.configurations WHERE name = 'xp_cmdshell'，返回1就得立刻关 - 关闭命令（需
sysadmin权限）：EXEC sp_configure 'show advanced options', 1; RECONFIGURE; EXEC sp_configure 'xp_cmdshell', 0; RECONFIGURE; - 同理处理
Ole Automation Procedures：把上面命令里的xp_cmdshell换成它即可 - 注意：改完必须执行
RECONFIGURE，否则只是内存生效，重启后还原
如何识别业务中真正依赖的存储过程
直接全禁用会炸掉业务，关键是要区分“谁在用、为什么用、能不能换”。很多所谓“必须用”的存储过程，其实只是历史代码没重构，或是开发图省事硬编码了系统过程名。
使用场景：报表定时任务调用 sp_send_dbmail、ETL 脚本里用 sp_executesql 拼接动态 SQL、遗留系统用 sp_MSforeachtable 做批量操作。
- 用扩展事件捕获实际调用：
CREATE EVENT SESSION [TrackSPCalls] ON SERVER ADD EVENT sqlserver.rpc_completed(WHERE ([object_name] LIKE 'sp_%')) - 重点盯
sp_executesql的参数内容——如果里面拼的是用户输入，那问题不在存储过程本身，而在调用方没参数化 -
sp_MSforeachtable这类非官方过程，微软不保证兼容性，SQL Server 2022 已明显变慢，建议改用sys.tables+ 游标或临时表模拟
替代方案不是加白名单，而是收口到应用层
很多人想建个“安全存储过程白名单”，结果维护成本越来越高，还漏掉 sp_xml_preparedocument 这种冷门但危险的接口。真正有效的做法，是让数据库只响应确定的、参数化的查询，其他逻辑全移到应用里。
性能与兼容性影响：应用层做循环或分页，比在数据库里用游标调 sp_cursoropen 更可控；用 ORM 的 ExecuteSqlRaw 替代 EXEC(@sql)，天然规避拼接风险。
- 把
EXEC(@dynamic_sql)全部替换成sp_executesql并显式声明参数，哪怕只有一处没改，就可能被注入 - 禁用
Ad Hoc Distributed Queries（配置项名），防止通过OPENROWSET直连外部数据库泄露凭证 - 如果真要调外部系统，用 Web API 或消息队列，别让数据库进程直接碰网络
权限最小化比禁用更难，但绕不开
禁用几个存储过程只是表面功夫。一个 db_owner 账户照样能重建 xp_cmdshell，甚至用 CREATE ASYMMETRIC KEY + UNSAFE ASSEMBLY 绕过所有限制。
容易踩的坑：给应用账户加了 EXECUTE 权限到某个存储过程，却忘了它所在的 schema（比如 dbo）本身有 EXECUTE 继承；或者用 ALTER ROLE db_executor ADD MEMBER，结果这个角色被悄悄赋予了 CONTROL SERVER。
- 查实际权限链：
SELECT * FROM fn_my_permissions(NULL, 'SERVER') WHERE permission_name LIKE '%CONFIGURATION%' - 删掉所有非必要的
GRANT EXECUTE ON，尤其是对master或msdb里的系统过程 - 定期跑脚本检查：是否存在
IS_SRVROLEMEMBER('sysadmin', 'app_user')返回1的非 DBA 账户
最麻烦的点从来不是“怎么关”，而是“关完谁来背锅”。业务方说功能异常，DBA 查日志发现是某张表触发器里偷偷调了 sp_start_job，这种隐式依赖，得靠调用链追踪和上线前灰度验证才能揪出来。
