Google

系統(tǒng)架構(gòu)解密

構(gòu)建安全可靠的系統(tǒng)

目錄

第一部分入門資料

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

1.1從密碼和電鉆談起

1.2可靠性與安全性：設(shè)計注意事項

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從設(shè)計到生產(chǎn)

1.4.7調(diào)查系統(tǒng)和日志

1.4.8危機響應(yīng)

1.4.9恢復(fù)

1.5小結(jié)

第2章了解攻擊者

2.1攻擊者動機

2.2攻擊者畫像

2.2.1業(yè)余愛好者

2.2.2漏洞研究人員

2.2.3黑客活動家

2.2.4犯罪分子

2.2.5自動化和人工智能

2.2.6內(nèi)部人員

2.3攻擊者方法論

2.3.1威脅情報

2.3.2網(wǎng)絡(luò)殺傷鏈

2.3.3TTP

2.4風(fēng)險評估注意事項

2.5小結(jié)

第二部分設(shè)計系統(tǒng)

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

3.1生產(chǎn)環(huán)境中的安全代理

3.2Google工具代理

33小結(jié)

第4章設(shè)計中的權(quán)衡

4.:設(shè)計目標和要求

4.1.1特性需求

4.1.2非功能性需求

4.1.3功能與涌現(xiàn)特性

4.1.4案例：Google的設(shè)計又檔

4.2需求平衡

案例：支付系統(tǒng)

4.3處理緊張局勢和統(tǒng)一目標

4.3.1案例：微服務(wù)和GoogleWeb應(yīng)用程序框架

4.3.2統(tǒng)一涌現(xiàn)特性的需求

4.4初始速度和持續(xù)速度

4.5小結(jié)

第5章最小特權(quán)設(shè)計

5.1概念和術(shù)語

5.1.1最小特權(quán)

5.1.2零信任網(wǎng)絡(luò)

5.1.3零接觸

5.2基于風(fēng)險的訪問分類

5.3最佳實踐

5.3.1API功能最小化

5.3.2Breakglass機制

5.3.3審計

5.3.4測試和最小特權(quán)

5.3.5診斷被拒絕的訪問

5.3.6優(yōu)雅失敗和Breakglass機制

5.4工作案例：配置分發(fā)

5.4.1基于OpenSSH實現(xiàn)的POSIXAPI

5.4.2軟件更新API

5.4.3自定義OpenSSHForceCommand

5.4.4自定義HTTP接收器（邊車）

5.4.5自定義HTTP接收器（內(nèi)置）

5.4.6權(quán)衡取舍

5.5一種用于認證和授權(quán)決策的策略框架

5.5.1使用高級授權(quán)控件

5.5.2投入廣泛使用的授權(quán)框架

5.5.3避免潛在的陷阱

5.6高級控制

5.6.1MPA

5.6.23FA

5.6.3業(yè)務(wù)依據(jù)

5.6.4臨時訪問

5.6.5代理

5.7權(quán)衡和沖突

5.7.1增加了安全復(fù)雜性

5.7.2對合作商及公司文化的影響

5.7.3影響安全性的質(zhì)量數(shù)據(jù)和系統(tǒng)

5.7.4對用戶工作效率的影響

5.7.5對開發(fā)復(fù)雜性的影響

5.8小結(jié)

第6章面向易理解性的設(shè)計

6.1為什么易理解性很重要

6.1.1系統(tǒng)不變量

6.1.2分析不變量

6.1.3心智模型

6.2設(shè)計易理解的系統(tǒng)

6.2.1復(fù)雜性與易理解性

6.2.2分解復(fù)雜性

6.2.3集中負責(zé)安全性和可靠性需求

6.3系統(tǒng)架構(gòu)

6.3.1易于理解的接口規(guī)范

6.3.2易于理解的身份、認證和訪問控制

6.3.3安全邊界

6.4軟件設(shè)計

6.4.1使用應(yīng)用程序框架滿足服務(wù)需求

6.4.2理解復(fù)雜的數(shù)據(jù)流

6.4.3考慮API的可用性

6.5小結(jié)

第7章適應(yīng)變化的設(shè)計

7.1安全變更的類型

7.2變更中的設(shè)計

7.3讓發(fā)布更容易的架構(gòu)決策

7.3.1讓依賴項保持最新并頻繁重建

7.3.2用自動化測試讓發(fā)布更頻繁

7.3.3使用容器

7.3.4使用微服務(wù)

7.4不同的變更：不同的速度與不同的時間線

7.4.1短期變更：零日漏洞

7.4.2中期變更：改善安全態(tài)勢

7.4.3長期變更：外部需求

7.5難點：計劃調(diào)整

7.6不斷擴大的范圍：心臟滴血漏洞

77小結(jié)

第8章彈性設(shè)計

8.1彈性設(shè)計原則

8.2縱深防御

8.2.1特洛伊木馬

8.2.2GoogleAppEngine分析

8.3控制降級

8.3.1區(qū)分故障成本

8.3.2部署響應(yīng)機制

8.3.3負責(zé)任的自動化

8.4控制爆炸半徑

8.4.1角色分離

8.4.2位置分離

8.4.3時間分離

8.5故障域和冗余

8.5.1故障域

8.5.2組件類型

8.5.3控制冗余

8.6持續(xù)驗證

8.6.1驗證關(guān)鍵區(qū)域

8.6.2驗證實踐

8.7實踐建議：著手點

8.8小結(jié)

第9章面向恢復(fù)性的設(shè)計

9.1要恢復(fù)什么

