自2022年5月起，“诸子笔会第二季”正式拉开帷幕。经过对首届活动复盘，我们在坚持大原则、大框架、主体规则基础上，优化赛制特别是奖项设置和评奖方式。13位专家作者组成首批“笔友”，自拟每月主题，在诸子云知识星球做主题相关每日打卡，完成每月一篇原创。除了共同赢取10万元高额奖金，我们更要聚焦甲方关注，发掘最佳实践，弘扬分享精神，实现名利双收。本期发文，即诸子笔会月度主题来稿之一。

浅谈几点安全工作实践中变与不变

文 | 半藏咸鱼

【半藏咸鱼】

某企业安全负责人，负责企业从0到1的安全建设。安全从业近十年，职业生涯大部分在甲方，对企业安全有一定经验和理解。

关于这个主题，本文所写的是在自身工作经历中，亲身体会到的技术架构发展变化对特定安全工作带来的变与不变，纯属个人经历感受，不一定客观和全面。

这里提到的技术架构发展变化主要指两个方面：

1、业务系统从物理IDC机房演变为公有云；

2、新的框架或者中间件加入安全特性。

企业在过去几年里所面临的安全风险，现在也仍需面对，如SQL注入、文件上传导致getshell等，这些风险并没有自动消失。但因为软件框架开始加入安全特性，开发人员逐渐重视，使得某些特定风险的出现频率已经降至很低。

企业在过去几年里所需要开展的安全工作，现在也仍然需要，如网络层访问控制或安全域划分、网络边界的流量分析等。但因为云上的一些特性、整体架构以及运维监控需要，带来了极大的便利性，使得部分安全工作可以更快速地展开，减少了大量前期工作的投入。

01网络访问控制的变化

很多公司创立之初就已选择在云上搭建业务，访问控制使用云原生的ACL和安全组，看不到路由交换等纯网络设备，防火墙也基本没有。相较于传统物理机房的访问控制，这种方式最大的感受是安全域划分变得十分容易，无需过多考虑原先的网段划分。

如果在传统物理IDC机房中开展安全域划分工作，很可能需要调整变更部分机器IP地址，以便将其划分到某个特定网段；甚至要移动机器物理位置，放置在同一个交换机下，最后在防火墙上实现不同IP网段之间的访问控制。这些操作的复杂性会导致不少安全域方案很难实际落地。

相比之下，在云上做区域划分落地实施就会方便很多。只需要创建相应的安全组，再把EC2关联到相应安全组即可，EC2会自动继承所在安全组的访问控制策略，无需考虑IP和物理位置。每个安全组中可添加任意机器实例，无需特别考虑IP段划分；每个安全组之间可以设置相应的访问策略。

假设公司一开始没有做安全区域隔离，所有EC2实例都在一个默认的安全组中。那么安全团队若要开展安全域划分工作，只需要告知运维同学创建3个安全组，分别是接入区、应用区、数据区，提前配置好各个组之间的访问策略，如应用区只能访问数据区的数据库端口；接着分阶段把实例添加到相应组中。此时，一个实例同时继承了默认安全组和新添加安全组的访问策略，不会影响到业务。在适当的时间将实例从默认安全组中移除，观察业务是否正常。一旦有问题，可以快速把实例添加回默认安全组。如此，操作的风险性相对降低了很多，方便性提高了不少。实际操作中，一般进入公司的第二个季度就能够完成测试环境的安全域落地工作。

那么，是否意味着云上就不需要防火墙了？笔者认为还是需要的，防火墙在特定场景仍然有用武之地，如多云之间访问控制、限制云上资产对外访问等。

网络层的访问控制，无论是物理IDC机房还是云上，访问策略的管理都还是一个难题，近年来似乎也没有太大改善。企业的网络策略一直处于只增不减的趋势，业务需要开通各种类型的白名单。针对这个问题也想请各位共同讨论，是否有比较好的解决方案？

02网关层日志收集方面的变化

