本次将跟大家一起探讨在阿里云上权限管理相关的话题，一起去理解背后的一些原理，掌握一些实践的方法。

时至今日，已经很难不通过RAM单独使用阿里云，在使用RAM时，是否也遇到过这样的一些困惑，听说过RAM Policy、Bucket Policy、Role Trust Policy等各种各样的权限策略，这些策略让大家眼花缭乱、不知所措。也听说可以把资源放进资源组授权，放进账号授权，甚至还可以给资源目录的组织节点做授权。这些纷繁复杂的资源关系应该如何去理解，在学校时听说过RBAC的角色，在阿里云RAM上也听到过很多角色，比如服务角色、服务关联角色、实际角色，这些角色和理解的角色它是同一个东西吗？带着这些问题和大家一起来探讨几个问题，首先理解访问控制的基本原理，第二个部分介绍5种典型的授权方式。最后一个部分在阿里云多账号环境下怎么使用管控策略来进行更加集中化的权限管理。

 

一、阿里云访问控制基本原理

首先要回答为什么要授权。当第一次安装Linux操作系统时，装完之后有一件很重要事情是把root账号给封存起来，需要创建一个普通的账号，用它来完成日常的操作。在阿里云上也同样有这样一个事情，当云账号被创建出来时，整个账号下面只有唯一的一个身份，即root身份，又称它为主账号身份，root身份它是有账号内所有的权限，出于安全的最佳实践，建议用户去创建RAM用户和RAM角色，用这些RAM用户和角色来完成日常工作。而同时要把root身份，即主账号身份彻底锁起来。不到万不得已千万不要去用它。这就是为什么要授权。

当在阿里云上执行某一个操作的时候，阿里云的内部到底发生了什么事情，无论是用什么方式访问控制台，还是用一些命令行工具telephone CUI, 编辑SDK和阿里云集成调用的API，也无论使用什么样的身份，主账号身份、RAM用户身份、角色身份，请求最终都会以API请求的方式到达阿里云。阿里云会在处理请求之前，首先做一件非常重要的事情——权限检查。这个权限检查是由RAM访问控制系统来负责完成，它的检查的原理简单概括为用用户身上绑定的权限策略去和请求当中对应的鉴权上下文做特征匹配，再基于权限策略的语言规范，对请求做出判定，到底是有权限还是没有权限。

RAM防问控制系统，它除了是在内部用于执行权限检查的系统之外，同时也是对于客户可以去使用的一款云服务，用户可以在RAM访问控制产品上面创建RAM用户、RAM角色、权限策略，并将这些策略绑定到这些用户和角色身上。权限策略是一个非常重要的组成部分。权限策略它总体上是Jason的文档，它其中包含多个statement语句，一个statement就描述了一个规则，表示在什么样的情况下允许或者禁止什么身份对什么资源执行什么样的操作，在一个statement内部是包含若干个条件的，一个条件描述了一种特征的取值是什么，比如action是什么，Resource是什么以及访问的原端IP是什么。

在一个条件的内部它可能会有多个取值，表明这个值可以取哪些范围是允许的，值与值的关系是或的关系，条件与条件的关系是且的关系。当所有的statement被评估完成之后，鉴权逻辑会基于所有这些鉴权的statement匹配的结果做出综合判断，判断的原则可以简单归结为显示deny优先命中，无allow则默认拒绝。这是一个非常简单的规则，在这个权限策略里面，注意到有一个resource字段，它的取值是阿里云资源的ARN，它有5段组成，其中后面四段分别代表了资源所属的云服务代码，它所在的地域、账号的UID，以及最后一个部分是与云服务相关的资源描述的部分。最后一个部分通常是由云服务定义的格式，格式可能不尽相同，但总的来看它可能分为两类，一类是资源名称型的AR，一类是资源ID型的AR，在后面的部分会看到这两种类型的AR决定了授权方式可能会有不一样的地方。这是在单个权限策略内部的情况。阿里云在对一个用户的请求做权限校验的时候，可能会有多种不同类型的权限策略参与到校验，这些权限策略类型不同是因为所绑定的实体不一样，比如有的可能绑定在身份上面，有的可能绑定在资源上，还可以绑定在资源组或资源目录的管控节点上面。RAM会把所有权限策略取下来，对请求进行权限的校验，这些权限策略分为两大类，一类是授权，下面的这几种策略就是授权的策略，还有一类是管控，接下来就分别介绍授权和管控这两种策略。

 

