3.4 安全需要向业务妥协吗
1. 业界百态
在安全行业5年以下的新人得到的灌输基本都是“安全不可或缺”，老兵们可能也有点“看破红尘”的味道，觉得高层重不重视安全也就那么回事。对乙方来说高声呼吁安全的重要性哪怕是强调的有点过头也可以理解，因为是赖以生存的利益相关者，靠它吃饭，影响股价。而对于甲方，实际上要分几种，第一类认为安全压倒一切，且心口一致。持有这类想法的实际又可以细分为两种人，第一种对安全行业涉猎不深，还停留在原始的执念阶段，第二种人的思想可以表达为“业务怎么样与我无关，只要不出安全问题，业务死了都无所谓”，这两种从表象上看都属于第一类，但本质上不同；而第二类人口头唱安全重要，但心里还是会妥协。可见甲方安全团队是形形色色的。
2. 安全的本质
撇开上述业界百态，先看安全管理的本质是什么？安全的本质其实是风险管理，绝对的安全可能吗，说绝对安全本身就是个笑话。就像知名黑客袁哥说的，哪怕是Fireeye这样的公司也一样会被APT，原因是攻防不对等，防御者要防御所有的面，而攻击者只要攻破其中一个面的一个点就可以了，公司几千人的客户端行为不是安全管理员能决定和预测的。在所有的面上重兵布防可不可以，理论上可以，但实际绝对做不到。接近于绝对安全的系统是什么样的？尽可能的不提供服务，提供服务也只提供最单调的数据交互模型，尽可能少的表现元素，那样的话还是互联网吗，还有用户体验可言吗？而且安全和成本永远要追求一个平衡。假设一个大中型互联网公司的安全建设成本从0～60分需要1000万，60～80分需要2000万，80～90分需要5000万，90～95分需要2亿，这种边际成本递增是很多公司无法承受的，只能追求最佳ROI，虽然最佳ROI难以衡量，但绝大多数人不会拿出收入的50%去投安全建设。
3. 妥协的原则
既然安全建设的本质是以一定的成本追求最大的安全防护效果，那一定是会有所妥协的。于是反过来揣摩一下那些说宁可业务死也要做安全的观点的初衷是什么呢，也许你猜到了，怕担责任！因为业务死了安全团队不担责任，他们可以说“你看安全不是没出问题嘛！”这固然是一种保护自己的方法，但是从公司的角度看这就有待商榷了。我认为安全本质还是为业务服务，如果业务死了，即使安全做得再好也没价值，更准确一点说，安全需要为业务量身定制，如果业务要轻装上阵，你给他重甲也不行，只能穿防弹背心。安全做得过于重度都是不合适的。相对而言第二类人拥有更加积极的心态，坚持原则又懂得给业务让路，只是要把握好分寸，避免自己的好心被人利用，成为安全问题不整改的免责窗口，那样就事与愿违了。
安全做得不称职的表现，除了“无视业务死活”，还包括：用户体验大打折扣，产品竞争力下降；公司内部流程大幅增加，严重影响工作效率；限制太多员工满意度严重下降，人员流失；规章制度太多，以至于公司文化显得不近人情……这些都属于安全做过头的表现。
有的人出发得太久，以至于忘了初衷是什么。
那么哪些可以妥协，哪些必须坚守呢？高危漏洞，有明显的利用场景，不能妥协。重要的安全特性，比如公有云中的VPC，底层缺少一个安全特性，直接会导致安全建设的上层建筑失去了“地基”，整个都不牢靠了，这种还是要坚持，可以不精致，但必须有。
对于不痛不痒的漏洞，以及待开发的安全功能，如果开发周期很长，受众群体很少，使用该功能的用户比例极少，边缘性产品，只影响某个中间版本到下个版本被其他机制完全取代了，诸如此类的情况可以考虑酌情妥协。当然这还会涉及另一个话题在不同的维度解决问题，这个之后再展开。
妥协并非退让，而是大局观，试想公司业务没有竞争力时，做安全的一样面临窘境，无论如何都要看主营业务的脸色，与其被动跟随不如快出半个身位。
最后补充一点：妥协不应该发生在工程师层面，而是应该在Leader和安全负责人这个层面。如果在安全工程师自己提的整改方案这个层面上，自己主动开始妥协了，那后面很多事情就没法做了。
