掃一掃
關注中圖網
官方微博
本類五星書更多>
-
>
全國計算機等級考試最新真考題庫模擬考場及詳解·二級MSOffice高級應用
-
>
決戰行測5000題(言語理解與表達)
-
>
軟件性能測試.分析與調優實踐之路
-
>
第一行代碼Android
-
>
JAVA持續交付
-
>
EXCEL最強教科書(完全版)(全彩印刷)
-
>
深度學習
Google系統架構解密:構建安全可靠的系統 版權信息
- ISBN：9787115569257
- 條形碼：9787115569257 ; 978-7-115-56925-7
- 裝幀：一般膠版紙
- 冊數：暫無
- 重量：暫無
- 所屬分類：>>
Google系統架構解密:構建安全可靠的系統 本書特色
1.Google安全團隊在本書中分享了成功設計、實現、維護系統的實踐，幫助讀者可了解如何在編程和測試等環節中實現安全性和可靠性。2.每一章均從基礎內容入手，逐漸過渡到復雜的內容，深奧的部分會使用爬行動物圖標來標識，幫讀者掌握重點。3.本書推薦了許多業界認可的工具和技術，讀者可跟據自身項目的需求，設計適合自身風險狀況的解決方案。4.谷歌安全工程副總裁Royal Hansen、Google SRE總監Michael Wildpaner為本書作序推薦，并受到諸多業內人士贊譽：“我有幸與作者共事多年，非常驚訝于他們毫無保留的分享。雖然這本書并非面面俱到，但我認為像它這樣豐富的實用技巧和對權衡取舍的坦率討論無可替代。”——Eric GrosseGoogle公司前安全工程副總裁“在當今萬物互聯的時代，在線服務的安全性與可靠性愈發引人關注。本書的作者基于在Google多年的實踐與思考，體系化地介紹了如何在早期對系統的安全性和穩定性進行頂層設計，同時把相應策略的執行貫穿系統的全生命周期。本書為互聯網開發和運維人員提供了具有實踐價值的指導。”——郄小虎騰訊公司副總裁“Google把重點聚焦在安全主題上，并將可靠性和安全性深度結合，總結出了一套有效的方法，這套方法就是你手中這本書的精髓。”——楊勇騰訊云副總裁、騰訊安全平臺部負責人“這本書系統地介紹了DevSecOps的理念和實踐。落地DevSecOps是龐大的工程，來看看Google是怎么做的吧！”——胡珀騰訊安全平臺部應用運維安全中心總監 “Google的技術和理念在業內一直比較先進，安全方面也是如此。這本書提到的很多實踐值得參考和嘗試。推薦國內安全從業者一讀。”——林銳林騰訊PCG安全總監“Google擁有開放的分享經驗，其安全團隊在這本書中分享了眾多先進的觀點和解決方案，并提供了關于基礎設施安全‘解坑’和安全設計的寶貴參考。”——ThreatSource（鳥哥）
Google系統架構解密:構建安全可靠的系統 內容簡介
作為系統架構的重中之重，安全性和可靠性是設計和維護可擴展系統的核心。在本書中，Google安全團隊分享了成功設計、實現、維護系統的很好實踐。你將了解系統的設計策略，如何在編程、測試、調試等環節中實現安全性和可靠性，以及如何應對不可預知的安全事件。全書分為五大部分，共21章，內容涉及安全性和可靠性的關系，系統的設計原則、實現原則、維護原則，還輔以豐富的案例分析。閱讀本書，你不僅能學到豐富的系統架構技巧，而且能看到相關從業者在面臨復雜的實際狀況時如何權衡利弊，從而真正提高系統的安全性和可靠性。
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
推薦序二 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
展開全部
Google系統架構解密:構建安全可靠的系統 作者簡介
【作者簡介】希瑟.阿德金斯（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落地工作，在研發與架構安全、安全漏洞發現與防護等方向有較多實戰經驗。
書友推薦
- >
伊索寓言-世界文學名著典藏-全譯本
- >
企鵝口袋書系列·偉大的思想20:論自然選擇(英漢雙語)
- >
羅庸西南聯大授課錄
- >
中國歷史的瞬間
- >
苦雨齋序跋文-周作人自編集
- >
有舍有得是人生
- >
名家帶你讀魯迅:故事新編
- >
詩經-先民的歌唱
本類暢銷