二、灵活多样的授权方式

第二个部分是授权的方式。在这个部分开始之前，想问大家一个问题，是否有对身份授予AdministratorAccess权限，是在什么场合下去对他做授权的，是个人账号、测试账号，还是生产账号，是否清楚这背后意味着什么。当给一个身份授予AdministratorAccess的时候，这意味着给这个身份授予了近200款阿里云服务的操作权限，包括这些服务所有类型的操作，涵盖了账号下所有Region所有资源类型的权限，它是非常大的权限。如果这个账号密钥发生泄露，黑客可以用这个身份把线上的ECS给停掉，把RDS停掉，导致业务瘫痪，也可以用这个账号在账号下创建ECS，比如用来挖矿或者用来作为攻击其他人的肉鸡。数据可能会被窃取，重要数据可能会被加密，然后勒索。不管是什么样的一个后果，它都意味着难以估量的损失。建议不要轻易使用AdministratorAccess。

阿里云提供了非常丰富的授权方法，这里介绍5种典型的授权方法。第一种是服务级的授权。服务级的授权是给一个身份授予某一个服务，比如ECS OSS VPC都是一款的服务，授予这个身份，这个服务下所有操作的权限，也包括账号下所有跟这个服务相关的资源的权限。授予服务级的权限相比于授予administrator权限，它是一种非常简单且有效的能够避免权限闲置以及RAM高危权限滥用的手段。在使用阿里云的时候，日常的工作可能使用的云服务数会是一小部分，比如10、20个，意味着有大量的服务的权限，实际上是不必要的，如果授予权限这就是闲置的。这其中也包括了RAM的高危权限，当开始准备以服务级的方式做授权的时候，实际上就会问自己一个问题，到底需要什么样服务的权限，在问出这个问题的同时，已经不自觉的解决了两个安全的问题，第一个是避免了大量不必要的权限的授予，以及避免了RAM高危权限的滥用。

服务级的授权主要有两种场景，第一种是对特定职能角色人员的授权，譬如公司专门负责VPC网络的专员，给他授予VPC网络权限。负责阿里云上账单费用发票的专员，给他授予BSS费用中心的权限，这就是对于特定职能角色的人员进行授权，还有一种场景是要去探索一个新的用云的方式做POC的验证，比如现在大模型很火，阿里云也提供了一个大模型的平台叫做百炼，如果要去试用这个产品，就可以给他授予服务器的权限，这样的好处是能够快速的完成POC的验证，而不必在比较早的阶段就纠结应该授予什么样的细腻度的权限，授予服务器的权限非常简单，因为阿里云为每一款服务都准备了系统授权策略，大概的格式是AliyunXXXFuilAxxess, 以及它的只读的版本AliyunXXXReadOnlyAccess，只需要在RAM的控制台去勾选相应的系统策略，将它绑定到身份上面就可以完成服务级的授权。

接下来是操作级的授权，服务级的授权总的来说还是一种相对粗粒度的授权的方式，有些情况下会希望授予比这个服务粒度更细的权限，这个时候可能就需要用到操作级的授权。阿里云的每一款服务都是由若干个API组成的，譬如以ECS服务为例，它包含有上百个API操作，覆盖了像磁盘、镜像、实例、快照等资源的CRUDL的操作，操作级的授权是给身份只授予其中一部分操作权限。

列举三个典型的场景会用到操作级的授权，第一个是比如要授予RAM的权限，RAM的权限它其中包括大部分的操作都是高危的权限，可以修改身份的权限，创建新的RAM用户和角色。但是RAM的操作里面还有一类可能会用于日常工作当中，比如CreateServiceLinkedRole或者PassRole这两个权限。如果希望授予一些普通的账号这类型的权限，但又想避免把一些高危的权限授予给这个身份，就采用操作级授权。还有一类场景是仅需要允许生命周期内部分操作被授予，譬如有些企业它内部有自己的一套云的资源的供给平台，这个平台负责去创生产这个资源以及消费这个资源，仅希望业务人员去使用这个资源，这种情况下，就可以通过操作级的授权去限制业务人员只读或者部分的修改权限。

