如何使用管控策略实现企业可用云产品白名单_资源管理(Resource Management)-阿里云帮助中心

使用管控策略的允许（Allow）效果，可以简单方便地实现企业可用云产品白名单，规范企业内部用户订购和使用云产品的行为。

应用场景

企业上云过程中，一般会根据企业自身情况，通过调研和挑选，圈定需要订购的云产品列表，并与云厂商签订批量订购协议，从而使企业利益最大化。企业内部会要求各用户从圈定的云产品列表中进行订购，避免企业利益受损。这就是常见的企业需要启用可用云产品白名单的场景。

另外，基于安全合规考虑，企业需要启用可用云产品白名单，用来规范用户的使用行为，避免有意或无意的违规。

方案对比

老方案：通过访问控制（RAM）授予用户指定云产品的权限

该方案是授权到每个用户，适用业务场景比较单一的情况。当授权的数量、授权维度增加时，通过该方式满足企业可用云产品白名单的要求就会比较难，且管理成本会比较高。具体体现在以下几个方面：

针对用户的点对点授权，复杂度与您所管理的用户和资源数量成正比。
您要为每个用户在对应环境内配置访问不同资源的所需权限。当某个用户不再需要某个权限，或者需要修改其权限时，您需要找到这个用户进行权限更新。在新增用户和减少用户时，您需要设置和回收权限。当可用云产品白名单需要更新时，您不得不再次对所有已生效用户同步这个更新，策略的维护成本不可避免。
授权策略复杂，需要满足赋权和规避策略的双重要求。
当授权的因素涉及到更多维度时（例如：需要考虑资源所在位置、所在业务环境等因素），需要根据不同维度授予不同权限。例如：某地域的资源不允许用户订购、某项目订购云产品的特定限制、某些用户或角色可以无限制操作等。这些情况会进一步增加授权管理的复杂性。
授权和管控耦合，带来合规风险。
权限管理员根据业务需要调整用户的授权以达到业务要求，这些操作需要避开对合规类权限的影响，他（她）需要了解权限设计的所有细节，必要时可能需要合规管理员的协助才能完成。合规管理员也面临同样的问题。很明显，两种角色职能的操作耦合状况，无论对权限管理还是合规管控，都会存在极大的安全隐患。用户身份和被访问的资源间存在诸多特定限制，从而形成复杂的权限配置要求，给管理带来麻烦。

新方案（推荐）：通过管控策略的允许（Allow）策略进行顶层管控

资源目录的管控策略支持了"Effect": "Allow"，企业可以使用它，简单高效地解决上述问题。管控策略示例如下：

{
  "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"

}

上述管控策略示例中包含以下两个内容：

仅允许对华北2（北京）和华东2（上海）地域的ECS和RDS进行操作（即允许订购和使用），禁止对其他不符合条件的云产品进行操作。
名为a-project-admin-*的RAM角色可以无限制地操作。

使用管控策略的优势如下：

管控策略具备基于资源目录树形结构从上向下继承的特点。
您只需要将管控策略绑定到需要管控的节点（资源夹或成员）上，它将沿着资源目录树向下（当前节点及其下所有节点）影响节点下的所有成员。当成员的RAM用户或RAM角色访问阿里云服务时，都将受到管控策略的管控，实现预期管控的结果。在需要更新可用云产品白名单时，您只需要维护这条管控策略即可。
重要
管控策略对所有资源目录成员中的RAM用户和RAM角色生效，但对根用户不生效。
管控策略不进行授权，它只定义权限的边界，可以在不改变用户原有授权的基础上叠加影响。
假设某用户具有访问ECS和EIP的权限，当该用户被上述示例中的管控策略影响后：
- 该用户可以访问华北2（北京）和华东2（上海）地域的ECS。
  该用户本身具有访问ECS的权限，且管控策略也允许访问华北2（北京）和华东2（上海）地域的ECS，所以该用户可以访问华北2（北京）和华东2（上海）地域的ECS。
- 该用户不能访问EIP。
  虽然该用户具有访问EIP的权限，但管控策略中未包含EIP的允许语句，所以该用户不能访问EIP。
- 该用户不能访问RDS。
  虽然管控策略允许访问华北2（北京）和华东2（上海）地域的RDS，但该用户本身没有被授予访问RDS的权限，且管控策略不会对用户授权，所以该用户不能访问RDS。
管控策略与RAM授权策略分开管理，共同生效。
使用管控策略进行合规管理，使用RAM进行授权管理，使合规管理与授权管理职能分开，从而保护企业合规安全。管控策略属于顶层管控决策，高于授权策略，是企业的基本原则，所有业务规范都必须在企业基本原则之下进行制定。

方案实施

当您充分了解了管控策略新方案后，您可以开启管控策略功能、然后创建自定义管控策略，并将其绑定到资源目录的目标节点上。具体操作，请参见开启管控策略功能、创建自定义管控策略和绑定自定义管控策略。

另外，在实施过程中还需要完成以下任务：

在自定义管控策略中，增加允许sts:AssumeRole策略。

在资源目录中，推荐您使用RAM用户通过STS方式登录到成员进行管理操作。此时，您需要在管控策略内增加对sts:AssumeRole的允许语句，确保管理用户的登录权限可用。修改后的管控策略示例如下：

{
  "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"

}

在绑定了管控策略的目标节点上，解绑系统管控策略FullAliyunAccess。
为了避免启用自定义管控策略后因为没有显式允许（Allow）而直接导致隐式拒绝（Implicit Deny）所有操作，资源目录会默认为每个节点绑定系统管控策略FullAliyunAccess，该策略允许所有访问。在您使用了自定义Allow管控策略后，则需要解绑系统管控策略FullAliyunAccess，避免您自定义的Allow管控策略无效。关于管控策略的工作原理，请参见工作原理。

了解更多

在上述示例中，企业需要对ECS、RDS之外的所有云产品实施禁用，如果使用拒绝（Deny）语句，企业不得不列出ECS、RDS之外的所有云产品，这个操作非常繁琐，且容易遗漏。在使用Allow语句后，实现过程就变得简单可靠。

如果您有明确的禁用操作项，且数量不多时，您可以使用Deny语句显式拒绝这类操作。例如：明确不允许订购中国（香港）和华南3（广州）地域的云产品，您可以使用Deny语句，策略示例如下。如果使用Allow语句，反而复杂了。

{
      "Effect": "Deny",
      "Action":[
                "*"
      ],
      "Resource": [
                "acs:*:*cn-hongkong*:*:*",
                "acs:*:*cn-guangzhou*:*:*"
      ]
}

因此，您需要根据实际业务场景，灵活使用管控策略的Allow和Deny语句，简化策略的编写。

在一个管控策略中可以包含多组Allow和Deny语句，您需要评估其合并后产生的最终结果，在设计时避免它们之间产生冲突。一旦冲突，会遵照Deny优先原则。同一节点上绑定的所有管控策略，也会被合并在一起进行鉴权，只要命中Deny语句，系统会直接判定结果为显式拒绝（Explicit Deny），结束整个鉴权流程。