原标题：互联网公司自研安全产品个人感悟朝着大牛进发

首先要说明的是，这是一篇方法论文章，技术干货会在后续的文章中做详细说明。

本篇文章主要着重以下几个问题，一、安全产品买还是自研，二、自研的长期收益在于哪里，安全产品的架构设计踩过的一些坑。三个方面来陈述。一、买还是自研？

这是所有甲方安全从业者一个基本的问题，我们的安全产品是购买第三方的好还是自研好？

我的经验是参考三个前提维度、两个重要参考指标。三个前提维度：信息化程度，人才储备，企业执行效率与领导态度，这三个问题决定是企业是否自研的是与否。

1、信息化程度：首先传统企业和互联网企业的信息化程度是非常不一样的，举个很简单的例子，十年前的套路如下，取自猪猪侠阿里云峰会的PPT：

这套方法论在面对传统的政府、传统企业依旧比较有效，但想黑进大中型互联网公司的核心业务基本非常困难。为什么会造成这么大的差距，我觉得核心问题是企业的信息化程度不太一样，很多安全问题在企业解决信息化和业务需求的时候，安全问题已经被消灭了百分之80-90%。举个简单的例子，一个大中型互联网的运维高并发架构，基本上一定会用到四层+七层负载作为保证。具体的架构图如下：

在这种架构下，我们发现上线流程可控了，在Nginx上做反向代理可以保证公网只暴露80和443。同时公网开发的业务系统，整个公司的运维OP也能做很好的把控，在防火墙上做好相关策略，端口安全问题基本被干掉了百分之90。

好，大家觉得可能说远了，我想表达的是什么？企业的信息化程度决定着企业的风险点范围，越先进的技术架构虽然也存在安全问题，但攻击者的门槛更高，而且越热门的技术威胁情报研究情报也会越活跃，及时出现问题企业也可以第一时间做好应急响应，这样企业可以腾出很多救火的时间去自研安全产品。自研最大的缺点就是见效慢，需要时间，当一个很简单的安全问题能搞穿一个企业的内网时候，我们投入巨资自研并不能解决企业短期的安全，反而会带来领导与兄弟部门的不信任。同时，在信息化不够先进的时候，企业对单一安全产品的依赖会更多，更广。这里看一下我之前公司的创宇盾产品，我认为做的还是比较好的：

如上红框中产品功能，其实大多数互联网公司都有成型的系统能更好的替代工作。比如内容防御，作为一个电商平台，一定会有个更完整的生态风控部门承担这项工作，而资源锁，整站锁对于互联网企业是不太需要的。抛开这些功能的研发量剩下的功能的开发技术门槛是非常低的，最大的难点是需要积累规则经验和稳定性经验，已经由技术问题转变成了时间问题，这已经不属于技术的范畴内了。

WAF demo可参见业内兜哥的公开课：FreeBuf直播间 FreeBuf.COM | 关注黑客与极客​ open.freebuf.com

Github上成型的WAF demo：

jx-sec/jxwaf

2、人才储备：

这个问题非常简单，说句玩笑话，我觉得互联网企业最不缺的就是研发。至少在我们企业基本大多数技术人人都有一门编码能力，不论是SQL、SHELL、C、Python、Java。所以提出需求解决需求的人才储备非常充足，比如我一个从没写过代码的同学，在短期内能够快速的研发出系统（虽然做的比较烂），没有兄弟部门，周围同事的支持和帮助是很难实现的，很多事情自己研究可能需要5天，同事一句话可能就是3分钟的事儿。所以企业内的人才是否广泛具备编码能力也是安全是否适合研发的先决条件。

3、企业执行效率与领导态度：

这个是不可避免的问题，在我看来安全系统很多解决核心问题的功能风险性都偏大。 比如在机器上安装agent、WAF需要抢占入口流量、扫描器可能会给业务数据带来潜在的威胁。这些都会成为企业在安全自研工作的阻力。然而购买安全产品却好得多，因为成熟的安全产品有其他用户的积累，不论稳定性短期内都会比自研的好（这是一定的）。如果企业文化不是一个类似互联网企业那样高速发展，领导愿意不停的去尝试新鲜技术，愿意在不断试错不断调整中快速发展的企业是不适合自研的。两个重要参考依据：我们的企业是不是超热点行业？投入产出比是否值得？

