SEC03-BP05 为您的组织定义权限防护机制 - 安全支柱
实施指导资源

SEC03-BP05 为您的组织定义权限防护机制

使用权限防护机制来减少可向主体授予的可用权限的范围。权限策略评估链包括您的防护机制，用于在做出授权决策时确定主体的有效权限。 您可以使用基于层的方法定义防护机制。在整个企业内广泛地应用一些防护机制，而对临时访问会话则以细粒度方式应用另一些防护机制。

期望结果：您可以使用单独的 AWS 账户对环境进行明确隔离。  使用服务控制策略（SCP）定义整个企业内的权限防护机制。在更靠近组织根级别的层次结构上设置较为广泛的防护机制，而在更靠近单独账户的级别上设置更严格的防护机制。

在支持资源策略的情况下，使用资源策略定义主体获得资源访问权限必须满足的条件。在适用的情况下，还应使用资源策略缩小允许操作的范围。在管理工作负载权限的主体上设定了权限边界，将权限管理委托给单独的工作负载负责人。

常见反模式：

  • 在 AWS 组织内创建成员 AWS 账户，但不使用 SCP 来限制其根凭证的使用和可用权限。

  • 根据最低权限原则分配了权限，但没有对可以授予的最大权限集施加防护机制。

  • 依靠 AWS IAM 的隐式拒绝基础来限制权限，相信策略不会授予非预期的显式允许权限。

  • 在同一个 AWS 账户中运行多个工作负载环境，然后依靠 VPC、标签或资源策略等机制来强制实施权限边界。

建立此最佳实践的好处：权限防护机制有助于建立人们对无法授予不需要的权限的信心，即使权限策略尝试这样做也是如此。 这样便可以减少需要考虑的最大权限范围，从而简化权限的定义和管理。

在未建立这种最佳实践的情况下暴露的风险等级：中

实施指导

我们建议您使用基于层的方法，为企业定义权限防护机制。在应用了额外的层时，这种方法可以系统性地减少可能的最大权限集。利用这种方法，您可以根据最低权限原则授予访问权限，从而减少由于策略配置错误而导致意外访问的风险。

建立权限防护机制的第一步是将您的工作负载和环境隔离到单独的 AWS 账户中。如果没有显式权限，一个账户的主体无法访问另一个账户中的资源，即使两个账户位于同一 AWS 组织或在同一组织单位（OU）下也是如此。您可以使用 OU 将要管理的账户分组为一个单位。  

接下来，您需要减少可向企业成员账户中的主体授予的最大权限集。为此，您可以使用服务控制策略（SCP），您可以将其应用于 OU 或账户。SCP 可以强制执行常见的访问控制措施，例如限制对特定 AWS 区域的访问，防止资源被删除，或者禁用存在潜在风险的服务操作。您应用到组织根的 SCP 仅影响其成员账户，不影响管理账户。 SCP 仅管理企业中的主体。您的 SCP 不管理企业外部访问您资源的主体。

如果您使用的是 AWS Control Tower，则可以利用其 controls 和 landing zones 作为权限护栏和多账户环境的基础。登录区提供了一个预先配置的安全基线环境，为不同的工作负载和应用程序提供了单独的账户。这些护栏通过结合使用服务控制策略（SCP）、AWS Config 规则和其它配置，围绕安全性、运营和合规性实施强制性控制措施。但是，在使用 Control Tower 护栏和登录区以及自定义组织 SCP 时，请遵循 AWS 文档中概述的最佳实践来避免冲突并确保适当的治理，这一点至关重要。有关在 Control Tower 环境中管理 SCP、账户和组织单位（OU）的详细建议，请参阅 AWS Control Tower guidance for AWS Organizations。

通过遵守这些准则，可以有效地利用 Control Tower 的护栏、登录区和自定义 SCP，同时缓解潜在冲突并确保对多账户 AWS 环境进行适当的治理和控制。

下一步是使用 IAM 资源策略来限定您可以对其所管理的资源采取的可用操作的范围，以及代理主体必须满足的任何条件。这一点可以很宽泛，只要主体是您的组织的一部分，就可以允许执行所有操作（使用 PrincipalOrgId 条件键），也可以精细到仅允许特定 IAM 角色执行特定操作。对于 IAM 角色信任策略中的条件，您可以采用类似的方法。 如果资源或角色信任策略在所管理的角色或资源的同一个账户中，明确指定了主体，则该主体不需要附加授予相同权限的 IAM 策略。 如果主体与资源位于不同的账户中，则主体就需要附加 IAM 策略来授予这些权限。

通常，工作负载团队需要管理其工作负载所需的权限。 这可能要求团队创建新的 IAM 角色和权限策略。 您可以在 IAM 权限边界内获取允许团队授予的最大权限范围，并将此文档关联到一个 IAM 角色，然后团队可以使用该角色来管理其 IAM 角色和权限。 通过这种方法，团队能够灵活地完成其工作，同时降低拥有 IAM 管理访问权限的风险。

更精细的步骤是实施特权访问管理（PAM）和临时提升的访问权限管理（TEAM）技术。 PAM 的一个例子是要求主体在采取特权操作之前进行多重身份验证。 有关更多信息，请参阅《配置受 MFA 保护的 API 访问》。TEAM 需要一种解决方案，来管理主体在获得提升访问权限时需经过的审批，以及允许获得提升访问权限的时间范围。 一种方法是将主体临时添加到具有更高访问权限的 IAM 角色的角色信任策略中。 另一种方法是，在正常运行情况下，使用会话策略缩小 IAM 角色向主体授予的权限范围，然后在批准的时段内暂时取消此限制。要了解有关 AWS 和精选合作伙伴验证的解决方案的更多信息，请参阅《临时提升访问权限》。

实施步骤

  1. 将您的工作负载和环境存放在单独的 AWS 账户中。

  2. 使用 SCP 来减少可向企业成员账户中的主体授予的最大权限集。

    1. 在定义 SCP 来减少可向组织成员账户中的主体授予的最大权限集时，您可以选择允许列表 或拒绝列表 方法。允许列表策略显式指定允许的访问权限，并隐式阻止所有其它访问权限。拒绝列表策略显式指定不允许的访问权限，并且默认情况下允许所有其它访问权限。这两种策略都有其优势和权衡，适当的选择取决于您组织的具体要求和风险模型。有关更多详细信息，请参阅 Strategy for using SCPs。

    2. 此外，请查看 service control policy examples，来了解如何有效地构造 SCP。

  3. 使用 IAM 资源策略缩小范围，并指定允许对资源执行操作的条件。 使用 IAM 角色信任策略中的条件来创建对代入角色的限制。

  4. 将 IAM 权限边界分配给 IAM 角色，然后工作负载团队可以使用该角色来管理自己的工作负载的 IAM 角色和权限。

  5. 根据您的需求评估 PAM 和 TEAM 解决方案。

资源

相关文档：

相关示例：

相关工具：