3.6　需要自己发明安全机制吗

1. 安全机制的含义

首先解释一下发明安全机制这句话的意思。安全机制包括：常见的对称和非对称加密算法，操作系统自带的RBAC基于角色的访问控制，自带的防火墙Netfilter，Android的基于appid隔离的机制，kernel支持的DEP（数据段执行保护），以及各种ASLR（地址空间随机映射），各种安全函数、服务器软件的安全选项，这些都属于已经存在的安全机制，注意我用的词是“已经存在”，而这个话题是针对是不是要在已有的安全机制上再去发明新的安全机制，比如三星手机的KNOX，就是在Android基础上自己造了个*。

2. 企业安全建设中的需求

企业安全的日常工作是不是也会面临自己去发明安全机制的需求？会，但是不常见。实际上，在日常中发生的绝大多数问题都属于对现有安全机制的理解有误、没有启用或没有正确使用安全机制而导致的漏洞，而不是缺少安全机制，所以绝大多数场景都不需要去发明安全机制。发明安全机制是需要成本的，且需要有足够的自信，否则不健全的安全机制消耗了开发的人力又会引入新的安全问题，但此话不绝对。

3. 取舍点

那什么情况下应该发明安全机制呢，这其实非常考验判断者的技术实力。之前也提过对于很多安全漏洞的修复是否要上升层次的问题，首先要判断这是单个问题还是属于一类问题，如果是前者，用救火的方式堵上这个洞就好，没必要再去考虑更多。但假如这是一类问题，而你又没提出通杀这一类问题的手段就会永远处于救火之中，疲于奔命。如果是一类问题，分几种情况。第一种归入安全编程能力不足导致的安全问题，这类问题不需要通过导入新机制解决，而是通过加强SDL的某些环节，加强培训教育去解决。第二种情况则是属于在相应的领域还没有成熟的安全解决方案或者现有的安全机制对抗强度太弱，则可以考虑自己去造*。

比如有一个函数存在整形溢出，但只有在极特殊的情况下才能触发，平时开发过程中已经大量的使用了安全函数，启用了编译的安全选项，除了给这个函数加一个条件判断修复这个bug外是不是还要考虑更进一层的防护呢？大多数情况下显然是没必要的，假如这是一个公共函数，那你可以选择把修复后的代码封装成安全的API，避免其他程序员自己实现的时候发生同类问题。

换个问题，如果公司产品的某个私有协议总是被人频繁地解密和利用，而这种解密对产品的影响又较大，假设就是游戏客户端跟服务端通信的指令都能被破解和仿冒，那这种情况下就需要考虑是否更改或创建安全机制，即有没有必要通过实现更强的通信协议加密或提高客户端反调试的对抗等级来缓解这一问题。

如果你说新建安全机制也是补洞的话，其实也没错，就像DEP相对于用户态的程序而言是一种机制，而对于操作系统和冯·诺依曼体系结构而言是一个洞。当你过于勤奋地在很微观的细节上补洞却总是补不完的时候，不妨停下来看看能否在更高更抽象的层次上打个补丁。

安全工程师如果要晋升为Leader很重要的一点就是对安全事件和安全漏洞的抽象能力，没有抽象就谈不上PDCA，就意味着更高的管理者对安全KPI在你手上能否改进不一定有信心。在纵深防御体系向中高阶段发展时，实际上会比较多的遇到是否要创新安全机制的问题，但是这个场景大多数公司未必会遇到。