本次主题是是防止凭证泄露的十种方法，如何管理阿里云访问密钥，怎样去预防人为造成的对企业伤害非常大的灾害，也是凭证泄露的灾害，分四个部分介绍有效防止凭证泄露的方法。首先需要了解凭证的安全风险，凭证泄露对企业产生的严重的后果，第二部分是了解阿里云的凭证类型，只有更好的认识凭证的类型和特点，才针对性的做凭证的管理，第三部分是防止凭证泄露的10个有效的方法，第四部分助力企业更好的提升凭证和资产的安全。阿里云今年也会逐步推出非常重大的安全升级策略。

 

一、凭证的安全风险

首先看凭证的安全风险。介绍两个非常典型的凭证泄露的案例，左边是国外的一个移动通信的应用开发的公司。这家企业的研发人员使用一个移动通信开发平台提供的开发套件。在开发的过程当中把程序的凭证硬编码在开发的代码当中，攻击者通过攻击开发平台获得到企业的硬编码的凭证，同时攻破企业线上的系统，获得到企业的线上数据，由于这是一家移动通信应用的开发公司，它的线上数据包括非常多人员的联系方式，以及客户非常私密的通话记录的信息，这家公司因为这件事情被监管部门进行调查。

右边是一家国外知名的打车平台，黑客首先获得到这家公司一名研发人员的即时通讯的联系方式，通过一个钓鱼的邮件发送IT修复的钓鱼邮件套取到员工的登录密码，通过员工的登录密码进入到内部系统之后，获得到这家公司发布在线上的脚本文件,文件当中配置有硬编码的程序凭证,最终导致这家公司线上的数据以及代码库整个都被暴露。这两个事件直接导致的原因都是由于研发人员将凭证信息硬编码在代码里面，除了的原因以外，还有其他原因会导致企业的凭证泄露。

看一个案例，虽然案例整体是虚构的，但是这里面每一步的风险每天都在发生，每个企业上云初期要注册一个云账号，注册的时候输入一个用户名，获得配置用户密码，这是企业上云访问控制台初始的第一个凭证。这家企业设置一个非常常见的密码，admin12345，第一个风险此埋下，因为密码太容易被破解，风险埋下之后，紧接第二个风险产生，很多公司在初期上云的时候，有核心的运维人员要负责基础配置，运维人员需要操作各种各样的云资源，做各种各样的账号配置，为了方便做运维的工作，把主账号的用户名和密码共享给核心的运维人员，免去后续授权的复杂工作，风险的隐患埋下。

审计是非常难区分真正的操作者，登录使用的是同样的用户名和密码，即便是后续有误操作，甚至于其中有些人对企业产生破坏性的操作，很难通过审计区分真正的操作者，由于过多共享主账号的密码，容易暴露密码，让更多的第三方的人知道企业核心的账号密码，在一个运维人员离职的时候，因为他掌握主账号的密码，他将企业核心的账号的资产直接带走，在基础的配置完成之后，企业的应用要上云，必须给应用分配程序访问的凭证，这时候运维人员为方便配置多个主账号的AccessKey是AK的凭证分发给线上的业务使用，免去很多后续的麻烦，业务的应用不需要经常申请新的权限，直接用一个admin的权限直接做后续的研发的工作，但是它也造成了更大的隐患。

主账号的AK是默认享有整个账号所有的权限，也意味着它一旦泄露，攻击者也如入无人之境，进到账号，访问所有的资源，获取所有的数据。第四个风险是研发人员为方便，将AK信息硬编码在代码当中，直接导致整个凭证的泄露，因为把AK信息硬编代码在代码里面，造成如果后续想要轮转AK会变得比较困难，需要从的代码里面全部梳理一遍，到底在哪里写AK信息，把AK替换掉，再重新发布代码，的过程非常的麻烦，所以这家企业选择AK长期使用。AK一般来说不会泄露的，AK长期的使用，暴露时间越长，泄露的机会会越多，越有造成AK的泄露。最终由于代码托管发布到托管平台，由于研发人员做技术分享的时候，不小心把包含AK的源代码分享到公网的平台上面，导致整个公司的凭证泄露，最终导致线上的各种数据的泄露，风险逐步的累积，最终会对企业带来非常致命的伤害。

 

二、阿里云的凭证类型

案例当中提到非常多的概念，提到程序凭证，人员凭证，主账号，子用户，正确的认识阿里云的凭证类型，了解它们的区别，才能更好的掌握凭证管理的方法,介绍阿里云凭证的类型，主账号和子账号两个概念，强调只有子用户，没有子账号。账号除了是一个登录的身份密码之外，它更大的作用是一个资源的容器，在注册一个账号之后，购买的所有的云资源都是放在资源的容器里面，同时还关联企业的发票信息、折扣信息，合同信息等各种各样的信息，账号容器是资源的归属，子用户只是一个操作资源的身份，所有的资源并不隶属于子用户所有。

