軟件開發安全設計原則

最小特權原則

對于請求存儲資源的主體，只應該分配最少的必要權限，而且應該保證賦予權限分配的必要時間最短。如果授予一個用戶或進程、組件超過其行為必要的權限范圍的許可，該用戶或進程、組件就有可能獲得或修改其沒有權限處理的信息。

權限分離原則

盡量把軟件劃分為不同的獨立組件，把權限分成不同的權限許可和認證條件，用戶授予不同的權限角色。不要將權限一次性授予一個用戶，應該根據需要提供多重認證與檢查機制再進行授予。

最少共享機制原則

避免多個主體共享同一個資源，因為敏感的信息可能通過相同的資源在這些主體之間共享，導致被其他用戶獲取。每個主體應該有不同的資源或不同的資源實例，在保證多用戶存取訪問靈活性的同時，防止由單一的共享機制導致潛在違背安全性的行為。

完全中立原則

每次主體對資源的請求，系統都應該實行認證和執行檢查，特別是和安全相關的內容，以避免錯誤地賦予主體過高的權限，或者在第一次授予權限之后，主體被攻擊之后攻擊者濫用相關權限。為了提高性能，一些系統會緩存主體的權限，這種做法易使系統產生較高的安全風險。

心理可接受程度原則

安全機制應該盡可能對用戶透明，只引入少量的資源使用限制，對用戶友好，才能在使用時方便用戶的理解和使用，真正起到安全防護的作用。如果安全機制妨礙了資源的可用性或使得資源難以獲取，那么用戶很可能會選擇關閉這些安全機制或功能。

默認故障處理保護原則

當系統失效或產生故障時，必須是以安全的方式來處理系統信息，系統故障處理默認應該是安全的設置。例如，即使喪失了可用性，也應該保障系統的機密性和完整性；故障發生時必須阻止未授權的用戶獲得訪問權限；發生故障后，應該不向遠程未授權的用戶暴露敏感信息，如錯誤號和錯誤信息、服務器信息之類。

經濟機制原則

復雜性是評估一個系統安全性的重要因素之一。如果設計、實現的功能非常復雜，那么系統存在安全漏洞的可能性就會大大增加，一些問題在復雜的系統中很難被及時發現。系統的設計和實現應該盡量簡單，以降低因復雜性帶來的安全問題。

不信任原則

開發者應該假定系統環境是不安全的。減少對用戶、外部系統、其他組件的信任，對外部實體所有的輸入都需要進行檢查。另外，也不應該認為每次對函數或系統的調用操作都會成功，必須對每次函數或系統調用返回值進行檢查，并進行正確的處理。

縱深防御原則

軟件應該設置多重安全措施，并充分利用操作系統提供的安全防護機制，形成縱深防御體系，以降低攻擊者成功攻擊的幾率。多重安全措施使攻擊者繞過每一個機制才能達到目的，提高了攻擊者的攻擊成本，降低了安全危害。

保障最弱環節原則

攻擊者一般從系統最薄弱的環節發起攻擊，而不是針對已經加固的組件。相對于破解一個數學上已經證明了比較安全的算法，攻擊者更喜歡利用軟件的安全漏洞。因此，軟件開發者必須了解自己軟件的薄弱點，對這些弱點實施更強的安全保護措施。

公開設計原則

應該假定攻擊者有能力獲取系統足夠的信息，不能依賴于攻擊者“不可能知道”來保護系統的安全。如果設計的加密算法存在弱密鑰，或者系統設有萬能口令等，攻擊者通過反匯編分析能夠獲取這些信息，攻擊者還可能是內部被辭退的員工，因此，依賴于攻擊者無法掌握某些特定信息來保護系統的安全是不可靠的。

隱私保護原則

系統收集到的用戶信息都必須實施妥善和安全的保護。攻擊者獲得了用戶的隱私數據之后，可以進一步發起針對用戶的各種攻擊，如欺騙等，因此不應該向其他用戶泄漏用戶的隱私信息。

攻擊面最小化原則

攻擊面（attack surface）通常也稱受攻擊面，是指對一個軟件系統可以采取的攻擊方法的集合。因為攻擊者對軟件的攻擊是通過其暴露在外部的接口、功能、服務和協議等資源來實施的，通過對每種資源計算其被攻擊成功的可能性，并將這些可能性綜合歸納，即可以衡量軟件的攻擊面大小。可以看出，一個軟件的攻擊面越大，其安全風險也就越大。

減少攻擊面是安全設計中的一個重要步驟，軟件設計人員需要仔細評估軟件中所有的功能模塊和接口的特性，分析其可能存在的安全風險，并設定相應的限制措施。如果一個功能/數據接口不是必要的，則應該取消或禁止，或者默認不開啟。如果一個功能/數據接口的配置沒有特殊的理由，則默認應該按安全的方式進行設置。

回答所涉及的環境：聯想天逸510S、Windows 10。