全部产品
Search
文档中心

资源管理:使用管控策略实现企业可用云产品白名单

更新时间:Jul 28, 2023

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

应用场景

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

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

方案对比

老方案:通过访问控制(RAM)授予用户指定云产品的权限

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

  • 针对用户的点对点授权,复杂度与您所管理的用户和资源数量成正比。

    您要为每个用户在对应环境内配置访问不同资源的所需权限。当某个用户不再需要某个权限,或者需要修改其权限时,您需要找到这个用户进行权限更新。在新增用户和减少用户时,您需要设置和回收权限。当可用云产品白名单需要更新时,您不得不再次对所有已生效用户同步这个更新,策略的维护成本不可避免。

  • 授权策略复杂,需要满足赋权和规避策略的双重要求。

    当授权的因素涉及到更多维度时(例如:需要考虑资源所在位置、所在业务环境等因素),需要根据不同维度授予不同权限。例如:某地域的资源不允许用户订购、某项目订购云产品的特定限制、某些用户或角色可以无限制操作等。这些情况会进一步增加授权管理的复杂性。

  • 授权和管控耦合,带来合规风险。

    权限管理员根据业务需要调整用户的授权以达到业务要求,这些操作需要避开对合规类权限的影响,他(她)需要了解权限设计的所有细节,必要时可能需要合规管理员的协助才能完成。合规管理员也面临同样的问题。很明显,两种角色职能的操作耦合状况,无论对权限管理还是合规管控,都会存在极大的安全隐患。用户身份和被访问的资源间存在诸多特定限制,从而形成复杂的权限配置要求,给管理带来麻烦。

    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),结束整个鉴权流程。