还有一种情况是比如云服务，为了满足不同客户群体的需要会提供非常丰富的功能，比如像VPC这款服务，它会提供像VPC网络交换机，Nat网关，VPN网关等功能，但是可能只希望授予的业务人员其中一部分的功能，在这种情况下，也可以使用操作级的授权来满足这样的授权场景的要求，使用操作级授权就得用到了自定义策略，编辑自定义策略可以使用RAM的控制台完成，提供了两种编辑的方法。

一种是可视化编辑器，它会直接给列出服务下面有哪些操作是可以勾选，也可以用脚本编辑的方式去做同样的事情，这两者的效果是完全相同的，使用操作级做授权其实相比于服务级授权，它有门槛在于如何知道要完成的这项工作需要哪些操作权限，建议结合阿里云官网提供的一些场景化授权的教程，以及每个云服务提供的API授权的参考文档来完成授权工作。譬如以OSS为例，在他的官网文档里面列举了非常常见的场景下，应该如何给身份授权来满足需要。服务级的授权和操作级的授权有共同的特点，授权是在操作这个维度展开的，在日常的工作中，对于资源区分的授权其实是非常常见的。

假设需要给某个应用授予他只能在某一个MQ的topic上收发消息的能力，仅允许应用在某一个OSS桶的子目录下读取文件能力，以及希望应用的管理员只能去管理企业里面属于这个应用相关的某一部分的ECS实例，这些场景它都是涉及要去区分资源进行授权，这都是资源级授权的场景。在阿里云授权到底本质是什么，授权的本质是在账号下创建一个权限绑定的关系，而这个权限绑定关系里面有三个非常重要的元素，一是身份，二是权限策略，三是资源范围。

对于很多熟悉RAM的人，身份和权限策略显得不陌生，但是资源范围可能就头一次听说或觉得比较抽象。资源范围是授权它生效的资源的最大的边界。阿里云有3种资源范围，第一种是账号的范围，账号的范围它囊括了账号内所有的资源，资源组的授权范围囊括了加入这个资源组内所有云服务的实例的资源的范围，单资源也构成一个范围，譬如以OSS Bucket为例，它下面会有若干个object文件，bucket它本身也就构成了一个资源范围，囊括它自身以及旗下的bucket文件，所以当再次提到授权的时候，对某一个身份在某一个资源范围上绑定某一个权限策略，同时还要注意到能够描述授权能访问的资源的有两个因素，一个是权限策略，另一个是资源的范围。一个用户在访问一个资源的时候，所相关的权限绑定关系的不同层级上的策略都会参与鉴权，RAM会把所有这些权限策略取下来，用来对请求进行权限评估。

在一般的情况下，可以认为这些策略之间并没有太大的差异，遵循所理解Deny优先和默认拒绝的基础原则。但还需要理解，在某些特殊的情况下，他可能表现出一些特殊的行为，比如在划账号的情况下，在账号级上的权限和资源级上的权限都必须allow，但这也不影响用最简单的方式去理解它。回顾了前面这部分的原理支持之后，查看三个场景应该如何做授权。第一个场景是希望授予这个身份只有访问某一个MQ消息队列的权限，给他授予账号级的权限，同时在权限策略里面把这个消息精确的ARN直接写到resource里面。对于第二个场景，同样授予账号级的权限，不同的在于因为授予他一个目录的权限，一个目录其实意味着有一批object文件需要被授予，所以使用ARN里面的通配服务来表达范围。第三个场景是ECS的批量授权。

