最小特权原则：最小化访问如何保护系统

除了我和伴侣之外，还有四个人握有我们家的钥匙：我们最好的朋友，以及我的公婆。他们各自有一套钥匙，以便在我们度假时帮忙给植物浇水，或借走几把椅子办派对。我没有把钥匙给任何邻居，因为我们彼此不太熟，而且我也看不出他们在我外出时需要进屋的理由。我不会把钥匙藏在花盆底下让谁都能用，更不会出门时把门敞开。那简直是在招灾，对吧？

同样的道理也适用于网络安全：只授予人和系统为完成其工作所最低限度所需的访问权限，不多也不少。这就是最小特权原则，简称 PoLP。没有默认的管理员权限，没有“以防万一”的超级用户权限，更不能让通行无阻的“全能通行证”遗留在被遗忘的测试账号里。一个人拥有的访问越多，一旦出问题就会损失越大！

本文将带您了解 PoLP 在幕后如何运作，以及为什么它是降低风险最有效的方法之一。阅读本文并不需要网络安全背景。事实上，我们的目标是把这个概念讲得足够通俗，让任何参与技术项目的人都能落实它，从而让您的应用更安全一点！

什么是最小特权原则？

最小特权原则（PoLP）有时也被称为最小权限原则（PoMP）或最小授权（PoLA）。它的字面意思就是：仅向个人或系统授予完成其工作所需的最少权限。不是可能会需要的最多权限，也不是最容易配置的权限，而是他们实际需要的，仅此而已。

重要的是，这不仅适用于人。PoLP 适用于所有人和所有事物：用户、服务、应用、虚拟机、API，甚至后台进程。只要它能登录或访问资源，就应视为潜在风险，只允许其执行必要操作。

遵循这一原则会迫使您更有目的性地思考：谁真正需要访问什么？需要多长时间？如果这些“钥匙”落入不当之手会发生什么？

最小特权原则如何运作

好的，我们已经看到 PoLP 的核心是把访问限制在最低限度。但在实践中，这并不意味着频繁地说“不了”。而是要设计有意授予访问、限时生效并带有护栏的系统与流程。可以采用以下几种策略：

基于角色的访问

与其临时给单个用户分配权限，不如分配“开发者”“分析师”“财务”等角色，每个角色都有预先定义的访问规则。这样更干净、更易管理，也能避免零星例外随着时间堆积成乱象。

限时或即时（JIT）访问

有时确实需要提升权限，但仅限于特定任务或时间窗口。通过 JIT 访问，用户可以请求临时提升权限，通常会设置明确的到期时间。

特权括起（Privilege bracketing）

这是 JIT 的更技术化做法：脚本或用户在执行某个操作时短暂获得提升的权限，随后立即降回普通级别。这在 DevOps 工作流中相当常见。

零信任等现代访问模型

PoLP 在零信任网络访问（ZTNA）中也扮演重要角色。在零信任模型中，没有任何用户或设备被默认信任：每次都必须证明身份，并说明访问请求的合理性。最小特权从一开始就融入其中。

这里的关键要点之一是，PoLP 不仅关注您是谁，还关注您此刻需要什么。

为什么最小特权原则很重要

当系统、用户和进程只拥有其真正需要的访问权限时，您就能降低事故风险。自本文开头以来我已反复强调这一点。那么在实践中风险是如何降低的呢？

缩小攻击面

授予的访问越多，攻击者就有越多可利用的空间。如果被攻陷的账号只能访问一个数据库，损害就止步于此。如果它能访问一切？那就听天由命吧。

限制恶意软件横向传播

恶意软件常通过在系统之间横向移动来传播。最小特权会把这些路径封死。即使系统某一部分被攻破，PoLP 也能帮助将感染控制在局部。

防止权限提升

攻击者喜欢把低权限账号变成管理员账号。有了 PoLP，权限范围被严格限定，权限提升的可乘之机就小得多。

防范内部威胁

风险并不全来自外部。有时员工会犯错，或者不幸的是，有人会带着目的行事。PoLP 在两种情况下都能缩小影响范围。

加速事件遏制

一旦出了问题，清楚地知道谁能访问什么会让遏制工作容易得多。您不必在“权限宾果”里手忙脚乱，眼看着火势蔓延。

支持合规

GDPR、HIPAA 和 PCI DSS 等法规都要求强有力的访问控制。PoLP 通过确保只有合适的人才能访问敏感数据，帮助满足这些要求。

提升运营清晰度

当每个人都仅拥有完成其工作所需的访问时，审计更容易、逻辑更清晰，也更不容易出现“权限蔓延”（那些没人记得何时授予、可能已不再需要却一直保留的权限）。

如果您希望围绕这些实践建立更稳固的基础，我们的数据安全入门课程将更深入地讲解 PoLP、加密与安全系统设计等核心原则。

最小特权原则的实践示例

好了，理论够多了。让我们看看 PoLP 的一个实际案例。

