边界防御思路在企业安全建设的实践-以有赞为例

目录

• 序言

• 边界防御的定义

• 边界防御的价值

• 边界防御的具体手段

• 边界防御在有赞的实践

• WEB边界的管控

• 自研系统边界的管控

• 网络边界的监控

• 运维流程边界管控

• 总结

序言

企业安全建设需要根据企业当前的实际情况确定，但是也有一些基本原则。从适用阶段划分来看主要有边界防御和纵深防御两个层级。

一、边界防御的定义

基于业务或者 IT 设备的划分，针对处于业务入口/网络入口建设的防御措施都叫边界防御。

多数企业来说，WEB 入口就是其边界。针对 WEB 入口的防护就是边界防护（比如 WAF）。还有常见的各种防火墙，也都属于边界防御手段。

另外，近几年逐渐被行业所重视的 SDL 也可以看成是边界防御手段的一种：SDL 实际是对自研系统内部研发流程，按照一定阶段和逻辑划分切割出各自的边界，这些边界上有输入也有输出，然后在这些边界上实行管控措施。

除此之外，日常的各种监控手段，因为其关注的仍然是边界线上的活动，实际也是边界防御的组成部分，比如 DNS 监控、统一接入接出等等。

二、边界防御的价值

边界防御主要适用于企业安全的初级阶段。这一阶段的企业安全"百废待兴"：无感知，无管控，无趁手的应急手段，无系统化的梳理和整改措施。

企业频繁出现多个种类、多个严重程度的安全问题；企业高层感知到的安全状态是"天天出问题"，“全面失控”。最开始针对这些情况的处理措施可能就是找几个安全运营人员做应急，哪里出火情去哪灭火。

这样的做法在效果上是立竿见影的，马上能扑灭一批看起来很紧急的灾情，容易让管理者和具体实施者有成就感和短期的安全感。

但是，随着问题越来越多，会出现以下一些情况：

• 相同或者相似问题总是一再出现，只是换个具体场景、业务内容而已，比如外链、恶意文件、刷单、刷优惠券等等反复出现，每次出现都让人如临大敌。

• 很多安全手段虽然看起来应该是能复用的，但是因为具体场景问题，一直避免不了重复建设。

• 安全问题的解决严重依赖运营团队的应急处理速度，而且是按下葫芦起了瓢，人力严重不足，只能不停地扩团队规模，再不行扩外包。

• 安全状况除了不断加强救火能力、时刻保持一颗高度紧张的心外，看不到有根本性好转的趋势。

• 最核心的一点，看起来做了措施1，措施2…措施n，但是如果被问到我们安全了吗？依然心里没底，因为并不确定这些措施够不够、判断依据是什么。

安全领域很多问题其实和军事领域是共通的。

军事领域，要对一块区域实现有效保护，第一步要做的就是划分边界，健全边界准入、保护和检查机制，确保任何人/物都只能通过特定通道进出。

比如我们的海关、机场的边检，还有边境巡逻就是这样的措施。想象一下如果取消了国界、边检，整个国家的状态也会是企业高层感知到的早期安全状态：问题遍地开花、全面失控。

有了这些基本的边界防御措施后，就能有效遏制安全问题全面开花的状态，很多问题就会自然覆盖或者消失，结束企业安全团队疲于救火的现状，能够更深入考虑进一步的企业安全问题，比如安全如何服务于业务的发展等等，实现企业安全从 0 到 1 的转变。

三、边界防御的具体手段

边界防御通常按照感知、应急、防护、整改（或者叫检测、响应、防护、策略，美国国防部把它叫做 DRPP ）四个手段实现闭环。这四个手段实际是针对事物发展的不同阶段予以处理的，因此也有人把它称为 事前、事中、事后 。

通常安全领域不这么说，原因在于除了边界防御外，我们后续还需要纵深防御。

在纵深防御阶段，基本思路体系是协同作战、相互配合、查漏补缺，再用事前、事中、事后的逻辑是无法说通的。而且事前、事中、事后只是突出了阶段，没有说明这个阶段在整个安全体系里的目标和价值，也没有体现这些阶段的内在关联性。

所以安全领域，多数人更倾向于"感知、应急、防护、整改"或者 DRPP 这样的表述。

常用的具体边界防御手段大概如下：

• 感知（Detection）：IDS/HIDS、DNS/扫描等监控、WAF、流程卡点等。

• 响应（Response）：SRC，WAF，IDS/HIDS等。