ECS的ARN，它是一个ID类型，它是一个随机产生的unique的ID，不能像OSS路径使用通配服务的方式去匹配它，需要用到资源组授权做批量授权。把一个项目或者一个应用所对应的ECS实例加入到这个项目所对应的资源组里面，然后给这个身份授予资源组上的权限，这样就完成了对一批ECS实例的集中授权。接下来会有一个视频的演示来看一下实际的在阿里云的控制台上，如何去完成这么授权的动作。这个视频里面会演示在一个资源组下面，创建属于这个资源组的ECS实例以及VPC的实例。

首先创建资源组，登录资源管理的控制台。选择资源组标签，创建资源组，创建两个资源组，一个project1，名称叫项目一，同时在创建一个project2，两个资源组创建出来，然后给两个用户分别叫张三、李四，分别给他们授予项目1上面的VPC和ECS的操作权限。这里选择资源组级别，选择资源组项目1授予ECS的for access以及ABC access。对于李四用户同样操作，只不过给他授予的是资源组项目2上面的权限。完成授权后接下来演示其中一个用户，在他的资源组下面去创建属于资源组的VPC和ECS的实例。

登录张三用户的账号，先来创建他的VPC资源，选择项目一，在资源组下创建项目，项目一上面创建VPC的资源。打开资源组的标签，选择张三他所拥有权限的项目一资源组，然后点击创建，VPC的实例就在项目一这个资源组下面创建完成。

接下来再来创建ECS的实例，同样先选择项目1这个资源组范围。选择刚刚创建了在这个资源组下的VPC交换机。下面都选择默认，这边注意打开高级选项，可以看到实例已经默认选择了上面选择的资源组的ID项目名称，创建成功。

接下来再演示一下在自己所属的资源组下面去查看实例，分别演示ECS、VPC的控制台中，通过这选择之后查看，以及在资源管理的控制台下面集中的查看。进入资源管理的资源组控制台，可以看到创建的实例，汇总的信息都在概览页列出来，以及是每一个具体的实例都在资源管理tab页下面列出来，可以基于产品地域或其他的维度对他进行一个统一的筛选。

再演示一下用没有资源组项目一资源组的权限的李四，另外一个用户尝试查看项目一下面的资源的情况，发现列表显示为空。VPC上面也会显示没有权限列出，资源管理里面也看不到项目一的资源，因为并没有给李四授予在项目一上面的资源组的权限。通过上面的视频，看到如何在资源组下面去创建对应的资源，用来做分权的管理，资源组除了提供分权隔离的能力之外，看到还可以对整个资源提供统一的资源的视图，方便去做更集中化的管理。

如果业务是在单个账号下面，并且有按照部门或者按照项目做资源隔离的诉求，非常推荐使用资源组来做分权的管理和权限的隔离。接下来进入了第4个部分跨服务的授权，在阿里云上面有一类的云服务，他为了完成某一类功能，需要访问用户在其他服务上面的资源，譬如ECS Workbench，买了ECS实例之后，通过浏览器登录到ECS上SSH的控制台，需要访问ECS来打开webSocket会话，比如像SAS云安全中心，它为了帮助识别网络上的安全风险，需要去访问VPC来查看它的配置情况。

比如DMS是数据库管理的服务，需要去访问RDS来帮助做一些运维管理的操作。再比如云监控cloud monitor, 它为了开启主机监控的功能，它需要在ECS安装监控插件。阿里云在所有的云服务之间，跨服务访问默认是隔离的，如果要完成这样场景下的功能正常工作，需要给服务做授权。如何对服务做授权，先看已经给云监控服务做过授权的账号，服务是怎么执行跨跨服务访问的，当给云监控的服务账号进行授权之后，云账号下面就会有与这个服务相关的服务关联角色出现，云监控服务账号就可以来扮演的服务关联角色，获取STS的token，这是一个临时有效的密钥，在使用STS token来访问ECS实例，去安装监控插件，服务关联角色也就是Service-Linked Role, 简称SLR，目的是为了解决跨服务授权访问的问题，信任与他关联的服务的服务账号，在他的身上绑定预置权限，这个权限允许有云监控在ECS上面安装插件，执行某个命令，这个权限策略是由相关联的服务所定义的，用户不能去修改或者删除这个权限策略，但是用户可以删除服务关联角色。

