最小权限原则，解析

最小权限原则一旦说出来就显而易见：只给账户、进程或用户执行其工作所需的访问权限，不多一分。在说法和实际系统运行方式之间的差距是大多数安全漏洞从小事故演变成完整域入侵的地方。

它的实际含义

最小权限原则（PoLP）说系统中的每个主体——用户、服务账户、应用程序、容器——应该以完成其功能所需的最少权限集合运行。不是方便的权限。不是某个人三年前授予然后忘记撤销的权限。是最少的权限。

这适用于每一层：文件系统权限、数据库角色、API 作用域、云 IAM 策略、防火墙规则、sudo 访问。读取静态文件的 Web 服务器进程不需要对 /etc 的写权限。只运行 SELECT 查询的报告脚本不需要具有 DROP TABLE 权限的数据库角色。市场部实习生不需要域管理员权限，哪怕那样比琢磨正确的组要简单。

为什么它的重要性超过看起来的样子

当攻击者入侵一个账户或进程时，他们继承该账户能做的任何事。如果被钓鱼的员工笔记本电脑只能访问与其团队相关的文件共享，那个钓鱼的影响范围就被限制住了。如果同一个账户碰巧拥有域管理员权限，因为 IT 曾经为了故障排除这样设置过，然后从未回滚，那么攻击者现在已经掌控了整个网络。

这是大多数漏洞后取证报告背后的逻辑：初始访问价值低，但通过权限过度的账户的横向移动把它变成了整个环境上的勒索软件。权限过度不会导致初始入侵，但它几乎总是让入侵变得昂贵的原因。

它在实践中的表现

云 IAM。 AWS、Azure 和 GCP 如果你不小心，都会默认为宽松行为——一个具有 "Action": "*" 和 "Resource": "*" 的 IAM 策略会通过验证且运行良好，直到一个泄露的访问密钥把攻击者交给完整账户控制。将策略的范围限定到特定操作和资源 ARN，而不是求助于通配符。

服务账户。 这些常常是最严重的违规者，因为没有人以审查人工账户的方式审查它们。一个部署到一个 S3 桶的 CI/CD 管道不应该持有能读取账户中每个桶的凭证。

数据库角色。 将只读报告角色与需要 INSERT/UPDATE 的应用程序角色分开，并将那些与能改变架构的 DBA 角色分开。PostgreSQL 和 MySQL 都支持细粒度的 GRANT 语句——使用它们，而不是给每个应用程序连接相当于 root 的权限。

Sudo 和本地管理员。 即时提升（请求访问、在有限时间窗口内获得它、自动失去它）总是好于常驻管理员权限。具有时间限制规则的 sudo 之类的工具，或企业环境中的 PAM 解决方案，存在的目的正是这个。

与