AWS 权限边界入门指南

AWS 权限边界令人困惑。我知道它们令人困惑，因为它们曾让我困惑，我花了好几年才弄明白。我还知道它们令人困惑，因为Corey Quinn 也这么说过，并希望有人能把它们讲得不那么令人困惑。

我大概会失败，但还是试试看。

太长不看版：常规 IAM 策略既可以让您做某些事，也可以阻止您做某些事。权限边界只能阻止您做某些事。 您主要用它们来允许某人管理一部分 IAM 事务，但又不至于多到让其能够提升权限（为自己或他人）。它们是一种故障保护机制。 如果您允许某人在某个账户中管理 IAM，又不希望其能够提升权限，那么您几乎总是需要一个权限边界！

AWS 官方文档提供了大量细节，但仍然有些令人费解。本文旨在帮助您理解这些概念及其存在的原因，而不是掌握编写它们的所有细节（有一处例外）。

请把我当成五年级学生而不是傻瓜，再解释一遍

好吧，既然您坚持。

在 IAM 权限边界出现之前，要让某人管理自己那部分资源的 IAM 权限，同时又不因为给 EC2 实例之类的对象（或者给他们自己）分配过多权限而制造安全问题，是非常困难的。这个问题主要出现在您希望让他们编写 IAM 策略并进行分配的时候。这正是委派管理的难点所在。“让某人管理与 IAM 相关的某些事务，但不包括另外那些事务”。

这是一种非常常见的场景。开发人员经常会在其应用堆栈中为实例、lambda 函数或容器任务创建一个角色，然后为该角色分配权限。这可能简单到只是让某个实例从 S3 存储桶中读取数据。事实证明，从安全角度看这很难处理：

• 如果您让开发人员自行编写策略，他们可能会添加过多权限……比如 *.*。
• 如果您让开发人员分配策略，他们可能会附加一个权限过多的现有策略。
• 如果您允许开发人员创建新角色并且分配策略……则同样存在上述问题。

当然，您可以让安全团队或高级管理员来处理所有这些事情，但这样效率低下。权限边界让您可以设置两级 IAM 管理员：承担整体安全责任的高级管理员，以及处理日常事务的低级管理员。

权限边界其实就是一个 IAM 策略，用于列出某人或某物可以拥有的最大权限。您附加该策略后，管理该对象的开发人员就永远无法赋予它超出边界所允许范围的权限。之后您甚至可以允许开发人员创建新的角色和用户并为其分配权限，但要求他们创建的任何对象都必须带有该权限边界。这样，他们就永远无法创建或更改任何东西并赋予其超出您意愿的权限。

我不确定这算不算五年级水平，能不能给个例子

Alice 是某个 AWS 组织的超级管理员。她需要监管数百个账户，而每个账户都有自己的本地管理员和真正负责构建应用的开发人员。

Bob 就是其中一名本地开发人员。Bob 正在构建一个新应用，由他自行创建角色和策略效率更高，因为他清楚自己的应用需要什么。

Alice 决定让 Bob 管理其应用部分内容的 IAM。具体而言：

• Bob 可以编写并分配新的 IAM 策略，赋予其实例和 lambda 函数所需的权限。
• 账户中还使用了一些其他 AWS 服务，这些组件绝不应触及它们。因此，您不能简单地用服务控制策略（SCP）把它们关掉，那样会导致本应使用这些服务的组件无法正常工作。
• 不允许 Bob 给自己分配新策略。

这是典型的委派管理场景——Bob 只被允许管理 IAM 中的一部分。 这正是您会用到权限边界的地方：

• Alice 创建一个权限边界“A”，允许访问 Bob 的实例和 lambda 函数可以通信的那些 AWS 服务（例如 S3、SNS、SQS）。
• Alice 创建一个权限边界“B”，允许 Bob 创建 IAM 角色和策略（并进行分配），但不允许他分配给自己。
• Alice 授予 Bob 创建和分配新角色与策略的 IAM 权限，但任何新角色都必须带有“A”权限边界。这意味着那些实例和 lambda 函数永远不会拥有超出该边界的权限，但可以拥有更少的权限。
• Alice 将权限边界“B”分配给 Bob，以防止他给自己分配权限。这样他就无法取消“部署的对象必须带有‘A’”这一要求。

