1. 为什么“只读账号”这件事值得单独写一篇但凡在生产环境里碰过数据库的人大概率都遇到过这种需求报表团队要连库查数、外包同事要临时看几张表、BI 工具要拉数据做看板、审计要核对记录——这些场景有一个共同点对方只需要看绝对不能改。这时候如果你图省事直接把 sa 或者某个高权限账号丢出去那基本等于把家门钥匙连同保险柜密码一起给了陌生人。我在实际运维里踩过最典型的一次坑早年给一个数据分析同事开了个账号图快直接给了db_owner结果对方用 Navicat 连上来之后误点了一个“生成 UPDATE 脚本”的按钮把一张几十万行的订单表状态字段全刷成了同一个值。虽然最后靠备份恢复了但那次事故让我彻底明白一件事——权限这东西给多了就是给自己埋雷。所以“创建只读账号”看着是个小操作实际上它是数据库权限管理里最基础、也最容易被做错的一环。这篇内容就是把我这些年反复操作、反复验证过的两种做法完整梳理出来一种走SSMS 图形界面适合不熟悉脚本、想点点鼠标就搞定的朋友另一种走T-SQL 脚本适合需要批量、需要留痕、需要复现的场景。两种方式我都会把每一步为什么这么做讲清楚而不是只丢一串命令让你抄。先明确一下这篇适合谁看如果你是刚接手 SQL Server 的运维、后端开发或者需要给团队配置数据访问权限的负责人这篇能直接拿去用。如果你已经会建账号但不确定权限到底给到哪一层才安全那更要往下看因为**“只读”其实分好几种粒度**给错了照样出事。在动手之前先把核心概念对齐一下不然后面容易懵。登录名Login和数据库用户User是两回事。登录名是服务器级别的负责“你能不能进这台 SQL Server 的大门”数据库用户是数据库级别的负责“进了大门之后你能进哪个房间”。很多人建完登录名发现连不上库就是因为忘了在目标数据库里再建一个对应的用户或者没做映射。这是新手最容易卡住的地方我后面会专门讲。只读权限的核心角色是db_datareader。这是 SQL Server 内置的数据库角色成员自动拥有该数据库中所有用户表的 SELECT 权限。注意关键词是“所有用户表”也就是说它是库级别的、全表覆盖的。如果你只想让对方看某几张表那就不能用这个角色得走更细的 GRANT 授权这个我也会在后面的小节里补上。权限最小化原则是贯穿全文的主线。只读账号就只给读不要顺手给个db_datawriter不要给db_owner更不要给sysadmin。每多给一层权限你的攻击面和误操作面就大一圈。下面进入正题先讲整体思路再分别拆两种操作方式。2. 整体设计思路与权限模型拆解2.1 只读账号到底“只读”到什么程度很多人以为“只读”就是不能改数据其实这个理解只对了一半。SQL Server 里的“读”和“写”边界比想象中细我们得先把这个边界划清楚才知道权限该给到哪。从操作类型上看一个账号可能涉及的动作包括查数据SELECT、插数据INSERT、改数据UPDATE、删数据DELETE、建表改表DDL、执行存储过程EXECUTE、看元数据VIEW DEFINITION等等。一个合格的只读账号理想状态是只能 SELECT其他全部拒绝。但这里有个细节db_datareader只保证了对用户表的 SELECT它不包含对视图、存储过程、函数的执行权限。也就是说如果对方要查的是一个视图光加db_datareader可能还是查不了得额外授权。这一点网上很多教程都不提导致不少人建完账号发现“明明给了只读角色怎么还是报权限错误”原因就在这。另外还有一个容易忽略的点默认情况下普通账号是能看到数据库里有哪些表的因为元数据的可见性在较新版本里默认是受限于权限的但老版本或者某些配置下可能暴露。如果你对表名本身都敏感那还得额外处理元数据可见性。这个属于进阶需求我在第 4 节会展开。2.2 两种操作方式的取舍逻辑为什么我要把 SSMS 和 T-SQL 两种方式都写一遍因为它们各自适用的场景完全不同不是谁替代谁的关系。SSMS 图形界面的优势在于直观、可核对。你每一步点了什么、勾了什么界面上都看得见适合一次性配置、适合教学、适合对脚本不熟的人。缺点是步骤多、容易漏、没法批量而且如果要在十台服务器上做同样的操作点鼠标点到手酸。T-SQL 脚本的优势在于可复现、可版本化、可批量。你把脚本存下来下次换台服务器直接跑几秒钟搞定。而且脚本可以进 Git、可以进变更单、可以审计这在规范化的运维流程里是刚需。缺点是对新手有门槛得理解每条语句在干什么。我的建议是第一次配置用 SSMS 走一遍把每一步对应到脚本上理解之后所有重复操作全部用脚本。这样既建立了直观认知又保证了效率。下面两节就按这个逻辑展开。2.3 权限授予的三种粒度对照在正式动手前先把三种常见粒度的区别摆出来方便你对号入座。粒度层级实现方式适用范围安全性整库只读加入db_datareader角色需要看全库所有表中覆盖全表单表只读GRANT SELECT ON 表 TO 用户只看指定几张表高精准控制视图只读建视图 授权视图 SELECT需要脱敏或限定列最高可隐藏底层结构大部分“给报表团队开个号”的需求用第一种就够了。但如果是给外部合作方、或者涉及敏感数据那必须往第二种、第三种走。我见过太多人一律用第一种结果把用户表、配置表、甚至带手机号的客户表全暴露了这是实打实的风险。3. 场景一SSMS 图形界面完整操作3.1 前置准备确认实例版本与连接方式动手之前先确认两件事能省掉后面一堆麻烦。第一确认你的 SSMS 版本和 SQL Server 实例版本。SSMS 是独立于数据库引擎发布的新版本 SSMS 可以连老版本实例但反过来不一定。如果你用的是比较新的 SSMS比如 19、20 这些版本连 SQL Server 2008 这类老实例时可能会遇到加密协议不兼容的报错典型的就是那个证书链是由不受信任的颁发机构颁发的或者客户端无法建立连接。遇到这种情况通常是在连接选项里勾选“信任服务器证书”而不是去折腾账号权限别搞错方向。第二确认你当前登录的账号有足够权限。创建登录名需要服务器级别的ALTER ANY LOGIN权限通常sysadmin或securityadmin角色成员可以。如果你连登录名都建不了那说明你手上的账号权限不够得先找 DBA 要权限这一步绕不过去。连接上实例之后在对象资源管理器里展开到安全性 → 登录名这一层接下来的操作都从这里开始。3.2 第一步创建服务器级登录名右键“登录名”选择“新建登录名”会弹出一个多标签的窗口。这里有几个关键填写项我逐个说。登录名填你想要的账号名比如report_readonly。命名建议带上用途别用user1、test这种过两个月你自己都不记得这号是干嘛的。身份验证方式选“SQL Server 身份验证”然后设置密码。这里有个实操经验——把“强制实施密码过期”和“强制实施密码策略”的勾选情况想清楚。生产环境建议勾上密码策略但如果你这个账号是给程序或 BI 工具用的密码过期会导致连接突然中断那就得评估。我一般给程序用的账号会取消“强制密码过期”避免半夜服务挂掉。默认数据库建议直接选成目标业务库比如YourDB。这样对方登录后默认就在正确的库里不用每次手动切。这个小设置能减少很多“我连上了但看不到表”的困惑。窗口左侧切到“用户映射”标签页这里是最关键的一步。勾选目标数据库然后在下面的“数据库角色成员身份”里勾选db_datareader。注意只勾这一个public是默认就有的不用管其他什么db_datawriter、db_owner一律不要碰。提示如果你在“用户映射”里勾了数据库但没勾任何角色那这个账号进库之后什么表都查不了会报“对象不存在或权限不足”。这是新手最常见的漏勾。点确定登录名就建好了同时数据库用户也自动映射上了。这一步其实一次性完成了“建登录名”和“建数据库用户”两件事SSMS 帮你把两步合并了这也是图形界面方便的地方。3.3 第二步验证权限是否真的生效建完别急着交付一定要自己先验证一遍。验证方法很简单用新账号重新开一个连接而不是在当前窗口测试。因为当前窗口是用你的高权限账号登录的测不出真实效果。在 SSMS 里点“连接 → 数据库引擎”服务器名填一样的身份验证选“SQL Server 身份验证”输入刚建的账号密码连进去。然后新建查询跑一句SELECT TOP 10 * FROM 你的某张表;能查出数据说明读权限没问题。接着再跑一句写操作试试UPDATE 你的某张表 SET 某字段 某字段 WHERE 10;注意我加了WHERE 10这样即使权限没拦住也不会真的改到数据是个安全的测试写法。正常情况应该报错类似“拒绝了对对象 xxx 的 UPDATE 权限”。如果这句没报错反而执行成功了那说明你的权限给多了赶紧回去检查角色成员身份。这个“读能通、写被拒”的双向验证是我每次配完账号的固定动作强烈建议你也养成习惯。只测读不测写等于没验证。3.4 图形界面的几个隐藏坑用 SSMS 建账号虽然直观但有几个坑我踩过这里提前给你标出来。坑一账号名和数据库用户不同步。有时候你在服务器级别删了登录名但数据库里的用户还残留着变成一个“孤立用户”。反过来如果你先建了数据库用户再建登录名也可能对不上。判断方法是查sys.database_principals里有没有sid对不上的用户。遇到这种情况用ALTER USER 用户名 WITH LOGIN 登录名重新绑定。坑二db_datareader不覆盖视图和存储过程。前面提过这里再强调一次。如果对方要查视图你得单独授权图形界面里是在数据库 → 安全性 → 用户 → 右键属性 → 安全对象里加操作比较绕这种情况我反而建议直接用脚本。坑三默认架构问题。如果目标库里有自定义架构Schema比如sales、finance那db_datareader是覆盖这些架构下的表的这点没问题。但如果对方要用schema.table的方式访问而没权限通常是架构的 SELECT 权限没给需要额外GRANT SELECT ON SCHEMA::sales TO 用户。4. 场景二T-SQL 脚本完整实现4.1 脚本整体结构与执行顺序脚本方式我习惯分成四段来写顺序不能乱建登录名 → 建数据库用户 → 授只读角色 → 验证。下面这段是通用模板你把库名、账号名、密码替换掉就能用。-- 1. 在 master 库创建服务器级登录名 USE master; GO CREATE LOGIN report_readonly WITH PASSWORD YourStrongPassword123!, DEFAULT_DATABASE YourDB, CHECK_EXPIRATION OFF, CHECK_POLICY ON; GO -- 2. 切换到目标数据库创建数据库用户并映射到登录名 USE YourDB; GO CREATE USER report_readonly FOR LOGIN report_readonly; GO -- 3. 授予只读角色 ALTER ROLE db_datareader ADD MEMBER report_readonly; GO逐段解释一下为什么这么写。第一段在master库执行因为登录名是服务器级别的对象必须在这个上下文里建。CHECK_EXPIRATION OFF表示密码不过期适合程序账号CHECK_POLICY ON表示仍然遵守密码复杂度要求这个建议保留别为了省事关掉。第二段的CREATE USER ... FOR LOGIN是关键它把数据库用户和登录名绑定起来。如果只建登录名不建用户账号能登录服务器但进不了具体库。第三段用ALTER ROLE ... ADD MEMBER而不是老式的sp_addrolemember。新语法从 SQL Server 2012 开始支持老语法虽然还能用但已经标记为弃用新项目一律用新语法。如果你维护的是 2008 这种老实例那就得用sp_addrolemember db_datareader, report_readonly。4.2 单表只读的精细化授权脚本如果需求不是全库只读而是只看某几张表那db_datareader就不能用了得走显式授权。脚本长这样USE YourDB; GO -- 先建用户如果还没建 CREATE USER report_readonly FOR LOGIN report_readonly; GO -- 只授予指定表的 SELECT 权限 GRANT SELECT ON dbo.Orders TO report_readonly; GRANT SELECT ON dbo.OrderDetails TO report_readonly; GRANT SELECT ON dbo.Products TO report_readonly; GO这种写法的好处是权限边界极其清晰对方只能看这三张表其他表连表名都摸不到配合元数据可见性控制的话。缺点是表多了要写一堆 GRANT维护成本高。我的经验是表数量在 10 张以内用显式授权超过 10 张且都是同一业务域考虑建个专用架构或者用角色统一管理。如果你想让授权更好维护可以自建一个数据库角色把权限挂在角色上再把用户加进角色-- 建自定义只读角色 CREATE ROLE role_report_reader; GO -- 给角色授权 GRANT SELECT ON dbo.Orders TO role_report_reader; GRANT SELECT ON dbo.OrderDetails TO role_report_reader; GO -- 把用户加入角色 ALTER ROLE role_report_reader ADD MEMBER report_readonly; GO这样以后要加表只改角色授权不用动用户人员变动时也只管加减角色成员管理起来清爽很多。4.3 视图只读需要脱敏时的正确姿势有些场景下底层表里有敏感字段手机号、身份证、金额但你又要让外部人员能查部分数据。这时候正确做法是建一个视图只暴露需要的列然后授权视图的 SELECT而不是直接授权底层表。USE YourDB; GO -- 建脱敏视图只暴露必要列 CREATE VIEW vw_OrderSummary AS SELECT OrderID, OrderDate, LEFT(CustomerPhone, 3) **** RIGHT(CustomerPhone, 4) AS MaskedPhone, TotalAmount FROM dbo.Orders; GO -- 授权视图查询 GRANT SELECT ON dbo.vw_OrderSummary TO report_readonly; GO这里有个关键点授权视图之后用户能不能绕过视图直接查底层表答案是——如果用户没有底层表的 SELECT 权限那就查不了视图是唯一的入口。这正是视图方案安全的地方。但要注意如果用户同时被加了db_datareader那底层表权限就绕过了视图脱敏就白做了。所以视图方案和db_datareader不能同时用二选一。4.4 脚本执行后的验证语句脚本跑完同样要验证。除了前面说的重新连接测试还可以用系统视图直接查权限配置这个在批量核对时特别有用-- 查某个用户属于哪些数据库角色 USE YourDB; SELECT r.name AS RoleName, m.name AS MemberName FROM sys.database_role_members rm JOIN sys.database_principals r ON rm.role_principal_id r.principal_id JOIN sys.database_principals m ON rm.member_principal_id m.principal_id WHERE m.name report_readonly;正常应该看到report_readonly属于db_datareader。如果查出来是空的说明角色没加成功回去检查ALTER ROLE那句有没有报错。再查一下显式授权SELECT dp.name AS UserName, o.name AS ObjectName, p.permission_name FROM sys.database_permissions p JOIN sys.database_principals dp ON p.grantee_principal_id dp.principal_id JOIN sys.objects o ON p.major_id o.object_id WHERE dp.name report_readonly;这两条查询我建议存成常用脚本每次配完账号跑一遍比在图形界面里翻半天快得多。5. 常见问题与排查技巧实录5.1 账号建好了却连不上问题出在哪这是最高频的问题我按排查顺序给你列出来。第一确认登录名是否启用。有时候账号被禁用了在 SSMS 里登录名属性 → 状态 → 是否允许连接到数据库引擎要选“授予”。脚本方式对应的是ALTER LOGIN 账号 ENABLE。第二确认身份验证模式。如果服务器只开了 Windows 身份验证模式那 SQL 账号根本没法登录。检查方法是右键实例 → 属性 → 安全性 → 服务器身份验证要选“SQL Server 和 Windows 身份验证模式”。改完这个需要重启 SQL Server 服务才生效很多人改完没重启以为没生效。第三确认默认数据库存在且可访问。如果登录名的默认数据库被删了或者对方没权限登录会失败。这种情况把默认库改成master先能登进去再排查。第四确认网络和端口。如果连的是远程实例还要确认 TCP/IP 协议启用、端口开放、防火墙放行。这类问题报错信息通常是“无法连接到服务器”和权限报错不一样注意区分。5.2 能连上但查不了表怎么定位连上了但一查就报“对象不存在或权限不足”按这个顺序查。先确认当前连的是哪个库。用SELECT DB_NAME()看一眼如果连错库了那当然看不到目标表。这也是为什么我前面建议把默认数据库设对。再确认用户是否真的在目标库里。用SELECT * FROM sys.database_principals WHERE name 账号名查如果查不到说明数据库用户没建回去补CREATE USER。然后确认角色成员身份。用 4.4 节那条查角色的语句核对。如果角色没加上补ALTER ROLE。最后确认是不是视图或存储过程。如果是db_datareader不覆盖需要单独授权这是前面反复强调的点。5.3 权限给多了怎么回收发现权限给多了别慌回收比授予简单。如果是角色给多了ALTER ROLE db_datawriter DROP MEMBER report_readonly;如果是显式授权给多了REVOKE SELECT ON dbo.某表 FROM report_readonly;如果是整个账号要停用ALTER LOGIN report_readonly DISABLE;注意DISABLE只是禁用登录账号和权限还在随时能恢复。如果要彻底删除顺序是先删数据库用户再删登录名反过来会报错因为用户还引用着登录名。USE YourDB; DROP USER report_readonly; GO USE master; DROP LOGIN report_readonly; GO5.4 常见问题速查表现象可能原因解决方向登录报错 18456账号禁用/密码错/验证模式不对检查登录名状态和服务器验证模式能登录但看不到库默认库无权限或不存在改默认库或补数据库用户查表报权限不足角色没加或查的是视图核对角色成员视图单独授权写操作没被拦住误加了写角色检查并移除 db_datawriter 等角色视图查不了只加了 db_datareader对视图单独 GRANT SELECT账号连不上远程协议/端口/防火墙检查 TCP/IP 和网络配置5.5 几个我踩过的实操心得心得一账号命名一定要带用途和责任人。我现在的习惯是app_报表系统_只读、vendor_某公司_只读这种格式虽然长但半年后你一眼就知道这号能不能删。心得二程序账号和人工账号分开建。程序用的账号密码写死在配置里人工用的账号走密码策略。混在一起的话程序账号密码过期会导致服务中断人工账号不过期又不符合安全要求。心得三定期审计只读账号的实际权限。我见过太多“当初说只读后来临时加了个写权限忘了回收”的案例。建议每季度跑一次权限核对脚本把db_datareader之外的额外授权都列出来复查一遍。心得四给外部人员的账号加登录时间限制。SQL Server 本身不直接支持时间段限制但可以通过登录触发器实现或者干脆用作业定时禁用/启用。这个属于进阶玩法有需要可以单独展开。6. 两种方式的对比与选型建议把两种方式放一起对比一下方便你按场景选。对比维度SSMS 图形界面T-SQL 脚本上手难度低点鼠标即可中需理解语句可复现性差步骤靠记忆强脚本可存可传批量操作几乎不可行天然支持审计留痕弱强可进版本库出错概率高容易漏勾低一次写对反复用适合场景一次性配置、教学生产部署、批量运维我的实际做法是新环境第一次配置用 SSMS 走一遍建立直观认知然后把等价脚本整理好存进运维文档之后所有环境一律跑脚本。这样既不会因为不熟脚本而配错也不会因为只会点鼠标而效率低下。还有一点值得说脚本方式天然适合做权限基线。你可以把“标准只读账号”的创建脚本固化下来新服务器上线时直接跑保证每台机器的权限配置一致。这种一致性在出故障排查时价值巨大因为你知道所有环境的行为应该是一样的。7. 权限之外几个容易被忽略的安全细节只读账号配完了不代表安全就做到位了。有几个延伸点做运维的应该心里有数。第一连接加密。默认情况下 SQL Server 的连接可能是不加密的账号密码在网络上传输存在被截获的风险。生产环境建议配置强制加密客户端连接时勾选加密选项。这也是为什么很多人连老实例时会遇到证书相关的报错——因为加密配置和证书不匹配。遇到这类报错正确做法是配置受信任的证书而不是简单关掉加密。第二账号密码的存放。程序账号的密码不要明文写在代码或配置文件里用配置中心或者加密存储。这个虽然是老生常谈但每年还是能看到因为密码泄露导致的数据事故。第三登录失败的监控。只读账号如果被暴力破解登录失败日志里会有大量记录。建议对登录失败做监控告警异常频率及时介入。SQL Server 的错误日志和 Windows 事件日志里都有记录可以配合监控工具采集。第四最小化元数据暴露。前面提过普通账号默认能看到部分元数据。如果连表名都敏感可以通过DENY VIEW DEFINITION或者控制元数据可见性来限制。这个配置要谨慎因为可能影响正常查询建议在测试环境验证后再上生产。8. 写在最后的一点个人体会配只读账号这件事技术含量确实不高但它特别能反映一个人的运维习惯。我见过太多人图快直接给高权限也见过有人把权限卡得死死的但自己都记不清给了啥。这两种极端都不好。真正靠谱的做法是权限给到刚好够用配置过程可复现事后可审计。SSMS 和脚本两种方式本质上是在“直观”和“可复现”之间做权衡理解了这一点你就知道什么时候该用哪种。最后分享一个我一直在用的小习惯每次给新账号配完权限我都会在运维文档里记一行——账号名、用途、责任人、创建日期、权限范围。看起来是小事但等到半年后有人问“这个 report_readonly 是谁建的、能不能删”你能三秒钟给出答案而不是翻半天聊天记录。这种确定性才是运维工作里最值钱的东西。