遭受刷验证码攻击后的企安建设规划感想 – 作者:i春秋学院-安全小百科

i春秋作家：78778443

背景

公司上市不到两周，便遭受到了黑客攻击，其中笔者团队的验证码比较容易识别，攻击者通过ORC识别刷了10几万的短信，除了造成一笔资金开销外，也给服务器带来了很大的压力；

并且在阿里云的控制台当中每天都能看到很多攻击信息，却没有拦截，原因是没有购买WAF防火墙，售后也频繁催促购买其安全设施；所以技术负责人也开始重视起安全问题来，笔者因为懂一些安全技术，所以老大希望笔者在这方面做一些规划指导，周末花了点时间根据公司的现状做了一下规划设想，下文便是当时的口述汇报，后来整理成了文字版，给读者做一些参考吧。

网络安全威胁”>一、网络安全威胁

提到安全可能直觉上会想到安全漏洞，代码安全等问题，不过安全一般比直觉上的范围更广泛，主要有来自于六个方面：网络安全、主机安全、应用安全、数据安全、运维安全、法律风险等。

1.1 网络层

拒绝服务攻击，分布式拒绝服务攻击（DDoS），是最暴力、血腥、有效的攻击方式，可直接导致企业云上业务系统带宽堵塞。
DDOS攻击防御有两个核心点，首先是识别谁是恶意攻击，另外就是要有足够的带宽和服务器性能来处理这些请求，DDOS攻击是在太野蛮，应对的方法也比较被动，可以使用云平台的防DDOS产品，但也会有误伤，所以遇到这种攻击也只能使用这种无奈的处理来应对。

1.2 主机层

云主机入侵攻击，云主机是企业云上业务系统的重要承载，攻击者通过暴力破解或配置漏洞等缺陷入侵云主机，用以构建僵尸网络、窃取数据及敲诈勒索等。

主机层的风险通常是一些通用漏洞的风险，比如2016年心脏滴血事件全球的服务器都会受到此影响，因此到相对好处理，我们可以使用阿里云的安骑士产品，一键修复系统中的安全漏洞。

1.3 应用层

Web应用漏洞攻击，企业云上业务系统对外提供服务的诸多系统采用HTTP/S应用协议（Web），攻击者利用Web服务可能存在的诸多漏洞进行攻击，窃取业务系统数据或权限等。

应用层变更最为频繁，每家的应用特点都有一些差异，所以通常应用层受攻击的可能性最大，要防御此风险需要持续不断的进行跟进，比如对开发的安全意识，安全开发进行培训，对项目上线前的测试增加安全测试部分。

1.4 数据层

数据窃取或篡改云上业务系统数据在传输过程中经过互联网，可能被中途窃取或篡改，造成数据完整性和机密性受到影响。数据层相对范围比较广，比如代码是否泄漏，是否有数据泄漏，以及页面挂马，网站的留言的黄赌毒关键词筛选等，因为这些数据泄漏的途径会随着应用层的变化而变化，因此数据层也同样需要持续跟进。

1.5 运维层

运维人员违规风险操作企业云上业务系统需要内部人员进行运维操作，如何防范高风险的运维操作至关重要。
不过运维层的操作风险倒也是各个厂家的一些通用风险，因此解决方案也相对较多，比如使用堡垒机在可视化界面上分配权限，这个权限可以让一个账户指定开启多长时间，并且还可以全程监控，以及操作记录回查，因此风险不大。

1.6 合规层

国家等级保护2017年6月，国家网络安全法开始实施，企业安全建设不仅仅是内部驱动，同时也有法律驱动。
包括实名制，以及日至留存，制定相应的企业安全防护策略等。

二、安全制度

大多数人可能想到安全是从安全技术上来解决，实际上安全问题不仅仅靠的是技术层面，更多的是从制度上去解决的；

2.1 安全工程化

这里提一下SDL，SDL是英文字母的缩写，中文名称是安全开发生命周期，他是一套安全的生成流程。最开始来自于微软，在微软2004年以前windows系统和office中存在大量安全漏洞，为了解决这些问题提出了SDL，当使用了SDL之后office、windows的安全漏洞大量降低，后来被各个厂商推广。
SDL从安全培训-》需求分析-》设计-》实施-》安全验证-》发布-》响应这7个方面入手，每一个环节有相应的安全标准，不过微软标准版的SDL推广并不是很顺利，原因很多，但标准版SDL比较繁重是一个重要的因素，因此各家都有自己的一套SDL标准，在这方面我们也可以进行一些借鉴，制定一套自己的SDL标准，这个标准的制定一定要符合可执行可落地来为依据，可以参考我下面的落地实施部分。

2.2 对外沟通

2016年前以前，白帽子发现漏洞在乌云网报告，乌云网通知到各个公司，2016年7月之后乌云网关闭，一批白帽子被抓，导致白帽子发现漏洞不敢报告；不过后来各家开始组建自己的漏洞报告平台，2017年6月安全法出来之后，大部分公司要合规，因此大一些的公司通常都有自己的安全团队，比如教育行业好未来的应急响应中心；现在大家发现漏洞通常会报告给对应的平台的SRC；

比如教育行业的好未来SRC：http://src.100tal.com/

瓜子二手车的SRC：https://security.guazi.com/

以及更多的SRC平台，如下图

2.3 安全落地

上面提到了安全工程化，不过SDL的标准对于我们现阶段太过于理想，所以需要针对实际情况制定一些可落地的方案

安全编程规范

将一些可能带来安全风险的操作写入规范当中去，比如参数的输入输出，服务器的安全配置，以及代码的安全发布流程等。

安全培训

很多时候开发者并不重视安全，又或许对安全缺乏了解，比如系统中有哪些安全漏洞，漏洞的危害和原理是什么样的，怎么去防止这些漏洞等等，大部分开发者的安全意识还是很弱，和互联网技术不重视安全也有关系，可能一些开发者知道一些SQL注入、XSS，但是一深入去问一下，就不知所以然，而开发者对安全起了至关重要的作用，所以很有必要对开发者进行安全意识和安全基础技术的培训，这样才能从源头解决安全问题。

代码审计

这个不管是对于安全的角度还是对于减少BUG的角度都是很有必要的一个环节，对每个项目设定一个代码审计人员，可以对此这些审计人员组织一次代码审计指导；

安全测试

目前我们项目上线做了充足的功能测试，但是安全测试相对偏少，或者说并不全面，可以专门针对测试的人进行一些安全工具的测试的指导。