浙江阿里企业邮箱凭据的安全使用方案

  常见的凭据类型有AccessKey（简称：AK）、临时安全令牌STS Token。

常见的凭据泄露案例

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

2.有些用户为了能够让自己的客户端直接调用到OpenAPI，将AK写到客户端代码中。攻击者通过反编译客户端代码，获取到AK信息。

3.开发者的技术文档或者分享材料中包含AK信息。

4.产品说明文档中包含的样例代码，包含AK信息。

5.用户无权限控制的接口中返回了凭据信息。

安全使用方案

  实现凭据安全使用方案的主要思路：避免研发阶段不必要的凭据传递与硬编码。

避免使用阿里云账号AK

  由于阿里云账号（主账号）拥有资源的所有权限，其AK一旦泄露风险巨大，强烈不建议使用阿里云账号AK。

避免在代码中硬编码凭据

  尽量避免在代码中直接编写凭据信息，可以将凭据信息写入到系统环境变量中，代码读入环境变量。以在环境变量中设置AK为例，您需要配置系统环境变量ALIBABA_CLOUD_ACCESS_KEY_ID和ALIBABA_CLOUD_ACCESS_KEY_SECRET。

使用密钥管理服务托管凭据

  密钥管理服务（Key Management Service）支持托管凭据，更多信息请参见凭据管理概述。如果您的凭据是RAM用户的AK，您可以使用凭据管家功能对已托管的RAM凭据进行定期轮换或立即轮转。您可通过在应用程序中安装RAM凭据插件的方式接入凭据管家，在应用程序执行过程中动态获取到有效的凭据，从而避免在代码中硬编码AK信息。

使用实例RAM角色

  ECS实例、ECI实例、ACK的Worker节点均支持实例RAM角色。通过调用ECS的元数据服务（Meta Data Server）换取临时安全身份凭证STS Token，避免AK硬编码，降低AK泄露的风险。

使用RRSA功能

  在容器服务 Kubernetes 版中，一个集群可以部署多个服务，同一个容器节点可能包含多个不同服务的Pod，在多租户场景下，若部署不受信任的服务，该服务可直接访问ECS的元数据服务（Meta Data Server），获取Worker节点关联实例RAM角色的临时令牌STS Token，会造成身份权限的泄露。RRSA实现Pod级别的权限隔离，该功能可自动将OIDC相关的信息注入到环境变量中，您可使用Credentials工具换取临时访问凭据STS Token。

使用Credentials工具包

  Credentials工具包封装了获取和管理凭据的功能逻辑，同时其默认凭据链功能更是能够有效避免硬编码凭据信息。

云安全中心AK泄露检测

  云安全中心实时检测GitHub平台公开源代码中阿里云账号或RAM用户的访问密钥AK信息，可识别出AK是否泄露，并提供相应的告警，建议您及时查看并处理外泄的AK事件。

凭据泄露处理

AK泄露

1.禁用或删除AK

  如果您的AK发生泄露，首先要对相关的AK进行禁用和删除，并轮换使用新的AK。详情请参见禁用RAM用户的AccessKey、删除RAM用户的AccessKey。

2.查询AK相关事件

  您可使用操作审计（ActionTrail）的AK审计功能，查询AK基本信息、访问的云服务及相关IP地址和资源，该功能可帮助您追溯AK使用信息，以便快速应对AK泄露等异常事件。

STS Token泄露

  虽然STS Token是临时的身份令牌，但其有效期的区间为15分钟~12小时。如果STS Token发生泄露，依旧存在非常大的安全风险，您可以按以下步骤回收所有已经颁发的STS Token。

1.使用阿里云账号登录RAM控制台。

2.移除RAM角色的所有权限策略。

3.删除RAM角色。

  删除RAM角色后，所有通过扮演该RAM角色获取的且未过期的STS Token都将立即失效。

如果您还需要使用该角色，您可以重新创建同名角色并授权相同的权限策略，使用新创建的角色继续完成您的任务。