推薦序一　xvii
推薦序二　xix
對本書的贊譽　xxi
序一　xxiii
序二　xxv
前言　xxvii

第一部分　入門資料

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

1.1　從密碼和電鉆談起　3
1.2　可靠性與安全性：設計注意事項　4

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

CIA 是指 confidentiality（機密性）、integrity（完整性）和 availability（可?性）。

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

這個概念源于?警警報機制，指引?戶“在緊急情況下打碎玻 璃”以此觸發警報。Breakglass 機制提供了緊急情況下完全繞開授權機 制訪問系統的能?。

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

1.優先選?解釋空間更少的窄接?
服務可以使?許多不同的模型和框架來開放接?，舉?個例?：

• 基于 RESTful HTTP 和 JSON 的 OpenAPI
• gRPC
• Thrift
• W3C Web Services（XML/WSDL/SOAP）
• CORBA
• DCOM

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

3.執?
如果防御者將特洛伊??包圍起來，限制了他們的暴露 環境，攻擊者將更難在不被注意的情況下離開藏?之處。?絡戰 中將這種戰術稱為沙盒（將在 8.2.2 節的“運?時層”進?更詳細的 描述）。

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

如今，提?安全性的常??法是對?絡進?分段，并將每個?段 的訪問權限授予特定類別的?戶或服務。可以通過將虛擬局域? （VLAN）與?絡 ACL 配合使?來達到此?的

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

因為單臺機器很少能使?項?型服務中斷（通常由多臺服務器? 撐），所以孤注?擲的攻擊者會開發?具來融合多臺機器的?量，這 就是所謂的分布式拒絕服務（distributed denial- of-service, DDoS）攻 擊。

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

編譯期間，ASan 添加某些指令，以便在提供的 Sanitizer 運?時中設置回調。運?時會維護有關程序執?的元數據，如 訪問哪些內存地址是有效的。ASan 使?影?內存來記錄程序將訪問的 給定字節是否安全，并在程序試圖讀取或寫?該字節時使?編譯器插 ?的指令來檢查影?內存。它還提供?定義內存分配和釋放（malloc 和 free）功能。例如，malloc 函數在返回的請求內存區域之前和之 后?即分配額外內存。創建?個緩沖區存儲區域，從?允許 ASan 報告 緩沖區上溢和下溢，并提供錯誤細節和位置等精確信息。要實現這? 效果，ASan 會將這些區域（也稱為紅?區域）標記為污染狀態。類似 地，ASan 會將已釋放的內存標記為污染狀態，從?使捕獲釋放后重引 ?（use-after-free）漏洞變得輕?易舉。

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

• ?絲雀測試和灰度發布。 通過向?范圍的?戶或系統發布重?變更來減少擔憂。
• 狗糧（dogfood）。通過向?戶展???不擔???做的變更，可以傳遞任何特 定更改對穩定性和?產?不會有影響的信?。狗糧（亦稱“吃你??的 狗糧”）是指在影響他?之前應?變更。
• 先可選，再強制
• 漸進式收緊

21.2.3　使安全兜底措施成為常態　344

21.2.4　提高生產力和可用性　344

如果? 們認為新的控制措施減緩了發展和創新的步伐，那么他們可能會認為 采納變更會對組織產?負?影響。

• 構建透明功能。我們討論了如何通過使?默認安全的 API、框架和庫來減輕開發?員在安全性和可靠性??的負擔。
• ??注冊與??判斷門戶。我們發現公開投票是?種令?滿意的管控?式。
  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