孟翔巍：漫谈安全的两三事

本文将以故事和经验实践的方式展示给大家，分享的内容主要有三个话题，分别是网络安全域的实践、API治理实践与SOAR的畅想与实践。本文仅为抛砖引玉之作，希望能给大家提供借鉴，并期待与业界同仁的深入探讨。

关于网络安全域，现在很多企业都想参考头部企业的模型来落地实施，其关键点是通过红黄绿三个区来实践落地。

红区，该区域终端仅能访问内网核心研发系统，且外设接口均被封闭；无互联网访问权限，有互联网访问需求时由公共机解决；进入该区域的人员，不允许带入任何具备留痕能力的设备，包含但不限于手机、U盘等。

黄区，该区域终端能访问内网非核心研发系统与部分办公系统，且外设接口均被封闭，有配套流程可以进行开放；具备基础互联网访问权限，即普通查询的web资源等；进入该区域的人员，在授权情况下允许带入具备留痕能力的设备，但需要一定处理，比如有专门的安保人员会用封条将笔记本和手机的摄像头贴起来。

绿区，该区域终端仅能访问内网办公系统，外设均处于放开状态；互联网访问权限无限制；人员可随意进出该区域，无物理限制。

这是一个非常理想的模型，但它有一个核心规则，即从低密到高密的单向数据流，从而保护整体的核心研发资产。该模型比较适合研发相对集中的企业。

2、达成该模型的前置条件

从实际落地经验来看，要达成该模型有三个关键的前置条件：

物理先行。至少得把具备同类属性的人员聚合在同一个物理空间里面，这个难度非常大，因为标杆企业在开始就把同一类人员聚集到同一个办公区，就会简单很多。如果刚开始没有这么做，后期几乎不可能把人员聚到一起，人员一定是交错的，这时候再进行人员办公区域调整将是一个巨大的工程量，这也是该标准模型落实不了的原因之一。

数据单向流的可行性。这个节点得解决两个问题，一个是技术实现问题，能否实现单向流，我当时有做过相关的工具调研，可以实现，但是部署和运维的难度比较大。一个是规则实现问题，是不是一定能做到低密往高密流，如果在业务规则源头上没有定义清楚，会很难实现，因为业务之间的交付已经形成定式，要去打破这种定式，用另外一个规则去约束业务，那么对业务的效率将造成极大的影响。

成本的控制。基于物理去实现这样的模型，取决于本身物理空间的需求较大，造成较大的成本投入；其次，物理空间规划好之后，每一块物理区域都需要一套IDC基础设施，如何说服老板投入，这本身也是个问题。

实际上，在做安全工作的过程中都会面临说服老板的情况，因为安全有一个重要的属性是“既不降本也不增效”，它与企业降本增效的理念是相违背的，因此安全工作都是通过降低安全事故的发生率去说服老板来进行投入。

3、纯逻辑方式实现裁剪模型

如果做不到物理先行，那就只能从逻辑上面去考虑。不再通过物理层面区分人员，尽量把相关人员集中在一起，从路由层面来建红黄绿区，再通过不同层面的路由互写，也就是ingress和exgress的方式，把路由进行输出和导入，从而实现类似物理先行那种管控状态。

但是经过试验发现这一套很难走下去，主要原因有三个：一是运维难度非常大，人员位置的变换还能解决，但是路由空间的配置本身就非常复杂，如果稍微有一点业务变更，意味着路由这边要调整很多东西，运维难度非常大；二是人员依赖性很强，这一套工作完整做下来的人员，在很熟悉路由规则的情况，运维还是可以搞定的，但如果人员进行了更替，意味着整体的延续性就不好了，因为一个月都不一定能交接完，即使交接完也需要有很长的适应周期；三是成本相对较小，这算是一个优点，基本上就是一套网络设备加上一套安全设备。

4、物理与逻辑相结合的方式实现裁剪模型

物理与逻辑相结合的方式，就是将物理层面定义为类似实验室的方式，相对封闭，按照“二八原则”把最核心的10-20%的人聚集到一起，然后以实验室的方式参照前面的模型把它彻底隔离起来，建立红区，其物理和路由层面是统一的。黄区和绿区还是用纯逻辑的方法，通过路由层面进行隔开。相对纯逻辑的裁剪模型来说成本会高一些，因为有物理和路由层面统一的部分，至少会多一套设备。

