《Google系统架构解密：构建安全可靠的系统》—

Velocity中国 Strata北京 AI北京 O'Reilly Conferences

Google系统架构解密：构建安全可靠的系统

Heather Adkins, Betsy Beyer, Paul Blankinship, Piotr Lewandowski, Ana Oprea, Adam Stubblefield 著

周雨阳, 刘志颖译

出版时间：2021年09月

页数：355

如何保证大型分布式服务能够安全、可靠地运行?拥有亿级用户和复杂业务场景的Google让这件事看起来很简单，但事实并非如此。在本书中，Google的SRE团队和安全团队分享了他们的前沿经验和真知灼见，并展示了互联网级别的服务如何保障安全性和可靠性。
随着DevSecOps日渐兴起，这本从Google和整个行业的经验中提炼方法论的书，将帮助你洞悉软件系统的安全可靠之道。你将通过以下几点来学习如何构建安全、可靠的系统。
● 系统架构设计策略
● 推荐采用的编程、测试和调试实践
● 预防和响应事故，以及从事故中恢复
● 让团队高效合作的文化

目录
产品信息
关于作者

推荐序一　
推荐序二　
对本书的赞誉　
序一　
序二　
前言　
第一部分　入门资料
第1章　安全性与可靠性的交集　
1.1　从密码和电钻谈起　
1.2　可靠性与安全性：设计注意事项　
1.3　机密性、完整性、可用性　
1.3.1　机密性　
1.3.2　完整性　
1.3.3　可用性　
1.4　可靠性与安全性：共性　
1.4.1　隐形　
1.4.2　评估　
1.4.3　简洁性　
1.4.4　演变　
1.4.5　弹性　
1.4.6　从设计到生产　
1.4.7　调查系统和日志　
1.4.8　危机响应　
1.4.9　恢复　
1.5　小结　
第2章　了解攻击者　
2.1　攻击者动机　
2.2　攻击者画像　
2.2.1　业余爱好者　
2.2.2　漏洞研究人员　
2.2.3　黑客活动家　
2.2.4　犯罪分子　
2.2.5　自动化和人工智能　
2.2.6　内部人员　
2.3　攻击者方法论　
2.3.1　威胁情报　
2.3.2　网络杀伤链　
2.3.3　TTP　
2.4　风险评估注意事项　
2.5　小结　
第二部分　设计系统
第3章　示例分析：安全代理　
3.1　生产环境中的安全代理　
3.2　Google工具代理　
3.3　小结
第4章　设计中的权衡　
4.1　设计目标和要求　
4.1.1　特性需求　
4.1.2　非功能性需求　
4.1.3　功能与涌现特性　
4.1.4　案例：Google的设计文档　
4.2　需求平衡　
4.3　处理紧张局势和统一目标　
4.3.1　案例：微服务和Google Web应用程序框架　
4.3.2　统一涌现特性的需求　
4.4　初始速度和持续速度　
4.5　小结　
第5章　最小特权设计　
5.1　概念和术语　
5.1.1　最小特权　
5.1.2　零信任网络　
5.1.3　零接触　
5.2　基于风险的访问分类　
5.3　最佳实践　
5.3.1　API功能最小化　
5.3.2　Breakglass机制　
5.3.3　审计　
5.3.4　测试和最小特权　
5.3.5　诊断被拒绝的访问　
5.3.6　优雅失败和Breakglass机制　
5.4　工作案例：配置分发　
5.4.1　基于OpenSSH实现的POSIX API　
5.4.2　软件更新API　
5.4.3　自定义OpenSSH ForceCommand　
5.4.4　自定义HTTP接收器（边车）　
5.4.5　自定义HTTP接收器（内置）　
5.4.6　权衡取舍　
5.5　一种用于认证和授权决策的策略框架　
5.5.1　使用高级授权控件　
5.5.2　投入广泛使用的授权框架　
5.5.3　避免潜在的陷阱　
5.6　高级控制　
5.6.1　MPA　
5.6.2　3FA　
5.6.3　业务依据　
5.6.4　临时访问　
5.6.5　代理　
5.7　权衡和冲突　
5.7.1　增加了安全复杂性　
5.7.2　对合作商及公司文化的影响　
5.7.3　影响安全性的质量数据和系统　
5.7.4　对用户工作效率的影响　
5.7.5　对开发复杂性的影响　
5.8　小结　
第6章　面向易理解性的设计　
6.1　为什么易理解性很重要　
6.1.1　系统不变量　
6.1.2　分析不变量　
6.1.3　心智模型　
6.2　设计易理解的系统　
6.2.1　复杂性与易理解性　
6.2.2　分解复杂性　
6.2.3　集中负责安全性和可靠性需求　
6.3　系统架构　
6.3.1　易于理解的接口规范　
6.3.2　易于理解的身份、认证和访问控制　
6.3.3　安全边界　
6.4　软件设计　
6.4.1　使用应用程序框架满足服务需求　
6.4.2　理解复杂的数据流　
6.4.3　考虑API的可用性　
6.5　小结　
第7章　适应变化的设计　
7.1　安全变更的类型　
7.2　变更中的设计　
7.3　让发布更容易的架构决策　
7.3.1　让依赖项保持最新并频繁重建
7.3.2　用自动化测试让发布更频繁
7.3.3　使用容器
7.3.4　使用微服务　
7.4　不同的变更：不同的速度与不同的时间线　
7.4.1　短期变更：零日漏洞　
7.4.2　中期变更：改善安全态势　
7.4.3　长期变更：外部需求　
7.5　难点：计划调整　
7.6　不断扩大的范围：心脏滴血漏洞　
7.7　小结　
第8章　弹性设计　
8.1　弹性设计原则　
8.2　纵深防御　
8.2.1　特洛伊木马　
8.2.2　Google App Engine分析　
8.3　控制降级　
8.3.1　区分故障成本　
8.3.2　部署响应机制　
8.3.3　负责任的自动化　
8.4　控制爆炸半径　
8.4.1　角色分离　
8.4.2　位置分离　
8.4.3　时间分离　
8.5　故障域和冗余　
8.5.1　故障域　
8.5.2　组件类型　
8.5.3　控制冗余　
8.6　持续验证　
8.6.1　验证关键区域　
8.6.2　验证实践　
8.7　实践建议：着手点　
8.8　小结　
第9章　面向恢复性的设计　
9.1　要恢复什么　
9.1.1　随机错误　
9.1.2　意外错误　
9.1.3　软件错误　
9.1.4　恶意行为　
9.2　恢复机制的设计原则　
9.2.1　面向快速恢复的设计（受政策监督）　
9.2.2　限制对外部时间观念的依赖　
9.2.3　回滚所代表的安全性和可靠性间的权衡　
9.2.4　使用显式吊销机制　
9.2.5　了解精确到字节的预期状态　
9.2.6　面向测试和持续验证的设计　
9.3　紧急访问　
9.3.1　访问控制　
9.3.2　通信　
9.3.3　响应人员的习惯　
9.4　预期外的收益　
9.5　小结　
第10章　缓解拒绝服务攻击　
10.1　攻守双方的策略　
10.1.1　攻方的策略　
10.1.2　守方的策略　
10.2　面向防御的设计　
10.2.1　具有防御能力的架构　
10.2.2　使服务具备防护能力　
10.3　缓解攻击　
10.3.1　监控与告警　
10.3.2　优雅降级　
10.3.3　DoS防护系统　
10.3.4　有策略的响应　
10.4　应对源于服务本身的“攻击”　
10.4.1　用户行为　
10.4.2　客户端重试行为　
10.5　小结　
第三部分　实现系统
第11章　案例分析：设计、实现和维护一个受信任的公共CA　
11.1　受信任的公共CA的背景　
11.2　为什么需要受信任的公共CA　
11.3　自建还是购买CA　
11.4　设计、开发和维护过程中的考虑　
11.4.1　选择编程语言　
11.4.2　复杂与简明　
11.4.3　保护第三方和开源组件　
11.4.4　测试　
11.4.5　CA密钥材料的弹性　
11.4.6　数据验证　
11.5　小结　
第12章　编写代码　
12.1　框架级安全性和可靠性保证措施　
12.1.1　使用框架的好处.
12.1.2　案例：用于创建RPC后端的框架　
12.2　常见安全漏洞　
12.2.1　SQL注入漏洞：TrustedSqlString　
12.2.2　预防XSS漏洞：SafeHtml　
12.3　评估和构建框架的经验　
12.3.1　用于常见任务的简单、安全、可靠的库　
12.3.2　部署策略　
12.4　简洁性有助于提升代码的安全性和可靠性　
12.4.1　避免多层嵌套　
12.4.2　消除YAGNI类代码　
12.4.3　偿还技术债务　
12.4.4　重构　
12.5　默认安全性和可靠性　
12.5.1　选择合适的工具　
12.5.2　使用强类型　
12.5.3　检查代码.
12.6　小结　
第13章　代码测试　
13.1　单元测试　
13.1.1　编写有效的单元测试　
13.1.2　编写单元测试的时机　
13.1.3　单元测试对代码的影响　
13.2　集成测试　
13.3　动态程序分析　
13.4　模糊测试　
13.4.1　模糊引擎的工作原理　
13.4.2　编写有效的模糊测试驱动程序　
13.4.3　示例fuzzer　
13.4.4　持续模糊测试　
13.5　静态程序分析　
13.5.1　自动代码检查工具　
13.5.2　如何将静态分析集成至开发工作流中　
13.5.3　抽象解释　
13.5.4　形式化方法　
13.6　小结　
第14章　部署代码　
14.1　概念和术语　
14.2　威胁建模　
14.3　最佳实践　
14.3.1　强制做代码审查　
14.3.2　依赖自动化　
14.3.3　验证工件，而不仅仅是人　
14.3.4　将配置视为代码.
14.4　基于威胁建模做安全加固　
14.5　高级缓解策略　
14.5.1　二进制文件来源　
14.5.2　基于来源的部署策略　
14.5.3　可验证的构建　
14.5.4　部署阻塞点　
14.5.5　部署后验证　
14.6　实用建议　
14.6.1　一步步来　
14.6.2　提供可操作的错误消息　
14.6.3　确保来源信息明确　
14.6.4　创建明确的策略　
14.6.5　引入Breakglass机制　
14.7　重温基于威胁建模部署安全措施　
14.8　小结　
第15章　调查系统　
15.1　从调试到调查　
15.1.1　案例：临时文件　
15.1.2　调试技巧　
15.1.3　当陷入困境时该怎么办
15.1.4　协同调试：一种教学方法　
15.1.5　安全调查与系统调试间的差异　
15.2　收集恰当、有用的日志　
15.2.1　将日志设计为不可变的　
15.2.2　考虑隐私要素　
15.2.3　确定要保留哪些安全相关的日志　
15.2.4　日志记录成本　
15.3　可靠、安全的调试访问　
15.3.1　可靠性　
15.3.2　安全性　
15.4　小结　
第四部分　维护系统
第16章　防灾规划　
16.1　“灾难”的定义　
16.2　动态灾难响应策略　
16.3　灾难风险分析　
16.4　建立事件响应团队　
16.4.1　确定团队成员和角色　
16.4.2　制订团队章程　
16.4.3　建立严重性和优先级模型　
16.4.4　确定与IR团队合作的运营参数　
16.4.5　制订响应计划　
16.4.6　创建详细的行动手册　
16.4.7　确保访问和更新机制就位　
16.5　在事件发生前预先安排系统和人员　
16.5.1　配置系统　
16.5.2　培训　
16.5.3　流程和程序　
16.6　测试系统和响应计划　
16.6.1　审计自动化系统　
16.6.2　开展非侵入式桌面演练.
16.6.3　在生产环境中测试响应　
16.6.4　红队测试　
16.6.5　评估响应　
16.7　Google的案例　
16.7.1　具有全球影响的测试　
16.7.2　DiRT演习测试紧急访问　
16.7.3　行业级漏洞　
16.8　小结　
第17章　危机管理　
17.1　是否存在危机　
17.1.1　事件分诊　
17.1.2　入侵与缺陷　
17.2　指挥事件　
17.2.1　第一步：不要惊慌　
17.2.2　开展响应　
17.2.3　组建自己的事件团队　
17.2.4　OpSec　
17.2.5　牺牲好的OpSec实践换取更大的利益　
17.2.6　调查过程　
17.3　控制事件　
17.3.1　并行处理事件　
17.3.2　移交　
17.3.3　士气　
17.4　沟通　
17.4.1　误解　
17.4.2　拐弯抹角　
17.4.3　会议　
17.4.4　让合适的人了解合适的细节　
17.5　整合回顾　
17.5.1　分诊　
17.5.2　宣布事件　
17.5.3　沟通和OpSec　
17.5.4　开始处理事件　
17.5.5　移交　
17.5.6　交还事件调查工作　
17.5.7　准备沟通和补救　
17.5.8　结束　
17.6　小结　
第18章　恢复和善后　
18.1　恢复调度　
18.2　恢复时间线　
18.3　恢复计划　
18.3.1　确定恢复范围　
18.3.2　恢复过程的考虑因素　
18.3.3　恢复检查清单　
18.4　启动恢复　
18.4.1　隔离资产
18.4.2　系统恢复和软件升级　
18.4.3　数据过滤　
18.4.4　恢复数据　
18.4.5　更换凭据和密钥　
18.6　恢复之后　
18.7　示例　
18.7.1　被入侵的云实例　
18.7.2　大规模钓鱼攻击　
18.7.3　需要复杂恢复工作的、有针对性的攻击　
18.8　小结　
第五部分　组织与文化
第19章　案例研究：Chrome安全团队　
19.1　背景和团队发展史　
19.2　安全是团队的职责　
19.3　帮助用户安全地浏览Web页面　
19.4　速度很重要　
19.5　设计纵深防御机制　
19.6　保持透明，让社区参与进来　
19.7　小结　
第20章　理解角色和责任　
20.1　谁为安全性和可靠性负责　
20.1.1　专家的作用　
20.1.2　了解安全专业知识　
20.1.3　资格认证和学术教育　
20.2　将安全性整合到组织中　
20.2.1　嵌入安全人员和安全团队　
20.2.2　案例：Google的嵌入式安全　
20.2.3　特殊的团队：蓝队和红队　
20.2.4　外部研究者　
20.3　小结　
第21章　建立安全可靠的文化　
21.1　定义健康的安全性和可靠性文化　
21.1.1　默认的安全性和可靠性文化　
21.1.2　评审文化　
21.1.3　意识文化　
21.1.4　说“是”的文化　
21.1.5　接受必然性的文化　
21.1.6　可持续发展文化　
21.2　通过最佳实践改变文化　
21.2.1　对齐项目目标和激励参与者　
21.2.2　通过风险规避机制减少恐惧　
21.2.3　使安全兜底措施成为常态　
21.2.4　提高生产力和可用性　
21.2.5　多沟通，保持透明　
21.2.6　怀抱同理心　
21.3　说服领导层　
21.3.1　了解决策过程　
21.3.2　为变革立案　
21.3.3　选择自己的战场　
21.3.4　升级和问题解决　
21.4　小结　
总结　
附录　灾难风险评估矩阵

