构建云上运行环境，安全是重中之重。亚马逊云科技采用了“责任共担模式”，邀您共同承担构建云上运行环境安全合规的责任。云上安全可二分为“云自身安全”和“云内部安全”。前者由亚马逊云科技负责，后者由您负责。您必须对云上资源进行必要和恰当的配置，使其具备一定的安全性，甚至达到更高的安全标准，从而履行安全责任。

亚马逊云科技提倡的完善架构的多账户云上环境包含六大支柱，其中权限管理是安全性支柱的重要内容之一。我们提供了一系列的服务、工具和方法帮助您有效管理权限：例如通过 Amazon Organizations 来集中监控和管理账户，通过 Amazon IAM 来管理账户内的各用户、角色和群组等等。

在多账户的组织层面建立权限防护机制，服务控制策略是其中不可或缺的一环。为弥补此块中国区域的服务差异，之前我们进行了许多有益的尝试（博客甲2020-04、乙2021-05、丙2021-09），核心思想是利用权限边界，尽可能模拟服务控制政策对账户的权限约束。最新的丙方案（以下称“前方案”）有一些限制和不足之处：例如策略文件大小有限、不支持组织关系继承等。此外前方案在易用性和可视化简洁操作方面，和原生服务亦有一定差距。本文力图改良不足和弥合差距，同时朝精简资源方面努力。本方案千方百计向原生服务靠拢，亦有利于您在原生服务发布后顺利迁移。

下表罗列了原生服务、本方案和前方案的主要异同点，以供您对比参考。

解决方案概览

本方案的核心思想是“于权限边界策略显式允许，于客户托管策略显式拒绝”来限制 IAM 实体。实现则借助于亚马逊云科技原生服务，但是尽可能精简所涉服务类型。此外设计理念是用户友好，即借鉴原生服务的操作习惯，充分利用管理控制台既有的用户交互界面，强调可视化交互模式，尽量提高易用性，简化不必要操作。在运维方面，利用流水线等工具提供一键部署和销毁功能。

上图是本方案架构草图，主要内容有：

·方案主体置于安全账户，主要包含主函数管理各账户权限，主队列序列化各触发事件，策略参数存放和可视化编辑各控制策略，各事件规则过滤收集相应触发事件等。

·在管理账户捕获组织结构的增删标签及移动账户事件。默认策略函数辅助附加推荐的策略到组织根。

·在各成员账户捕获创建角色和用户事件。

以上是本方案的核心架构和主要服务。和前方案相比减少了所用服务种类和资源数量，简化了用户操作和日常运维。本方案有一个通用公共字串作为“前缀”，方便标识本方案资源。

适用服务控制策略

>>新建策略并适用

适用服务控制策略（以下简称“策略”）主要分两步，首先定义策略，其次绑定策略。登陆安全账户参数库控制台，新建标准敏感字串型参数，名称为 /前缀/ policy /名称，密钥源为 alias /前缀/ pbm，值为策略文档。注意参数库并不会检查策略语法，您可以在 IAM 控制台验证策略是否合规。您可以按照原生服务的策略内容进行定义。

定义好策略后，可以绑定并适用策略。登陆管理账户组织控制台，在组织结构中选择组织部门或者账户，选择标签页，新建标签，其键为策略参数名，其值为空，然后保存。

对于成员账户而言，适用策略内容包含账户标签中的所有策略，以及上溯至根的所有组织部门以及组织根标签的所有策略的并集。类似于用作拒绝列表的策略继承。注意，本方案暂不支持严格的用作允许列表的继承。我们在后面章节详细分析。

我们会对适用策略内容进行合并，根据语句标识去重，按策略大小限制创建数个客户托管策略，以便附加到 IAM 实体和设置权限边界。IAM 实体现有的权限边界策略内容会被合并保留，仍然有效。

>>修改策略内容或删除策略

要修改策略内容，登陆安全账户参数库控制台，找到策略参数，选择编辑进行修改并保存。要删除策略，找到策略参数，选择删除进行删除。建议删除前先解绑该策略，即删除策略在组织结构里对应的所有标签。

增删改策略参数都会触发参数事件并被捕获。对于策略所涉组织部门和账户，都会更新适用策略。

>>修改或解除绑定策略

要修改绑定，登陆管理账户组织控制台，在组织部门或账户标签页删除并新建标签（因标签不支持修改键）。删除和新建标签可在一步完成。要解除绑定，在组织部门或账户标签页删除标签。

增删标签都会触发接口调用事件并被捕获。对所涉组织部门或账户，会更新适用策略。

