AWS Organizations 中组织单元的最佳实践

Original URL: https://aws.amazon.com/cn/blogs/mt/best-practices-for-organizational-units-with-aws-organizations/

在推动业务创新的过程中，AWS客户希望快速部署并拥有安全保障。多账户框架可以提供相关指导，帮助客户规划其AWS环境。这套框架在满足安全需求的同时，能够根据变化的业务需求扩展并适应其AWS环境。拥有良好架构的多账户AWS环境以AWS Organizations为基础——这是一项AWS服务，旨在帮助您集中管理并统筹多个账户。

本文将深入探讨AWS最佳实践架构，帮助您建立起安全可靠的组织体系。本文将具体介绍并阐释组织单元（OU）建议结构，并提供具体的实现案例。如果您需要更全面的概念，不妨直接查看建立AWS最佳实践环境页面。
为何使用多租户的AWS环境？
在AWS的支持下，您可以快速进行实验、创新与扩展，同时严格保证云环境的灵活性与安全性。在客户构建及部署工作负载时，往往需要相应机制以隔离各类资源（即资源容器），并通过使用多个AWS账户加以实现。每个AWS账户能够为您的AWS资源提供天然隔离且独立的安全保护、访问权限与计费边界，保证各类资源之间互不干扰。例如，您账户之外的用户在默认情况下并没有权限访问您账户中的资源。同样的，您在使用AWS资源过程中产生的成本将仅与当前账户相关联。大多数用户在刚开始使用AWS时往往只设置一个账户，但随着工作负载在规模性与复杂性层面的不断提升，AWS建议您设置多个账户。作为最佳实践，多账户环境能够为您带来以下助益：

配合各类要求实现快速创新：您可以将AWS账户分配给企业内的不同团队、项目或者产品。区分账户建立起一整套快速创新机制，充分满足不同场景下的独特安全要求。
简化计费：使用多AWS账户能够简化您的AWS成本分配方式，助您轻松确定哪部分支出与哪款产品或哪条服务线相对应。
灵活的安全控制能力：您可以使用多AWS账户将具有不同安全要求或者需要满足特定合规性条款（例如HIPAA或PCI DSS）的工作负载或应用程序隔离开来。
轻松适应业务流程：您可以通过最能反映企业业务流程多样化需求的方式轻松组织多个AWS账户，例如根据不同运营、法规与预算要求进行账户划分。
最终，多租户AWS环境使您能够使用云服务快速行动并构建起差异化产品与服务，同时建立起一套具备良好安全性、可扩展性与弹性保障能力的业务实现体系。但是，我们该如何构建多账户AWS环境？在具体实施层面，大家可能遭遇多种问题，例如应使用哪种账户结构、应采用哪些策略与围栏，以及如何设置审计环境等等。

在本文中，我们将逐步了解构建安全高效的多账户AWS环境的具体要素——AWS通常将这类环境称为“登陆区”。其代表着用于构建初始框架的最佳实践，且能够随着您AWS工作负载的持续增长而始终保持良好的灵活性。

设置多账户AWS环境的最佳实践

在切入正题之前，我们首先来熟悉一部分术语。组织单元（OU）是AWS Organizations中的账户逻辑分组。OU可帮助您将账户组织到一套统一的层级结构当中，使您更轻松地应用各类管理控制机制。AWS Organizations策略则为您在控制机制中实际使用的执行策略。服务控制策略（SCP）是用于定义组织内各账户所能执行的AWS服务操作（例如Amazon EC2 run instance）的具体策略。

在构建这套结构时，一大关键原则在于减少此结构的整体管理开销。为此，我们最小化整体层级结构的深度以及需要应用策略的位置数量。例如，服务控制策略（SCP）主要应用于OU层级——而非账户层级——借此简化错误排查流程。后文也将介绍这种管理方法的例外情况。

首先，我们应考虑需要创建哪些账户组或OU。OU允许根据功能、通用策略以及AWS账户的组织习惯进行账户划分，借此更轻松在具有类似职能的AWS账户之间共享集中管理的资源。您的OU应该基于相同功能或者一组通用控制机制，而非直接复制企业中的报告结构。

生产与软件开发生命周期（SDLC)

在深入了解基础OU之前，请首先考虑如何实现软件开发生命周期。鉴于大多数企业对生产工作负载拥有不同的策略性要求，某些OU当中可能嵌套有非生产（SDLC）型OU与生产型OU。SDLC OU中的各账户负责托管非生产环境，即开发、测试与预生产环境等。这些账户不应与其他账户存在生产依赖关系。另一方面，生产OU中的账户则负责托管各类生产工作负载。对于并非由客户开发的应用程序与服务，SDLC账户可对分段环境进行建模。例如，我们既可以将现成产品托管在SDLC OU下的开发环境当中，也可以将其托管在工作负载OU中生产OU下的生产账户之内。

