云计算时代的虎符龙节
在云计算蓬勃发展的当下，云上安全问题无疑变成了头等大事，而AKSK无疑又是云安全问题中不可忽视的一部分。
AKSK在本质上代表了一种身份认证，作为云上最容易泄露但同时也是最为敏感的数据，云平台通过对AKSK进行身份认证鉴权，来确认用户是否合法访问云平台，以及可以访问哪些云资源。通过AKSK鉴权的用户，便可以自由穿梭于云平台的各种资源中，操作租户自有权限下的各种资源与数据。
机事不密祸先行
近年来，因为AKSK泄露带来的各种网络安全和数据安全问题层出不穷，AKSK的泄露将会直接导致用户在云平台的各种云资源被恶意操作修改，用户在云平台的数据被恶意窃取，造成的影响不可谓不大。
在所有的AKSK泄露案件中，几乎都可以归纳于以下几点原因：
- AKSK安全存储手段缺失，最直白的如硬编码到业务代码中并上传github，其次也有明文配置到配置文件并在日志中任意打印等等。
- AKSK业务隔离手段缺失，比如多个业务共有一对AKSK，这样任何一个业务造成的AKSK泄露都会导致其他业务受影响。
- AKSK安全分发手段缺失，比如直接通过微信、企业微信等即时通讯工具对AKSK口口相传等等。
AKSK的安全管理问题，是一个技术问题，但绝对不单单是一个纯技术问题，它也是一个安全运营的问题，技术能力只是兜底的一种手段，而有效的运营管理机制则是避免风险的前提。
扬汤止沸，劳而无功
当然现在市面上并不是完全没有AKSK的保护手段，只不过其功效有限，而后患无穷。
比较常见的一种“强硬手腕”，就是直接对AKSK做来源IP的限制，只允许白名单内的IP访问，这种做法的效果是立竿见影的，但是，作为一款已经上云的业务，使用如此“老态龙钟”的方式对AKSK做保护，却丧失了云计算本应该带来的灵活性、拓展性，实在是捡了芝麻丢了西瓜，得不偿失。
当然也有另外一种直接的方式，比如将AKSK与云服务器绑定起来，云服务器各种系统信息可以作为指纹参与AKSK身份认证的计算，云服务器由于有完整的操作系统，即使关机重启，也不用担心像docker pod一样环境信息发生改变，这样确实是一种有效的措施，但是这样一方面需要云平台能提供AKSK与云服务器绑定的能力，另一方面，也基本相当于舍弃了业务部署在docker环境上的可能性。业务部署在docker上的好处自然勿须多言，它相较于云服务器有更低的成本、更好的拓展性、更强的环境一致性等，对于以商业利润为最终目标的业务来说，是无法忽视的诱惑。
当然，也有一部分人觉得，既然这样，我们自己来保护，比如我生成一把密钥，使用密钥自行加密AKSK，这个密钥我自己保存，这样还不行吗？嗯，这里必须要承认一点，对AKSK做加密保护本身是一个值得探索的方向，而且也一定是最终需要实践的方向。但是，自己生成密钥给AKSK加密，这样风险其实又转移到了密钥安全性上。
现在有互联网的国家，基本都有自己的密码法、信息安全法，我国也不例外。这里没有必要大费周章的展开那些已有的法律法规来论证什么样的密钥是安全的，其实我们对于密钥安全的问题，有一个最基础的门槛，即：你的密钥是否是由国家密码局认证过的设备生成和保护的。只这一条，就可以扼杀大部分期望通过自己生成的密钥来对敏感数据做加密的想法。
话说回来，如果你真的有了自己的受国家密码局认证的加密机，自己搭建了一整套密钥管理系统，那你确实可以自己生成密钥来保护自己的AKSK了，但是，这又涉及到成本的问题了，还是那句话，对于以商业利润为最终目标的业务来说，这种成本和长期运维的消耗，可能是一种形式的不可承受之重。
也有一些人想到了需要依赖于云平台的能力，不能光自己在那闭门造车，比如很多时候总是有人咨询，能不能通过腾讯云的KMS系统对我的AKSK加密呢？这其实又陷入进了一个鸡生蛋还是蛋生鸡的怪圈了。要知道KMS本身也是腾讯云的一款产品，如果用KMS对你的AKSK保护了，那么当你要对它解密时，你必须得访问KMS吧？而你访问KMS，有需要明文的AKSK吧？
看起来，AKSK的保护问题似乎无解了？
纲举目张，度知长短
前面讲了这么多AKSK保护的难点和问题，难道就真的没有办法对它进行保护吗？
办法肯定是有的！
只不过我们得换一种思路，不破不立！
我们不妨从一个更高的视角来看待这个问题，假设，我们不再把AKSK作为云平台的根凭据，而是将他作为某种数据资产，可以让云平台来帮我们管理。
此时一定引起另一个问题，前面也分析到了，如果AKSK保护在了云平台上，那么访问云平台不是也需要AKSK么？这个AKSK又从哪里来？
其实很简单：用另一个AKSK来访问。
前面我们已经分析过，对于AKSK保护的场景，他其实是需要一定的运营机制辅助的，技术手段并不能从根本上解决这个问题，此时不妨我们逻辑推导这样一种思路：
首先，毫无疑问，云资源是可以通过对账号进行授权的方式，达到访问权限的管理的，这是基础之一；
其次，显而易见，现在成熟的云平台，必然是允许根账号生成子账号的，且每种子账号本身的访问权限是可以由根账号制定的，这是基础之二。
基于以上两个基础，不放我们再大胆一点，假设我们将业务需要的AKSK数据存储到了云平台上，成为了一种凭据资源；
接着，我们再生成一个权限受限的子账号，这个子账号被授权只能读取某个凭据资源；
当业务需要访问某些云上资源时，它首先需要用小权限的AKSK来拉取托管凭据，进而根据托管凭据中的AKSK再去访问云上资源；
现在看起来似乎有点眉目了，但是，新的问题再次出现了，小权限的子账号的AKSK又怎么保护呢？
绕了一圈问题似乎又回到了原点？
四两拨千斤：一种基于腾讯云SSM和白盒密钥的综合解决方案
前面铺垫了这么多，我们终于可以进入正题了。
前面我们已经讨论了一种看起来似乎可行的方案：将问题从保护大权限AKSK，转化成了保护小权限的AKSK。
这里就不再绕圈子了，要推荐的方案就是：通过对子账号进行三权分立式的职责拆分，结合SSM的安全托管能力，同时使用白盒密钥对小权限的AKSK在不可信环境下的保护，来达到对AKSK的安全保护的效果。
上述的几个步骤，可以描述为如下：
1. 使用主账号分别创建只写子账号与只读子账号
2. 使用只写账号在SSM上创建一个自定义凭据A，自定义凭据中存放用户真实的业务AKSK。
3. 对只读账号进行CAM授权，明确限制只读账号只允许访问凭据A。
4. 使用主账号生成只读子账号的AKSK。
5. 将只读子账号的AKSK，使用腾讯云KMS的白盒密钥产品加密，
6. 步骤4中生成的密文和白盒解密SDK以及相关IV等交付给业务
7. 业务在进程启动时，首先通过白盒密钥解密AKSK密文，获取到只读子账号的AKSK明文，然后通过只读子账号的AKSK去访问凭据A，获取到凭据A的明文，业务拿到凭据A的明文后，在业务中使用业务明文AKSK去访问真实的业务资源。关于白盒密钥
接下来花一点篇幅对白盒密钥做一下科普。
白盒加密，与传统对称加密的区别在于：白盒的密钥与算法是经过混淆的，白盒解密密钥中不存在密钥的明文。
传统的加密方式，密钥必须要完整出现才能够正常解密，为了能正常解密，则必须要保证密钥完整出现在不可信环境下，这时无论你怎么隐藏密钥，即使是编译成二进制的动态库，攻击者都有办法分析出完整的密钥明文，而且只要攻击者拿到密钥明文，由于传统加密算法的公开性，攻击者甚至可以自己编写出解密程序进行密文的正常解密，举一反三，这里对于IV的保存也是有这样的问题。
而白盒加密技术，将算法和密钥进行深度融合，对密钥进行复杂的数学运算，进而把密钥信息隐藏在二进制混淆密钥库中，在程序运行的任何阶段，密钥均以一个巨大的查找表的形式存在，在任何情况下密钥都不会以明文形式出现，可以有效的隐藏密钥。同时在整个过程中，原始密钥始终被加密隐藏，不会存在在内存中，从而防止密钥被静态分析和动态调试。
黑客如果想解密，就必须获取完整地二进制混淆密钥文件与白盒SDK，否则，使用传统的对称加密算法无法对密文进行解密，这种保护机制可以有效抵御不可信环境下的密码学攻击手段，这种方式增大了对密文破解的难度。
这里可能读者还是会有疑问，那我用白盒密钥解密时，就不需要AKSK了吗？
答案是：不需要了。因为客户一旦使用白盒密钥完成加密后，密文、密钥、白盒SDK就可以离线工作了。不再依赖于云平台的解密能力。
关于SSM
凭据管理系统（Secrets Manager，SSM）基于密钥管理系统 KMS为用户提供凭据的创建、检索、更新、删除等全生命周期的管理服务，结合资源级角色授权轻松实现对敏感凭据的统一管理。针对敏感配置、敏感凭据明文编码带来的泄露风险问题，用户或应用程序通过调用 Secrets Manager API/SDK 来查询凭证，可以有效避免程序硬编码和明文配置等导致的敏感信息泄密以及权限失控带来的业务风险。
SSM使用KMS的主密钥CMK作为加密密钥，通过 Name-Value 的方式存储多种类型数据，Value 部分支持最大4096字节，例如数据库连接、账号密码、IP 端口等。对所管理的凭据内容进行加密存储。
使用凭据时，SDK将通过 TLS 安全传输数据到服务器本地。
关于KMS
密钥管理系统 KMS是基于硬件加密机的云上密钥管理系统，主要提供以下核心服务：
- 密钥的全生命周期管理
- 加密、解密算法（AES， 国密SM4）
- 真随机数
- 密钥的轮换等
用户的密钥由加密机进行安全的管控，国内Region密钥采用国密算法SM4进行加密，海外region 采用AES 进行加密，符合不同地域对合规性的要求。
关于只读、只写子账号CAM策略的设置
只读子账号的策略内容模版如下：
{
"version": "2.0",
"statement": [
{
"effect": "allow",
"action": [
"ssm:GetSecretValue"
],
"resource": [
"qcs::ssm::uin/${主账号UIN}:secret/creatorUin/${资源创建者UIN}/${资源ID}"
]
}
]
}其中，将：
- ${主账号UIN}替换为主账号的UIN
- ${资源创建者UIN}替换为新建的子账号的UIN
- ${资源ID}替换为SSM中新建的凭据名
只写子账号的策略内容模版如下：
{
"version": "2.0",
"statement": [
{
"effect": "allow",
"action": [
"ssm:CreateSecret",
"ssm:UpdateSecret"
],
"resource": "*"
}
]
}小结
AKSK的安全保护，本质上，其实属于数据安全领域的一个垂直细分场景。
随着AI、大数据、云计算等方向的汹涌甚至野蛮发展，数据安全本质上已经发展成为了一个多维度多场景的老大难问题。
做好数据安全，是有难度的！
将数据安全作为一种服务提供给更多的中小企业甚至个人云租户，更是难上加难！
这种难度不仅仅来自于技术上，更多的时候也来自于人本身。
无论面对多么精妙复杂的系统，人本身永远就是最大的安全隐患。
正如本文之前所说的，保护AKSK不仅仅是需要技术水平，更多的，也需要相应匹配的运营制度加以辅助。
但是，不仅仅是面对AKSK这个场景，只要有安全问题的场景下，我们都应该记住，制度和规矩的设立都有它的道理，在工作中我们应该用严谨和理性的态度来约束自己，不要让我们人类成为一个轻易就能攻破的安全漏洞。