讀軟體開發安全之道：概念、設計與實施09安全設計

1. 安全設計

1.1. 過載、混亂和迷惑性並不是資訊的屬性，而是設計的失敗。

• 1.1.1. 愛德華·塔夫特

1.2. 不應該將系統的安全性留給審查員進行修補

• 1.2.1. 審查員應該在對設計進行審查時，將威脅和緩解作為安全評估的附加

• 1.2.2. 小型企業的運營通常不會那麼正式，並且設計師和審查員可能是同一個人

2. 在設計中整合安全性

2.1. 設計階段為將安全原則和模式應用到軟體專案中提供了絕佳的機會

• 2.1.1. 在設計階段，開發者應該建立開發文件，以便明確一個軟體專案的高層級特徵，類似於一個架構藍圖

• 2.1.2. 設計文件中通常包含功能描述（從外部審查軟體是如何工作的）和技術規範（從內部審查軟體是如何工作的）​

2.2. 經驗豐富的設計師會從一開始就將安全性納入設計方案之中

• 2.2.1. 在開始編碼之前，你可以先進行威脅建模、識別攻擊面、繪製資料流等

• 2.2.2. 在設計過程的早期最容易進行重大更改，這樣能夠避免事後重做

• 2.2.3. 儘早探索新的架構，並滿足基本的要求，越早著手越容易完成

2.3. 明確設計中的假定規則

• 2.3.1. 預測嚴重的誤解，從而使你永遠不會聽到任何人說：​“但我原本以為……”

• 2.3.2. 一些對文件很重要，但在設計中很容易忽略的常見假定規則

• 2.3.2.1. 會對設計空間帶來限制的預算、資源和時間

• 2.3.2.2. 系統是否可能成為攻擊目標

• 2.3.2.3. 非協商性要求，如與舊系統的相容性

• 2.3.2.4. 對於系統必須執行的安全級別的期望

• 2.3.2.5. 資料的敏感性，以及保護資料安全的重要性

• 2.3.2.6. 對系統未來變更的預期需求

• 2.3.2.7. 系統必須達到的特定效能或效率基準

• 2.3.3. 澄清假定規則對於安全性至關重要，因為誤解通常是一些問題產生的根本原因

• 2.3.3.1. 薄弱的介面設計或元件之間互動不匹配，而攻擊者恰恰能夠利用上述情況

2.4. 定義範圍

• 2.4.1. 如果一個設計的範圍很模糊，審查員可能會認為一些重要的安全內容不在範圍之內，而設計師也不會意識到有問題

• 2.4.2. 不要因為那些被遺漏在設計生態系統之外的部分，導致整個設計的失敗

• 2.4.3. 當你接管一箇舊系統時，你首先要努力理解它，要關注它最敏感的部分，以及對於維護安全性最基礎的部分，或者最明顯的攻擊目標

• 2.4.4. 你可以透過定義一個狹窄的範圍，使其對應需要重新設計的部分，來處理現有系統的設計迭代、衝刺(sprint)和主要修訂

• 2.4.5. 在重新設計的過程中，工作超出預期範圍是很常見的，並且這通常是一件好事，當超出預期範圍時，你應該根據需要對範圍進行調整

• 2.4.6. 很少有軟體設計是存在於“真空”中的，它們需要依賴於現有的系統、流程和元件

• 2.4.6.1. 確保設計能夠與它所依賴的事務很好地協作至關重要

2.5. 設定安全要求

• 2.5.1. CIA三元組是一個很好的起點

• 2.5.1.1. 描述保護私人資料免遭未經授權披露的需求（機密性）

• 2.5.1.2. 描述保護和備份資料的重要性（完整性）

• 2.5.1.3. 描述系統所需要的穩健和可靠程度（可用性）

• 2.5.2. 許多軟體系統的安全要求很簡單，但為了確保完整性並傳達優先事項，仍然值得對其進行詳細的說明

• 2.5.3. 要特別關注對於安全性要求很高的軟體，我們要仔細列舉它的安全要求