• 防护（Protection）：WAF、IDS/HIDS、防火墙、流程卡点等。

• 整改（Policy）：SDL/SDLC、流程卡点等。这些手段很多都同时具备感知、应急、整改等多个功能，各自效果和优劣势也很明显，需要企业安全人员根据实际情况做取舍，具体细节这里就不再赘述。

四、边界防御在有赞的实践

我接手有赞安全时，整个有赞的企业安全建设就是处于很早期的阶段：

• 业务边界没有系统性梳理。

• 没有清晰的监控措施和应急流程。

• 没有明确的防护措施。

• 自研业务系统的设计没有系统化的安全要求，有问题时也不确定怎么处理或者没人处理（比如白盒扫描出的安全问题因为长期无人跟进，最后干脆取消了）。

• 各个业务系统在出现安全问题时如何协作没有明确的规范，只能靠电话拉人应急。

• 安全问题频繁出现，内控/数据泄露等问题尤为明显；生产系统偶尔因为意外会发现部分安全问题，但是整体是否有其它问题无人能回答。

基于以上情况，我首先分析了有赞现有的业务边界和常见安全问题的核心抓手。

4.1 WEB 边界的管控

有赞作为微信起家的电商 SaaS 平台，99%以上的业务都是对外提供 WEB 服务，其它服务入口非常少，基本可以忽略。所以，管控好 WEB 入口就等于管好了有赞最大的边界、管好了有赞的"国门"。在这个场景里，能承担起海关、边检角色的最好手段就是 WAF。

确定必须上 WAF 手段后，接下来就是怎么做的问题。一是自研，二是外采。这一点上，整个团队踩了一个大坑。

最开始，基于对 serverless 技术的熟悉，我们希望利用 serverless 技术免运维（稳定性有保障）、高弹性（性能有保障、价格低廉）、高扩展性（适应业务需要，比如双 11 场景）、开发成本低（快速上线）等优势，实现简单的 WEB 内容快速过滤。基于这个方案，预计一周就能完成简单过滤逻辑，后续再不断小步迭代和完善，达到快上线快拿结果的目的。

理想很美感、现实总是很骨感：有赞运维部门为了确保业务的高可用，实施的是多云部署架构，各个云协同负载业务流量。其中用到的另外一个云平台目前暂无 serverless 产品支持。如果继续使用这个方案，要么只能覆盖一半的业务流量，要么都切换到单一厂商的 serverless 产品、破坏现有的多云架构，运维部门不能接受多云变单云的结果。

基于这个情况，serverless 方案只能放弃，原本计划的一周开发完成、一月上线的目标只能延后，现在就只剩下了外采一个途径了。

现有的 WAF 方案里，总体分为两大类：基于 cname 解析的云 WAF 和基于单机私有化部署的软件 WAF。

云 WAF 的优势在于部署简单、免基础设施的运维，性能可以秒级弹性扩张。劣势在于基于 cname 的实现方式，一旦有故障需要迅速下线时，延迟时间可能在几分钟到几小时级别。运维角度，基于业务高可用考虑，这点是不能接受的。

而且，云 WAF 所有流量都走公网转一遍，对服务商的公网带宽有极高的要求，多数服务商不具备这样的能力，或者即使具备但是价格昂贵。

单机私有化部署的软件形式 WAF 优势在于所有流量走内网，不管是网络延迟还是带宽成本都有优势。劣势在于部署复杂、对现有运维架构的侵入性非常高，涉及到现有整个 IT 架构的整改，对运维和安全部门的资源协调能力有很高的挑战。

两个方案综合对比，最终从业务高可用和应急角度考虑，我们选择了单机软件私有化部署的 WAF 方案。

后续还涉及到 WAF 的自带 agent 不满足现有运维需求、多数业务位于同一个域名从而如何按业务接入、运维对 WAF 的 agent 这种中间件系统部署的高度谨慎、测试部门对于 WAF 会引起的系统性能的影响的疑问、基于业务的 WAF 策略运营、有赞云该如何处理等复杂问题，这里就不再一一赘述了，总之是一言难尽。

值得庆幸的是经过几个月的奋斗，到目前为止，整个 WAF 系统即将全网正式 run 起来了。

4.2 自研系统边界的管控

长久以来，安全问题实际两个诱因：一是使用的第三方组件/系统的安全问题，比如 fastjson 的问题，linux 操作系统的漏洞等等；另一个是自研系统实现过程中各种原因引发的问题。

