Windows服务器站点搭建：权限配置一步到位

　　去年二月份那会儿，运维组的老王被线上报警搞到抓狂——Windows服务器上新搭的站点，权限配置整得跟迷宫似的。前端小李提交了个静态资源更新，结果IIS报403，转头骂后端接口没开权限；后端老张查日志发现连数据库连接池都权限不足，又怼运维没配好服务账户。我原以为这帮人能自己吵明白，结果三小时后工单系统弹了二十条消息，全在@我：“这权限到底归谁管？”

　　其实那站点架构简单得很，就三层：Web层跑IIS，中间层是.NET Core，底层连SQL Server。可权限配置愣是搞出五套——IIS应用程序池账户、Windows本地用户、SQL登录账户、文件系统NTFS权限、还有个不知道谁加的共享文件夹权限。老王说他是按“最小权限原则”配的，可实际效果是：前端改个CSS要找运维开IIS读权限，后端发个API要找DBA开SQL执行权限，连日志文件都因为NTFS权限没配继承，导致服务账户写不进去，直接触发熔断。

　　手机亮了一下，是测试组在群里发截图：同一个接口，用管理员账户跑通了，用服务账户跑就报“未将对象引用设置到对象的实例”。我盯着屏幕冷笑——这他妈哪是权限问题，这是权限配置工具太垃圾啊！Windows自带的“本地安全策略”界面，跟二十年前似的，点个“添加用户”能卡三秒，配个文件夹权限得展开五层菜单，更别说跨服务的权限继承了，根本搞不清哪层生效哪层覆盖。

　　后来我直接甩了套PowerShell脚本给老王，核心就三行：

　　```powershell
　　$serviceAccount = "DOMAIN\AppService"
　　icacls "C:\inetpub\wwwroot" /grant $serviceAccount":(OI)(CI)M" /T
　　New-SqlLogin -Name $serviceAccount -LoginType WindowsUser
　　```

　　说白了，别用GUI手动点，直接脚本批量配。IIS应用程序池账户、文件系统权限、SQL登录，全用同一个服务账户，权限给到“修改”（M）就够——反正生产环境又不会让服务账户删系统文件。老王一开始还嘀咕：“这样不违反最小权限原则吗？”我直接怼回去：“你手动配的‘最小权限’，最后搞出二十个例外，反而更不安全！”

　　咖啡凉了，我抿了口，继续吐槽。其实这事儿最气人的是“优胜劣汰”的逻辑——Windows服务器权限配置，明明有更高效的工具（PowerShell、组策略），可大家就是不用，非要手点GUI。为啥？因为运维组KPI里没“配置效率”这一项，他们只关心“有没有按文档配”，不关心“配一次要花多久”。就像前端小李上次说的：“我改个按钮颜色要等运维半小时开权限，这接口QPS再高有个屁用？”

　　窗外天黑了，键盘声突然变响——是隔壁组在赶排期。我突然想起上个月招聘时，有个候选人简历上写“精通Windows权限管理”，结果面试问“如何用脚本批量配置IIS应用程序池权限”，他支支吾吾说“一般用GUI更直观”。我当时就笑了：这年头，连权限配置都要“直观”，那生产环境出问题谁负责直观？

　　说回老王那事儿，后来他用了脚本，三分钟配完所有权限，线上报警果然没了。但两周后，测试组又报了个问题：某个临时文件没配删除权限，导致服务账户写不进去。老王找我：“你不是说给‘修改’权限就够吗？”我翻了下文档，发现那文件是日志轮转生成的，确实需要“完全控制”。可问题来了：如果每个特殊场景都手动加权限，那脚本的意义在哪？

文章配图，仅供参考

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!