作者：赵彦,江虎,胡乾威
出版社：机械工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
互联网企业安全高级指南试读：
前言
在互联网+的进程中，一方面互联网企业越来越多，另一方面由外部环境推动的或自发的安全意识越来越强，对安全建设的需求也越来越多，很多企业都开始招聘安全负责人，不乏年薪上百万元和几百万元的安全负责人职位，但事实是很多公司常年用高薪，都招不到合适的安全负责人，其中的原因有很多，比较客观的一条就是这个行业所培养的有互联网整体安全视角的人实在寥寥无几，而这些人大都不缺高薪，也不缺职位。我在“信息安全行业从业指南2.0”一文中曾经写过自2014年开始，安全行业的大部分高端人才都在互联网行业，为什么还是有那么多缺口？细想了一下有几个方面的因素：
·过去，安全并不太受重视，安全从业者的职业发展瓶颈明显，很多拥有整体安全视角的人离开了安全行业转去做其他的事情了。
·早年在乙方安全公司的人经历了给客户从零开始建设安全体系的过程，而后来进入乙方的毕业生，接触客户时大都已经有安全体系，无法体验从0到1的过程并从中学到完整的方法论，很多方法论甚至已“失传”，有些方法论原本就只集中在公司总部的一圈人手里，分支机构除了文档得不到“大象”。
·BAT这类企业安全也早已经过安全建设期，后来者分工很细，除了几个早已身居总监职位的老员工之外，大多数人无法得知安全体系的全貌，很多人离开了BAT也说不清自己责任之外的事情该怎么做。
·二三线互联网企业中，很多团队所持有的安全体系并不完整，也不是业内最佳实践，有些甚至就是救火型团队，更难有体系化的积累。
·当下的很多乙方安全公司，在互联网大潮的冲击下也面临着转型的挑战，要提供符合时代趋势的解决方案仍需努力。
·在社区，目前大家都热衷攻防，而不是企业安全建设。攻击者、乙方、甲方之间仍然存在较大的鸿沟，彼此互相不屑，从社区里也多半只能挖掘到一些单点型的防御手法，即便好学的人订阅了所有的安全站点和微信公众号，恐怕也难以学会企业整体安全建设的方法。
基于以上种种原因，我明显感觉到有一堵墙存在于业界、社区、甲方、乙方、想学习的人和信息的不对称之间，我决定动手推倒这堵墙，所以就有了这本书。
首先本书聚焦于互联网行业的企业级安全解决方案、架构、方法论和建设思路，关于单点技术，市面上已经有很多书，所以本书内容大多不会围绕单点技术来讲，而是希望读者看完之后找到企业安全整体建设的那种感觉。即便是一个甲方安全工程师，也能从中学到互联网公司安全负责人的知识和视野，并以此为导航，逐步积累自己所需要的知识和技能，向更高的层级发展。
对于乙方安全公司的从业者而言，顾问们或许可以从中了解甲方的需求和工作，从而提供更加接地气的交付方案。对于产品设计和研发人员，本书展示的互联网安全架构有助于拓展传统安全的思路，不一定能直接复用，但也许能有所启发。
对于黑客技术爱好者，比较安全的道路仍然是从事安全，不可避免地也要学习这些，高级的渗透和攻击技巧都需要绕过防御手段，了解防御者思维是必须跨过的门槛。
本书同样适用于想了解企业安全建设的CTO、运维总监、研发总监、架构师。但本书内容都假设读者有一定的基础，对一些比较基础的名词和技术没有做太多的解释。
在出版这本书时由于时间和信息披露方面的限制，写出来的部分与我们原先期望的仍有不少差距，但另一方面我们希望像互联网产品的迭代方式一样，不追求完美，但求尽快面世，因此本书也难免带着各种bug上线，也欢迎各位读者的意见或建议。此外，我们计划在本书的第2版中进一步展开某些话题，并且更加系统化，同时会在业界最佳实践方面挑战另一个维度。
最后特别感谢本书的编辑吴怡自我在360工作时便找到我，建议我将网络中的文字写成书，让更多的人能读到。感谢另外两位作者江虎（ID：xti9er）和胡乾威（ID：Rayxcp）帮我分担了很多压力，使得此书能尽快面世。同时感谢netxfly@小米、职业欠钱@腾讯、clyde@电信云堤、终极修炼师@唯品会、laintoday@爱奇艺提供的帮助。理论篇第1章安全大环境与背景
如果从一个很微观的角度切入企业安全这个话题，那么大多数人会像一叶孤舟跌进大海茫茫然找不到方向，所以本章从安全领域整体环境入手，以便于读者找到系统性的那种感觉。尽管笔者没有致力于提供关于企业安全的一个非常完整的“上帝视角”，但也尽可能地兼顾了这方面的需求。1.1 切入“企业安全”的视角
目前安全行业中“二进制”和“脚本”流派广为人知，虽然他们是安全行业的主力军，但除了微观对抗之外，安全是一个很大的工程，比如企业安全管理，实际上并不属于上述两类。确切来说，应归入另外一个群体：CSOs，加了s表示他们是一个群体，这个群体从生态链的顶端联接着绝大多数从业者和安全厂商。在这个描述中我并没有发明新的名词，没有新建一个诸如气宗剑、宗这样的词，只是在知识结构和职业背景上做一定的区分，用于后续对这本书的扩展。
企业安全是不是发现漏洞然后修复漏洞，再设置一下防火墙之类的工作？假如你的公司只有一个产品、两台服务器、3个程序员，我认为这个说法不能算错。不过在绝大多数情况下，企业安全远不止于此。渗透性测试和对抗能不能算企业安全？在一个过于纸上谈兵的企业我觉得这是不错的切入点，不过局部对抗发生于企业安全的各个场景中，它只能算是缩影，不是全貌。企业安全是什么？对传统乙方安全公司，对新兴的业务安全公司、移动安全公司，对甲方的互联网公司，对甲方的传统公司，对咨询顾问，对漏洞研究者，对活跃于各大SRC上的白帽子们来说，诠释肯定都不一样。
先说一下笔者的经历，以便了解是从什么角度来阐述这一问题的。学生时代跟现在的很多白帽子一样玩玩渗透，玩玩二进制，在过去叫幻影（Ph4nt0m）的组织里认识了很多大V，大学毕业后即进了绿盟做渗透测试、安全服务和咨询，这是乙方中离甲方安全最近的职位，接受了绿盟对传统安全体系和方法论的教育，有些10年前的东西放到今天看都还会觉得完全不过时。
现在的安全行业里除了显得有些务虚的安全理论之外，要么就是一边倒的攻防，要么就是过于超前、浮在表面没有落地方案的新概念，这些声音对企业安全实操都缺乏积极的意义。有些方法论是有实操意义的，并不像攻防研究者声称的是纯务虚的东西，纯粹是位置决定想法的问题。还有些流行的概念在解决实际问题上的效果有待验证，并不像市场鼓吹的那么好。技术很重要，但攻防只解决了一半问题，安全的工程化以及体系化的安全架构设计能力是业内普遍的软肋，多数人不擅此道。对市场上的各种观点，我认为可能需要一个相对客观的评价：即某项技术或管理在全生命周期的各个环节中，在不同的行业、不同的场景下有什么样的价值，而不是很随意地贴标签。很多概念10多年前就有了，发明一个新概念讲与过去一样的事情，再给自己贴一个发明者的标签对行业没有积极的意义。纵深防御之类的概念在ISS没被IBM收购之前就有了，为什么现在有的人觉得这个词很新？因为过去没重视，或者说缺少实践。
在绿盟最大的便利并不是下班路上随便都能找到能聊exploit技术的大牛，而是视野：从金字塔视角看到安全的整体解决方案，囊括组织、管理和技术3方面的东西，覆盖全行业全价值链过程的技术方案，算上第三方的话几乎涵盖市面上所有的安全产品和解决方案。有人看到这些会问：这不是传统安全那一套吗？且不急，本书后面讲的都是围绕互联网企业安全的，并不打算在传统安全上花很多篇幅，只是需要区分一下企业安全实际的状况和某些厂商为了兜售自己的产品而宣扬的概念是有所不同的，大多数厂商都会避开自己的弱项而在市场活动及软文上专注地强调自己擅长的概念。
离开绿盟后我去了甲方，一家大型网游公司，2008年将近万台的物理服务器分布于三十多个IDC的规模似乎比当时搜狐全站的IDC规模还要大一些。跟现在一样，那时候也是普遍缺少安全负责人的时代，我也有幸组建了一支属于自己的安全团队，成为当时极少数的安全总监之一。团队中的人现在遍布互联网行业的半壁江山，且都是安全部门独当一面的骨干。在这段时间我亲身经历了从乙方到甲方视角的过渡，从零开始建立安全体系，真正把乙方玩的东西在一家甲方公司落地了。我的方法思路过程跟某些互联网公司不太一样，因为那时候BAT的安全人员大多是毕业后直接去的甲方，一开始就做甲方安全，而我是从乙方到甲方，所以实践上更多是参考了乙方的方法论，再自己摸石头过河，除了攻防之外，多线并行，直接建立较完整的安全体系。
后来在安全行业不太景气的那个年代我好像碰到了安全行业的天花板。之后跟在“信息安全的职业生涯”一文中所述的那样，我实践了里面所说的最后一跳，做了一家网游公司的技术负责人，社会俗名CTO，由安全转向全线技术管理。说实话，在这段时间里我并不是特别重视安全，一方面跟自己是安全出身有关，另一方面这确实是位置决定想法的事情，不是安全不重要，而是有很多事情比安全更重要。老实说，安全这个事情跟金钱关系密切，当你有100万元的时候拿出2万元买个保险箱装它们你觉得值，但你只有2万元的时候要拿出8千元买保险箱，大多数人都会不愿意。可参见我在知乎上回答的那个问题：“为什么做安全一定要去大公司”。我窃以为很多公司的CEO、CTO对安全的认识，翻译过来应该是：被黑是一件很负面的事情，所以找个人筹建团队打包了，只要不出事就行。他们不是真的认为安全非常重要，也不会把安全当成一种竞争力。现在说这句话并不是在影射过去，当下国内很多企业的观念仍然停留在这个水平上。
之后我去360经历了短暂的时光，再次以乙方的身份拜访了企业级客户，很偶然地发现大多数乙方安全公司的顾问或工程师其实都没有企业安全管理的真正经验。虽不能把这些直接等价于纸上谈兵，不过确实是乙方的软肋。在甲方企业高层的眼中，攻防这档子事可以等价于我花点钱让安全公司派几个工程师给我做渗透测试然后修复漏洞，不像大型互联网公司那样上升为系统化和工程化的日常性活动。离开数字公司后，我到了全球化的公司（华为）从事产品线安全，负责两朵云：公有云和终端云。产品线安全属于甲方安全，又跟很多甲方安全不太一样，比传统意义上的甲方安全介入得更深，覆盖率更高的SDLC，直接导向产品设计的源头。对绝大多数甲方而言，你也许在用OS的Dep&ASLR，也许在用各种容器，但你很少会自己去发明轮子，你也许会自己造一个WAF这样的工具，但你可能很少会像微软那样要自己去搞一个EMET这种涉及安全机制层面的东西。但在产品线安全里，这一切都会更进一步，不只是像互联网企业那样关注入侵检测、漏洞扫描等，而是从设计和威胁建模的角度去看整体和细节的安全。这又拓展了我从R&D的视角看待以及分析安全问题的眼界。因此，我可以站在一个较全面、客观、中立的立场来说安全，我不会说某些方式属于纸上谈兵，也不会把攻防捧得至高无上。
接下来，切入本章正题，企业安全是什么？我认为它可以概括为：从广义的信息安全或狭义的网络安全出发，根据企业自身所处的产业地位、IT总投入能力、商业模式和业务需求为目标，而建立的安全解决方案以及为保证方案实践的有效性而进行的一系列系统化、工程化的日常安全活动的集合。怎么感觉有点咬文嚼字？实际上，这里面的每一个项都会决定你的安全整体方案是什么，哪怕同是中国互联网TOP10中的公司，安全需求也完全不一样。
有人也许会觉得CSO干的活有点虚，但凡偏管理都是纸上谈兵。我不直接回答这个问题，我只举一个例子。大多数身在这个行业的人都知道社工库遍地都是，入侵者甚至站在了大数据的维度，国内的数据库绝大多数除了password字段加盐值存储之外，其余信息都以明文保存。而在欧美等地隐私保护是有明确的法律规定的，映射到数据持久化这个细节，就是需要满足一定强度以上的加密算法加密存储。CSO就是需要制定这些策略的人，难道说这些都是形而上学无用的安全措施吗？在互联网公司，安全负责人会较多地介入到日常技术性活动中，但随着组织规模的扩大和行政体系的加深，CSO不再可能像白帽子一样专注于攻防对抗的细节，这也是一个无法回避的现实问题。是不是一定要说出诸如CSRF时IE和其他浏览器的区别，才算是合格的CSO？我觉得这要看具体场景，对于国内排名TOP10以后的互联网企业，我觉得这个要求也许勉强算合理范畴，但对于规模非常庞大的企业而言，这个要求显然太苛刻了，比如我所在公司，CSO属于法务类职位而不是技术类职位。
不想当将军的士兵不是好士兵，虽然有人想走纯技术路线，但是仍有很多人想过要当CSO。CSO这个职位跟某些大牛表达的不完全一致，所以下面的篇幅会继续写，至少在技术层面，CSO不会只停留在微观对抗上，而是会关注系统性建设更多一点。至于跟董事会建立沟通桥梁，虽然也重要，不过关注的人就更少了，本书将不会涉及。1.2 企业安全包括哪些事情
企业安全涵盖7大领域，如下所示：
1）网络安全：基础、狭义但核心的部分，以计算机（PC、服务器、小型机、BYOD……）和网络为主体的网络安全，主要聚焦在纯技术层面。
2）平台和业务安全：跟所在行业和主营业务相关的安全管理，例如反欺诈，不是纯技术层面的内容，是对基础安全的拓展，目的性比较强，属于特定领域的安全，不算广义安全。
3）广义的信息安全：以IT为核心，包括广义上的“Information”载体：除了计算机数据库以外，还有包括纸质文档、机要，市场战略规划等经营管理信息、客户隐私、内部邮件、会议内容、运营数据、第三方的权益信息等，但凡你想得到的都在其中，加上泛“Technology”的大安全体系。
4）IT风险管理、IT审计&内控：对于中大规模的海外上市公司而言，有诸如SOX-404这样的合规性需求，财务之外就是IT，其中所要求的在流程和技术方面的约束性条款跟信息安全管理重叠，属于外围和相关领域，而信息安全管理本身从属于IT风险管理，是CIO视角下的一个子领域。
5）业务持续性管理：BCM（Business Continuity Management）不属于以上任何范畴，但又跟每一块都有交集，如果你觉得3）和4）有点虚，那么BCM绝对是面向实操的领域。最近，有网易、中有支付宝、后有携程，因为各种各样的原因业务中断，损失巨大都属于BCM的范畴。有人会问：这跟安全有什么关系？安全是影响业务中断的很大一部分可能因素，例如DDoS，入侵导致必须关闭服务自检，数据丢失，用户隐私泄露等。又会有人问：这些归入安全管理即可，为什么要跟BCM扯上关系，做安全的人可以不管这些吗？答案自然是可以不管，就好像说：“我是个Java程序员，JVM、dalvik（ART）运行原理不知道又有什么关系，完全不影响我写代码！”事实上，BCM提供了另一种更高维度、更完整的视角来看待业务中断的问题。对于安全事件，它的方法论也比单纯的ISMS更具有可操作性，对业务团队更有亲和力，因为你知道任何以安全团队自我为中心的安全建设都难以落地，最终都不会做得很好。
6）安全品牌营销、渠道维护：CSO有时候要做一些务虚的事情，例如为品牌的安全形象出席一些市场宣介，presentation。笼统一点讲，现在SRC的活动基本也属于这一类。
7）CXO们的其他需求：俗称打杂。这里你不要理解为让安全团队去攻击一下竞争对手的企业这样负面向的事情，而是有很多公司需要做，但运维开发都不干，干不了或者不适合干的事情，安全团队能力强大时可以承包下来的部分，事实上我的职业生涯里就做了不少这样的事情。
基础的网络安全是在甲方的绝大多数安全团队能覆盖的事情，不管你的安全团队能力如何，在公司里有无影响力，这个是必须要做的，因为这是把你招过来的初衷。再往后的发展，是否止于此则看个人的想法。对于沉醉攻防技术的人，其实不需要往后发展了，这些足够了。但如果你的安全团队富有活力和想法，即便你想止于此他们也不干，把部门做大做强是这些人的愿望，只有这样才能给安全团队更大的空间。这点跟乙方是不一样的，对于乙方而言，你可以在某个单点领域上无限深挖，而不会遇到天花板，因为你始终是在满足主营业务的需求，即使你成为骨灰级的专家，公司也会对你在某方面创新有所期待而给你持续发展的可能性。但是在甲方，安全不是主营业务，归根结底，安全是一个保值型的后台职能，不是一个明显能创造收益的前台职能，是一个成本中心而非盈利中心。安全成本的大小跟业务规模以及公司盈利能力相关，公司发展时预算和人员编制都会增加，业务停滞时安全做得再好也不会追加投入，因为无此必要。反面的例子也有：做得不好反而追加投入的，那是一种政治技巧而非现实需要。在乙方，无论你的漏洞挖掘技能多厉害，公司都不会跳出来说“你已经超出我们需求了，你还是去更强大的公司吧”（通常情况下）。但是在甲方，假设是在一个国内排名大约TOP5以后的互联网企业，养一个漏洞挖掘的大牛也会令人很奇怪，他是在给企业创造价值还是在自娱自乐是会受到质疑的，CSO也会被质疑是否花了大价钱挖来的人不是出于业务需要而是用于扩大自己团队在业内影响力这种务虚的事。假如公司到了Google这种级别，有一大堆产品，储备大牛则是顺利成章的，业务上显然是有这种需求的。不过还要看产出是否对主营业务有帮助，工作成果不能转化为主营业务竞争力的尝试性活动在公司有钱的时候无所谓，在公司收紧腰带时则其存在价值就有争议。
以狭义的安全垂直拓展去发展甲方安全团队的思路本质上是个不可控的想法，筹码不在CSO手中，甚至不在CTO手中，而是看主营业务的晴雨表，甲方安全是要看“脸”的，这个脸还不是指跨部门沟通合作，而是在最原始的需求出发点上受限于他们。因此有想法的安全团队在网络安全方面做得比较成熟时会转向平台和业务安全，平台和业务安全是一个很大的领域，发展得好，安全团队的规模会扩大2倍，3倍，并且在企业价值链中的地位会逐渐前移，成为运营性质的职能，结合BCM真正成为一个和运维、开发并驾齐驱的大职能。
BCM在很多人眼里就是DR（Disaster Recovery，灾难恢复），DR其实只是BCM中的一个点，属于下层分支。不过这对技术领域的人而言是最直观的部分，DR在互联网企业里由基础架构部门或运维主导。不过强势的甲方安全团队其实也是能参与其中的，而BCP（Business Continuity Plan，业务持续性计划）中的很大一部分跟安全相关，我之前也主导过BCP&DRP（Disaster Recovery Plan，灾难恢复计划），受益于绿盟那个年代的教育不只是攻防，而是完整的信息安全和风险管理。有兴趣的读者可以看一下BS25999（BCM的一个标准）。
广义的信息安全，比较直观的映射就是ISO2700x系列，行业里的绝大多数人都知道ISO27001和BS7799，这里就不展开了，对真正有安全基础的人而言，都是很简单的东西。在企业里能否做到广义的安全，主要看安全负责人和安全团队在公司里的影响力，对上没有影响力，没有诠释利害关系和游说的能力，自然也就做不到这些。另一方面，狭义安全主要对接运维开发等技术面公司同僚，但是广义安全会对接整个公司的各个部门，对于沟通面的挑战来说，又上了一个新的台阶，在我看来这主要取决于安全的领队人物自己拥有什么样的知识结构以及他的推动能力如何。
在企业完全涉及的7大领域中，对于第4）条，如果你所在的组织有这方面的需求，安全职能自然也会参与其中，是否刻意去发展他则看自己需求，对我朋友中某些做过IT治理和风险咨询的人，相信是有能力一并吃下的，如果是技术派，不建议去尝试。
第6）条属于水到渠成的事情，到了那一步你自然需要考虑，就算你不想，公司也会让你去，就像我现在明明做技术活，却也不知道为什么会跟这一类事情挂上钩。
第7）条有人看时自动过滤了，不过安全负责人自身是否有瓶颈，能否在企业里发展起来跟这条有很大关系，甚至有很多从1）发展到2）、3）的人都需要借助7）这个渠道，点到为止，不多说了。
对于互联网公司，我建议做1）、2）、5）；对于传统行业，我建议做1）、3）、4）、5）。
在互联网行业，我觉得安全工作可以概括为以下几个方面：
·信息安全管理（设计流程、整体策略等），这部分工作约占总量的10%，比较整体，跨度大，但工作量不多。
·基础架构与网络安全：IDC、生产网络的各种链路和设备、服务器、大量的服务端程序和中间件，数据库等，偏运维侧，跟漏洞扫描、打补丁、ACL、安全配置、网络和主机入侵检测等这些事情相关性比较大，约占不到30%的工作量。
·应用与交付安全：对各BG、事业部、业务线自研的产品进行应用层面的安全评估，代码审计，渗透测试，代码框架的安全功能，应用层的防火墙，应用层的入侵检测等，属于有点“繁琐”的工程，“撇不掉、理还乱”，大部分甲方团队都没有足够的人力去应付产品线交付的数量庞大的代码，没有能力去实践完整的SDL，这部分是当下比较有挑战的安全业务，整体比重大于30%，还在持续增长中。
·业务安全：上面提到的2），包括账号安全、交易风控、征信、反价格爬虫、反作弊、反bot程序、反欺诈、反钓鱼、反垃圾信息、舆情监控（内容信息安全）、防游戏外挂、打击黑色产业链、安全情报等，是在“吃饱饭”之后“思淫欲”的进阶需求，在基础安全问题解决之后，越来越受到重视的领域。整体约占30%左右的工作量，有的甚至大过50%。这里也已经纷纷出现乙方的创业型公司试图解决这些痛点。
对整体介绍的部分在前面的篇幅讲得比较多，主要目的是希望“视野”部分不缩水，这些概念在后面篇幅都不打算再展开了。1.3 互联网企业和传统企业在安全建设中的区别
总体来看，传统企业偏重管理，有人说是“三分技术，七分管理”；而互联网企业偏重技术，我认为前面那个三七开可以倒过来。其实这种说法也是不准确的，到底什么算技术，什么算管理，这些都没有明确的定义。安全领域大部分所谓管理不过是组织技术性的活动而已，充其量叫技术管理。
先说一下传统企业和互联网企业在安全建设需求上的差异。
传统企业安全问题的特征如下：
1）IT资产相对固定。
2）业务变更不频繁。
3）网络边界比较固定。
4）IDC规模不会很大，甚至没有。
5）使用基于传统的资产威胁脆弱性的风险管理方法论加上购买和部署商业安全产品（解决方案）通常可以搞定。
大型互联网企业需要应对如下问题：
·海量IDC和海量数据。
·完全的分布式架构。
·应对业务的频繁发布和变更。
同时架构层面需要关注：高性能、高可用性、（水平）扩展性、TCO（ROI）。
在规模不大的互联网公司，传统企业的风险管理方法论是可以沿用的。但在大型互联网公司，传统企业的方法论可能会失效，因为你可能连基础架构上跑什么业务都搞不清，想理清所有系统接口间的调用关系以及数据流去检视设计风险以及设置细粒度的访问控制就是件不现实的事情。产品线极多时，业内没有任何一个团队敢说自己有能力支持全产品线，对于高速发展的业务，当你理清了你想要的时，说不定架构又发生变化了。只有对占公司整体营收比较主要的以及培育性质的战略级的核心业务，才有必要去深入调研并随之更新，其他的主要依靠自动化手段。1.传统企业的安全建设
从安全建设上来看，传统企业的安全建设是：在边界部署硬件防火墙、IPS/IDS、WAF、商业扫描器、堡垒机，在服务器上安装防病毒软件，集成各种设备、终端的安全日志建设SOC，当然购买的安全硬件设备可能远不止这些。在管理手段上比较重视ISMS（信息安全管理体系）的建设，重视制度流程、重视审计，有些行业也必须做等级保护以及满足大量的合规性需求。2.互联网企业的安全建设
互联网可分为生产网络和办公网络，即便最近Google声称取消内网也是针对办公网络而非生产网络。互联网行业的大部分安全建设都围绕生产网络，而办公网络的安全通常只占整体的较小比重。但是某些传统企业可能完全没有生产网络而只有办公网络，那么网络安全也就变成办公网络的网络安全。但我推测，随着社会“互联网+”进程的加速，很多传统企业也会有自己的生产网络，最终都变成和互联网公司一样的形态。所以对于那些在给传统企业客户提供咨询和解决方案的乙方的工程师，如果不学习互联网安全，也迟早会陷入困境。
互联网企业的生产网络中，安全解决方案基本上都是以攻防为驱动的，怕被黑、怕拖库、怕被劫持就是安全建设的最直接的驱动力。互联网公司基本不太会考虑等保、合规这种形而上的需求，只从最实际的角度出发，这一点是比传统企业更务实的地方。曾遇到过一个例子，说要在服务器上装防病毒软件，推测就知道是传统企业的思路，不是没有真正实践过互联网企业安全就是没被业务线挑战过。在大型互联网企业，仅是性能损耗、运维成本和软件成本这几条就能分分钟把这种需求干掉，更不用进入对于服务器防护这种更实际的话题了。很多标准说到底都是各厂商参与编写，博弈并达成妥协，有利于自己产品销售的代言白皮书，并不是完全站在建设性的角度的，作为乙方给政企客户写解决方案建议书无可厚非，但在互联网公司做企业安全，生搬硬套某些标准就会闹出笑话来。3.从量变到质变
对于超过一定规模的大型互联网公司，其IT建设开始进入自己发明轮子的时代，安全解决方案开始局部或进入全部自研的时代。例如不会购买硬件防火墙，而是用服务器+Netfilter的方式自建，不会部署硬件IDS/IPS，而是用其他方式来解决这个问题。其实不难理解，规模小的时候买台硬件防火墙放在最前面，省事。但是规模大了，难道去买1000台硬防放在IDC机房？成本上就没法通过批准。再说，基于分布式系统的CAP理论和Map-Reduce衍生的一系列互联网架构，本质上都具有“无限”的扩展能力，而对于传统的硬件盒子式的解决方案，其设计大多源于对小型网络体系架构的理解，基本不具备扩展能力，完全不能适应大规模的互联网架构。在这种情况下甲方安全团队自己动手去打造完全围绕自身业务的解决方案也就成必然趋势。4.大型互联网企业安全建设的方法论
自研或对开源软件进行二次开发+无限水平扩展的软件架构+构建于普通中低端硬件之上（PC服务器甚至是白牌）+大数据机器学习的方式，是目前大型互联网公司用来应对业务持续性增长的主流安全解决方案。是否真的到了机器学习阶段这个有点难说，但是安全进入大数据时代则是肯定的。
与办公网络和雇员信息安全管理相比，互联网公司的文化比较开放，一般不太会维持激进的安全政策（对雇员做太多信息安全方面的管制和限制），这点也是跟传统企业差别比较大的地方。
也有一些灰色地带，比如TCO较高的安全方案，一开始没感觉，但实质是吸毒，随着IDC的规模扩张，安全的成本越来越大，最后被自己巨大的成本“毒死”。对于做惯传统行业解决方案且客户手里都有大把预算的顾问来说，对这一点是没感觉的，几千万元的安全整体方案信手拈来，但是放到互联网中，一旦业务规模成倍增长，这些方案最终都会走入死胡同。不止是成本，如果不能做到兼顾宿主的性能，安全架构随整个业务架构水平扩展，保证高可用性，最终安全措施都会走进死胡同。
以安全集成为自身职业亮点的人如果不积极学习，会有很大贬值风险，因为以后不需要堆硬件盒子式的解决方案了，就算堆也不再是原来的堆法。1.4 不同规模企业的安全管理1.创业型公司
对于创业型公司而言，安全不是第一位的，我在唱反调吗？应该只是大实话而已。安全建设的需求应该是：保障最基本的部分，追求最高性价比，不求大而全，映射到技术实现应该是做如下事情：
·基本的补丁管理要做。
·漏洞管理要做。
·L3~L7的基本的访问控制。
·没有弱密码，管好密码。
·账号认证鉴权不求各种基于条件的高大上的实时风控，但求基本功能到位。
·办公网络做到统一集中管理（100人以上规模）和企业防病毒，几个人的话，就完全不用考虑了，APT什么的就听一听拉倒了。
·流程什么的就没必要去搞了，有什么需求，口头约束一下。
·找两篇用到的开发语言的安全编程规范给程序员看看，安全专家们说的SDL就不要去追求了，那个东西没有一堆安全“准”专家玩不起来。
·系统加固什么的，网上找两篇文章对一下，确保没有root直接跑进程，chmod 777，管理后台弱密码对外这种低级错误，当然有进一步需求，也可以参考后面的技术篇中的措施。
·实惠一点的，找个靠谱的白帽子兼职做一下测试，或者众测也行。
是不是觉得简陋了一点？我估计很多乙方提供的服务除了卖产品之外也不会比这个效果更好了。不过，现在不少创业公司是拿了不小的风投的，也没那么寒酸。另外一个很重要的特征是，创业公司基本都上公有云了，不会自己再去折腾IDC那点事，所以相对而言以上措施中的一部分可以等价于：
1）使用云平台提供的安全能力，包括各种抗DDoS、WAF、HIDS等。
2）使用市场中第三方安全厂商提供的安全能力。
具体怎么选怎么用就不展开讲了，不过不要因为迷信云平台关于安全能力的广告而自己不再去设防，毕竟针对租户级的通用型的安全方案其覆盖面和防御的维度是有限的。2.大中型企业
这个层次对应市场上大多数公司的安全需求，它的典型特征是，业务营收的持续性需要安全来保障。公司愿意在IT安全上投入固定的成本，通常小于IT总投入的10%，不过这已经不错了。这时候开始有专职的安全人员或安全团队，建设上重视效果和ROI，会具备初步的纵深防御能力。对应技术上的需求为：
·L2~L7中的每一层拥有完整的安全设计。
·对所有的服务器、PC终端、移动设备，具有统一集中的状态感知、安全检测及防护能力。
·应用层面细粒度控制。
·全流量入侵检测能力。
·无死角1天漏洞发现能力。
·在安全等级较高的区域建立纵深防御和一定的0天发现能力。
·初具规模的安全专职团队。
·对应用交付有自主的评估和修补能力。
·从IT服务层面建立必要的流程、业务持续性以及风控应急措施。
·对业务安全形成自己的风控及安全管理方法论。
·将难以自己实现的部分外包。
好像跟前面的描述比一下子抽象了？是的，这个层级的安全需求没办法很具体地量化。不同的业务模式对应的安全实现还是有很大的不同，加上这个区间里的公司营收规模可以差很大，对应的安全投入也可以差很多。那什么样的公司归入这个区间呢？比如四大行，国内TOP10甚至TOP5以后的互联网公司，大量的电信、金融、政府、能源等企业都属于这个区间，但我为什么不把BAT归入这个区间？这样的分类岂不是不科学？我之所以这样分类完全是从安全建设的复杂度上去考量的，而不是从安全建设的资金投入上去归类的。很多行业（比如金融）的安全投入很大，但这些解决方案大都是靠花钱就能买来的，而BAT的方案花钱不一定能买得到，很多都需要自己动手去打造，对安全团队的定位、能力和需求完全不一样。那BAT以外较大的互联网公司呢？我觉得他们会玩些各自特点的小花样，但是不会进入大范围的复杂的安全建设，这是由公司的整体面和业务决定的，不需要过分保障和超前业务的安全建设。
再往上一层是大型互联网企业。1.5 生态级企业vs平台级企业安全建设的需求
生态级企业和平台级企业之间的安全建设需求不仅仅是量的差别而是质的差别。1.差别的表象
主要差别表现在是否大量地进入自己造轮子的时代，即安全建设需要依托于自研，而非采用商业解决方案或依赖于开源工具的实现。
那么平台级公司和生态级公司的区别又在哪里？从表象上看，生态级公司的大型基础架构如果用传统的安全方案几乎都无法满足，所以会大量的进入自研。而平台级公司则会依赖开源工具更多一些，不会对所有解决方案场景下的安全工具进行自研。如果有预算也会优先投在“业务安全”侧，比如反欺诈平台等等，而不会自己去搞入侵检测。当然，这有可能是个伪命题，有可能随着时间的推移，乙方公司也开始提供具有可扩展性、能应对分布式架构的方案，或者当时间尺度拉得长一点，平台级公司每年在自研上投入一点点，多年之后也具备了BAT级别的安全能力也并非完全不可能。不过这些都是理想状况，现实总是受到多方面因素制约的。2.差别的成因
第一个因素是技术驱动在底层还是在应用层驱动业务。表象上，平台级公司和生态级公司都是以PC端Web服务为入口的平台应用和以移动端APP入口的移动应用。有的依赖于一些PC客户端或移动端偏底层的APP，但在技术实现方式上，平台级公司更多地直接使用或少量修改开源软件，而生态级公司的IT基础设施则会类似于Google的三篇论文一样，不仅仅停留在使用和少量修改，而是会进入自己造轮子的阶段。其中所造的轮子是否对业界有意义这种问题暂时不去评价，但对应的安全建设则反映出平台级公司的安全主要围绕应用层面，而生态级公司的安全会覆盖基础架构和应用层面两块。直接使用开源工具的部分交给社区去处理，自己跟进打补丁就行了，但如果是自己开发的，那么就需要自己去解决一揽子的安全问题，比如Google造了Android这个轮子，那Android一系列的安全问题Google需要自己解决，比如阿里自己去搞了一个ODPS，那阿里的牛人也需要解决这个，再比如华为在物联网领域造了LiteOS这个轮子，自然也要去处理对应的问题，而这些偏底层的问题显然早已超出应用安全的范畴，也不是一般的甲方安全团队有能力应对的。其实有些平台级公司也是发明了一些轮子的，比如自动化运维工具，比如一些NOSQL，不过IDC规模两者之间仍然差得比较远，上层的业务复杂度也有差距，支持的研发团队的规模也有差距，对安全工具的自动化能力和数据处理规模仍然存在阶梯级的差别，这一点也决定了为什么要自研。安全其实只是IT整体技术建设的一个子集，当整体技术架构和实现方式进入自产自销阶段时，安全建设也必然进入这个范畴。对于很多实际上依靠业务和线下资源驱动而非技术驱动的互联网公司而言，安全建设去做太多高大上的事情显然是没有必要的。
第二个因素是钱，钱也分为两个方面：1）成本；2）ROI。假设安全投入按IT总投入的固定10%算，又假设生态级公司的安全建设成本是平台级公司的5~10倍，这个成本除了带宽、IDC服务器软硬件之外，还有技术团队，加起来才是总拥有成本TCO。10个人的安全团队和100个人的安全团队能做的事情相差太大，具体可以参考我在知乎上的帖子“为什么从事信息安全行业一定要去大公司？”。还有一方面则类似于“去IOE”，上面提到目前对于大型互联网没有合适的安全解决方案，即使有，这个成本可能也会无法接受，所以假如乙方公司能推出既能支撑业务规模，又具有性价比的方案，我认为甲方安全团队真的没有必要再去造轮子了。
第三个因素是人。安全团队的人员数量也只是一个很表面的数字，安全团队的构成才是实力，能囤到大牛的安全团队和由初级工程师组成的安全团队显然是不一样的，首先前者的成本不是所有的公司都能接受，其次，平台不够大即使大牛来了也未必有用武之地。大多数平台级公司中安全团队的知识和经验集中在Web/App、应用层协议、Web容器、中间件和数据库，生态级公司则扩展至系统底层、二进制、运行时环境和内核级别，能力积累也存在差别。这里并无褒贬之意，仅在说明业务对技术的需求不一样。3.平台级公司的“止步”点
那么，平台级公司在安全建设上是不是就没有乐趣呢？其实这类公司也玩一些小花样，比如修改SSHD、LVS，加入一些安全特性。可能也会自己定制一个WAF，或者搞搞日志的大数据分析。但比如涉及DPI、全流量入侵检测、SDN、内核级别的安全机制，基本上都不会介入，对于一个规模不是特别大的平台级公司的甲方安全团队而言，这些门槛还是有点高。4.生态级公司的竞技场
生态级公司是不是全领域进军自己造轮子呢？也不是，主要工作还是在入侵检测、WAF、扫描器、抗DDoS、日志分析等领域。在SDL环节上可能也会自己研发些工具，但很与比直接使用商业工具更短平快。阿里钱盾、腾讯管家、百度杀毒这些都跟360客户端一样与生产网络没什么关系，就不去讲了。另外自研工具有一个原则：都限定在“民用”领域，不会自己去发明一个RSA算法这样的东西。
国内的平台级公司里也有一个例外：数字公司，因为其主营业务是信息安全，所以就没有安全投资固定占比理论的影响。1.6 云环境下的安全变迁
云计算的本质是改变企业需求方通过传统的渠道获取IT资源的形式。传统的方式是一个企业假如要构建信息化的能力，必须要采购硬件，采购软件，维护一个较大的IT团队，TCO很高。但是，到了云计算时代，这一切你都不需要，你只要轻点鼠标就可以获取大量的计算、存储和网络资源，并且不再需要专门的人员去IDC机房维护服务器，不需要大量的运维人员，甚至某些通用的应用开发都省了，你可以将手头的IT预算用于最需要的部分—完全聚焦于自己的业务，而不用费大量的精力维护基础设施，甚至资源的获取变得弹性：需要时轻易获取大量甚至海量的计算资源，用完后可以及时释放，不用担心资产闲置和老化。在IT产业的销售模式中被颠覆的一环是，传统企业不再直接购买服务器存储商业数据库，而是通过云计算平台获取。同样地安全到了云计算时代，企业客户会更希望通过云化的方式来获取和整合安全的解决方案，例如SaaS（Security as a Service），这就要求安全产品或解决方案本身需要支持虚拟化、软件化、分布式、可扩展性，并且利用大数据和人工智能，利用云端无限的计算和存储能力，缓解传统安全解决方案中数据的离散、单点的计算能容不足，信息孤岛和无法联动等问题。1.云的租户
对使用云的租户而言，云平台自身以及应用超市Marketplace（类似APP store）集成了各个安全厂商的云安全产品以及可托管的安全专家服务。如果自身没有太强烈地要主导安全实践的意愿，通常情况下通过应用超市和云平台免费提供的安全功能就可以快速构建基础的安全能力。如果希望得到进阶的安全防护，则必须自己进一步动手。2.云安全提供商
在传统的安全方案中，安全厂商以提供硬件安全产品和安全服务为主，而在云环境下，硬件形式的安全方案会越来越不合拍，与之相比，把竞争力构建在软件层面的安全方案会成为云上的主流。相比过去面对面提供安全服务，现在则转变为在租户侧部署各种安全传感器，通过在云端汇聚安全度量数据，结合威胁情报或由专家解读数据来提供可管理的一站式安全服务。第2章安全的组织
很多人忽略组织，但实际上组织是比技术和流程更重要的东西，“人”是所有问题的决定性因素。本章就讲一下安全组织中的人。2.1 创业型企业一定需要CSO吗1.招聘方的诉求
当下不少创业型公司都在找CSO，也有找到我的，就顺带分享一下我对这个问题的思考。首先这个问题即便是对同一个人而言可能答案也会因时而变，其次CSO只是一个代表性的称呼，大家不要过于纠结一定要做什么事才算CSO，CSO和CISO又有什么区别之类的，在这个语境下用来指代招聘方想找拥有全局安全管理经验的人，甚至最好是资深的从业者，他能带一支哪怕是几个人的安全团队，并能把安全相关的事全部揽过去。2.不同阶段的需求
对于尚在天使融资阶段，找个CSO大多就是去忽悠投资人的，通俗一点理解就是凑一支履历光鲜的队伍去“骗钱”。能不能做事情这个很难说，也不能说人家一定做不了事情，这种只能事后诸葛亮的盖棺定论，随便说人不靠谱也是不负责任的，不过我想对于大多数有不错岗位的人而言应该是不会去的。
对于拿到A轮、B轮投资的阶段，业务方向已被证明，业务量不大但进入快速成长期，问题层出不穷。CEO和CTO觉得头疼并且想把这部分压力转嫁出去，理论上是应该找一个懂安全的人的，但是现在这个时间点（也就是2016年）真的不是一个好时间，在当下很多公司用数百万也经常找不到合适的CSO，创业型公司要在这个时间点上争夺安全人才真的是很累的一件事。建议找2~3个靠谱的安全工程师，然后CTO（技术总监）、运维Leader、开发的架构师这几个角色快速补一点安全的知识和方法论，哪怕是充当救火队长赶鸭子上架，大家配合一下，应该也能把安全撑起来，不一定非要找一个大牛级的CSO，因为有时候业务量没那么大规模，不一定需要很高级别的人，且创业型公司为了保持自己的鲜活也不需要套用大公司的流程和方法，做好基础的运维安全，代码安全，加强一些安全意识，不出问题的时候腾出时间来研究一下下一步怎么做，跟时间和业务增长速度赛跑，跑着跑着，应该就会越来越轻松了。当然，作为创业者，如果你有一个安全领域的朋友愿意帮你出谋划策，偶尔回答一下安全建设如何做这类问题，其实那CSO的需求也就解决了，代价只是请吃几顿饭。
对于拿到C轮、D轮、E轮投资的阶段，业务初具规模，开始朝更高的目标冲刺，同时能给人画更多的“饼”，如果之前已经招到靠谱的安全工程师，那这个时候应该已经成长起来，承担起Leader的角色，通常也不需要从外部招CSO了。这个时候想从外部招CSO的都是之前主观的或被迫的不太重视安全，出了问题才想要头痛医头脚痛医脚。这个时候的业务形态跟大公司比应该是“麻雀虽小五脏俱全”，安全管理上应该是有很多相似的地方了，对于初具规模的业务而言安
试读结束[说明：试读内容隐藏了图片]