协同共建｜深入分析应用密钥安全治理之术

文｜应用漏洞扫描Oteam、PCG安全团队

Martinzhou

I. 背景

当前，各类开放平台、依托云原生技术模式的PaaS/SaaS服务涌现，密钥（Credentials / Secrets）成了跨服务、跨平台调用认证的关键一环。短短几十个字符，背后往往通向上万台CVM或者整个业务数据。好似露出洋面的一角冰山，稍往下深挖，底下可能就是牵动企业安全命脉的“金山银山”。

当前，针对个人用户登录密码的保护技术日臻成熟，基于短信验证码、指纹、人脸或是物理设备的多因子验证获得较为广泛的落地。但用于服务与服务间认证的密钥，往往未获得同等力度的安全保护。

针对上述与应用密钥有关的风险，本文将从研发及数据安全视角，结合近期实践，从四方面探讨可采取的治理思路，以求抛砖引玉，也欢迎大家参与共建，共同探索。阅读本文，你将收获：

有哪些存在风险的敏感密钥？

如何检测敏感密钥泄露？

开发人员如何安全地使用密钥？

业务系统如何安全地设计密钥？

II. 密钥安全四问

2.1 有哪些存在风险的敏感密钥？

知己知彼、百战不殆。在着手扫描清查密钥风险前，可以先对业界各类常见的密钥类型做梳理。否则容易陷入疲于应对已暴露密钥，case by case添加规则。基于我们的实践，分享可参考分类思路如下：

值得一提的是，各企业内部可能也建设了一系列PaaS、SaaS平台，可根据自身实际情况酌情梳理、纳入风险评估。

接着，就需要评估已梳理各类密钥关联的风险（如，会导致数据被匿名访问）及检测特征（如，密钥自身存在的显著特征，详参见2.2.1部分讨论）。梳理思路可以表格形式记录，参考如下：

2.2 如何检测敏感密钥泄露？

 2.2.1 敏感密钥概况 

场景一、匹配密钥本身的特定格式

密钥本身有很强的特定格式，可以直接用正则匹配。例如，

腾讯云appid会以AKID开头，例如：AKIDxxxx
Github服务间相互调用的密钥以ghs开头，例如：ghs_tVGHE4***666222

匹配方式简单直白 —— 写正则匹配密钥本身。例如，针对在代码中硬编码腾讯云密钥的风险，使用开源静态代码检查工具semgrep，不难快速编写出扫描规则：

pattern-regex: (AKID)(?i)[a-zA-Z0-9]{32}\b
pattern-not-regex: q-ak.+(AKID)(?i)[a-zA-Z0-9]{32}

场景二、匹配密钥及所处的代码结构

现实场景中我们会发现，绝大部分密钥本身没有很强的特征