互联网企业安全运维实践

雷英

安全领域众多，分享这个议题是因为在之前的工作过程中发现大家非常关心的机密数据泄露、资产盗窃、数据篡改、服务中断及物理逻辑的破坏行为通常都发生在安全运维环节，需要通过安全运维确保整个系统在一定的安全级别中运行。

安全建设思考

当企业开始着手考虑安全建设时，要考虑的因素有很多，其中包括管理层的期望、业务部门的安全诉求、组织环境和企业治理模式等。综合了解这些信息后，需要评估这时安全所处的阶段，可能还会做同行差距分析，然后才着手做安全规划，一般来说建设信息安全有4个阶段。

第1个阶段通常是“救火”。优先解决业务痛点，同时做一些基础的“保命”工作，来降低安全事件发生的概率，快速找到可能导致内外网安全入侵的安全隐患并修复，比如无线安全、VPN远程访问、弱口令和服务器后门等。此时也是最困难的，要人没有、钱也很有限，更关键的是买设备也来不及，只能根据以住渗透经验转换成防御方法，按照2/8法则做最有效的工作。另一个方面快速组织团队，因为你的安全项目计划里已经有很多活要等着干。

第2个阶段是体系化建设阶段。过了救火期，可以稍微喘口气，进行有序的安全建设。主要精力是在基础安全建设，比如安全老三样：堡垒机、双因素和VPN等。这个阶段还不能用互联网，因为团队里基本上不具备开发能力，主要是以商业安全设备为主，外加少量的安全工具自研，提升运维的效率。这个阶段也可以参考ISO27001体系出台三、四级的管理规范，并推动落地，确保从源头解决问题，否则永远处在擦地板的过程，因为水桶有洞，水不断滴出来，擦一次是干净了，过一会儿又流出来了。

第3个阶段属于安全的高阶阶段。商用系统可能并不能很好地满足需求，所以需要大量自研工具来解决实际问题，有能力的话可以考虑加入安全大数据和APT。

第4个阶段进入安全的智能级别。智能的检测、阻断和响应代表公司安全未来的方向。

架構一词，起源于古罗马时代，是描述如何构建一个建筑物以及它的实用和非实用功能绘画的过程和相关的艺术科学，这个词同样在IT领域广泛使用。

软件架构尤其在运行环境中会比较抽象，以往做安全系统的架构，由于对系统缺乏全面了解，通常都是拿一张平面的网络拓扑图。其实架构是分不同的层次和视图的，根据业务的差别、功能的不同和关注人员的差别，需要不同视角的视图。

系统安全的架构应该包含哪些东西？个人认为它至少应该包含3个主要的维度：第1个就是系统自然的技术堆栈，在IT技术里，任何系统的技术堆栈都是天然存在的。最常见的系统分层架构，有客户端或者浏览器、APP；下面有运行的代码，它可能运行在中间件服务器上；再下面可能是数据库、操作系统、服务器、网络和基础设施，这是一个最简单的分层方式。

第2个维度是业务流程视角，其实和安全这个课题是没有太大关系，它更多的是关注业务功能的实现。比如说支付业务有支持业务的流程，网购有网购业务的流程，理财业务有理财的流程，它随系统差别来实现不同的业务目标。

第3个维度是安全视图，比如客户端、应用、中间件和DB都有不同的保护机制。在另外一个维度就是业务流程，业务的每个模块也需要不同的保护机制，这些保护机制最后贯穿成一个网状的结构，如何选择合适的保护机制对它进行保护，那就需要第3个轴安全技术来构成三维视角，在安全的机制里它分为2类：第一类是系统自身的防护；第2类是对业务系统的保护。

为了便于理解，我们把这个框架对应到建筑架构上，第1层是地基，代表基础设施；第2层是网络；第3层是服务器；第4层是中间件及应用。再往上就是应用、客户端，系统堆栈的概念比较好理解。

业务系统视图对应的横轴，比如可能有101，102，103等多个房间，业务流程把它想象在101房间先办理注册，102房间去选1个东西，103加到购物车，104可能是支付，105完成退出。

接下来看第3个轴，系统自身的保护。构建一个房子，自身要坚固，柱子要牢靠、墙体要结实，这样这个建筑才能稳定。除了本身安全，还要考虑在里面住的客人，要为他们提供安全保护，走廊、消防和空调的排布是不是合理的，能否有效保护内部用户的安全。这就能看出系统安全架构的基本维度，而对于保护机制的选择有一个逐步评估分解的过程。这里还需要大家注意每一个IT系统，不管是系统开发还是安全开发，都有生命周期的概念，而生命周期对安全架构的设计是有影响的。

