SQL Server里有个角色叫public，限制每个数据库用户都默认属于它。用户很多人以为只要不给用户授予任何显式权限，限制他就安全了。用户这个想法错得离谱。限制

上周我帮一个客户排查问题，用户他们的限制应用连数据库用的账号只有db_datareader权限，理论上只能读不能写。用户可开发人员死活说他们能往表里插数据。限制我一看，用户guest用户被启用了，限制而guest在public角色里恰好有INSERT权限。用户就这么个不起眼的限制默认配置，让所谓的用户"只读用户"变成了能写数据的账号。

更隐蔽的限制是存储过程。SQL Server里有个约定：如果存储过程和表属于同一个schema，且调用者有该schema的EXECUTE权限，那么存储过程体内部对表的操作会绕过调用者的直接表权限检查。这叫所有权链。比如你建了个usp_DeleteAllUsers的存储过程，给某个用户授予了执行权限，他就能通过这个存储过程删光所有数据——哪怕他根本没有对Users表的DELETE权限。

还有个坑叫DENY与REVOKE的区别。很多人混淆这两个概念。REVOKE只是移除一个权限授予，如果用户通过其他途径（比如角色成员资格）获得了该权限，REVOKE根本拦不住他。而DENY是硬性禁止，优先级最高。我见过一个系统，DBA想限制某个用户访问敏感列，用了REVOKE SELECT ON dbo.Employee FROM restricted_user，结果用户通过db_datareader角色照样能查。正确的做法应该是DENY SELECT ON dbo.Employee TO restricted_user。

行级安全（Row-Level Security）是另一个被低估的工具。SQL Server 2016以后支持这个功能，但很多DBA根本不用。它允许你通过一个内联表值函数定义谓词，比如"这个用户只能看部门ID等于他所在部门的数据"。没用这个的话，你只能靠应用层过滤，但懂行的人都知道，应用层的过滤形同虚设——只要有人直接连数据库，所有数据都裸奔。

最后说个最基础但最容易被忽略的：sa账号。很多生产环境里sa密码设得极其简单，或者干脆禁用但没完全禁用——比如你禁用了sa，但Windows认证的管理员组里有个普通域用户，他通过sysadmin角色成员资格拿到了全库控制权。这种间接路径，权限审计工具往往扫不出来。

限制用户权限不是建个只读账号就完事。你得检查public角色的默认权限，理清所有权链的影响范围，正确区分DENY和REVOKE，考虑行级安全，还得提防那些通过Windows组间接获得的系统级权限。每个环节都可能漏风，而攻击者最擅长的就是把这些小漏洞串成一条完整的攻击链。