>>在组织结构内移动账户

登陆管理账户组织控制台，选择一个账户，选择移动，选择目的组织部门然后移动账户。移动账户事件会被捕获，对该账户会根据新组织部门更新适用策略。

>>在账户内新建用户或角色

登陆成员账户 IAM 控制台，新建用户或者角色。新建事件会被捕获。如果新建 IAM 实体不在白名单列表中，则会根据所属账户及组织部门更新适用策略。

>>更新节点适用策略

我们用“节点”代指组织树形结构上的点，包括组织根，组织部门和账户。如果想对某节点的所有子账户，或者某账户更新策略，即重新适用最新策略，您可以在该节点新建或删除任意非策略标签，以触发主函数执行。

以上通过控制台可视化方式进行的操作，都可以通过亚马逊云科技命令行接口，软件开发包等其他方式达到相同的效果。

监控告警和日常运维

>>管控新成员账户

新建账户后，您需要登陆基础账户 Amazon Step Functions 控制台，执行管控状态机，以使得新账户受到本方案有效管控。完成之后移动账户到组织部门，以适用该部门的策略。

>>监控策略适用状态

本方案通过事件捕获和传递机制触发主函数来适用策略，故存在分钟级别的延迟。您可以通过状态邮件，或者登陆安全账户日志组控制台，查看名为 /aws/lambda/前缀-lambda-pbm 的日志组，了解运行状态。

在安全账户预置了状态 Amazon SNS 主题，接收方案主要运行状态和告警信息。内容会发送到您订阅的电子邮箱。主要的告警信息包含：

Amazon SNS：

·无法识别的标签键：即没有以 /前缀/policy/名称 形式创建的标签键。

·不合规的策略内容：策略内容不合策略语法，或者不合 JSON 语法。

JSON：

·显式允许语句过多：显式允许语句只能置于权限边界策略，受到6,144字节的限制。

·无法附加策略到实体：有可能 IAM 实体附加托管策略数已达上限20个。

·无法更新现有边界策略：有可能现有边界策略语句标识与控制策略语句标识冲突。

>>白名单和使用限制

您可以定义 IAM 实体白名单，以躲避本方案的权限约束。但是我们强烈不建议您使用，且原生服务也没有对应的功能。白名单是一个逗号分隔的字串，存储于基础账号的参数中。只要实体名称在白名单中，就不会适用策略。定义好白名单后，您可以在某节点更新适用策略，使之生效。

本方案和原生服务类似，有以下主要限制：

和原生服务类似：

·仅影响成员账户中的 IAM 角色和用户，对管理账户没有影响。

·不影响服务相关角色，即路径中有 aws-service-role 的角色。

服务相关角色：

·不影响维持本方案正常运行的核心角色。我们用这些核心角色管理成员账户权限。

·不影响名为 OrganizationAccountAccessRole（组织账号访问角色）。我们用此角色部署和销毁方案。

请注意，我们保留组织账号访问角色，以供您在紧急情况下使用。如果您绕过本方案使用该角色对实施了管控的 IAM 实体或者策略进行修改，您的账户可能产生新的安全漏洞或者进入权限管理的未知状态。您可以重新适用策略以巩固安全。

>>策略大小和附加数

在原生服务中，策略文档最大值为5,120字节，最多附加5个策略到节点，组织部门最大深度为5层。所以理论上适用到账户的策略内容最大值为5,120*5*5 =128,000。

在本方案中，策略文档以托管策略形式存在，最大值为6,144字节。 最多附加20个标签到实体。但是附加到 IAM 实体上的托管策略最多20个，所以理论上适用到账户的策略内容最大值为6,144*20=122,880。

需要注意的是，显式允许语句只能置于权限边界策略中，故显式允许语句最多只能是6,144字节。所以，我们建议您以用作拒绝列表的方式使用本方案，可有效突破限制到122,880字节。

但是我们建议您充分考虑原生服务的限制，而非用尽本方案的限制以便迁移：例如单个策略内容不要超过5120字节。附加到节点的标签数不要超过5个。另外默认附加数上限是10个，需要申请增加服务限额到最多20个。

标签策略替代方案的载体

标签策略也是目前中国区服务差异之一。我们也为此提供了替代解决方案（博客丁2022-08）。在对标签策略转写为显式拒绝的普通策略文档后，可将其以用作拒绝列表的服务控制策略适用到相应的组织部门或账户，达到替代原生标签策略的目的。

用作允许列表的策略继承

