本章将共同来探索刚好够用的授权，以及如何在云上实施最小权限原则。如果您恰好已经在使用RAM来管理您企业云上的身份和权限，这里有一些小问题给到您是否能回答。首先第1个问题，您知道阿里云账号内到底一共有多少个RAM用户和RAM角色吗？您知道他们中有多少已经长期闲置不再使用吗？你知道他们中有多少RAM用户和角色拥有他们本不应该拥有的权限吗，如果您刚好使用RAM来和你的企业进行授权。您是如何给您企业的员工和应用程序做初始授权的？您是否有遇到过同事找您没有权限帮加权限这类问题？您是否尝试过实践最小权限原则？实践过程中遇到过什么阻力吗？如果您对以上这些问题存在一些困惑，经过本次的演讲这些困惑就都能得到解答。本次演讲一共有四个部分，首先提出最小权限原则以及面临的挑战；其次，会给出云上最小权限的最佳实践的实施路径，最后会发布RAM访问控制最新的产品能力叫AccessAnalyzer访问分析服务，以及带大家一起来看一下如何使用服务的新的能力识别您账号内身份的过度授权。以及您账号内资源存在的外部访问的情况。

 

一、最小权限原则概述和挑战

最小权限原则它是一个信息安全的原则，也是零信任的安全基石之一。它的核心思想是用户、应用程序以及系统进程应当仅被授予当下完成其工作所必须的最低权限，即不应该给用户或者应用程序授予超过他所需要的权限。最小权限原则的实施有很多好处，比如最小化攻击面，有数据表示，绝大部分的高级攻击行为，它其实都依赖于特权凭证的使用，如果您能够减少您企业拥有特权凭证的这些身份，就可以减少攻击面，还有比如像防止数据泄露、减少人为的误操作。其实经常会听到一些段子，某个企业的一线或者实习生不小心把数据库里面的数据都删了，有没有思考背后为什么这些实习生能够拥有删除数据库内所有资源的权限。

在和客户交流的过程中，收到了很多客户的反馈，有客户反馈是他因为没有管理好企业云上的身份权限，遇到了一些坑，比如有客户反馈有一线的研发同学因为误操作删除了线上的ACK，导致业务故障，还有比如使用了主账号AK，并且AK泄露了，导致企业的一些机密数据被黑客窃取了。企业发现账号内突然间多了好多台ECS服务器，然后把账号内所有的钱都花光了，并且服务器用来挖矿，最后排查发现原来是一个离职的员工，他凭证没有被回收导致的情况，也有一些企业客户分享他实施了最小权限，但是仍然会有一些问题，比如频繁的有公司的员工不停的更新权限，太繁琐了，还有客户反馈是实现了最小权限授权，给每一个客户都设置了独立的策略，这样够精细化，但实际上随着企业员工数量的增长，根本处理不了，管理成本太高，所以错误的实施最小权限，可能会让企业因为承受不了繁琐的工作而过早的放弃。

企业既会有安全的诉求，比如降低安全风险，防止数据泄露，解决管理混乱的问题，也知道企业对效率也有需求，希望企业内部的业务能够快速迭代，能够在企业内部鼓励创新，能够快速的体验新的云服务，比如最近AI非常火，要快速的使用阿里云上的百链，应该能够快速的用起来，所以实施最小权限必须要考虑安全和效率的平衡，如果权限收的越小，企业的研发可能没有办法正常工作，如果权限放的越大，相当于对攻击者敞开了大门。

 

二、云上最小权限的实施路径

云上最小权限的实施路径是一个最佳的实践，这里是一个一维坐标，越往左边权限越大，越往右边权限越小，最小权限并不是一蹴而就的一个过程，不可能第一天能够实践到最小权限，最小权限其实是一个持续迭代的过程，逐渐的把所拥有的权限从大往小做升级迭代，并且它是要持续review和持续迭代的过程。

首先来看一下账号内拥有最大权限的身份是主账号，主账号它其实是拥有账号内所有资源所有操作的权限，最核心的一点是主账号的权限无法被管控，主账号的凭证一旦丢失，没有任何办法管控或者回收。所以非常推荐非必要不要使用主账号，包括主账号登录、主账号的AK，那作为企业的管理员不使用主账号，可以使用拥有admin权限的RAM用户来代替，admin权限RAM用户，照样是拥有账户内所有资源所有操作权限，但是他与主账号不同的一点是他的权限是可以被管控的，假设凭证泄露了，可以快速的把他拥有的权限给他解除掉，及时的降低风险。这里面需要提到不能给所有的员工都授予min权限，这样风险也还是很高的，推荐一定要认真的review到底哪些人应该拥有admin权限，哪些人不应该拥有，而且admin权限的用户数是相对固定的，可能只有企业的一两个核心云上管控人员才会拥有，对于一些非管理员或企业的应用该怎么授权，推荐任何新业务的起点，可以通过授予云服务的FullAccess系统策略来实现初始的授权，比如应用要使用OSS，使用MNS这类云服务，基于所需要的云服务给他授予产品的FullAccess权限，这里面需要注意一定要排除掉，比如像RAM的FullAccess。

