Google系统架构解密 下载 pdf 百度网盘 epub 免费 2025 电子书 mobi 在线

> 谷歌SRE系列新作，聚焦安全性和可靠性

> 谷歌团队针对系统架构分享前沿经验

> 腾讯一线DevSecOps工程师倾力翻译

如何保证大型分布式服务能够安全、可靠地运行？拥有亿级用户和复杂业务场景的Google让这件事看起来很简单，但事实并非如此。在本书中，Google的SRE团队和安全团队分享了他们的前沿经验和真知灼见，并展示了互联网级别的服务如何保障安全性和可靠性。

随着DevSecOps日渐兴起，这本从Google和整个行业的经验中提炼方法论的书，将帮助你洞悉软件系统的安全可靠之道。你将通过以下几点来学习如何构建安全、可靠的系统。

- 系统架构设计策略

- 推荐采用的编程、测试和调试实践

- 预防和响应事故，以及从事故中恢复

- 让团队高效合作的文化

推荐序一　xvii

推荐序二　xix

对本书的赞誉　xxi

序一　xxiii

序二　xxv

前言　xxvii

第一部分　入门资料

第1章　安全性与可靠性的交集　3

1.1　从密码和电钻谈起　3

1.2　可靠性与安全性：设计注意事项　4

1.3　机密性、完整性、可用性　5

1.3.1　机密性　5

1.3.2　完整性　5

1.3.3　可用性　6

1.4　可靠性与安全性：共性　6

1.4.1　隐形　6

1.4.2　评估　7

1.4.3　简洁性　7

1.4.4　演变　7

1.4.5　弹性　8

1.4.6　从设计到生产　9

1.4.7　调查系统和日志　9

1.4.8　危机响应　9

1.4.9　恢复　10

1.5　小结　10

第2章　了解攻击者　11

2.1　攻击者动机　12

2.2　攻击者画像　13

2.2.1　业余爱好者　13

2.2.2　漏洞研究人员　13

2.2.3　黑客活动家　14

2.2.4　犯罪分子　14

2.2.5　自动化和人工智能　15

2.2.6　内部人员　15

2.3　攻击者方法论　19

2.3.1　威胁情报　19

2.3.2　网络杀伤链　20

2.3.3　TTP　20

2.4　风险评估注意事项　21

2.5　小结　21

第二部分　设计系统

第3章　示例分析：安全代理　25

3.1　生产环境中的安全代理　25

3.2　Google工具代理　27

3.3　小结29

第4章　设计中的权衡　30

4.1　设计目标和要求　31

4.1.1　特性需求　31

4.1.2　非功能性需求　31

4.1.3　功能与涌现特性　32

4.1.4　案例：Google的设计文档　33

4.2　需求平衡　34

4.3　处理紧张局势和统一目标　37

4.3.1　案例：微服务和Google Web应用程序框架　37

4.3.2　统一涌现特性的需求　39

4.4　初始速度和持续速度　39

4.5　小结　41

第5章　最小特权设计　42

5.1　概念和术语　43

5.1.1　最小特权　43

5.1.2　零信任网络　43

5.1.3　零接触　43

5.2　基于风险的访问分类　43

5.3　最佳实践　44

5.3.1　API功能最小化　45

5.3.2　Breakglass机制　47

5.3.3　审计　47

5.3.4　测试和最小特权　49

5.3.5　诊断被拒绝的访问　50

5.3.6　优雅失败和Breakglass机制　51

5.4　工作案例：配置分发　51

5.4.1　基于OpenSSH实现的POSIX API　52

5.4.2　软件更新API　52

5.4.3　自定义OpenSSH ForceCommand　53

5.4.4　自定义HTTP接收器（边车）　53

5.4.5　自定义HTTP接收器（内置）　53

5.4.6　权衡取舍　53

5.5　一种用于认证和授权决策的策略框架　54

5.5.1　使用高级授权控件　55

5.5.2　投入广泛使用的授权框架　55

5.5.3　避免潜在的陷阱　56

5.6　高级控制　56

5.6.1　MPA　56

5.6.2　3FA　57

5.6.3　业务依据　58

5.6.4　临时访问　59

5.6.5　代理　59

5.7　权衡和冲突　59

5.7.1　增加了安全复杂性　60

5.7.2　对合作商及公司文化的影响　60

5.7.3　影响安全性的质量数据和系统　60

5.7.4　对用户工作效率的影响　60

5.7.5　对开发复杂性的影响　60

5.8　小结　61

第6章　面向易理解性的设计　62

6.1　为什么易理解性很重要　62

6.1.1　系统不变量　63

6.1.2　分析不变量　64

6.1.3　心智模型　65

6.2　设计易理解的系统　65

6.2.1　复杂性与易理解性　65

6.2.2　分解复杂性　66

