+86 13541016684Mon. - Fri. 10:00-22:00

AWS Organizations —— 管理众多账号区分不同部门的费用

AWS Organizations —— 管理众多账号区分不同部门的费用

AWS Organizations —— 管理众多账号区分不同部门的费用

云服务的使用正在各个领域扩展,从构建简单的网站到使用大数据的高级数据利用。 其中,AWS(亚马逊网络服务)的份额位居第一。 AWS 拥有 200 多种类型的服务,许多公司将它们用于多种目的。

随着AWS的使用不断增长,管理公司内部的AWS账户已成为一个主要问题。
出于安全原因,AWS 建议将每个系统和生产/验证/开发环境的 AWS 账户分开。 因此,随着AWS使用的不断深入,AWS内部账户数量变得庞大,账户管理和控制的问题也日益凸显。

AWS Organizations 是一项“解决这些 AWS 多账户问题”的 AWS 服务。 在本文中,我们将广泛解释 AWS Organizations 的工作原理、它可以解决的问题以及用例。

 

您可以使用 AWS Organizations 做什么

让我们仔细看看 AWS Organizations 的功能。 在这里,我们将介绍四个主要内容。

  • AWS账户集中管理
  • 创建和管理新帐户
  • 集中计费和成本管理
  • 账户间资源共享

 

 

Organizations简述

AWS Organizations 可为多个 AWS 账户提供基于策略的管理。借助 AWS Organizations,您可以创建账户组,然后将策略应用于这些组。Organizations 支持您针对多个账户集中管理策略,无需使用自定义脚本和手动操作流程。

使用 AWS Organizations,您可以创建服务控制策略 (SCP),从而集中控制多个 AWS 账户对 AWS 服务的使用。Organizations 支持您通过 包括API,SDK和Console界面创建新账户。Organizations 还有助于简化多个账户的计费模式,即您可以通过整合账单(Consolidated Billing)为您组织中的所有账户设置一种付费方式。所有 AWS 客户都可以使用 AWS Organizations,且无需额外付费。要注意的是任意的AWS账户只能存在一个Organization中.

1

AWS Organizations关键性概念

在正式接触AWS Organizations之前我们必须要先弄清楚其中的关键性名词和概念

Organization – 组织

•     组织是指一系列AWS账户,您可以将其整理为一个层次结构并进行集中式管理

AWS account – 账户

•     AWS账户是您AWS资源的容器,例如: Amazon S3 存储桶、 Amazon EC2 实例等

•     通过AWS Identity and Access Management (IAM) 规则  (users, roles) 管理AWS资源

•     AWS Organizations中最小的管理单元

Master account – 主账户

•     在组织中为所有账户付款的账户

•     管理您的组织的Hub(中心)节点

Organizational unit (OU) – 组织单元

•     组织单元是组织内的一组AWS账户

•     把AWS账户添加到逻辑组中,账号管理更方便

•     AWS账户和组织单元OU可以是另外一个组织单元OU的成员

•     一个AWS账户可以是多个组织单元OU的成员

Administrative root – 管理根

•     管理根是整理AWS账户的起始点,也是整个组织层次架构中的最顶层的容器。

Organization control policy (OCP) – 组织控制策略

•     含有一个或多个语句的配置,这些语句用于定义您要应用于某组AWS账户的控制策略

•     不同应用场景使用不同的组织控制策略

下图可以帮助您更直观的理解这些概念之间的关系:

2

下面我会更详细的介绍以上提出的这些概念:

Account加入Organization的方式

1. 从Organization中创建新账户

  • 新的AWS账户只能通过主账户来创建
  • 在创建账户的过程中,您可以配置下面的信息

Ø  电子邮件地址 (必须)

Ø  账户名称 (必须)

Ø  IAM 角色名称 (可选 – 默认的名称是 OrganizationAccountAccessRole)

§  为主账户通过AssumeRole方式访问当前账户开启信任权限

§ 权限设置为完全控制

Ø  IAM 访问账单 (可选) 。注意! IAM 用户仍然需要相关的IAM权限才可以访问账单

  • 新AWS账户

Ø  自动成为您组织的一部分

Ø  可以从组织中删除,但是可以通过策略让其没有执行Leave Organization的权限

2. 让已有账户加入Organization

  • 邀请只能通过主账户发起
  • v 被邀请的AWS账户可以选择接受或者拒绝邀请

Ø  默认的行为是拒绝

Ø  可以通过IAM权限来控制

  • 当邀请被接受

Ø  这个AWS账户就成为组织的一个成员

Ø  可应用的OCP规则会被自动引用到这个账户

  • 被邀请的AWS账户可以被从组织中移除,但是可以通过策略让其没有执行Leave Organization的权限

AWS Account的逻辑组(OU)

•     把AWS账户添加到逻辑组中,账号管理更方便

•     AWS账户和组织单元OU可以是另外一个组织单元OU的成员

•     一个AWS账户可以是多个组织单元OU的成员

如下图所示:

3-1

 

