身份管理

身份是指在云环境中执行操作的实体。云上主要有两种身份类型：人员身份和程序身份。

人员身份通常代表组织中的个人，比如企业中的安全管理员、运维管理员、应用开发者。通常通过阿里云的控制台、CLI、特定场景下的客户端等方式对云上的资源进行操作。

程序身份则代表应用程序或服务，往往是通过阿里云的 OpenAPI 来访问云上的资源和数据。

在阿里云上，针对两种类型的身份管理，基于安全的最小化原则，核心有两大原则：缩小暴露时长和缩小暴露面积。

缩小暴露时长指尽可能使用临时身份或凭据替代固定身份或凭据，即使使用固定身份或凭据，也建议定期轮转。

缩小暴露面积指尽可能安全保管密钥或凭据，避免在不同身份类型之间混用凭据或身份。

基于这两大核心原则，针对不同类型的身份管理，在阿里云上有以下最佳实践可以参考。

人员身份

避免使用 Root 身份

在阿里云上，注册完一个阿里云账号后，即可通过用户名和密码的方式登录到阿里云控制台，登录成功后，即获得了 Root 身份。该身份具有该账号下所有的权限，一旦账号密码泄漏，风险极高。另外，如果多人共用该身份，每个人都保有该账号的用户名和密码，会增加泄漏的可能。同时，多人共享的情况下，在云上的操作日志中无法区分出是组织中哪个人使用了该身份进行了操作，也无法进行进一步溯源。因此，除了极个别场景，应该尽可能的使用阿里云 RAM（Resource Access Management，访问控制）身份进行云上资源的访问，避免使用阿里云账号的 Root 身份。对于 Root 身份的使用，参考下述“建立更安全的登录机制”一节中的最佳实践，提升 Root 身份的安全性。

实现人员身份的统一认证

通过集中化的身份提供商（Identity Provider，简称 IdP）来进行人员身份的统一认证，能够简化人员身份的管理，确保组织内在云上、云下的人员身份的一致性。当人员结构变更、人员入、离职时，能够在一个地方完成人员身份的配置。 对于云环境的使用者来说，也无需为其颁发额外的用户名和密码（如 RAM 用户名和密码），只需要保管好其在组织内的 IdP 中的身份和凭据即可。对于一些组织而言，通过一些网络上的访问控制措施，使其 IdP 仅能够在企业内网访问，给人员身份的认证过程增加了额外一个限制条件，进一步保障了企业人员身份的安全。

阿里云支持基于 SAML 2.0 协议的单点登录（Single Sign On，简称 SSO）。在阿里云上，我们建议通过 RAM SSO的方式跟组织内的 IdP 进行集成，实现人员身份的统一认证。对于云上有多个阿里云账号的复杂组织，还可以通过云SSO进行多账号下的 SSO 集中化配置，进一步实现多账号下的人员身份统一管理，提升管理效率。

建立更安全的登录机制

对于人员身份的登录方式，往往是通过用户名和密码的方式进行。一旦用户名和密码泄漏，攻击者极有可能通过该身份登录阿里云，造成一些不可挽回的损失。因此，对于人员身份来说，保护好用户名和密码显得尤为重要。可以从以下几种方式提升登录方式的安全性：

1. 提升密码强度。如增加密码位数、混合使用数字、大小写字母、特殊字符等。针对阿里云 RAM 用户，管理员可以设置密码强度规则，强制 RAM 用户使用更复杂的密码，降低密码泄漏和被破解的风险。

2. 避免密码混用。在不同的服务、站点，或不同的用户共用一个密码，增加了密码的暴露面积，会增加密码泄漏的可能性。如果其中一个服务或用户的密码泄漏，那攻击者就可以通过尝试登录的方式，找到共用密码的其他服务。因此，确保不同服务、不同用户使用不同的密码，能够降低密码泄漏的风险。

3. 定期轮转密码。密码存在的时间越长，泄漏风险越高。通过定期重设密码，降低单个密码存在的时长，能够进一步降低密码泄漏风险。针对阿里云 RAM 用户，管理员可以在密码强度规则中设置密码有效期，来实现密码定期轮转。

