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：

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

加入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服务时的最佳实践：

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

 不要通过Master Account来管理资源

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

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

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

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

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

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

给予Organization最小权限

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

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

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

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

作者介绍：
姚远

姚远，AWS解决方案架构师，负责基于AWS的云计算方案架构的咨询和设计，同时致力于AWS云服务在国内的应用和推广。现致力于网络和DevOps相关领域的研究。在加入AWS之前，在思科中国担任系统工程师，负责方案咨询和架构设计，在企业私有云和基础网络方面有丰富经验。

本文转载自AWS技术博客。

原文链接：https://amazonaws-china.com/cn/blogs/china/aws-organizations-manage-account/

创作场景

AWS Organizations 管理众多账号再也不是难题