任何用户、程序或系统组件，只授予完成自身任务所必需的最小权限，其余访问一律默认拒绝。这不是一道可做可不做的安全配置，而是账号泄露、内鬼操作、横向攻击等绝大多数安全事件的第一道防线，下面从概念、配置方法到落地场景，一次性讲透。
最小权限原则是什么
最小权限原则（Principle of Least Privilege，简称POLP）起源自美国军方早期的多级安全模型，后来被Saltzer和Schroeder在计算机系统安全设计中正式总结，行业共识认为，它是信息系统安全设计的基石性原则之一。
这个原则不复杂,拆开看就三层意思，第一，权限范围收窄，只给完成本职任务必需的权限，第二，权限时长最短，用完即收回，第三，权限粒度最细，能限定到单条命令、单个文件、单个数据表就别给整个目录或整个库。
举个日常场景,公司前台小张的职责是录入客户信息，那他的账号只需要对客户信息表的“插入”和“修改”权限，不需要让他有删除权限，更不需要给他整个数据库的管理员账号，一旦小张的账号被钓鱼，攻击者能做的也只是改几条客户信息，而不是把整个数据库拖走。
与最小权限相对的是“默认允许”思维，很多企业在配置系统时，习惯先给所有权限，遇到不够再收紧，这种做法刚好反了，最小权限要求先拒绝一切，再按需逐个开放。默认拒绝是从源头上掐断越权访问的可能。
最小权限原则怎么配置
配置最小权限没有统一脚本,但有通行的四步法，适用于服务器、数据库、云平台、应用系统各类环境。
- 第一步,梳理资产与角色，列出系统里所有账号、服务、API密钥，标注每个人或程序实际要做什么。
- 第二步,绘制访问路径图，从登录到操作到数据落盘，一步步画出需要经过的资源。
- 第三步,按需授权，每项权限对应一条业务理由，没有理由的权限一律撤销。
- 第四步,定期审计与回收，权限不是一次性配置，员工转岗、项目结束、服务下线，都要同步清理权限。
配置过程中有个常见误区：把“管理员账号”当成角色下发，正确做法是区分
身份与权限，人可能只有一个，但权限应该通过角色临时授予，用后即回收。
Linux权限最小化设置方法
Linux是使用最广泛的服务器系统,权限最小化操作很具体，建议从用户、文件、命令三个层面入手。
-
用户层面,禁止用root直接登录，为每个业务创建独立系统用户，修改
/etc/ssh/sshd_config，设置PermitRootLogin no，日常操作通过sudo提权，并在/etc/sudoers中精确指定可执行命令，例如开发人员只需要重启某个Java服务，就只给这条命令：dev ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart demo-app千万别写成
dev ALL=(ALL) ALL，这等于把整个系统交给了一个普通开发账号。 -
文件层面,用
ls -l查看文件权限，执行chmod收紧，数据目录通常设置为750（属主读写执行，属组读执行，其他人无权限），对敏感配置文件如/etc/shadow，权限必须是640或更低。 -
命令层面,利用sudoers实现对命令的精细控制，超出白名单的命令一律拒绝，对于运行中的服务进程，使用
systemd的ProtectSystem=strict、ProtectHome=true等安全指令，让进程即使被攻破也只能访问指定目录。
这些命令写出来很简单,真正难的是坚持“先授权后使用”的习惯，部分运维人员为图省事，把sudo权限直接给通配符，这在本质上又回到了默认允许的老路。
最小权限原则 数据库账号权限配置
数据库是数据资产的核心,权限配置有行业惯例可直接套用。
-
MySQL,业务账号只授权特定库表，常规配置如下：
GRANT SELECT, INSERT, UPDATE ON appdb.orders TO 'app_user'@'10.0.0.%';
禁止使用
GRANT ALL ON .给业务账号，后台分析账号可单独创建，仅授SELECT权限，避免误操作写入脏数据。 -
Redis,如果只是做缓存，关闭所有危险命令，在
redis.conf中设置：rename-command FLUSHALL "" rename-command CONFIG "" enable-protected-configs yes生产环境务必开启
requirepass，并限制bind网段。 -
PostgreSQL,使用
REVOKE先收回默认权限，再按角色GRANT，思路是先将public模式权限全部回收，再给指定角色开放对应表。
数据库权限审计建议每季度执行一次,通过SHOW GRANTS查看账号权限清单，对长期未使用的账号直接DROP，不少安全事件就是“僵尸账号”引发的，账号在，权限在，但人早走了。
权限最小化方案：从账号到API的落地
只谈服务器和数据库还不够,现代应用系统的权限最小化必须覆盖API接口、云平台凭证和第三方集成。
-
API密钥管理,开发环境、测试环境、生产环境的密钥必须隔离，密钥权限精确到接口级别，例如支付回调接口和查询接口分开授权，查询密钥即使泄露，也无法发起支付操作。
-
云平台RAM策略,主流云厂商均基于策略语法控制资源访问，配置时用条件键缩小范围，比如限制来源IP、限制访问时间、限定资源标签，例如仅允许某运维账号在办公网段内操作指定ECS实例。
-
微服务内部调用,服务间通信使用短期令牌（如JWT），设置极短有效期（例如5分钟），并校验服务身份标识，长期有效令牌是内部攻击的放大镜，一旦提取整个集群都暴露。
-
第三方集成授权,对接外部系统时，用OAuth 2.0的单次授权码模式，取消“永久授权”勾选，在“西装革履”的合同谈判中，对方往往要求宽泛权限，务必坚持按接口粒度授予，不合理的直接砍掉。
最小权限与合规要求
从合规监管视角看,最小权限已经写入多项标准，国内网络安全等级保护2.0（等保2.0）在访问控制章节明确要求对管理用户权限进行分离和最小化配置，欧盟GDPR第25条提出数据保护设计原则，默认数据最小化，与权限最小化一脉相承。
据工业和信息化部数据,近年来国内数据泄露类安全事件中，相当一部分源于内部权限管控失效，业内专家指出，权限失控的内在原因是组织架构变动与权限调整脱节，员工从A部门调到B部门，原部门权限不回收，权限越积越多，最终形成“超级账号”。
云安全联盟（CSA）发布的最佳实践里，反复提及“按需分配”和“定期复审”两个关键动作，合规不是做给别人看的展览品，而是实实在在控制安全风险的流程。
常见问题：最小权限相关解答
最小权限和默认拒绝是一回事吗？
不是,最小权限是目标状态，默认拒绝是具体策略，默认拒绝是“没有明确允许，就是拒绝”，这种策略是达成最小权限最有效的手段，你可以有默认拒绝的网络ACL，也可以有默认允许但手动收窄的权限列表，前者通常更安全，监管也更认可。
最小权限会不会影响业务人员的办公效率？
初期配置严格确实会带来少量额外申请流程,但长远看是增效的，权限范围小，误操作概率低，排障时间缩短，一位只负责编辑文档的员工，不需要拥有删除整个共享目录的权限，这既保护了数据，也保护了他自己，更现实的是，权限越少，账号泄露后的损失边界越清晰，业务连续性反而更有保障。
怎么验证当前系统的权限是否符合最小权限原则？
一个简单思路是“排空测试”：将某个账号的权限全部收回，再按照业务文档逐项放行，无法说出用途的权限不予开放，另一个做法是审计日志分析，查看过去90天内实际调用过的API、执行过的命令、访问过的数据表，以实际行为反向校验授权清单，若长期未用的权限远超使用的权限，就说明最小权限没有落实到位。
最小权限原则的价值不在于“卡住所有人”，而在于让每一次访问都经得起审计，把默认拒绝变成习惯，把按需授权变成流程，把定期清理变成制度，安全水位自然会提升，系统如此，人也如此不该有的权限，一分不给。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/694235.html
