AWS云计算技术架构探索系列之二-身份账户体系(IAM)

一、前言建立身份账户体系是我们上云的第一步，良好的账户体系设计，会为后续的管理带来极大的便捷性和扩展性，反之，则可能增加管理的复杂，以及账户使用的不安全。AWS设计了一套完备的身份账号体系，主要包括IAM(Identity and Access Management),以及Organizations，其中IAM，包括账号，用户组，用户，角色，策略等。其关系图如下：用户，用户是AWS的身份凭证，分为

恰恰虎

4390人浏览 · 2022-05-01 07:14:25

恰恰虎 · 2022-05-01 07:14:25 发布

一、前言

建立身份账户体系是我们上云的第一步，良好的账户体系设计，会为后续的管理带来极大的便捷性和扩展性，反之，则可能增加管理的复杂，以及账户使用的不安全。

AWS设计了一套完备的身份账号体系，主要包括IAM(Identity and Access Management),以及Organizations，其中IAM，包括账号，用户组，用户，角色，策略等。其关系图如下：

用户，用户是AWS的身份凭证，分为根用户和IAM用户。用户的识别包括用户名/密码，AK/SK。
用户组，包含多个用户的组，方便用户策略的统一分配和管理。
角色，定义了受信任实体的特定权限，且凭证在短期内有效。通俗的说，定义了A(受信实体)对于B(目标资源)有特定的权限(增删改查等动作)，这个权限是通过短期凭证实现。
策略，是对权限的定义，允许或者拒绝(Effect)，对于哪些资源(resource)，实施哪些动作(Action)。
账户，即申请的AWS的账户，通过根用户管理其下所有IAM用户和资源，也是账单的承载单位。
组织，对多个账号统一管理，包括整合账单和服务控制策略。

下面我来具体介绍：

二、用户和用户组

用户是AWS的身份凭证，包括用户名/密码，AK/SK两种认证方式，用户名/密码用来登录控制台，AK/SK一般用户CLI，以及API访问。

用户可以分为：

根用户，一个账号默认有一个根用户，根用户作为账号的持有者，默认具备所有权限，类比管理系统的超级管理员。
IAM用户，根用户可以创建IAM用户，并为之设置策略，使其拥有相应的权限。
联合用户，相对于AWS来说的第三方用户，比如公司系统的已有的用户，或者来自互联网提供商，如Facebook，Google等。这种用户模式，比较好的适配混合云的场景。

对于只有几个人的小微企业，可能只需要根账户就能搞定一切。但是在大中企业中，技术岗位和人员有明确的分工，比如有应用开发者，数据库管理员，网络管理员，他们对不同资源有不同的权限要求，不可能将根用户给所有人的开放，此时就需要创建和分配不同的IAM用户，如下图所示：

如果一个IAM用户的认证信息泄露，影响的范围仅在所分配的权限范围内，且可以通过根用户修改其登录凭证，及时止损。但是如果根用户认证信息泄露，那就可以随意删除和修改所有其他用户的认证信息以及权限，影响将非常大。

那如何保护根用户信息呢，首先根用户只能掌握在少数账号管理人员手中，其他人是无法接触到的；其次，根用户启用MFA(Multi-Factor Authentication)，它提供了额外的安全级别，可以通过购买第三方硬件(类似于银行的U盾)，或者安装与 MFA 兼容的APP程序生成密钥。

用户组是一组用户的集合，可以为组内的用户统一分配权限，方便用户的管理。

三、角色

AWS的角色与传统的RBAC中的角色概念是不一样的，传统的RBAC中角色，是一组权限的集合，角色仅可以分配或者授权给某个用户。而AWS的角色首先也是一组权限的组合，同时还定义了受信任实体(即可分配的服务)。比如：

定义一个角色，EC2具有S3存储桶所有操作权限，受信任的实体就是"EC2服务"，权限就是"S3存储桶所有操作权限"。当该角色分配给某个具体的EC2实例，该EC2实例就具备了S3存储桶的所有操作权限。

角色的受信任实体可以有以下类型：

AWS产品，如ec2，s3等。
AWS账户，即其他的AWS账户。
Web身份，Cognito 或任何 OpenID 提供商。
SAML 2.0 身份联合。

当角色授予给某个具体的受信任实体的实例后，该实例就具有了角色定义的权限。在实现过程，是通过调用STS( Security Token Service)的API，获取临时凭证，再通过临时凭证签署对AWS服务API调用。

继续上面的例子，其Role逻辑关系和实现过程，我用以下的图示表示:

四、策略

策略是权限的定义形式，AWS采用JSON表达式,如下：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor1",
            "Effect": "Allow",
            "Action": "s3:*",
            "Resource": "arn:aws:s3:::mybucket",
            "Condition": {
                "IpAddress": {
                    "aws:SourceIp": "10.0.0.1"
                }
            }
        }
    ]
}

Effect，表示允许(Allow)，拒绝(Deny)。
Action，表示对服务的具体操作类型。如样例中s3:*，表示对s3服务的所有操作。
Resource，表示具体的资源标识，如样例中，arn:aws:s3:::mybucket表示S3的具体存储桶。
Condition,表示附加的条件，如样例中，对源IP进行限制。

其内容是，允许或者拒绝(Effect)，对于哪些资源(resource)，实施哪些动作(Action)。当然AWS提供了策略生成器，可以通过配置的方式生成该文件。

我们可以将一个或者多个策略附加给用户组，用户，角色。在策略定义以及执行的过程中，遵守以下原则：

