关于最小权限、JIT 与强授权

我从事安全专业工作已超过 20 年。我数不清自己说过多少次“最小权限”。它就像一句小小的口头禅，与“纵深防御”和“内部威胁”并列。

但是，告诉别人要落实最小权限，然后转身走出房间，无异于医生在保险体检中判您不合格，叮嘱您“吃得健康一点”，随后走出房间并向您多收费用。

最小权限是实实在在的，它很重要。与每 90 天更换一次密码不同，它能对提升安全性产生实质影响。

最小权限同样非常难以实现，在大规模环境中尤其如此。而且它对您最重要的用户并不奏效。

为什么？ 因为最小权限并不是您此刻所需的最小权限，而是您为完成工作可能在任何时候需要的最小权限……永远如此。而当某人需要执行超出这些权限最初映射范围的操作时，就会触发一个缓慢的变更流程，必须跨越不同的团队和管理者。

或者有时您只能去说服 Bob 给您访问权限。而 Bob 是个颇有戒心的难缠角色，因为他谁都不信任，也不想在您搞砸时被追责。

即便实施了最小权限，如果攻击者拿到了这些凭据（云原生泄露事件的首要成因），他们仍然很可能做出恶意行为。因为虽然对普通用户或员工实施最小权限通常不算太糟，但对于按设计就需要更多权限的开发人员和管理员来说，落实起来确实非常困难。

正如我们用 MFA 实现强身份验证一样，我们也需要某种手段来实现强授权。

这正是即时授权（Just in Time，JIT）发挥作用的地方。与其事先设法厘清某人需要的全部权限，不如让他们在任何时点申请有时限的权限。我现在认为，JIT 应当成为管理性访问和敏感访问的标准做法。

我的建议是：最小权限对于一般用户访问是一个很好的理念，但在云中，对于任何级别的管理员/开发/敏感访问，JIT 更为合适。

即时授权

JIT 是 PIM/PAM 的一种形式。特权访问管理和特权身份管理是用于提升用户权限的系统。用户平时以较低权限运行，直到需要提权为止；这些系统会采用多种技术来提供扩展的访问权限，通常针对有时限的会话。今天不打算深入探讨其中的细微差别，但其优势在于既保持灵活性，又维护了安全性。用户必须在需要时申请额外权限，因此即使其凭据遭到泄露，攻击者所能做的仍然有限。

“JIT”（Just in Time）是实现 PAM/PIM（其实也适用于任何访问）的一种技术。用户拥有的基础凭据可能完全无法访问任何资源，然后在其提出申请时再提升权限。我们自己就在使用 JIT（在 Cloud Defense 中亦可使用），Netflix 也基于其内部工具发布了一款名为 ConsoleMe 的开源工具。Azure 内置了一项名为 Entra ID Privileged Identity Management 的服务（但需额外付费）。（Entra ID 就是我们以前所说的 Azure AD，直到有人认为出于品牌考虑去让数百万客户困惑是个好主意。）此外还有更多选择，这里只是举例。

为增强安全性，JIT 需要采用带外审批流程并提供有时限的访问权限。这些是基本要求。申请与审批应通过不同于常规身份验证的路径进行，类似于一种 MFA 形式。区别在于，MFA 是用于身份验证的带外因素（证明您就是您所声称的人），而 JIT 是一种授权形式（您申请并获得执行某项操作的许可）。

管理摩擦

最小权限和 JIT 都会带来摩擦。其实，我们在安全领域所做的一切都会带来某种摩擦，尤其是 Bob。对于最小权限，主要摩擦在于定义和部署权限的管理开销，以及当有人缺少所需权限时会出现什么故障。对于 JIT，摩擦则在于提交申请并获得审批的过程。

由于长期使用并研究最小权限和 JIT，我总结出了一些减少摩擦的方法。在某些情况下，您最终会获得更快、更好流程，而不是我们以往的做法

• 申请与审批流程必须是实时的。这意味着通过 ChatOps、短信，或者随新冠疫苗一起植入您体内的 5G 芯片来完成审批。
• 对于权限较低的访问，例如对某些日志的读取权限，您可以而且应该支持自助审批。这有什么帮助？因为它仍然使用带外流程，并降低了攻击者利用丢失/被盗/泄露凭据的可能性。
• 您还可以支持自动审批，甚至无需点击进入自助审批。这有什么帮助？您可以自动审批，同时利用带外渠道通知权限已被提升。如果您曾向自己的 Netflix 或 Hulu 账户添加设备，就可能见过这种做法。仅仅是知情本身就可能极为有效。
• 如果这是面向开发人员的，您需要支持命令行以及他们使用的其他工具。主动贴近他们。让使用变得极其简单。如果您强迫他们登录某个安全工具，项目就会失败。
• 如果审批人无法即时响应，您就会失败。不要让 Bob 成为唯一的审批人。

在开发人员/管理员已经使用的工具中为他们提供这项能力。让它快速且无摩擦。理想情况下，要比打开密码管理器或在塞满 374 个云账户的 SSO 门户里点来点去更简单、更快捷。给 Bob 买点饼干吧，巧克力曲奇。（等等，那是我。）

您还可以使用自动化来减少最小权限访问的摩擦。Duckbill Group 在 Chris Farris 的帮助下，使用不同的技术实现了他们自己版本的自动化最小权限。AWS Access Advisor 之类的工具可帮助您监控已使用的权限并对其进行收紧。自动化可帮助您大规模实施最小权限，也可以作为 JIT 的补充。

何时使用哪一种

最小权限绝非过时的概念。对于需要相当稳定访问级别的日常用户/员工而言，它仍然是黄金标准。JIT 最适合权限更高的访问，尤其是对生产环境的访问，尤其是在云中——凭据泄露是那里最大的漏洞来源。以下是我们自己使用它的场景：

• 开发人员对生产环境的读取访问。
• 开发人员对生产环境的变更访问（CI/CD 之外）。限制严格得多，需要更多审批人。
• 对生产账户的管理员访问。
• 事件响应访问。
• 部分开发账户访问，因为这比返回 SSO 门户更快，在使用命令行时尤其如此。

我不再认为，仅靠最小权限对于云（IaaS/PaaS）中任何较高级别的特权访问是一个可行的概念，即便我们使用了强 MFA。随着时间推移，在大规模环境中妥善界定权限范围太难了。在这些用例中，JIT 是远为更好的选择。当需要长期保持一致的权限时，最小权限仍然非常可行，尤其是在结合良好的访问日志记录和 MFA 时。JIT 是 MFA 的搭档。它是与强身份验证相配的强授权。随着我们继续将更多关键操作迁移到暴露于互联网的管理平面，JIT 就是出路。