探真科技李祥乾：基于ROI逻辑寻求平衡 让业务迭代更安全

对于很多业务开发和运营人员来说，安全其实是一件比较麻烦的事情，总是要被安全部门驱动着去做漏洞修复的工作，还要为之牺牲部分迭代的数据和工作时间，因此这也招来了业务部门对安全的反感，毕竟业务的快速迭代才是企业发展的核心动力，而不是绝对安全。

 

为什么安全难落地？难点具体存在于哪些方面？安全与业务的收益应该如何统筹？近日，在由火线安全举办的火线沙龙23期—云原生DevSecOps专场上，探真科技研发副总裁李祥乾分享了自己的理解和思考。

 

新的云原生架构下存在新的安全风险

 

李祥乾首先指出，在当前的云原生时代下，新的云原生架构既涵盖了原有传统架构下面临的问题，也同时引进了新的安全风险。一方面，webshell、病毒、木马、反弹shell这些问题在新的架构下仍然存在，另一方面，云原生带来了更快的集成、交付，带来了更灵活的隔离技术与SDN，但也为安全带来了巨大的挑战。

 

首先，云安全的核心目标是降本提效，降本提效意味着更快的集成和交付，但新的供应链风险、漏洞风险控制成本也随之加倍提升。因为单位时间内交付的镜像、交付新服务的速率变大了，控制这些风险控制会与这种交付速度之间存在的冲突也会增强。

 

其次，云原生架构下诞生了基于容器的更灵活的隔离技术和软件定义网络，但他们实际上都是在物理层面上面增加了一层更灵活的虚拟化技术。这种虚拟化技术本身相比传统的虚拟机的隔离，存在逃逸或者提权的风险会变得更大。比如Docker和k8s此前就都曾暴露出了很多容器逃逸的漏洞，在这种隔离机制下，像传统的网络防火墙这样的传统安全方案和能力都会失效。因为在容器网络下迁移会很频繁，它的IP是动态分配的，传统基于IP的策略通通都会失效。

 

再则，更复杂的代码肯定会带来更多的bug和漏洞，在云原生架构下更高层的抽象、更复杂的实现技术也意味着这些核心组件的缺漏洞和缺陷的风险在大幅提升。最后，微服务化后，微服务的数量和服务调用关系复杂度是呈几何比例提升的，这对于安全策略的管理、安全运维成本以及如何感知这些流量和变化，都带来了巨大的挑战。

 

李祥乾分享到，从典型的DevOps流程去看风险会发现，在测试环境下，比如代码仓库层面，很多代码本身可能就会包含敏感数据，包括数据库密码或是密钥等等，再有，业务开发人员自己写的代码也会存在漏洞和bug，这些都有可能被攻击者利用。

 

 

当开发人员想要去做测试的时候，从CI/CD工具里面会去拉取代码去做构建镜像，这里就会存在一些可能包含病毒和木马的镜像，风险可能会在这个阶段就被推送到仓库。而从镜像仓库的层面，仓库里存储的活跃镜像数量可能高达几万甚至十几万个，这些镜像甚至还包含着几十万个漏洞。这种漏洞的管理成本对于安全部门和业务部门来说事实上是相当高的，这么多漏洞想要全部修复不现实，这么多的漏洞优先修复哪个？这里也会存在大量矛盾。

 

在生产环境下，在镜像的分发流程中也存在镜像可能被篡改的风险，被默认安全的镜像一旦被篡改，那么在镜像的运行过程中，镜像漏洞就有可能会被攻击者利用，利用这些漏洞的攻击能否被检测到和管理，这也是安全需要去解决的问题。

 

李祥乾同时也指出，更具灵活性、更加速的CI/CD给安全带来的并不只是烦恼，从辩证的角度看，这种灵活性加速了业务迭代，加速了持续集成和持续交付，实际上它也会进一步推动着云原生下的安全运营和安全策略的加速迭代。

 

在他看来，安全如果想要以更加灵活和和深入的方式实现对风险和集群资产的感知，那么就必须利用数据去持续的学习和优化，来降低安全运营的成本、提高运营效率。为安全人员去减少重复性的配置，让安全人员能够持续的关注在最需要关注的安全问题上。

 