当然，客户也可能会创建单一SDLC OU以通过多个账户托管全部开发阶段。但如果生命周期各阶段中的OU策略存在差异，则SDLC OU可以替换多个OUs，例如开发OU与预生产OU。但无论如何，业务环境中通常应始终存在一个单独的生产OU，用以承载生产级工作负载。

根据实际需求，我们可以在OU层级应用策略，借此管理生产与SDLC环境。通常，我们建议您在OU层级——而非单一账户层级——应用管理策略，借此简化策略管理以及可能需要的故障排查操作。

基础性OU

AWS建议大家首先从安全性与基础设施层面入手。大多数企业都拥有集中团队，负责为整个组织提供安全与基础设施支持。因此，我们建议为这类特定职能团队创建一组基础性OU，分别为基础设施OU与安全OU。

OU：基础设施

基础设施：用于共享各类基础设施服务，例如网络与IT服务等。我们需要为各种基础设施服务类型分别创建账户。

示例：某客户拥有三项共享式基础设施与网络服务，分别提供对企业网络的访问、通过RabbitMQ（消息总线服务）建立的托管消息服务以及一个通用的共享基础设施账户。其OU与账户结构如下图所示：

OU：安全

安全OU用于托管与安全相关的访问与服务。安全OU自身、其下各子OU，以及与之关联的AWS账户，都将由企业中的安全部门所持有及管理。

建议账户

Log Archive: 此AWS账户充当信息合并点，用于从当前环境内的各AWS账户处收集与安全性相关的AWS访问与审计日志信息。

Security ReadOnlyAccess (人工): 此AWS账户，旨在帮助安全团队成员以只读权限访问AWS环境中的其他AWS账户，借此实现审计、探索性安全测试以及调查。例如，在调查可疑安全事件的早期阶段，您的安全团队成员将首先访问此AWS账户并使用只读IAM跨账户角色，而后访问其他AWS账户以查看并监控资源状态。

Security Breakglass (人工): 此AWS账户使用频率较低，仅在发生安全事件时供安全团队成员使用。通过此账户，您可以对AWS账户进行广泛的写入访问。在安全事件发生时，安全团队成员需要获得特殊授权才能获取此访问权限。在事件解决之后，相应的临时访问权限将被撤销。所有访问操作也将得到详细记录。

Security Tooling (最低程度人工): 此为一个或多个AWS账户，用于托管面向安全的各类工作负载与服务、工具以及支持数据。此账户中配置的工具与服务通常包括Amazon GuardDuty主账户、AWS Security Hub主账户、Amazon Detective主账户以及各类第三方云安全监控服务与工具。应尽量减少出于管理目的对这些AWS账户进行的人工访问，尽可能推广基础设施即代码（IaC）与其他自动化技术。除了管理访问权限之外，安全团队成员可能还需要其他人工访问权限，借此与安全服务进行交互并执行各类必要的安全服务配置操作。

在中央服务部署到位之后，我们建议您创建与产品或服务的构建或运行直接相关的OU。在基础部署之上，大部分AWS客户会构建以下几种OU。

OU：Sandbox

此OU用于各技术人员的AWS账户，允许他们借此学习并深入研究AWS服务项目。我们建议您将此沙箱中的账户与客户内部网络剥离开来。要访问AWS服务，则必须访问互联网，本文建议您严格限制互联网连接。此外，大家还应考虑在沙箱账户中设置固定支出限制，例如每月100美元，并定期向领导团队报告以及时发现异常状态及过度使用等情况。

例如，某客户为所有员工提供沙箱账户：

OU：Workloads

此类OU用于管理创建软件生命周期的AWS账户。本文建议大家创建工作负载账户以隔离软件服务（而非直接与客户团队映射），保证所部署的应用程序能够充分适应组织结构的变化。您可以轻松将一组账户的访问权限在不同团队之间往来移交——相比之下，将软件服务从一个账户转移到另一个账户则相当艰难复杂。

SDLC/非生产OU中的账户仅用于软件服务分段，且不应与其他OU构成依赖关系。

其他附加OU中的账户应仅围绕工作负载/生产OU账户进行设计与部署。

示例：某客户拥有三个不同业务部门，分别为制造、消费者服务与市场营销，各部门共享同一套治理与运营模型。消费者服务部门拥有一套公开的beta版方案，但并未包含在OU当中。在这种情况下，本文建议您使用以下结构：

以此为基础，我们已经建立起面向业务的基础性OU，接下来即可推进云探索之路了。下面来看初始框架：

我们建议您根据实际需求添加其他面向业务的OU，借此建立起维持业务运作并持续进行扩展的能力。下面来看基于现有AWS客户实践的其他几种常见OU主题：

OU: PolicyStaging