9.1.1隨機錯誤

9.1.2意外錯誤

9.1.3軟件錯誤

9.1.4惡意行為

9.2恢復(fù)機制的設(shè)計原則

9.2.1面向快速恢復(fù)的設(shè)計（受政策監(jiān)督）

9.2.2限制對外部時間觀念的依賴

9.2.3回滾所代表的安全性和可靠性間的權(quán)衡

9.2.4使用顯式吊銷機制

9.2.5了解精確到字節(jié)的預(yù)期狀態(tài)

9.2.6面向測試和持續(xù)驗證的設(shè)計

9.3緊急訪問

9.3.1訪問控制

9.3.2通信

9.3.3響應(yīng)人員的習(xí)慣

9.4預(yù)期外的收益

9.5小結(jié)

第1。章緩解拒絕服務(wù)攻擊

10.1攻守雙方的策略

10.1.1攻方的策略

10.1.2守方的策略

10.2面向防御的設(shè)計

10.2.1具有防御能力的架構(gòu)

10.2.2使服務(wù)具備防護能力

10.3緩解攻擊

10.3.1監(jiān)控與告警

10.3.2優(yōu)雅降級

10.3.3DoS防護系統(tǒng)

10.3.4有策略的響應(yīng)

10.4應(yīng)對源于服務(wù)本身的“攻擊”

10.4.1用戶行為

10.4.2客戶端重試行為

10.5小結(jié)

第三部分實現(xiàn)系統(tǒng)

第11章案例分析：設(shè)計、實現(xiàn)和維護一個受信任的公共CA

11.1受信任的公共CA的背景

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

11.3自建還是購買CA

11.4設(shè)計、開發(fā)和維護過程中的考慮

11.4.1選擇編程語言

11.4.2復(fù)雜與簡明

11.4.3保護第三方和開源組件

11.4.4測試

11.4.5CA密鑰材料的彈性

11.4.6數(shù)據(jù)驗證

11.5小結(jié)

第12章編寫代碼

12.1框架級安全性和可靠性保證措施

12.1.1使用框架的好處

12.1.2案例：用于創(chuàng)建RPC后端的框架

12.2常見安全漏洞

12.2.1SQL注入漏洞:TrustedSqlString

12.2.2預(yù)防XSS漏洞：SafeHtml

12.3評估和構(gòu)建框架的經(jīng)驗

12.3.1用于常見任務(wù)的簡單、安全、可靠的庫

12.3.2部署策略

12.4簡潔性有助于提升代碼的安全性和可靠性

12.4.1避免多層嵌套

12.4.2消除YAGNI類代碼

12.4.3償還技術(shù)債務(wù)

12.4.4重構(gòu)

12.5默認安全性和可靠性

12.5.1選擇合適的工具

12.5.2使用強類型

12.5.3檢查代碼

12.6小結(jié)

第13章代碼測試

13.1單元測試

13.1.1編寫有效的單元測試

13.1.2編寫單元測試的時機

13.1.3單元測試對代碼的影響

13.2集成測試

編寫有效的集成測試

13.3動態(tài)程序分析

13.4模糊測試

13.4.1模糊引擎的工作原理

13.4.2編寫有效的模糊測試驅(qū)動程序

13.4.3示例fuzzer

13.4.4持續(xù)模糊測試

13.5靜態(tài)程序分析

13.5.1自動代碼檢查工具

13.5.2如何將靜態(tài)分析集成至開發(fā)工作流中

13.5.3抽象解釋

13.5.4形式化方法

13.6小結(jié)

第14章部署代碼

14.1概念和術(shù)語

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可驗證的構(gòu)建

14.5.4部署阻塞點

14.5.5部署后驗證

14.6實用建議

14.6.1一步步來

14.6.2提供可操作的錯誤消息

14.6.3確保來源信息明確

14.6.4創(chuàng)建明確的策略

14.6.5引入Breakglass機制

14.7重溫基于威脅建模部署安全措施

14.8小結(jié)

第15章調(diào)查系統(tǒng)

15.1從調(diào)試到調(diào)查

15.1.1案例：臨時文件

15.1.2調(diào)試技巧

15.1.3當(dāng)陷入困境時該怎么辦

15.1.4協(xié)同調(diào)試：一種教學(xué)方法

15.1.5安全調(diào)查與系統(tǒng)調(diào)試間的差異

15.2收集恰當(dāng)、有用的日志

15.2.1將日志設(shè)計為不可變的

15.2.2考慮隱私要素

15.2.3確定要保留哪些安全相關(guān)的日志

15.2.4日志記錄成本

15.3可靠、安全的調(diào)試訪問

15.3.1可靠性

15.3.2安全性

15.4小結(jié)

第四部分維護系統(tǒng)

第16章防災(zāi)規(guī)劃

16.1“災(zāi)難”的定義

16.2動態(tài)災(zāi)難響應(yīng)策略

16.3災(zāi)難風(fēng)險分析

16.4建立事件響應(yīng)團隊

16.4.1確定團隊成員和角色

16.4.2制訂團隊章程

16.4.3建立嚴重性和優(yōu)先級模型

16.4.4確定與IR團隊合作的運營參數(shù)

16.4.5制訂響應(yīng)計劃

16.4.6創(chuàng)建詳細的行動手冊

16.4.7確保訪問和更新機制就位

16.5在事件發(fā)生前預(yù)先安排系統(tǒng)和人員

16.5.1配置系統(tǒng)

16.5.2培訓(xùn)

16.5.3流程和程序