而且，即使将红区摘出去，黄区和绿区的运维难度也不小，因为红区在整体规划中的占比较小，黄区和绿区还是占大部分。此外，对人员的依赖性依然很强，因为它的复杂度就决定了如果出现人员交替，其连续性一定会存在问题。所以经过一段时间的实践，随着整体覆盖面的铺开，发现最终的目的难以实现。

5、解决方案的探索过程

基于上面几种模型的探索，我就在思考，到底要通过这个模型解决什么问题？我认为这个模型是尝试从人员、终端、应用三个角度实现防攻击、防泄漏和防特权，这是它要实现的顶层目标。

其次，参考这个模型，最大的价值点是什么？我个人认为是从物理角度出发，解决了人、机（设备）、料（应用）之间的问题。为何很多组织参照模型的时候落不了地，有个最重要的原因，就是对于物理先行上有绝对的执行鸿沟。因为在物理位置固定好的组织中，再去进行位置的调换将是绝对达不成的工作，基本不是某个人能决定的，牵涉的范围很大。

因此，既然物理层面落不下去，那就抛开一定的输出点，不再考虑人的问题，转而去解决机、料的问题，实际上就是在实现能不能访问、权限给不给的问题，而这个问题就可以通过SDP来解决。

纵观SDP整体架构，其中关于用户部分有信任引擎，可以从IAM/PAM/4A获取一些基础的权限数据，然后通过一部分通道策略传输到应用代理，明确可以访问哪些应用。经过两两组合来解决前面提到的两个核心问题，就是本身的基础权限的源和信任引擎加到一起，信任引擎对权限通过模型的方式去做加权，根据本地终端的环境数据来决定给多少权限，这就解决了权限到底给不给的问题，然后信任引擎加上代理的porxy，解决能不能访问的问题。

事实上SDP概念是基于零信任而来，被炒作了很长一段时间，主要体现的核心价值有两个，动态鉴权与动态授权，也就是解决权限和访问的问题。

关于API治理心得，先给大家介绍一下背景。有一天，研发负责人找过来，说业务正在做数字化转型，要构建应用产品生态，想通过一个平台做API的生命周期管理，问安全要不要一起联合立项？听完我很感兴趣，因为我本来也想做治理这块的事情，但是业务不参与到整个过程中，只靠安全来推动会遇到很大阻力。所以当研发负责人愿意来一起建设，我们是一拍即合。

1、安全的考虑点与业务的适配性

在请示老板意见的这段时间发生了一些状况，因为彼此较忙中间没有太多交流，等我们第一次碰撞的时候才发现两人的思考方向完全不同。研发负责人想的是平台的架构、API的管理、以及应用之间的区分等等。而我是从安全角度出发，想的是API发布之后的权限范围、使用协议、敏感数据加密、数据脱敏、API认证、授权等等。

然后研发负责人就说了，你想那么多安全需求，我怎么去做融合，总得先要沟通梳理一下。我一想也对，至少应该通过沟通去调研到一些内容，比如架构层设计、技术支撑管理的流程配套、内部API和外部供应链等等，这次事情也让我明白安全应该考虑到与业务的适配性，不能只站在自己安全的角度思考问题。

2、业务的分层方案

两周之后，业务给出了方案架构，初始的想法是内部的API要管，上游的也要管，但是一个平台全部管理的复杂度有点高，于是就有两个方向：一是就做一个平台，将它做成两个模块，分管内外；另一个是，把平台一拆为二，内外部分开管理。区别在于，两个平台相对来说成本和周期更高，一个平台更简单一些；但是从从后期管理来看，两个平台运营的成本要低一些，一个平台运营成本则偏高。两种方式各有优劣，但是从安全的角度来说，两个平台要比一个平台好，因为如果外部平台万一被漏洞利用，内部平台还能用，比一个平台的安全性更稳妥一点。

经过综合考虑，最后还是将平台一拆为二，即如图所示的Inbound与Outbound。在整个过程中，我们把APP分类之后，在平台中嵌入了一个流程点，就是在产品上线时一定要把API发布到平台，如果有对外的交付需求，可以把API在对外的网络上再做一次发布。当然后期还在完善中，只需要一次发布就可以完成两件事。然后，其他APP来调用时直接从平台调用即可，不需要再进行APP之间的调用。大概整体架构和业务的实现，安全与研发基本达成共识。