在策略评估逻辑中，有如下基本关系：显式拒绝 > 显式允许 > 隐式拒绝。> 的含义是覆盖。因此服务控制策略有两种主要使用方式，即用作拒绝列表和用作允许列表。本方案对策略的处理方法是从叶遍历到根取并集，然后按许可情况分别适用为客户托管策略和权限边界策略。假设有如下组织结构，虚线框内为节点附加策略内容，对最右侧路径的账户3而言：

● 用作允许列表的策略继承，特点是以显式允许为主，且删除托管的 FullAWSAccess （允许所有操作）策略。由于原生服务策略继承采取筛选器模式，故要在账户允许操作，则该操作的显式允许必须被该账户及其之上的每个组织部门直至组织根显式允许。

? 左图：原生服务只有操作 B 会被允许（所有节点允许）。

? 左图：本方案会允许操作 B （所有节点允许）和操作 C（任意节点允许）。

● 用作拒绝列表的策略继承，特点是以显式拒绝为主，且每个节点附加托管的允许所有操作策略。由于显式拒绝覆盖显式允许，故该模式较为简单。即如果该账户及其之上的每个组织部门直至组织根的任意节点有显式拒绝，则操作都会被拒绝。本方案与原生服务一致。

? 右图：操作 ABC 都被显式拒绝，其他操作被允许（本方案和原生服务一致）。

回顾之前策略语句的处理办法，即显式允许置于权限边界策略，显式拒绝置于客户托管策略。如果您的策略语句没有显式允许，我们会添加一个类似允许所有操作的显式允许语句。如果您的策略语句有至少一个显式允许，我们会把所有的显式允许置于权限边界策略中，而不做任何额外添加。

综上，本方案可视为用作拒绝列表的策略继承。在用作允许列表的策略继承情况下，本方案没有原生服务那么“严格”，即允许操作要求任意而非所有节点显式允许。您需要充分考虑这个区别，以便迁移。例如若日后希望迁移至用作允许列表的策略继承，则路径上所有节点都应显式允许该操作。

迁移到原生服务

上面章节在不同方面讨论了迁移到原生服务的注意事项，此处做一个总结。

● 单个策略小于5,120字节，且和原生服务策略一一对应；

● 组织结构节点附加标签小于等于5个；

● 按照用作拒绝列表的方式继承策略。如果用作允许列表的方式，则所有节点都需要显式允许。

我们建议您提早规划，当原生服务发布后，尽早迁移过去。迁移之前，请在沙盒环境进行充分测试。

● 按照现有策略一一对应创建服务控制策略；

● 按照现有绑定关系一一对应附加新建的服务控制策略到节点；

● 删除所有组织结构节点上的策略标签以解绑所有策略；

● 卸载本方案。

>>非组织多账户架构管控

如果由于各种原因，您不能或者不便使用 Amazon Organizations 组织，则本方案不适用此种场景。不过在前方案的基础上，我们提供对非组织多账户架构的支持，进行类似服务控制策略的管控。您可以访问 Cloud Foundations 解决方案页面联系亚马逊云科技专家获取解决方案。此外本方案支持亚马逊云科技全球区域部署。

安全措施与考量

作为安全功能的替代方案，我们十分重视本方案的安全性，尽可能“自我约束”。例如对所有适用之处用 Amazon KMS 客户密钥进行静态加密。安全账户不经过管理账户直接代入成员账户，且代入角色遵循最小权限原则严格限定 IAM 相关操作。各用户密钥、事件总线、队列、主题的资源权限也遵循最小权限原则。

您可以删除组织账号访问角色以进一步提高安全性。在此之前，我们建议您充分测试控制策略的影响，以免陷入困境。请注意，本方案基于该角色部署和卸载。

>>适用推荐的强制策略

我们预置了十几个策略，涵盖了 Amazon Control Tower 里所有的强制护栏，并额外新增了几个。建议您在组织根适用所有预置策略，以增强安全。适用方法是运行管理账户中的 前缀-lambda-pbm-policy 函数，输入任意参数。

卸载解决方案

本方案提供销毁状态机一键销毁所有资源。卸载之前务必确认您的云上环境已经迁移至原生服务或者其他类似方案，以避免出现安全漏洞。此外您需确认已经删除组织结构中的所有策略标签。

总结

本文介绍了一款直观易用的服务控制策略替代新方案，力图弥合服务差异，并在可视化交互和简化操作方面着力提升用户体验。同时在使用习惯和策略管理上，充分考虑日后平稳有序迁移到原生服务的各方面问题。您可以访问 Cloud Foundations 解决方案页面了解更多信息，或者联系亚马逊云科技专家获取解决方案。