安全中间件的设计思路和简单实践

rasp 的侵入式特性和拦截特性导致开发和运维普通不太愿意配合，当生产环境出现问题时往往第一时间先把责任推给 rasp，逐渐的安全部门普遍只能把 rasp 设置为告警模式，而且越是大的集群拦截开的就越少，所以字节的 elkeid 和某外卖大厂内部的 rasp 都是告警模式，没有发挥 rasp 的实际作用。相反的深圳某体制内企业他们的信息系统大部分都是采购的，并采取自研的策略，但是这个企业对外每开放一个端口，都强制要求安装网防 G01 进行管控。

我思考这个问题得出的答案是：
本质上 rasp 是安全部门推动的，对业务性来说代码可控力度较弱，强侵入性和强拦截性导致只有话语权较强的企业才能完整落地。尤其排查问题的成本实在过高，所以导致开发、运维、安全三方技术力量在面对生产环境问题时很容易扯皮，最终 rasp 面临的不是减少拦截性就是减少侵入性。

当然，后面我们再进一步解析安全中间件会发现：本质上这是一个管理问题，还真不是技术问题。

安全中间件的优势是：

运维和开发由于合规因素都是相对隔离的，企业人数越多，运维和开发的隔离性就越明显。在运维人员采购以及管控中间件的这部分工作中，安全中间件的优势就出现了：运维部门采购安全中间件后，往往会开启所有的安全策略，但是安全策略的关闭、调整的权限是留给开发部门的。从管理角度上运维人员已经落实了安全责任，如果开发在使用中间件时为了业务逻辑关闭、调整中间件的安全策略，属于是开发部门的安全问题与运维无关。

这也间接解释了国内很多企业的安全部门尴尬的原因：安全工作要落地，但是各部门又没有相关的能力，只能安全部门自身输出安全能力提供安全产品。而安全预算往往又不足，只能安全部门从业务端开始从业务捋到运维，链路太长又气又累，出了问题还要背锅。但安全部门本质上是要求从业务端就开始层层履行安全责任的监管部门，而目前的现状是运动员又是裁判员，这让人确实很难受。

接下来聊聊我手工改造 tomcat 的一些过程，供大家欣赏：
1）准备两套 tomcat 源码，分别重命名
这样做是因为 maven 环境下的 tomcat 开发调试较为方便利于长期开发，而 ant 是标准的编译方案适合最终发布。

2）使用 idea 直接加载 apache-tomcat-8.5.75-src-maven 目录
点击 modules 按钮
选中 java 按钮点击 sources 按钮声明源码目录
将以下代码放到 pom.xml 里面然后放到源码的根目录中

注意：确保采用正确语言级别，tomcat8.5 我采用 java8 的语法