云账号管理与凭证保护

云账号是云上资源的载体、云上操作的执行者。围绕着资源访问管理，阿里云提供了多种产品功能，方便客户管理和操作云资源。

• 主账号（Root Account）：创建阿里云账户时，默认生成的账号，拥有所有资源的完全控制权；

• RAM用户（RAM User）：主账号下创建的具有特定权限的子用户，用于日常操作和管理；

• AccessKey ：即访问密钥（下称 AK），用于API和SDK调用的凭证，AccessKey ID 和 AccessKey Secret需要配合使用，AK 是一种永久凭证，除非禁用或删除，生成之后可一直使用；

• 安全令牌（Security Token Service）：阿里云提供的一种临时访问权限管理服务，STS Token具有时效性，可以自定义有效期，到期后将自动失效，无需定期轮换，可以减少长期访问密钥（AccessKey）泄露的风险。

以下为账号凭证的使用示意图：

不合理的账号分配及权限配置，会导致企业的安全风险放大。一旦用户账号密码、AK泄漏，黑产可通过凭据访问对应的企业云资源，威胁企业系统稳定性、导致数据被窃取或篡改，甚至可能导致云资源被黑灰产挖矿、勒索。本文将介绍云账号管理与凭证保护的关键建议，以帮助用户控制账号安全风险。

一、尽量避免使用主账号和主账号AK

主账号默认拥有资源的所有操作权限，且无法进行限制，多人共用时无法在审计日志中区分出具体使用人，一旦泄露风险极大，因此在使用阿里云账号时，应该：

• 避免直接使用主账号用户名密码登录，并为阿里云账号绑定MFA设备；

• 避免使用主账号AK直接调用API，而是创建RAM用户AK，以防AK泄漏时失去整个云账号的控制权限。

二、避免使用弱密码或弱口令

弱密码是指一些过于简单，容易被猜到或通过技术手段能快速破解的密码，比如密码长度少于8位、使用 "123456" 或 "admin" 等常用组合，或使用自己的个人信息（姓名、生日、电话号码等）作为密码等。

弱密码是系统被入侵的重要原因之一，因此在设置密码时就应该避免使用弱密码或者弱口令。建议为RAM用户设置足够强的密码规则，比如限制密码长度范围为8~32位，密码中必须包含大写字母、特殊字符等，同时设置密码有效期不超过90天，定期更新密码、设置密码重试次数等，降低密码被破解的可能。

针对云资源中的弱口令，您也可以使用云安全中心的基线检查功能，检查服务器中是否存在高危弱口令风险，并根据提示进行修改。

三、账号开启多因素认证（MFA）

Multi-Factor Authentication (MFA，多因素认证) 是一种计算机安全技术，要求用户提供两个或更多独立的身份验证因素，它能够在用户名和密码之外再额外增加一层安全保护。

启用MFA后，用户登录阿里云网站时，系统将要求输入用户名和密码（第一安全要素），然后要求输入来自其MFA设备的动态验证码（第二安全要素），双因素的安全认证可以为账户提供更高的安全保护。

阿里云账号（主账号）绑定多因素认证设备后，只针对阿里云账号（主账号）生效，不会影响RAM 用户（子用户）的登录，因此建议分别为阿里云账号绑定MFA设备和为RAM用户绑定MFA设备。

启用MFA设备后，下次登录阿里云时将强制验证安全码，请确保账号使用人能够获得安全码。

四、按需为 RAM 用户分配最小权限

您应该根据使用者的实际业务场景和需求，配置对应RAM子账号的权限，一般建议参考以下几个原则：

1. 控制台用户和程序用户分离：不建议为一个RAM用户同时创建用于控制台操作的登录密码和用于API调用的AccessKey，应用程序用户和人员用户应该分离，避免混用；

2. 限制高危权限的分配：高危权限包括 Admin、变更RAM身份、变更账单和费用配置、变更云资源配置等。建议拥有高危权限的RAM身份数小于等于3个，针对人员身份，建议根据人员职能划分权限，例如：系统管理员、网络管理员、数据库管理员、安全管理员等；针对程序身份，非必要不授予高危权限；

3. 对操作范围进行精细化授权：对RAM用户授权时，应限制在某个云服务的部分操作权限，尤其是数据类产品的访问，必须进行精细化授权，避免通过通配符*进行批量授权；

4. 避免不同人员共用RAM账号：为不同的员工、不同的应用分配不同的RAM用户，避免不同人员或业务应用间共用账号，同时进行最小化授权，当发生问题时，可以快速追溯到具体的账号；