最小授权原则，所有策略的定义都应该遵循，在满足要求情况下，按照最小原则授权。
拒绝优先原则，如果附加的多个策略有冲突，那么拒绝的策略优先。

对于附加用户组，用户，角色的策略，称之为基于身份的策略，该策略可以分为三种类型：

Amazon 托管策略，Amazon创建和托管的策略，该类型策略是无法修改的，并开放给所有账户，我们可以直接拿来用。
客户托管策略，客户在自己的账号中创建和托管的策略，客户可以根据自己的需求，灵活定义策略，以便精确控制。
内联策略，创建和管理的策略，直接嵌入在单个用户、组或角色中。

另外一种策略是附加在具体的资源上，称之为基于资源的策略。如下的策略就是附加在S3的DOC-EXAMPLE-BUCKET存储桶上，其格式如下：

{
  "Version":"2012-10-17",
  "Statement":[
    {
      "Sid":"AddCannedAcl",
      "Effect":"Allow",
    "Principal": {"AWS": ["arn:aws:iam::111122223333:root","arn:aws:iam::444455556666:root"]},
      "Action":["s3:PutObject"],
      "Resource":"arn:aws:s3:::DOC-EXAMPLE-BUCKET/*",
      "Condition":{"StringEquals":{"s3:x-amz-acl":["public-read"]}}
    }
  ]
}

与基于身份的策略相比较，基于资源策略的json表达式多了个Principal(委托人)字段，即该存储桶可以被两个账户实施PUT操作。

基于资源策略都是内联策略，即在创建某个具体资源的时候附加的，并与之绑定。目前仅部分服务支持该类型策略，比如S3，SQS等。具体可以参见：

使用 IAM 的 Amazon 服务 - Amazon Identity and Access Management

那为什么要设计基于资源的策略呢？我们来看个场景。

创建一个允许所有操作S3存储桶mybucket资源的策略，并分配给Role1，再将Role1附加到3个EC2上，这样这3个EC2就具备对S3存储桶mybucket所有操作权限。随着业务的调整，需求发生了变化，要求仅EC2 B能操作mybucket资源，其他两个不可以操作，如何实现呢？

首先想到的是，将Role1角色从EC2 A，EC2 C上删掉，但是Role 1有可能不只是包含这一个策略，如果删掉了，会影响这两台实例对其他资源的权限。还可以将role 1分拆成两个，这种操作实际也很麻烦，role多了也不好管理和维护。此时就可以使用基于资源的策略，就能轻松的解决问题。

在mybucket附加一个基于资源策略，拒绝EC2A，EC2C的操作，根据拒绝优先原则，策略叠加后，EC2 A，EC2C就无法访问。

五、账户

账户是可以对所属资源进行管理，以及查看和管理账单信息，账户的持有者就是根用户，通过根用户实现对资源的管理。

当企业的规模比较小时，一个账户，多个IAM用户的模式就能满足资源管理的需求。但是当发展到一定规模，就会遇到管理瓶颈，以账户管理为例，主要有：

多个环境管理，有开发环境，测试环境，以及生产环境，这些环境的资源是隔离，权限也要隔离。同一个账户多IAM用户模式，很容易出现由于权限管控错误，导致生产事故的问题。
用户管理，员工离职或者入职，或者岗位变化等等，导致用户管理工作繁重。

针对这些问题，企业一般采用多身份账户体系策略，如下：

每个环境创建一个对应账户，在该环境账户中，维护相应环境的资源，以及跨账户角色，允许身份账户对资源的访问。

身份账户管理维护所有的IAM用户，通过分配可访问跨账户角色的策略，控制IAM对各个环境资源的访问权限。

当某个员工加入，只需要在身份账户中创建一个IAM用户并分配策略，当该用户对访问的环境资源有需求变化时，通过变更策略即可搞定。这种多身份账户体系设计，即解决了各个环境的用户隔离，又通过对用户的统一管理，实现不同环境资源的访问。

六、组织

当企业采用多账户体系策略时，就会涉及到多账户的管理，组织就是AWS提供管理多账户的服务，主要有以下功能：

1、整合账单，可以管理和支付所有成员账户的账号，同时也可以享受折扣优惠，降低成本。

2、服务控制策略(SCP)，可以为所有的成员账户附加统一的服务策略，以便对成员账户管理。主要的是，这些策略对成员账户的根用户也生效，。

组织中，有且仅有一个管理账户，通过管理账户邀请成员账户加入。

七、总结

本篇中系统的介绍了AWS身份账户体系的内容。主要包括用户，用户组，角色，策略，账户以及组织，其相关的知识点，通过以下的表格总结

名称	定义	核心内容
用户	用户是AWS的身份凭证	1、分为根用户，IAM用户，联合用户 2、根用户具备所有的权限，需要重点关注其信息安全，采用MFA机制 3、根据对权限不同要求，创建不同IAM用户
用户组	多个用户的组	统一分配策略，方便用户的管理
角色	受信任实体的特定权限，且凭证在短期内有效	1、角色的定义，包括受信任实体，以及策略 2、受信任实体包括AWS产品，AWS账户，WEB身份，SAML 2.0 身份联合
策略	权限的定义	1、策略的内容，允许或者拒绝(Effect)，对于哪些资源(resource)，实施哪些动作(Action) 2、策略分为基于身份的策略和基于资源的策略
账户	申请的AWS的账户	1、对所属资源进行管理，以及查看和管理账单信息 2、账户的持有者就是根用户 3、多账户策略为最佳实践
组织	多账户的管理	1、整合账单功能 2、服务控制策略（SCP）功能