云原生安全与DevOps保障
上QQ阅读APP看本书,新人免费读10天
设备和账号都新为新人

前言

在陈旧的政府办公大楼地下室里,我正在收拾置物架上的废弃硬件,一对看起来还算结实的硬盘吸引了我的注意力。我的第一份工作,是在一家法国税务机构做服务台技术员,那是2002年,我19岁。老板在安排我打扫地下室时还有些过意不去,她以为我不会喜欢这份差事,但我却像是打开了四十大盗藏宝洞的阿里巴巴。这么多闲置的旧服务器,仍然足以运行一些不知名的UNIX系统,拿来玩玩儿更不在话下。要不是我的公寓只有一间卧室和一个小厨房,我会把所有的东西都搬回家,组装成一个巨大的网络!

这两块硬盘是15000转/分的SCSI硬盘,原本属于一台老旧的域控制器。我把硬盘放在一边,继续寻找可以插入它们的SCSI卡。我在旁边的一个盒子里找到了一块,它满是灰尘但是完好无损。我用几个小时完成了对废弃硬件的清理和盘点,并获准将硬盘和SCSI卡带回家。我的计划很简单:把它们插到我的一块备用主板上,搭建互联网上最快的反恐精英(一款第一人称射击游戏)服务器。然后我要用新安装的512Kb/s的DSL线路把这台服务器连上互联网,邀请游戏玩家们到这里切磋。

整整一个周末,我都在想办法让这两块硬盘和SCSI卡能正常工作,让它们可以被Debian安装程序识别出来。我在几十个论坛和邮件列表里搜索了好几个小时,寻找关于这个特殊硬件的帮助和技巧,但找到的大部分内容都是和其他型号SCSI卡相关的结果,还有一些我完全搞不懂的神秘内核咒语。周末很快过去了,接着一周也很快过去了,终于,我成功地试出了正确的参数组合,Linux安装程序在RAID 1上启动了。我想也许是我的问题,但是硬件真的很难搞!

成功的喜悦转瞬即逝,这些老旧的15000转/分硬盘嘎吱嘎吱地狂响,我坐在几米开外,几个小时后就被吵得快要抓狂。当然,我的游戏服务器运行正常而且速度还算可以,但我还是不情愿地关掉了它,把小公寓改造成数据中心的计划彻底泡汤了。

我是在千禧年前后学习的IT,那时IT领域里的重点是硬件和网络。和我的同事及导师一样,我每周都要花几个小时去了解最新的服务器、最新的CPU和最好的硬盘。我们必须了解这一切,才能搭配出完美的系统来运行我们的应用。硬件的采购周期很长,而且价格昂贵,尤其是我所在的政府机构,选错了硬件意味着在接下来三年都要为无法更换的服务器买单。

把这个问题放在现如今的环境下想想。三年!大多数创业公司都生存不了这么长时间。任何JavaScript Web框架也火不了这么久。很多人在一家公司也待不了这么长时间。在IT世界里,三年可以算永生了。

那个时候(现在,我的口气好像爷爷辈的人)不可能在一年甚至两年内就把网络服务推向市场。没有云和服务提供商,就没办法托管服务器,甚至没办法运行远程访问的在线服务。我们的互联网连接速度也很慢,不适合在本地桌面和在线服务上传输大量数据。政府机构拥有的上行链路“高达” 128Kb/s,却还要和150个人共享!设置服务器的过程又慢又痛苦,常常要花好几个小时和硬件驱动程序斗智斗勇,还要花好几天的时间进行复杂的布线和安装。每个组织里都有一整个部门来处理这些工作,程序员知道需要尽早申请服务器,不然项目就会因此延迟数月之久。

IT对硬件和网络的重视也意味着安全团队必须同样重视硬件和网络。那时人们鲜有对应用安全性的讨论;相反,人们集中火力过滤网络流量和对服务器的访问(包括物理的和虚拟的)。我们在学校里学习的是防火墙、跨VLAN的独立系统和基于网络的入侵检测。我们没有在Web应用的安全性上投入太多,因为我们想象不到,在接下来的几年里,世界上大多数人将不再使用Outlook这种安装在本地的软件,转而使用Gmail这样的SaaS服务。这种转变的萌芽始于2005年前后,并在几年之后愈演愈烈。

在DevOps成为主流,并且持续集成、持续部署和基础设施即服务这些概念得到普及之后,那些被拖沓的硬件管理工作折磨得没了脾气的人们开始反抗,他们看到了几天内就能把基础设施部署好的希望,而再也用不着等上好几个月了。然而,大多数安全人员却表示反对,他们担心基础设施一旦失控,最终将会危及安全。

一开始,我也是这些反对的人当中的一员。所有来之不易的技能让我养成了从硬件控制角度来考虑安全性的习惯:如果连系统都不是自己运行的,那么哪来安全可言。然而,当我看到我在开发部门的朋友部署应用时只需几条命令,而我的老办法仍然需要好几个小时时,我的观点一点一点地发生了转变。显然,他们找对了方向。于是我找了一份运维工程师的工作,将一个庞大的Java应用迁移到AWS上。这是一段痛苦的旅程。我没用过Puppet或Chef这样的配置工具,而且那时AWS肯定也没有现在这么成熟。我编写了定制的Perl脚本来自动配置服务器,还学会了使用API来动态创建虚拟机。我的老板喜欢只用几条命令就让应用在新服务器上崩溃,然后再重新部署,但整个过程相当笨拙,容易出错,而且很不稳定。尽管如此,这仍然是一个不错的开始,它让我渐渐相信,安全性高度依赖于基础设施的灵活性:如果系统可以快速运行起来,问题就可以更快得到解决,安全性自然也会更好。

当我加入Mozilla云服务团队之后,经验丰富的团队对先进DevOps技术的娴熟运用让我大开眼界。我看到一个服务自动扩充一倍服务器来应对提升的流量,然后在几个小时后当负载降低时,这些额外的服务器又被销毁,这让内心痴迷于技术的我感受到了美好。对部署自动化的重视让新项目在初始设置后的一两天内就可以完成集成。小规模的组织也可以利用这种灵活性快速成长,打出名声,并最终成长为技术巨头。在过去,配置好基本的Linux服务器,让它用上两块硬盘的RAID 1并连上像模像样的互联网就要花上几周的时间,我们现在取得的巨大进步让人惊讶不已。

我坚信安全必须为业务服务。当业务需要现代化时,安全也要顺势而为进行变革,不要沦落为业务的阻碍,这就是DevOps运动的重演。我编写本书的目的是帮助那些有抱负、有经验的安全工程师,他们要在保障数据和客户安全的同时支持组织采用现代化实践。我把自己以往那些在对安全性要求很高的Web服务中集成的安全经验,与整个安全社区多年来不断完善的实践和技术相结合,总结成书。这一切并不是一成不变的,而且在本书出版之后,DevOps技术的发展之路还相当的漫长,但只要我们还要继续运行在线服务,本书总结的理念便依然适用。