对于前者，有赞环境里，WAF 就能很大程度缓解，加上规律性的众测等措施也能实时发现一些问题；对于后者，SDL 是不二选择。

• 自研系统的安全问题，有些是业务功能或者逻辑设计就有安全问题。比如允许客户上传富文本然后显示给消费者，这样的功能天然就给黑产灰产留下了操作的空间；

• 还有抢优惠券/代金券这样的业务，一旦产品逻辑考虑不全就可能被人钻了空子实现薅羊毛、损失商家营销资金。

• 另外一些问题是具体技术实现方案导致的，比如密码明文存储、该有的权限控制没有权限控制、代码逻辑bug等等。

• 最后，到测试环节，白盒测试和黑盒测试也会发现问题，但是传统的测试更偏产品功能的实现性，对于安全问题缺乏跟下去的抓手。

• 上线前，运维部门缺乏对业务系统前期整个流程环节完整性的监督与控制（比如之前是否有产品设计，测试出的问题是不是都整改了等等）。

• 上线后，对于线上系统的持续监控谁来做，有问题如何闭环等等。

以上这些过程中的所有问题合起来，共同导致了现在业务系统的所有安全问题。

SDL 就是在这些环节的边界上设置卡点和触发器，再借助一些工具、流程平台，实时跟踪这些问题，推动问题的整改和闭环。

SDL 要落地，根本上要做的事情是打通整个产品设计和研发、上线环节，整个过程会高度侵入现有产品及研发流程、系统、平台。具体来说：

• 设置研发效率平台卡点，实现需求评审阶段的通知和产品设计的安全评审，没经过安全评审的需求，禁止系统进入下一阶段。每次收到通知后，工单系统会自动新建一个安全评审工单，通知到安全部门和具体需求的负责人。安全评审结束且通过后，若无问题，安全部门结束这个工单，效率平台再往下一步变动时没发现未结束工单就正常往后续变动了；否则会拒绝进入下一个阶段。

• 一旦效率平台进入研发阶段，也会和上一步一样，自动触发技术评审的工单，整个流程和产品评审一致。

• 同时，持续交付平台会有手动代码扫描按钮，相应研发人员可以手动对自己的代码扫描，发现问题提早整改，避免在集成测试阶段发现过多问题而无法整改。

• 集成测试阶段，会自动触发白盒平台对整个应用/项目代码做白盒扫描。如果有问题，会自动生成工单通知到相应负责人，并且在集成测试出测试报告时检测是否有未结束工单，有的话，集成测试就不通过。

• 上线前，环境变更到qa或者预发时，会自动触发黑盒测试，整个流程和白盒一致。

• 最终向运维提上线申请时，流程系统自动查看是否有未完成工单。若有，上线申请无法提交。

• 上线之后，每季度会有针对公司业务系统的众测。对测出的问题，有完整的整改流程和期限要求，否则该系统以后的所有产品、研发流程的变动都会被卡住，确保安全问题整改落到实处。

从以上描述也可以看得出，SDL 是个非常重流程的事情，重度依赖流程平台的卡点和通知，成本极高。所以整体定位讲，SDL 只会接入少数高危、重点业务。为了实现这一点，我们在工单平台设置了一个基本逻辑：只对我们加了白名单的应用/项目发工单，其它业务不受影响。

当然，以上流程的实现会有更多系统对接上的细节问题，基于篇幅考虑，不继续赘述了。

另外一方面，SDL 标准化建设因为工作量巨大，基本是个超级工程，考虑到有赞目前的业务风险紧急程度，我们采取了非标准 SDL 和标准 SDL 同步进行的策略。具体来说：

• 在标准化建设之外，我们使用工单通知的方式感知产品评审，然后人力去筛选高危、敏感业务做产品设计阶段的安全评审；至于技术评审，根据产品评审阶段的信息确定要不要进行。考虑到后续有黑白盒平台把关，技术层面的安全评审在非标准SDL流程里一般原则是不做。

• 同时，利用已经早期部署完成的黑白盒工具对外提供黑白盒服务，跟踪产品研发阶段的代码和功能层面的安全问题。这个事情主要在研发阶段由研发人员自己完成，上线卡点处由安全部门检查：若是我们关注的项目、前期已经要求做扫描的项目，安全部门检查扫描及整改结果（复扫结果）；否则直接放过去，最终实现SDL的高危覆盖与标准化建设的同步进行。

4.3 网络边界的监控