是的，解决这个问题有多种方法……但简而言之，每当您想让某人管理账户中的部分 IAM，而又不希望其权限过大时，您很可能就需要一个权限边界。

再说一遍，为什么服务控制策略在这里行不通

有时 SCP 或许可行，但只有在您身处 Organization 中时才能使用 SCP，而权限边界在任何账户中都适用。此外，SCP 非常适合用于限制可以发起哪些 API 调用（从而限制可以使用哪些 AWS 服务），但它们并不是为这种粒度和条件判断而设计的。

想想我上面的例子——Alice 可能必须知道资源标识符，才能允许访问账户中的服务，但又要排除 Bob 创建的资源。也许有办法处理这种情况（例如资源路径），但那并不比我们的权限边界示例更简单，而且取决于所支持的条件键，未必总能奏效。

在我的事件响应培训靶场中，我使用 SCP 来限制账户中的管理员用户（学员），防止他们破坏我的 Organizations 级访问权限以及其他一些内容。但这之所以可行，是因为我给了他们完整的 IAM 权限，而且他们本身已经是那类超级管理员。如果我想限制他们创建具有过多权限的资源的能力，我就需要一个权限边界，或者用 SCP 限制他们只能分配某些预先制定好的策略。

我不能直接用拒绝策略吗

并不太行。在权限边界出现之前我们试过这种做法，除了复杂之外，漏洞实在太多。

能再给一个简单的例子吗

当然！下面就是我们自己在用的一个例子。

有些用户允许我们在其账户中进行 IAM 变更。为此我们使用跨账户角色。用户部署该角色时，会应用一个权限边界，使我们永远无法更改自身的权限。这可以防止权限提升。

我想我明白了，但这些 IAM 策略之间如何相互作用

请查阅 AWS 关于策略逻辑评估的文档，以下是我的要点笔记：

• 服务控制策略限制任何人在账户中可以执行的操作（例如可以开启和关闭服务）。
• IAM 权限策略允许用户和角色在账户中执行操作。
• IAM 资源策略允许用户和角色与该策略所附加的资源进行交互。
• 权限边界设定用户或角色可以拥有的最大权限。它们不会允许您执行操作，但可以阻止您执行操作。

这些策略共同发挥作用。 要执行某项操作，您必须在这套体系的某处拥有相应的允许权限，并且没有任何地方的拒绝策略阻止您执行该操作。 任何一条 Deny 都会覆盖任何 Allow，无论它位于何处。

再提醒我一次，什么时候使用权限边界

当您想允许某人管理账户中的部分 IAM，但仍要限制其管理范围时，您就应该想到权限边界。

即便您正在使用我们新推出的FireMon Authorization Control这类高级 IAM 工具，您可能仍然需要一些权限边界，在高度敏感的账户中尤其如此。

您说过要提供的那个示例是什么

尽管权限边界的作用是阻止您执行某些操作，但它们仍然要求您指定所有允许的权限。换句话说，如果您编写了一个带有 DENY 语句的权限边界，用以阻止该用户/角色执行某一项操作，您仍然需要一条 ALLOW * 语句，否则他们将无法执行任何操作。

这一点起初让我感到困惑，因为我误读了 Amazon 的说明，以为可以仅用权限边界来阻止操作。确实可以，但除了一种我今天不打算展开的资源策略用例之外，权限边界还必须包含您希望允许的所有内容。您不能只在权限边界中 DENY 某一项操作，而在常规 IAM 权限策略中 ALLOW 其他操作，这样是行不通的。权限边界中同样需要有 ALLOW 语句（是的，我会取巧，有时会在这里直接用 ALLOW *）。

我还是不明白

请给我发一封电子邮件。说真的，这些东西确实令人困惑。