在注册云账号的时候，默认会产生一个根用户，根用户是有账号下全部的权限的，没有手段限制权限，导致根用户的用户名、密码，或者创建根用户的AccessKey凭证泄露，入侵者会享有账号下所有的权限。强烈建议尽量少使用根用户。企业的员工和应用程序想要访问云资源，推荐一款产品，提供了为人员和应用程序单独分配独立身份，授予所需要的一个细粒度权限控制身份，通过访问控制的权限授予细粒度甚至到某一台ECS重启的权限，员工和应用访问云资源的时候，阿里云鉴别和认证访问者的身份，以及他的权限是否执行操作。

看人员凭证和程序凭证的区别。人大多数情况下都是通过浏览器或者移动app，通过访问控制台的方式运维云资源，做基础的配置，人员访问的凭证类型是通过SSO单点登录的方式，从企业自由的身份体系登录到阿里云的平台上，也是直接使用用户名密码，加上MFA多因素认证的双重保证登录，也提供钉钉扫码便捷的方式，减少登录的输入步骤，程序主要都是通过SDK，CLI编排工具，开发工具调用阿里云的Open API访问云资源，程序访问有两种类型的凭证，一种是常用的长期凭证AccessKey，它的特点是长期有效，一旦创建出来，在主动禁用之前，它都是有效的，意味着它如果泄露，攻击者直接拿着AK做相应的操作，通过扮演角色获得到一种临时凭证STS Token，凭证的特点是短期有效，它的有效性保证安全性会比AccessKey会更强。

 

三、防止凭证泄露的10种方法

是防止凭证泄露的十种有效的办法。十个方法全部都浓缩在凭证管理的最佳实践的大图里面。首先看两个基本原则，第一个原则，缩短暴露时长，任何一个凭证暴露的时间越长，它越有有机会被泄露。所以所有的凭证的使用时间应该是尽量的控制，尽快的在不需要使用的时候失效，或者周期性的做轮转来缩短整个暴露的时长，第二个原则，缩小暴露面积，每一个凭证都有它的权限，还有功能限制凭证使用的环境，通过各种限制条件，让凭证生效的范围缩小，在仅需要的范围内生效，暴露出去造成的影响也会相对更小。所以主账号暴露的面积会造成最大的影响。

把十个方法分为事前的规划和管理阶段，和事后的审计和治理阶段，第一个是反复强调的尽不使用主账号，主账号是有风险的，需要为人员和程序分别分配身份。要将人员和程序身份做分离。如果给一个用户同时开启控制台登录，又创建程序凭证AccessKey，当用户不小心把密码泄露，很有会直接影响AccessKey在运行的线上的应用。连带的会破坏线上的环境。所以将人员和程序分开，让他们影响缩小到的范围里面。分开之后，人员身份和程序身份分别有几种方法防止凭证泄露。

人员身份的方法有使用SSO单点登录，及时清理闲置RAM用户，使用强密码策略，使用MFA多因素认证，使用登录IP限制程序身份。防止泄露的主要方法有使用临时凭证,不将AccessKey明文硬编码在代码当中,使用AccessKey白名单策略,及时清理AccessKey 。在事后的阶段，虽然事前做到非常多防止凭证泄露的方法，但还是需要不停的持续监控整体身份管理是否做到位，推荐通过审计日志和各种检测的工具及时发现风险。由于操作审计的日志默认保存90天。

所以在真正发现风险的时候，回溯操作审计记录，发现90天之前的记录没有了，无法从根源上找到凭证是如何泄露的，推荐提前做好操作审计日志的投递工作，把日志投递到sis或者oss bucket的里面做保存，后续遇到风险或者故障排查的时候，找到足够的操作审计的日志做排查，定期的通过提供的各种检测的工具，及时的发现凭证管理上面的漏洞和风险，及时的做修复和调整。

进入到凭证管理最佳实践的第一条，尽不使用主账号，因为无法完全杜绝使用子账号，在初始注册的时候，肯定需要用到主账号。账号级别的配置，比如账号本身的密码轮转，账号本身的MFA绑定之类的都是需要用到主账号，所以仅在必要的时候使用主账号密码，妥善保管好密码，把密码仅保存在核心运维人员手里，甚至于有公司把密码直接放到保险箱，把一个MFA硬件设备塞到保险箱里面，只要保证应急状况下能够找到响应人。开启MFA多因素认证能够保证主账号密码的泄露拦截，然后尽量减少主账号的登录。

第二部分，在程序访问上要做到不使用主账号AccessKey，使用RAM用户的AccessKey替代主账号。临时凭证的方案会比直接使用AccessKey更安全。现在看人员凭证管理最佳实践。分为两个部分，左边的部分是减少密码暴露，密码越少暴露，泄露的风险会越降低，右边是加强密码防护，减少密码暴露的第二点是SSO单点登录的方案，使用单点登录让员工直接使用企业的域账号身份密码登录阿里云的控制台，不需要再创建一个云上的用户的密码，少一个密码，密码泄露的风险会降低。