RAM有一个提权的能力，它是属于高危的权限，随着在业务初期，授予了FullAccess 是为了快速迭代，随着业务逐渐稳定，是可以逐渐缩小权限，比如某个应用他可能只需要读取OSS Bucket里面的内容，就不需要拥有比如Bucket删除修改的权限，可以把一些产品的部分高危权限做逐渐的回收，同时也可以限制权限的作用范围，比如把权限的生效范围限制到某个资源组，后面会详细的介绍，最终再随着业务更加的稳定，缩小的权限范围，真正的实现仅授予所需要执行的操作，以及仅授予所需要访问的资源的权限，最终实现云上的最小权限，这是给出的一个最佳实践。但大家可能会困惑到底如何把这一套理念或者这套东西应用到实际的业务场景中。接下来一一介绍RAM有哪些产品能力可以帮助到大家，为了让大家更好的贴合的业务，提出按照权限的生命周期为牵引来给大家逐渐的介绍，权限并不是独立存在的，肯定和人员或者应用程序或者资源相结合，人员职责会变化，业务会迭代消亡，所以权限也并非是一成不变的，他也有自己的生命周期。

把权限生命周期分为三个部分，第一个部分是初始的规划，在刚开始的时候如何完成权限初始规划，第二个部分是随着业务的迭代，要做业务支撑，如何给已有的身份增加权限，第三个是要响应安全合规的要求，怎样定期的做权限审计、回收权限。第一部分初始的规划，分别是资源的规划和权限的规划。讲权限为什么要讲资源规划，良好的资源规划是良好的权限划分的基础，因为资源规划就决定了资源的隔离性，从而也就决定了权限的生效范围。如果企业是有强隔离诉求的，那推荐您使用多账号的架构实现业务的资源隔离，比如您企业有很多的不同的业务，或者有很多的子公司，您是希望这些业务或子公司之间的资源是完全隔离的，无论是资源还是身份或者独立结算，您可以使用多账号架构，或者您企业可能要满足一些特殊的合规诉求，您也可以比如对独立的一些账号使用一些合规的手段，也可以使用多账号架构将您企业的不同的业务划分到不同的账号。但企业作为一个集团，他可能又有一些统一的安全的诉求，或者一些安全红线要进行设置，阿里云提供资源目录，这款产品就可以帮助大家实现资源基于多账号的隔离，以及统一的管控，这里是一个企业解决方案提供的规范的或者是建议，一个资源的划分，您可以按照您自己公司的组织关系构建资源层级，可以保证，比如每个不同的产品，它的资源都是在独立的号内的，这样就可以做到完全的物理上的隔离。

同时，企业的it运维同学或者团队可以通过最上层的企业管理账号下发统一的管控诉求，比如日志的统一的收集，一些安全管控策略的统一下发等等。比如您如果没有多账号的诉求，或在某一个具体的业务账号内仍然有很多不同的应用，可以在账号内把资源按照应用来分组，把资源组作为资源的虚拟隔离的边界，举一个具体的例子，比如账号内有两个应用，分别是应用A和应用B，把这两个应用所用的资源分别放到独立的资源组A和资源组B里面，对于一些共享的资源，可以放在一些共享的资源组里面，在给应用A授权的时候，就直接授予了他只能访问资源组A的权限，在授权范围里面选择，如图给应用A研发授予了ECS FullAccess权限，它最终的效果是只能访问资源组A里面的ECS实例，并不能访问资源组B里面的ECS实例，上面同事通过DEMO做了非常详实的介绍。权限的规划，权限描述或者管理的是谁可以访问什么资源。按照权限它的生效的类型不同，可以把它分为基于身份的策略和基于资源的策略两种。

