随着金融企业数字化转型的发展，企业的应用系统越来越多，加之监管和风险形势越来越严峻，特别是由于每年护网工作的要求，我们越来越需要对企业内如此大量应用的安全情况进行排查和整改。这对于企业来说要付出较大的成本，往往会陷入到运动式“查漏补缺”的旋涡而无法自拔。每隔一段时间就要搞个XX专项排查，实际执行过程中各参与方都不堪其扰，倾向于采取一些“短平快”的手段，缺乏经过全面评估的解决方案，效果也很难得到长期保持。

那么有没有更好的工作方式呢？笔者认为将短期的查漏补缺与长期的架构管控相结合或许是个不错的选择。

查漏补缺通常有两种情况，一种是解决上线前遗留的风险，另外一种是解决上线后发现的上线前未知的风险，下面分别以具体示例说明常见的整改方式以及如何与架构管控相结合。

第一种是已有安全要求但应用建设时没有落实好，导致查漏补缺后发现包括应用自身的安全功能或与应用关联的安全设备需要更新，修复上线前遗留的已知风险。

以SSL协议的算法套件治理为例，禁止使用RC4和DES等弱算法早已是业界共识，虽然这都是几年前的要求了，但很多时候我们做的并不到位。当需要对此进行查漏补缺时，虽然并不需要对应用进行过多的修改，但仍然需要排查、方案制定、宣讲、测试、与业务沟通、准备客服话术等多项工作，其中的工作成本也是非常高的，正所谓“出来混，早晚是要还的”。

还有一种场景是使用弱口令的场景，口令作为一种认证手段仍是不可或缺的，如果使用弱口令，黑客一旦攻击成功以后便如入无人之境。弱口令很难根治，通常的做法是隔一段时间就要排查整改一遍。与此类似的还有软加密使用的密钥，虽然规范和要求上不厌其烦地强调不能对密钥进行硬编码和不能明文保存，但实际工作中仍然发现有不少对密钥硬编码或明文保存密钥的情况。

出现上述这些问题的原因在于上线前管控不到位，我们可以增加相关的管控流程，增加管控流程就意味着我们需要增加很多的工作量，在安全人员人力有限的情况下，我们如何解决这个问题呢？一方面我们借助架构管控的现有流程确保安全要求落地，另一方面我们应该借助标准化构件化开发的思想，想方设法将这安全基线落实在各类公共类服务和组件中，结合架构管控要求，要求应用通过组件组装的方式实现建设，这样工作量会明显减少。

第二种是应用上线后发现了新的漏洞或者监管提出了新的合规要求，如应用级的组件漏洞、开源组件漏洞或中间件漏洞，又如新发布的数据安全规范中提出的对数据脱敏的要求等。

以前段时间的Log4j漏洞为例，由于从漏洞通报到发布解决漏洞的版本之间存在时间差，如果我们一味快速上线新发布的版本，受限于上述时间差和上线窗口，必然会将我们的资产暴露于危险之中，甚至上线匆忙发布的新版本还可能引入新的风险。我们应该采取通用的缓解措施（如引入RASP实现及时止血），然后等待新版本集中测试完成后再进行统一更新，这样更有利于保障生产运行稳定。

以日志脱敏为例，每个应用整改的成本是非常高的，其中包括梳理、处理和检查等多项工作，每个项目组至少需要一个月以上的工作量，我们有没有办法通过在某个点上对数据进行动态脱敏呢？部分个人信息是有明显特征的，所以实际上是有可能的，如果应用在建设时统一了接口元数据，整改效果会加理想。

在日常查漏补缺的工作中，我们一直在努力将其与架构管控工作相结合，笔者总结了以下几点认识和经验在此与大家分享，希望对大家有所帮助:

1.充分认识查漏补缺整改工作难以开展的根本原因。安全功能作为软件质量必不可缺的一部分，按照系统论这一理论，安全功能与用户体验、兼容性、性能等其他方面有着千丝万缕的联系，这种联系相互交织，牵一发而动全身，从而造成整改的成本非常昂贵。特别是在应用各种架构实现不标准的情况下，如不同浏览器对SSL的支持程度会对应用的兼容性产生影响。

2.实现查漏补缺当前目标的同时一定要注意收敛增量风险。在日常工作中应持续思考将未来增量的风险纳入架构管控流程和技术管理流程中, 不能因为当前目标紧急就忽略了当前工作应该为到达未来目标所做的积累，忽略了对本次查漏补缺深层次的反思和总结，这样不能算是一次完整的查漏补缺工作。

3.安全工作与应用架构、技术架构和数据架构紧密结合，这是安全工作的使能器，决定了安全工作的上限。当面对大量不标准的应用，且应用的数据又杂乱无章时，安全工作是很难开展的，要么采用“点到即可”的管理思路，要么采用“大力出奇迹”的技术思路。如果应用架构、技术架构和数据架构得以统一的话，安全可以利用“卡点”针对性地对代码和数据进行统一处理，最大程度地减少误操作和漏操作，快速实现安全目标。

4.在保护之余，充分利用框架和组件对应用进行检测，为安全工作提供全面数据。在统一架构之后，安全类组件（包括提供安全功能的组件和集成安全部分能力的组件）不仅可以对应用进行保护，还可以对风险进行检测和收集。像Log4j这种问题的日志还是要由应用日志提供，后续由SOC对日志进行统一分析，弥补网络日志对加密数据无法处理的不足。

5.日拱一卒，功不唐捐，对应用分类施策，不追求100%完美。应用的场景是比较复杂的，有些应用因采购等原因无法自主可控，这些都是可以接受的。我们应该采取分类分级思路，对这些应用采取针对性的手段，在技术上与行内其他应用隔离，在管理上要求供应商做出SLA保证，确保应用风险可控。