网络边界监控的依据是任何恶意入侵最终都需要与公网通信，通信的数据内容、端点、频度都会有各种异常。IDS/HIDS/DNS 监控等就是基于这样的思路做出的具体措施。

有赞的现状来说，基于 WAF 和 SDL 都是必须要落地的、最紧迫的超级工程，现阶段没有更多资源落实太复杂的措施。另外一个基础条件是，有赞现在对生产网、办公网都采取了统一接入、统一接出这样的措施，DNS 成为了有赞内网与公网边界上的必经点，且有现成的 DNS 解析数据可用。综合考虑，DNS 监控是个成本最低、收益最高的手段，所以我们采取了对 DNS 做定时分析来实现基本的网络边界监控的目标。

具体实现上，有赞内部有现成的、基于 flink 实现的离线数据分析系统，且也有 handoop 相关生态，所以最终花在这件事上的开发成本，把断断续续开发的时间加起来估计不到一周。

目前这套逻已经发挥了不错的效果，比如发现了不少内部员工办公电脑的恶意后门问题。

4.4 运维流程边界管控

有赞有相对完整的上线、ACL 等运维流程。公司内部系统、生产系统的变更都会经过这些节点。

有赞安全在我接手之前，基本没有系统化的梳理和整改，所以累积了很多安全角度不合理的线上系统。这些系统已经上线的情况下，安全部门再去推安全整改，一是无法感知到这些问题，二是业务部门对这块的整改没有动力，推动阻力很大。但是这些问题又必须做出逐步整改，所以在这些业务日常变更的卡点处设置安全审核是最合理、成本最低、效率最高的方案。

目前来看，这些卡点已经连续触发了包括 CP 系统、有赞云等多个系统的安全问题整改，对有赞线上系统的安全体系化建设发挥了小而精的效果。

最终，有赞通过以上建设，实现了安全建设从 0 到 1 的变化：有感知，有应急，有防护，有整改。

以上这些措施只是实现了边界防御（DRPP），边界上能解决的问题是有限的，所以下一步的计划就是针对边界上存在的问题，做更进一步的优化以及升级为纵深防御，把各个防御点联动起来，查漏补缺。

总结

企业安全建设需要分清阶段，根据阶段采取适合这个阶段的措施。初级阶段最重要的任务就是建围栏、守边界、控事故。把企业风险圈定在一个范围内之后，才是进一步在这个围栏内部做更精细化的处理，比如纵深防御的建设。

企业安全建设的初级阶段需要注意的问题是被事故牵着鼻子走。因为这阶段的现状就是事故遍地开花、有失控趋势，很多人就一下子慌了神，失了分寸，每天到处救火，真正该抓住的抓手却忘了去做。比如发现内部销售团队有利用一些系统缺陷获取不该获取的数据的问题就计划要在所有基础设施都不具备的情况下彻底整改这件事，但事实上这些事情的本质原因都是基本的围栏没建好，要整改会是个花费很高收入很少的事情，还不能保证后续不再出现。

在这个阶段，最合适的做法就是两点：

• 第一，保留大概20%精力处理日常的突发事件，比如突发的重大安全事故、突发的恶性数据泄露问题的跟进等等，手段上怎么快怎么做，怎么简单怎么做，不求彻底根治，只求当前止血。某App平台的外链欺诈应急就是例子。

• 第二，搞清楚这些问题的公共特征和原因，找准一个核心抓手下手去做，然后之前那些遍地开花的事故自然就会大规模收敛。比如有赞安全目前几乎所有安全问题都来源于WEB入口，控制住了这个入口，多数安全问题自然就会消失。然后再去做SDL这样的深度整改的事情就会从容很多，会首先上WAF的原因，除了长期体系化建设之外，另外一个很重要原因就是基于快速收敛问题的考虑。

做到以上几点，保证最高优先级的突发事故处理的同时，始终把工作主线钉在该做的核心抓手上，而且即使应急也尽量往主线手段上靠，最终确保整个安全建设既不丢眼前救火，又能实现 0 到 1 的变化，以至于逐渐不需要救火（比如目前依靠 WAF、非标 SDL 等措施，基本无需救火，差不多走上了日常运营路径）。过了这个阶段之后，整个工作思路就需要有新的方式和方法来做，以上方案就不再适用，具体内容这里也不再赘述了。

总之，企业安全建设是一个高度复杂的工作，需要相应的指挥者既有上帝视角的高度，又有落到实处的细节把握能力，是需要所有安全从业者不断修炼的事情。