为了防止误删除，RAM在删除SLR之前检查云服务是否还有资源在使用服务关键角色，如果有用户需要先去删除对应的云服务资源，再来删除服务关联角色。如何给云服务授权，在多数的情况下，当在使用云服务的某项功能时，比如云监控，要去开启主机，监控的功能，云监控会自动创建服务关联角色在账号下，可能疑问既然云服务它可以自动创建，这个还算什么给他授权，来看一下实际的过程。

要开启主机监控的时候，云监控服务它实际上并不能直接创建服务关联角色，它是以用户的一个临时身份，等同于用户的身份调用RAM的接口去创建服务关联角色，所以在这个过程中，RAM会检查原始用户身上是否具有这个权限，如果没有这个权限，云监控也没有办法代替创建角色。所以这就回答个问题，如何授权，只要访问监控服务的用户具备创建服务关联决策权限，云监控服务会自动创建这个角色来完成对服务的授权，这是自动创建的情况，也可以在阿里云的控制台上面主动为某一个云服务创建关联角色这就是对服务的授权。在阿里云上还有一类授权，叫做对STS会话授权，在一个云账号下面，可以创建若干个RAM的用户和角色，但是这个数量是有上限的，比如RAM的用户最多创建5000个，角色数量最多创建1000个，这对于大多数企业内部的身份，不管是人员身份，程序身份可能都够了，但有一类的场景可能无法满足，即移动应用场景，譬如现在都进入移动互联网的时代，手机上都可以装有很多APP，这些一个稍微大一点的应用，可能有几十上百万的用户数量，如果每一个应用的用户都需要以独立的身份来访问阿里云上的某个资源，这种情况下，如果用RAM用户和普通身份就无法满足这种场景。这种情况下，就需要用到STS会话。

STS会话是扮演角色产生的，调用STS的Assume Role接口，指定会话策略，会话的时长，指定RAM角色的ARN信息，可以得到一个STS的token，这个STS token就代表了一个会话，这个会话它也是一个独立的身份，可以去访问云服务，STS会话有两个特征。第一个它的凭证是临时有效的，第二它可以绑定这个会话所特有的权限策略，称之为会话策略，一个会话所拥有的实际的权限是由扮演他的角色上面的权限策略，以及指定的会话策略取交集产生的，STS会话为什么容易满足大规模的身份场景，是因为STS会话它的产生非常的轻量，只要调一个STS的Assume Role就可以产生一个会话的身份，因为这个原因可以用它来解决一个场景，假想需要实现一个移动的应用，会有很多移动的客户端，希望让他能够完成上传图片的这么功能，会选择OSS做图片的存储，如果传统的架构下面，会让移动设备的客户端直接把图片上传到应用服务器，再用应用服务器写入OSS，这也是行得通的，但它会有一个问题，在于应用服务器会存在比较大的流量压力，客户端在高峰时期上来时，服务器就要与之相对应扩展，其实是一个不必要的负担，是否能够让移动设备端直连OSS，不要经过应用服务器去中转图片的流量，当然是可以的，但这会引入两个安全上的问题：

第一个是凭证的安全，客户端如果要去访问OSS的bucket桶，如何把密钥安全的部署到移动端上。

第二个问题是即便能够把这个密钥部署到安全的部署到移动端上，如何能够实现在不同的移动设备的租户之间的权限隔离

这两个问题是需要被解决的。基于前面讲到的STS会话的特点，对架构做稍微的改造，应用服务器它不在作为流量的中转，它只是在客户端登录的时候，为每一个客户端分配一个专属的STS会话，在这个会话上面，通过会话权限策略约束会话所能访问的OSS bucket桶的特定目录，移动设备客户端使用STS token来访问bucket，这就很好的解决了刚刚提到的这两个问题，第一个凭证安全的问题，STS它是临时有效的凭证，可以放心的把这个凭证交流给移动设备端去使用，同时因为会话是权限受控的，即便被其他的用户获取到，也不能够访问不相关的目录，这就是通过STS会话来改造之后给出了架构。