16.6測試系統(tǒng)和響應(yīng)計劃

16.6.1審計自動化系統(tǒng)

16.6.2開展非侵入式桌面演練

16.6.3在生產(chǎn)環(huán)境中測試響應(yīng)

16.6.4紅隊測試

16.6.5評估響應(yīng)

16.7Google的案例

16.7.1具有全球影響的測試

16.7.2DiRT演習(xí)測試緊急訪問

16.7.3行業(yè)級漏洞

16.8小結(jié)

第17章危機管理

17.1是否存在危機

17.1.1事件分診

17.1.2入侵與缺陷

17.2指揮事件

17.2.1第一步：不要驚慌

17.2.2開展響應(yīng)

17.2.3組建自己的事件團隊

pSec

.4O

17.2

的利益

取更大

實踐獲

Sec

的Op

牲好

.5犧

17.2

查過程

.6調(diào)

17.2

件

控制事

17.3并行

1

17.3.移交

.2

17.3士

氣

.3

17.3通

解

注

17.4誤

1

17.4.

角

彎抹

.2拐

17.4

議

.3會

17.4

細節(jié)

合適的

人了解

合適的

.4讓

17.4

顧

整合回

17.5

診

1分

17.5.

布事件

.2宣

17.5

pSec

通和O

.3溝

17.5

事件

始處理

.4開

17.5

交

.5移

17.5

作

調(diào)查工

還事件

.6交

17.5

救

通和補

備溝

.7準

17.5

束

.8結(jié)

17.5

小結(jié)

17.6

和善后

章恢復(fù)

第18

調(diào)度

恢復(fù)

18.1

間線

恢復(fù)時

18.2

劃

恢復(fù)計

18.3

范圍

定恢復(fù)

1確

18.3.

因素

的考慮

復(fù)過程

.2恢

18.3

清單

復(fù)檢查

.3恢

18.3

復(fù)

啟動恢

18.4

產(chǎn)

離資

1隔

18.4.

升級

和軟件

統(tǒng)恢復(fù)

.2系

18.4

據(jù)過濾

.3數(shù)

18.4

復(fù)數(shù)據(jù)

.4恢

18.4

和密鑰

換憑據(jù)

.5更

18.4

后

恢復(fù)之

18.6

復(fù)盤

示例

18.7

云實例

入侵的

.1被

18.7

魚攻擊

規(guī)模釣

2大

18.7.

攻擊

對性的

、有針

作的

復(fù)工

雜恢

要復(fù)

.3需

18.7

小結(jié)

18.8

化

與文

組織

部分

第五

隊

全團

e安

hrom

究：C

例研

章案

第19

19.1背景和團隊發(fā)展史

19.2安全是團隊的職責(zé)

19.3幫助用戶安全地瀏覽Web頁面

19.4速度很重要

19.5設(shè)計縱深防御機制

19.6保持透明，讓社區(qū)參與進來

19.7小結(jié)

第20章理解角色和責(zé)任

20.1誰為安全性和可靠性負責(zé)

20.1.1專家的作用

20.1.2了解安全專業(yè)知識

20.1.3資格認證和學(xué)術(shù)教育

20.2將安全性整合到組織中

20.2.1嵌入安全人員和安全團隊

20.2.2案例：Google的嵌入式安全

20.2.3特殊的團隊：藍隊和紅隊

20.2.4外部研究者

20.3小結(jié)

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

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

21.1.1默認的安全性和可靠性文化

21.1.2評審文化

21.1.3意識文化

21.1.4說“是”的文化

21.1.5接受必然性的文化

21.1.6可持續(xù)發(fā)展文化

21.2通過最佳實踐改變文化

21.2.1對齊項目目標和激勵參與者

21.2.2通過風(fēng)險規(guī)避機制減少恐懼

21.2.3使安全兜底措施成為常態(tài)

21.2.4提高生產(chǎn)力和可用性

21.2.5多溝通，保持透明

21.2.6懷抱同理心

21.3說服領(lǐng)導(dǎo)層

21.3.1了解決策過程

21.3.2為變革立案

21.3.3選擇自己的戰(zhàn)場

21.3.4升級和問題解決

21.4小結(jié)

總結(jié)

附錄災(zāi)難風(fēng)險評估矩陣

第一部分入門資料

如果你邀請用戶寫H1其最喜愛的產(chǎn)品特性，他們的清單基本不可能以安全性和可靠性開始。這

兩個特性通常隱藏在他們的預(yù)期中，當(dāng)產(chǎn)品運行良好時，用戶就不會注意到它們。

我們相信，安全性和可靠性應(yīng)該是每個組織的頭等大事。歸根結(jié)底，幾乎沒有用戶想使用一個

既不可靠乂不安全的產(chǎn)品，因此這些方面提供了差異化的業(yè)務(wù)價值。

本書的第一部分重點介紹對于一個系統(tǒng)來說，安全性和可靠性的基礎(chǔ)實踐中存在的大量重合項,

以及在它們之間需要面臨的權(quán)衡。我們?yōu)槟闾峁┝藨?yīng)對潛在對手的高級指導(dǎo)：他們可能的行為

及其行為對系統(tǒng)生命周期可能產(chǎn)生的影響。

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

撰寫人：AdamStubblefield^MassimilianoPoletto>PiotrLewandowski

DavidHuska和BetsyBeyer

1.1從密碼和電鉆談起

2012年9月27日，Google發(fā)布的一份內(nèi)部公告導(dǎo)致了一系列的服務(wù)故障。最終，一把電

鉆排除了這些故障。

