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

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

13條安全設計原則

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

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

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

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

《構建安全軟件》中提到：“任何足夠復雜的系統都會失效，失效是不可避免的，企業應該提前做好準備。可以避免的是與失效相關的安全問題。但問題是，當很多系統以任何方式失效時，它們都會表現出不安全行為。”

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

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

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

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

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

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

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

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

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

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

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

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

借用別人的好點子

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