今天我们能感觉到网络攻击已经在进化，比如基于国家、政治团体以及有组织的犯罪机构发起的攻击越来越多，攻击者更有耐心，可能会从不起眼的用户入手。还有一个变化是一些高级的攻击逃逸技术越来越先进。还有一些攻击是针对个人的，针对人的弱点进行社会工程学的攻击，非常难防范，会突破我们原来认为不会被攻破的防御系统，把一些恶意的程序注入到你的系统里。

但是我们仍然可以继续遵循基本的计算机安全实践，来构建安全体系。按照合规的方法去做，这一点非常重要。我们都知道在禁止酒驾立法之前，发生非常多酒驾引起的人员伤亡的事故，但是立法之后很少有人去触碰法律的红线。信息安全也一样，如果真正做到监管合规的要求，你的安全等级已经到达一个比较高的维度了。

第3个身份管理，这个人是谁，在我的系统里面有什么样的权限，授予他可以访问哪些数据。

第4个是数据保护，数据保护目前仍是很多企业最关心和最担心的问题，因为全球90 %的企业都认为自己可能有数据泄漏方面的风险。

从整个2016年来看，全球总共爆发900多起非常严重的数据泄露事件，泄漏数据达到5亿多条，包括小米、京东和雅虎在2016年都发生过大规模的数据泄漏的事件。

另外一块是日志，记录和监控可以协助发现未经经授权的安全事件，有助于确定安全措施有意义的改进，以保护公司的机密信息。这里只是一个示例，我们在构建技术保障体系的时候，按分层原则，每个层次上都需要考虑相应的保护机制。

除了像BAT一样的先进公司，大多数企业在安全运维层面还是离不开找到合适的人、买到合适的设备这2条。这里谈谈买到合适的设备时的一些经验。

给大家讲个与老板偏好相关的真实案例。之前老板传达的信息是买设备，别买大了，省下的钱公司用于投资，会产生更多的收益。听上去没毛病，所以我们在选购数据中心边界防火墙时，按年30 %的复合增长计算，1套墙满足3年业务增长是没有问题的，到第4年插块板卡，就能扛5年。结果2年后，业务以每年超过100 %的速度增长，在这个过程中，新老板上任了，说容量怎么不够了，就把之前的设计翻出来，也说得通，那就买板卡扩容吧。没想到只过了6 ～7个月，容量又报警了，业务成长实在太快了，只好去找新老板说板卡已经扩到头了；只能换一套更强处理能力的设备，可以体会一下向老板做汇报的心情。

第2个案例是关于品牌的。在采购过程中，有个品牌为了进来，杀低价中标。都是国际一线品牌，按道理来说没什么问题，但是有点水土不服，各种奇怪问题全来了，在短时内就发生了7次严重故障，所以用了不到1年，果断换掉。这次之后，我们对品牌的考虑更加慎重，和采购死磕，提升技术评分的比例，确保不让不符合预期的产品进来。

关于中心端产品的容量，如果是互联网公司，建议按当前量放大5 ～10倍考虑，因为业务的增长往往是倍数成长，非常吓人，不能总是出现性能瓶颈；另外一方面需要考虑架构优化，用Scal Out方式横向扩容。

关于测试，这里指实际环境测试。实验室不全面，如果条件允许，时间、人充足，测试当然没有坏处。如果时间紧、人手不足的情况下，就选择性地进行测试，比如性能类产品首次选择使用时，最好先测试一下。

另外，这几者之间要互相平衡，它们之间都是有联系的。比如容量估算不準，又没做实际环境测试，等设备买来，一上线直接挂掉也是有可能的。

安全运维之术

这一部分主要介绍安全运维需要考虑的一些问题。

这里讲2个重要概念。Due care中文通常翻译成适度关注或应用的注意，Due diligence翻译成适度勤勉或是尽职调查；在信息安全领域，Due care实际上是说一个企业要制定各种各样的策略、规程和标准等，用来对企业信息资产的保护，也就是企业应该做的事情。而Due diligence则是要保证Due care要做的那些事情一直保持在最新状态。

举个例子，比如你要外出时做了2个动作：

1想着手机会不会电不够用，不够用怎么办；

2随手把充电宝装口袋里。

其中1是你的思想活动，有没有“想”就属于Due care，也可能会顺手查看手机电量。想过之后，可能会觉得电够用不带充电宝，也可能会觉得不够用而带上充电宝，这都不重要，重要的是你“想没想”，有没有检查手机电量的意识。

第2是你的实际动作。如果你觉得电不够用带了充电宝，但没检查充电宝是否有电，或忘了充电线，那就是没做到Due Diligence。也就是说虽然采取了相应的动作，但没达到预期的效果。

