互联网企业安全运维实践(2)

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

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

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

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

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

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

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

二、安全运维之术

这一部分主要介绍一下，安全运维需要考虑的一些点。

这里讲两个重要概念。Due care中文通常翻译成适度关注或应用的注意，Due diligence翻译成适度勤勉或是尽职调查;

在信息安全领域，Due care实际上是说一个企业要制定各种各样的策略、规程和标准等，用来对企业信息资产的保护，也就是企业应该做的事情。而Due diligence则是要保证Due care要做的那些事情一直保持在最新状态。

举个例子说明。你要外出时，做了两个动作：

1、想着手机会不会电不够用呢，不够用怎么办;

2、随手把充电宝装口袋了。

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

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

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

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

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

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

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

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

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

关于漏洞

（编辑：ASP站长网）