在规模上实现最小权限的策略 第二部分

作者：Joshua Du Lac 和 Emeka Enekwizu于2024年7月9日发布于 AWS IAM Access Analyzer，AWS 身份与访问管理 (IAM)，AWS 组织，最佳实践，中级 (200)，管理与治理，安全、身份与合规永久链接 评论区 分享

关键要点

在本篇文章中，我们将继续探讨如何利用 AWS 身份与访问管理 (IAM) 在规模上实现最小权限的策略。在本文的第一部分，我们讨论了九种实施 IAM 最小权限的策略中的前五种，并介绍了几种可以帮助您扩大方法的思维模型。本篇的第二部分将继续探讨剩余的四种策略以及与之相关的思维模型，以便在组织中实现最小权限的扩展。

6 授权开发者编写应用策略

如果你是唯一在云环境中工作的开发者，那么你自然会编写自己的 IAM 策略。然而，我们观察到，许多正在扩大云使用的组织中，通常会有一个集中式的安全、身份或云团队管理员，协助开发者为开发团队撰写定制的 IAM 策略。出现这种现象的原因多种多样，可能是因为对策略语言的不熟悉，或是因担心授予过多权限而导致的安全风险。虽然集中式创建 IAM 策略在一段时间内可能有效，但随着团队或业务的增长，这种做法往往会成为瓶颈，如图1所示。

这种思维模型被称为限制理论。有了这个模型，你应该积极寻找团队或组织面临的瓶颈，找出根源，并解决这些限制。这听起来可能很明显，但在快速发展过程中，瓶颈可能在机动性受到损害之前就不会显现。随着组织的成长，过去有效的流程在今天可能已经不再适用。

软件开发者一般了解他们构建应用的意图，且在一定程度上理解所需的权限。同时，集中式的云、身份或安全团队则往往自认为在安全地撰写策略方面是专家，但对于应用程序的代码缺乏深入了解。其目标是使开发者能够编写策略，以减轻瓶颈问题。

问题是，如何为开发者提供必要的工具和技能，以便他们自信、安全地为其应用创建所需的策略？开始的简单方法是投资于培训。AWS 提供了多种 正式培训选项 和 渐进指南，可以帮助你的团队更深入理解 AWS 服务，包括 IAM。然而，即使是自行为组织主办小型黑客马拉松或工作坊会议，也能驱动更好的成果。考虑以下四种工作坊，作为与团队进行自我学习系列的简单选择。

如何使用不同 IAM 策略类型的工作坊 学习何时使用哪种策略类型，谁应该拥有和管理该策略。IAM 策略学习体验工作坊 学习如何编写不同类型的 IAM 策略，并对主体和资源实施访问控制，使用条件来缩小访问范围。IAM 故障排除工作坊 学习如何借助 IAM API、AWS 管理控制台、IAM 访问分析器和 AWS CloudTrail 创建精细粒度的访问策略，回顾 IAM 策略评估逻辑的关键概念。像专业人士一样精细化 IAM 权限 学习如何以编程方式使用 IAM 访问分析器，使用工具检查 CI/CD 流水线和 AWS Lambda 函数中的 IAM 策略，获得安全和 DevOps 团队视角上的实践经验。

接下来，你可以通过建立促进协作和提升质量的流程来帮助团队。例如，强烈建议进行同行评审，我们将在后文中讨论。此外，管理员可以使用 AWS 本地工具如权限边界和IAM 访问分析器策略生成来帮助开发者更安全地开始编写他们自己的策略。

首先，让我们看看权限边界。IAM 权限边界 应该通常用于将政策创建责任委托给开发团队。你可以设置开发者的 IAM 角色，使其只能在特定权限边界附加的情况下创建新角色，该权限边界允许你作为管理员设定开发者可以授予的最大权限。这一限制通过开发者身份基础策略中的条件得以实施，要求特定动作如 iamCreateRole 或 iamCreatePolicy仅在附加了指定权限边界时才被允许。

这样，当开发者创建一个 IAM 角色或策略以授予应用程序所需权限时，必须添加指定的权限边界来“约束”该应用程序可用的最大权限。因此，即使开发者创建的策略例如针对其 AWS Lambda 函数 的策略并不够细化，权限边界也能帮助组织的云管理员确保 Lambda 函数的策略不大于设定的最大预定义权限。因此，凭借权限边界，开发团队可以在有约束的情况下创建新角色和策略，而无需管理员创建人工瓶颈。

此外，开发者还可以使用 IAM 访问分析器策略生成。IAM 访问分析器审核你的 CloudTrail 日志，并根据你在特定时间范围内的访问活动自动生成 IAM 策略。这大大简化了编写细粒度 IAM 策略的过程，从而允许最终用户访问 AWS 服务。

IAM 访问分析器策略生成的经典用例是在线上测试环境中生成 IAM 策略。这为帮助识别所需权限并进一步调整你的生产环境策略提供了良好的起点。例如，IAM 访问分析器无法识别所使用的生产资源，因此它为你添加了资源占位符，以便你修改和添加应用团队所需的具体 亚马逊资源名称 (ARN)。然而，并非每个策略都需要定制，接下来的策略将专注于重用一些策略。

7 维护书写良好的策略

第七和第八个策略聚焦于流程。我们要关注的第一个流程是维护书写良好的策略。首先，并非每个策略都需要是艺术作品。在你的帐户间重用书写良好的策略是明智的，因为这是一种有效的扩展权限管理的方法。处理此任务的方法有三个步骤：

确定使用案例创建策略模板维护策略模板库

例如，如果你刚开始使用 AWS 和一个新账户，我们建议使用 AWS 管理的策略 作为参考开始。然而，随着时间的推移，这些策略中的权限可能并不适合你打算使用云的方式。最终，你会希望在自己的账户中识别出重复或常见的使用案例，并为这些情况创建通用策略或模板。

