# SEC03-BP05 为您的组织定义权限防护机制
<a name="sec_permissions_define_guardrails"></a>

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

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

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

 **常见反模式：**
+  在 [AWS 组织](https://aws.amazon.com/organizations/)内创建成员 AWS 账户，但不使用 SCP 来限制其根凭证的使用和可用权限。
+  根据最低权限原则分配了权限，但没有对可以授予的最大权限集施加防护机制。
+  依靠 AWS IAM 的*隐式拒绝*基础来限制权限，相信策略不会授予非预期的*显式允许*权限。
+  在同一个 AWS 账户中运行多个工作负载环境，然后依靠 VPC、标签或资源策略等机制来强制实施权限边界。

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

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

## 实施指导
<a name="implementation-guidance"></a>

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

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

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

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

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

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

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

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

### 实施步骤
<a name="implementation-steps"></a>

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

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

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

   1.  此外，请查看 [service control policy examples](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html)，来了解如何有效地构造 SCP。

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

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

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

## 资源
<a name="resources"></a>

 **相关文档：**
+  [ 上的数据边界AWS](https://aws.amazon.com/identity/data-perimeters-on-aws/) 
+  [使用数据边界建立权限防护机制](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_data-perimeters.html) 
+  [策略评估逻辑](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) 

 **相关示例：**
+  [服务控制策略示例](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html) 

 **相关工具：**
+  [AWS 解决方案：临时提升的访问权限管理](https://aws-samples.github.io/iam-identity-center-team/) 
+  [经过验证的 TEAM 安全合作伙伴解决方案](https://docs.aws.amazon.com/singlesignon/latest/userguide/temporary-elevated-access.html#validatedpartners)