基于身份的策略是权限策略是给到某一个具体的身份身上，用来描述身份可以做什么事情，基于资源的策略是策略是叠加给到某一个资源身上的，描述的是资源可以被谁来访问。大家平时在RAM控制台上接触比较多的都是基于身份的策略，因为这些策略都是授权给具体的RAM身份或者RAM用户或RAM角色，所以先来看左边这一部分基于身份的策略。RAM提供两种类型的技术身份策略，分别是系统策略和自定义策略，系统策略是由阿里云设置，比如给各个云服务都提供了FullAccess和ReadOnlyAccess两个系统策略，系统策略是方便业务实现快速的授权，但因为考虑通用性，所以没有办法实现精细化的管控，如果您希望做一些非常精细化的管控或者您需要做一些符合您具体业务诉求的权限，您可以通过创建自定义策略来完成。

如果您使用自定策略来授权，但又不知道如何开始，在RAM控制台上提供了很多权限的模板。这里列出来了一些是给企业的横向职能团队提供的一些权限模板，比如像为企业的财务管理员，数据库管理员，网络管理员等等做授权，如果您是初始化开始，您可以给您企业的职能角色创建不同的用户组，把这些权限授予给对应的组，把您对应的员工加入到某个用户组内，完成对职能角色的授权。超级用户权限模板，不推荐给过多的RAM用户授予admin权限，但可能企业里面会有一些运维工程师，可能需要访问很多资源，一个个给他授权也很麻烦，您可以使用PowerUserAccess权限模板来给他授权，跟admin的区别是它排除掉了像访问控制，资源目录，企业的财务关系这些高危操作的权限。

第二部分是权限的业务支撑，随着业务的迭代您可能会需要增加权限，如果已知道比如要用一个新的产品，直接给他对应增加，按照刚刚的增加产品FullAccess就好，但肯定会遇到不知道该怎么授权的情况，最核心的是无权限。如果使用过阿里云控制台，肯定会看到过一些权限报错的弹窗，不知道大家是否遇到过，可能明明拥有产品的ullAccess，访问产品控制台仍然给报错，根本不知道缺少什么权限，最近一段时间，很多产品的控制台都做了升级，现在的无权限报错弹窗里面，可以有这样诊断的能力，点诊断就可以告诉您当前到底是缺少什么权限导致的无权限，以及无权限的类型是什么，阿里云有很多的权限类型，您到底是因为具体哪一类的权限导致了无权限，以及会给出一些推荐的解决方案。

如果对于访问者，自己没有办法修改权限策略，还可以把错误的诊断信息分享给您的企业的管理员，管理员可以通过RAM控制里面提供的权限诊断的能力看到更详细的完整的诊断信息，管理员可以为当前账号内所有RAM身份所产生的权限报错的信息进行诊断。不仅仅是控制台的访问，Open API的访问的报错也可以进行诊断，管理员能够看到更详细的信息，比如如图所示的是某一个访问者，他所访问的无权限的原因是因为他被某一条具体的自定义策略显示拒绝，管理员就可以通过查看具体的自定策略来看一下这一次的无权限访问到底是否符合预期，如果不符合预期，管理员就可以进一步对已有的权限策略进。如果要修改，就会涉及到要对自定义的权限策略进行修改的过程，当前有两种自定义权限策略修改的工具，一个是可视化编辑器，另外一个是JSON脚本编辑器，如果您是对权限策略还比较陌生，或您是希望从零开始新创建权限策略，比较推荐通过可视化编辑器的方式，选择对应的一些操作就可以完成，如果您已经是一个老手，或您可能只需要修改原有策略里面的一点内容，可能通过JSON脚本编辑器会更加的方便。

对于各位，如果已经比较熟悉RAM policy的同学，大家可以尝试看一下，左边这段代码里面有哪些错误。答案是有四个错误，第一个是拼写错误，allow拼写有问题，第二个是action字段写错了，Action字段其实应该是用分号来分隔，这里用的是一个点，第三个是SourceIp condition，condition同样的的格式是用一个冒号分隔的两部分，SourceIp它是一个通用的condition，应该加上ACS前缀。第四个是可以看到SourceIp的值，它并不是一个标准的CIDR的方式，对于如果使用自定义策略或通过JSON直接处理权限的这一类场景如何避免这些错误，这些错误都是平时帮客户做问题排查的时候，客户真实写出来的。那为了解决问题，发布Access Analyzer访问分析服务产品提供的第一个能力权限策略检查。权限策略检查能够帮助大家分析权限策略中存在哪些问题，并且把它分成四类，第一类是错误Error类型，这个类型的问题是会影响权限策略实际生效，这一类问题推荐一定要修改，否则您所授予的权限可能不符合您的预期。第二个类型是安全警告类，这一类的问题可能并不会影响策略的实际生效，但是会带来一些安全隐患，比如过于宽松的授权。第三类是警告类型，也就是策略内容不符合推荐的一些最佳实践，比如一些格式的错误等等，第四类是建议，他不会实际影响策略的生效，但是可以建议做一些优化。