• 2.5.4. 安全性無關緊要

• 2.5.4.1. 由多個研究小組共享的天氣資料收集程式：溫度和其他大氣條件都可供任何人免費測量，並且披露這些資訊也是無害的

• 2.5.5. 一般性準則

• 2.5.5.1. 將安全要求表達為最終目標，而不規定“如何做”

• 2.5.5.2. 考慮所有利益相關者的需求

>  2.5.5.2.1. 在這些需求可能發生衝突的情況下，有必要找到一個良好的平衡點

• 2.5.5.3. 瞭解關鍵緩解措施的可接受成本和權衡

• 2.5.5.4. 當有不尋常的要求時，解釋這些要求的動機以及它們的目標

• 2.5.5.5. 設定可以實現的安全目標，無須要求完美

2.6. 威脅建模

• 2.6.1. 提高軟體架構安全性的最佳方法之一是將威脅建模納入設計過程之中

• 2.6.2. 先炮製一系列潛在的設計，依次對每一個設計進行威脅建模，透過某種彙總評估對它們進行評分，然後選擇最好的一個

• 2.6.3. 威脅建模會突出風險，進而促使你評估替代方案

• 2.6.4. 使用基準威脅模型來指導設計的另一種方式是突出設計決策帶來的額外風險的來源

• 2.6.4.1. 為敏感資料新增快取層，以提高響應時間

• 2.6.5. 好的軟體設計最終取決於主觀判斷

• 2.6.6. 策略

• 2.6.6.1. 進行靈活的設計，以便未來輕鬆地新增安全保護

>  2.6.6.1.1. 不要把自己置於不安全的境地

• 2.6.6.2. 如果有需要特別關注的特定攻擊，則對系統進行檢測，以推動對企圖濫用例項行為的監控

• 2.6.6.3. 當可用性與安全性發生衝突時，尋求使用者介面的替代方案

• 2.6.6.4. 使用一些能夠說明設計中可能存在的主要缺點的潛在場景（源自威脅模型）​，來解釋安全風險，並使用這些場景來證明不實施緩解措施的成本

3. 建立緩解措施

3.1. 設計介面

• 3.1.1. 介面定義了一個系統的邊界，描繪了設計或其元件的侷限性

• 3.1.2. 可能包括系統呼叫、庫、網路（客戶端/伺服器或點對點）​、程序間和程序內 API、公共資料儲存中的共享資料結構等

• 3.1.3. 複雜的介面通常都有自己的設計，比如安全通訊協議

• 3.1.4. 要記錄輸入的資料是否經過可靠驗證，或應該被視為不受信任的資料

• 3.1.5. 連線外部元件（設計範圍之外的元件）的介面應該符合這些元件的現有設計規範

• 3.1.6. 要想設計安全的介面，首先要對它們的工作方式做出可靠的描述，包括必要的安全屬性（即CIA、黃金標準或隱私要求）​

• 3.1.7. 審查介面的安全性相當於驗證它們的功能是否能夠正常執行，以及是否能夠在潛在威脅面前保持強健

• 3.1.8. 在某些情況下，另一種選擇是封裝介面以新增安全保護

• 3.1.8.1. 設計一個額外的軟體層來提供加密和解密，以確保該元件僅儲存加密後的資料，這樣即便資料洩露了也不要緊

3.2. 設計資料處理

• 3.2.1. 資料處理是幾乎所有設計的核心，因此保護它是很重要的一步

• 3.2.2. 減少對敏感資料的移動

• 3.2.2.1. 在設計級別上顯著降低風險的關鍵機會

• 3.2.2.2. 以後的實施中通常是不可能做到的

• 3.2.2.3. 要想減少傳遞資料的需要，一種方法是將資料與不透明的識別符號相關聯，然後使用該識別符號作為控制代碼，在必要時，你可以將其轉換為實際的資料

• 3.2.2.4. 標識公共資訊或資料是否具有保密要求

>  3.2.2.4.1. 這在資料處理的要求中是一個重要的例外，讓你能夠在合理的地方放鬆保護