Google有一個內(nèi)部密碼管理系統(tǒng)，用于員工存儲密碼，以及與不具備更高級身份驗證機制的

第三方服務(wù)進行機密共享。存儲密碼之一就是連接Google舊金山灣區(qū)各園區(qū)的公交車上的訪

客Wi-Fi密碼。

在9月27日那天，運輸團隊通過電子郵件向數(shù)千名員工發(fā)布了Wi-Fi密碼已更改的公告，

最終導(dǎo)致流量遠遠超過了密碼管理系統(tǒng)（該密碼管理系統(tǒng)是幾年前為一小部分系統(tǒng)管理員開發(fā)

的）所能承受的峰值。

過載流量導(dǎo)致密碼管理系統(tǒng)的主服務(wù)無法響應(yīng)，因此負載均衡器將流量牽引到備份服務(wù)，結(jié)果

備機也立即過載。此時，系統(tǒng)向值班工程師發(fā)出告警，而該工程師沒有響應(yīng)服務(wù)失敗的經(jīng)驗：

密碼管理系統(tǒng)有良好的運行基礎(chǔ)，并且在其存在的5年中從未遭受過停機。該工程師嘗試重

新啟動服務(wù)，但不知道重新啟動需要硬件安全模塊（HSM）智能卡。

這些智能卡存儲在全球各地的Google辦事處的多個保險箱中，但不在值班工程師所在的紐約

市。當(dāng)服務(wù)無法重啟時，該工程師聯(lián)系了澳大利亞的一位同事，想取回智能卡。令人沮喪的是，

澳大利亞的工程師無法打開保險箱，因為密碼存儲在離線的密碼管理器中。幸運的是，加利福

尼亞的另一位同事將該密碼記錄在了在線保險箱中，并且能夠取回智能卡。但是，即使加利福

尼亞的工程師將卡插入讀卡器，該服務(wù)仍然因密碼錯誤而無法重啟：“密碼無法加載任何保護

此密鑰的卡。”

澳大利亞的工程師認為應(yīng)該用蠻力解決他們的安全問題，因此用起了電鉆。一小時后，保險箱

打開了，但即便是剛?cè)』氐目ㄒ灿|發(fā)了相同的錯誤消息。

團隊花了一個多小時才意識到，智能卡讀取器上的綠燈實際上并不表示該卡已正確插入。當(dāng)工

程師將卡翻轉(zhuǎn)過來時，服務(wù)重啟成功，故障排除了。

可靠性和安全性都是一個真正值得信賴的系統(tǒng)的關(guān)鍵組成部分，但要構(gòu)建既可靠又安全的系統(tǒng)

是很困難的。盡管對可靠性和安全性的要求具有許多共性，但設(shè)計它們時也有不同的注意事項。

忽視可靠性和安全性之間的微妙關(guān)系很容易引起意外的結(jié)果。密碼管理系統(tǒng)的故障是由可靠性

問題（失效的負載均衡和過載保護策略）觸發(fā)的，而提高系統(tǒng)安全性的多種措施使恢復(fù)密碼管

理系統(tǒng)變得復(fù)雜。

安全與隱私的交集

安全與隱私是密切相關(guān)的概念。系統(tǒng)為了尊重用戶隱私，必須從根本上是安全的，并且在對手

面前表現(xiàn)得與預(yù)期相同。同樣，一個完善的安全系統(tǒng)如果不尊重用戶隱私，就不能滿足許多用

戶的需求。雖然本書關(guān)注的是安全性，但描述的一些方法通常也用于實現(xiàn)隱私保護。

1.2可靠性與安全性：設(shè)計注意事項

在設(shè)計可靠性和安全性時，必須考慮不同的風(fēng)險?？煽啃悦鎸Φ闹饕L(fēng)險往往是非惡意的，例

如軟件更新失敗或物理設(shè)備故障，而安全風(fēng)險來自主動嘗試利用系統(tǒng)漏洞的對手。在設(shè)計可靠

性時，你會假設(shè)某些地方在某些時候會出錯；在設(shè)計安全性時，你必須假設(shè)有人隨時隨地蓄意

搞破壞。

因此，不同的系統(tǒng)在故障響應(yīng)的設(shè)計上也完全不同。在沒有破壞者的情況下，系統(tǒng)通常會在故

障發(fā)生時默認放過（或默認打開），例如電子鎖默認在斷電時保持打開狀態(tài)，允許人們安全進

出。在故障發(fā)生時默認放過/打開的設(shè)計可能導(dǎo)致明顯的安全漏洞。為了防御可能利用電源故

障的人，可以將門設(shè)計為在故障發(fā)生時默認保護，并在不通電時保持關(guān)閉狀態(tài)。

可靠性與安全性的權(quán)衡：冗余

在沒計可靠性時，通常需要向系統(tǒng)添加冗余。舉例來說，許多電子鎖在斷電時會默認保護，但

會允許使用物理鑰匙。同樣，火災(zāi)逃生通道為緊急情況提供了冗余的出口。盡管冗余提高了可

靠性，但也增加了攻擊而。龍抗方只需在一條路徑上找到漏洞即可成功。

可靠性與安全性的權(quán)衡：事件管理

攻擊者的存在還會影響協(xié)作方法以及事件發(fā)生時響應(yīng)者可以使用的信息?？煽啃允芤嬗趽碛卸?/p>

角度的響應(yīng)者，它們可以協(xié)助快速發(fā)現(xiàn)問題的根本原因并解決問題。相比之下，通常在處理安