在对AWS Organization进行策略或结构性调整时，最重要的就是在广泛应用之前对调整内容进行验证。为此，管理员需要在不影响生产效果的前提下，构建并应用潜在的调整操作。组织单元“OU:PolicyStaging”是一类非生产OU，可供组织管理员测试提出的OU设置并验证策略应用效果。

本文建议大家创建子OU与账户以测试变更。在充分理解并验证变更之后，即可采用部署策略将变更逐步应用至更广泛的组织当中。这里建议大家首先在目标账户上进行最小规模的初步试验，并在建立一定信心后继续推进组织结构的变化。以这种方式进行变更，能够将潜在影响范围控制在最低程度。

示例：策略团队负责管理关于安全性、基础设施、工作负载、代码以及部署相关策略。为了分段完成一系列工作，大家应采取以下结构：

OU: Suspended

其中包含已关闭，且正等待被从组织中删除的各AWS账户。将服务控制策略（SCP）附加至此OU，以拒绝所有后续操作。如果需要修复账户，请保证为账户标注详细信息以实现后续追溯。

已离职雇员拥有的账户以及其他即将清退的账户，应被移动至“suspended”OU当中。各账户还应标注有详细信息，例如其来源等，以备后续进行恢复或者其他追溯性操作。

关闭达90天的账户将被永久删除，此后该账户及其对应的资源将无法恢复。已关闭的账户将在组织当中显示为“suspended”状态。在被永久删除之后，我们将无法在组织中继续查看该账户。

关于关闭账户的更多详细信息，请参阅AWS账户关闭说明文档。

OU: IndividualBusinessUsers

受限访问OU，其中包含业务用户等非技术人员的AWS账户。这些用户可以创建与业务生产相关的应用程序，例如设置S3存储桶并与各合作伙伴共享报告/文件。

OU: Exceptions

在某些情况下，业务用例需要在OU: Workloads定义的安全性或审计条件中包含部分例外。当识别出与之匹配的情况后，即可准予例外，账户将获得自定义安全机制。OU: Exceptions下的账户将凭借这种自定义属性，将SCP直接应用于该账户——而非OU。由于附带有自定义的预防性控制措施，这些账户的所有者还可以进一步对现有检测及反应系统（例如Amazon CloudWatch Events、AWS Config Rules等）进行更严格的审查。

例如，绝密项目就是属于一类特殊情况，可能适合被归属于Exceptions OU。项目的最终归属，取决于您在合规性与安全性层面定义了哪些SCP，以及当前新产品是否能够在相关SCP定义的规则之内发布。如果相关安全约束过于严格，大家甚至有必要为其单独建立新的组织，借此避免监管对象后续给主组织带来更高的潜在风险与缓解成本。

OU: Deployments

此OU包含用于CI/CD部署的AWS账户。与工作负载OU（生产与SDLC）内的各账户相比，部署OU可以为CI/CD部署管道提供完全不同的治理与运营模型。CI/CD分发机制有助于降低组织对于中央团队负责运营的共享CI/CD环境的高度依赖性。对于工作负载OU内各应用程序所对应的每一组SDLC/生产AWS账户，您可以在Deployments OU之下为其创建一个对应的CI/CD账户。

CI/CD部署管道可以由AWS CodeX服务或者自托管服务具体实现。本文建议大家以与软件服务构建与部署运营模型相匹配的方式进行CI/CD分发。

非生产OU中的账户用于实现CI/CD服务分段，且不应与其他OU构成依赖关系。

示例：某客户拥有三个不同业务部门：制造（使用工业物联网服务，并使用自治运营模型）、消费者服务、以及市场营销（共享治理与运营模型）。在这种情况下，本文建议您使用以下OU与账户：

这里建议大家将CI/CD部署OU划分为不同的层级结构与AWS账户，这是因为治理及运营模型有着不同的要求。

对于每一项需要构建的服务，大家都应在团队OU之下创建与开发生命周期相匹配的账户。其中生产阶段应处于OU:Workloads/OU:Prod之下，开发生命周期中的所有其他阶段则应处于OU:Workloads/OU:SDLC之下。

各项服务（即一组SDLC账户）都应拥有与之对应的部署账户。该账户位于OU:Deployments之下。例如，如果名为foo的服务拥有开发、beta、QA以及生产四个账户，则其整体环境配置应如下图所示：

现在，我们已经建立起额外的OU与账户。

总结

拥有良好架构的多租户策略能够帮助您在AWS中加快创新步伐，同时帮助您满足安全性与可扩展性需求。本文中提及的框架充分体现了AWS最佳实践，建议大家将其作为AWS探索之旅的理想起点。

要着手构建您自己的环境，请参阅《AWS Organizations 上手指南》；或者，您也可以使用AWS Control Tower通过数次单击快速设置起安全的初始AWS环境。

本篇作者