IAM 代表“身份和访问管理”，它在 AWS 内提供了一个集中的控制中心，并与所有其他 AWS 服务集成。
IAM 是所有 AWS 资源的 GateKeeper 或安全卫士。
IAM 提供 MFA（多因素身份验证）支持，允许您在整个组织中设置自定义密码轮换策略。
您可以授予其他人管理和使用您 AWS 账户中资源的权限，而无需共享您的密码或访问密钥。
您可以为不同的人授予不同的权限以获取不同的资源。例如，您可能允许某些用户完全访问 Amazon Elastic Compute Cloud (Amazon EC2)、Amazon Simple Storage Service (Amazon S3)、Amazon DynamoDB、Amazon Redshift 和其他 AWS 服务。
对于其他用户，您可以只允许对某些 S3 存储桶进行只读访问，或者只允许管理一些 EC2 实例或访问您的计费信息，但不能访问其他任何内容。
为在 Amazon EC2 上运行的应用程序安全访问 AWS 资源 您可以使用 IAM 功能为在 EC2 实例上运行的应用程序安全地提供凭证。这些凭证为您的应用程序提供访问其他 AWS 资源的权限。示例包括 S3 存储桶和 DynamoDB 表。
您可以向您的帐户和个人用户添加双重身份验证，以提高安全性。使用 MFA，您或您的用户不仅必须提供密码或访问密钥以使用您的帐户，还必须提供来自特殊配置设备的代码。
IAM 实体
用户： 任何个人最终用户，例如员工、系统架构师、CTO 等。
组：具有共享权限的类似人员的任何集合，例如系统管理员、人力资源员工、财务团队等。其指定组中的每个用户都将继承为该组设置的权限。
角色：任何需要被授予权限才能完成其工作的软件服务，例如——AWS Lambda 需要对 S3 的写入权限，或者需要从 RDS MySQL 数据库读取权限的 EC2 实例队列。
策略：用于授予或限制访问权限的记录规则集。为了让用户、组或角色正确设置权限，他们使用策略。策略是用 JSON 编写的，您可以使用自定义策略来满足您的特定需求，也可以使用 AWS 设置的默认策略。
IAM 策略与上述其他实体分开，因为它们不是 IAM 身份。相反，它们附加到 IAM 身份，以便相关 IAM 身份可以执行其必要的功能。
IAM策略
借助 IAM 策略，您可以通过创建策略并将它们附加到 IAM 身份（用户、用户组或角色）或 AWS 资源来管理 AWS 中的访问。
策略是 AWS 中的一个对象，当与身份或资源相关联时，它定义了其权限。AWS 在 IAM 委托人（用户或角色）发出请求时评估这些策略。
大多数策略作为 JSON 文档存储在 AWS 中。您不必了解 JSON 语法。您可以使用 AWS 管理控制台中的可视化编辑器来创建和编辑客户管理的策略，而无需使用 JSON。
要创建 IAM 策略，您必须创建一个 JSON 文档。请参阅下面的 JSON 文档结构：
声明中的信息可能包含以下实体：
-
版本 – 指定要使用的策略语言版本。作为最佳实践，请使用最新的 2012-10-17 版本。
-
声明 – 将此主要策略元素用作以下元素的容器。您可以在策略中包含多个声明。
-
Sid – 包括一个可选的语句 ID 以区分您的语句。
-
Effect – 使用 Allow 或 Deny 指示策略是允许还是拒绝访问。
-
委托人 – 如果您创建基于资源的策略，则必须指明您希望允许或拒绝访问的账户、用户、角色或联合身份用户。如果您要创建 IAM 权限策略以附加到用户或角色，则不能包含此元素。主体隐含为该用户或角色。
-
操作 – 包括策略允许或拒绝的操作列表。
-
资源 – 如果您创建 IAM 权限策略，则必须指定操作适用的资源列表。如果您创建基于资源的策略，则此元素是可选的。如果您不包含此元素，则应用该操作的资源就是附加该策略的资源。
-
条件 - 指定策略授予权限的情况。
IAM 策略示例：
"Version": "2012-10-17",
"Statement": [
{
"Sid": "FirstStatement",
"Effect": "Allow",
"Action": ["iam:ChangePassword"],
"Resource": "*"
},
{
"Sid": "SecondStatement",
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "*"
},
{
"Sid": "ThirdStatement",
"Effect": "Allow",
"Action": [
"s3:List*",
"s3:Get*"
],
"Resource": [
"arn:aws:s3:::confidential-data",
"arn:aws:s3:::confidential-data/*"
],
"Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
}
]
}
以下示例显示了一个 JSON 策略，该策略允许用户对 us-east-2 区域内 123456789012 账户中的 Books 表执行所有 Amazon DynamoDB 操作 (dynamodb:*)。
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "dynamodb:*",
"Resource": "arn:aws:dynamodb:us-east-2:123456789012:table/Books"
}
}
策略类型
以下策略类型按从最常用到不常用的顺序列出，可在 AWS 中使用。
基于身份的策略– 将托管策略和内联策略附加到 IAM 身份（用户、用户所属的组或角色）。基于身份的策略授予身份权限。
基于资源的策略– 将内联策略附加到资源。基于资源的策略最常见的示例是 Amazon S3 存储桶策略和 IAM 角色信任策略。基于资源的策略向策略中指定的主体授予权限。委托人可以与资源在同一个账户中，也可以在其他账户中。
权限边界– 使用托管策略作为 IAM 实体（用户或角色）的权限边界。该策略定义了基于身份的策略可以授予实体的最大权限，但不授予权限。权限边界不定义基于资源的策略可以授予实体的最大权限。
组织 SCP – 使用 AWS Organizations 服务控制策略 (SCP) 定义组织或组织单位 (OU) 的账户成员的最大权限。SCP 限制基于身份的策略或基于资源的策略授予账户内实体（用户或角色）的权限，但不授予权限。
访问控制列表 (ACL) – 使用 ACL 来控制其他账户中的哪些主体可以访问 ACL 附加到的资源。ACL 类似于基于资源的策略，尽管它们是唯一不使用 JSON 策略文档结构的策略类型。ACL 是向指定委托人授予权限的跨账户权限策略。ACL 不能向同一账户中的实体授予权限。
会话策略– 当您使用 AWS CLI 或 AWS API 代入角色或联合用户时传递高级会话策略。会话策略限制角色或用户的基于身份的策略授予会话的权限。会话策略限制已创建会话的权限，但不授予权限。
IAM 中的优先级
-
明确拒绝：拒绝访问特定资源，并且该裁决不能被否决。AWS 检查适用于您的请求上下文的每项策略。如果单个权限策略包含拒绝操作，AWS 将拒绝整个请求并停止评估。这称为显式拒绝。
-
显式允许：只要没有关联的显式拒绝，就允许访问特定资源。
-
默认拒绝（或隐式拒绝）：IAM 身份开始时没有资源访问权限。相反，必须授予访问权限。
单个帐户中请求的评估逻辑遵循以下一般规则：
默认情况下，所有请求都被拒绝。（通常，始终允许使用 AWS 账户根用户凭证对账户中的资源发出的请求。）任何权限策略（基于身份或基于资源）中的显式允许会覆盖此默认值。组织 SCP、IAM 权限边界或会话策略的存在会覆盖允许。如果存在一种或多种这些策略类型，则它们都必须允许该请求。否则，它被隐式拒绝。
任何策略中的显式拒绝都会覆盖任何允许。
注意：只有组织中的服务控制策略 (SCP) 才能限制授予 root 用户的权限。
IAM 密钥详细信息
IAM 是不受地域限制的全球 AWS 服务。任何用户、组、角色或策略都可以全局访问。
具有完全管理员访问权限的根账户是用于注册 AWS 的账户。因此，用于创建 AWS 账户以供使用的电子邮件地址应该是公司的官方电子邮件地址。
首次创建帐户时，新用户没有权限。这是一种安全的委派访问方式，因为必须有意授予权限。首次加入 AWS 生态系统时，当您授予新用户编程访问权限时，他们会获得一个访问密钥 ID 和一个秘密访问密钥 ID。
这些只是专门为新用户加入而创建的，所以如果他们丢失了，只需生成一个新的访问密钥 ID 和一个新的秘密访问密钥 ID。访问密钥仅用于 AWS CLI 和开发工具包，因此您不能使用它们来访问控制台。
在创建您的 AWS 账户时，您的公司内部可能有一个提供单点登录 (SSO) 的现有身份提供商。如果是这种情况，那么在 AWS 上重用您现有的身份是有用、高效且完全可能的。为此，您让一个 IAM 角色由其中一个 Active Directory 代入。
这是因为 IAM ID 联合功能允许外部服务能够承担 IAM 角色。
IAM 角色可以在首次使用/创建之前或在使用/创建之后分配给服务，例如 EC2 实例。您可以根据需要多次更改权限。这一切都可以通过使用 AWS 控制台和 AWS 命令行工具来完成。
您不能嵌套 IAM 组。单个 IAM 用户可以属于多个组，但无法创建子组以将一个 IAM 组嵌入到另一个 IAM 组中。
借助 IAM 策略，您可以轻松添加标签，帮助定义谁可以访问哪些资源。这些标签随后用于通过特定的 IAM 策略控制访问。例如，生产和开发 EC2 实例可能会被这样标记。这将确保只能访问开发实例的人无法访问生产实例。
IAM 用户不是单独的账户；他们是您帐户中的用户。每个用户都可以拥有自己的密码来访问 AWS 管理控制台。您还可以为每个用户创建一个单独的访问密钥，以便用户可以发出编程请求以使用您帐户中的资源。
如果您的公司目录与安全断言标记语言 2.0 (SAML 2.0) 兼容，您可以将公司目录配置为为您的用户提供对 AWS 管理控制台的单点登录 (SSO) 访问。基于属性的访问控制
假设您有三个项目，名为 Heart、Sun 和 Lightning，您的员工都在从事这些项目。您为每个项目创建一个 IAM 角色。
然后，您将策略附加到每个 IAM 角色，以定义允许代入该角色的任何人都可以访问的资源。如果员工在您的公司内更换工作，您可以将他们分配给不同的 IAM 角色。
可以将人员或程序分配给多个角色。但是，Sun 项目可能需要额外的资源，例如新的 Amazon S3 存储桶。在这种情况下，您必须更新附加到 Sun 角色的策略以指定新的存储桶资源。否则，不允许 Sun 项目成员访问新存储桶。
网友评论