第三是及时清理闲置的RAM用户下面标红的地方是今年阿里云会针对闲置用户清理提出一个新的功能，加强密码防护有三个方案，使用强密码策略，使用MFA多因素认证，对应有相应的新的策略的发布以及使用登录IP限制。详细讲几个方案。首先及时清理RAM闲置用户。闲置用户的产生是员工离职以后账号没有及时的做清理删除，有项目结束，项目的运维研发人员转移到另一个项目，甚至转岗到其他公司的部门，原有的研发的账号如何处理，会有第三方合作的公司和代运维的公司合同到期，代运维工作解除，代运维公司创建的账号如何处理，用户身份如果没有及时的删除，离职人员和三方公司都继续持有用户名和密码来登录公司的账号，很会造成机密数据的泄露，为防止闲置用户产生影响，要及时的清理。

最佳实践首先推荐有的IDP，身份管理系统，通过SCIM协议的同步的方式，把IDP的人员身份直接同步到阿里云上面，在人员离职的时候，在IDP把人员禁用删除后，也会同步到阿里云RAM，把用户身份做同步的禁用和删除。前提是IDP支持删除的功能，有一定的门槛的条件，除此以外也做手动的审计和治理，定期通过审计检查长期未登录的用户，在做相应的用户禁用的操作，为方便能够更自动化的，更快捷的做清理闲置用户，阿里云在9月20号开始逐步灰度的发布两年闲置用户自动禁入控制台，登录策略的功能不需要配置，它是一个默认的策略，每天会检查有多少RAM用户已经超过两年无任何登录记录，自动把登录功能关闭掉，如果用户要登录，RAM管理员仍然开启用户的登录状态,建议尽快把密码重置，不确定密码是否泄露，所以尽快重置，绑定MFA，保证身份是可信的。

第四个方法是强密码策略。弱密码都是非常容易被破解的，保证员工都能够使用强密码策略，因为密码是让员工设置的，RAM访问控制产品有密码策略功能做限制。做几种类型的密码策略的配置，保证密码长度在八位以上，限制员工只能设置八位以上的密码，密码当中必须包含大小写字母、数字、符号当中至少三种。密码当中不允许出现用户名。密码有效期在90天以内，也是每90天员工需要轮转一次的密码，新建密码，密码过期以后要限制登录，否则密码过期无意义。密码过期之后要限制登录密码重试约束在五次以内。防止爆破性的突破密码，另外两条规则，密码历史，检查策略以及最少包含的不同字符数，这都是可选的策略，根据的安全要求去设置，经过一系列的策略设置之后，能保证员工使用的是强密码。密码不容易被破解和泄露。

第二重保障是使用MFA多因素认证，阿里云的MFA多因素认证用在两个场景下面，第一个场景是最重要的是登录时候的二次认证，登录的时候如果只有密码，密码一旦泄露，没有任何其他的防护，攻击者直接用密码登录控制台，访问云资源，加上第二重保障，两个认证方式同时泄露的概率是非常低的，有效的拦截异常的登录，推荐做MFA多因素的绑定，如果绑定多因素认证的方式以后，再进行高危的风险操作，比如删除，释放ECS实例做重启的动作的时候，控制台也会再次唤起二次验证，二次验证帮助员工确认现在操作是有高风险的，同时防止恶意的行为，多因素认证很多企业觉得很麻烦。每次登录的时候，除了输入一个密码，还得再加一个东西，现在也提供选择的多因素认证的方式，包括手机短信认证，相对方便，收到短信直接输入验证码。

第二个是使用虚拟MFA的设备,需要在手机上装APP。使用硬件的U2F设备，或者使用邮箱，邮箱标灰的作用是因为它只在风险操作的二次验证场景下使用，登录的时候是不使用邮箱做二次验证的，因为它的安全系数相对没有那么高，为了促进更多的绑定MFA，让更多的异常盗用的登录拦截在登录之前，在8月20号已经开始逐步灰度一个新策略，RAM用户默认启用MGA多因素认证。有企业已经被灰度到,账号的RAM配置调整到强制所有的RAM用户登录时必须进行MFA验证，保障凭证安全的非常有效有力的方式，有企业觉得已经做好安全加固，做登录的IP限制，保证员工只在公司的范围内访问阿里云，在的前提下，也允许用户调整配置。回到两种其他的验证方式，第一种是仅在异常登录时候验证，风控系统会判定用户登录时候的环境是否跟和以往的环境有很大的差异，如果出现风险的时候会唤起多因素认证，无风险正常只用密码登录。

另一种是依赖独立配置，部分用户单独的设置它是不是需要进行MFA认证,建议保持强制的配置，这是使用多因素认证方法，第六个方法是使用登录IP限制，大多数的运维人员都还是在公司的网络环境之下，利用网络可信环境的配置，把企业的可信的IP配置到RAM产品当中，限制员工只能在公司的办公网络环境下面访问控制台。员工在家远程办公或者出差，推荐企业给员工提供VPN的服务。通过代理的方式同样限制整个网络环境在企业可信的IP范围之内，这是使用登录IP限制的一个方法,前提也需要非常清晰的梳理好企业的可信网络环境，避免把员工拦截在外面。

是程序凭证，AK泄露如何预防，AK是最常用的程序凭证，因为它是一个长期有效的凭证，它一旦泄露，凭证一直持续有效，入侵者也使用凭证访问云资源，所防止AK泄露最直接的办法是不使用AK，用另外一个凭证替代，它是临时凭证STS Token。有场景下还是必须要使用AK，将AK不明文硬编码在代码中，今年也会推出AK的IP访问白名单策略，及时清理闲置的AK，首先看临时访问凭证STS Token。

