在规模上实现最小权限的策略

实现最小权限的策略 第1部分

通过 Joshua Du Lac 和 Emeka Enekwizu 于 2024年7月9日发布在 AWS IAM 访问分析器、AWS 身份和访问管理 (IAM)、AWS 组织、最佳实践、中级 (200)、管理与治理、安全、身份和合规性永久链接评论 分享

关键要点

最小权限是 Amazon Web Services (AWS) 客户关注的重要安全主题。在之前的博客中，我们曾提供有关如何撰写最小权限策略的战术建议，建议您复习相应内容。也许您能为自己撰写一些最小权限策略，但要将其扩展到数千名开发者或数百个 AWS 账户，便需要策略来最小化在整个组织中所需的总工作量。

在 reInforce 2022 上，我们推荐了实现最小权限的九个策略。虽然我们推荐的策略保持不变，但这一系列博客作为更新，深入讨论了一些策略。在此系列中，我们仅关注 AWS 身份和访问管理 (IAM)，而不涉及应用或基础设施身份。在接下来的讨论中，我们将回顾 AWS 中的最小权限，然后深入探讨九个策略，并最终总结一些关键要点。本文第 1 部分涵盖了前五个策略，而 第 2 部分 将讨论剩余的四个策略。

最小权限概述

最小权限原则指的是应当授予用户和系统执行所需任务所需的最小权限集。这是理想情况，但在不断变化的环境中，实现起来并不简单您的员工或用户在变化，系统在变化，新技术也在不断涌现。AWS 不断添加新服务或功能，团队中的个人可能希望采用它们。如果分配给这些用户的策略完全符合最小权限，那么您将在用户请求更改访问权限时不断更新权限。对许多人来说，施加最小权限的策略可能会显得过于严格。讽刺的是，完美的最小权限可能意味着最大化的工作量。

我们希望找到一种更务实的方法。首先，您应认识到存在着两种相互竞争的目标之间的紧张关系您“不希望的事情”和您“希望的事情”，如下图所示。例如，您不希望创建昂贵的资源，但希望为开发者提供自由选择资源的权力。

在考虑最小权限时，竞争目标之间会产生自然的紧张关系，您可以调整若干控制措施，以安全地实现灵活性。我与数百位客户探讨过这一主题，许多人主要集中在撰写几乎完美的权限策略上，试图强行实现最小权限。然而，这种方法并不十分有效。那么，我们应该从哪里开始呢？为此，我们将把这个问题拆解为三个组成部分：策略、工具和心理模型。前两者或许对您来说比较清晰，但您可能会想：“什么是心理模型？”心理模型帮助我们将复杂的事物概念化为相对简单的形式，尽管这自然会忽略一些信息。

团队

团队通常根据组织的规模而有所不同。我们认识到每个客户都是独特的，客户需求在不同企业、政府机构、初创公司等之间各不相同。如果您觉得以下示例描述目前不适用于您，或者您的组织还不足以实现太多团队的共存，请记住，随着您组织的持续发展，这些场景在未来可能更具适用性。在考虑最小权限之前，让我们先讨论一些常见场景。

在云计算中操作的客户往往将团队划分为两种类型：去中心化和集中化。去中心化团队可以是开发者或开发组、运维人员或在您的云环境中工作的承包商。集中化团队通常由管理员组成，包括云环境团队、基础设施团队、安全团队、网络团队或身份团队。

场景

为了有效地在组织中实现最小权限，团队之间必须协作。让我们考虑三个常见场景：

第一个场景关注的是开始使用 AWS 所需的基础角色和权限集。集中化团队例如云环境团队或身份与访问管理团队通常会创建这些初始的默认角色和政策，您可以通过账户工厂、IAM 身份中心或 AWS 控制塔 部署它们。这些默认权限通常启用开发者的联合，或者启用一些自动化，例如监控或部署工具。

第二个场景是为应用创建角色和政策。在基础访问和权限建立之后，您的开发者需要利用云计算来构建。去中心化团队软件开发者、运维人员或承包商利用第一个场景中的角色和政策，创建系统、软件或需要自身权限的应用，以执行有用的功能。这些团队通常需要为其软件创建新的角色和政策，以便与数据库、Amazon 简单存储服务 (Amazon S3)、Amazon 简单队列服务 (Amazon SQS) 队列及其他资源进行交互。

最后，第三个场景是验证和完善现有权限，这一任务应由两组团队负责。

旅程

在 AWS，我们常说最小权限是一个旅程，因为变化是常态。您的开发者可能会变化，系统可能会变化，您可能会更换使用的服务，而使用的服务可能会增加新的功能，您的团队想要采用以实现更快或更高效的工作方式。因此，您现在考虑的最小权限在未来可能会被您的用户认为不足。