通过视频，来演示一下刚刚提到的架构。使用Python实现了简单的server和一个APP端，其实是用桌面的一个应用来模拟的手机里面的应用，比较简陋。这边先启动服务端进程，登录，第二个部分是为了完成这个角色扮演的过程有哪些配置，RAM这边准备了一个用户，会部署到服务端，用来扮演目标的角色，给他授予STS Assume Role的权限，角色这边准备DEMO的角色，他拥有OSS访问的权限，并且信任这个账号下的子账号去扮演。

OSS配置会创建一个专门的bucket桶，可以看到现在这个桶里面是没有任何的文件，除了hello word.，演示通过客户端登录。使用1001用户登录，登录之后看到服务端给返回了一个STS token，把它显示出来，包括了他的访问的凭证，AKNID secret过期的时间，以及一个很长的一串secret token，这是登录的时候服务端打出来的日志，把本地的某一个文件上传。当这边点了上传之后，就会把图片上传到上面的OSS路径下，显示图片已经上传成功，也进入到OSS的控制台，刷新看到路径已经产生，并且下面上传路径跟刚刚看到的是一样的，演示成功。STS会话是有是有有效期的，他的过期的时间是UTC的3:41，五分钟之后将过期，再演示一下会是什么效果。现在已经过期，再次点上传，OSS会返回token已经过期，这说明的会话是有有效期的。

再来看一下会话的权限隔离性，假设1009ID是一个黑客账号，黑客能改代码，不会按照常规自己传自己的目录，他去传到1001这个目录下，他想去把另外一个图片传到1001这个用户的目录下查看能否完成。点击上传发现OSS拒绝请求，因为在1009这个用户他获取的STS会话上面，他仅仅能够上传到1009对应的OSS目录下，这说明会话策略起到了租户隔离的效果，最后来看一下正面代码，其实非常简单的，首先看一下server代码，Server在login的时候，去办理角色，同时，后续的UID ，把UID作为会话的名称，以及会在权限策略里面约束它所能访问的路径。这是用Python调用STS的一段代码，非常简单。查看客户端的代码，首先是在登录的时候，登录的时候会拿取到服务端反馈给的STS Token的三元组，把它保存在内存里面，并且用这个三元组token初始化OSS的客户端，可以看到整个过程没有长期密钥存在，当点击上传的时候，直接调用OSS客户端把相关的图片加载到内存里面，然后再把它上传到OSS目录下面，这就完成了整个过程。

STS会话其实是阿里云提供的非常棒的一个工具。可以完成很多灵活的东西，包括不只是提到的移动端的场景，还包括跨服务的访问，或者跟一些像OIDC的身份集成，都会用到STS token的方案，但是STS提供这些非常棒的功能的同时，它也是一个利润，使用不当反而会对系统的安全性和稳定性产生负面的影响，根据实际的一些经验，有这四类不当的做法可能会产生影响，比如第一个是明文的传输密钥，会像刚刚架构下面，服务端在给客户端传递STS密钥的时候，它会经过的互联网，如果这个过程没有任何的加密措施，很容易被窃取。第二个是会话期限设置过长，会话一般是15分钟到12个小时，可以由用户自己选定，建议在合理的范围内选择最小的会画有效期，这样的好处是减少密钥被泄露风险，以及一旦泄露之后，可能被黑客利用来造成伤害的时间窗口。

第三个不当的做法可能是大家很容易忽视的，在扮演会话的时候，可能习惯性的不去指定会话的名称，因为STS的接口里面允许指定会话的名称是什么，如果不去指定会话名称，当出现问题需要去查看审计日志，查看当时是谁在访问的时候，就没有办法，建议在扮演的时候，指定一个能够有效代表访问者身份的会话名称，最后一点在于扮演的速率超限，STS Assume Role接口给每个云账号默认配备了100QPS的访问权限，这对于大多数的场景是足够用的，但如果没有注意好这个数据，它一旦被超过，可能导致扮演的操作被拦截，可能对业务的稳定性产生影响。建议首先合理规划调用速率，比如快要达到限额的时候，开始采取措施，第二是尽可能复用token，比如在刚刚提到场景下面，并不是每次要上传的时候去拿一个新的token，而是当用户在登录的时候，就去拿一个token，在他这个有效期内去尽可能去复用它，通过这样的措施，基本上就能够避免掉扮演速率超限。如果在场景下，仍然有可能需要这么大的QPS，同时也是在访问OSS款产品，还有一个备选方案是使用OSS的在URL签名的方案来实现没有这种数据限制更大的方案，这个方案可以在阿里云官网上去搜索来了解。

 