临时凭证的有效期很短，最长不超过12个小时。而且时间完全定义。一到有效期后它会自动失效，不需要主动吊销，同时为方便使用临时凭证，在下面的很多场景下面都提供自动获取临时凭证的方案，不需要再使用一个永久AK获取临时凭证，会杜绝永久AK的使用。凭证使用的原理是各种类型的RAM身份,SSO用户，RAM用户或者角色，还有阿里云的服务都会通过扮演角色的方式换取STS Token，用token调用API访问阿里云的API，下面看到有四种应对不同场景的临时凭证的使用方法，如果应用部署在ECS上面，有ECS实例角色方案。

如果应用部署在容器服务ACK上面，有容器服务的RRSA方案，如果应用部署在函数计算上面，有服务角色的方案。如果只是开发做线上调试测试的工作，也用云SSO产品,使用临时凭证做线上的调试，使用临时凭证的方案是各个云服务帮助换取到STS Token，并且分发给部署在服务上面的应用，以ECS实例角色为例。首先管理员需要创建一个角色，授予相应的权限，代表的是应用访问的云资源，比如访问OSS或者数据库，授权之后，角色和ECS的实例做一个绑定的动作，实例角色是专属于ECS实例使用的，每一个ECS实例当中，它的原数据服务会帮助扮演角色，到访问控制产品换取到STS Token临时凭证。部署在ECS实例当中的应用通过向原数据服务获取STS Token，访问API。

整个配置过程非常简单，不需要在应用程序代码里面写永久AK,没有人会接触到永久AK。同时凭证的使用非常简单，不需要手动轮转原数据服务刷新STS Token。也为不同的ECS实例绑定不一样的角色，授予不一样的权限，做到细粒度的权限的控制。这是ECS实例决策的方案。如果应用是部署在容器服务上面，也有相应的方案，它的原理和ECS有一点区别。首先打开一个叫RRSA的功能，功能打开之后，容器服务会自动的到访问控制里面创建一个OIDC provider，它是发放OIDC Token凭证的,token会作为一个中间换取STS Token的介质，在配置之后，整个ACK集群当中的RRSA服务，会获取到OIDC token，客户的应用拿着OIDC token,用assume row with OIDC的API， 换到STS Token的一个临时的凭证访问阿里云的资源。只要按照步骤配置完，拿到一个临时凭证，应用访问云资源，同样不需要接触到永久AK。同时不需要手动轮转。

看整个配置的过程，如何配置容器服务里RRSA服务。首先需要在容器服务当中启动RRSA功能，功能启动比较简单，在控制台上面。在集群中，打开已经创建好的集群，找到基本信息当中的一个配置RRSA OIDC 功能,启用。在整个更新的过程当中，容器服务已经自动的在RAM当中配OIDC provider，不需要手动操作，到RAM来看是否已经创建好，在SSO管理看到已经创建好的OIDC provider，provider是用来发放OIDC token，不需要做任何的改动，默认都是配置好，安装组件，到容器服务的控制台找到web pop的组件，在安全的分类下面。一键安装，在容器服务当中RRSA 功能正式开启，需要创建一个角色，角色是给应用使用，角色代表应用所享有的权限，它会绑定在整个容器的POD上面，需要手动创建一个角色，角色的信任对象是自动创建出来的OIDC provider，直接在选项里面找到，下面有三个限定条件，都是为了限制角色只能用在OIDC provider上,防止过大的权限,限制换token的过程是更安全的。

角色创建完之后，需要做授权。授予需要的相应的权限，根据业务情况定。回到ACK的部署，定义yaml，部署测试的应用-demo应用。demo在容器服务的文档中也有提供，demo部署完之后，查看部署的结果。看到有一个OIDC provider获取到 OIDC token的文件，直接调用STS的API去换取STS token，拿到临时的凭证，再访问阿里云的API。撤销授权是验证权限是否真实有效。第三个换取临时凭证STS token方案。如果应用部署在函数计算上，有一个换取STS token的方案，创建一个角色，角色只信任函数计算服，角色授予相应的权限之后，把角色和函数做一个绑定的动作，函数会替STS服务换取STS token，信息会放在函数的上下文里面，部署在函数上面的应用通过上下文获取到STS token,访问云服务。

这几个方法都是类似的，服务已经替STS服务做换取STStoken的一个工作，直接让应用拿到token访问阿里云的资源。第七种方案是临时凭证当中,开发人员如果要做简单的调试工作,有云SSO服务应用于使用RD多账号管理结构的企业，给用户的员工分配云SSO的用户身份之后，在登录的界面上直接拿到一个访问凭证，这是一个临时的凭证，直接做线上的开发调试的工作，也支持CRI的方式，这两种方式都不需要再使用永久凭证，直接通过STS token做调试的工作。如果有场景，没办法完全适用刚才的临时凭证的方案，还要使用永久AK。不将AK明文编码在代码当中，建议使用统一存储，自动获取的两种方案，上面这种方案推荐将AK信息配置存储在本地配置，环境变量，或者配置文件当中。

