授予应用账号tempdb的dbowner权限还有哪些未考虑的风险？

未覆盖的风险评估点 #

• 权限溢出风险：dbowner权限意味着该账号可以在tempdb中执行任意操作，包括篡改/删除其他业务或系统进程创建的临时对象，直接导致其他正在运行的业务请求报错、数据异常甚至服务崩溃。如果应用代码存在SQL注入漏洞，攻击者还可以通过该账号直接控制tempdb，进而尝试提权访问其他业务数据库。
• 临时对象命名冲突与空间占用风险：不使用#/##前缀创建的是tempdb内的常规用户表，这类对象不会随会话断开自动删除，也不会被系统自动回收，除非手动删除或SQL服务重启。如果应用代码逻辑不完善，创建对象后不主动清理，会快速占用tempdb磁盘空间，最终引发磁盘满故障，影响整个SQL实例上的所有业务。同时这类全局可见的对象还可能出现命名冲突，直接导致应用创建对象失败。
• 跨会话数据泄露风险：非#前缀的对象对所有有tempdb访问权限的账号可见，如果应用将敏感数据存入这类对象，其他账号可以直接读取，存在严重的数据泄露隐患。
• 运维排查复杂度提升：大量非系统生成的永久临时对象存在于tempdb中，会干扰故障排查时对系统临时对象的定位，延长故障恢复时间。同时如果这类对象存在锁等待，也会和系统锁混在一起，大幅提升死锁、阻塞问题的排查难度。
• 配置维护成本增加：SQL服务重启后权限会重置，意味着如果要满足该需求，必须额外添加启动存储过程或者运维脚本，每次SQL服务重启后重新执行授权操作，增加了运维配置项和故障点，一旦脚本执行失败会直接导致应用故障。
• 合规风险：绝大多数企业的数据库安全规范都要求遵循最小权限原则，授予非系统账号系统数据库的dbowner权限属于严重的过度授权，无法通过等保、内部审计等合规检查，会带来合规处罚隐患。

低风险替代方案 #

不需要授予dbowner权限即可满足应用需求：只需给该账号授予tempdb的CREATE TABLE权限，同时指定该账号在tempdb中的默认schema为dbo，就能实现不用加#前缀创建对象的需求，权限范围远小于dbowner，风险更低。如果企业规范不允许修改tempdb默认权限，也可以引导应用调整代码使用标准临时表，或者在业务库中创建专用的临时表schema满足需求。

内容的提问来源于stack exchange，提问作者Farshid SQLServer