这一旅程由设置、验证和完善权限的生命周期构成。云管理员和开发者会 设置 权限，然后 验证 权限，最后随时间 完善 权限，这一循环如图 2 所示。这会产生反馈循环的持续改进，从而成为实现最小权限的旅程。

实施最小权限的策略

接下来的部分将深入探讨实施最小权限的九个策略：

第1部分本文：

第2部分

为提供一些逻辑结构，策略可以分为三个类别计划、政策和流程。计划 是您考虑目标和想要实现的结果的地方，然后设计您的云环境以简化这些结果。政策 专注于您将需要在 IAM 策略语言 中或以代码形式例如 基础设施即代码实现其中一些目标。流程 类别将考察持续改进的迭代方法。让我们开始。

1 从粗粒度控制开始

大多数系统都有关系，这些关系可以进行可视化。例如，AWS 账户的关系可以被可视化为一个层级结构，包含一个组织的管理账户和在该层级内的一组 AWS 账户，以及这些账户内的主体和政策，如图 3 所示。

在讨论最小权限时，容易过度关注层级底部的政策，但如果您希望在规模上实施最小权限，您应当反转这一思维。相反，这一策略关注粗粒度控制，指的是一组顶层的、较宽范围的控制措施。这些广泛的控制措施的示例包括 多账户策略、服务控制政策、阻止公共访问、以及 数据边界。

在您实施粗粒度控制之前，必须考虑哪些控制能实现您想要的结果。在相关的粗粒度控制到位后，您可以在层级下调整权限，通过更细粒度的控制措施逐步优化。下一个策略将回顾我们推荐的第一个粗粒度控制。

2 将账户作为资源的强边界

虽然您可以从一个 AWS 账户开始，但我们鼓励客户采取多账户策略。随着客户继续使用云，通常需要明确的安全边界、控制限制的能力，以及账单分离所需的功能。AWS 账户内部建构的隔离可以帮助您满足这些需求。

客户可以通过 AWS 组织 将单独的账户分组为不同的组合组织单位。一些客户可能会选择按环境进行对齐，如开发、预生产、测试、生产，或者根据业务单元、成本中心或其他选项进行分组。您可以选择如何构建您的组织，AWS 提供了参考指导，以帮助客户在采用 多账户策略 时。

同样，您可以使用这种方法对安全控制进行分组。当您分层实施预防性或侦测性控制时，可以选择将其应用于哪些账户组。在思考如何分组这些账户时，请考虑您希望在何处应用可能影响权限的安全控制。

AWS账户为账户之间以及存在于这些账户中实体之间提供了强边界。如图 4 所示，默认情况下，这些主体和资源无法跨越它们的账户边界由左侧的红色虚线表示。

为了使这些账户相互通信，您需要通过添加细粒度的权限显式启用访问权限。对于跨账户资源共享、跨 VPC 网络或跨账户角色假设等用例，您需要显式启用所需的访问权限，通过创建必要的权限。然后，您可以通过使用 IAM 访问分析器 对这些权限进行审查。

其中 IAM 访问分析器中的一种分析器， 外部访问，帮助您识别组织内或账户中的共享资源例如 S3 桶、IAM 角色、SQS 队列等 更多内容，与外部实体共享。这有助于您识别是否存在可能对您组织造成安全风险的意外访问。虽然您可以在单个账户中使用 IAM 访问分析器外部访问，但我们建议在组织层面使用。您可以通过将组织设置为受信区来配置整个组织的访问分析器，以识别来自组织外部的访问。

要开始，您可以 创建分析器，并开始分析权限。分析可能会产生 发现，您可以对预期和意外访问权限进行审查。您可以 归档 预期访问发现，但您需要迅速采取行动以减少与意外访问相关的安全风险。

总之，您应将账户作为资源的强边界，并利用 IAM 访问分析器帮助验证您的假设，自动化发现账户边界中的意外访问权限。

3 优先采用短期凭证

在访问控制方面， 短期凭证更佳。与可能以明文形式存储或不小心共享的长期访问密钥或密码相比，短期凭证由强身份动态请求。由于这些凭证是动态请求的，因此它们是临时的并且会自动过期。因此，您不必显式撤消或轮换凭证，也无需将其嵌入到应用程序中。

在 IAM 的背景下，当我们讨论短期凭证时，我们实际上指的是 IAM 角色。我们可以将适用的短期凭证用例分为两类开发者的短期凭证和应用的短期凭证。

开发者人类用户通常通过两种方式与 AWS 云交互；通过 AWS 管理控制台或通过 AWS CLI 进行编程访问。对于控制台访问，您可以通过身份提供者直接联合至各个 AWS 账户，或通过 IAM 身份中心更为集中化的方式进行访问。对于编程访问，您可以通过 [使用 AWS CLI 的 IAM 身份中心](https