全事件時更希望將解決問題的人員最少化，使對手無法獲得相關(guān)消息。在安全事件中，以按需

共享的原則來分享信息。同樣，海量的系統(tǒng)日志有助于為事件響應(yīng)提供信息支撐，并縮短恢復(fù)

所需事件的時間，但根據(jù)記錄的內(nèi)容不同，日志也可能成為攻擊者的重要目標。

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

安全性和可靠性都與系統(tǒng)的機密性、完整性和可用性有關(guān)，但它們針對這些因素的考慮角度不

同。兩者之間的關(guān)鍵差異在于是否存在惡意的對手?？煽康南到y(tǒng)一定不會出現(xiàn)違背機密性的問

題，例如出錯的聊天系統(tǒng)可能存在錯發(fā)、亂碼或丟失消息的情況。此外，安全的系統(tǒng)必須防止

惡意訪問、篡改或破壞機密數(shù)據(jù)。通過下面的例子來看看可靠性問題是如何導(dǎo)致安全問題的。

K在傳統(tǒng)定義中，機密性、完整性和可用性一直被視為安全系統(tǒng)的基本屬性，叫作CIA1三

要素。盡管很多模型基于CIA擴展了安全屬性，但C1A三要素長期以來仍受歡迎。雖然首字

母縮寫一樣，但這個概念與美國中央情報局沒有任何關(guān)系。

11此處的CIA是指confidentiality（機密性）、integrity（完整性）和availability（可用性）。編者注

1.3.1機密性

在航空業(yè)中，一個明顯的機密性問題是一鍵通按鈕卡在了發(fā)聲位置。在一些有據(jù)可查的案例中，

卡住的麥克風(fēng)按鈕廣播了飛行員之間的私人對話，這明顯違反了機密性。在這種情況下，并不

存在惡意攻擊者，而是硬件可靠性缺陷導(dǎo)致設(shè)備在非飛行員預(yù)期的情況下傳遞了信息。

1.3.2完整性

同樣，數(shù)據(jù)完整性被破壞也不一定涉及攻擊者。2015年，Google網(wǎng)站可靠性工程師注意到,

端到端加密的完整性檢查在一些數(shù)據(jù)塊上出現(xiàn)了失敗的情況。處理數(shù)據(jù)的某些機器存在無法糾

正的內(nèi)存錯誤，因此網(wǎng)站可靠性工程師決定改寫程序，通過按位取反（0和1互換）操作徹

底檢查計算每個數(shù)據(jù)版本的完整性。這樣一來，他們才能知道結(jié)果是否與原始完整性檢查的值

相匹配。事實證明，所有錯誤實際上都是按位取反導(dǎo)致的，后續(xù)網(wǎng)站可靠性工程師恢復(fù)了所有

數(shù)據(jù)。有趣的是，這是一個在完整性故障中采用安全技術(shù)來恢復(fù)的實際案例。（Google的存

儲系統(tǒng)使用的是非加密的端到端完整性檢查，但因為一些其他因素，SRE團隊沒有發(fā)現(xiàn)按位取

反的故障。）

L3.3可用性

最后一點，可用性顯然既關(guān)乎可靠性，又關(guān)乎安全性。攻擊者可能會利用系統(tǒng)漏洞，使系統(tǒng)停

止運行或阻止已授權(quán)用戶的使用?；蛘撸粽呖赡軙刂品植荚谑澜绺鞯氐拇罅吭O(shè)備來發(fā)動

經(jīng)典的分布式拒絕服務(wù)（distributeddenial-of-service,DDoS）攻擊，利用這些設(shè)備向受

害者發(fā)送大量請求。

拒絕服務(wù)（denial-of-service,DoS）攻擊很有趣，這是因為它橫跨可靠性領(lǐng)域和安全性領(lǐng)域。

從受害人的視角來看，很難區(qū)分惡意攻擊流量與設(shè)計缺陷或合理上升帶來的峰值流量。舉個例

子，2018年的一次軟件更新導(dǎo)致一些GoogleHome設(shè)備和Chromccast設(shè)備在調(diào)整時鐘時產(chǎn)

生了巨大的網(wǎng)絡(luò)流量，進而導(dǎo)致Google的中央時間服務(wù)出現(xiàn)了非預(yù)期的流量峰值。與之類似,

重大的突發(fā)新聞或事件會使得數(shù)百萬人發(fā)出幾乎相同的查詢，這看起來很像傳統(tǒng)的應(yīng)用級

DDoS攻擊。如圖1-1所示，2019年10月的一個深夜，舊金山灣區(qū)發(fā)生了4.5級地震，該

地區(qū)的Google基礎(chǔ)設(shè)施服務(wù)接收到大量查詢流量。

:?)

二

E-

L

L

一

五

工

y

20:00203021:00213022：002230

圖1-1：2019年10月14日，舊金山灣區(qū)發(fā)生4.5級地震時，該地的Google基礎(chǔ)設(shè)施

服務(wù)接收到的Web流量（以每秒HTTP請求量計算）

1.4可靠性與安全性：共性

與許多系統(tǒng)特性不同，可靠性和安全性是系統(tǒng)設(shè)計中的突出屬性。這兩點都很難在事后再加固,

因此理想情況下，在設(shè)計的初期階段就應(yīng)該將兩者都考慮在內(nèi)。系統(tǒng)變更過程中很容易無意中

影響到這兩點，因此需要在整個系統(tǒng)生命周期中持續(xù)關(guān)注和測試它們。在復(fù)雜的系統(tǒng)中，很多

