文章 - 企业安全体系建设之路之产品安全篇

本文纯属个人经验和见解，如有语言不妥之处，还望批评指出。

概述:

首先呢，笔者不是做市场营销的，不是产品经理更不是程序员，笔者只是一个搞信息安全的，所以涉及到产品运营的东西就不讲了，只能从攻防安全的角度去阐述产品的安全建设。此篇文章的描述可能只适用于互联网相关的产品。

产品安全

一个公司产品安全性的高低，决定了用户使用安全感的归属。

如果产品三天两头爆出漏洞，造成用户信息泄漏，敢问还会有用户会用吗？如果有替代的产品，用户一定会弃之而后快。

一个好的互联网产品，特别是和用户信息隐私或者钱挂钩的产品，安全问题绝对是不能忽视的。

产品安全不仅和用户相关，更是掌握了企业的生死存亡。好的产品应该是易于维护的，出了安全问题能够快速定位漏洞点，更改或新增功能时，也能够像编写插件一样容易，对于安全问题来讲，能够让测试很清晰明了。产品安全点线面共存，自成一套完善的安全体系，共同协作以达到产品的高机动性，这样不仅是对用户负责，更是对企业自身的发展负责。

产品安全开发手册

一个产品开发出来，其成品经过肯定是代码拼出来的，所以产品安全的源头在开发这里。

产品在开发之初从需求到一个想法到设计到成品的过程，不能说程序员参与了全部过程，但至少代码部分是程序员参与的，一个产品的开发，特别是那种大型的产品，开发不止一个人，一般来讲是一个开发团队，其中各个程序员的技术水平和对代码安全认知不同，不可能每一个程序员都是安全开发出身的，这样就造成了产品中有些地方安全性很高，有些地方安全性很差。所以，如何规范程序员的编写代码，是开发团队需要思考的问题。

漏洞的产生是人为和编程语言的特性共同决定的，我们不去考究开发语言自身的漏洞或者后门等其他外部环境因数，单单从程序员自身编写代码说起。正所谓无规矩不成方圆，这句话到今天放到哪里都还是那么的合适，制定一个规范的安全开发手册很重要，这样可以让不懂安全的程序员知道漏洞容易发生在什么地方，在代码层上应该怎么样来进行规避。光靠安全开发手册还不行，还得对程序员进行安全培训，我们不能过于相信程序员能够完全的遵照安全开发手册进行书写。

产品安全开发库

为了和安全开发手册相互适应，企业还应该有属于自家公司的安全开发库，什么是安全开发库呢？所谓的安全开发库就是能从代码层上规避漏洞风险，比如说SQL注入漏洞，我们都知道SQL注入漏洞发生在与数据库交互过程中，所以，我们就会在SQL语句进入数据库之前进行非法字符的过滤操作，当然XSS漏洞也差不多，所以呢，要规避此类问题，就是加一个全局的过滤代码，但是呢，这样也不是十分完美，所以我们就需要开发一套安全库，专门来处理SQL，XSS这类常见的漏洞安全库，所有的语句执行直接带入到库中的函数。如：

Name = “test”;

User_info = DB.select(Name);

User_info变量返回的就是用户的信息，DB这个类库就是专门处理select这类数据库操作的，如果有特殊字符引入的话，DB这个类库就会进行过滤绑定操作，从而对常规漏洞进行规避。如JAVA中的Hibernate库，这个库里面就封装有对SQL语句的执行操作，但是对SQL语句的处理还是不够完善，处理后SQL语句后产生的漏洞利用难度已经很大了。

这样，就会是不懂如何过滤的程序员也能写出安全的程序出来。

产品安全制度

一套完善的安全产品制度也是很重要的，其中包括了产品从诞生到上线再到下线等一系列过程，其中的安全把控也是需要很多的人力和资源的。

产品从上线之日起，安全问题就已经提上日程，一套完善的产品安全制度可以说是一道指引方向的明灯，以不至于让维护这套产品的工作人员无从下手或者胡乱下手。