3、安全应对与解决方案

框架与业务实现达成共识之后，我就着手考虑安全应对与解决方案。首先是对应用进行定级，才能确定后面API的范围。然后，尽量梳理清楚现有的API资产，包括数量与类型。做完这两项基础工作，就开始研发。

在Inbound的安全工作中，首先重点肯定要有流程配套，包括API的发布、使用以及随着产品的下线的生命周期，一定要有一个配套流程。第二步，根据应用定级和API资产治理的结果，确定哪些API需要什么样的安全配套。第三步，梳理API的时候也会把一些APP之间的关系梳理清楚，这时没必要把授权卡的太紧，就给予了较为宽松的授权范围。然后，做轻量级的传输加密，挑重点去做，保证即使发生API的泄露，这种基本的加密形式也会有所保障。最后，通过一些工具对威胁进行监控。

在Outbound的安全工作中，主要分为公有云和供应链上下游两个部分。首先把使用协议做出来，将供应链这块的使用协议推下去，风险共担。第二步，要有认证机制，确定哪些APP需要严格一些的认证。第三步，要有严格的授权范围，要调用哪个APP就只能调用哪个。第四步，重量级传输加密，只要是出去的数据都要加密，也是为了防止数据泄露。最后，点对点消费，就是上下游每一次抓取数据，使用完后就销毁掉，不再留存。

通过这种方法来实现安全与业务的协同，同时完成各自的目标。

4、API治理心得

首先，安全不要尝试走到业务前面。安全实际上是一个孪生技术，基本上是孪生在整个业务的成熟度上面，因此安全的成熟度不可能高于业务，一般比较厉害的能跟业务保持一致，比业务慢半拍也是比较合理的。

第二，先治理后技术，技术的价值是为管理服务的。既然为管理服务，那么要做好支撑，肯定是个自上而下的过程，如前文提到的先把应用资产治理好再去实现技术会更顺畅。

最后，常态化运营，不要湮没建立起来的秩序，通过流程的方式让整体更加规范化。

我对SOAR的理解分为三层，第一层就是业内对SOAR的定义，即SOAR是安全自动化编排，是实现自动化安全威胁响应的能力。第二层，基于该定义我认为SOAR是一个技术框架，有两个关键词，即自动化响应和编排，自动化响应其实是靠整体的技术栈来解决，编排是靠流程来解决。基于这个理解，我认为它是在解决安全运营最后一公里的问题，在我的团队里我更愿意称之为“自愈”，这是我的第三层理解。

谈到自愈，此处分享一个经典剧本，相当于威胁处置的SOAR过程。第一步植入，第二步潜伏等待，第三部命令执行，当其去做CC回连，这时相关工具就会检测到威胁数据，产生一些日志，然后会有一个脚本化过程，把CC回连阻断掉。

基于这个剧本，我一直认为SOAR是一个技术框架，这里列举了三个例子，基线管理、漏洞管理和补丁管理。

实际上，SOAR上线之前，其他流程都是自动化，唯独修复阶段都需要人工，无论是基线、漏洞，还是补丁。这就是前面提到的最后一公里，也是我想推动的方面。首先，我是把基线抽出来做，写一些修复脚本，也就是自愈脚本，然后找了一个下发成功率最高的桩，检验时发现该思路可行，于是就往上推。现在，基线的SOAR实践基本没有问题，工单从产生到整体闭环，不再需要人工去干预。

其中，自愈脚本和桩一起做了编排，让桩能做的事更多一点，这样的话基线流程基本实现100%自动化，补丁也接近100%自动化，漏洞做不到100%，但会提高自动化率，通过这种方式把整体的SOAR体系逐步构建起来。

在实践完之后，我当时在考虑要不要做一个中台，有两种方式，一是做成中台，把SOAR最后流程的人工端点补完；二是把SOAR做成SOC的一个模块，模块之间来调用，整体过程还是“SOC-SOAR-桩”互相拉动的方式。其实这两种方式差别不大，把前中台分开去看，觉得可能逻辑更清晰一点，方便整体架构的横向扩容和收缩；把前中台做到一起，相对来说功能更集约，前台能力更全面。因为目标都是自愈，从底层来看，两种方式实现流程都一样，怎么选择取决于组织的具体情况。