对于安全来说，需要想到如果没有采取这个措施，可能存在怎样的安全风险，为了降低风险，采取了一定的行动，并且要确保这个行动是有效的、而且一定要真实的执行。

IT系统会有各种各样的变更，如发布、升级、割接和改造等。变更是最容易引发系统故障的操作，为了降低变更对系统的影响，我们推进三思而行的3步工作法。做变更之前先问自己3个问题，首先我是这项工作的合适人选吗？其次我有能力执行这个任务吗？最后我能控制整个变更吗？

当3个问题得到的答案是肯定的，再去申请执行这个变更；如果任何问题的答案有迟疑，就要和自己的主管协商，制定最佳方案，包括变更失败的回退计划。通过这一举措大大降低了变更造成的业务影响。

研发的同事通常关注的是HTTP xxx返回值相关问题、延迟、扩展性、代码重用、Deadline、KPI、需求变更、框架、形式源、功能如何实现以及代码质量等问题，最主要关注代码有没有Bug；运维的同事通常关注HTTP 4xx及5xx错误、性能、可靠性、对阀值进行预警、监控图断崖和是否出现异常，也最关心别出故障。

研发和运维的同事对安全的理解会有不同，但大体上对安全的理解包括DDoS攻击、病毒木马、堡垒机、数据脱敏、拖库和数据泄露，只能理解和自己工作关系比较大的那个部分。而负责安全的同事则关注1～7层上的防护措施会不会被绕过，然后就是各种漏洞，开源框架的、编程语言的、代码里的和逻辑上存在的各种安全漏洞公交站，传输过程中以及存储过程中的漏洞、Bug的修复和更高级的漏洞利用方式。找出各种高、中、低危漏洞。除此之外还要时刻关注无线渗透、弱口令、0day、彩虹表、各种马、注入和后门。这里就不一一列举了，反正就是能黑进入系统、能拿数据以及能偷钱的技术都需要了解和防范。

其他非技术部门的同事对安全的关注仅仅是看看热点，谁家出什么事了，旁观者心态。视野的不同决定了在安全工作上采取行动的不同。

在安全运维的过程中，有时不得不去做一些高危操作，就像给飞行中的飞机更换故障发动机，因为站点业务是7×24服务的，不可能或很少能遇到停机操作窗口。前面已经说过，做变更有一套方法规避风险，包括参与变更人员、厂商和我们工作时的配合。但总有疏漏的时候，有一次我们更换防火墙引擎故障，结果导致防火墙双活，业务中断约10分钟。后来复盘故障时领导也觉得这类操作的确很危险，即使再小心，也是十分危险的。所以就设定了Outage Window操作，高危操作放在这个窗口内，订单损失是不计入ATP监控的，并没有人会因此滥用这个窗口。

关于漏洞

漏洞年年有，今年特别多，像前段时间出的Struts2；还有2019年4月15日国外黑客组织Shadow Brokers泄露出了一份机密文档，其中包含了多个Windows远程漏洞利用工具，可以覆盖全球70 %的Windows服务器，影响程度非常巨大。这2次事件影响面都非常广，修复花很大力气，在企业里面推动补丁管理还是挺难的。简单来说就是补洞的人不懂安全，懂安全的插不上手。需要说的是补丁是必须要打的，不然就给入侵者留下方便之门，不做为，亦作恶。

关于安全意识

需要足够的耐心，一次次去宣讲，普通员工到技术人员到管理层，大家整体的安全意识才会提高，特别是管理层，宣讲的时候讲技术通常效果不好。这时应该选择讲案例，将安全与商业价值联系起来管理层才会真正重视。安全工作成功的关键是高层、重视和承诺。

关于变化

这个也好理解，整个IT环境是不断动态变化的，当前有效的安全防护措施，因为某个不安全系统的上线，就有了突破口，需要持续检查，发现变化带来的新风险。

关于坚持

其实安全运维是整个安全的基石，需要耐心去踏踏实实做一些事情，而很多我们身边的“大牛”在最初入行时也是从调设备写代码开始的，通过真正接触一线的工作，在后期的提升会比较快，而不是说看几本安全的书就能怎样。

安全运维自动化

我们为了提升安全运维效率，在运维自动化方面有过很多尝试，比如防御DDoS攻击方面，分布式漏洞扫描方面、交换机封IP、基于VPN的链路容灾方案，防火运维自动化方面等，在DevOps深入推进的今天，可以说能够自动化你想自动化的一切。

关于DDoS攻击分为2种类型，一种是已经被打怕的人，另外一种是已经被打习惯的人。DDoS攻击目前仍是网络安全的头号大敌，超过100 G规模的攻击很常见。笔者是被打习惯的一类人，在战斗中增加经验值，并且考虑了一些自动化的防御手段，比如自研DDoS攻击看板、实时了解受攻击情况、与运营商BGP联动、实现被攻击IP一键丢黑洞及快速释放被攻击带宽。另外云端防护是必须要借助的，因为现在的攻击量太大了，需要云清洗能力。

