权限给多了没人会觉得有问题

权限问题很少是某一次错误决定造成的，更多是一点点加上去的。为了让某个脚本跑起来，给它开了高权限；为了方便排查，把某个账号加进了管理组。半年之后，谁也说不清哪些权限是必要的，哪些只是当时顺手。

越权访问的后果和被盗号不太一样。账号是自己的，操作记录也是自己的，事后很难分辨哪些动作是本人做的。这也是为什么权限要按用途分，而不是按人分。

判断一个账号的权限是否合适，可以问一个简单的问题：如果这个账号的凭据泄露了，最坏能造成多大影响。答案如果超出它的职责范围，就该考虑收一收。

先把账号本身理清楚

列出系统里所有的登录账号，标出每一个的用途和归属。注册了很久、没人认领的账号，通常是早期留下的；共用账号最难查，因为日志里所有人都叫同一个名字。

每个人的操作都用独立账号，看起来多了几步，实际上省了后面很多事。谁做了什么一目了然，人员变动时也只需要处理一个账号。

系统自带的账号不用删，但要确认它们不能直接登录。这类账号往往权限很高，又没有人在日常使用，最容易在很久之后被人翻出来利用。

执行权限和文件属主

允许某个普通账号执行管理命令的做法，等于给了它一把万能钥匙。确实需要提权的，把它限制在几个具体命令上，而不是整类权限。这样即使账号被拿走，能做的事也很有限。

文件的属主和权限位也要跟着看。网站目录被设成所有人可写，是最常见也最容易被利用的配置：任何能上传文件的入口，都可能变成写入可执行文件的地方。

服务运行用的账号尤其要单独划分。让网站进程以管理账号运行，图了一时方便，代价是任何一处代码问题都会直接变成系统级风险。

收完之后要验证

改完权限别只看配置文件，用实际账号试一遍：用普通账号去读不该读的目录、去执行不该执行的命令，看返回的是拒绝还是成功。很多配置写在那里，实际并不生效。

也要确认业务没被打断。定时任务、服务之间的调用、日志写入的位置，这些都可能因为权限收紧而报错，而且往往不是在改完的当天就出现。

最后把当前状态记下来，包括每个账号的用途和对应的权限范围。下次再有人申请加权限时，先对照这份记录，能挡掉不少临时需求。

定期重新过一遍同样重要。人走了、服务下线了，权限却还在，这类残留不会自己消失。

几个容易出问题的位置

网络上共享的目录，如果按账号统一给写权限，一个人上传的可执行文件可能被别人的进程调用。

数据库账号与系统账号的对应关系也要理清。很多站点用一个数据库账号跑所有功能，出了事无法区分是前台还是后台的操作。

远程登录用密钥比用密码好，但密钥文件如果放在共享盘或者代码仓库里，等于把锁和钥匙一起交出去。

提权操作应该留下记录。谁在什么时间用了什么命令，这条记录在追溯时非常关键，比事后靠印象回忆靠谱得多。

服务之间的调用也要单独划分身份。一个服务用管理账号去连另一个服务，图的是方便，代价是任何一处漏洞都能蔓延到全局。

新同事入职时按角色给权限，临时需要更多的，事后记得收回，别让临时变成长期。

权限调整之后，业务方有自己的使用习惯，改完和他们核对一遍，比单方面决定更稳妥。

难的不是设权限，而是长期保持清楚。把每次改变的原因写下来，半年后还有人看得懂。

定期把权限清单和实际配置对照一次，差距就是需要处理的地方。

运维用的跳板机要单独管理，登录路径集中在一处，比每个人都直连所有机器容易控制。

账号不再使用时，除了停用登录，还要检查它名下有没有遗留的定时任务和密钥文件。

权限变更要有审批的痕迹，即使只是几句确认，也能避免事后说不清是谁改的。

把这些要求写进新同事的入职说明里，比事后一次次提醒更省事。

权限管理没有终点，只有周期性的复查。