书名：Google系统架构解密：构建安全可靠的系统

作者：Heather Adkins, Betsy Beyer, Paul Blankinship, Piotr Lewandowski, Ana Oprea, Adam Stubblefield 著

译者：周雨阳, 刘志颖译

国内出版社：人民邮电出版社

出版时间：2021年09月

页数：355

书号：978-7-115-56925-7

原版书书名：Building Secure and Reliable Systems

原版书出版商：O'Reilly Media

Heather Adkins

希瑟·阿德金斯（Heather Adkins）、贝齐·拜尔（Betsy Beyer）、保罗·布兰肯希普（Paul Blankinship）、彼得·莱万多夫斯基（Piotr Lewandowski）、阿那·奥普雷亚（Ana Oprea）和亚当·斯塔布菲尔德（Adam Stubblefield）均为Google的SRE团队和安全团队成员。

查看Heather Adkins更多信息

Betsy Beyer

Betsy Beyer是Google纽约负责SRE的一名技术文档作家。她之前曾为遍布全球的Google数据中心与Mountain View硬件运维团队编写文档。在搬到纽约之前，Betsy是Stanford大学技术性写作课程的讲师。她曾经学习国际关系与英文文学，并在Stanford和Tulane获得学历。
Chris Jones是Google App Engine的一名SRE。Google App Engine是一个PaaS服务，每天处理超过280亿个请求。他的办公室在旧金山，他之前的工作包括Google广告统计、数据仓库，以及用户支持系统的维护。在之前，Chris曾经在学校IT行业任职，同时参与过竞选数据分析，以及一些BSD内核的修改。他有计算机工程、经济学，以及技术政策学的学位。同时他也是一名有执照的职业工程师。
Jennifer Petoff是Google SRE团队的一名项目经理，工作地点在都柏林，爱尔兰。她曾经负责管理大型全球项目，包括：科学研究、工程、人力资源，以及广告等。Jennifer在加入Google之前，曾在化工行业任职八年。她获得了Stanford大学的化学博士与学士学位，同时她还拥有Rochester大学的心理学学位。
Niall Murphy是Google爱尔兰团队广告SRE的负责人。他拥有20年互联网行业经验，目前是INEX（爱尔兰网络互联枢纽）的主席。他曾经写作以及参与写作很多科技文章与书籍，包括O’Reilly出版的IPv6 Network Administration，以及很多RFC。他目前在参与书写爱尔兰互联网发展史。他拥有计算机科学、数学，以及诗歌学的学历（他当时一定是想错了！）。他目前与妻子和两个儿子居住在都柏林。

查看Betsy Beyer更多信息

Paul Blankinship

希瑟·阿德金斯(Heather Adkins)、贝齐·拜尔(Betsy Beyer)、保罗·布兰肯希普(Paul Blankinship)、彼得·莱万多夫斯基(Piotr Lewandowski)、阿那·奥普雷亚(Ana Oprea)和亚当·斯塔布菲尔德 (Adam Stubblefield)均为Google的SRE团队和安全团队成员。

查看Paul Blankinship更多信息

Piotr Lewandowski

查看Piotr Lewandowski更多信息

Ana Oprea

查看Ana Oprea更多信息

Adam Stubblefield

查看Adam Stubblefield更多信息

购买选项

定价：129.80元

书号：978-7-115-56925-7

出版社：人民邮电出版社

联系出版社邮购