对于产品的安全制度应该制定通用的，不对就改，而不是很多套方案，没有必要，也没有意义。制度应从产品开始研发直到下线的这么一个过程制定，有始有终的保障。

笔者以自身经验，简单的说几点，产品开始构思制定并研发这些就不谈了，我们直接到测试环节。

产品安全测试

产品安全测试作为产品上线前的安全测试，其发现的问题整改起来比上线后整改起来容易的多，按道理来说，内测环节发现的问题一般会很多，内测完后整个产品的安全性肯定会上升一个档次。

测试应该合理的安排测试和整改额人员，以免浪费或者占用资源。

产品预上线

为什么需要预上线呢？那是因为网络环境的复杂性，当有了用户后，我们还得保证服务器的稳定性，如CC压力测试等其他非常规测试。我们在预上线发现的问题可以保留到产品正式运营以作数据参考。

产品的预上线和所谓的内部试运营差不多，预上线要的效果就是服务器的运行和上线后的运行是否能够达到产品设定的标准，其中包括产品的性能等等。

产品上线

产品在上线后，还需要对产品进行一次安全测试评估，安全评估如不达标应立即下线整改，整改完后上线。其实按照评估标准来讲，评估是应该放在预上线这个环节的，个人觉得，在实际的真实环境评估的效果可能会更好一点。

评估中的资产清单应纳入到安全管控范围内，这样可以更好的发现产品运营中产生的问题，对应急很有帮助。

其实来讲，企业的所有资产都应该在内部有一个报备清单，其上下线设备产品都应有一个申请，这个不应该是个麻烦，这个对整个企业的安全建设制度化有非常大的帮助，这个可以让运维或者安全人员知道哪些设备上线，哪些设备下线，及时检查相关流程是否符合规范，是否存在安全隐患等等。

资产应有统一管理，其中包括端口问题，所有资产设备的IP端口都应有详细的资产说明表，要开哪个IP，哪个端口，关闭哪个IP或端口都需要申请，这个是安全人员做渗透测试或者安全漏洞扫描必须的。

在运营期间，应该定期有复评估,当然，复评估发现问题后也应该暂下线进行整改。

产品运营

所谓运营，说白了也就是产品运行的管理者，运营的安全也是产品安全体系建设里重要的一环。当前的运营也不仅仅是产品的维护者，在这几年的安全形式下，运营逐步变成了一个团队，不再是以前的一个人或者两个人来做，现在的运营更多的是运维和安全管理的结合体（当然还有其他的人员，这里主要讲和安全相关的人员，我们就不讨论了）。其中结合了漏洞扫描、基础运维、防火墙、流量分析监控等等，分工细致，各司其职保证运营过程中的每个环节。定期展开应急演练来考验企业的应急能力和团队协作能力。当然这个是大企业做的，大企业有资源分工比较细。但对于小企业来讲，因为成本和资源问题，人还是只有那么多，需要控制成本，所以安全运营者的能力和压力是很大的，那么小企业就只能是买一些安全服务或者安全产品来进行协作，能力强一点的安全人员可以考虑开源的安全产品来部署企业，不能说防护能力提高多少，但是总归是有效果的。

安全运营重点在于监控，也就是所谓的“一杯茶，一包烟，一个破站盯一天”，监控网络的有许多产品，开源的、收费的比比皆是，怎么选就要看产品的具体需求了，这个是没有一个统一的标准。

产品预下线

产品到了需要下线的时候，需要做一个下线退网评估，企业应该循循渐进的开始清理服务和资源，逐步的减小服务范围直到达到一个最低临界点，待产品资源清理和转移的差不多时，开始走下线流程。

产品下线

产品在完成其使命或者再没有利用价值时，就应该断网下线。

在关闭相关域名或者IP和端口后，备份保存其数据，其服务器也应该进行格式化操作。然后资产清单报备除名留存备案。

产品安全建设总结

大体上产品的生命周期为：

产品安全建设也主要是围绕用户和功能开展，其他的如物理上的安全可以参考本系列文章的前两篇。产品开发出来肯定是供用户使用的，所以要考虑到用户信息和用户体验等等问题，这个就是产品经理该考虑的事情了。