我们自研的DDoS攻击看板分成3个状态，第一块是谁正在被攻击，第二块是哪些被攻击系统正在引流，第三块显示哪些被引流的系统正在做流量清洗。正在做流量清洗的系统，需要特别关注业务的运行情况，确保业务得到保护。

讲一下交换器封IP，由于我们系统架构的特殊性，需要由交换机设备完成IP自动封锁的任务。先看一下流程，比较简单，分为4个过程：发现恶意IP，可以通过IPS或其他系统检测出来；送入IP封锁系统进行规则匹配；符合封锁条件的IP直接自动下发到交换机进行封锁；达到封锁时间则自动解封。

再看一下实现原理。最上面通过API对接Web Portal和恶意IP识别系统，Web可以实现IP的增删查以及交换机ACL查询，有IP白名单机制，确保受保护IP不会被封锁。比如分公司IP或合作伙伴IP地址，ACL下推到交换机时增加了防呆机制，防止系统发生将不该封的IP封锁或是大批量封锁用户IP的情况发生。

这个是一个基于VPN的链路容灾系统设计，我们做的自动化有几块。一个是全国有几百家汽车站需要与总部系统通讯，如果采购商用VPN系统造价很高，那我们在某宝上买了Netgear的路由器，安装Openwrt开源固件提供VPN服务，大约节省80多万元成本。这个设计的专利部分是设计了一套全冗余的结构，冗余的程度达到就算任何一个机房的链路坏了、设备坏了甚至其中1个IDC全部crash，这套系统仍然可以持续运行。

维护和管理几百条VPN隧道是非常麻烦的事情，我们开发了VPN管理工具，可以批量生成中心端VPN的配置信息，远端的VPN小盒子也通过脚本实现即插即用，大大降低了维护的复杂度。

随着互联网技术的不断发展，在线网站的规模越来越大，防火墙作为网络的安全屏障在广泛使用，其数量也在不断增加。据了解，使用几台到几十台的企业有很多，也有一些大型集团公司或跨国公司使用数百台防火墙。面对这么多防火墙，要把它管理好，难度是很大的。有些厂商说你可以使用我们的防火墙集中管理系统，帮助降低运维复杂度。但当告诉他，我们有好几个品牌的墙，他们往往会说对不起，其他的系统管不了，只能管自家的墙。有商用产品可以实现不同品牌防火墙策略集中管理，但是按License算钱，价格昂贵，而且不灵活，不能实现个性化的需求。在这种多品牌，多数量的情况下，防火墙系统的运维难度和挑战将变得非常大。

我们自主开发了防火墙运维管理系统，通过计算路由，生成防火墙拓扑，判断出一个策略需求，经过哪几台防火墙。策略查询2个功能，一是用户自助查询2点间的防火墙策略；二是申请策略时后台会自动判断是否已有策略支持，如果有的话，会返回消息告诉用户说已经有策略了，无须申请。

策略生成模块，抽象策略对象，判断策略申请是增、删、改哪种场景生成相应的工艺。工单对接是指如何与企业中的变更管理、工单管理系统对接。自动化不能逾越流程，反而要严格遵循流程，在工单对接环节会重点强调。其他工具，VPN管理、改密码、审批关系维护和墙元素查询，都非常有价值，极大提升运维工作效率。

最后简单谈一些感想。第1，做安全运维也要理解业务，理解业务才能针对不同业务实施不一样的保护级别，如果全部采用相同保护级别的话，安全成本会非常高。

第2，要有充分的预案，因为我们不知道接下来会发生什么，我们通常认为防火墙HA部署的可靠性已经很高了，但是极端情况下会出现2台防火墙同时坏掉的悲剧，就需要有应急预案处理这样的极端情况。

第3，定期演练。即使有了预案，还需要定期演练，不然真出现问题，对方案不熟悉或是预案针对的环境已经发生变化，预案早已不再有效却没有及时发现。

第4，善用乙方的资源，在系统的专业性方面，乙方的工程师可能比较强，但对于业务本身，当然是甲方工程师更清楚，要利用相应的优势，为业务提供保护。

第5，创新思维，就是用创新的想法去解决实际问题，并且成为一种能力。

第六，全面安全视角，安全运维不仅是对各种安全设备和软件进行运维保障系統安全，还要兼顾运维安全，解决研发、运维同时产生的各种危险点，基本上涵盖了整个系统安全的方方面面。所以需要有全面的安全视角，才能应对不断产生的安全风险和挑战。