在创建模板时，你必须了解这个模板是为谁或什么服务。必须注意的是，开发者的需求往往与应用程序的需求不同。当开发者在你的账户中处理资源时，他们往往需要创建或删除资源。例如，创建和删除 亚马逊简单存储服务 (Amazon S3) 的存储桶，以供应用程序使用。

相对而言，软件应用一般需要读取或写入数据在这个例子中，是读取和写入开发者创建的 S3 存储桶中的对象。注意，开发者的权限需求创建存储桶与应用程序的需求读取存储桶中的对象是不同的。由于这些是不同的访问模式，你需要创建针对不同用例和实体设计的不同策略模板。

图2进一步强调了这个问题。在所有可能的 AWS 服务和 API 操作集中，有一组权限与开发者或更可能是他们的 DevOps 构建和交付工具相关，还有一组权限与他们正在构建的软件应用程序相关。尽管这两组可能有一些重叠，但并不完全相同。

在讨论策略重用时，你可能已经在考虑你账户中的常见策略，例如为团队成员提供的默认联合权限或跨多个账户执行例行安全审计的自动化。这些策略的大多数可以被视为在你的账户之间普遍存在且通常不变的 默认策略。同样，权限边界策略我们之前讨论的也可以在不同账户之间具有共同点，变动较少。重用这两类策略都具有价值。然而，过于广泛地重用策略可能会导致在需要变更的情况下产生挑战要更改“可重用策略”，你必须修改该策略的每个实例，即使仅在一个应用程序中需要这样做。

你可能会发现，你有相对常见的资源策略，多个团队需要例如 S3 存储桶政策，但存在细微差异。在这种情况下，你可能会发现创建一个符合组织安全政策的可重复模板并让你的团队复用是有用的。我们在这里称之为 模板，因为团队可能需要更改一些元素，例如他们授权访问资源的主体。应用程序的策略如开发者创建的附加到 亚马逊弹性计算云 (Amazon EC2) 实例角色的策略通常更具定制性，可能不适合做成模板。

图3说明了某些策略的变动量少，而其他策略则更为定制化。

一元机场的官方网站

无论你选择重用一个策略还是将其转化为模板，重要的一步是将这些可重用策略和模板安全地存储在一个库中此案例中为 AWS CodeCommit。许多客户使用 基础设施即代码 模块，使开发团队能够轻松输入自定义内容并以编程方式生成符合他们安全政策的 IAM 策略。有些客户将这些策略和模板直接记录在库中，而其他人则使用内部维基与其他相关信息相结合。你需要决定哪种流程最适合你的组织。无论采用何种机制，都要确保团队能够访问并进行搜索。

8 进行同行评审和验证策略

我们在 第一部分中提到，最小权限是一个旅程，而反馈循环是关键的一部分。你可以通过人工审查来实施反馈，或通过自动化审核和验证发现来实现。这对核心的默认策略和定制的专用策略同样重要。

我们先来看看一些可以使用的自动化工具。我们推荐的一个好工具是使用 AWS IAM 访问分析器政策验证 和 自定义政策检查。政策验证在你撰写政策时帮助你设定安全和功能性的策略。该功能可以通过 API 和 AWS 管理控制台访问。IAM 访问分析器会对你的策略进行 IAM 策略语法 和 AWS 最佳实践 的验证。你可以查看政策验证检查结果，包括安全警告、错误、一般警告和对你的政策的建议。

让我们看一下几个发现类别。

发现类型描述安全性包括警告，指出如果你的策略允许 AWS 认为的安全风险的访问，因为该访问过于宽松。错误包括错误，如果你的策略包含阻止政策正常运行的行。警告包括警告，如果你的政策不符合最佳实践，但问题并不构成安全风险。建议如果 AWS 建议的改进不影响政策权限，则包括建议。

自定义政策检查是 IAM 访问分析器的一项新功能，它帮助安全团队准确和主动识别策略中的关键权限。你可以使用此功能检查与参考策略即，确定更新的策略是否比现有版本授予了新访问权限或与 IAM 操作列表核对即，验证你的政策是否未允许特定的 IAM 操作。自定义政策检查使用 自动推理，这是一种静态分析，能够在云中提供更高水平的安全保证。

一个可以帮助你进行同行评审和自动化的技巧是使用 基础设施即代码。这意味着你可以将 IAM 策略编写并部署为 AWS CloudFormation 模板 (CFTs) 或 AWS Cloud Development Kit (AWS CDK) 应用程序。你可以使用软件版本控制系统管理模板，这样你就可以清楚地知道做了哪些更改，然后测试并跨多个账户部署你的默认策略，例如通过使用 AWS CloudFormation StackSets。

在图4中，你将看到一个典型的开发工作流。这是一个简化版本的 CI/CD 流水线，包括三个阶段：提交阶段、验证阶段和部署阶段。图中的开发者代码包括 IAM 策略会经过多个步骤的检查。

在提交阶段，如果你的开发者正在撰写策略，你可以在他们提交源代码时快速进行同行评审，从而在团队内创造一定的责任感，以便撰写最小权限策略。此外，你可以通过在验证阶段引入 IAM 访问分析器政策验证来使用自动化，以便工作只有在没有检测到安全问题时才能继续。要了解更多关于如何在你的账户中部署此架构的信息，请参见 这篇博客文章。如果希望了解该过程的 Terraform 版本，请访问 这个 GitHub 存储库。

9 随时间推移移除多余权限

我们的最后一个策略专注于现有权限，以及如何随着时间推移去除多余权限。你可以通过分析哪些权限被授予，确定哪些是使用中的，哪些是未使用的，从而判断哪些权限是过多的。即使你正在开发新的策略，后来可能会发现