两种使用的方法。首先阿里云SDK提供credentials工具，工具默认按照配置好的顺序嗅探各个类型的凭证，找到之前配置的各种的凭证直接自动的应用，如果不想用默认工具链的方式，也直接指定使用环境变量或者配置文件，AK信息只存在环境变量当中，每次用的时候从环境变量里面去取，研发人员不用每次写代码的时候把AK信息编辑进去，这是反复的引用的，另一种方式是云上的托管服务，KMS的密钥管理服务将AK信息，AK凭证都托管在云上的服务。

托管到KMS服务之后。首先有权限控制，只有KMS的管理员真正接触到AK的明文信息，研发人员都不需要再接触AK，研发人员直接使用KMS服务动态的获取到AK的凭证，同时因为是托管的，KMS服务还帮自动轮转AK，这也是云上提供的方案，通过这两种方式，避免在代码当中暴露铭文的AK，万一有漏网之鱼的情况，不能避免有异常的外部的调用，AccessKey的IP白名单策略的功能会在十月份做发布，把AK调用的来源限制在可信的网络范围内，通过配置的IP白名单，IP白名单提供两种类型的白名单,介绍整个运行的方式。首先有一种AK级别的IP白名单，它是绑定在单个AK上面的，白名单的IP，只对AK起限制。

另一个白名单是账号级的IP白名单，白名单一旦配置了，它对账号下所有的AK会生效，包含主账号的AK和所有的RAM AK，账号级的白名单对账号所有的都生效，会有一个优先判定的策略，当一个accesskey发起调用的时候，首先会看AK身上是否绑定一个单独AK的白名单，如果有，会先走AK级白名单的整个判定的规则，如果来源IP在白名单的IP范围内，IP包含网络IP，也包含专有网络VPC。

在IP范围内会通过，如果不在里面会做拦截，如果AK身上没有绑定单个的IP白名单,会走到下面再去看账号有没有设置整个账号的IP白名单，如果有，也是一样的判定策略。如果在IP内会通过，如果不在IP内做拦截，如果两种白名单都没有限制，和现在正常使用的AK一样，直接通过，会进到下一步鉴权的环节，鉴权完成之后调用API,两种IP白名单的方式有不同的配置的方法，比如使用账号IP白名单做一个基础的限制，把整个API AK的调用圈定在一个相对可信的大的IP范围内，如果有非常重要的AK，甚至于已经疑似发生风险的AK，再给它精确的到一个非常小的IP范围内做相应的可信网络的配置，IP白名单策略功能会在十月份灰度的发布，前提是要用功能，需要梳理企业的IP，通过操作审计和各个数据服务的数据审计的功能检查现在已经在使用的IP。最后一个方法是需要及时的清理AccessKey，任何一个闲置的AK长期存在，它都有会是暴露的风险，甚至于因为AK长期无人用，它被盗用的时候都很难发现，因为AK已经无人管理。

正常AK使用推荐定期清理闲置的AK。最好的方案还是使用STS token，在无法用STS token的时候，有比较严格的AK的申请和回收的流程规范约束。在一个应用下线的时候，在一个业务结束的时候，一定要检查AK是否不再使用，做禁用的动作，为方便更好的执行闲置禁用规则，在今年十月底开始会陆续灰度发布两年闲置AK自动禁用功能，每天检查AK已经两年无任何调用记录，自动的把AK禁用掉。如果AK还需要使用，通过管理员重新激活，建议长期闲置的AK尽量不要再使用,用新的AK轮转，不要再重启闲置AK。如果还有发生的风险，及时发现它，也是更快速的响应，让风险扼杀在摇篮里面。

如何更快速的发现凭证管理的风险，有几种方法推荐。首先是治理检测，RAM产品本身和云治理中心两款产品共同推出凭证管理的一个检测功能，这里涉及到23个治理项，包括闲置AK，包括AK调用的记录问题等，使用的配置上面的问题都在检测项里面，同时还会提供详细的明细数据，AK ，RAM，用户有风险，相应的针对性的做治理的动作，也提供治理方案，第二个是主动审计，在操作审计当中，单独的有一栏-AccessKey审计，针对AK的更详细的审计记录，包括AK最近调用的时间，它使用的云产品，调用的IP来源等信息，更好的排查最近调用是否存在疑似风险的行为，尤其是AK泄露的情况下，一定要排查是否有动作发生，产生什么影响，第三种是云安全中心会提供AK的泄露的检测以及漏洞的检测，AK泄露是明确AK已经发布在github的公共平台上，它会第一时间收到通知，并且用各种方式告警通知。

强烈建议如果收到通知，不要忽视他，尽快的把AK轮转掉，因为黑客的动作快，当发现的时候，他们已经开始动作，马上盗用AK，创建资源，做违法的动作，甚至有删除数据，做勒索等动作，同时云安全中心也会发现很多的安全漏洞，很多时候凭证的泄露也是由于漏洞造成的，要尽量及时的发现漏洞，做修复的动作，防止APP泄露。回顾今年会发布的这几样重要的策略，每一个策略都会应用到每一个RAM的账号上面。

 

