IAM 资源 - AWS 规范性指导

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

IAM 资源

通过进行简短的调查来影响AWS安全参考架构 (AWSSRA) 的未来。

尽管 AWS Identity and Access Management (IAM) 不是一项包含在传统架构图中的服务，但它涉及了 AWS 组织、AWS 账户和 AWS 服务的各个方面。如果不先创建 IAM 实体并授予权限，则无法部署任何 AWS 服务。对 IAM 的完整解释超出了本文档的范围，但本节提供了最佳实践建议的重要摘要以及其他资源指南。

  • 有关 IAM 最佳实践，请参阅 AWS 文档中的 IAM 安全最佳实践、AWS 安全博客上的 IA M 文章以及 AWS re: Invent 演示文稿。

  • AWS Well-Architected 安全支柱概述了权限管理流程中的关键步骤：定义权限护栏、授予最低权限访问权限、分析公共和跨账户访问权限、安全共享资源、持续减少权限以及建立紧急访问流程。

  • 下表及其附注简要概述了有关可用的 IAM 权限策略类型以及如何在安全架构中使用这些策略的推荐指南。要了解更多信息，请观看 AWS re: Invent 2020 视频，了解如何正确选择 IAM 策略组合。

 

用例或政策

效果

由... 管理

目的

属于

影响

部署于

服务控制策略 (SCP)

Restrict

中心团队，例如平台或安全团队 [1]

护栏、治理

组织、组织单位、账户

组织、OU 和账户中的所有负责人

组织管理账户 [2]

基准账户自动化策略（平台用于操作账户的 IAM 角色）

授予和限制

中央团队，例如平台、安全团队或 IAM 团队 [1]

（基准）非工作负载自动化角色的权限 [3]

单一账户 [4]

成员账户中自动化使用的委托人

成员账户

基准人工策略（授予用户执行其工作的权限的 IAM 角色）

授予和限制

中央团队，例如平台、安全团队或 IAM 团队 [1]

人类角色的权限 [5]

单一账户 [4]

联邦委托人 [5] 和 IAM 用户 [6]

成员账户

权限边界（获得授权的开发者可以分配给其他委托人的最大权限）

Restrict

中央团队，例如平台、安全团队或 IAM 团队 [1]

应用程序角色的护栏（必须使用）

单一账户 [4]

此账户中应用程序或工作负载的个人角色 [7]

成员账户

应用程序的计算机角色策略（角色附加到开发人员部署的基础架构）

授予和限制

委托给开发者 [8]

应用程序或工作负载的权限 [9]

单一账户

此账户中的本金

成员账户

资源策略

授予和限制

委托给开发者 [8,10]

资源权限

单一账户

账户中的本金 [11]

成员账户

  

表中的注释：

  1. 企业有许多集中式团队（例如云平台、安全运营或身份和访问管理团队），他们分担这些独立控制的责任，并对彼此的政策进行同行审查。表中的示例是占位符。你需要为你的企业确定最有效的职责分工。

  2. 要使用 SCP，您必须启用 AWS Organizations 中的所有功能。

  3. 通常需要常用的基准角色和策略来实现自动化，例如管道权限、部署工具、监控工具（例如 AWS Lambda 和 AWS Config 规则）以及其他权限。此配置通常在配置账户时交付。

  4. 尽管它们与单个账户中的资源（例如角色或策略）有关，但可以使用 AWS CloudFormation StackSets 将其复制或部署到多个账户。

  5. 定义一组核心的基准人类角色和策略，这些角色和策略由中央团队部署到所有成员账户（通常是在账户配置期间）。示例包括平台团队中的开发人员、IAM 团队和安全审计团队。

  6. 尽可能使用联合身份验证（而不是本地 IAM 用户）。

  7. 权限边界由授权的管理员使用。此 IAM 策略定义了最大权限并覆盖了其他策略（包括允许对资源进行所有操作的“*:*”策略）。在基准人工策略中应规定权限边界，以此作为创建角色（例如工作负载性能角色）和附加策略的条件。诸如 SCP 之类的其他配置会强制附加权限边界。

  8. 这假设已经部署了足够的护栏（例如 SCP 和权限边界）。

  9. 这些可选策略可以在账户配置期间交付，也可以作为应用程序开发过程的一部分交付。创建和附加这些策略的权限将由应用程序开发者自己的权限控制。

  10. 除了本地账户权限外，集中式团队（例如云平台团队或安全运营团队）通常还会管理一些基于资源的策略，以启用跨账户访问权限来操作账户（例如，提供对 S3 存储桶的访问权限以进行日志记录）。

  11. 基于资源的 IAM 策略可以引用任何账户中的任何委托人来允许或拒绝对其资源的访问。它甚至可以引用匿名委托人来启用公共访问权限。

 确保 IAM 身份仅拥有一组精心划分的任务所必需的权限，对于降低恶意或无意滥用权限的风险至关重要。建立和维护最低权限模型需要制定周密的计划，以持续更新、评估和缓解超额特权。以下是该计划的一些其他建议：

  • 使用贵组织的治理模式和既定的风险偏好来建立特定的防护和权限边界。

  • 通过不断迭代的过程实现最低权限。这不是一次性的练习。

  • 使用 SCP 降低可操作的风险。这些措施旨在成为宽阔的护栏，而不是针对性狭窄的控制措施。

  • 使用权限边界以更安全的方式委派 IAM 管理。

    • 确保委派的管理员将相应的 IAM 边界策略附加到他们创建的角色和用户。

  • 作为一种 defense-in-depth 方法（与基于身份的策略结合使用），使用基于资源的 IAM 策略来拒绝对资源的广泛访问。

  • 使用 IAM 访问顾问、AWS CloudTrail、AWS IAM Access Analyzer 和相关工具定期分析历史使用情况和授予的权限。立即纠正明显的过度权限。

  • 在适用的情况下，将广泛的操作范围限定为特定资源，而不是使用星号作为通配符来表示所有资源。

  • 实施一种机制，根据请求快速识别、审查和批准 IAM 策略异常。