首页 > 科技 > 计算机 > 信息安全

云原生安全与DevOps保障

作译者：覃宇

出版时间：2020-04 千字数：489 版次：01-01 页数：388

开本：16开装帧： I S B N ：9787121384486

换版：

纸质书定价：￥108.0

库存:有

分享到：

共有图书评论0条【查看评论摘要】

看了又看

{{data.bookName}}

￥{{data.price}}

内容简介

前言

上架建议

作者简介

编辑推荐

音视频专区

1	DevOps 保障	1
1.1	DevOps 方法	2
1.1.1	持续集成	3
1.1.2	持续交付	4
1.1.3	基础设施即服务	5
1.1.4	文化和信任	6
1.2	DevOps 中的安全	7
1.3	持续安全	8
1.3.1	测试驱动安全	10
1.3.2	攻击监控与应对	12
1.3.3	评估风险并完善安全性	16
1.4	本章小结	17
第1 部分	案例研究：在简易的 DevOps 流水线上应用多层安全性
2	建立简易的 DevOps 流水线	21
2.1	实现线路图	22
2.2	代码仓库 ：GitHub	24
2.3	CI 平台 ：CircleCI	24
2.4	容器镜像库 ：Docker Hub	28
2.5	生产环境基础设施 ：Amazon Web Services	30
2.5.1	三层架构	31
2.5.2	配置访问 AWS	32
2.5.3	虚拟私有云	34
2.5.4	创建数据库层	35
2.5.5	EB 创建前两层	37
2.5.6	将容器部署到系统中	41
2.6	快速安全审计	44
2.7	本章小结	45
3	第一层安全性 ：保护 Web 应用	47
3.1	保护并测试 Web 应用	48
3.2	网站攻击和内容安全	52
3.2.1	跨站脚本攻击和内容安全策略	52
3.2.2	跨站请求伪造	59
3.2.3	点击劫持和 IFrame 保护	64
3.3	用户身份验证的方法	65
3.3.1	HTTP 基本身份验证	66
3.3.2	密码管理	68
3.3.3	身份提供商	69
3.3.4	会话和 Cookie 的安全性	75
3.3.5	测试身份验证	75
3.4	依赖管理	76
3.4.1	Golang vendoring	76
3.4.2	Node.js 的包管理	78
3.4.3	Python requirements	79
3.5	本章小结	80
4	第二层安全性 ：保护云基础设施	81
4.1	保护并测试云基础设施 ：部署器	82
4.1.1	设置部署器	83
4.1.2	配置 Docker Hub 和部署器之间的通知	84
4.1.3	对基础设施执行测试	85
4.1.4	更新发票应用的环境	85
4.2	限制网络访问	86
4.2.1	测试安全组	87
4.2.2	开放安全组之间的访问权限	90
4.3	搭建安全入口	91
4.3.1	生成 SSH 密钥	93
4.3.2	在 EC2 中创建堡垒机	94
4.3.3	启用 SSH 双因子验证	96
4.3.4	被访问时发送通知	101
4.3.5	一般安全注意事项	103
4.3.6	开放安全组之间的访问权限	109
4.4	控制对数据库的访问	111
4.4.1	分析数据库结构	112
4.4.2	PostgreSQL 的角色和权限	114
4.4.3	为发票应用定义细粒度的权限	115
4.4.4	在部署器中断言权限	120
4.5	本章小结	122
5	第三层安全性 ：保护通信	123
5.1	安全通信意味着什么	124
5.1.1	早期的对称加密	125
5.1.2	Di?e-Hellman 与 RSA	126
5.1.3	公钥基础设施	129
5.1.4	SSL 和 TLS	130
5.2	理解 SSL/TLS	131
5.2.1	证书链	132
5.2.2	TLS 握手	132
5.2.3	完美前向保密	135
5.3	让应用使用 HTTPS	136
5.3.1	从 AWS 获取证书	136
5.3.2	从 Let’s Encrypt 获取证书	137
5.3.3	在 AWS ELB 上启用 HTTPS	139
5.4	现代化 HTTPS	142
5.4.1	测试 TLS	143
5.4.2	实施 Mozilla 现代指南	146
5.4.3	HSTS ：严格传输安全	147
5.4.4	HPKP ：公钥固定	149
5.5	本章小结	152
6	第四层安全性 ：保护交付流水线	153
6.1	代码管理基础设施的访问控制	155
6.1.1	管理 GitHub 组织中的权限	156
6.1.2	管理 GitHub 和 CircleCI 之间的权限	158
6.1.3	用 Git 对提交和 tag 签名	161
6.2	容器存储的访问控制	165
6.2.1	管理 Docker Hub 与 CircleCI 之间的权限	165
6.2.2	用 Docker 内容信任机制对容器签名	168
6.3	基础设施管理的访问控制	169
6.3.1	使用 AWS 角色和策略管理权限	169
6.3.2	将密码分发到生产环境系统中	173
6.4	本章小结	179
第 2 部分	监控异常，保护服务免受攻击
７	收集并保存日志	183
7.1	从系统和应用中收集日志	185
7.1.1	从系统中收集日志	187
7.1.2	收集应用日志	191
7.1.3	基础设施日志	194
7.1.4	收集 GitHub 日志	197
7.2	通过消息代理串流日志事件	199
7.3	在日志消费者中处理事件	201
7.4	保存并归档日志	204
7.5	访问日志	206
7.6	本章小结	209
8	分析日志找到欺诈和攻击	211
8.1	日志分析层的架构	212
8.2	使用字符串特征检测攻击	219
8.3	欺诈检测的统计模型	223
8.3.1	滑动窗口与循环缓冲	223
8.3.2	移动平均值	226
8.4	利用地理信息数据来发现滥用	229
8.4.1	记录用户的地理信息	230
8.4.2	计算距离	231
8.4.3	找到用户的正常连接区域	232
8.5	检测已知模式的异常	234
8.5.1	user-agent 特征	234
8.5.2	异常的浏览器	234
8.5.3	交互模式	234
8.6	向运维人员和最终用户发出告警	235
8.6.1	向运维人员升级安全事件	236
8.6.2	何时以何种方式通知最终用户	239
8.7	本章小结	240
9	入侵检测	243
9.1	入侵七部曲 ：杀伤链	244
9.2	什么是攻击指示符	246
9.3	扫描终端节点寻找 IOC	254
9.4	使用 Suricata 检查网络流量	265
9.4.1	设置 Suricata	267
9.4.2	监控网络	268
9.4.3	编写规则	269
9.4.4	使用预定义规则集	270
9.5	在系统调用审计日志中寻找入侵	271
9.5.1	执行的漏洞	272
9.5.2	捕捉欺诈命令的执行	273
9.5.3	监控文件系统	275
9.5.4	监控不可能发生的事情	276
9.6	信任人们发现异常的能力	277
9.7	本章小结	278
10	安全事件响应案例分析 ：加勒比海“瘫”	279
10.1	加勒比海“瘫”	281
10.2	识别	281
10.3	隔离	285
10.4	杀灭	287
10.4.1在 AWS 中捕获数字取证制品	289
10.4.2出站 IDS 过滤	290
10.4.3使用 MIG 追踪 IOC	295
10.5	恢复	298
10.6	总结经验和充分准备的优势	300
10.7	本章小结	303
第 3 部分	DevOps 安全性走向成熟
11	风险评估	307
11.4	风险管理是什么	308
11.5	CIA 三要素	310
11.2.1	机密性	311
11.2.2	完整性	312
11.2.3	可用性	313
11.6	确定组织面临的最大威胁	314
11.7	量化风险产生的影响	316
11.4.1	财务	317
11.4.2	声誉	317
11.4.3	生产力	318
11.8	识别威胁并度量脆弱程度	318
11.8.1	STRIDE 威胁建模框架	319
11.8.2	DREAD 威胁建模框架	320
11.9	快速风险评估	322
11.9.1	收集信息	323
11.9.2	建立数据字典	325
11.9.3	识别并度量风险	326
11.9.4	给出建议	328
11.10	记录并跟踪风险	329
11.10.1	承担、拒绝或转移风险	331
11.10.2	定期回顾风险	331
11.11	本章小结	332
12	测试安全性	333
12.4	维护安全可见性	334
12.5	审计内部应用和服务	335
12.5.1	Web 应用扫描器	336
12.5.2	模糊测试	339
12.5.3	静态代码扫描	342
12.5.4	审计云基础设施	345
12.6	红军和外部渗透测试	349
12.7	Bug 赏金计划	353
12.8	本章小结	356
13	持续安全	357
13.4	实践并反复练习 ：10000 小时安全性	358
13.5	第一年 ：将安全整合到 DevOps 中	359
13.5.1	不要过早下结论	360
13.5.2	全面测试并建立仪表盘	360
13.6	第二年 ：居安思危	362
13.6.1	避免重复的基础设施建设	362
13.6.2	自建或采购	363
13.6.3	承受攻击	364
13.7	第三年 ：推动变革	364
13.7.1	重新审视安全优先级	365
13.7.2	迭代前进	365

近年来，在软件开发领域，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 章将介绍一个在组织中实现持续安全的三年模型，并分享一些能增加成功机会的技巧。

查看更多 > 图书评论

暂无评论

发表图书评论

评论标题：
评论内容：
验证码：: 看不清楚
点击刷新
: 您还没有登录，请登录后再评论。
点击“登录”

购买过本书的顾客还买过

{{data.bookName}}

￥{{data.price}}