文|应用漏洞扫描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}
场景二、匹配密钥及所处的代码结构
现实场景中我们会发现,绝大部分密钥本身没有很强的特征&