这些功能实际上在RAM控制台上已经可以使用了，它其实在JSON脚本编辑器的模式下是可以体验的，把刚刚让大家纠错的那段代码复制进去，可以清晰的标识出来当前存在的哪些错误，并且明确指出错误的原因是什么，您应该如何来进行修改。第三个阶段是权限的收敛。会有两部分内容，一个是识别身份的控制授权，一个是识别资源的跨账号访问，业界有一个概念叫做权限的蔓延，指的是随着时间的推移，用户或应用程序获得的权限会逐渐的增加，最终超出他最初所需要的权限范围。左边图可以很直观的表现情况，图的横坐标是时间，纵坐标是拥有的权限数量。上面这条曲线用来描述身份可能被授予的权限，它随着时间的推移，它是会逐渐增加的，下面这条曲线描述的是身份实际使用的权限，其中的差值就是过度授权，会给大家一种感觉，过度授权的量其实还挺大的，其实并不是杜撰出来的，最新的数据提供的2024年报告指出有98%被授予的权限，实际上是没有被使用过的，值其实也是非常令人吃惊的，竟然有这么大比例的权限都是过度的授权。

发生过度授权或者权限蔓延的原因是什么？随着系统功能的变化、人员职责的变化或者一些临时的权限提升，都会导致权限的显著的增加，但因为缺乏权限审计，这会导致权限实际上没有被回收，所以导致差值越来越大，如何来解决权限蔓延带来的风险？比如现在都知道权限过度授权有很多风险，如果您企业的安全团队要求您现在回收权限，相信可能困惑之一是怎么知道要收敛哪些用户的哪些权限。

为了解决问题，推出了权限审计功能，功能在RAM控制台上线已经有一段时间，今天也是第一次正式给大家做介绍。权限审计功能是为了帮助您识别RAM身份到底拥有什么权限，其中哪些权限被使用过，使用这些权限最近的一次时间是什么，权限审计由三部分的能力组成，第一个会用RAM身份授予的信息来做分析，对于RAM用户，他的授权信息包括直接给他授予的权限，以及他从用户组上继承来的权限，对于RAM角色来，就是直接授予RAM角色的权限，可以给一个RAM的身份attach很多policy，但最终这些policy组合身上的结果到底是什么？权限审计提供的是分析能力，他是通过什么来分析？中间内部实现了策略分析服务，是用形式化的证明以及一些算法能够计算出来，多个权限的叠加之后，实际的生效范围是什么。那第三部分是会用到操作审计的日志，所有RAM的身份论是在控制台还是CLI, 还是通过open API执行调用和调用API的时候，背后都是会把所有控制平面的操作都是会审计下来，通过调用审计日志的信息，可以提供某一个身份访问某一个权限他的最近使用时间，这里给出来的是控制台上权限审计能力的一些界面，能力现在是在控制台的RAM用户详情页和RAM角色详情页，可以看到当前已经支持100多款服务访问审计的分析，可以看到当前身份拥有这么多服务的权限，以及这些权限都是通过哪些policy被授予的，以及对服务的最近访问时间是什么。对于五款核心服务，还支持能够具体看他每一个操作或者他每一个API的访问记录是什么。

 

三、使用AccessAnalyzer识别过度授权

刚刚提到权限审计能力，提供的是单个RAM用户或者整个RAM角色，权限的使用情况，其实企业有时候是希望有一个集中的更全面的视角来看整个企业或者多账号内到底有多少个RAM的身份存在过度授权，因此接下来会为大家介绍，Access Analyzer访问分析服务的第二个能力——识别过度授权。您只需要创建一个访问分析器，之后访问分析器就会持续的扫描您账号内，或者是您的整个企业的所有账号内的所有的RAM用户和RAM角色，并且来分析他所保有的权限的情况，以及他对权限的使用的情况，最终会产出这四类的分析结果：

第一类的分析结果是超级管理员，超级管理员就是拥有admin权限的身份。推荐您一定要详细的确认这些身份是否应该拥有admin权限，如果应该拥有admin权限，一定要加上MFA多因素认证来保障凭证的安全性。

