很多入侵事件的起点并不复杂：站点目录权限给成了 777，Web 进程又以高权限身份运行，攻击者传一个脚本上去，访问一次就拿到了服务器上的执行能力。还有一种情况是运维共用 root 账号，谁用过、什么时候用的，事后完全查不出来，一个人不小心把口令泄露出去，等于整个环境失守。
最小权限听着像一句口号，落到操作上就是几个具体的问题：谁能登录、登录之后能做什么、哪些目录可以被改、服务以什么身份在跑、数据库账号能碰到多少数据。把这几个问题一个个回答清楚，加固就完成大半。
把 SSH 的口令登录关掉，改成密钥；私钥自己保管好并加保护口令，不要把私钥随手放在跳板机的公共目录里。root 禁止直接登录，日常操作走普通账号，需要提权时用 sudo。sudo 不要一把给全部命令，按岗位给白名单，比如只允许重启服务、查看日志、清理缓存。sudo 的执行记录一定要留，它是事后追溯的主要依据。
站点目录的属主设成运行 Web 服务的用户，代码目录本身不给写权限——程序更新走发布流程，不需要让运行账号能改自己的代码。真正需要写的是上传目录、缓存和日志目录，这几个单独放开。上传目录还要额外禁止执行脚本，否则传上去的东西就能直接被访问运行。
配置文件里的数据库口令、密钥，权限收到 600，属主不要设成 Web 用户。临时目录挂上不可执行属性，能挡掉一部分落地二进制再运行的攻击方式。
给每个服务单独建低权限账号，不要图省事用 root 起 Node 或 Java 进程。容器里也一样，默认用 root 的运行方式会让逃逸后的权限直接拉满。数据库账号按库授权，应用账号不要给全库权限，更不要给建库、删表、授权这类管理权限——真被注入的时候，这些权限就是攻击者的放大器。
定时任务的权限经常被忽略：权限过松，本地任意账号都能往里面加条目，等于给提权铺了路。备份账号和生产运维账号要分开，备份数据能删得掉的环境，勒索软件最喜欢。还有开放端口，管理面板、数据库端口如果对全网开放，前面做的账号加固都会被尝试绕开。
举个具体例子。某次排查发现，应用使用的数据库账号对所有库都有读写权限，而配置文件对 Web 用户又是可读的，两者叠加的结果是：只要存在一处注入点，攻击者就能顺着配置文件读到口令，再连上数据库把其他业务的数据一起导出。把权限收回来之后，同一个注入点能造成的影响立刻小了许多——应用账号只能碰自己那几张表，配置文件对 Web 用户不可读，跨库这条路就断了。这个例子说明，最小权限不是某一项配置，而是一组相互配合的限制，只做其中一件往往起不到作用。
退一步讲，即便限制做全了，也不该假设一定能挡住攻击。加固的真正目的是让一次突破的代价可控，出问题时有边界、有记录、能收回来，而不是提供一个绝对安全的环境。
权限收敛之后，日常操作会多出一些确认步骤，比如提权时要输入口令、发布代码要走流程。这些步骤一开始会让人觉得麻烦，但它们同时留下了记录，出问题时能顺着记录找到人和时间点。把成本和收益放在一起看，这些麻烦是值得的。
简单的验证方式是用低权限账号做几件不该成功的事：往代码目录写文件、读配置文件、连数据库的其他库，看是不是都被拒绝。再定期复核 sudo 规则和对外开放的端口，确认没有新的口子被临时打开后忘记关掉。变更要有记录，否则下次迁移或者重装系统，一切又会回到默认状态。
售后客服
企业微信
