大型互联网组织安全产品研发与落地的一些方法与思考

一、读前必看

1、写这篇文章的心理动机

工作几年的时间里一直在从事技术相关的工作，自己闲暇之余和工作经历经常会有脉脉上所说的工作如同拧螺丝一样的工作。从个人角度的很长时间的确给我造成了很大的困扰，毕竟在国内鼓吹35岁技术人员就被淘汰的大氛围下，我也经常感受到危机感。我经过工作的几年时间对这个问题形成了一些思考。希望借此文分享给大家。

2、文章讨论的适用范围

技术人员成长从大体方法论而言分两类:一种是向上走,贴近业务或者架构、一种是往下走深入行业技术极限，开发一个更好的零部件或者工具。本文更多是论述比较高风险安全产品从产生到落地的过程。

3、适合阅读对象

安全产品经理

安全研发工程师

对产品感兴趣的安全工程师

二、组织开展项目研发前的准备工作

确定项目产出程度，即投入产出是否简单明了，我一般把项目分为复杂项目和简单项目，以下为个人经验作为界定，可能有误

复杂项目的特征:

1.安全产品需要公司多维度人员参与开发，如风控系统可能需要SDK，逻辑引擎，消息中间件平台，前后端多方面支持，可以拆分成多个微服务。

2.接入面积较广，可能成为不同业务线的接入。尤其大厂可能有不同的业务场景，都需要接入此系统，如比如直播搜索都需要接入此系统。

3.在生产流程上存在高危风险点，如分布式HIDS,WAF等在生产会侵入生产服务器进程或者流量转发流程，需要多维度配合。

4.项目的核心功能会超过20个接口以上的前后端耦合。

相对简单项目的特征:

1.管理流程类项目:项目仅侵入管理流程节点，并不会耦合业务与生产风险。

2.生产无侵入类项目:如日志分析类，蜜罐类相关的项目。

个人经验：简单项目可以采用全栈式开发的模式，即1-2个具有安全背景的研发工程师完成相关的工作即可。一旦出现复杂项目的特征，需要慎重考虑是自研还是购买第三方产品，下文的人员配比会详细的解释原因。

三、复杂安全项目的全流程闭环

越来越感觉到人的精力十分有限，精细化分工是社会提高生产效率演进的产物，具备科学性，但不是个人视野狭隘或抱怨自己拧螺丝的借口

3.1 复杂项目的全流程闭环

主要针对大型甲方的内部安全产品，乙方同学可以补充，主要区别在后方，不详细赘述

1.需求收集与运营流程闭环思考:

我们以大家熟悉的WAF来进行举例，在此阶段我们要考虑，我们研发的WAF有多少个业务部门要接入，他们有没有什么特殊的需求和顾虑要访谈收集。运营流程上我们的WAF有多少种视角(使用角色)，如一线RD想要看什么，规则运营者关注什么，安全部门的Leader想要看什么，公司的CTO想要看什么，他们各自需要什么样的功能。

2.原型图制定与敏捷开发规划:

还以我们的WAF为例，WAF最重要的是Firewall意思即防火墙，所以Web Application Firewall这个名词的字面意思是首要需要进行开发的，即规则配置，规则运转，规则下发，拦截模块。结合上面需求调研的结果是首要优先出具原型图和prd文档。所以排期会比较明确。

3.架构模型的闭环:

基于一个WAF，我们做完原型图与规划后。需要才真正要站在研发的架构视角看问题。基于运营闭环与原型图的模板，我们技术怎么选型，拆成多少个大模块。消息队列用什么，怎么设计架构能让产品经理比较轻易的改需求（注意合理的改需求）。

4.多模块模块耦合的通信结构制定:

基于一个WAF可能，web配置平台后端逻辑通过HTTP接口沟通。命中日志与waf数据仓库通过kafka沟通。配置中心与waf核心模块可能通过etcd的kv与zk的树形结构进行同步。那么彼此的接口定义，json字段请务必先约定好。请用文档说话，不要嘴上说!!!

5.模块内部的设计模式分析与微服务拆分:

比如一个数据库读写的模块，以OO的思想。我们可以拆分为业务逻辑层与数据库原子层。那么数据库原子层与业务逻辑层是拆分成微服务还是写成一个模块，需要调研与分析。不怕大家笑话，我原来写代码SQL和业务逻辑写在一起的，结果改个需求，呵呵大家都懂得，真的有一种SQLboy的无力感。后来我才知道原来错的不是公司螺丝钉分工模式，错的是我不会写代码。

6.运营流程的闭环并loop 1-5:

平台做出来是要有人用的，那么势必会被吐槽。那么需要有人接受吐槽的point，并整理需求，反复loop1-5，当架构设计的越合理，当需求到来时改动的面积会越小。