本文介绍阿里云资源目录中管控策略能力的一种推荐实践，您可以点击了解资源目录产品背景介绍。
场景说明
企业根据自身情况，通常会限定其业务用云时允许采购的云产品，这些云产品一般经过企业的调研和挑选过程、是企业采购的最佳选项。被确认为适用于企业的产品，并非是阿里云的大量云产品种类，它只要满足企业所需又不会超出必要范围；企业一般会与阿里云签订这些产品的批量采购协议以取得优惠政策，使企业利益最大化。为了在云采用过程中落实可用产品的采购规则、使企业受益，企业需要制定一套顶层策略来限定允许采购的云产品范围，以防止企业内用户的有意或无心的“违规”操作导致企业利益受损。
这是常见的、企业启用“可用产品白名单”的情况；还有很多其他场景，例如基于安全合规考虑，企业也都需要启用这一白名单以规范用户使用行为，本文所描述的方案均适用于解决此类管控需求的问题 。
方案对比和采用
如何禁止企业用户不能订购白名单之外的云产品呢？
我们向您介绍两种方案，分别是使用访问控制（RAM）针对性授权和使用管控策略“允许”（CP:Allow）进行白名单控制。通过对方案实施过程及两者特征的比对，我们建议并推荐您使用后一种方案。
旧方案：授予用户“特定产品”的相应权限
是的，这是看起来最直接的解决方案，但操作起来却很繁琐、不易维护且容易出错。
针对用户的点对点授权，其复杂度与您所管理的用户和资源数量成正比
可以想到，您要为每个用户在相应环境内配置访问不同资源的所需权限。
当某个用户不再需要这个权限（离开这个环境时），或者需要更改权限，您都需要找到它并进行权限修改；您需要在新增用户和减少用户时进行权限的设置和回收；当“可用产品白名单”需要更新时，您不得不再次对所有已生效用户同步这个更新，策略的维护成本不可避免。
授权策略更为复杂，需要满足赋权和规避策略的双重要求
实际上，用户和资源数量的组合本身还不是最复杂的状况。当授权的因素涉及到更多维度，比如您需要考虑因 资源所在位置、所在业务环境 等因素不同而设定不同权限时，例如：“某区域资源不允许用户订购”、“A项目采购产品的特定限制”、“某些用户角色可以无限制操作”，这些情况进一步加重了授权管理的复杂性。
授权和管控耦合，带来合规风险
权限管理员根据业务需要调整用户的授权以达到业务要求，这些操作需要避开对“合规类”权限的影响，他需要了解权限设计的所有细节，必要时可能需要合规管理员的协助才能完成；合规管理员也面临同样的问题。很明显，两种角色职能的操作耦合状况，无论对权限管理还是合规管控，都会存在极大地安全隐患。
如图，实线/虚线箭头分别表示允许和拒绝的策略。
为了满足业务需要，用户身份和被访问的资源间存在诸多特定限制，从而形成复杂的权限配置要求，给管理带来麻烦。
授权到每个“身份”，在业务场景比较单一时是或许可用；一旦授权的数量、维度增多以后，通过授权的方式满足企业“限定产品使用”的要求显然很难落地、管理成本会非常高。
新方案：使用管控策略(CP:Allow)进行顶层管控
近期，阿里云资源目录的管控策略（Control Policy，简称CP）支持了"Effect": "Allow"，语义上可解释为“仅允许”，企业可以使用它，简单高效的解决上述问题。
先看下面的Control Policy设计：
{
"Statement":[
{
"Effect": "Allow",
"Action":[
"ecs:*",
"rds:*"
],
"Resource": [
"acs:*:*cn-beijing*:*:*",
"acs:*:*cn-shanghai*:*:*"
]
},
{
"Effect": "Allow",
"Action": "*",
"Resource": "*",
"Condition": {
"StringLike": {
"acs:PrincipalARN": [
"acs:ram:*:*:role/a-project-admin-*"
]
}
}
}
],
"Version": "1"
}
上方CP中有两个Statement。第一个，定义仅允许“北京”“上海”的ECS和RDS可以操作（即允许订购和使用），其他不符合条件的产品操作将被禁止；第二个，定义名为“a-project-admin-*”的role可以无限制操作。
CP具备基于资源目录树形结构从上向下继承的特点
您只需要将CP绑定到需要管控的节点（Folder或Account）上，它将沿着资源目录树向下（当前节点及其下方所有节点）影响所有账号，无论用户在哪里访问这些账号中的资源，都将受到CP的管控、实现预期管控的结果。在需要更新允许使用的产品清单时，您只需要维护这份CP即可。
CP并不会进行授权，它只定义权限的“边界”，可以在不改变用户原有授权的基础上叠加影响
假设用户zhangsan具有访问ecs、eip的权限，当他被此CP影响后，由于CP的许可范围不包含eip，即使zhangsan拥有访问eip的权限也不能对eip进行任何操作；同时他也不能访问rds，因为CP并不会为他进行授权。
CP与授权策略分开管理、共同生效
使用CP让合规管理与授权管理职能分开，从而保护企业合规安全。CP属于顶层管控决策，高于授权，是企业的基本原则，所有业务规范都必须在企业基本原则之内进行制定。
了解了CP方案的原理之后，您在执行时，还需要做以下两件事。
- RD推荐您使用ram user通过sts方式登录到成员账号进行管理，所以此时您需要在CP内增加对sts:AssumeRole的许可策略以确保管理用户的登录权限可用。Control Policy修改如下：
{
"Statement":[
{
"Effect": "Allow",
"Action":[
"ecs:*",
"rds:*"
],
"Resource": [
"acs:*:*cn-beijing*:*:*",
"acs:*:*cn-shanghai*:*:*"
]
},
{
"Effect": "Allow",
"Action": "*",
"Resource": "*",
"Condition": {
"StringLike": {
"acs:PrincipalARN": [
"acs:ram:*:*:role/a-project-admin-*"
]
}
}
},
{
"Effect": "Allow",
"Action":[
"sts:AssumeRole"
],
"Resource": "*"
}
],
"Version": "1"
}
- 在某个节点上绑定了您自定义的CP后，需要解绑这个节点上的默认系统策略“FullAliyunAccess”。这个系统策略在您未绑定任何CP时“放行所有访问”，避免CP启用后因为没有显式Allow而直接导致“隐式拒绝”所有操作。所以在您使用了自定义的allow CP后，需要解绑它，否则它会使您的allow CP无效。如需了解管控策略的详细工作原理，可以点击产品文档查看。
延伸阅读
灵活使用CP的Allow和Deny，简化策略的编写。
在上述例子中，企业需要对ecs、rds之外的所有产品实施“禁用”，如果使用Deny语句，您将不得不列出ecs、rds之外所有阿里云产品，这个数量目前已经达到260多款，可想而知这一难度之大，使用Allow可以很大程度让实现变得简单可行。
在CP中除了可以使用allow来简化策略内容，也可以使用deny进行配合，进一步使您的CP语句简洁易读。
何时使用Deny？
如果您有明确的禁用操作项，且数量不多，您可以使用Deny来“显式拒绝”这类操作。
例如，明确不允许订购地域为“香港”和“广州”的产品，您可以增加下面的Statement，用deny来处理。如果使用allow，反而更加复杂了。
{
"Effect": "Deny",
"Action":[
"*"
],
"Resource": [
"acs:*:*cn-hongkong*:*:*",
"acs:*:*cn-guangzhou*:*:*"
]
}
再次提醒，在一个CP中可以包含多组Allow和Deny的内容，您需要合并评估其产生的最终结果，在设计时避免它们之间差生冲突；一旦冲突，请参考Deny优先原则。同一层级上绑定的所有CP，会被合并在一起进行鉴权，只要命中拒绝（Deny）策略，系统会直接判定结果为拒绝（Explicit Deny），结束整个鉴权流程。