产品的开发过程中得有属于企业自己的一套代码封装库和安全开发手册，建设这些不是说安全问题一定可以避免，但是至少代码会更加的规范，代码功能的更新会更加的容易;安全问题我们不能说没有，至少不会比没有代码约束的产品强。

产品测试环节每个企业的具体标准都不相同，但是测试流程都大同小异，所以其他公司一些比较好的测试规范能借鉴就借鉴，作为补充参考。测试环节也是最能够发现问题的。

一个产品上线必定附带一系列的其他属性，其中的资源调度问题就会凸显出来，所以一些企业安全建设者们为什么都说要规范流程化，规范流程化是很多安全建设的前辈们总结出来的，规范流程化不仅仅是适用于产品安全建设，其更适用于整个企业的安全体系建设。一套完善的安全建设体系必定是流程化的，如我们平时的渗透测试一样，先信息搜集再WEB漏洞再系统漏洞再怎么怎么样。一套完善的体系可以让我们的思路更加的清晰，知道该往那个地方走，而不是胡乱瞎摸方向。

对于产品来讲，在上线前需要做一次安全检查，也就是所谓的安全评估，产品的安全评估主要分为下面几项，当然，这个标准看每个企业自身。笔者就不细分了，列几个大点：

一：业务基本情况介绍

这个大项主要是描述这个产品的主要功能、技术实现、网络部署情况等。把产品部署的物理和网络等基础环境和产品功能信息给个详细的介绍说明。

二：基础安全检查

这项主要是对产品的部署进行渗透测试、压力测试、功能测试等测试项。

其包括系统漏洞扫描、安全基线、弱口令、数据库、中间件等的安全配置情况检查。其检查形成报告，提供给开发和运维人员进行整改，整改后进行相关问题的复核和新问题的发现。最后形成报告，留存以作备案参考。

三：配套安全管理措施

这项主要为系统运维方面，其中包括日志留存、安全管控、资源调度监控等边界检查。排查相关安全工作是否落实。

当然还有应急管理，每个系统或者产品上线前，都应该单独制定一个应急预案，为什么要单独呢？因为我们知道，每个系统或者产品的功能和资源流程架构是不同的，通用的应急预案要有，但是更应该细化到每个系统和产品身上。

四：安全评估结论意见

最后在完成了初评估和最终评估后，生成最终的安全评估报告。

在最后给相关运维和运营人员一定的建议，其中包括当前产品可能会发生的问题和运营中可能发生的安全问题等。

在完成了安全评估后产品上线，上线后最重要的就是运营。在运营中，随着用户人数和产品功能的更新完善，随之而来的就是安全问题的产生。之前的安全评估所修复的问题可能再一次的暴露在当前的产品环境当中，伴随老漏洞而来的可能是新漏洞的产生。所以保持渗透测试和漏洞扫描的常态化是非常有必要的。

如果当前产品存在漏洞被非法入侵，用户数据被脱，或者服务器被黑，权限被降。那么运营应该要考虑怎么样消除社会影响，怎么样把企业损失降到最低，怎么进行系统取证操作，快速定位入侵点。

当然了，如果有条件的企业，可以建立一个SRC平台，给一些奖励，白帽子发现的漏洞都可以提交到SRC，建立企业漏洞库，方便管理，参考并以此保证以后少出现此类问题。

在运营期间，每年至少进行一次全方位的系统复评估，以保证其系统的稳定性和安全性。

产品到了生命周期后期时，随着新产品的出现，用户数量开始下降，产品被合并或被代替，那么运营者可以考虑对产品进行下线处理。

在产品下线前要做一次产品预下线评估，这样做的好处是，企业全方位的排查了当前待下线的产品安全性，当前产品系统环境中是否存在APT攻击痕迹，逐步开始走系统下线流程。然后开始减少提供给系统的资源，企业应该循循渐进的开始清理服务和资源，逐步的减小服务范围直到达到一个最低临界点。