没有遵循 Secure by Design 而建的系统，整改就是噩梦

笔者的公众号写作停了好久。原因是忙。忙什么？

在无文档、代码无历史无注释，甚至部分客户端无源码等“百无”条件下，彻底地修补一个系统的严重安全问题——也就是等保测评常说的“系统整改”。

这个系统的安全问题，还是笔者自己做的渗透测试（AI辅助渗透测试之如何对甲方说明API安全问题（利用HAR记录文件））发现的......一个人的大包大揽了属于是（早知如此，连渗透测试都不去做，净折腾自己）。

言归正题。“Secure by Design” 是一个广泛采纳的安全设计原则术语，强调在系统开发生命周期的最初阶段就将安全性内嵌于架构与设计之中。

有些翻译直接译为“安全设计”，又或者“设计即安全/设计保安全”，但这其实和术语中的 “by” 所带来的语境有偏差，笔者认为应强调安全和设计之间的关联性，即表述为“以设计致安全"，方更显准确。

如果系统的设计并未考虑安全因素，整改就是噩梦。其实，这就是甲方实施网络安全（比如等保测评）时可能会碰到的最大困境：

安全测评管杀不管埋——发现系统存在基础设计方面的安全问题时，什么体系、框架、措施、设备实际都只能两手一摊。

本文中，笔者发掘和修补安全风险的这个系统，偏偏就是这么一个在设计时完全没有考虑安全因素的系统，Secure by Design 基本为零。

在发现的问题中，笔者简单举个例子：这个系统的API没有设计任何机制去校验发起调用的客户端是否可信，而且API参数是设计为直接使用系统核心数据对象的数据记录ID值。

要发起 D.o.S 攻击简直不要太容易。至于数据篡改、泄漏之类问题就不细说了——总之连用户隔离都未彻底实现，就可想而知。

很显然，这种从一开始就设计错了而导致的安全问题，是无法简单地用什么安全设备或外挂补丁就能解决的。

正常来说，应找回原开发者整改，但原开发者已经提桶跑路了......所以，要不让甲方另外找人重写一套？

甲方马上开始打算盘：重写要花多少钱？系统不能停用，重写开发期间如何保证安全？又或者......我能不能侥幸一下？

所以，这不仅仅是 Secure by Design 要如何在软件工程上贯彻的问题，是更进一步地，网络安全行业不能局限于狭义上的网络安全，还应该具备帮甲方从根本上解决风险的能力的问题。

这需要：

• 清晰地向甲方描述不安全的系统设计会带来什么风险和后果。

面对真实风险，没有什么售前售后。只有说清楚了问题，才能对冲掉甲方普遍存在的侥幸心理。 

• 准确地向甲方提出怎样的安全设计可以消除现有的风险。

网络安全并不能狭义地用攻防概括，“分析—设计—实现”三部曲的软件工程能力依然是核心能力。

• 恰当地为甲方评估实施安全设计全过程所需要耗费的资源。

资源永远有限，时间、人力和金钱无一不是制约，要基于换位思考才能与甲方达成共识。 

• 灵活地为甲方编排保障业务持续稳定运行的整改过程步骤。

皮之不存，毛将焉附？为保障业务正常运行，整改的部署过程必然比新系统上线要复杂得多。

• 负责任地为甲方完成系统的整改过程。

不排除在整改过程中还会发现原来没有发现的安全风险。负责任地整改，就应先采取措施控制和消除风险，急甲方之所急。

笔者也清楚，要能做到以上5项并不容易，但以前说做IT要懂业务，现在一样说做安全要懂业务，只做系统防护而不切入系统业务逻辑，懂业务就是空话一句。

现实中，网络安全常被外围化。但软件工程在设计阶段留下的缺陷，后续无论投入多少防护资源，都难以弥补基础性风险。就如一个未校验客户端身份、直接暴露核心数据ID的API，其脆弱性不会因部署任何安全设备而消失。

有效的整改高度依赖于软件工程能力：需在不中断业务的前提下协调接口兼容、分阶段灰度、控制未知风险。这要求安全人员不仅理解威胁，也熟悉系统架构、发布流程和成本约束。

甲方对整改的犹豫往往源于对影响范围和投入产出的不确定。若方案无法清晰对应到可执行步骤和资源需求，再正确的原则也难以落地。

所以，Secure by Design 并不仅仅是对软件工程的一项要求，更应该是网络安全与软件工程结合的契机，因为问题是在网络安全一侧发现，要完美闭环，最理想的状况必然是连环都不出现，直接闭合。

顺带概括说说笔者这次整改的部署过程。因为该系统包括后端管理系统和API接口、前端多种APP和网站等若干个子系统，且子系统基本不可能实现同步升级，故此，需要设计有兼容能力的升级部署过程（即灰度发布）如下：

1、后端的整改需要在保留兼容未升级的客户端的前提下，实现安全设计。

2、把网站和逆向还原得到的客户端APP，整改实现安全设计。

3、升级部署新的后端——因为保留了兼容能力，此时的新后端并不安全，但已经部署的客户端全都可以继续运行，业务不中断。后续期间或许也要持续发布后端的修正版本，但始终保留兼容性。

4、逐步分批升级前端APP和网站，在真实环境中快速迭代，修正整改过程可能引入且未能在测试时暴露的BUG。

5、在前端APP和网站已经全面替换且达到一定稳定程度后，取消后端保留的不安全的兼容性，然后重新部署，从而使后端达到设计的安全。

以上过程在执行前还应该生成流程图及甘特图作为形象化的说明和引领。

最后，或许会有人想知道：究竟是什么人开发的系统能如此无视安全性。笔者不好开地图炮，所以拐弯抹角地说：

为何从 Win 10 开始到现在 Win 11 都一直这么多Bug ，甚至连补丁也会是 Bug ？雇的程序员都是些什么人？

注：题图为笔者自行拍摄，十二门徒石。

~ 完 ~

本站微信订阅号：

本页网址二维码：