4. 使用多因素验证。多因素认证 MFA（Multi Factor Authentication）是一种简单有效的安全实践，在用户名和密码之外再增加一层安全保护，用于登录阿里云或进行敏感操作时的二次身份验证，以此保护您的账号更安全。阿里云支持虚拟 MFA、U2F 安全密钥等多种二次验证方式。建议为云上的人员身份都启用二次验证。对于使用云下 IdP 进行统一身份认证的组织，也建议在 IdP 侧提供二次验证的选项。

通过角色扮演代替固定身份

基于缩小暴露面积的原则，使用临时身份替代固定身份，能极大降低身份泄漏风险，同时对于人员身份来说，也能够抽象人员权限模型，如按人员职能进行角色划分，有利于规范化人员权限设置，提升管理效率。

在云上，建议通过单点登录（Single Sign-on，简称 SSO），基于角色扮演的方式，实现人员身份的管理。

程序身份

不使用云账号 AccessKey

云账号 AccessKey 等同于阿里云账号的 Root 权限，也就是该账号内的完全管理权限，而且无法进行条件限制（例如：访问来源IP地址、访问时间等），也无法缩小权限，一旦泄漏风险极大。对于程序访问的场景，请使用 RAM 用户的 AccessKey 来进行阿里云 API 的调用。

避免共用 AccessKey

多个程序身份共用 AccessKey，或程序身份、人员身份共用 AccessKey 的情况下，AccessKey 所关联的权限需要包含所有身份的使用场景，导致权限扩大。另外，共用场景下，一处泄漏会导致所有应用都受到影响，风险扩大，同时增加了泄漏后的止血难度。对于同一个应用的不同环境，如生产环境、测试环境，往往需要访问不同的资源，同时，测试环境代码往往不够稳定和健壮，更容易有泄漏风险，如果共用同一个 AccessKey，测试环境 AccessKey 泄漏后也极容易造成对生产环境的影响，导致业务安全风险。

因此，针对不同应用、大型应用的不同模块、同一个应用（或模块）的不同环境（如生产环境、测试环境等），都建议创建不同的 AccessKey 供程序身份使用，每个 AccessKey 只有该场景下所需要的权限，避免共用 AccessKey 的情况。

定期轮转 AccessKey

同人员身份的用户名密码一样，AccessKey 创建和使用时间越长，泄漏的风险越高。每隔一段时间，通过创建新的 AccessKey，替换掉应用在使用的 AccessKey，并将旧 AccessKey 进行禁用和删除，实现 AccessKey 的定期轮转。另外，也可以通过阿里云密钥管理服务（Key Management Service，简称 KMS）的凭据管家功能，实现 AccessKey 的集中管控和自动化定期轮转。

除了 AccessKey，其余类型的程序访问凭据，都应该进行定期轮转，降低凭据泄漏风险。

使用临时凭据代替固定凭据

通过给 RAM 用户或云账号的 Root 身份创建 AccessKey 供程序调用，都属于固定凭据类型。一旦创建出来，在删除之前，就是由固定的 AccessKey ID 和 AccessKey Secret 组成了该凭据。使用固定凭据会造成很多风险，比如应用研发人员将固定 AccessKey 写入了代码中，并将其上传到了 Github 等公开仓库，造成了 AccessKey 泄漏，最终导致业务受损。在阿里云上，我们建议尽可能通过角色扮演的方式获取临时凭据 STS Token，代替固定 AccessKey 的使用。每个 STS Token 生成后，在超过角色最大会话时间（小时级）后，自动失效，从而降低了因固定凭据泄漏导致的风险。

针对不同类型的云上应用部署方式，阿里云提供了相应的功能，集成了 STS Token 凭据的使用：

1. 针对在 ECS 实例上部署的应用，通过ECS实例角色实现临时凭证的获取和使用，将 RAM 角色跟实例进行绑定，应用程序中即可通过实例元数据服务获取临时授权Token。

2. 针对在 ACK 上部署的应用，通过容器服务RRSA功能，实现 RAM 角色和指定 ServiceAccount 进行绑定，在 Pod 维度即可扮演对应角色实现 STS Token 的获取。

3. 针对在函数计算中部署的 Serverless 应用，可以通过FC函数角色实现临时凭证的获取和使用。

无论哪种部署方式，在应用代码中通过阿里云官方提供的 SDK，根据部署类型设置相应的身份验证（Credentials）配置，都可以便捷的直接获取 STS Token，无需关心具体的凭据缓存以及过期更新逻辑。