最小权限原则

起源与核心思想

1975 年，Jerome Saltzer 和 Michael Schroeder 在论文《The Protection of Information in Computer Systems》中首次系统阐述了最小权限原则。他们的出发点是：每个组件一旦被攻破，其造成的伤害只限于该组件被授权访问的资源范围。

原则的对立面——过度权限（Overprivilege）——在现实中极为普遍。数据库连接账号用 root 运行、Lambda 函数的 IAM 角色带 *:* 全量权限、Docker 容器以 root 用户执行业务进程、Kubernetes Pod 无 securityContext 限制、开发环境数据库账号密码直接复用到生产环境，这些都是最小权限原则缺失的具体表现。

2020 年 SolarWinds 供应链攻击中，攻击者在得手后之所以能横向移动到大量客户环境，部分原因正是 SolarWinds Orion 平台被设计为需要域管理员级别权限运行，一旦被植入后门，获得的就是顶级权限。[1]

各层次的实践

数据库层：Web 应用的数据库账号只授予所需表的 SELECT/INSERT/UPDATE/DELETE，不给 DROP TABLE、FILE、SUPER 等危险权限；只读报表账号只授 SELECT。

云 IAM 层：AWS 推荐先用 IAM Access Analyzer 分析实际调用记录，生成精细策略，而非直接授予 AWS 管理策略（AdministratorAccess）。Google Cloud 的 VPC Service Controls 在此基础上还能限制服务账号的网络访问范围。

容器与 OS 层：容器以非 root 用户运行（Dockerfile 中 USER 1000）；使用只读文件系统；Kubernetes 的 SecurityContext 设置 allowPrivilegeEscalation: false；Linux Capabilities 按需添加而非直接 --privileged。

人员权限层：员工权限按职责精确划分，离职立即吊销；生产环境的高权限操作走审批流程，日志不可抵赖。