第二类的分析结果是特权身份，特权指的是RAM的一些高危权限，可以给任意的一个身份做提权，这一类身份的凭证如果被泄露了，风险是很高的，可以给任何一个普通的用户，直接授予admin权限，让他变成超级管理员，对于拥有特权身份的用户，建议一定要控制人数，并且确认真的需要有权限再授权。

第三类分析的结果是不活跃的身份，不活跃的身份是指在创建访问分析器的时候，会让您选择一个统计周期，比如您可以选择90天或120天，或最高到180天，那如果在统计周期内，比如180天时间内，某一个RAM身份都没有任何的访问记录，或权限的访问记录，会认为身份是一个不活跃的身份，建议对于长期不活跃的身份，应该将身份进行禁用或者删除，来避免身份泄露带来的危害。

第四类是过度授权的身份，含义是在统计周期内使用过权限的，但是它保有一些他本不应该拥有的权限，或者他拥有一些权限没有被使用，属于过度授权的身份，推荐对于活跃且过度授权的身份，做一些适当的权限的收敛，减少过度拥有的权限。识别过度授权，首先会提供整体的可视化的数据概览，可以展示出所有的分析结果每一类的用户和角色分别有多少，以及他当前的占比的情况。如果您创建的分析器的分析范围是资源目录，还会额外提供一个报表，用来展示在资源目录内待处理的分析结果最多的5个用户。

具体的详情可以看到结果列表页，有非常具体的信息，比如到底是哪一些资源，所处的分析结果是哪种类型，包括保有了多少个服务的权限，但实际使用了多少个服务的权限。进入到详情里面，展示的是一个过度授权的用户的详情页，看到用户的一些身份信息、创建时间、最后访问时间、他所拥有的服务、已经访问的服务以及这些服务的详情都在下面都可以直观的看到。

访问分析服务还支持和event bridge, 事件总件产品做集成，任何访问分析服务产生的新的分析结果，都可以通过event bridge产生这样的事件，可以基于监听事件来做对应的一些操作。举个例子，为了识别异常新增的管理员，攻击案例如果一个黑客或一个攻击者拿到了账号企业内的一把泄露的AK之后，他不会用这一把泄露的AK直接干坏事，因为目标太明显，他做的第一个事情是尝试用这把AK创建一个新的RAM用户，给新的RAM用户创建他的AK，并且给新的RAM用户授予admin权限。为了识别情况，可以在企业整个管理账号里面创建RAM分析器，一旦监测到会有新的管理员的身份被创建出来了，会立刻产生事件总件，通过比如一些消息服务通知到团队的运维同学，运维同学就可以立刻执行异常的处理，可以避免悄无声息的账号里面多了高危的身份。

基于身份的策略、初始化如何给身份授权、如何基于权限报错来给身份增加权限、如何识别身份是否存在一些闲置的权限、如何给他做权限的回收。那接下来分享基于资源的策略，基于资源的策略它是授予给资源身上的，可以实现谁可以来访问资源，对于调用者以及资源在同一个账号内的情况，既可以使用基于身份的策略来完成授权，也可以使用基于资源的策略来完成授权。右边这张图是在同账号的情况下，权限生效范围是它两者的一个并集，在没有显示拒绝的时候，可以通过任意一方完成授权的动作。但在跨账号的场景就不同，跨账号是指身份在一个账号内，资源在另外一个账号内，在默认的情况下，阿里云有租户隔离机制，一个身份只能访问当前账号内的资源，但是在主动授权的情况下，通过基于资源的策略可以实现跨账号的授权，首先在下面账号内给OSS Bucket授予了权限策略，在上面一个账号内对某一个RAM用户授予了权限策略，必须要两边都有权限，这样就可以实现跨账号的访问。

酒店房间里面还有一扇门，门是可以通往隔壁的客房，门在业界是叫客房联通门，它的存在意义是为了方便您，比如您的家庭或者您跟您的朋友住在一起可以方便联通，如果您只订一间房那个门是打不开的，或者打开了也没有办法访问隔壁房间的，必须要求两个房间的门都打开，才能构建连通性，跨账号也是一样的，两边都需要授权，最终策略才能够生成，访问才能够生效，通过例子知道基于资源的策略可以实现跨账号的访问，对于在企业内或给供应商做授权的时候，是非常方便的，比如是Bucket的拥有者，可能想把某些资源共享给另外一个账号，可以直接通过这些资源策略，不需要在当前账号内再创建身份给供应商使用，但是这里面可能也会带来风险，如果策略写错了，本来要共享给A，但实际上共享给了B，共享给了其他人。带着这个问题来推出发布的Access Analyzer第三个能力识别跨账号访问。

 

