可信設計
Categories:
安全架構與設計原則
安全三要素與安全設計原則
- 完整性 Integrity
- 可用性 Availability
- 機密性 Confidentiality
開放設計原則
Open Design
- 設計不應該是秘密, 開放設計更安全.
- 安全不依賴保密.
失敗-預設安全原則
Fail-safe defaults
- 訪問決策基於"允許", 而不是"拒絕".
- 預設情況下不允許訪問, 保護機制僅用來識別允許訪問的情況.
- 失敗安全: 任何一個複雜系統應該有功能失效後的應急安全機制, 另外對錯誤消息和日誌要小心, 防止信息洩露.
- 預設安全: 系統在初始狀態下, 預設配置是安全的, 通過使用最少的系統和服務來提供最大的安全性.
權限分離原則
Separation of Privilege
- 一種保護機制需要使用兩把鑰匙來解鎖, 比使用一把鑰匙要更健壯和更靈活.
- 權限分離的目的
- 防止利益衝突, 個別權力濫用
- 對某一重要權限分解為多個權限, 讓需要保護的對象更難被非法獲取, 從而也更安全.
- 分離不同進程的權責
系統可以預設設置 3 個角色, 角色間系統帳號權限相互獨立, 權責分離:
- 系統管理員: 負責系統的日常用戶管理, 配置管理.
- 安全管理員: 負責對用戶狀態, 安全配置的激活, 去激活管理.
- 安全審計員: 負責對前面二者的操作做日誌審計, 並擁有日誌導出權限, 保證系統用戶所有操作的可追溯性.
最小權限原則
Least Privilege
- 系統的每一個用戶, 每一個程式, 都應該使用最小且必須的權限集來完成工作.
- 確保應用程式使用最低的權限運行.
- 對系統中各用戶運行各類程式, 如數據庫, WEB 伺服器登, 要注意最小權限的帳號運行或連接, 不能是系統最高權限的帳號.
- 新建帳號時, 預設賦給最小權限的角色.
經濟使用原則
Economy of Mechanism
- 保持系統設計和代碼儘可能簡單, 緊湊.
- 軟體設計越複雜, 代碼中出現 bug 的機率越高, 如果設計儘可能精巧, 那麼出現安全問題機率越小.
- 刪除不需要的冗余代碼和功能模組, 保留該代碼只會增加系統的攻擊面.
- 設計可以重複使用的組件減少冗余代碼.
- 經濟適用: 簡單, 精巧, 組件化.
- 不要過設計
最小公共化原則
Least Common Mechanism
- 盡量避免提供多個對象共享同一資源的場景, 對資源訪問的共享數量和使用應應儘可能最小化.
- 共享對象提供了信息流和無意的相互作用的潛在危險通道, 盡量避免提供多個對象共享同一資源的場景.
- 如果一個或者多個對象不滿意共享機制提供的服務. 那他們可以選擇根本不用共享機制, 以免被其它對象的 bug 間接攻擊.
- 共享內存最小化
- 端口綁定最小化
- 減少連接, 防禦 Dos 攻擊
完全仲裁原則
Complete Mediation
- 完全仲裁原則要求, 對於每個對象的每次訪問都必須經過安全檢查審核.
- 當主體試圖訪問客體時, 系統每次都會校驗主體是否擁有該權限.
- 盡可能的由資源所有者來做出訪問控制決定, 例如如果是一個 URL, 那麼由後台伺服器來檢查, 不要在前端進行判斷.
- 特別注意緩存的使用和檢查, 無法保證每次訪問緩存的信息都沒有被黑客篡改過. eg. DNS 緩存欺騙.
心理可承受原則
Psychological Acceptability
- 安全機制可能為用戶增加額外的負擔, 但這種負擔必須是最小的而且是合理的.
- 安全機制應該儘可能對系統用戶友好, 方便他們對系統的使用和理解.
- 如果配置方法過於複雜繁瑣, 系統管理員可能無意配置了一個錯誤的選項, 反而讓系統變得不安全.
- 該原則一般與人機交互, UCD(User Centered Design)界面相關.
縱深防禦原則
Defense in Depth 縱深防禦是一個綜合性要求很高的防禦原則, 一般要求系統架構師綜合運用其他的各類安全設計原則, 採用多點, 多重的安全校驗機制, 高屋建瓴地的從系統架構層面來關注整個系統級的安全防禦機制, 而不能只依賴單一安全機制.