引言：本文整理自【弹性计算技术公开课——ECS安全季】系列课程中，阿里云弹性计算高级技术专家张振华带来的课程《如何安全访问和管理ECS资源》一节。
一、身份与访问控制的基本概念
首先给大家介绍一下关于身份与访问控制的一些基本概念。
身份与访问控制是为了实现集中管理阿里云上的用户身份，只有通过这个身份的认证，并且满足了特定权限授权条件下的用户才能够访问或者操作您所指定的阿里云资源，避免您的云资源被未经授权的用户恶意访问，所以这里会涉及到三个管理系统，分别是身份管理、权限管理以及资源管理。
所谓身份管理，就是您如何管理您的企业员工或者应用的身份。权限管理是您要怎样分配权限，比如管理员可以拥有全部的访问权限，而研发人员根据自己的职责范围，只能在特定的网络环境下操作有限的云资源，一般建议遵循最小够用的原则来给员工进行授权。资源管理是您要怎样管理云上的资源，建立的管理方式是按照部门或者是业务线划分到不同的资源组，只有被授权可以访问资源组的用户身份，才可以操作对应的云资源。这里的云资源，不仅仅是ECS的资源，也包括网络资源，比如VPC，也包括存储资源，比如OSS、对象存储以及日志服务，同样也包括像数据库、云原生的容器等各种各样的云资源。
在阿里云上面，我们统一负责用户身份管理和访问控制的服务，称为RAM，它的全称是Resource Access Manager，即资源访问控制，RAM有主账号和子用户RAM账号这两个概念，这两种账号，都可以通过用户名、密码登录到阿里云的控制台，并对其云上的资源进行操作。用户在访问阿里云账号时，使用的是主账号，主账号的密码规范、登录安全的风险控制策略是由阿里云统一管理的。在主账号下的子用户，即通常所说的RAM用户，它的密码策略则可以由客户自己设定，比如密码字符的组合规范、重试登录次数、密码轮转周期等策略。
管理员可以通过RAM控制台为RAM用户创建密码策略，来保证各个子用户都可以使用定期轮转的强密码，从而提高整体账户的安全性。RAM服务使得一个阿里云主账号可以拥有多个独立的RAM用户，从而避免与其他用户共享云账号的密钥，并可以根据最小权限的原则为不同用户分配最小的工作权限，从而降低用户的信息安全的管理风险。RAM的策略可以细化到针对某一个API、Action或者Resource ID等最细粒度的授权，还可以支持多种的限制条件，比如像限制来源IP的访问范围，安全访问的通道，比如必须要通过SSL或者TLS，还有访问的时间段或者是MFA的多因素的认证等等。
RAM是阿里云账号安全管理和安全运维的基础，通过RAM可以为每个RAM用户分配不同的密码或API访问密钥（Access Key），消除云账号共享带来的安全风险；同时可为不同的RAM用户分配不同的工作权限，大大降低了因用户权限过大带来的风险。
一般来说，企业的管理者或者运维主管往往会成为阿里云上的主账号拥有者，也就是超级管理员。
1.我们建议由超级管理员根据组织实体或业务场景，创建不同的RAM用户、RAM用户组，并为每个用户分配唯一的安全凭证AK。
2.控制授予每个用户、用户组对ECS资源授予不同的操作权限，根据最小权限原则，分权管理不同的资源，降低信息泄露风险。
3.更进一步，可以将RAM角色关联到ECS实例上，不同的实例赋予不同授权策略，这样就无需在实例中保存Access Key，使它们对不同的云资源具有不同的访问权限，实现更精细粒度的权限控制。
接下来展开介绍一下ECS的身份管理、权限管理以及如何避免显示的AK配置的一个最佳实践。
二、身份管理的安全治理原则与验证手段
首先介绍一下身份管理中的安全治理原则和验证手段，以及基本概念，并且分别介绍RAM用户和RAM角色的相同点和不同点，接下来是关于身份管理安全的治理原则，还有安全的验证手段。
什么是身份认证？身份认证指的是通过凭证信息来认证用户的真实身份。
它通常是指通过登陆密码或访问密钥，也就是AccessKey机制来进行身份认证。请注意，用于身份认证的凭证信息对于用户来说是敏感的秘密信息，用户必须妥善保护好身份凭证信息的安全。
阿里云提供多种多样的身份认证能力，总体上可以分成是面向用户或企业员工的认证手段，还有面向应用程序的认证手段这两大类。
第一大类是面向用户的认证方式有，账号密码认证、SSH密码认证、基于MFA验证码的认证（比如人脸、短信、短时口令等）和SSO单点登录认证。
- 账号密码认证相信大家都不陌生：用户可以使用其云账号（即主账号）或其云账号下RAM用户的密码登录阿里云控制台并对其云上资源进行操作。阿里云的账号密码规范、登录安全风控策略由阿里云统一管理。云账号下子用户（RAM用户）的密码策略则可以由客户自己设定，如密码字符组合规范、重试登录次数、密码轮转周期等策略。例如，用户可以通过RAM控制台为RAM用户创建密码策略，以保证各个子用户都使用定期轮转的强密码从而提高整体账户的安全性。
- SSH密码认证也是常用的非对称密钥认证机制。针对ECS Linux实例，如果用户已经将SSH公钥配置在Linux实例中，那么在本地或者另外一个实例中，用户可以使用SSH私钥通过SSH命令或相关工具登录之前有公钥配置的实例，而不需要输入密码。SSH密钥对默认采用RSA 2048位的加密方式，相较于传统的用户名和密码认证方式，SSH密钥对登录认证更为安全可靠，同时便于远程登录大量Linux实例。同时，阿里云容器服务也支持通过 SSH 密钥对的方式远程登录集群。
- MFA是一种简单有效的最佳安全实践方法，它能够在用户名和密码之外再额外增加一层安全保护。启用MFA后，用户登录阿里云时，系统将要求输入用户名和密码（第一安全要素），然后要求输入来自其MFA设备的可变验证码（第二安全要素）。这些多重要素结合起来将为用户的账户提供更高的安全保护。阿里云可以支持基于软件的虚拟MFA设备。虚拟MFA设备是产生一个6位数字认证码的应用程序，它遵循基于时间的一次性密码（TOTP）标准（RFC6238）。
- 同时，阿里云也支持基于SAML 2.0的单点登录（Single Sign On，简称SSO），可以支持企业客户使用企业自有身份系统的登录服务登录访问阿里云。为了满足不同企业客户的登录场景需求，阿里云提供了以下两种基于SAML 2.0协议的SSO机制：
- 用户SSO：阿里云通过身份提供商IdP颁发的SAML 断言（SAML Assertion）确定企业用户与阿里云RAM用户的对应关系。企业用户登录后，使用该RAM用户访问阿里云资源，对应的访问权限由RAM用户的授权策略所限制。
- 角色SSO：阿里云通过身份提供商IdP颁发的SAML断言（SAML Assertion）确定企业用户在阿里云上可以使用的RAM角色。企业用户登录后，使用SAML断言中指定的RAM角色访问阿里云资源，对应的访问权限由RAM角色的授权策略所限制。
第二大类是面向应用程序的认证方式，主要有AccessKey认证和STS认证两种。其中AccessKey是用户调用云服务API的身份凭证，用于在用户通过API访问阿里云资源时对用户身份进行认证。API凭证相当于登录密码，只是使用场景不同。前者用于程序方式调用云服务API，而后者用于登录控制台。
- Access Key包括访问密钥ID（AK ID）和秘密访问密钥（AK Secret）。AK ID用于标识用户，而AK Secret用来验证用户身份的合法性。用户在调用资源时会传入AK ID，并使用AK Secret对请求进行签名（HMAC-SHA1算法）。用户可以登录阿里云用户中心或RAM控制台来管理Access Key，包括创建、冻结、激活和删除操作。Access Key是可以长期使用的API访问密钥，建议用户在使用时要考虑对Access Key的周期性轮转。请注意，出于有效权限分割和降低风险的考虑，云上最佳安全实践中不建议用户为其云账号（即主账号）创建AK凭证，而建议为其下属的RAM用户各自创建AK凭证。建议RAM用户更多的使用STS临时token，而不是使用长期使用的永久AK。
- 阿里云Security Token Service（STS）是为RAM用户、阿里云服务、身份提供商等受信实体提供短期访问资源的权限凭证的云服务。有时存在一些用户（人或应用程序），他们并不经常访问客户云账号下的云资源，只是偶尔需要访问一次，这些用户可以被称为“临时用户”；还有些用户，例如运行在不可信移动设备上的App，由于自身安全性不可控，不适合颁发长期有效的访问密钥。这些情况下，可以通过STS来为这些用户颁发临时权限凭证。颁发令牌时，管理员可以根据需要来定义令牌的权限和自动过期时间（默认为1小时过期）。STS访问令牌是一个三元组，它包括一个安全令牌（Security Token）、一个访问密钥 ID （Access Key ID） 和一个秘密访问密钥 （Access Key Secret）。用户在调用资源API时传入安全令牌和访问密钥ID，并使用秘密访问密钥对请求进行签名（和上述AK签名机制相同）。
在通过身份认证后，RAM实际上会生成两类的身份，一类是实体身份，比如RAM用户、RAM用户组，另一类是虚拟身份，也就是RAM角色，那这两者有什么相同和不同点呢？
首先，RAM用户和RAM角色都是RAM中定义的身份，前者是实体身份，代表人或者程序，而后者是一种虚拟身份，往往需要被实体用户扮演才能生效。无论是RAM用户和RAM角色在被授予权限后都可以直接访问资源，也可以通过 SSO 和企业 IdP 互联。
不同点在于：
1. RAM用户有确定的登录密码和访问密钥，可以支持控制台登录，享有登录凭证；
2. RAM用户可以被加入RAM用户组，从而继承用户组的权限，RAM用户组就是用来划分一组职责相同的RAM用户，因此可以被赋予一组同样的权限策略；
3. RAM用户可以对应企业内的人员、应用等，在需要协同使用资源的场景中，避免直接共享阿里云账号的密码等机密信息，缩小机密信息的可见范围，并为RAM用户和RAM用户组赋予最小权限，即使不慎泄露机密信息，也不会危及阿里云账号下的所有资源。
而RAM角色虽然有确定的虚拟身份，也可以被赋予一组权限策略，但是没有确定的登录密码或访问密钥。RAM角色需要由一个受信的实体扮演，该实体在扮演RAM角色时即获得RAM角色的权限。在云产品通信的场景中，为受信的实体（例如ECS实例）绑定RAM角色后，该实体可以基于STS（Security Token Service）临时凭证访问其他云产品的API，避免将AccessKey写在配置文件中等高危操作，保证AccessKey的安全。
企业在云上的身份和AK的管理中，常见的风险往往是因为账号或者是AK的管理或使用不善，会导致AK的安全的风险敞口会变大，甚至是AK的泄露，从而导致了一些安全的隐患，因为用户名的密码的泄露或者是AK泄露所造成的危害，也备受企业的关注，这里列举了一些常见的安全风险，这里可以分成两类。
第一类是人员管理上的风险，第二类是AK管理上的风险，在人员的管理上常见的风险，第一是使用了主账号进行日常运维和管理的操作，第二是存在多人共享一个RAM用户，这样会影响审计信息，第三是控制台的用户，没有和企业的账号打通，由于员工的离职之后，一些数据没有和企业内部账号的信息进行同步，第四种是高权限的用户且没有配置好MFA，登录的IP的白名单等安全的设置，会有一些高危的用户登录的风险，最后一种，是存在长期不使用的僵尸用户，扩大了风险的敞口。
AK管理的风险主要有，一般是经常会使用主账号的AK，在主账号AK如果一旦泄露了，止血的成本就非常的高昂。第二类是在代码中的硬编码的AK，从而容易从ECS的镜像OSS文件或者是一些外部的公开的渠道上面把AK泄露出去，第三种是存在的人和程序混用RAM用户而造成了AK被误删的这种场景，第四种是存在AK长期不轮转，造成了风险的累积。还有一种是客户端的代码中包含了永久AK，这也是非常容易泄露的。
为此我们给出了五个身份安全治理的原则和建议：
- 原则一是不推荐您使用主账号的AK。因为主账号AK拥有的是超级权限，一旦泄漏后的风险极高，而且主账号AK不支持精细化的授权，也不支持临时授权和白名单控制。我们推荐您开启主账号MFA的多因子认证来增强主账号的安全性，通过云安全中心提供的AK泄漏扫描能力来检查自身环境是否使用了主账号AK。
- 原则二是区分人员和程序的RAM身份。人员不应启用AK，控制台子用户不应该拿到AK，可以使用SSO实现统一认证登录。而程序应该与子AK一一对应，并且关闭程序子AK的控制台登录能力。
- 原则三是合理的授权，比如客户端或测试开发环境使用临时Token，而不是永久AK，定期清理长期不使用RAM子用户。
- 原则四是安全合理的使用永久AK，至少可以定期巡检&报警，开启AK白名单、限制白名单访问来源IP，避免明文编码AK，避免将AK暴露到外部公共平台上，以及实现AK加密和集中化管理。
- 原则五是尽可能的实现无AK的使用，比如我们可以定义ECS实例的RAM角色，授权给某个ECS，实现权限精细化控制和管理，并且过程中无需明文的保存AK信息。
RAM访问控制服务允许企业对主账号内的身份安全做整体性的安全控制，比如密码强度的设置策略会对主账号下所有的RAM用户生效，用户的安全设置也允许设置MFA的多因素的认证与设置允许控制台登录的来源的IP的掩码，以及是否允许RAM用户自主管理密码和MFA的设备等等。
这里推荐您免费开通RAM访问控制服务提供的身份权限治理服务，当您开通了身份权限治理服务功能之后，RAM会持续的检测阿里云账号及其下的RAM用户是否存在身份权限的安全风险，帮助您及时发现治理上的缺失，并提供友好的治理引导，帮助您完善云上身份权限治理的配置，身份权限治理服务的检测项，包含了AccessKey管理检测，RAM用户管理检测，密码强度和MFA管理检测，安全使用的建议，以及高危权限的管理，还有细粒度的权限管理和授权效率的建议等等。
具体来说，您需要使用阿里云的账号或者是具有管理权限的RAM用户登录到RAM的控制台，在左侧的导航栏中点击概览，在概览页的标签页下面选择治理检测，可以查看身份权限的治理的检测数据。单击下载报告，可以下载检测的数据到本地进行查看，可以按照报告中介绍的治理方案，在控制台完成身份权限的治理。
小结：在身份管理这一部分，我们介绍了什么是身份认证，阿里云提供了多种多样的面向用户和应用程序的认证手段，在通过身份认证之后，RAM其实会生成两类的身份，一类是实体身份，我们称为RAM用户，另一类的是虚拟身份，也就是RAM角色。
我们对比了两者的相同点和不同点，介绍了在身份管理里面的一些安全的风险，安全治理的原则以及阿里云建议的一些最佳实践。
您通过RAM访问控制服务来设置企业用户整体的安全性是最常见的治理手段，另外也建议您开通免费的身份权限治理服务，阿里云可以帮助您及时发现治理缺失的漏洞，并提供友好的治理引导，帮助您完善云上的身份权限治理的配置。
三、权限管理的策略与授权案例
接下来介绍关于权限管理的策略和授权案例。首先先介绍一下访问控制的实现原理，介绍如何给身份进行授权，特别是关于ECS授权的一些基本的案例。接下来会介绍一些高阶的授权能力，比如可以基于资源组进行访问控制和资源的管理，也可以使用标签进行资源管理，最后介绍操作审计。
访问控制是管理资源访问权限的服务。它不仅提供了多种满足日常运维人员职责所需要的系统权限策略。也允许您通过图形化工具快速地创建自定义的用户权限策略。
1. 它可以根据请求特征，比如请求源IP地址、日期时间、资源标签等条件属性匹配精细的资源访问控制策略。
2. 也支持根据RAM用户或RAM角色的身份特征，判断其是否在资源维度和操作维度是否有访问权限。
3. 也支持根据资源特征，比如资源是否在指定资源组中，判断RAM用户或RAM角色是否有访问权限。
当您的企业存在多用户协同操作资源的场景时，RAM可以让您避免与其他用户共享阿里云账号密钥，按需为用户分配最小权限，从而降低企业的信息安全风险。
RAM访问控制支持控制台、SDK、OpenAPI、阿里云CLI命令行等多种方式的调用，因此也是非常方便的。
如何给身份进行授权？默认情况下，阿里云的主账号控制了资源的所有权限，主账号创建出来的RAM用户是默认没有任何权限的，因此需要通过授权的方式给RAM用户赋予权限，用户的授权会分为两个步骤。
首先需要新建一组权限的策略，给RAM主体绑定权限的策略。权限策略也叫做policy，就是用一组语法结构去描述一组权限的集合，目前支持两种的权限策略，分别是阿里云维护的系统策略和用户自定义的权限策略，系统策略，用户是只能使用而不能够修改，是由阿里云来进行维护。用户的自定义策略，用户就可以通过可见化可视化的编辑器，包括权限策略的脚本编辑器，以及权限策略的模板等多种方式，进行自主的创建，更新和删除。
第二步是为RAM的主体进行授权，也就叫做attach policy，attach policy是给RAM用户或者用户组或者角色，绑定一个或者是多个的权限策略，他的授权范围可以是整个云账号的资源也可以是指在云账号下指定的一个资源组内的资源，绑定的权限策略，可以是系统策略，也可以是自定义的策略，如果绑定的权限策略被更新了，更新之后的权限策略就会自动生效，而无需要再重新绑定这个权限策略。
为了方便您使用，ECS已经预定了一些系统策略来方便您在日常的管理中快速的为RAM用户，RAM用户组或者是RAM角色去添加这些权限的策略。这里面包含了ECS管理员的权限，ECS只读的权限，管理弹性网卡的权限，下发云助手命令或者是只读云助手信息导入导出ECS实例镜像等权限。
这里我们举一个在企业内部控制员工资源使用权限的案例。
首先，企业的管理员可以按需创建和管理资源的职位，来创建一个SysAdmins的用户组，添加权限策略，并授予执行所有操作的权限，管理员需要严格的控制高权限的人数，并且给管理员去开启MFA登录。
管理员可以为需要使用的资源的职位创建Developers用户组，为开发人员创建相应的RAM用户，并按照各自用各自的职位加入到不同的用户组，根据研发的自定义，管理员可以根据最小够用的权限策略的原则去授予开发人员，去调用StarInstance、StopInstance、DescribeInstancestar 等ECS最基本的功能接口的权限，如果为了加强网络的安全控制，管理员可以添加这网络相关的权限策略，规定比如组内的用户的IP如果不是来自于企业网络内部，则拒绝其访问资源。如果某一个开发人员的职位，变更为系统管理员，就可以将其RAM的用户从Developers用户组移动到SysAdmins用户组，如果Developers用户组的RAM用户，需要更大的权限，修改用户组的权限策略就可以应用到用户组里面所有的RAM用户。
对于云产品，比如ECS实例，可以给特定的ECS实例绑定RAM角色，基于STS临时访问凭证去访问其他的云产品，在阿里云上是可以实现这样一组策略。
再来举另外一个例子，也是为不同的职责的人员去授予不同的权限，其实可以根据企业的实际情况，给更多的角色分配更多的更细粒度的权限策略，这里既可以是系统的策略，也可以根据实际情况去自定义一些访问的策略，比如这里分成了云管理员，系统管理员，网络管理员，安全管理员，财务还有开发人员等各种各样的角色。他们的角色的访问策略就可以由您自己去管理。
接下来学习一些权限控制的高阶用法，首先是基于资源组的细粒度资源管理和访问控制，资源组其实是根据资源的用途，权限，归属等维度，对您所拥有的云资源可以进行分组，从而实现企业内部多用户、多项目的资源的分级管理，每个云资源目前只能属于一个资源组，加入到资源组，它不会改变云资源间的关联关系，比如可以按照云资源的用途来进行分组，将生产环境的实例和测试环境的实例，分别放入到生产环境和测试环境的两个资源组中。
在产品测试的时候，只对测试环境内的资源组进行实际的操作，从而避免对生产环境的实例发生误操作，在产品需要上线的时候，再选择生产环境的资源组装的实例进行操作，也可以按公司不同的部门使用的资源放入到多个不同的资源组中，并且设置相应的管理员，从而实现分部门的管理实例。
这里举某个游戏公司项目开发的真实案例，某个游戏公司在并行开发三个游戏项目，每个项目都会用到多种云资源，公司是要求项目要能够独立管理，项目的人员也只能访问到它所在项目的资源，这时候就可以基于资源组来实现RAM的访问控制。
基于资源组的访问控制具体应该怎么做？首先可以由企业的管理员分别给三个项目创建三个不同的资源组，并且把每个项目所用的独立资源放入到对应的资源组中。在资源管理页找到资源组，创建出资源组，点击资源组内，再点击转入资源，就可以将云产品对应的资源转入到资源组内。第二步是企业的管理员给项目人员创建RAM用户，给RAM用户在资源组内授予ECS的相关的一些权限，这样RAM用户就可以访问本项目内的ECS资源，但无法访问其他项目的ECS资源。
除了使用资源组外，也可以使用标签来划分不同的资源，相比于资源组，标签是一种更加灵活的资源划分维度或者工具，比如可以按照地区、部门、环境分别给资源打上多个标签，同一个资源可以支持多个标签。如果从资源视角来看，可以把资源分成各个云产品，比如有ECS计算资源，有OSS存储资源，有VPC网络资源，从标签的视角，就可以更加贴近于用户的视角，可以把资源按照地区或者是部门或者是环境等多个维度来进行区分，在此基础上，可以基于标签来实现访问的控制。
通过标签来进行RAM用户的健全的访问控制的原理如左图所示，首先是由云管理员使用阿里云的主账号新建一个自定义的策略，在策略中，可以指定带有特定的RequestTag，或者是特定的ResourceTag，RequestTag是意味着RAM用户在发起请求的时候必须要传入特定的Request标签，比如在创建资源时传入这个标签，就会给ECS实例自动打上Request的标签，而ResourceTag标签就意味着RAM用户要访问的资源本身必须包含特定的Resource的标签。
在阿里云的主账号创建好自定义策略之后，将自定义策略授予给RAM用户，预期的结果就是RAM用户只能按照标签匹配的条件来访问ECS资源，而操作未绑定标签的ECS资源时会报错。
再来看一个真实的客户案例，某公司希望根据不同的角色对资源进行管理，要求在API层面和控制台都可以用，这里分别有四个RAM角色，分别是资源的生产者，资源授权的管理者，还有两类的用户，一类是datacenter用户组里的用户，一类是bizcenter用户组里的用户。
资源的生产者负责资源的生产和调度，资源的授权者是负责管理资源标签的策略和授权的关系，前两者一般可以是用户公司的财务人员和运维人员，而datacenter的用户组的成员和bizcenter用户组的成员往往是公司的研发人员。
运维人员可以按照ResourceTag去创建出包含自定义的标签策略的策略，授予datacenter成员去访问带有这个datacenter tag的ECS资源；授权bizcenter的成员，可以访问带有这个bizcenter ECS tag的资源。
这里资源的授权就相当于对资源进行打标签，需要资源上有标签，在ECS上面添加相应的标签就可以。如果希望用户无法访问当前资源，只要把这个标签删除掉就可以，而不需要再去修改这个标签的权限策略，这样对于权限的管理就转化成了对于标签的管理，这样是一种更加灵活的使用权限控制的策略。
我们强烈建议您开启操作审计的服务，操作审计的服务称为ActionTrail,它可以帮助您去监控记录云账号对于产品服务的访问和使用的行为，您可以根据这些行为进行事后的行为分析、安全分析，来监控未授权的访问，或者识别潜在的安全配置错误，威胁或者是意外行为，也可以满足行为合规审计的一些要求。
小结：刚刚在权限管理中，我们介绍了ECS几个产品的安全能力，介绍了访问控制的实现原理，如何给身份授权以及给ECS授权的案例，建议您基于身份授予访问ECS资源的权限，对于有更细粒度的ECS资源访问控制的需求，建议您可以使用资源组或者是标签tag进行批量授权，最后还是建议您能够开启操作审计来监控云账号对于操作的行为进一步监控和控制。
四、避免显示AK配置的最佳实践总结
接下来为大家介绍如何避免显示AK配置的最佳实践。
前面提到了RAM角色是一种虚拟的角色，ECS里面的RAM角色，它其实就是RAM角色的一种，他是使ECS的实例可以扮演某一种特定权限的角色，可以通过临时访问凭证STS去访问指定的云服务，比如ECS可以临时访问OSS的对象存储、访问数据库，这样最大的好处是您不需要在ECS内去保存用于访问云服务的明文AK信息，而且是由ECS的云服务通过角色扮演的方式来实现了与ECS实例和其他阿里云服务间的一安全通信。
为了实现这个效果，您可以在RAM的控制台上去创建一个RAM角色，指定的可信的实体类型是阿里云的服务，角色的类型是普通服务角色，授信的服务是ECS云服务器，为RAM角色进行授权，比如是可以只读的访问对象存储，在ECS的控制台上，选择指定的ECS实例，授予ECS实例的RAM角色就可以了。
接下来，我们通过给ECS关联的RAM角色来解决一个实际的安全隐患。
在很多用户的业务服务当中，经常会使用到MSE配置中心来管理日常、或者预发、或者线上各种环境的配置信息，由于配置项中往往存在敏感的数据，明文保存在配置中心是不安全的，但如果把配置项加密保存在MSE配置中心之后，又需要把加密之后的配置传给KMS进行解密，在过程中会使用到密钥等敏感的配置项，这些配置项如果在使用过程中落盘，比如落到了ECS实例里面，就会容易产生安全的风险。
这时候就可以通过给ECS的实例去关联一个RAM的角色，来无密钥的访问MSE的配置中心和KMS。通过给ECS的实例关联RAM角色，授予一个临时访问的权限，这时候就可以避免开发人员和用户，拥有解密配置项的能力。这里ECS实例去访问MSE的配置管理的时候，使用的是MSE的SDK，在获取到了配置项，实际上这时候还是一个加密的配置项，这个加密配置项是封装在MSE的SDK当中的，这时候应用程序再拿加密的配置项，调用KMS的SDK，调用KMS的SDK之后返回的结果也是在KMS的SDK中，这里面全过程中所有的敏感配置项都不会落盘，都是在内存当中。好处就是用户无论是KMS的密钥的管理员，还是MSE的配置的管理员，他们都获取不到敏感的信息。
五、总结
最后我们对本次分享做一个总结：本次分享一共有三大部分，分别是身份认证、访问控制和一些进阶的安全方案。
如何提升身份认证的安全性？建议您开启主账号MFA的多因素多因子认证来增强主账号的安全性，不建议使用主账号的AK，而是给应用颁发子AK，避免将明文的AK暴露到外部的开发平台上，同时定期的去清理长期不使用的RAM用户。尽可能的使用具有时效性的临时的STS token。
提升访问控制安全性方面，建议您可以利用ECS已经预定义好的系统策略和自定义的RAM策略，为不同职责的人员授予权限，可以基于资源组，按照云资源的用途、部门结构等不同的维度来管理资源，授予不同用户访问不同资源组的权限，也可以使用标签对云资源进行细粒度的资源管理和控制。
在进阶方面，建议您可以使用ECS实例的RAM角色，将RAM角色关联到某个具体的ECS实例上，这样就可以避免将显示的AK配置落到ECS的本地，同时建议您能够启用操作审计ActionTrail，可以进行事后的行为分析和安全跟踪，来识别潜在的安全风险，满足合规审计的需求，建议您也开通免费的身份权限治理服务来定期检测身份和权限上的安全风险，及时完善云上身份和权限配置的安全性。
以上就是本次分享的全部内容。希望通过这个分享，能为您在阿里云上安全的使用ECS，提供一些的帮助和建议，谢谢大家。