对互联网入口的请求流量安全分析是常规工作之一。根据笔者自身经历来看，虽然公司不同，但整体架构是差不多的：都是入口流量经过四层网关，再经过七层网关，然后流量被路由达到相应业务模块的API层。其中的区别在于日志收集的职责主体有所不同。

以笔者早期参与入口流量分析为例，需先在出口设备上对流量按一定比例做物理分光，一般业务是70%的光能量，避免光衰太厉害影响到业务。获得一份完整的入站流量后，再复制两份，其中一份用于流量分析，解析后导入ELK做查询分析。在完成分光设备测试采购、上架、流量解析、ELK搭建调试等工作以后，差不多大半年时间就过去了，之后才开始进入“正经”的安全工作。同时还需解决ELK平台稳定性和容量问题，这些都由安全同学主导。

大家可能会疑惑，为什么不在七层nginx反代去做web层日志收集，这在技术上其实没有问题。

但是回答这个问题，就需要回到当时的技术背景。彼时业务都在IDC物理机房，DDoS攻击流量未达到所采购出口总带宽特定阀值的时候，依靠自身能力来检测和清洗攻击流量，不触发云清洗。DDoS检测发现需要四层和七层的流量，使用入口光纤的流量做分析是相对方便和快捷的方案。DDoS检测使用了分光流量，所以web层流量分析也共用了这套方案。当前对于云上业务，DDoS防御是云的标配，不再需要自己落地一套检测和清洗系统，只需做好应急预案即可。

当时日志平台建设主要由安全侧主导，运维和开发同学对入口流量日志使用需求度不高，需要排查问题时登录机器以命令查看nginx日志为主。

此后，笔者入职另一家公司，公司业务主要在云上，大体架构差不多。技术选型上有所演进，四层网关从本地的LVS转变为云上的NLB，七层网关从nginx反代转变为kong或者envoy。在入职后发现，运维同学已经把API层的流量存放在ELK平台上，流量从产生到可在ELK平台上查询，前后不超过5秒，这简直太赞了。

笔者个人认为，可能是因为技术架构整体变得复杂后，日常需要对更多和业务相关的日志进行监控告警，更快发现业务可能存在的问题。比如某接口请求返回大量500可能预示着接口存在问题。同时故障发生时，也需要一个日志平台，快速定位问题。因此运维同学会对收集API层日志及其他日志的工作更加迫切，此时安全只需搭顺风车使用就好，完全不用关心日志平台的可用性和稳定性。

七层代理从nginx反代演进到现在的kong或者envoy，kong是基于OpenResty 的应用，有很好的功能可扩展性，可编写插件。对于安全开展API层安全、反爬接口统一加固、恶意流量隔离等都带来了极大的方便。这部分内容笔者正和开发同学在摸索验证过程中。

03应用安全问题的变化

这部分简单谈谈由于SQL注入和上传文件导致的getshell风险减少的原因。

在当前的业务系统中，SQL注入被发现的难度越来越高。业务上对数据库进行操作时基本都会通过一个中间层，比如MyBatis，它们封装了SQL语句的预编译函数，如在MyBatis中对于SQL语句中的外部参数前加上“ # ”符号就可实现对参数预编译功能（参数为字段名需额外处理）；DevSecOps中静态代码扫描也能够扫出一部分SQL注入风险；通过安全团队长期的培训教育，开发对于SQL注入问题也有了一定的重视程度。综合这些因素，SQL注入逐渐不再“主流”。

对于文件上传漏洞导致的getshell也在变少，因为业务上会使用独立的文件存储服务器，比如七牛云、阿里OSS等对象存储，这类攻击比较难影响到业务。但除getshell以外，上传文件导致的其他问题还是存在的，笔者也有遇到过，所以该有的安全配置也要和开发宣导到位，比如content-type类型，由公司侧控制。

结合自身的工作经历，笔者的感受是：安全工作结合技术架构来顺势开展，能够达到事半功倍的效果。比如应用安全结合公司CI/CD流程，网关安全结合kong或者envoy等。总之，要多和其他技术部门一起搞事。

详情请关注安在新媒体—人物、热点、互动、传播，有内涵的信息安全新媒体。