很久以前，Jerry Saltzer和Michael Schroeder發(fā)表了一篇論文，題為“計算機系統(tǒng)中的信息保護”，該論文的第三部分提供了信息安全的一些基本設計原則。人們都說，他們給安全界帶來啟發(fā)式的影響，其實不僅如此，在近40年后的今天，他們早在1975年提出的原則仍然實用。

在新年開始之際，筆者建議你在設計新系統(tǒng)時采用這13個原則。雖然13并不認為是吉利的數(shù)字，但筆者相信，當你將這些原則在企業(yè)中付諸實踐時，將會給你帶來好運氣。

13條安全設計原則

1）保護最薄弱環(huán)節(jié)–-Spaf（即備受推崇的普渡大學安全專家Gene Spafford）通過一個有趣的故事來說明這個原則。試想一下，你需要負責把睡在公園長椅上的無家可歸的人（我們稱他為Linux）的財產運送給另一個無家可歸的女人（我們稱她為Android），你租用了一輛裝甲卡車來運送，運輸公司的名稱是“Applied Crypto, Inc.”。現(xiàn)在，假設你是準備竊取財產的攻擊者，你是會攻擊Applied Crypto卡車、無家可歸的人Linux還是無家可歸的女人Android？很容易做出選擇吧？（提示：答案是，“除了卡車以外”）

筆者及其合著者John Viega在2001年撰寫的《構建安全軟件》一書中寫道，“安全從業(yè)者經常指出，安全就像一根鏈條，鏈條的強弱取決于其最薄弱的環(huán)節(jié)，同樣的道理，軟件安全系統(tǒng)的安全性也取決于其最薄弱的組件。”攻擊者往往會尋找系統(tǒng)中最薄弱的地方，而最薄弱的地方很少會是某個安全功能或特性。當涉及到安全設計時，一定要考慮你的系統(tǒng)中最薄弱的環(huán)節(jié)，確保它是足夠安全的。

2）深度防御–筆者和Kenneth van Wyk喜歡將這個稱為“腰帶和吊襪帶”的方法。在安全領域，冗余和分層通常是好事。不要指望你的防火墻來阻止所有惡意流量；同時還應該使用入侵檢測系統(tǒng)。如果你正在設計一個應用，通過安全冗余和防御層來防止單點故障。《構建安全軟件》中提到：“深度防御背后的概念是管理不同防御策略的風險，這樣的話，即使某個防御層無法提供足夠的安全性，另一個防御層將有可能防止數(shù)據(jù)泄露。”這是信息安全專家普遍認同的概念，理由很簡單：它有用。

3）保證失效后的安全性—請確保你設計的系統(tǒng)不會在失效后保持“開放”。關于這個原則，筆者最喜歡的故事是命運多舛的Microsoft Bob產品（Bob是Clippy回形針的前身），據(jù)傳說，如果你三次嘗試輸入用戶名和密碼失敗后，Bob將會詢問你是否要選擇使用一個新密碼，感謝Bob（攻擊者說）！很顯然，在這種情況下，更好的默認設置應該是拒絕訪問。

《構建安全軟件》中提到：“任何足夠復雜的系統(tǒng)都會失效，失效是不可避免的，企業(yè)應該提前做好準備?？梢员苊獾氖桥c失效相關的安全問題。但問題是，當很多系統(tǒng)以任何方式失效時，它們都會表現(xiàn)出不安全行為。”

4）最小特權—當你需要為用戶或進程授予權限來完成一些操作，盡可能授予最小的權限。想想你的Outlook聯(lián)系人列表，如果你需要別人訪問你的聯(lián)系人列表來查看一些數(shù)據(jù)，授予他們讀者權限，但不要授予編輯權限。這有一個更專業(yè)的例子：系統(tǒng)的大多數(shù)用戶的日常工作并不需要根級權限，所以不要授予他們根級權限。底線是，避免無意的、不必要的或不正確的權限使用，以“吝嗇”的方式來授予權限。

5）獨立權限—筆者曾經看到一個系統(tǒng)將其認證前端劃分成大量角色，這些角色對系統(tǒng)有不同程度的訪問。問題是，當任何角色的用戶需要執(zhí)行后端數(shù)據(jù)庫操作時，該軟件會臨時授予每個用戶管理員權限。這樣做并不好，即使是最底層的實習生也可以侵入數(shù)據(jù)庫。要知道，如果攻擊者可以騙取一個權限，而無法得到第二個權限時，他將無法成功發(fā)起攻擊。所以保持權限的分離。

6）經濟機制—復雜性是安全工程的敵人，卻是攻擊者的朋友。無論是從設計的角度來看，還是從部署的角度來看，在復雜的系統(tǒng)中，很容易將事情“搞砸”。具有諷刺意味的是：想看看復雜的東西嗎？只要看一看現(xiàn)代企業(yè)軟件的任何一部分。