組件會影響到安全性和可靠性，一個看似不經(jīng)意的更新可能對整個系統(tǒng)的安全性或可靠性造成

影響，而這種影響在事故發(fā)生前可能并不明顯。讓我們通過更多細節(jié)來研究這些共同點。

1.4.1隱形

當(dāng)系統(tǒng)運行一切正常時，可靠性和安全性幾乎是隱形的，但可靠性和安全性團隊的目標之一是

贏得并保持客戶和合作伙伴的信任。無論是出現(xiàn)問題時，還是在進展順利的情況下，良好的溝

通都是這種信任的堅實基礎(chǔ)。溝通中應(yīng)該開誠布公、細致入微，并且避免套話和行話，這非常

重要。

不幸的是，在沒有緊急情況的時候，可靠性和安全性的隱形意味著它們通常被視為可以減少或

推遲也不會立即造成嚴重后果的成本，但它們失效時帶來的損失可能很嚴重。據(jù)媒體報道，可

能因為數(shù)據(jù)泄露事件的出現(xiàn)，2017年威瑞森收購雅虎的互聯(lián)網(wǎng)業(yè)務(wù)的價格降低了3.5億美元。

同一年，斷電事件導(dǎo)致達美航空的核心系統(tǒng)停機，造成近700架航班取消和數(shù)千次的航班延

誤，使達美當(dāng)天的航班吞吐量減少了將近60%。

1.4.2評估

因為實現(xiàn)絕對可靠性或安全性的想法是不切實際的，所以可以從實際風(fēng)險出發(fā)來評估負面事件

帶來的成本，以及預(yù)防這些事件的前期成本和機會成本。但是，對于可靠性和安全性，應(yīng)該以

不同的方式衡量負面事件的可能性。我們可以推導(dǎo)出系統(tǒng)組成的可靠性，并根據(jù)所需的錯誤預(yù)

算2來計劃工程工作。其中至少一部分可以這樣，因為我們可以假設(shè)各個組件之間的故障是

無關(guān)的。而組合的安全性就更難評估了。通過分析系統(tǒng)的設(shè)計和實現(xiàn)，可以提供一定程度的保

證。攻防演練（以攻擊者的角度開展測試）也可以用于評估系統(tǒng)對特定攻擊類型的抵抗力、攻

擊檢測機制的有效性以及受到攻擊的潛在后果。

2有關(guān)錯誤預(yù)算的更多信息，請參閱＜SRE：Google運維解密》中的第3章。

1.4.3簡潔性

使系統(tǒng)設(shè)計盡可能精簡，是提高對系統(tǒng)可靠性和安全性的評估能力的最佳方法之一。較簡單的

設(shè)計縮小了攻擊面，減少了系統(tǒng)非預(yù)期交互的可能性，并使系統(tǒng)更容易被理解。在緊急情況下，

可理解性尤其有用，它可以幫助響應(yīng)者快速解決問題并減少平均修復(fù)時間（MTTR）。第6章

將洋細闡釋該主題，并討論相關(guān)策略，例如將攻擊面最小化，以及將安全不變量的權(quán)責(zé)劃分到

簡單的、獨立運行的子系統(tǒng)中，以便于獨立地推理“

1.4.4演變

無論初始設(shè)計多么簡潔和優(yōu)雅，系統(tǒng)極少情況下會保持長久不變。添加新功能、改變規(guī)模以及

底層基礎(chǔ)設(shè)施的演進都會讓系統(tǒng)變得復(fù)雜。在安全方面，跟進不斷發(fā)展的攻擊手法和新攻擊者

的需求也會使系統(tǒng)變得復(fù)雜。此外，滿足市場需求的壓力也會導(dǎo)致系統(tǒng)開發(fā)人員和維護人員走

捷經(jīng)，從而積攢技術(shù)債務(wù)。第7章討論了其中一些挑戰(zhàn)。

復(fù)雜性通常會在不經(jīng)意間積累起來，這可能會導(dǎo)致系統(tǒng)到達臨界點。在這種情況下，一個看起

來無關(guān)緊要的微小變更就會走系統(tǒng)的可靠性或安全性產(chǎn)生重大影響。DebianGNU/Linux版本

的OpenSSL庫就出現(xiàn)過一個因微小變更而導(dǎo)致重大故障的案例：2006年引入的一個錯誤，在

將近兩年后才被發(fā)現(xiàn)。一位開源研發(fā)人員注意到Valgrind（一款調(diào)試內(nèi)存問題的標準工具）

報告了一個問題：內(nèi)存使用前未進行初始化。為了消除警告，研發(fā)人員刪除了兩行代碼。不幸

的是，這導(dǎo)致OpenSSL的偽隨機數(shù)生成器只使用進程：D作為隨機種子，而在Debian系統(tǒng)

中，該1D當(dāng)時默認在廣32768范圍內(nèi)取值，因此可以很輕易地通過暴力破解獲取加密密鑰。

Google也同樣無法幸免。例如，2018年10月，YouTube在全球范圍內(nèi)停機了超過一小時，

起因是通用日志庫里的一個小變更。該變更的目的是提升事件日志的細粒度，在其作者和指定

的代碼審閱者看來都沒有問題，并且通過了所有測試。然而，其開發(fā)者完全沒有意識到在

YouTube的業(yè)務(wù)規(guī)模下會產(chǎn)生的影響：在生產(chǎn)環(huán)境的負載下，這個變更導(dǎo)致YouTube的服務(wù)

