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

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

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

 

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

 

 

Organizations简述

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

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

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账户的控制策略

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

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

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

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的成员

如下图所示：

 

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的案例:

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

•     Resource必须是”*”

•     没有condition

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

简单化的账单管理

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

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

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

Organization不同的管理级别

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

账单模式(Billing mode)

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

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

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

•     账单模式中的所有功能

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

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

 

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

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

进入AWS Organizations服务

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

服务栏搜索：

账号栏下拉：

创建新的Organization

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

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

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

添加新Account到Organization下

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

•     直接添加账户

•     邀请其他账户加入

1. 直接添加账户(Account)

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

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

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

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

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

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

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

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

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

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

从Organization删除Account

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

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

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

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

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

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

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

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

利用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的权限

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

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

•     Resource必须是”*”

•     没有condition

 

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

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

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

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

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

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

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

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

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

 

使用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服务记录