云时代安全体系跨时升级 面向未来的全流程实战详解

近年来，在软件开发领域，DevOps 和云原生已经是大势所趋。工程师只须将代码提交到仓库中，持续交付流水线就会自动地构建和测试代码，并快速地将结果呈现在用户面前。新特性的上线分分钟就能完成，我们看到海内外的互联网巨头们正不断刷新着每日部署的次数纪录。
与此同时，全球范围内不断发生的安全事件也引起了人们的警觉，尤其是愈发严重的用户隐私泄露问题，与之相关的丑闻也层出不穷。虽然，安全事件频发与极短的发布周期、相对开放的云基础设施之间并没有必然的联系。但是，DevOps 实践者一定不能忽视安全问题，并应该好好利用云原生和自动化流水线的优势，做到防患于未然。因此，本书的内容对实践者来说，一定不能错过。
作为安全工程师，你一定是最关注安全问题的人。云原生基础设施安全保障和传统基础设施安全保障有何不同？如何借助云原生基础设施的优势减轻烦琐的安全保障工作？如何让 DevOps 团队能更多地关注安全问题并进行提早预防？
作为 DevOps 团队中的一员，你一定会关注一些具体实践和工具。Web 应用安全扫描工具有哪些？持续交付流水线存在风险吗？安全性如何用自动化测试驱动？ 如何监控系统中的攻击？权限管理如何做？ HTTPS 的正确打开方式是什么？
作为管理者，你一定注重整个组织对安全事件的预防和应对。当安全事件发生时，组织如何有条不紊地快速应对？当安全危机解除后，组织如何进行事件回顾，
避免错误重演？如何对组织面临的安全风险进行评估？如何一步步提升整个组织的安全意识，并做到持续安全？
读者可以在本书中找到上述问题的答案。难能可贵的是，作者将这些思想、实践和工具通过一个假想的 Web 应用示例串联在了一起，读者在阅读的同时不妨动手尝试一下。本书篇幅有限，不可能将所有的云基础设施和全部的安全实践收录其中， 读者可以举一反三。但其背后安全内建的思想却是放之四海而皆准的。
感谢家人的支持鼓励，感谢博文视点编辑们的辛苦付出，他们的付出使得本书的翻译圆满完成。十分荣幸能够有此机会将这本新意十足、干货满满的图书介绍给国内的读者。希望读者和我一样能有所收获。
——覃宇 2020 年 3 月于成都

前 言
在陈旧的政府办公大楼地下室里，我正在收拾置物架上的废弃硬件，一对看起来还算结实的硬盘吸引了我的注意力。我的第一份工作，是在一家法国税务机构做 服务台技术员，那是 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 技术的发展之路还相当的漫长， 但只要我们还要继续运行在线服务，本书总结的理念便依然适用。

关于本书
本书是为 Sam 写的，她是一个虚构出来的人物，她从一开始就从事 IT 工作， 在过去的几年时间里，她一直在做运维工作，同时也承担一些开发工作。Sam 最近在 Flycare 找到了一份 DevOps 工程师的工作。Flycare 正在构建一个管理医疗发票和账单的 Web 和移动平台。这是一家小型创业公司 ：两名运维人员加五名全职开发人员，还有几名业务人员。麻雀虽小，但数据健康的风险却不小，他们希望 Sam 能够搭建一个安全的平台来运行 Web 服务。
这也是 Sam 求之不得的挑战，但是对于开发人员喜欢一天三次将 GitHub 的代码部署到 Docker 容器中的一家创业公司来说，保护这样一个高风险的平台将会非常困难。她需要一些帮助，于是我写了这本书来帮助 Sam。
本书是如何组织的
《云原生安全与 DevOps 保障》的结构就像一份教程，从基本的运维理念开始， 确保读者先掌握最基本的 DevOps 技术，再逐步深入更复杂的主题。我们将在第 1 部分深入研究一个示例环境的安全性，在第 2 部分识别和对抗攻击，在第 3 部分完善组织的安全策略。这些章节的顺序也反映出一个还没有建立安全策略或者刚刚采用 DevOps 的组织实现安全策略的方式。这是一本包含了大量概念而且实践性很强的手册，你一定有机会将理论应用到实践之中。
路线图
第 1 章将阐述 DevOps 的概念，以及安全性和开发、运维实践紧密结合的必要性。你将了解我们用整本书来实现的持续安全方法。
第 1 部分从第 2 章开始，到第 6 章结束，将带领读者了解如何保障一条完整DevOps 流水线的安全。
第 2 章将介绍构建在 AWS 上的 DevOps 流水线。你将搭建一条流水线去自动化地部署一个示例应用。一开始它并不安全，我们将指出需要改进的地方， 并在接下来的章节里逐一解决。
第 3 章将阐述 Web 应用的安全性。我们将讨论如何测试网站，如何防止常见攻击，如何管理用户身份验证，以及如何使代码保持最新。
第 4 章将着重介绍如何加固 AWS 基础设施。你将了解到如何将安全测试作为自动化部署的一部分来执行，如何限制网络访问，如何保护对基础设施的访问，以及如何保护数据库。
第 5 章将深入讨论通信安全，讨论 HTTPS 下的加密协议 TLS，以及如何正确地实现 TLS 以达到保护网站的目的。
第 6 章将论述交付流水线的安全性。我们将讨论如何管理 GitHub、Docker Hub 和 AWS 中的访问控制。你还将了解到如何保护源代码和容器的完整性， 以及如何向应用分发凭证。
第 2 部分从第 7 章开始，到第 10 章结束，重点关注如何监控基础设施中的异常， 以及如何保护服务免受攻击。
第 7 章将阐述日志流水线的结构。你将看到收集、串流、分析、存储和访问这五层如何协作以便能有效地对日志进行处理。
第 8 章将着重介绍日志流水线中的分析层。你将运用各种技术来处理日志， 并检测异常和欺诈活动。
第 9 章将探讨入侵检测。我们将讨论在网络、系统和人员这三个层次中用于检测欺诈活动的工具和技术。
第 10 章将给出一个发生在虚构组织中的安全事件案例研究。你将了解如何应对和响应安全事件，以及如何从安全事件中恢复。
第 3 部分从第 11 章开始，到第 13 章结束，将教你完善 DevOps 组织安全策略的技术。
第 11 章将介绍风险评估。你将了解 CIA 三要素（保密性、完整性和可用性），以及 STRIDE 和 DREAD 两种威胁建模框架。你还将了解如何在组织中实施轻量的风险评估框架。
第 12 章将探讨 Web 应用、源代码和基础设施三个层级的安全测试。我们将讨论各种可以用来查找组织中安全问题的工具和技术。
第 13 章将介绍一个在组织中实现持续安全的三年模型，并分享一些能增加成功机会的技巧。