【讨论】云上accesskey安全使用（云上office）

## 什么是 accesskey

accesskey 是用于身份验证和访问阿里云资源的凭证，包括 Accesskey （用于标识用户）和 AccessKeySecret（用于校验），在 RAM 模块中生成。Accesskey 不用于控制台直接登录，而是用于开发工具（API、CLI、SDK、Terraform 等）访问阿里云，发起的请求会携带 AccessKey ID 和 AccessKey Secret 加密请求内容生成的签名，进行身份验证及请求合法性校验。

如果 Accesskey 泄漏，可能会导致资源滥用、数据泄漏、费用损失、身份冒充的风险。

## accesskey 如何保护

### 使用前

1、针对人员岗位的工作需求分配权限，权限分配按照小权限原则；

先明确业务场景，在不影响当前业务运行的前提下，尽快缩小疑似泄露的 AccessKey 权限，限制高风险权限，降低业务和资费受损的风险。在 AccessKey 禁用和删除之前请不要解除该策略（限制高风险权限）的授权。

建议限制的高风险权限，例如：禁止该 RAM 用户在访问控制（RAM）中创建新的 RAM 用户及授权，禁止 ECS、RDS、OSS、SLS 资源的释放，禁止发送短信等。

例如下面的配置，对于敏感云上资源操作全部禁用。

```json
{
"Version": "1",
"Statement": [
{
"Effect": "Deny",
"Action": [
"ram:AddUserToGroup",
"ram:AttachPolicyToGroup",
"ram:AttachPolicyToRole",
"ram:AttachPolicyToUser",
"ram:ChangePassword",
"ram:CreateAccessKey",
"ram:CreateLoginProfile",
"ram:CreatePolicyVersion",
"ram:CreateRole",
"ram:CreateUser",
"ram:DetachPolicyFromUser",
"ram:PassRole",
"ram:SetDefaultPolicyVersion",
"ram:UpdateAccessKey",
"ram:SetPasswordPolicy",
"ram:UpdateRole",
"ram:UpdateLoginProfile",
"ram:UpdateUser"
],
"Resource": "*"
},
{
"Effect": "Deny",
"Action": [
"ecs:DeleteInstance",
"ecs:DeleteInstances",
"ecs:DeregisterManagedInstance",
"ecs:ReleaseDedicatedHost"
],
"Resource": "*"
},
{
"Effect": "Deny",
"Action": [
"rds:DeleteAccount",
"rds:DeleteDatabase",
"rds:DeleteDBInstance",
"rds:DestroyDBInstance"
],
"Resource": "*"
},
{
"Effect": "Deny",
"Action": [
"oss:DeleteBucket",
"oss:DeleteObject",
"oss:PutBucketAcl",
"oss:PutBucketPolicy"
],
"Resource": "*"
},
{
"Effect": "Deny",
"Action": [
"log:DeleteLogStore",
"log:DeleteProject",
"log:PutProjectPolicy",
"log:DeleteProjectPolicy"
],
"Resource": "*"
},
{
"Effect": "Deny",
"Action": [
"dysms:CreateProductNew",
"dysms:CreateSmsTemplateNew",
"dysms:AddSmsTemplate",
"dysms:SendSms",
"dysms:SendBatchSms"
],
"Resource": "*"
}
]
}
```

2、针对员工/服务器终端和网络侧建设安全防护能力，防止因为黑客攻击导致 Accesskey 泄漏；

3、开启主账号和特殊账号的 MFA 多重验证，避免权限较大用户 Accesskey 泄漏，导致严重破坏。

### 使用中

1、针对开发人员的安全宣贯，提高开发人员安全意识，要求开发人员遵守安全编码规范，安全测试规范，工作时时应注意数据保护，不随便记录 Accesskey，不外发代码和开发文件；

2、针对开发人员的开发环境配置云桌面/数据沙箱/加密等措施，避免 Accesskey 从员工开发环境中外泄；

3、定期轮转替换代码中的 Accesskey ，避免旧代码泄漏产生影响

4、对软件客户端进行软件防破解加固，防止攻击者从软件客户端中逆向获取 Accesskey。

5、使用 KMS 来存储托管 Accesskey，相当于配置一层代理防护，Accesskey 不会在外使用，而是直接使用云接口来处理接口访问的问题。

6、避免使用权限较大的阿里云账号，特别是主账号。

7、避免将 Accesskey 直接硬编码写入软件中。

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

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

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

1、Accesskey 泄漏巡检

首先阿里云有 Accesskey 泄漏检测能力（但是这个能力有个小问题，就是泄漏检测不及时，有时候使用泄漏 ak 好几天了才出一个告警）（记得把阿里云的通知打开，及时关注阿里云的通知）

为了弥补这个告警不及时的问题，也可以自己新建一个告警策略，根据 AK 的调用失败次数（比如调用被拒绝）、AK 的调用行为（比如探测/新建/删除行为）、AK 的调用 IP（是否是业务名单内的）这些参数进行配置，一旦检测到这些参数异常，那就对外告警。

2、Accesskey 巡检

在互联网平台上（特别是 github、gitee 之类的代码平台）对 Accesskey 泄漏情况进行巡检，及时发现泄漏的代码，它可能出现在项目代码、客户端、技术文档、产品说明文档甚至就一个普通的 txt 文件中。

3、Acceskey 的定期检查

在 RAM 上，定期检查 accesskey，检查 Accesskey 的权限是否配置正确，检查 accekey 是否被使用，对于停用的 Accesskey 及时删除。

4、周期性检查账单情况，发现账单是否有异常变动

在实际工作中，作者所在场景就有通过账单异常发现风险的案例。

5、开启操作日志审计，将日志保存到 OSS 或者 SLS 中以便后续审计溯源。