此外，安全策略的执行和迭代也必须更加灵活，把固化在代码逻辑里面的策略变成数据和规则，以保证安全策略的可持续更新。“我们希望的云原生安全，是云上的原生安全，而不是原生环境下的安全。”

 

 

李祥乾谈到，从业务视角来看，对安全的第一印象可能是安全会让DevOps的效率变慢。比如说零信任，零信任要求一切都需要去频繁的做鉴权和审批，比如说哪怕是在谷歌，他们的BeyondCorp零信任安全方案的落地也足足耗时了6年多的时间，在其他的企业对零信任的认知可能还参差不齐，他的落地难度其实还是很高的，那么企业也需要去考量，零信任还要不要落地？

 

再有一点是微隔离，现在微服务的数量这么多，网络策略配置越来越复杂，一旦少配一个、漏配一个，就可能会造成业务上的损失。微服务还会带来大量的报警，消耗运营人员大量的精力和时间处理这些报警，这其实是一个比较大的成本。

 

第三点是镜像安全方面的问题，镜像的数量是很庞大的，而漏洞的数量更要大于镜像的数量，海量的漏洞难以一一修复，甚至还有很多漏洞是无法修复的，即使安全团队发现了问题识别出了高危漏洞，但可能官方还没有发布相关的漏洞补丁，这样还是会进一步阻碍和减慢CI/CD，无法真正的帮助业务开发和运维来解决问题。

 

 

李祥乾表示，相比于业务迭代需求的重要程度，安全的需求其实肯定不能overide，企业的核心动力还是业务的迭代，安全的目标其实是控制业务的风险，所以他提出，应该基于ROI的逻辑去寻求安全与业务的平衡，从而让业务的迭代更安全。

 

 

李祥乾谈到，安全有两种逻辑和做法，其一是事中运行时和事后的对抗博弈的逻辑；其二则是事前预防的逻辑。具体来说，事中运行时和事后的对抗博弈的逻辑就是只，在发生安全事件需要应急响应，或是漏洞事件突然爆发的时候，安全人员需要跟攻击者或是潜在的风险去做持续的对抗和博弈。

 

在他看来，这种一定程度上说是“擦屁股”，是在问题发生或去遏制风险的蔓延，以及在事后通过复盘去避免下次还这么狼狈。“它的核心逻辑其实是风险控制，安全永远没法消灭风险，消灭风险可能成本会很高，但对于攻击来者来说也存在成本，最终会演变成攻防成本的对抗。因此安全团队需要通过合理的成本去将风险控制到一定程度下，直到攻击者不愿意在为同等的收益去付出成本时，就达到了攻防的平衡，这是这种对抗和博弈逻辑所追求的最终目标。”

 

而事前预防的逻辑则是指以ROI为中心return on investment，从投入产出比的视角来看待风险控制的问题。当企业发生过几次安全风险之后，势必会重视整体安全防护体系的建设，包括纵深防御的建设，去做流程安全等等，来进一步提升整个企业的安全水位线。

 

安全的目标实际上跟业务或是DevOps的目标其实存在某种趋同，实质上都是业务持续性的管理，让业务高持续性高可用的运行，避免数据泄露风险、PR风险、GR风险等等，“其实不会有任何公司会为了提高防御能力去穷尽所有去修复所有的漏洞，这样的话成本边际效应会越来越高，从最终的逻辑都是基于ROI逻辑，让业务迭代更安全，寻求一个平衡。”

 

李祥乾最后指出，基于ROI逻辑进行事前预防，也符合云原生安全的零摩擦（Zero Friction）核心理念。众所周知，零信任网络在用户侧以难落地而出名，而零摩擦与零信任的“零”都代表着无限趋近，对于灵信任来说是不可能什么都不去信任，肯定是要有根信任。而对于云摩擦来说，没有任何安全方案是完全没有摩擦的，重点是平衡安全的收益和业务的收益。

 

具体来说就是，在同样降低安全风险的目标的前提下，如何能做到安全运营成本的降低，效率的提升，以这个目标来提高用户的体验。第二点是更好的适应不同的企业流程和文化，降低实际用户在落地实践的时候，跟其他部门或者其他的业务需求产生的一些摩擦。第三点是实现安全的闭环，安全不能只发现问题，还需要去解决问题、管理问题。