简介：企业上云多账号架构中，如何做到从上到下治理的同时，解决好员工的权限边界问题？
由多账号上云模式说起
多账号上云模式的产生
咱们的企业客户上云，个别都是从尝试部署大量业务开始，而后逐渐将更多业务采纳云上架构。随着企业上云的进一步深刻，越来越多的企业业务被放在了云端，这使得企业洽购的云资源迅速增多，资源、我的项目、人员、权限的治理变得极其简单，仅仅应用一个账号，使得问题被放大，很难失去无效解决。单账号负载过重已有力撑持，许多企业开始创立更多账号以扩散业务压力。于是，许多企业抉择应用了更多账号，对应其不同的业务。因而，从账号的应用方面看，企业应用的账号数量逐渐增多，多账号上云模式逐步成为多业务上云的重要选项。
多账号模式的劣势
诸多企业抉择采纳多账号模式上云，也是因为多账号绝对单账号而言，有着不可代替的劣势。
• 应用多账号的逻辑强隔离，实现企业不同业务利用间的互相独立
账号与账号之间默认是隔离的。这将防止不同业务间产生依赖项抵触或资源争用，甚至能够反对为每个业务设置明确的资源限度。
• 利用多账号扩散危险，最大水平晋升资源平安边界，尽可能将危害降到最低
打消平安“核按钮”。当非法用户窃取到一个高权限时，“爆炸半径”被限定到单个账号内，而不影响企业所有业务。
• 轻松应答大型企业多分公司关系，反对多种法律实体、多种结算模式共存
每个账号都可对应惟一一个法律主体，多账号环境人造反对团体企业的多分公司主体、以及不同业务的不同结算模式。
• 多账号易于结构化治理，业务的拆分和交融变得简略
业务过多导致“臃肿”不利于治理，业务间也非扁平状态，存在业务关联的“组织性”要求，单个账号很难解决，多账号却易于实现；同时，借助账号的独立性，它们可轻松地拆分或交融于不同的管控域，与企业业务适配联动。
多账号架构的挑战
多账号的采纳，如果不去有序的治理它，也会有很多麻烦。
比方，账号散落没有集中、没有结构化，就无奈做到组织化治理。再比方，下层管理者如何可能一眼全局、如何可能集中管控，都是影响企业业务效率的问题，须要解决。
无序治理的多账号人心涣散，有序治理是企业多账号模式促成生产效率的第一要务。
从多账号组织化问题看，阿里云的资源目录产品，能够很好地解决多账号有序治理问题。这是资源目录的根底能力之一。
资源目录是阿里云面向企业客户，提供的基于多账号的治理与治理服务。
大家能够看到，上图中，利用资源目录的组织能力，企业能够很快的构建属于本人的业务架构，将企业多账号依照业务关系聚合，造成结构化易治理的状态，并提供闭环的企业云资源管理服务，以此来适配业务的治理须要。
多账号模式下的权限管控问题
阿里云诸多大客户对于企业 TopDown 管控越来越器重。
随着客户业务的大量上云，员工（user）被密集且简单的授予各种资源、服务的权限以运作这些业务，企业治理端很难十分粗疏地考量每个业务的具体受权，但心愿可能从顶层做出企业的全局管控，即制订企业“大标准”以限定用户权限边界，免得超出公司的合规范畴。
如何可能简略高效的解决这个问题？以下是资源目录管控策略产品设计的初衷。
管控策略产品定义与实现
管控策略（Control Policy，下文简称 CP）是一种基于资源构造（资源目录中的组织单元或成员账号）的拜访控制策略，能够对立治理资源目录各层级内资源拜访的权限边界，建设企业整体访问控制准则或部分专用准则。管控策略只定义权限边界，并不真正授予权限，您还须要在某个成员账号中应用访问控制（RAM）设置权限后，相应身份才具备对资源的拜访权限。
从企业上云的角度看，管控策略的施行对象是企业用户对所需云资源的操作行为。从企业用户订购云资源、配置和应用云资源、最初到销毁云资源，管控策略能够对企业用户操作云资源的整个生命周期行为作出预设的前置校验，阻止不合乎预设规定的操作产生，最终达到标准企业用户对云资源应用行为的目标。
管控策略的实现机制
在鉴权引擎中减少管控策略校验
管控策略（CP）是如何实现权限管控成果的呢？
上图所示为用户拜访资源申请的鉴权流程。管控策略在鉴权引擎中减少前置校验逻辑，在正式鉴权之前就对操作产生的边界进行断定：对于 Explicit Deny（显式回绝）或 Implicit Deny（隐式回绝），将间接做出「回绝」后果，仅当管控策略的断定后果是 Allow（容许）时，鉴权引擎才会进行下一步断定。
基于资源目录实现从上至下的管控
当企业创立了一个资源目录，并为每个部门创立了成员账号后，如果对各成员账号的行为不加以管控，就会毁坏运维规定，带来平安危险和老本节约。利用资源目录 - 管控策略性能，企业能够通过企业治理账号集中制订治理规定，并将这些治理规定利用于资源目录的各级组织构造（资源夹、成员账号）上，管控各成员账号内资源的拜访规定，确保安全合规和老本可控。例如：禁止成员账号申请域名，禁止成员账号删除日志记录等。
当成员账号中的 RAM 用户或角色拜访阿里云服务时，阿里云将会先进行管控策略查看，再进行账号内的 RAM 权限查看。具体如下：
• 管控策略鉴权从被拜访资源所在账号开始，沿着资源目录层级逐级向上进行。
• 在任一层级进行管控策略鉴权时，命中回绝（Deny）策略时都能够间接断定后果为回绝（Explicit Deny），完结整个管控策略鉴权流程，并且不再进行账号内基于 RAM 权限策略的鉴权，间接拒绝请求。
• 在任一层级进行管控策略鉴权时，如果既未命中回绝（Deny）策略，也未命中容许（Allow）策略，同样间接断定后果为回绝（Explicit Deny），不再进入下一个层级鉴权，完结整个管控策略鉴权流程，并且不再进行账号内基于 RAM 权限策略的鉴权，间接拒绝请求。
• 在某一层级鉴权中，如果未命中回绝（Deny）策略，而命中了容许（Allow）策略，则本层级鉴权通过，持续在父节点上进行管控策略鉴权，直至 Root 资源夹为止。如果 Root 资源夹鉴权后果也为通过，则整个管控策略鉴权通过，接下来进入账号内基于 RAM 权限策略的鉴权，详情请参见权限策略断定流程。
管控策略的用法说明
管控策略的语言
CP 应用与 RAM 基本相同的语法结构。
CP 语法结构中蕴含版本号和受权语句列表，每条受权语句包含受权效劳（Effect）、操作（Action）、资源（Resource）以及限度条件（Condition，可选项）。其中 CP 较 RAM 的 Condition 反对上，多了一种条件 Key：acs:PrincipalARN，实现对执行者身份（目前反对 Role）的条件查看，次要利用场景为下文中提到的「防止指定云服务拜访被管控」。您能够理解更多 CP 语言的应用办法
管控策略的影响成果
您能够将自定义 CP 绑定到资源目录的任意节点，蕴含任何一个资源夹或成员账号。CP 具备基于资源目录树形构造从上向下继承的特点，例如：为父资源夹设置管控策略 A，为子资源夹设置管控策略 B，则管控策略 A 和管控策略 B 都会在子资源夹及其下的成员账号中失效。
• CP 仅影响资源目录内的成员账号下的资源拜访。它对资源目录企业治理账号（MA）下的资源拜访不会产生影响，因为 MA 并不属于 RD；
• CP 仅影响成员账号内的 RAM 用户和角色拜访，不能管控账号的根用户（Root user）拜访。咱们建议您在资源目录内应用资源账号类型成员，这一成员类型禁用了根用户；
• CP 基于资源的拜访失效。无论是资源目录内的用户，还是内部用户，拜访资源目录内的资源时，都会受到 CP 的管控；例如，您对资源目录内的 A 账号绑定了一个 CP，同样实用于在资源目录内部的 B 账号内的用户拜访 A 账号内的资源时的管控
• CP 同样影响基于资源的受权策略。例如，在资源目录内的 A 账号中 OSS bucket 上授予资源目录内部的 B 账号内的用户拜访，此拜访行为同样受到绑定在 A 账号的 CP 影响
• CP 对服务关联角色（Service Linked Role）不失效。对于服务关联角色的详情，请参见服务关联角色
防止指定云服务拜访被管控
管控策略将对被管控成员账号中的资源拜访权限限定边界，边界之外的权限将不容许失效，此限定同样影响阿里云服务对该成员账号拜访的有效性。
阿里云服务可能应用服务角色（Service Role）拜访您账号中的资源，以实现云服务的某些性能。当一个服务角色的权限超过管控策略的边界时，此权限会受到管控策略的束缚，这可能导致云服务的某些性能不能失常应用。如果这正是您配置管控策略冀望的后果，则无需进行其余额定操作，然而，如果您不心愿这些云服务被管控，您能够采纳以下办法进行解决：
- 确认您不心愿被管控的云服务所应用的服务角色名称。您能够登录 RAM 控制台，查看账号下的所有服务角色。
- 在造成管控成果的管控策略中减少 Condition key: “acs:PrincipalArn” 的条件，将受影响的云服务所应用的服务角色名称写入到 PrincipalArn 字段，以防止该服务角色被误
管控。示例如下：
{
"Statement": [
{
"Action": ["ram:UpdateUser"],
"Resource": "*",
"Effect": "Deny",
"Condition": {
"StringNotLike": {"acs:PrincipalARN":"acs:ram:*:*:role/< 服务角色名称 >"}
}
}
],
"Version": "1"
}管控策略应用限度与参考
阿里云资源目录 - 管控策略目前已反对对 152 款云产品，您能够查看反对管控策略的云服务
管控策略的应用限度如下：
• 资源目录内最多容许创立自定义管控策略的数量为 1500 个；
• 每个节点（资源夹、成员账号）最多容许绑定自定义管控策略的数量为 10 个；
• 每个自定义策略的最大长度 2048 个字符。
咱们建议您先进行部分小范畴测试，确保策略的有效性与预期统一，而后再绑定到全副指标节点（资源夹、成员账号）。
原文链接
本文为阿里云原创内容，未经容许不得转载。