• 3.2.2.5. 在沒有明確規定的情況下，始終將個人資訊視為敏感資訊，並且僅在有特定用途時才收集此類資料

>  3.2.2.5.1. 無限期地儲存敏感資料會帶來無盡的保護義務

>  3.2.2.5.2. 要想避免這種情況，你可以在可能的情況下（比如在其變得不活躍的多年後）銷燬不使用的資訊

3.3. 將隱私融入設計

• 3.3.1. 個人資訊的洩露經常會成為頭條新聞，我相信公司可以透過將隱私融入軟體設計中來獲得更好的結果

• 3.3.2. 隱私問題關乎資料保護給人帶來的影響，不僅涉及法律和監管問題，還涉及客戶期望和未經授權即披露所帶來的潛在影響

• 3.3.3. 當人們或流程對政策中的承諾產生了誤解，或者根本沒有考慮上述內容時，往往就會發生隱私問題

• 3.3.4. 審計是隱私管理的重要工具，即使我們只使用它來記錄對敏感資料的合法訪問

• 3.3.4.1. 透過仔細追蹤訪問記錄，我們可以及早發現並糾正有問題的訪問和利用

• 3.3.4.2. 在隱私資料洩露之後，如果沒有任何記錄可以指明誰可以訪問相關資料，那麼人們將很難有效地做出響應

• 3.3.5. 設計師要儘可能設計出明確的隱私保護措施

• 3.3.5.1. 如果你無法判斷隱私的合規性，請讓隱私政策的負責人在設計上簽字

• 3.3.6. 常用技術

• 3.3.6.1. 識別收集到的新型別資料，並確保隱私政策合規

• 3.3.6.2. 確認政策允許你將資料用於你想要的目的

• 3.3.6.3. 如果該設計可能不會對資料的使用施加限制，請考慮僅將訪問許可權賦予熟悉隱私政策規範以及瞭解如何審計合規性的員工

• 3.3.6.4. 如果政策限制了資料的保留期限，請設計一個系統來確保及時刪除相關資料

• 3.3.6.5. 隨著設計的發展，如果資料庫中的某個欄位被廢棄，請考慮將其刪除以降低洩露的風險

• 3.3.6.6. 考慮建立一個資料共享的審批流程，以確保接收方能夠獲得管理層的批准

4. 規劃整個軟體生命週期

4.1. 太多的軟體設計都默默地假定了這個系統會永遠存在下去，而忽略了一個現實，即所有軟體的生命週期都是有限的

4.2. 從首次釋出和部署，到更新和維護，再到最終退役，系統生命週期中的許多方面都存在重大的安全隱患，而且這些隱患隨著時間的推移很容易被忽略

4.3. 至少任何設計都應該考慮資料的長期處理

5. 權衡取捨

5.1. 在無法簡單地做出選擇的情況下，權衡取捨需要進行大量的工程判斷，同時還要考慮很多其他因素

5.2. 大多數設計工作都是在企業或專案社群中進行的，它們所需的安全級別在很大範圍內都是統一的

5.3. 設計階段是在軟體的各項競爭需求之間取得適當平衡的最佳機會

5.4. 當考慮到預定的截止日期、預算和人數限制、遺留的相容性問題，以及冗長的功能列表時，很少會（甚至完全不會）將安全作為重中之重

5.5. 安全軟體設計的核心是在這些理想化的原則與現實世界系統的實用需求之間取得適當的平衡

• 5.5.1. 完美的安全性從來不是我們的目標，額外的緩解措施也只能帶來有限的好處

• 5.5.2. 最佳設計從來都不容易確定，但在軟體設計中明確這些權衡，更有可能找到合理的折中方案

6. 設計的簡潔性

6.1. 如果安全性需要依賴於正確地做出一些複雜的決定或設計一些複雜的機制，我們都要小心：要看看是否有更簡單的方法來實現相同的目標

6.2. 在軟體中，我們卻很容易在不經意間繞過外部保護層，開啟通往內部的通道