四、阿里云2024年凭证安全升级重大策略

首先八月份已经发布用户默认启用登录MFA，铺开到全网所有的RAM用户身上，都需要绑定MFA，做登录的二次验证，防止异常调用的行为，九月份会开始逐步清理闲置用户。功能会持续运行，所以每一天都会检查有哪些闲置用户做每天的禁用，它会持续的运行下去，十月份开始闲置AK的清理的功能发布和IP白名单策略的发布，这两个都会针对性AK的整个治理的动作，在11月到12月左右做减少主账号AK，主账号AK默认有最大权限，所以它风险极高。为促进少用主账号AK，会把主账号五个配额调整到两个，降低配额促使更多的用RAM，不要用主账号AK。

介绍MNC客户：云上无明文密钥实践，之前分享在阿里云上如何针对人员身份包括程序身份做更好的管理，提供很多的最佳实践和解决方案，下面把解决方案和最佳实践落地到企业中，围绕MNC企业介绍如何把这一套的最佳实践和解决方案落到云上的环境当中。

 

五、MNC客户面临的身份管理风险

MNC指跨国企业，企业在云上会有比较多的业务，它在不同的国家也都会有它相应的运营中心，跨国企业都代表在国际市场上，包括国内市场上都是非常头部的企业，企业在云上会面临安全风险，这两组数剧来自于今年的最新的报告，从报告中看到有98%分配的账号的权限是没有被实际使用的。第二组数据是和程序的凭证相关的。看到在web应用程序工具中，有77%的事件和密钥泄露是有关的，在很多企业面临的数据泄露风险的事件当中，有38%的数据泄露事件和AK的泄露是有关系的，看到对于跨国企业，对于国际的头部企业，它们在云上也是面临着很多的和身份，权限，AK，密钥等相关的安全风险，另外一份报告也佐证猜想，这份报告是来自于国际的一个云安全联盟的报告，在2022年和2024年做相关的调研。

对于国际市场的头部企业，RAM，身份和访问控制的风险，一直都处于非常top的位置，跨国企业又代表阿里云上非常非常大体量的，包括头部的客户，所以对身份安全的重视也成为MNC企业的一个共识。今天的分享围绕客户如何把身份权限的最佳实践落地到企业的日常运维当中，先了解具体会遇到的风险，遇到的风险是和本身的运维模式是有关系的。对于MNC企业客户来说，过去几年也服务很多头部的MNC的客户，在上云的初期，首先会构建一个安全合规和可扩展多账号环境，称之为Landing Zone，有基础环境之后，再把的业务系统，比如CRM，业务的应用搬到阿里云上。

洞察很多头部的MNC的客户，往往是这样的运维的模式，首先内部会有infra的team，或者是Ccoe团队，是一个中心化运维的模式，本身会负责治理相关的云上的战略，或者是相关的落地标和原则，对于业务系统，往往会采取采购第三方的供应商，帮他们做系统的研发，或者后续的运维，这是一个非常好的运维模式，MNC客户把精力更多的放在业务当中，把应用的本身的研发或包括底层运维交给更合适的人做。随着企业有很多的供应商，供应商会都用到阿里云上做日常的运维，甚至包括资源采购，有些企业会给供应商分配本地的RAM用户，供应商人员是不在企业内部的身份管理系统里面，给他分配RAM用户做事情，对于应用。

如果应用需要访问阿里云的API,需要访问OOS存取数据，之后需要给他分配密钥，给他创建一把固定的AK，交给供应商，供应商写在代码里面，供应商访问云上API，另外很多供应商需要操作很多资源，在日常过程中，也会分配比较大的权限，能够更好的做运维的操作。本身供应商不在企业的整体人员的管理的范畴当中。比如供应商的人员离职或者变动，没有及时通知到客户的infra team，没有及时回收用户的身份，包括密钥，AK等，会造成未授权问题。很多客户的AK的泄露,是因为已经离职的人员带走一把AK,做未授权的访问,造成数据泄露的风险，如果相关的RAM用户，又有过大的权限，风险会急剧的增加。

 

六、云上无明文密钥实践

为让客户能够更好的使用阿里云上身份和管理的最佳实践，要把风险消除掉，举客户落地的最佳实践，包括在过落地过程中的具体的方案，把无明文密钥的最佳实践应用到企业的日常安全，包括运维的流程当中。首先看阿里云卓越架构的整体的最佳实践。

核心的原则是最小化原则，因为安全讲究的是最小化，通过缩短暴露时长和缩小暴露面积这两个手段确保云上身份权限的最小化，减少泄露的风险。具体的过程在阿里云上会有相应的解决方案。比如SSO做统一的身份管理，针对AK，也推荐使用无AK的方案，使用临时凭证的方案降低固定AK的泄露的风险，在治理过程中，MNC客户会觉得方案是非常好的，在落地过程中会关注核心两类，一个身份类型，另一个是用户的身份。