OCP(Organization Control Policy)

  • 描述要应用的控制策略
  • 不同的使用场景有不同的应用控制策略 OCP
  • 应用控制策略OCP可以被附加到

Ø  组织(Organization)

Ø  组织单元(OU)

Ø  AWS账户(Account)

  • OCP拥有继承属性(AWS账户, 组织单元OU, 组织)

Ø  Policy是继承关系的,也就是说OU会继承organization的policy,而AWS Account会继承OU的policy

Ø  Account的policy会跟随其移动,如果这个Account从一个OU移动到另一个OU,那么属于这个Account的Policy也会移动。但是它不会再接收之前OU的Policy,而是会接收新OU的Policy

 

OCP support in V1:Service Control Policies(SCPs)

  • 允许您对AWS服务 API进行访问控制

Ø  定义一个允许访问的API列表 – 白名单

Ø  定义一个禁止访问的API列表 – 黑名单

  • 服务控制策略无法被本地管理员覆盖
  • 对于IAM用户和角色,最终生效的权限是服务控制策略和相关的IAM权限的交集
  • 必要但不充分,本地用户拥有某行为权限,必须要同时拥有SCP权限和IAM权限
  • IAM 规则模拟器对SCP有感知
  • SCP的控制权限大于本地administrator的权限

下图是使用白名单和使用黑名单写SCP的案例:

4-1

SCP使用的是IAM policy的语法,和IAM Policy一样,但是有以下两点不同

•     Resource必须是”*”

•     没有condition

一定注意,允许最终用户行为的话,必须要SCP和IAM Permission同时拥有。下图所示,如果在SCP允许S3和EC2,但是在IAM Permission允许EC2和SQS。那么最终用户只能拥有EC2的权限

5-1

简单化的账单管理

•     单个付款账户为所有账户付款

•     组织内所有的AWS账户的资源被核算到统一的账单中并应用相关的阶梯价

•     所有已存在的整合账单家族将会被迁移到组织的账单模式中

Organization不同的管理级别

您可以在创建新组织的时候选择不同的管理级别

账单模式(Billing mode)

•     和当前的整合账单模式向下兼容 (CB)

•     从整合账单家族中创建的的组织自动被设置为账单模式

完全控制模式(Full-control mode)

•     账单模式中的所有功能

•     开启所有类型的OCP管理功能

•     从账单模式转换成完全控制模式需要得到组织中所有AWS账户同意

 

动手利用AWS Organizations来管理您的组织

下面我就给大家演示一下,使用AWS Organizations服务如何能做到快速,方便,准确的来管理您的多个账户

进入AWS Organizations服务

进入AWS Organizations服务的方式,可以通过在service上搜索的方式进入,或者通过在Account菜单下点击My Organization进入。在Service的下拉菜单中没有这项服务。

服务栏搜索:

6-1

账号栏下拉:

7

创建新的Organization

8

在AWS Organizations服务界面上选择创建组织,选择希望创建的组织的种类,这里我演示时选择Full Control模式,如果希望仅进行账单整合(Consolidated Billing),那么选择右边的“Enable Only Consolidated Billing”。无论是哪种模式,账单都会是整合的。区别只在于Master Account能不能对加入的账号进行控制

9-1

注意:现在Consolidated Billing功能已经迁移到AWS Organization下了,如果点击主账号下的My Account-> Consolidated Billing,可以看到该提示,并且点击View Linked accounts也是直接就会跳转到AWS Organization界面

10-1

创建完毕之后,会出现组织架构管理界面,前面带星号的账号就是Master Account

11-1

添加新Account到Organization下

在创建完Organization之后,添加账号到Organization下有两种方式

•     直接添加账户

•     邀请其他账户加入

12

1. 直接添加账户(Account)

13

填写你希望添加的账号的全名和邮箱,并分配一个IAM Role,这个IAM Role是用来给予这个新Account一个full administrative control的权限

14-1

大约等待几秒钟,Account即可创建。对比如果是要自己在AWS网页创建账号,速度上提升了非常多。不过创建时没有设置密码,需要用户登录时在控制台点击忘记密码来重置。

15-1

在Global根账号控制台登录新创建的账号,因为不知道密码,所以需要点击忘记密码来重置。随后会在注册邮箱收到重置密码的链接,点击重置密码之后,重新登录即可

16

17-1

登录账户之后,可以看到这个新账号已经可以工作,并且Consolidated Billing功能是默认开启的。并指示该账户已经在一个Organization下了。

18

2. 邀请其他账户(Account)加入

点击Invite account来邀请其他账号加入,添加账号号码或者邮箱,并点击邀请即可

19-1

在界面右侧,点击Invitations可以看到已经邀请的账号的信息

20

此时在被邀请的账号的注册邮箱中会收到来自Master Account的邀请邮件,如果希望接受这个邀请加入Organization。那么可以选择点击邮件中的链接或者直接进入自己账号下的Organization界面接受也可以。

21 22

在Invitation界面中可以看见Organization的ID,邀请人的Account以及申请控制的类型,最后还有申请加入时的留言(Notes)

23

最后回到主账号下,可以看见包括Master Account,主动创建的Account以及受邀请加入的Account的信息