6.2.3　集中负责安全性和可靠性需求　67

6.3　系统架构　67

6.3.1　易于理解的接口规范　68

6.3.2　易于理解的身份、认证和访问控制　69

6.3.3　安全边界　74

6.4　软件设计　78

6.4.1　使用应用程序框架满足服务需求　78

6.4.2　理解复杂的数据流　79

6.4.3　考虑API的可用性　81

6.5　小结　83

第7章　适应变化的设计　84

7.1　安全变更的类型　85

7.2　变更中的设计　85

7.3　让发布更容易的架构决策　86

7.3.1　让依赖项保持最新并频繁重建86

7.3.2　用自动化测试让发布更频繁86

7.3.3　使用容器　87

7.3.4　使用微服务　87

7.4　不同的变更：不同的速度与不同的时间线　89

7.4.1　短期变更：零日漏洞　90

7.4.2　中期变更：改善安全态势　92

7.4.3　长期变更：外部需求　94

7.5　难点：计划调整　96

7.6　不断扩大的范围：心脏滴血漏洞　97

7.7　小结　98

第8章　弹性设计　99

8.1　弹性设计原则　100

8.2　纵深防御　100

8.2.1　特洛伊木马　100

8.2.2　Google App Engine分析　102

8.3　控制降级　104

8.3.1　区分故障成本　105

8.3.2　部署响应机制　107

8.3.3　负责任的自动化　109

8.4　控制爆炸半径　111

8.4.1　角色分离　112

8.4.2　位置分离　113

8.4.3　时间分离　115

8.5　故障域和冗余　115

8.5.1　故障域　116

8.5.2　组件类型　117

8.5.3　控制冗余　119

8.6　持续验证　120

8.6.1　验证关键区域　121

8.6.2　验证实践　122

8.7　实践建议：着手点　124

8.8　小结　125

第9章　面向恢复性的设计　127

9.1　要恢复什么　128

9.1.1　随机错误　128

9.1.2　意外错误　128

9.1.3　软件错误　128

9.1.4　恶意行为　129

9.2　恢复机制的设计原则　129

9.2.1　面向快速恢复的设计（受政策监督）　129

9.2.2　限制对外部时间观念的依赖　132

9.2.3　回滚所代表的安全性和可靠性间的权衡　133

9.2.4　使用显式吊销机制　139

9.2.5　了解精确到字节的预期状态　142

9.2.6　面向测试和持续验证的设计　145

9.3　紧急访问　146

9.3.1　访问控制　147

9.3.2　通信　148

9.3.3　响应人员的习惯　148

9.4　预期外的收益　149

9.5　小结　149

第10章　缓解拒绝服务攻击　150

10.1　攻守双方的策略　150

10.1.1　攻方的策略　151

10.1.2　守方的策略　152

10.2　面向防御的设计　152

10.2.1　具有防御能力的架构　152

10.2.2　使服务具备防护能力　154

10.3　缓解攻击　154

10.3.1　监控与告警　154

10.3.2　优雅降级　155

10.3.3　DoS防护系统　155

10.3.4　有策略的响应　156

10.4　应对源于服务本身的“攻击”　157

10.4.1　用户行为　157

10.4.2　客户端重试行为　158

10.5　小结　159

第三部分　实现系统

第11章　案例分析：设计、实现和维护一个受信任的公共CA　163

11.1　受信任的公共CA的背景　163

11.2　为什么需要受信任的公共CA　164

11.3　自建还是购买CA　165

11.4　设计、开发和维护过程中的考虑　165

11.4.1　选择编程语言　166

11.4.2　复杂与简明　166

11.4.3　保护第三方和开源组件　167

11.4.4　测试　167

11.4.5　CA密钥材料的弹性　168

11.4.6　数据验证　168

11.5　小结　169

第12章　编写代码　170

12.1　框架级安全性和可靠性保证措施　171

12.1.1　使用框架的好处.172

12.1.2　案例：用于创建RPC后端的框架　172

12.2　常见安全漏洞　176

12.2.1　SQL注入漏洞：TrustedSqlString　177

12.2.2　预防XSS漏洞：SafeHtml　178

12.3　评估和构建框架的经验　179

12.3.1　用于常见任务的简单、安全、可靠的库　180

12.3.2　部署策略　181

12.4　简洁性有助于提升代码的安全性和可靠性　182

12.4.1　避免多层嵌套　182

12.4.2　消除YAGNI类代码　183

12.4.3　偿还技术债务　184

12.4.4　重构　184

12.5　默认安全性和可靠性　185

12.5.1　选择合适的工具　185

12.5.2　使用强类型　186

12.5.3　检查代码.188

12.6　小结　189

第13章　代码测试　190

13.1　单元测试　190

13.1.1　编写有效的单元测试　191

