【企业安全】企业安全架构建设

1 安全组织架构

在甲方的安全工作中，重点自然是在企业的安全建设上，但是为了能持续不断的输出，安全队伍的建设变成了不可或缺的一环。成员的能力决定着企业安全的高度，合理的安全队伍配置是整个建设之路上的引擎。

1.1 理想中团队

按照角色与工作职责，安全相关的岗位可细分为：CSO、安全架构、安全审计、安全测试、代码审计、安全开发、安全运维、安全运营、安全风控等方向，比较理想的安全团队并不是要求设置以上全部岗位，而是在开展相关工作时需要涉及这些专业技能。根据公司的大小差异，各个岗位的名称与headcount也都不太一样。

1.2 现实版团队

“理想很丰满，现实很骨感”，这句话尤其请乙方安全工程师注意。为什么是乙方安全工程师呢？因为很多人以后都希望转到甲方。虽然平时有接触不少客户，但若不是项目负责人或不是参与安全评估类的项目，很少清楚知道客户所处环境。很多甲方公司或许并没有专职的安全人员，或许仅有临时工，此类场景常常出现在传统企业、非互联网过渡到互联网的企业中，所以在准备跳槽时对企业的选择需要谨慎。

作为掌舵者的CSO重要性不言而喻，由于具备实战能力与经验兼备的CSO较少，从成本与安全需求的迫切性出发，不少企业在该职位上也没有留下足够的薪金，也导致了目前比较普遍的现象：

• 安全由运维leader负责，向cto汇报；
• 安全由测试leader负责，向cto汇报；
• 安全由开发leader负责，向cto汇报；
• 企业内部由运维/测试/开发参与安全项目，像上一级负责人汇报…

术业有专攻，即使很强大的leader在遇到一些安全项目的决策时，也极有可能持保守态度，在没把握情况下与其犯错不如不做。相比专业的安全人员，这无疑在一定程度上限制了企业安全的发展。此外，由于对安全领域的不熟悉，在与上级领导沟通、对安全项目上的投入等方面表现不足，往往也会成为制约企业安全建设的因素。

还有一种较为常见的场景，公司中并没有设置CSO这一职位，该职务一般由安全部经理甚至有发展潜力的安全工程师担任。所谓的潜力简要概括为：

1.3 安全架构组

组成：CTO、CSO、架构师、安全架构师、中间件等各部门领导

职能：重大安全架构决策，安全相关规章制度评审。

1.4 安全接口人

成员：各业务部门负责人（可设置AB岗）

职责：负责所在部门/业务线安全问题的对接、沟通、跟踪。

2 安全架构规划

安全架构规划是一个非常复杂与庞大的话题，由于水平有限以下观点仅供参考。在一些对外交流中，有不少人会参照书本上或其他公司分享的案例，从标准体系(27001&等级保护等)—>具体工作的视角进行规划。但作为安全建设从头开始的体验者，深刻感受其可行性、见效率与不足之处。

2.1 安全风险发掘

在实习的时候，记得当时的部门领导(上交大网络安全学院老师)说过：信息安全从业者就好比是医生，企业有问题需要我们去出诊，首先就是要根据病症进行相关检查分析才能对症下药。那么甲方安全工程师做安全就是医生给自己看病，需要不断的搜集异常症状并进行分析判断是否有问题，即安全风险发掘。以下是对常见企业安全风险的简单梳理：

要做到实用性，往往要求熟悉公司网络环境与业务形态，此外还需要一定的嗅觉性，追究其根源便是：意识、经验与视野。

2.2 外部经验交流

在一次企业安全沙龙中，看到了蘑菇街的安全项目蓝图，并从中得以借鉴。通过前期安全风险挖掘的积累，信息安全组内进行头脑风暴并对相关项目进行梳理，把相同实现效果的项目整合成一大类，再把各个大类聚合在一起，便有了初始的安全架构规划图：

安全是动态的、持续性的，需要保持一颗善于发现问题、思考总结的心，不断完善企业安全的整体画像，不断优化相关环节的同时也进行项目的推进。

3 安全工作推动

3.1 领导支持

安全工作的推动是一个自上而下的过程，在建设的伊始便是与上层领导沟通，并争取获得必要的支持，具体理由可参照【企业安全：企业安全建设需求】进行分析与汇报。此外如果是项目负责人，应该自己先竭尽所能的去推动，实在有困难时邀请领导出面参与会议或回复邮件，也是提升工作效率的一大利器。

3.2 安全运营

在企业安全建设初期，除了救火工作外还建议开展体系化的、丰富的安全意识培训。人是安全的知名薄弱环节，因为员工的安全意识参差不齐，所以需要进行多个渠道（邮件、即时通讯工作群）、多种方式（海报、易拉宝、动画片、暴漫）、多种内容（通用安全意识、最新安全威胁、行业安全情况）等方面的长期"洗脑"。这里把安全意识的培训推广工作加入到了安全运营的一个环节，除此之外安全方案的不断优化、漏扫插件的更新、waf规则的即时添加调整、SRC的推广都应该属于运营范畴。

3.3 做事思路

根据已经参与或负责的安全项目发现，在甲方做事情很讲究做事的思路。以下简要的记录了深有体会的几个小点：

1）城市包围农村，结合多个部门一起推动

在推动专项安全项目时，会出现不好对付的部门。这时候不能硬碰硬，从存在安全问题的部门做起，其次是支持安全工作的部门，接着再按照实现难易程度与花销依次排序，把最难推动的部门放最后。推动过程中，不断及时汇报项目进展情况，比如本周推动90%的部门完成安全改造，剩余10%的部门尚未整改。迫于压力，一般情况下10%左右的部门也会尽快加入进来。

2）鼓励+奖励 > 惩罚

面对业务部门时采用鼓励与奖励的方法会好过惩罚。不少人有时会产生一种错觉，凭借自己的技术强力把业务方怼回去并暗自高兴，然而我的想法确是和业务方友好相处甚至做朋友，安全的出现是为了业务变得更加安全更好，而不是阻止业务前进的步伐，当高危漏洞降级至没法再降比如低危时，可以注明情况并通过安全测试。不过需要补充的是，礼让、文明合作是有尺度的，基本的原则不能丢，某些情况下不能轻易妥协。

3）主动出击引导业务进入安全节奏

一般的甲方可能只有一个或几个人懂安全，无论是开发大神还是运维大神都不会太懂，所以信息安全组的成员更应该主动的去找相关人员沟通，交流遇到的安全问题以及结合实际业务场景提出合理的安全建议，将安全早点带入到各个业务场景中。在日常的工作中，效率值的排名一般是：直接找人当面沟通 > 电话沟通 > 即时通讯工具沟通 > 邮件沟通，当然也可以几种相结合，主动想办法提升工作效率。

*************** 未完待续 ***************

在【企业安全】系列文章中，最怕出错的其实就是本篇章。因为涉及到安全组织架构、安全架构规划等具有相当高度的内容，很可能会因为视野狭窄与经验不够丰富等因素给大家带来误解，如有错误之处请留言指正。