盡可能保持事物簡單。《構建安全軟件》中提到，“KISS的口頭禪眾所周知：‘保持簡單，保持愚蠢?。↘eep It Simple, Stupid!）’這個說法同樣適用于安全領域及其他任何領域。復雜性增加了問題的風險，避免復雜性，就是避免問題。”

7）不要共享機制—你是否應該將面向內部的業(yè)務應用放在公共云中？根據(jù)這條原則，最好不要。你可以將你的身份驗證系統(tǒng)限制為你信任的員工，為什么讓你的系統(tǒng)處理隨機互聯(lián)網流量呢？

還有一個專業(yè)的例子：如果你有多個用戶使用相同的組件，讓你的系統(tǒng)為每個用戶創(chuàng)建不同的實例。不共享用戶之間的對象和訪問機制，可以減少安全故障的可能。

8）不要輕易信任—假設你的系統(tǒng)運行的環(huán)境處于不利條件，不要讓所有人都能調用你的API，當然也不要讓所有人能夠訪問你的機密信息。如果你依賴于云組件，你需要對其進行檢查，以確保它沒有被欺騙或者受到感染。預防命令注入、跨站腳本等攻擊。在《構建安全軟件》中，“最后一點要記住的是，信任是可傳遞的，當你給出信任時，你往往會將這種信任擴展到你信任的實體所信任的對象上。”

9）假設你的機密信息并不安全—安全不能“含糊其辭”，特別是當涉及存儲在你的代碼中的秘密信息時。假設攻擊者能夠找出關于你的系統(tǒng)盡可能多的信息，甚至可能超過超級用戶。攻擊者的工具包有反編譯器、反匯編器以及很多分析工具。假設他們瞄準了你的系統(tǒng)，他們怎么查看二進制碼中的加密密鑰？函數(shù)掃描會讓加密密鑰呼之欲出，畢竟二進制只是一種語言。

10）徹底檢查--企業(yè)應該對每次訪問和每個對象進行檢查。請確保你的訪問控制系統(tǒng)是全面的，適應當今這個多線程世界的。不管你做什么，如果更改系統(tǒng)權限，請確保對訪問進行了系統(tǒng)化的重復檢查。不要緩存授權或使用權的結果。在充滿大規(guī)模分布式系統(tǒng)和多處理器計算機的世界，這條原則非常重要。

11）使安全可用—如果你的安全機制太繁瑣，你的用戶會想盡辦法規(guī)避或避免它們。請確保你的安全系統(tǒng)足夠安全，但也不要“過頭”。如果你深深地影響了可用性，沒有人會使用你的東西，不管它多么安全。雖然它非常安全，但同時也非常沒用。Spaf經常會笑話據(jù)稱是世界上最安全的系統(tǒng)，即系統(tǒng)硬盤消磁，被埋在填滿混泥土的30英尺的圍繞法拉第電網的洞里。這樣的系統(tǒng)肯定很難使用。

12）保護隱私--大家都在談論保護隱私，但大多數(shù)人實際上沒有做任何相關事情。你可以幫助解決這個問題。當你設計一個系統(tǒng)時，考慮一下最終用戶的隱私。你收集個人識別信息（PII）只是因為市場部有人要求這樣做嗎？這樣做好嗎？你是將PII存儲在可能受到破壞的地方嗎？難道不應該對這些信息進行加密嗎？信息安全從業(yè)人員并不需要提供對這些隱私問題的答案（這是首席信息官的工作），但如果沒有其他人提出這類問題，你需要提出。

13）使用你的資源—正如筆者14歲時在童軍領導培養(yǎng)課程中學到的那樣，“使用你的資源”這條原則具有令人難以置信的廣泛應用范圍。如果你不確定你的系統(tǒng)設計是否安全，請尋求幫助。架構風險分析很難，但有些人已經做了幾十年。如果你做不到的話，最好不要嘗試單獨操作。不要羞于尋求幫助，這件事情非常復雜。

借用別人的好點子

筆者永遠都不會忘記在硅谷的HSARPA會議演示軟件安全幻燈片的那天。這個幻燈片是基于筆者的《構建安全軟件》一書中的內容，該書有一章是圍繞這些安全原則。其中一張幻燈片是Saltzer和Schroeder的圖譜，你猜誰正好坐在觀眾席中？正是Michael Schroeder本人，他贊揚了這個幻燈片，這個世界確實很小。Saltzer和Schroeder在1975年是正確的，當我們在撰寫《構建安全軟件》的今天仍然是正確的。將他們的原則應用到2013年的安全工作中，不要害怕使用別人想出的好想法。