13.1.2　编写单元测试的时机　191

13.1.3　单元测试对代码的影响　192

13.2　集成测试　193

13.3　动态程序分析　194

13.4　模糊测试　197

13.4.1　模糊引擎的工作原理　197

13.4.2　编写有效的模糊测试驱动程序　200

13.4.3　示例fuzzer　201

13.4.4　持续模糊测试　204

13.5　静态程序分析　205

13.5.1　自动代码检查工具　205

13.5.2　如何将静态分析集成至开发工作流中　209

13.5.3　抽象解释　211

13.5.4　形式化方法　213

13.6　小结　213

第14章　部署代码　214

14.1　概念和术语　214

14.2　威胁建模　216

14.3　最佳实践　217

14.3.1　强制做代码审查　217

14.3.2　依赖自动化　218

14.3.3　验证工件，而不仅仅是人　218

14.3.4　将配置视为代码.219

14.4　基于威胁建模做安全加固　220

14.5　高级缓解策略　222

14.5.1　二进制文件来源　222

14.5.2　基于来源的部署策略　224

14.5.3　可验证的构建　225

14.5.4　部署阻塞点　230

14.5.5　部署后验证　231

14.6　实用建议　232

14.6.1　一步步来　232

14.6.2　提供可操作的错误消息　233

14.6.3　确保来源信息明确　233

14.6.4　创建明确的策略　233

14.6.5　引入Breakglass机制　234

14.7　重温基于威胁建模部署安全措施　234

14.8　小结　234

第15章　调查系统　235

15.1　从调试到调查　236

15.1.1　案例：临时文件　236

15.1.2　调试技巧　237

15.1.3　当陷入困境时该怎么办　243

15.1.4　协同调试：一种教学方法　246

15.1.5　安全调查与系统调试间的差异　246

15.2　收集恰当、有用的日志　247

15.2.1　将日志设计为不可变的　248

15.2.2　考虑隐私要素　249

15.2.3　确定要保留哪些安全相关的日志　249

15.2.4　日志记录成本　252

15.3　可靠、安全的调试访问　253

15.3.1　可靠性　253

15.3.2　安全性　253

15.4　小结　254

第四部分　维护系统

第16章　防灾规划　257

16.1　“灾难”的定义　257

16.2　动态灾难响应策略　258

16.3　灾难风险分析　259

16.4　建立事件响应团队　259

16.4.1　确定团队成员和角色　260

16.4.2　制订团队章程　261

16.4.3　建立严重性和优先级模型　262

16.4.4　确定与IR团队合作的运营参数　262

16.4.5　制订响应计划　263

16.4.6　创建详细的行动手册　264

16.4.7　确保访问和更新机制就位　264

16.5　在事件发生前预先安排系统和人员　264

16.5.1　配置系统　265

16.5.2　培训　265

16.5.3　流程和程序　266

16.6　测试系统和响应计划　266

16.6.1　审计自动化系统　267

16.6.2　开展非侵入式桌面演练.267

16.6.3　在生产环境中测试响应　268

16.6.4　红队测试　270

16.6.5　评估响应　270

16.7　Google的案例　271

16.7.1　具有全球影响的测试　271

16.7.2　DiRT演习测试紧急访问　271

16.7.3　行业级漏洞　271

16.8　小结　272

第17章　危机管理　273

17.1　是否存在危机　274

17.1.1　事件分诊　274

17.1.2　入侵与缺陷　275

17.2　指挥事件　276

17.2.1　第一步：不要惊慌　276

17.2.2　开展响应　277

17.2.3　组建自己的事件团队　277

17.2.4　OpSec　278

17.2.5　牺牲好的OpSec实践换取更大的利益　280

17.2.6　调查过程　280

17.3　控制事件　283

17.3.1　并行处理事件　283

17.3.2　移交　284

17.3.3　士气　286

17.4　沟通　287

17.4.1　误解　287

17.4.2　拐弯抹角　287

17.4.3　会议　288

17.4.4　让合适的人了解合适的细节　289

17.5　整合回顾　290

17.5.1　分诊　290

17.5.2　宣布事件　290

17.5.3　沟通和OpSec　290

17.5.4　开始处理事件　291

17.5.5　移交　291

17.5.6　交还事件调查工作　291

17.5.7　准备沟通和补救　292

17.5.8　结束　292

17.6　小结　293

第18章　恢复和善后　294

18.1　恢复调度　295

18.2　恢复时间线　296

18.3　恢复计划　297

18.3.1　确定恢复范围　297

18.3.2　恢复过程的考虑因素　298

18.3.3　恢复检查清单　301

18.4　启动恢复　302

18.4.1　隔离资产　302

18.4.2　系统恢复和软件升级　303

18.4.3　数据过滤　304