四、使用AccessAnalyzer识别外部访问

假设你是账号1 OSS Bucket的管理者，本来想写一条策略，把Bucket共享给账号2的，但是误操作，错把共享的对象设置成了新，所有人都可以来访问Bucket。识别快账号访问的功能就是为了解决问题，只需要在您的账号内创建访问分析器，访问分析器就会持续的监测您账号内基于资源的这些策略，判断它是否存在跨账号的访问。如果判定存在，就会生成一条warning，或者生成一个分析的结果。功能可以设置支持设置信任的区域，可以选择当前账号或整个资源目录，如果您选择的是当前账号，只要资源共享给了账号外的身份，就认为是跨账号，如果您选择的是当前资源目录，如果资源共享给了当前资源目录的身份，认为不是跨账号，如果共享给了资源目录之外的账号，那就是跨账号的行为。

当前的能力支持两个资源的识别，一个是OSS Bucket，另外一个是RAM的角色，因为这两个都是非常典型的支持基于资源的策略的产品。会持续的监测资源的变化，实时的产出结果，可以基于分析结果修改非预期的授权行为。这里也给出来具体的跨账号访问的分析截图，可以看到分析的对象是OSS Bucket，被设置成了公开访问，任何甚至匿名用户都可以访问Bucket，允许访问Bucket操作，因为是通过ACL来实现公开访问，所以意味着任何人都可以对Bucket执行公共读操作。举一个具体的例子讲一下整个功能的应用场景，录了一小段DEMO，先给大家介绍整个解决方案的实现，场景是为了识别OSS Bucket存在公开访问的情况，并且利用函数计算做自动的修复。任何情况下都不应该把OSS Bucket设置成公开访问，因为它会带来很大的风险。在企业的管理账号内创建RAM访问分析服务，会持续的监测整个企业所有业务账号内OSS Bucket, 一旦识别到某一个OSS Bucket被开启了公开访问，它就会产生一条分析的结果，分析结果会通过事件总件来触发函数计算服务，由函数计算服务执行开启OSS主旨公共访问的这样开关，来实现修复，这是整个解决方案的调用顺序。

接下来看一下具体的DEMO，DEMO在多账号下做演示，可以看到这里面有两个浏览器tab，橙色的是企业管理账号，绿色的代表企业的业务账号。首先通过云SSO登录企业管理账号。进入到RAM控制台，可以看到提前已经创建好了分析器，它的类型是外部访问，它的分析范围是资源目录。进到分析详情里面，可以看到待处理的分析结果，当前是没有任何待处理分析结果。接下来进到函数计算的控制台，可以看到提前创建好了一个函数。它的作用是用来开启阻止OSS公共访问开关，这是OSS提供的产品能力，函数可以看到它是由event bridge来触发的，具体的详情可以看到它识别OSS Bucket存在的公开访问的情况。切换到业务账号，在业务账号里面创建一个不合规的OSS Bucket。创建一个Bucket，为了演示，把阻止公共访问选项给关掉。

Bucket创建好之后，会通过Bucket policy来实现公开访问的能力，选中对所有账号开启OSS Bucket读的权限。再切换到企业管理账号，刷新就可以看到新产生一条分析结果，他的对象就是刚刚创建的Bucket。详情识别出来Bucket是可被公共访问的。再到函数里面看到刚刚设置的函数产生了一条新的调用日志，可以知道问题已经被自动的修复，业务账号里面阻止公共房的开关已经被打开。切换管理账号看一下分析结果，之前待处理的分析结果已经得到了解决。

综上所述，首先提到了实践最小权限的好处以及挑战，最小权限是可以提升安全性，减少攻击面，但也需要考虑安全和效率的平衡，第二点提出了最小权限的实施路径，最小权限并不是一蹴而就的，而是需要持续的迭代逐渐的缩小权限范围。按照项目初始阶段的权限规划，如何做资源的规划，基于资源的规划、资源的隔离做权限的规划，然后讲了随着项目逐渐进入到稳定期，如何做一些新的权限的授予，如何使用权限策略检查能力，检查policy是否正确符合预期。然后分享了权限的定期审计、定期回收，怎样使用权限审计能力以及访问分析的能力回收权限，处理异常的情况，最后介绍了资源的非预期共享的情况，如何使用策略分析服务来识别非预期的跨账号共享。上面提到的所有功能，在RAM控制台上都已经上线了，欢迎大家试用与交流。