本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
IAM 资源
| 通过进行简短的调查 |
尽管 AWS Identity and Access Management (IAM) 不是传统架构图中包含的服务，但它涉及 AWS 组织的方方面面 AWS 账户、和 AWS 服务。如果不先创建 IAM 实体并授予权限，则无法部署任何 AWS 服务 实体。对 IAM 的完整解释超出了本文档的范围，但本节提供了最佳实践建议的重要摘要以及其他资源指南。
-
有关 IAM 最佳实践，请参阅 AWS 文档中的 IAM 安全最佳实践、 AWS 安全博客中的 IAM 文章
以及 re AWS : Invent 演示 文稿。 -
W AWS ell-Architected 安全支柱概述了权限管理流程中的关键步骤：定义权限护栏、授予最低权限访问权限、分析公共和跨账户访问权限、安全共享资源、持续减少权限以及建立紧急访问流程。
-
下表及其附注简要概述了有关可用的 IAM 权限策略类型以及如何在安全架构中使用这些策略的推荐指南。要了解更多信息，请参阅 re AWS : Invent 2020 视频，了解如何正确选择 IAM 策略组合。
用例或政策 |
效果 |
由... 管理 |
目的 |
与以下内容有关 |
影响 |
部署于 |
服务控制策略 (SCPs) |
Restrict |
中心团队，例如平台或安全团队 [1] |
护栏、治理 |
组织、组织单位、账户 |
组织、OU 和账户中的所有负责人 |
组织管理账户 [2] |
资源控制策略 (RCPs) |
Restrict |
中心团队，例如平台或安全团队 [1] |
护栏、治理 |
组织、组织单位、账户 |
成员账号中的资源 [12] |
组织管理账户 [2] |
基准账户自动化策略（平台用于操作账户的 IAM 角色） |
授予和限制 |
中央团队，例如平台、安全团队或 IAM 团队 [1] |
（基准）非工作负载自动化角色的权限 [3] |
单一账户 [4] |
成员账户中自动化使用的委托人 |
成员账户 |
基准人工策略（授予用户执行其工作的权限的 IAM 角色） |
授予和限制 |
中央团队，例如平台、安全团队或 IAM 团队 [1] |
人类角色的权限 [5] |
单一账户 [4] |
联邦委托人 [5] 和 IAM 用户 [6] |
成员账户 |
权限边界（获得授权的开发者可以分配给其他委托人的最大权限） |
Restrict |
中央团队，例如平台、安全团队或 IAM 团队 [1] |
应用程序角色的护栏（必须使用） |
单一账户 [4] |
此账户中应用程序或工作负载的个人角色 [7] |
成员账户 |
应用程序的计算机角色策略（角色附加到开发人员部署的基础架构） |
授予和限制 |
委托给开发者 [8] |
应用程序或工作负载的权限 [9] |
单一账户 |
此账户中的本金 |
成员账户 |
资源策略 |
授予和限制 |
委托给开发者 [8,10] |
资源权限 |
单一账户 |
账户中的本金 [11] |
成员账户 |
中央根用户管理 |
授予和限制 |
中央团队，例如平台、安全团队或 IAM 团队 [1] |
大规模集中管理成员账户 root 用户 |
Organization（组织） |
成员账户中的所有 root 用户 |
组织管理账号、委派管理员账号 |
表中的注释：
-
企业有许多集中式团队（例如云平台、安全运营或身份和访问管理团队），他们分担这些独立控制的责任，并对彼此的政策进行同行审查。表中的示例是占位符。你需要为你的企业确定最有效的职责分工。
-
要使用 SCPs，必须启用其中的所有功能 AWS Organizations。
-
通常需要常用的基准角色和策略来实现自动化，例如管道权限、部署工具、监控工具（例如 AWS Lambda 和 AWS Config 规则）以及其他权限。此配置通常在配置账户时交付。
-
尽管它们与单个账户中的资源（例如角色或策略）有关，但可以通过使用AWS CloudFormation StackSets将其复制或部署到多个账户。
-
定义一组核心的基准人类角色和策略，这些角色和策略由中央团队部署到所有成员账户（通常是在账户配置期间）。示例包括平台团队中的开发人员、IAM 团队和安全审计团队。
-
尽可能使用联合身份验证（而不是本地 IAM 用户）。
-
权限边界由授权的管理员使用。此 IAM 策略定义了最大权限并覆盖了其他策略（包括允许对资源进行所有操作的
"*:*"策略）。在基准人工策略中应规定权限边界，以此作为创建角色（例如工作负载性能角色）和附加策略的条件。其他配置，例如 SCPs 强制附加权限边界。 -
这假设已经部署了足够的护栏（例如， SCPs 和权限边界）。
-
这些可选策略可以在账户配置期间交付，也可以作为应用程序开发过程的一部分交付。创建和附加这些策略的权限将由应用程序开发者自己的权限控制。
-
除了本地账户权限外，集中式团队（例如云平台团队或安全运营团队）通常还会管理一些基于资源的策略，以启用跨账户访问权限来操作账户（例如，提供对 S3 存储桶的访问权限以进行日志记录）。
-
基于资源的 IAM 策略可以引用任何账户中的任何委托人来允许或拒绝对其资源的访问。它甚至可以引用匿名委托人来启用公共访问权限。
-
RCPs 适用于其子集的资源 AWS 服务。有关更多信息，请参阅 AWS Organizations 文档 RCPs中的支持列表。 AWS 服务
确保 IAM 身份仅拥有一组精心划分的任务所必需的权限，对于降低恶意或无意滥用权限的风险至关重要。建立和维护最低权限模型需要制定周密的计划，以持续更新、评估和缓解超额特权。以下是该计划的一些其他建议：
-
使用贵组织的治理模式和既定的风险偏好来建立特定的防护和权限边界。
-
通过不断迭代的过程实现最低权限。这不是一次性的练习。
-
用于降低 SCPs 可操作的风险。这些措施旨在成为宽阔的护栏，而不是针对性狭窄的控制措施。
-
使用权限边界以更安全的方式委派 IAM 管理。
-
确保委派的管理员将相应的 IAM 边界策略附加到他们创建的角色和用户。
-
-
作为一种 defense-in-depth方法（与基于身份的策略结合使用），使用基于资源的 IAM 策略来拒绝对资源的广泛访问。
-
使用 IAM 访问顾问 AWS CloudTrail、IAM Access Analyzer 和相关工具定期分析历史使用情况和授予的权限。立即纠正明显的过度权限。
-
在适用的情况下，将广泛的操作范围限定为特定资源，而不是使用星号作为通配符来表示所有资源。
-
实施一种机制，根据请求快速识别、审查和批准 IAM 策略异常。