18.4.4　恢复数据　304

18.4.5　更换凭据和密钥　305

18.6　恢复之后　306

18.7　示例　308

18.7.1　被入侵的云实例　308

18.7.2　大规模钓鱼攻击　309

18.7.3　需要复杂恢复工作的、有针对性的攻击　310

18.8　小结　311

第五部分　组织与文化

第19章　案例研究：Chrome安全团队　315

19.1　背景和团队发展史　315

19.2　安全是团队的职责　317

19.3　帮助用户安全地浏览Web页面　318

19.4　速度很重要　319

19.5　设计纵深防御机制　319

19.6　保持透明，让社区参与进来　320

19.7　小结　320

第20章　理解角色和责任　321

20.1　谁为安全性和可靠性负责　322

20.1.1　专家的作用　322

20.1.2　了解安全专业知识　324

20.1.3　资格认证和学术教育　325

20.2　将安全性整合到组织中　325

20.2.1　嵌入安全人员和安全团队　327

20.2.2　案例：Google的嵌入式安全　327

20.2.3　特殊的团队：蓝队和红队　329

20.2.4　外部研究者　330

20.3　小结　332

第21章　建立安全可靠的文化　333

21.1　定义健康的安全性和可靠性文化　334

21.1.1　默认的安全性和可靠性文化　334

21.1.2　评审文化　335

21.1.3　意识文化　336

21.1.4　说“是”的文化　339

21.1.5　接受必然性的文化　340

21.1.6　可持续发展文化　340

21.2　通过最佳实践改变文化　342

21.2.1　对齐项目目标和激励参与者　342

21.2.2　通过风险规避机制减少恐惧　343

21.2.3　使安全兜底措施成为常态　344

21.2.4　提高生产力和可用性　344

21.2.5　多沟通，保持透明　345

21.2.6　怀抱同理心　346

21.3　说服领导层　347

21.3.1　了解决策过程　347

21.3.2　为变革立案　348

21.3.3　选择自己的战场　349

21.3.4　升级和问题解决　349

21.4　小结　350

总结　351

附录　灾难风险评估矩阵　353

作者介绍　355

封面介绍　355

【作者简介】

希瑟·阿德金斯（Heather Adkins）是在Google有近20年工作经验的“老兵”，也是Google安全团队的创始成员。

贝齐·拜尔（Betsy Beyer）毕业于斯坦福大学，是Google SRE技术作者。

保罗·布兰肯希普（Paul Blankinship）是Google技术写作团队负责人，同时服务于Google安全与隐私工程团队。

彼得·莱万多夫斯基（Piotr Lewandowski）是Google安全生产技术负责人，负责促成SRE与安全团队紧密协作。

阿那·奥普雷亚（Ana Oprea）负责安全、SRE及Google技术基础设施的战略规划。

亚当·斯塔布菲尔德（Adam Stubblefield）是Google安全领域的技术负责人，他协助建立了Google大部分核心安全基础设施。

【译者简介】

周雨阳

就职于腾讯安全平台部研发安全团队，参与DevSecOps的一线建设工作，对业务研发流程、编码安全及漏洞检测有深入了解，曾发现并报告Google、Apple、Mozilla等的产品漏洞，另译有《黑客攻防技术宝典：反病毒篇》。

刘志颖

高级安全工程师，现就职于腾讯PCG应用安全团队，担任研发安全方向负责人，主导应用漏洞风险治理和DevSecOps落地工作，在研发与架构安全、安全漏洞发现与防护等方向有较多实战经验。

暂无出版社相关信息，正在全力查找中！

暂无相关书籍摘录，正在全力查找中！

在线阅读地址：Google系统架构解密在线阅读

在线听书地址：Google系统架构解密在线收听

在线购买地址：Google系统架构解密在线购买

“When designing for reliability, you assume that some things will go wrong at some point.

When designing for security, you must assume that an adversary could be trying to make things go wrong at any point”

书籍介绍

> 谷歌SRE系列新作，聚焦安全性和可靠性

> 谷歌团队针对系统架构分享前沿经验

> 腾讯一线DevSecOps工程师倾力翻译

如何保证大型分布式服务能够安全、可靠地运行？拥有亿级用户和复杂业务场景的Google让这件事看起来很简单，但事实并非如此。在本书中，Google的SRE团队和安全团队分享了他们的前沿经验和真知灼见，并展示了互联网级别的服务如何保障安全性和可靠性。

随着DevSecOps日渐兴起，这本从Google和整个行业的经验中提炼方法论的书，将帮助你洞悉软件系统的安全可靠之道。你将通过以下几点来学习如何构建安全、可靠的系统。

- 系统架构设计策略

- 推荐采用的编程、测试和调试实践

- 预防和响应事故，以及从事故中恢复

- 让团队高效合作的文化