三、多账号管控利器——RD管控策略

第三个话题是在多账号的场景下面，如何用管控策略来实现集中化的权限管控。随着阿里云企业在云上的业务逐渐的扩展，用云的规模越来越大，用云的复杂性也越来越高，企业开始更多去往多账号的模式去转变，因为多账号的模式会带来一些优势，第一个是多个账号它从可以利用账号之间天然的隔离性，包括权限以及一些资源配有的隔离性，来让企业各个部门之间有更好的独立性，以及当有一些大型的企业，它内部可能会有多个法律实体，可以用多账号来解决这些不同的法律实体之间的差异化结算的问题，多账号它可以被用来突破单个账号下面的资源配额的限制，实现更好的水平扩展的能力，使用多账号会带来这样的一些好处，但同时也让企业的管理变得更加的复杂，难以进行集中化的管理，包括对资源生命周期的集中管理，包括对费用账单的集中管理，也包括出于安全合规要求对权限做的集中化的管控，非常推荐多账号模式的用户使用资源目录这款产品，因为它帮助很好的解决了资源费用合规集中管控的问题，以合规管控的场景为例。

资源目录提供了管控策略的功能，企业的管理员账号，它可以创建并维护管控策略，将管控策略附加绑定在企业组织的任何一个节点上，包括单个成员账号，或者是在某一级的组织节点上面，被绑定在某一个组织节点上的管控策略，它会对组织节点下辖的所有成员账号内所有的RAM用户和角色同时生效权限管控，这是基于管控策略就是特点，它非常适合于企业内部进行自上而下top down的事线和规则管控，管控策略是如何参与鉴权的，当身份去访问某一个资源的时候，除了账号内授权的策略，相关的云账号作为企业资源目录的成员账号，以及成员账号上级的所有负节点上绑定的管控策略都会参与进去。RAM会把所有这些权限都取下来，来评估请求的权限是否有效，管控策略每一级上面的管控策略都必须有独立的allow，任何一个层级上面管控策略没有权限，整个请求都会失效。

与此同时，管控策略它不具备对身份进行授权的效果，它只是限定账号内所有身份的权限的边界，实际的授权仍然是需要在账号内对身份进行具体的授权。管控策略它主要的目的是企业用来基于企业内部或者外部，比如行业所制定的一些合规的要求，用它来实现这种事前的安全合规管控的能力，在图中所列举的这6种场景是来自客户的真实的使用场景，使用管控策略来实现比如禁止暴露公网，强制要求加密存储，加密传输等管控的目标，所有这些管控的目标，它大多数都可以描述为强制企业只能以什么方式做，或者禁止企业做什么事情，发现不管是国内还是国外，这些企业越来越重视使用安全合规的方法来应对合规的要求，同时，也更加倾向于用这种系统化，自动化的能力实现持续的合规，而不是靠运动式的方式做合规的整治。

接下来会有三个管控策略事例来看如何实现管控的目标，比如这个事例通过管控策略来限制企业他所能够使用的云服务的范围，以及某些云服务它所能使用的region的范围，比如有些企业他不希望你在海外去开某些节点，或者不希望在国内开某些节点，都可以通过这种方式来实现。这两个策略是用来实现禁止暴露公网可访问的地址。左边是用来限制禁止创建外部可访问的ECS实例，右边是禁止创建外部可访问的OSS Bucket文件。权限策略资源目录的管理员，要把每个成员账号的RAM高位权限进行回收，回收到使用集中化的方式来进行授权管理，比如以其他的方式进行集成。

综上所述，首先介绍了RAM相关的基本原理，包括避免使用root身份，介绍权限策略语言和类型是什么，第二个部分里面介绍了5种典型的授权方式，最后一个部分介绍了在多账号上面怎么进行集中化的权限管控。