一、前言
建立身份账户体系是我们上云的第一步,良好的账户体系设计,会为后续的管理带来极大的便捷性和扩展性,反之,则可能增加管理的复杂,以及账户使用的不安全。
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)功能 |
附件:
AWS云计算技术架构探索系列之一-开篇
AWS云计算技术架构探索系列之二-身份账户体系(IAM)
AWS云计算技术架构探索系列之三-计算
AWS云计算技术架构探索系列之四-存储
AWS云计算技术架构探索系列之五-网络文章来源:https://www.toymoban.com/news/detail-833591.html
AWS云计算技术架构探索系列之六-数据库文章来源地址https://www.toymoban.com/news/detail-833591.html
到了这里,关于AWS云计算技术架构探索系列之二-身份账户体系(IAM)的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!