Google系統(tǒng)架構解密：構建安全可靠的系統(tǒng)

推薦序一　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　調查系統(tǒng)和日志　9
1．4．8　危機響應　9
1．4．9　恢復　10
1．5　小結　10
第 2章　了解攻擊者　11
2．1　攻擊者動機　12
2．2　攻擊者畫像　13
2．2．1　業(yè)余愛好者　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　網(wǎng)絡殺傷鏈　20
2．3．3　TTP　20
2．4　風險評估注意事項　21
2．5　小結　21
第二部分　設計系統(tǒng)
第3章　示例分析：安全代理　25
3．1　生產環(huán)境中的安全代理　25
3．2　Google工具代理　27
3．3　小結29
第4章　設計中的權衡　30
4．1　設計目標和要求　31
4．1．1　特性需求　31
4．1．2　非功能性需求　31
4．1．3　功能與涌現(xiàn)特性　32
4．1．4　案例：Google的設計文檔　33
4．2　需求平衡　34
4．3　處理緊張局勢和統(tǒng)一目標　37
4．3．1　案例：微服務和Google Web應用程序框架　37
4．3．2　統(tǒng)一涌現(xiàn)特性的需求　39
4．4　初始速度和持續(xù)速度　39
4．5　小結　41
第5章　最小特權設計　42
5．1　概念和術語　43
5．1．1　最小特權　43
5．1．2　零信任網(wǎng)絡　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　優(yōu)雅失敗和Breakglass機制　51
5．4　工作案例：配置分發(fā)　51
5．4．1　基于OpenSSH實現(xiàn)的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　業(yè)務依據(jù)　58
5．6．4　臨時訪問　59
5．6．5　代理　59
5．7　權衡和沖突　59
5．7．1　增加了安全復雜性　60
5．7．2　對合作商及公司文化的影響　60
5．7．3　影響安全性的質量數(shù)據(jù)和系統(tǒng)　60
5．7．4　對用戶工作效率的影響　60
5．7．5　對開發(fā)復雜性的影響　60
5．8　小結　61
第6章　面向易理解性的設計　62
6．1　為什么易理解性很重要　62
6．1．1　系統(tǒng)不變量　63
6．1．2　分析不變量　64
6．1．3　心智模型　65
6．2　設計易理解的系統(tǒng)　65
6．2．1　復雜性與易理解性　65
6．2．2　分解復雜性　66
6．2．3　集中負責安全性和可靠性需求　67
6．3　系統(tǒng)架構　67
6．3．1　易于理解的接口規(guī)范　68
6．3．2　易于理解的身份、認證和訪問控制　69
6．3．3　安全邊界　74
6．4　軟件設計　78
6．4．1　使用應用程序框架滿足服務需求　78
6．4．2　理解復雜的數(shù)據(jù)流　79
6．4．3　考慮API的可用性　81
6．5　小結　83
第7章　適應變化的設計　84
7．1　安全變更的類型　85
7．2　變更中的設計　85
7．3　讓發(fā)布更容易的架構決策　86
7．3．1　讓依賴項保持最新并頻繁重建86
7．3．2　用自動化測試讓發(fā)布更頻繁86
7．3．3　使用容器　87
7．3．4　使用微服務　87
7．4　不同的變更：不同的速度與不同的時間線　89
7．4．1　短期變更：零日漏洞　90
7．4．2　中期變更：改善安全態(tài)勢　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　區(qū)分故障成本　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　持續(xù)驗證　120
8．6．1　驗證關鍵區(qū)域　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　面向快速恢復的設計（受政策監(jiān)督）　129
9．2．2　限制對外部時間觀念的依賴　132
9．2．3　回滾所代表的安全性和可靠性間的權衡　133
9．2．4　使用顯式吊銷機制　139
9．2．5　了解精確到字節(jié)的預期狀態(tài)　142
9．2．6　面向測試和持續(xù)驗證的設計　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　監(jiān)控與告警　154
10．3．2　優(yōu)雅降級　155
10．3．3　DoS防護系統(tǒng)　155
10．3．4　有策略的響應　156
10．4　應對源于服務本身的“攻擊”　157
10．4．1　用戶行為　157
10．4．2　客戶端重試行為　158
10．5　小結　159
第三部分　實現(xiàn)系統(tǒng)
第 11章　案例分析：設計、實現(xiàn)和維護一個受信任的公共CA　163
11．1　受信任的公共CA的背景　163
11．2　為什么需要受信任的公共CA　164
11．3　自建還是購買CA　165
11．4　設計、開發(fā)和維護過程中的考慮　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　數(shù)據(jù)驗證　168
11．5　小結　169
第 12章　編寫代碼　170
12．1　框架級安全性和可靠性保證措施　171
12．1．1　使用框架的好處．172
12．1．2　案例：用于創(chuàng)建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　動態(tài)程序分析　194
13．4　模糊測試　197
13．4．1　模糊引擎的工作原理　197
13．4．2　編寫有效的模糊測試驅動程序　200
13．4．3　示例fuzzer　201
13．4．4　持續(xù)模糊測試　204
13．5　靜態(tài)程序分析　205
13．5．1　自動代碼檢查工具　205
13．5．2　如何將靜態(tài)分析集成至開發(fā)工作流中　209
13．5．3　抽象解釋　211
13．5．4　形式化方法　213
13．6　小結　213
第 14章　部署代碼　214
14．1　概念和術語　214
14．2　威脅建?！?16
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　創(chuàng)建明確的策略　233
14．6．5　引入Breakglass機制　234
14．7　重溫基于威脅建模部署安全措施　234
14．8　小結　234
第 15章　調查系統(tǒng)　235
15．1　從調試到調查　236
15．1．1　案例：臨時文件　236
15．1．2　調試技巧　237
15．1．3　當陷入困境時該怎么辦　243
15．1．4　協(xié)同調試：一種教學方法　246
15．1．5　安全調查與系統(tǒng)調試間的差異　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
第四部分　維護系統(tǒng)
第 16章　防災規(guī)劃　257
16．1　“災難”的定義　257
16．2　動態(tài)災難響應策略　258
16．3　災難風險分析　259
16．4　建立事件響應團隊　259
16．4．1　確定團隊成員和角色　260
16．4．2　制訂團隊章程　261
16．4．3　建立嚴重性和優(yōu)先級模型　262
16．4．4　確定與IR團隊合作的運營參數(shù)　262
16．4．5　制訂響應計劃　263
16．4．6　創(chuàng)建詳細的行動手冊　264
16．4．7　確保訪問和更新機制就位　264
16．5　在事件發(fā)生前預先安排系統(tǒng)和人員　264
16．5．1　配置系統(tǒng)　265
16．5．2　培訓　265
16．5．3　流程和程序　266
16．6　測試系統(tǒng)和響應計劃　266
16．6．1　審計自動化系統(tǒng)　267
16．6．2　開展非侵入式桌面演練．267
16．6．3　在生產環(huán)境中測試響應　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　行業(yè)級漏洞　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　讓合適的人了解合適的細節(jié)　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　系統(tǒng)恢復和軟件升級　303
18．4．3　數(shù)據(jù)過濾　304
18．4．4　恢復數(shù)據(jù)　304
18．4．5　更換憑據(jù)和密鑰　305
18．6　恢復之后　306
18．7　示例　308
18．7．1　被入侵的云實例　308
18．7．2　大規(guī)模釣魚攻擊　309
18．7．3　需要復雜恢復工作的、有針對性的攻擊　310
18．8　小結　311
第五部分　組織與文化
第 19章　案例研究：Chrome安全團隊　315
19．1　背景和團隊發(fā)展史　315
19．2　安全是團隊的職責　317
19．3　幫助用戶安全地瀏覽Web頁面　318
19．4　速度很重要　319
19．5　設計縱深防御機制　319
19．6　保持透明，讓社區(qū)參與進來　320
19．7　小結　320
第 20章　理解角色和責任　321
20．1　誰為安全性和可靠性負責　322
20．1．1　專家的作用　322
20．1．2　了解安全專業(yè)知識　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　可持續(xù)發(fā)展文化　340
21．2　通過最佳實踐改變文化　342
21．2．1　對齊項目目標和激勵參與者　342
21．2．2　通過風險規(guī)避機制減少恐懼　343
21．2．3　使安全兜底措施成為常態(tài)　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　選擇自己的戰(zhàn)場　349
21．3．4　升級和問題解決　349
21．4　小結　350
總結　351
附錄　災難風險評估矩陣　353
作者介紹　355
封面介紹　355