一家中型科技公司突然收到一个紧急事件：生产环境中的一个缺陷导致客户仪表板出错。三个人被拉来处理：Corey、Luca 和 Sam。他们各自的角色截然不同，更重要的是，他们的访问级别也完全不同。

Corey - 前端开发工程师

Corey 负责该仪表板的 UI，因此被请来排查。他拥有：

• 对前端代码库和 Web 应用 CI/CD 流水线的访问权限。
• 只读访问最近一次部署的日志。
• 不直接访问生产数据库或云基础设施。

Corey 发现，客户姓名的渲染方式最近有所调整，可能因为 API 返回了意外的空值而失败。他将问题标记为需要进一步深挖，但他不能（也不该）SSH 到生产环境或自行查看数据库。他的访问范围与其角色完全匹配：UI 代码、日志，且无任何高危权限。

Luca - 站点可靠性工程师

Luca 负责基础设施。收到 Corey 的提示后，他开始更深入地追踪问题。他拥有：

• 对Kubernetes 仪表板和集群日志的访问权限。
• 能够重启服务、回滚部署以及临时扩缩系统。
• 即时访问生产数据库的读取权限，仅通过内部审批工具授予。

Luca 利用权限检查 API 服务日志，注意到最近一次迁移引发了轻微的数据不一致。为确认这一点，他请求了限时数据库访问，获批后读取了受影响的行，然后其提升的访问权限在 30 分钟后自动过期。

如果您像 Luca 一样与数据库、流水线或云基础设施打交道，理解数据系统的构建方式有助于从一开始就设计安全的访问机制。我们的理解数据工程课程是一个不错的起点。

Sam - 财务负责人

与此同时，Sam 需要通知客户成功团队受影响的用户，以及这对其订阅和 SLA 的影响。她拥有：

• 一个由生产数据库只读分析副本驱动的仪表板工具的访问权限。
• 可以导出报告，但不能运行自定义查询，也无法查看任何敏感的内部日志。
• 无权访问生产服务器、代码或开发者工具。

Sam 根据事件报告中标记的客户 ID，在内部仪表板中筛选计费层级与使用数据来生成报告。她完成工作不需要更多权限，即使想越权，也挖不进不该看的内容。

在这个例子中，每个人都拥有所需权限，不多不少。Corey 不可能误删数据库表。Luca 的提升权限有明确的时间盒并被记录。Sam 能回应干系人，却从未接触生产基础设施。

如何实施最小特权原则

先说明一点：实施 PoLP 并不需要您一夜之间推倒重来。哪怕是很小的改动也能带来很大差别，从小做起完全没问题！

步骤 1：开展权限审计

在收紧访问前，您需要先弄清谁拥有什么。您需要审查：

• 用户账号（员工、合同工、服务账号）
• 应用与集成
• 后台进程或脚本
• 云角色、数据库用户、SSH 密钥，以及您能想到的其他一切。

留意共享凭证、默认账号具备 root 访问，或自 2018 年起就未调整过的角色等红旗问题。

步骤 2：从最小权限起步

无论创建新账号是人还是机器，都应默认授予最低访问级别。如有需要，再让用户或服务请求更多权限。事后补加权限比在出事后清理过度授权的账号要容易（也更安全）。

前几周可能会有点烦，您会收到很多请求，但等大家把角色所需的大多数任务做过一两次后，情况就会稳定下来。

步骤 3：强制权限分离

将管理员角色与普通用户角色分开。如果有人需要两者（例如 DevOps 工程师），请使用不同账号或会话：一个用于日常任务，另一个仅在特定操作时启用提升权限。这样可以降低意外（或恶意）滥用的风险。

步骤 4：实施即时（JIT）权限

使用支持临时提升访问的工具，正如我们之前讨论的。比如：

• 会过期的数据库凭证
• 30 分钟后自动撤销的云角色
• 与特定任务绑定的审批流程

步骤 5：监控并记录活动

日志不仅用于调试。需要跟踪：

• 谁访问了什么
• 何时发生了权限提升
• 对角色或权限组的变更

在审计、事件响应或了解系统日常使用情况时，这些数据都极其宝贵。

步骤 6：定期审查与调整

即便是最好的设置也会随着时间漂移。岗位变化、团队演进、老工具退役。安排周期性审查（按季度是个不错的开始），清理未使用账号、调整权限，并在权限蔓延成为问题之前加以发现。

挑战与局限

理论上，PoLP 听起来很简单：别发放超过必要的访问。在实践中？会复杂一些，尤其是在大型、快速运转、遗留系统众多、团队变化频繁且请求源源不断的环境里。

大型组织中的复杂性

在大公司里，没人能完整掌握谁能访问什么。团队重叠、职责模糊，理顺现有权限感觉就像在玩叠叠乐。您移除了团队 1 不应需要的权限，却不巧让 Scott 无法开展工作。结果发现，Scott 会在 Matt（团队 2）休假时代班，因为那曾是他去年的岗位，直到他转岗。实施 PoLP 往往需要跨部门协调，这既耗时，也需要相当的沟通技巧。

生产力放缓的风险