24

从Organization删除Account

有两种方式可以从Organization下面删除加入的Account:

1. Master Account主动从Organization删除Account,点击单个或多个Account,点击删除即可

25

2. 加入Organization的Account脱离Organization,在该Account下选择My Organization,可以看见其加入的Organization信息以及选择离开该Organization

26

利用OU(Organization Unit)来管理多个Account

开始时Organization下是没有任何OU的,需要用户自己手动去添加。每一级OU又可以添加自己下一级的OU,从而形成一个树状结构

27

你可以创建一个多级OU组织,包括一个根OU,两个一级OU和两个二级OU

28

所有的Account默认都在根OU下,你可以选择一个或者多个Account,并把他们移动到任意OU下。目前只能移动Account到OU,不能从OU主动加Account

29

针对不同的OU可以开启不同的Policy来控OU下面的Account,不过要开启这个feature,必须首先在Root OU下启动这个功能

33

利用Policy(Service Control Policy)来管理Account的行为

在使用Policy开管理Account时,始终记住两个原则:

1. Policy是继承关系,并且可以随Account移动

•     Policy是继承关系的,也就是说OU会继承organization的policy,而AWS Account会继承OU的policy

•     Account的Policy会跟随其移动,如果这个Account从一个OU移动到另一个OU,那么属于这个Account的Policy也会移动。但是它不会再接收之前OU的Policy,而是会接收新OU的Policy

2. 最终Account下的User的行为是SCP和IAM Permission共同决定的

一定注意,允许最终用户行为的话,必须要SCP和IAM Permission同时拥有。下图所示,如果在SCP允许S3和EC2,但是在IAM Permission允许EC2和SQS。那么最终用户只能拥有EC2的权限

31

Service Control Policy在Policies下面可以进行设置,默认情况就有一个什么权限都有的FullAWSAccess Policy并且是attach到Root OU的。这也就意味着默认情况下,只有有Account加入这个Organization,那么这个Account就拥有操作所有AWS服务的权限。如果希望修改SCP,那么可以点击右侧的Policy editor进行修改

32

SCP的格式和IAM Policy格式一致,但有下面两点不同。在修改完或创建完Policy之后,可以attach给任何OU或Account

•     Resource必须是”*”

•     没有condition

 

点击Policies界面下左上角的Create Policy可以从头创建一个SCP,你既可以选择使用Policy generator帮助你生成一个新的SCP,也可以从你已经创建的一个SCP中进行复制。在创建时,你可以选择白名单模式或者黑名单模式

34

这里我选择白名单模式,创建一个名为“SCP_Allow_access_VPC_subnet”的SCP,仅允许Account创建和查看VPC和Subnet,其余动作都禁止

35

将创建的SCP分配给OU,进而这个SCP会传递给下面添加的Account

36

在SCP配置界面下,将原来的FullAWSAccess策略解除,添加新创建的“SCP_Allow_access_VPC_subnet”策略。这个时候问题就来了,因为这个Account会继承所在OU的SCP,而所在OU又会继承上层OU的SCP。所以其实目前来说,这个Phoenix Yao的Account是会拥有两个SCP,包括拥有所有权限的“FullAWSAccess”和限制权限的“SCP_Allow_access_VPC_subnet”

37

在这种情况下会怎么样呢?其实和IAM Policy一样,SCP只会允许最小权限,所以当你用Phoenix Yao账号打开VPC界面时,会发现你无法查看除了VPC和Subnet的任何信息。另外,注意一下,这个Policy生效有时候需要一些时间,不是马上能看到结果。

38

我们再来看下IAM policy和SCP一起作用的结果。使用Phoenix Yao这个root账号创建一个User,并赋予其除了查看Subnet其余动作都可以做的IAM Policy。

39

将这个Policy绑定到新创建的IAM User的IAM Permission中

40

将SCP恢复成“FullAWSAccess”以单独测试IAM Permission是否生效,发现已经生效。

41

最后将SCP和IAM Permission一起使用。得到的结果应该是取最小权限,即只能查看VPC的情况

42

 

使用AWS Organizations时的最佳实践

下面介绍一些在使用AWS Organizations服务时的最佳实践:

1.      使用CloudTrail服务监控Master Account的行为活动

2.      不要通过Master Account来管理资源

3.      在管理你的组织时要采用”最小权限分配”的原则

4.      使用OU来对账号进行权限的分配管理

5.      仅给Organizations的根账号(root)分配仅需要的权限

6.      在测试权限时先使用单个AWS Account来测试

7.      避免在一个组织中同时使用”白名单”策略和”黑名单”策略

8.      每创建一个新的AWS Account都需要有足够合理的原因

给予Organization最小权限

•     对所有AWS组织行为设置相对应的IAM权限

•     您也可以把AWS组织相关的元素(组织,组织单元,AWS账户)作为IAM规则的资源进行管理

•     您可以把管理您组织的权限通过IAM role功能委托给一个在其他AWS账号中的IAM用户

•     所有的组织管理行为可以通过AWS CloudTrail服务记录