比如企业内部的员工，供应商的员工和用户是否离职，是否有人员的变动，是否保有固定AK的场景，对于业务的应用，称之为程序的身份，会关注程序是否用固定的AK，是否把AK硬编码到的代码当中,后面会有泄露的风险，真正在落地的过程中，除了把风险消除掉，头部的企业客户怎么能够更平滑的把方案推进到企业的流程当中，避免给应用和业务造成一定的成本增加，作为一个中心化运营团队，要想把优秀的方案推到业务团队的过程中，包括供应商的开发系统当中，面临最大的挑战是是否要改代码，登录方式是否会改变，是否能平滑做迁移，这都是企业客户最多的问题，在设计方案的时候，落地云上的身份和访问控制的治理的方案时候，往往会分为三个部分。

首先会针对人员身份做存量的治理，识别之前是否有没有登录的用户，有些供应商账号不再用，做一个及时的清理，和企业的IDP做SSO单点登录的集成，确保所有的用户都能通过SSO的方式统一登录阿里云控制台，不需要给他分配独立的本地的RAM用户和密码，能够实现一定程度上的无明文的密钥，不会把用户名和密码拿走,第二部分是程序身份的访问程序的管理，在给客户落地的过程中，会优先推荐使用基于RAM角色无AK的方案，另外针对非阿里云的密钥，会推荐使用KMS托管密钥的方式，最后场景是针对权限的整体化的治理，要实现最小化的权限，识别有哪些权限在用。

第一部分，针对人员身理方案，在阿里云有丰富的方案，简单归类，核心是三种SSO方案，第一种方案实际是基于单账号的RAM SSO，在多账号架构-Landing Zone整体架构出来之前，很多客户采取单账号的运维模式，这种模式比较适合在阿里云上，它只有一个阿里云账号的客户，基于单账号的RAM SSO和IDP做集成。

第二种情况是企业会有多套的身份管理系统，或者对接比较非标准的IDP，身份管理系统不支持SAML协议，它提供其他的协议。这种情况下推荐使用IDaaS产品做中转实现最终跟阿里云的SSO的集成，最后是云SSO，也是最近几年发布的一款针对多账号场景下的人员身份的统一管理的产品，基于这种场景下，如果有多个阿里账号，只用去和IDP做一次集成实现完整的一套身份的管理，以及身份的集中化的管理，在落地过程中，MNC客户会考虑，第一个是要确保人员身份集中化管理的，要有单一的认证源，因为一旦分散认证源之后，会造成运维成本的增加。有些风险无法及时发现，一定要有单一的可信的认证的源。

第二个是一定要能够满足现有的客户的场景，因为阿里云上绝大多数产品是支持RAM角色的，也有少部分的产品它是不支持RAM角色的。针对这种场景，如果客户之前已经在用RAM用户再做平滑迁移的过程中，能够把原有的RAM用户的权限平滑迁移到SSO权限体系当中。

最后一点是客户非常关注的后期的运维成本，跟业务团队、供应商团队，包括本身的中心化的团队是否增加额外的成本，以云SSO场景做一个介绍，云SSO本身实现多账号的身份的集中化管理，云SSO本身是一款免费的产品，首先会推荐客户使用这种方案，右边是一个比较标准的云SSO和阿里云多账号体系的集成，在企业的资源目录管理账号中开启云SSO这款产品，然后云SSO和企业的IDP做集成，实现单一的认证源。所有的企业用户都会在云SSO做一个集中化的管理，所有的用户会通过云SSO再去登录到不同的阿里云账号账号中，客户在实施过程中一定会面临原有的RAM的用户怎么能够平滑的迁移过来，期望的目标首先是要实现统一化的管理，以前的RAM账号，每个账号下都要创建对应的RAM用户，它是一个分散的管理，最后希望能够统一的实现管理。

第二部分是迁移过来之后，要降低对员工的影响，尽量不让员工感到非常大的差异，比如之前有权限能够访问云产品，如果迁移之后不能访问，所以在迁移过程中，要做到平滑的迁移，实施步骤会针对客户的情况，第一步是要先识别清理掉的用户，用户不再使用阿里云，已经离职，清理掉之后，降低后续迁移的成本，先释放掉不用的后续也不会再用RAM用户。

第二个步骤是按照最佳实践的一个原则做好企业的IDP和云SSO身份的打通，做好相关的单点动作和配置，是一次性的工作，第三步是把之前的RAM的身份权限能够平滑的迁移过来，如果客户之前是用RAM角色的方式登录阿里云，也会推荐直接把权限迁移到对应的云SSO的访问配置。发现很多企业用RAM用户的方式，需要访问不支持RAM角色的产品，某比较偏SARS产品，比如大数据的某些产品，这种情况下，还是需要保留它原有的RAM用户的访问的链路,通过云SSO多账号的权限管理同步的功能，也称之为RAM用户同步的功能，把企业的SSO的用户同步到对应云账号下的RAM用户当中，最终登录过去之后，体现的是一个RAM用户的身份,和之前的没任何的差别。权限建议是通过自动化的方式做复制。