5. 对职责相同的RAM用户分类授权：当企业涉及多种运维需求，比如数据库、网络、安全等，可创建不同的用户组，通过RAM管控多运维人员的权限。

作为管理员，您需要持续对账号下的RAM用户权限进行治理，阿里云提供了以下工具帮助您及时发现和处理RAM用户权限管理中存在的缺失和问题：

1. 身份权限治理：开通身份权限治理后，阿里云将持续检测账号下身份权限的安全风险，包括AK使用、RAM用户管理、MFA管理、弱密码等问题的检测，并提供对应的治理方式；

2. 权限审计：使用权限审计功能，可以识别RAM身份所拥有的权限，以及权限的最近访问时间，对于长期未使用的权限，应从RAM身份中删除，从而遵循RAM身份的最小授权原则。

五、避免在开发中硬编码AK

大量的AK泄露事件是由于应用开发过程中的疏忽导致的，以下是一些常见的凭据泄露案例：

• 直接将AK硬编码在业务代码中，有代码仓库阅读权限的开发者均能获取到AK信息。若直接将业务代码上传到开源社区或代码托管服务，将导致AK的进一步泄露；

• 为了能够让客户端直接调用到OpenAPI，将AK写到客户端代码中。攻击者通过反编译客户端代码，获取到AK信息；

• 公开的技术文档或者分享材料中包含AK信息；

• 产品说明文档中的样例代码包含AK信息；

• 无权限控制的接口中返回了凭据信息。

在避免上述操作的同时，您应该参考下述建议，尽可能缩小凭据的暴露范围和时间：

（一）使用临时凭证替代永久AK

STS（Security Token Service）是阿里云提供的一种临时访问权限管理服务，作为一种临时授权机制，具有明确的有效期限，到期后自动失效，从而显著减少了凭证泄露可能导致的风险暴露时间。

使用时您需要先创建一个RAM角色（RAM角色是一种虚拟用户，可以被授予一组权限策略），有角色权限的RAM用户可以使用自己的AK调用AssumeRole接口，即可获得上述RAM角色的STS Token。

• 当ECS实例或部署在ECS实例上的应用需要访问其他云资源时，建议使用实例RAM角色；（InstanceRamRole）后创建临时访问凭证，调用阿里云API，进行跨服务访问或数据操作；

• 当您使用容器服务时，应当禁止集群内的应用通过ECS或ECI实例元数据获取实例关联角色对应的临时凭证，不为实例关联角色授予任何RAM权限策略，此时可以使用RRSA功能，赋予集群内应用通过RRSA功能获取访问云资源OpenAPI的临时凭证的能力。

（二）AK接入KMS密钥管理服务

尽管我们在先前的讨论中提倡采用STS token作为授权手段，但在某些独特情境下，使用AK（访问密钥）或许仍然在所难免。在此类情况下，推荐您使用KMS密钥管理服务管理及使用RAM凭据，以此来确保敏感凭证的安全保管。

当您授予KMS管理RAM用户AK的权限后，即可使用KMS提供的RAM凭据插件、阿里云SDK从KMS获取RAM凭据值并缓存在应用程序的内存中，然后向云产品发起请求。

（三）配置系统环境变量减少AK暴露

如果以上方式仍不能满足您的业务使用场景，您还可以通过配置系统环境变量ALIBABA_CLOUD_ACCESS_KEY_ID和ALIBABA_CLOUD_ACCESS_KEY_SECRET，创建默认的访问凭证。

调用接口时，程序直接访问凭证，读取您的访问密钥（即AccessKey）并自动完成鉴权，避免在代码或配置文件中直接使用Access Key（AK）等敏感信息，以免当代码泄漏或者误上传至外部时，AK等敏感信息也被泄漏。

六、建设完整的账密、AK回收机制

虽然凭据的持续管理在组织内的落地存在一定难度，但阿里云仍然建议您实施本项建议中的做法。因为，当租组织内的人员发生变动、或其他针对凭据的安全措施存在漏洞时，账密/AK 的回收机制能够有效避免损失并将影响控制在最小范围。具体策略应涵盖以下两点：

• 人员离职与转岗时回收账号：将阿里云账号的回收工作加入人员离职或转岗流程，当员工离职或发生岗位调整，根据实际情况完成账号停用、权限回收等关键操作。

• 定期轮转AK：若您的业务使用KMS密钥管理服务，可参考《动态RAM凭据概述》完成AK自动化轮转。否则，建议您参考《轮转RAM用户的AccessKey》制定定期AK转换计划，比如每季度更换一次，以降低长期使用同一凭据的风险。