器快速地耗盡內(nèi)存并崩潰。當(dāng)用戶的流量轉(zhuǎn)移到其他正常的服務(wù)器時，級聯(lián)故障導(dǎo)致整個服務(wù)

都停止了。

1.4.5彈性

當(dāng)然，一個內(nèi)存利用率問題不應(yīng)該引起全局的服務(wù)中斷°系統(tǒng)應(yīng)在非預(yù)期情況下具有彈性。從

可靠性角度來看，這種情況通常是因預(yù)期外的高負載或者組件故障而導(dǎo)致的。負載是系統(tǒng)請求

數(shù)量和平均開銷組合而成的，因此可以通過減少負載量（減少執(zhí)行）或者減少每個請求的平均

開銷（執(zhí)行成本更低）來實現(xiàn)彈性。為了定位組件故障，系統(tǒng)設(shè)計應(yīng)該包括冗余和不同的故障

域，以便通過重新路由請求來限制降低故障的影響。第8章將進一步討論這些話題，第10章

將特別深入探討DoS緩解措施。

無論一個系統(tǒng)的各個組件具有多大的彈性，一旦變得足夠復(fù)雜，就難以保證整個系統(tǒng)不受傷害，

但可以通過縱深防御和故障域來解決這個問題?？v深防御是多種防御機制的集合（有時候是冗

余）。獨立故障域限制了故障的“爆炸半徑”，因此也提高了可靠性。良好的系統(tǒng)設(shè)計會限制

攻擊者利用淪陷的主機或者盜取的憑證進行橫向移動或是提權(quán)，進而影響系統(tǒng)的其他部分。

你可以通過劃分權(quán)限或者限制憑證的可用范圍來實現(xiàn)不同的故障域。舉個例子，Google內(nèi)部

基礎(chǔ)設(shè)施所支持的憑證明確地限定了地理區(qū)域。這類特性可以限制攻擊者向其他區(qū)域服務(wù)器橫

向移動的能力（如果已經(jīng)掌控了一個區(qū)域的服務(wù)器）。

對敏感數(shù)據(jù)使用獨立的加密層是深度防御的另一種常見機制。舉個例子，即使磁盤提供了設(shè)備

級前密，在應(yīng)用程序?qū)右布用軘?shù)據(jù)通常是個好主意。這樣，假設(shè)攻擊者獲取通過物理方式訪問

存儲設(shè)備的方法，即使驅(qū)動控制器中的加密算法實現(xiàn)有缺陷，也不足以危及受保護數(shù)據(jù)的機密

性。

雖然目前為止引用的例子都來自外部攻擊者，但內(nèi)部惡意人員的潛在威脅也是需要考慮的。盡

管內(nèi)部人員可能比第一次竊取員工憑證的外部攻擊者更了解潛在的突破點，但在實踐中這兩種

情況通常沒有太大區(qū)別。最小特權(quán)原則可以緩解內(nèi)部的威脅。它規(guī)定用戶只能在指定時間范圍

內(nèi)擁有工作所需的最小權(quán)限集。舉個例子，UNIX的sudo機制支持細粒度的策略，用以指定

哪些用戶可以作為什么角色來運行哪些命令。

在Google,我們還使用多方授權(quán)來確保敏感操作由特定的員工組來審批。這種多方機制既能

防御內(nèi)部惡意人員，又能降低人為錯誤的風(fēng)險（可靠性故障的常見原因）。最小特權(quán)和多方授

權(quán)不是新鮮事物，它們已經(jīng)為很多非計算機的場景所應(yīng)用，大到核導(dǎo)彈發(fā)射井，小到銀行金庫。

第5章將深入討論這些概念。

1.4.6從設(shè)計到生產(chǎn)

將一個可靠設(shè)計轉(zhuǎn)化為完整部署的生產(chǎn)系統(tǒng)的過程中，要一直考慮安全性和可靠性。從代碼開

發(fā)開始，就有機會通過代碼審閱來發(fā)現(xiàn)潛在的安全性和可靠性問題，甚至可以通過使用公共框

架和庫來防止產(chǎn)生問題。第12章探討了這方面的技術(shù)。

在部署系統(tǒng)之前，可以用測試來確保它的功能在正常情況下和邊緣情況（通常會影響可靠性和

安全性）下都能正常工作。無論是使用負載測試來了解系統(tǒng)在大量查詢下的行為，或是使用模

糊測試來探索潛在的非預(yù)期輸入后的表現(xiàn)，抑或使用特定的測試來確認加密庫是否會泄露信息,

測試都在其中發(fā)揮著關(guān)鍵作用，以確保實際構(gòu)建的系統(tǒng)符合設(shè)計意圖。第13章深入介紹了這

些方法。

最后，一些實際部署代碼的方法(參見第14章)可以控制安全性和可靠性的風(fēng)險。例如，金

絲雀測試和緩慢部署可以防止系統(tǒng)崩潰并波及所有用戶。同樣，如果部署系統(tǒng)只接受經(jīng)過合理

審閱的代碼，則將有助于降低內(nèi)部人員將惡意二進制文件發(fā)布至生產(chǎn)環(huán)境的風(fēng)險。

1.4.7調(diào)查系統(tǒng)和日志

到目前為止，我們都將重點放在了防止可靠性和安全故障的設(shè)計原則和實現(xiàn)方法上。不幸的是,

想要達到完美的可靠性和安全性，成本通常很高，因此不切實際。我們必須假設(shè)預(yù)防機制有失

敗的可能，因此需要制訂計劃來檢測故障并從故障中恢復(fù)。