在这种情况下，为了做平滑的迁移，首先不能把它原有的登录方式关闭掉,原有的RAM用户密码还保持有效，因为要确保它出现问题，它还使用原有的方式能够登录,避免无法登录控制台做运维管控的操作，同步过来的新的RAM用户本身的权限是空的，通过API的方式把原有的RAM用户的权限复制过来，包括其他产品，ACK，堡垒机，都通过API的方式把权限重新加回去。最后要求员工都使用新的云SSO的统一的登录方式实现集中化登录，如果确定无问题之后，把老的RAM用户删除掉，最终实现平滑迁移。

通过这种方式，既保留原有的登录方式，又提供新的登录方式，提供一个平滑的过渡期。最终是降低客户整体的迁移的成本，下一部分针对程序做迁移，程序的访问凭据，核心是云上AK做体系化设计,最推荐使用基于RAM角色的无AK的方案，使用SKS token临时密钥的方案，这种方案常见的场景支持RAM角色的操作，比如阿里云上绝大多数的产品都支持RAM角色，比如常见的ECS，OSS产品都支持RAM角色，这种场景迁移到基于RAM角色的的使用方案过程中，核心是给供应商或者给员工提供相关的示例代码。在给客户做迁移的项目当中，发现改动非常少，把RAM角色配好，它在代码侧调整是几行代码，核心是后面的测试，包括验证的工作，还有其它凭据，因为企业还需要问非阿里云的服务，需要用到固定的密钥，这种场景，推荐使用KMS做一个集中化的密钥的管控，确保不会把明文的密钥写在代码当中。

程序访问KMS,如果再给他分配一把AK，没有符合最佳实践,所以访问KMS实例的时候，也使用RAM角色的方式访问KMS，拿到最终的密钥，访问其他的云服务，这是整体的一个链路，无论对于阿里云的API，还是对于其他的其他厂商，包括其他服务的API，都有相应的支持，最终都通过类似RAM角色的无AK的方案把它收掉，确保每一个环节都没有明文的AK，对于KMS场景，比如在MNC客户中，怎么部署和运维产品，因为KMS本身会有一定的费用，它是一个以实际的方式收取费用的。这几年KMS提供多账号共享的能力。比如MNC客户，它本身在云上都会有很多的账号，但如果每个账号都买KMS实例,会造成一定的成本的浪费。

另外一个问题无法做统一的管理。如果每一个业务账号都有KMS，运维人员管理密钥的时候，他要登到每一个账号下做密钥的管理，成本是非常高的，所以比较推荐通过KMS实例共享方式，比如在一个secret账号，或者一个infra账里面统一采购KMS的实例，共享给不同的业务账号里面实现集中化的管理，同时实现一定程度的成本的节省，针对KMS密钥的管理，用RAM角色的方式做访问，如果客户应用需要部署在其他云，或者部署在线下机房，它也需要访问KMS实例，建议通过client key和password方式访问KMS实例，在线下部署应的时候，无法用阿里云临时密钥的方案，把client key，password通过自动化的方式存储到OSS bucket里面。

在后续的CI/CD的流程中，把client key自动能够打包到业务的代码里面实现自动化的发布，不需要把client key明文交给供应商或交给研发人员，也实现一定程度上的明文的密钥，最后一部分介绍在权限治理的方案，在和很多MNC客户交流的过程中，最开始看到的关于98%的数据，发现很多时候给供应商分配的账号权限非常大的，很多权限是没有使用的，在权限最小化当中，发现很难实现权限最小化，第一天做权限最小化，后面再需要访问另外一个产品，开通另外一个权限，会造成运维成本的增加，权限分配的过程中，利用像资源组，用户组等，框定大致的范围，在使用的过程中，再结合阿里云上提供的产品的能力，对当前的使用状况做分析，比如今年发布RAM访问分析器的产品的能力，利用访问分析器识别阿里云上RAM用户角色等，有没有闲置的权限，再通过回收的方式把闲置权限回收掉，过程需要持续做，才能够实现最终权限的最小化，过程会带来一个问题，不断做会造成运维的成本。

所以给客户的方案是通过自动化方式做事情，通过自动化方式降低人为的错误，实现更好的人力的释放,包括运维流程自动化的场景。这是比较标准化的自动化的权限回收流程，分析客户的RAM用户的闲置权限，核心通过RAM访问分析器的产品做分析，但它识别类似于web访问，包括闲置的权限等场景，它会对具体的账号下RAM的身份做实时的分析，分析完之后，如果发现风险，会把事件推到阿里云的事件总线产品中，通过监听事件做自动化的操作，比如在函数计算里面写代码，通过监听闲置风险的发现，做针对性的处理，比如识别到RAM身份，它有web访问的情况，比如非组织外的成员要扮演角色，把web访问给修复掉，通过函数计算中RAM的API实现自动化的修复，最终实现自动化的权限的回收的流程。

 

七、总结

MNC客户对安全要求是非常高的。在和很多客户接触过程中，会发现不断推优秀的安全的解决方案，一定会对企业内部的运维流程，包括效率会造成一定的程度的影响，最终在客户业务场景中落地的时候，要在安全和效率之间是取得平衡。比较好的一个方案是结合自动化的方式，比如自动化的权限的复制，自动化权限回收的能力提升效率，最终实现一个安全降低的风险，提升整体的运维的效率。