1、超热点行业，比如区块链，可能全世界的黑客都在盯着。甚至为了他不惜动投入大量人力物力进行代码审计，投入各种0day。这种情况下，自研就没有必要，先快速购买提高进攻门槛，才是首先要解决的问题。否则可能会出现，系统还自研到一半，已经丢了200个币，领导会想，这安全部门在干嘛，吃干饭的么？

2、投入产出比是否值得。例如DDOS这种除了3BAT和运营商很少有厂商能够做到大流量清洗，当然这只是技术层面，很多云清洗的厂商，仔细调研你会发现背后都有这四家+运营商的影子在协助。当然说这番话不是说要去买3BAT的运营商产品服务，因为服务嘛就像下馆子，每个企业口味不一样，服务这种产品的客户主观感受更强，在技术解决的情况下，选择合适自己的才是最好的。比如一个中型电商平台，难道我们要为防DDOS自建一个机房进行流量清洗并招聘专门的团队开发么？这是一个很现实的问题，所以以DDOS为例投入产出比是重要的参考因素。二、自研的长期收益在于哪里？

1、灵活，定制化场景：

自研的安全产品一定是最适合企业目前生态和安全现状的，并且可以像互联网企业其他产品一样进行安全迭代开发。在企业安全的救火压力没那么大的时候，很容易在3个月到半年内开发出一套最适用企业生态的产品。我们可以做一个真正意义上的SOC所有安全产品的报警都在上面处理，而不是一方传统的SIEMS和SOC那样很多无法落地。

2、多系统勾连，组成乙方产品无法完成的纵深生态。

其实有一些乙方产品已经实现了相关的功能，比如我们看HIDS阿里云的云盾安骑士：

这项功能如果没有阿里内部自建的威胁情报平台是非常难以实现的，所以我们看到很多一线互联网的云安全产品已经开始逐渐往这个方向走以适应更多的互联网企业。比如WAF，既然我们可以拦截传统安全，为何不能再JS里面种个Cookie字符串做设备指纹对接风控系统，比如数据库审计系统发现异常了，可不可以自动对接WAF和防火墙快速实现拦截策略。这种联动乙方产品很多时候出于商业考虑只给自己的产品预留了接口，而并没有预设第三方接口。造成联动的困难。三、安全自研踩过的坑架构设计，解耦，写注释和文档，多向研发部门的程序员请教开发经验。

不要写前后端粘在一起的代码，太难维护了。我作为研发巨菜做的第一个系统是公司的权限服务器管理系统，使用Django实现的，全程用了Django的模板系统，开发效率高CURD很顺利，人瞬间膨胀了很多，开发一时爽，维护火葬场。粘在一起的代码主要功能接口分散很难做到统一，导致有些bug可能不能修改单一接口就修复给自己留了无数的坑（正在准备重构ing）。架构能解耦就解耦，写好代码和注释，要不有时候改bug看到自己写的代码真的有点懵。学会正确使用git，符合开发的基本流程规范。

2、做好监控、监控！！

又是自我膨胀带来的教训，就大多数安全系统来说，实现功能跟容易。但维持稳定性是重中之重，毕竟安全是跟运维一样的基础保障部门，平时看不见工作，出了事儿容易背锅。不可控，所以在自研系统的时候要做好监控。举个例子，我自研的HIDS系统，觉得一切自我感觉良好，直到有一天我觉得这么完美的系统我应该接进open-falcon做监控，结果接进去我傻眼了。

我的生产者消息队列的积压程度已经不正常了，只能说我们公司的机器好，运算效率高，并没有影响到实际系统的运营。如果我们换一种思路想，假设这是WAF呢？造成核心业务的Reponse延迟这怎么办，所以要做好监控。具体经验后文再说。

以上是我的一些拙见，希望对大家能起到帮助。