將如第15章所述，完善的日志記錄是檢測和防備故障的基礎(chǔ).一般來說，日志越完整詳細就

越好，但這個準則有些注意事項。在足夠大的規(guī)模下，大量日志會帶來很大的成本，并且會給

分析日志造成困難。前文中提到的YouTube案例說明E志也會導(dǎo)致可靠性問題。安全日志還

帶來了額外的挑戰(zhàn)：日志通常不應(yīng)該包含認證憑證或個人身份信息(personallyidentifiable

information,PH)等敏感信息，以免日志本身成為使攻擊者感興趣的目標。

1.4.8危機響應(yīng)

在緊急情況下，團隊必須快速而順利地協(xié)作，否則可能立即出現(xiàn)不良后果。在最壞的情況下，

一個事件可能在幾分鐘內(nèi)毀掉一家企業(yè)。例如，2014年，一名攻擊者接管了代碼托管服務(wù)Code

Spaces的管理端工具，然后刪除了該服務(wù)的所有數(shù)據(jù)，包括所有備份，導(dǎo)致該服務(wù)在幾小時

內(nèi)完全不可用。這些情況下都需要及時響應(yīng)，而精心排練過的協(xié)作和良好的事件管理就顯得尤

為重要了。

組織危機響應(yīng)非常有挑戰(zhàn)性，所以最好是在緊急情況發(fā)生之前就制訂好響應(yīng)計劃。發(fā)現(xiàn)事件是

需要時間的。在任何情況下，響應(yīng)人員都是在壓力和時間緊迫的情況下操作的，并且(至少在

剛開始時)對情況的認知有限。如果組織規(guī)模較大，同時事件需要24小時響應(yīng)或者跨時區(qū)協(xié)

作、跨團隊維護和班次間事件管理交接，就會導(dǎo)致操作進一步的復(fù)雜化。安全事件通常會存在

矛盾：一方面想讓各個關(guān)鍵方都參與進來；另一方面，通常法律和監(jiān)管要求限制信息只能在必

要知曉時才能共享。而且，最初的安全事件可能只是冰山一角。調(diào)查可能超出公司范圍，或者

涉及執(zhí)法機構(gòu)。

在危機期間，至關(guān)重要的是一個清晰的指揮鏈以及一套堅實的檢查清單、行動手冊和協(xié)議。將

如第16章和第17章所述，Google己經(jīng)將危機響應(yīng)轉(zhuǎn)化成名為“Google事件管理”

(IncidentManagementatGoogle,TMAG)的程序,包含處理各類事件的標準化方法(無論

是系統(tǒng)中斷，還是自然災(zāi)害)，并組織有效的響應(yīng)。IMAG是基于美國突發(fā)事件指揮系統(tǒng)

(IncidentCommandSystem,ICS)模型建立的,這是一種用于指揮、控制和協(xié)調(diào)多個政府機

構(gòu)的應(yīng)急人員的標準化方法。

當(dāng)沒有面臨持續(xù)事件的壓力時，應(yīng)急人員通常會有大段的空白時間，沒有行動。在這些時間段

里,團隊需要保持個人技能和行動的敏銳性，并改進流程和基礎(chǔ)設(shè)施,為下一次的應(yīng)急做準備。

Google的災(zāi)難恢復(fù)測試系統(tǒng)(DisasterRecoveryTestingprogram,DiRT)會定期模擬各種

內(nèi)部系統(tǒng)故障，迫使團隊去應(yīng)付這些場景。頻繁地攻擊性安全演習(xí)能測試防御能力，并有助于

識別新的漏洞。Google甚至在小事件中也使用IMAG,這進一步促使我們定期使用應(yīng)急工具和

流程。

1.4.9恢復(fù)

從安全事故中恢復(fù)，通常需要為了修復(fù)漏洞而打補丁。直覺上，你希望使用非?？煽俊⒔?jīng)常運

行的機制讓該過程盡快流轉(zhuǎn)。然而，快速推送變更的能力是一把雙刃劍：雖然此功能可以幫助

快速關(guān)閉漏洞，但它也可能引入錯誤或性能問題，從而造成大量破壞。如果漏洞廣為人知或風(fēng)

險嚴重，則快速推送補丁的壓力更大。推動修復(fù)程序的節(jié)奏究竟是快還是慢（緩慢推進時確保

無副作用，但漏洞就存在被利用的風(fēng)險），最終歸結(jié)為風(fēng)險評估和業(yè)務(wù)決策。例如，通過降低

某些性能或增加資源使用量來修復(fù)嚴重漏洞或許是可以接受的。

這樣的選擇強調(diào)了需要可靠的恢復(fù)機制，使我們能夠在不影響可靠性的情況下快速推出必要的

變更，并且還可以在潛在問題導(dǎo)致大范圍故障之前發(fā)現(xiàn)這些問題。例如，穩(wěn)健的艦隊恢復(fù)系統(tǒng)

需要可靠地表示每臺機器的當(dāng)前和所需狀態(tài)，還需要提供備份，以確保狀態(tài)永遠不會回滾到過

時或不安全的版本。第9章將介紹該方法及同類方案，第18章將討論在事件發(fā)生后如何實

際恢復(fù)系統(tǒng)。

1.5小結(jié)

安全性和可靠性有很多共同之處一一它們都是所有信息系統(tǒng)的固有屬性，最初很容易成為換取

更快速度的代價，而事后則需要高昂的修復(fù)成本。本書旨在幫助你在系統(tǒng)增長過程中，盡早解

決與安全性和可靠性相