背景

近日发生了公有云 aksk 泄露的问题。导致部分 bucket 被暴露在公网。就此事件的补救措施是更换泄露的aksk，并实施定期轮转aksk。

其实在此之前，也陆续发生过几次由于开发人员疏忽大意导致的泄露，影响面有大有小。本文会简单谈谈怎么建立起制度，以及哪些措施可以有效提前规避问题。

‍

场景分析

先介绍下业务环境：目前的多云场景下，80% 以上的 aksk 用于访问对象存储服务。剩下的20%，用于调用其他各类不同的云服务。

‍

事前准备

基调

权限分配的根本原则是：最小化授权。

即如果用户只需要 get 指定实例，就不要再给其他的额外权限，例如put、delete，甚至直接扩散到其他实例。

‍

aksk 权限 和控制台权限分离：

用于登录控制台的子用户，不开启 API 编程访问。

‍

对象存储 aksk 管理

这里先谈谈，云厂是如何控制用户访问对象存储的。

‍

对于对象存储，大部分云厂策略分配的方式有三类：

• 桶权限配置，一般区分为三种
  • 公开读写
  • 公开读
  • 私有
• Bucket 授权策略
• 用户访问控制

‍

非必要情况下，桶权限配置应当设计为私有，除非桶本身需要对全网公开。例如阿里云的桶需要被腾讯云的cdn访问，且桶本身只存储非敏感可公开的对象。

‍

以一个简单需求为例，在 AWS 云厂根帐号 123456789 下，期望读取对象存储 testbucket-pyw​ 的object，应该怎么做？

有两种授权方式：Bucket 授权策略 & 用户访问控制

‍

Bucket 授权策略

此方式将 桶​ 作为授权的 对象​。

首先我们在 根帐号 123456789 下，创建一个子用户 iam-user-a，无需在 IAM 侧授予任何策略。

然后在 testbucket-pyw​ 桶侧添加权限，允许用户 arn:aws:iam::123456789:user/iam-user-a​ 读取 object。

​​

{
  "Id": "Policy1701851562874",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Stmt1701851553931",
      "Action": [
        "s3:GetObject",
        "s3:GetObjectAcl"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::testbucket-pyw/*",
      "Principal": "arn:aws:iam::123456789:user/iam-user-a"
    }
  ]
}

策略编写可参考：AWS S3 策略生成器

‍

用户访问控制

此方式将 用户​ 作为授权的 对象​。

首先我们在 根帐号 123456789 下，访问控制 IAM 中配置策略：

​​​​

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "s3:GetObjectAcl",
                "s3:GetObject"
            ],
            "Resource": "arn:aws:s3:::testbucket-pyw/*"
        }
    ]
}

策略保存完毕后，创建一个子用户 iam-user-a，授予刚才生成的 IAM 策略。

‍

‍

根据策略 json 可以很明显分析出两者的差异。

Bucket 授权策略：策略中需要同时指定 Resource​ 和 Principal​

用户访问控制：策略中只需要指定 Resource​ ，Principal​无需配置。因为策略会绑定在 Principal​ 即子用户 之上。

‍

至此可以得出结论：

• 当 子用户 和 bucket 归属同一个根帐号下时，两种方式都适用。

• 当 子用户 和 bucket 归属不同的根帐号时，只适用于 Bucket 授权策略​。

‍

我们当前生产环境下，大绝部分场景是 子用户 和 bucket 归属同一个根帐号。选择哪种方式授权见仁见智，取决于后续做安全分析时，你会选择 子用户​ 还是 桶​ 作为分析的对象。

我更建议使用 用户访问控制​来进行权限控制，因为我们在进行用户安全分析时，对象是 用户​。桶 仅仅是众多云服务的一类。

‍

当我们在 用户访问控制​来进行桶的权限控制时，也请满足 最小化授予 的原则。单一用户只访问单一桶，而不在策略中授权访问多个桶。

‍

其他服务 aksk 管理

服务类型众多，使用场景也不频繁，所以此处不展开过多。

仅从共性来讨论，首先还是满足基调：

1. 最小化权限分配
2. 单一需求分配单一用户，不要多业务多人混用同一个子用户的aksk。

‍

‍

事后排查

上面描述的都是事前采取的措施，实际实施过程中，往往会有疏漏。以及已经不满足设计规范产生了风险，我们应该如何事后补救？

‍

aksk 管理工具

这里需要设计工具类产品，我们也正在进行中。

‍

产品大致的功能需求应该满足：

1. 全量获取到所有云厂账号及其子账号aksk
2. 子账号与具体业务或人员建立关联
3. 获取 aksk 的最后 调用时间 & 调用服务 & 调用资源
4. 全量获取到 IAM 子账号策略
5. 全量获取到桶和桶策略以及其他常用云服务策略
6. 关联分析子账号策略和桶策略。定期提醒超过半年时限的需轮转；分析高风险策略并提醒更新策略。

‍

aksk 轮转

aksk 轮转需要业务侧配合变更配置，变更可能存在风险，总结一些轮转的实践规范：

‍

总结

aksk 的安全问题本质上属于数据安全领域，涉及多云厂，多产品，多业务场景。铺开来实现其实难度很大，效率和安全永远是天平的两端。

对不同的云厂而言，可能各自会有一些手段来加强安全，例如 kms​ ，sts​ 等。

但是在多云环境下，依赖单一云提供的能力无法很好兼容所有的场景。还是依赖内部流程和平台的建设。

‍

‍

引用链接

• AWS S3 策略生成器