如果过于激进地收紧访问，就会造成瓶颈。人们会被审批流程卡住，或在拿不到那一个关键权限前无法开展工作。这在小公司尤为明显，因为每个人都会身兼数职。我在一家初创公司就遇到过一次：连续 3 周里，每次需要权限都要等 2 小时（而我每周至少要申请 5 种不同权限），最后我只好直接申请管理员角色。申请获批后，我拥有了远超所需的访问，但至少能把工作做完。

总之，最糟糕的做法就是让 PoLP 给人一种官僚作风的感觉。它必须与顺畅的权限提升流程和良好的沟通配套实施。

在处理遗留系统或不断壮大的团队时，在安全与效率之间寻找平衡本就不易。我们关于如何维护数据安全的博文探讨了如何在实践中保持安全且不拖慢进度。

“万事通”的遗留应用

有些老系统在设计时根本没考虑过细粒度权限。它们默认需要广泛访问，在严格控制下可能会出错（或无法使用）。在这种情况下，您可能需要把应用隔离在沙箱环境中并密切监控，同时规划长期修复方案。

权限蔓延隐蔽且监控耗力

随着时间推移，用户会不断积累访问权限。有人被“暂时”加入某个组，然后就一直没人把他移除。这种缓慢而隐秘的积累被称为权限蔓延，它是需要定期审计的最大原因之一。六个月前合理的权限，今天可能完全没有必要。即使您把权限限制得滴水不漏，仍需要跟踪谁在何时以何种原因使用了什么。缺乏可靠的日志与监控，PoLP 将更难执行，也更难在审计或事件响应中拿出证据。

说实话，PoLP 并不省心，也谈不上有趣。但我们必须承认它值得去做。就像给前门上锁一样，它用一点小小的摩擦换来了极大的安全性。

相近原则与相关概念

零信任架构

零信任颠覆了传统安全模型。它不再假设网络内部的一切都是安全的，而是默认把每个用户、设备和应用都视为不可信（即使它们已经“在内部”！）。

在零信任环境中，最小特权不仅是最佳实践，更是硬性要求。每一次访问请求都会被实时评估，用户或服务仅被授予完成所需任务的最低限度访问，通常还会限时、限任务。

这通常通过以下方式实现：

• 基于用户身份、设备类型、地理位置和要执行的操作等因素的动态、细粒度访问控制。下文会详细介绍。
• 持续评估风险的策略引擎，而非只在登录时评估。
• 即时访问结合详细日志与自动撤销。

零信任架构。来源：Gartner

特权括起

我们之前提到过特权括起。它是指仅在需要执行特权操作的那一刻提升权限，随后立即降回。

它常用于高安全环境，在那里长期开放完整管理员访问风险太高。比如：

• 脚本在低权限用户下运行，但在那一条命令上使用sudo 重启系统服务。
• 部署流程临时承担一个高权限角色以修改基础设施，完成后自动撤销访问。

这在 DevOps 和自动化场景中特别有用。让后台进程 24/7 以 root 身份运行，就是一颗定时炸弹。

可信计算基（TCB）最小化

可信计算基包含系统用于强制执行安全性的所有组成部分。它可以包括操作系统内核、虚拟机管理程序、加密库和访问控制逻辑等。TCB 越小，审计与信任就越容易。

PoLP 与此相关，因为过度授权的软件会扩大 TCB。例如，如果一个日志守护进程可以写入任意系统文件，它就成了 TCB 的一部分（尽管本不该如此）。降低权限能减少任何单一组件破坏系统的风险。

如果您关注安全操作系统设计、虚拟化、嵌入式系统或高安全云环境，可能会接触到 TCB 最小化。

基于属性的访问控制（ABAC）

传统访问控制依赖静态角色（如“管理员”或“支持”），而 ABAC 基于属性做出决策，即与用户、资源或请求相关的上下文数据。

例如：

• “如果用户属于人力资源部且使用公司发放的设备且处于工作时间，则允许访问。”
• “如果请求来自公司 VPN 之外，则阻止访问敏感数据。”

ABAC 是零信任环境的关键组成部分，因为它能做出细粒度、实时的访问决策，适应不断变化的条件。它并不取代 PoLP，而是通过在最低基线权限之上叠加情境化权限来加以强化。

要点回顾

好了，内容不少！希望您现在对 PoLP 有了更深入的理解。请记住：

• 访问应始终是有意而为。 用户、系统和应用只应拥有完成工作所需的权限，不多不少，不永久，也不是“以防万一”。
• PoLP 不仅适用于人。 它同样适用于服务账号、脚本、API、物联网设备、容器……凡是能彼此通信的东西都适用。
• 权限蔓延真实存在。 缺乏定期审查，人们就会积累不再需要的权限。定期审计与良好范围界定的角色有助于保持清洁。
• 即时与临时访问是好帮手。 在需要的那一刻提升权限，然后立即收回。系统处于高权限状态的时间越少越好。

尽管短期内看起来会更麻烦，但 PoLP 并不是要让您的生活更难，而是为了在错误与泄露不可避免时，尽可能降低代价！