“活动页面一定要在七夕当天上线。”
“活动已经安排好，页面按照计划在制作，准时上线没问题。”
“业务系统更改需要经过我们安全部门测试才可以上线。”
“这个活动页面是有时效性的，七夕当天必须要上线，安全测试完，活动都结束了，先上线再说，不然，活动期间业绩完不成。”
“我们发出去的1千个优惠券，怎么一下子就被抢光了，而且，我们真正的用户都反应说没抢到。”
“又是羊毛党，页面有个漏洞可以批量刷优惠券，用户现在说我们耍猴，优惠券根本抢不到。”
“安全部门请解释一下。”
安全部门：“我太难了......”

上述情景在很多企业会遇到，企业都是以业绩为主，业务部门是赚钱的部门，安全部门是烧钱的。除了大型电商公司外，企业一般以业务部门的要求，优先考虑，安全工作要在不影响业务部门正常运转的情况下开展。如何在保证业务的同时做好安全，是企业安全建设需要考虑的重要环节。

一、制定安全工作方针

凡事预则立，不预则废，安全部门首先要做的，是制定一份安全工作方针，方针中除了整体安全建设外，还应包括业务部门和安全部门配合工作部分：
1）安全部门会拟定安全工作流程，包括安全测试、基线加固、补丁更新等，列举每项工作需要业务部门配合的部分、对业务运行可能造成的影响，流程与业务部门确定，达成一致，如：系统上线前、迭代更新前，需要预留充分的安全检测时间给安全部门。具体测试时长，收集业务部门、安全测试人员要求后由领导决定。
2）业务部门应该配置完善的灰度测试环境，保证灰度、真实环境一模一样。
3）业务系统升级迭代工作计划，需要安全部门派人参与，避免设计阶段带来安全隐患，如：尽量减少互联网暴露面，减少漏洞较多的中间件、框架的使用。
4）资产变更情况及时与安全部门同步，包括新资产下线，旧资产废弃等，保证安全部门日常检测的资产是全面的。

二、两者之间的平衡

用户交互性较高的系统，很难既做到安全又不影响用户体验，举个栗子：某网银系统没有验证码，安全部门判断存在暴力破解的风险，业务部门认为，每次都要输入验证码，会影响用户体验。这时候需要平衡业务与安全，做个取舍，安全部门需要列举不同场景下存在的风险，业务部门列举同场景下用户体验的影响，由老板做取舍。

同时，安全部门也需要从业务的角度出发，输出对业务系统影响最小又保证安全的方案，老板希望能解决问题的下属多过只知道抛出问题的下属。

类似的方案包括：
1） 前几次输入不需要验证码，输入次数过多，才需要输入验证码。
2） 业务逻辑漏洞容易被羊毛党利用，造成严重的经济损失，修复可以采用session机制等方式，跟进每个用户的状态。
3） 建立完善的风控系统，遏制羊毛党，不影响真正、优质用户使用系统。
4） 不易修复的漏洞，如果上线时间紧的话，先输出紧急抑制方案，如Struts2漏洞，先关闭相应的功能，临时修复。漏洞不能利用，业务不影响使用，后面再考虑升级框架。同时，网络中使用流量监控的方式，发现系统运行期间，互联网破坏行为。
5） 错误提示页面友好化，如：“您访问频率太快，请稍后访问。”等。

三、安全事件处理

***是个博弈的过程，没有一直胜利的将军，安全工作从来都是，平时看不到工作效果，出事了才知道安全的作用。安全事件也反应了前期安全工作中的疏漏，安全部门可以借助事件，推进之前没法推进的工作。如以下场景：
某单位业务系统，管理员经常映射高危端口到互联网，方便在家里远程办公，安全部门一直没法收集互联网开放的端口，以及弱口令控制。有一次单位中勒索病毒，大量服务器、数据库被加密。经查实是管理员映射3389端口到互联网，***破解口令进入服务器后，在内网大量散发勒索病毒。安全部门借此事件，向单位发布安全生产管理要求，互联网开放端口必须要经过安全部门审核，所有服务器统一使用堡垒机登录，杜绝弱口令行为等等。

安全与业务是对冤家，不打不相识，懂得技术，撩得业务，才是合格的甲方安全。

原文地址：https://blog.51cto.com/14464202/2434762