关于配置文件的保存方式及源代码安全审计的讨论 | 总第230周

‍‍

‍‍

0x1本周话题

话题一：请问大家的配置文件，包含明文密码的，类似mysql，redis这种，或者自己业务里边的，用什么方式保存呢？除了MSE Nacos 外，近期看到《MSE Nacos：解决敏感配置的安全隐患》。

A1：自己业务最简单，可以改程序逻辑，获取配置文件里的密文后还需要解密。redis不支持配置密文，这个无解。mysql本质属于第一种，去规范开发连接字符串，mysql自身不需要读取配置文件密码。

A2：配置中心接口取，不落盘，内存里可能有明文出现。每一次读取都是可以审计的。这应该是主流方案，之前我们自己做了本地加密的方案，难以维护，主要是 JDK 会版本冲突，以及部分应用兼容性问题。还是感觉中心化好点，不过又多了个故障点。

A3：我们以前是配置中心，对接KMS之类，管理涉密内容。后来有一些特殊的场景导致不能对接配置中心，要用配置文件，然后通过DevOps流程打包应用发布镜像的时候，将基于应用生成的加密的配置文件和应用认证信息打包到镜像中。应用启动的时候，安全这边做的一个加解密组件走一层认证到密钥管理中心获取解密密钥，并解密配置文件。至于攻击能搞到内存，我就放弃抵抗了，这种已经降维打击我了。

A4：应用评估并做好逃生，应用访问一次然后就放内存了频率倒不高，但确实是在应急时出错可以要命的东西。看看安全有没有魄力承担业务大面积挂了的风险，一般来说，这要挺强的架构能力。

A5：密码泄露导致的风险是个隐性的风险，业务大面积挂了就是一个众所周知的风险了。不光是架构，需要整个应急响应能力。

A6：职责在，就考虑，职责都不在的话，还是尊重责任部门的意见。一般来说，业务优先吧，因为安全增加业务连续性风险，得评估权衡。

A7：只能多演练，做好备份。上次阿里云和滴滴那个事故，我们就反复思考了我们现在安全这边负责的SSO,还有网络准入，这些东西有可能导致连环问题的出现，比如某个业务刮了，SSO假设正好也坏了，SASE对接SSO也用不了，办公应用登录不上去，发布系统也登录不了等等乱七八糟的。然后前两周运维团队组织了演练搞了又搞尽量丰富故障场景，做好演练。

只能通过别人家的案例补充我们的场景，多做演练。常见的就是中间件基础服务，安全基础服务、账号系统、权限系统等等。降级、备份、备用链路、反正安全这边以前出现过问题的，能考虑上的都考虑上了。这个只能靠学习别人的经验了，反正现在公司比较重视演练，会不断补充场景。

A8：还要考虑上游单点问题，我准备了3种访问家里设备的方案，vpn，向日葵，映射端口，双出口（两条联通），结果有一天联通整个挂了。

A9：看着一堆密码明文到处放，特别是数据库密码，真是心里闹心。绝大部分安全人员在运维应急响应方面能力，我觉得是不足的。虽然分工不同，不过运维应该还是基础的东西，需要了解一些。

如果安全主导搞了密码加密这一套，那么就得时时想着怎么应急处理大面积故障，怎么快速回复，这种时候安全常用的bypass模式好像不好使了，得真正想办法在限定时间内给解决问题了。

A10：安全搞性能是不专业的，这块就邀请应用运维专家来评审，就跟应用方案会让安全评审一样。但是这个事对应用和运维来说就是徒增负担的事，只有安全会考虑这个加密，如果不在这方面达成一致，肯定通不过。

A11：我就想说加密也是应用的事，起码不仅是安全的事。这是最近两年ga检查的主基调，安全不要想着自己把所有事揽了，别人不知道无感，就要有感，就要调动起来，就要上下检查 。

话题二：请问目前公司内部有没有做源代码安全审计，是自己人实施的还是外购服务呀。

A1：我们是自己做，肉眼code review。其实我们对比了下，codeql扫出来的结果比市面上的那几家好点，而且codeql还有数据流可以跟踪，比较适合人工去跟踪审计。默认的规则检出率还行，尤其是硬编码，其他的也还凑合。

A2：买了审计产品、代码扫描工具，配合安全技术人员人工复核，不过效果不是很好。你们都这么高级用上了codeql了，这个门槛应该比较高吧。

Q：逻辑漏洞怎么搞呢？一般工具也是一些编码级别的。

A3：这个就没法用白盒工具了，黑盒偏多。比如sonarqube fortify这类，不过不是针对逻辑漏洞的，这些还是要人工去审查，专业性要比一般的开发人员高，所以师傅们也是内部自己人审计么，有没有找安服公司呀。

Q：研发人员的代码缺陷之类的有做管理吗？我一直觉得源代码检测是不是放到代码质量管理里边比较好一些。

A4：我也感觉能让开发人员随时能做源代码检测比较快。最终还是要专业代码审计专家过一过。

0x2

原文始发于微信公众号（君哥的体历）：关于配置文件的保存方式及源代码安全审计的讨论 | 总第230周